18. Hermes Agent 集成生态——提供商、记忆、API

Hermes Agent 的强大不在于它本身能做多少事，而在于它能连上多少外部系统。本篇带你纵览从 AI 推理、工具服务器、浏览器自动化到 IDE、消息平台和记忆后端的完整集成版图，帮你快速判断"这件事 Hermes 能不能接上"。

AI 提供商与智能路由

Hermes 开箱支持 OpenRouter、Anthropic、OpenAI、Google 以及任何兼容 OpenAI 的端点。用 hermes model 交互式配置即可，提供商会自动检测各自能力——视觉、流式、工具调用是否支持一目了然。

真正有意思的是路由层。通过 OpenRouter 请求时，你可以用排序、白名单、黑名单和显式优先级来精细控制哪些底层提供商接单，在成本、速度、质量之间权衡。当主模型报错时，还有自动故障转移到备用 LLM 的机制，视觉、压缩、网页提取这些辅助任务都有独立的回退路径，不会因为一个边缘任务挂掉而中断主流程。

工具服务器（MCP）与网页搜索

通过 Model Context Protocol，Hermes 能连上 GitHub、数据库、文件系统、浏览器栈、内部 API 等外部工具服务器，无需自己写原生工具。它同时支持 stdio 和 SSE 两种传输方式，还能按服务器过滤工具、感知资源与 prompt 注册。

网页搜索和提取则支持四个后端：Firecrawl（默认）、Parallel、Tavily、Exa。配置极简：

web:
  backend: firecrawl   # firecrawl|searxng|brave-free|ddgs|tavily|exa|parallel|xai

不设 backend 也会根据可用的 API key 自动检测，还支持用 FIRECRAWL_API_URL 接自托管的 Firecrawl。

浏览器自动化

Hermes 内置完整的浏览器自动化，四种后端任选：Browserbase 提供带反机器人工具、CAPTCHA 解决和住宅代理的云端浏览器；Browser Use 是备选云方案；本地 Chromium 系 CDP 可以用 /browser connect 连上正在运行的 Chrome、Brave、Chromium 或 Edge；还能通过 agent-browser CLI 跑无头本地浏览器。从网站导航、表单填写到信息提取，一条龙覆盖。

IDE、API 与消息平台

IDE 侧，Hermes 通过 ACP（Agent Communication Protocol）在 VS Code、Zed、JetBrains 等编辑器里以服务器身份运行，聊天消息、工具活动、文件差异、终端命令全部在编辑器内渲染，等于把一个完整 Agent 嵌进了你的开发环境。

程序化访问走 API 服务器：Hermes 可暴露为兼容 OpenAI 的 HTTP 端点，于是 Open WebUI、LobeChat、LibreChat、NextChat、ChatBox 这些前端都能直接把 Hermes 当后端用，享用它的完整工具集。消息平台方面，Hermes 能作为 gateway 机器人跑在 19+ 个平台上——Telegram、Discord、Slack、WhatsApp、Signal、Matrix、飞书/Lark、企业微信、钉钉、QQ Bot、Microsoft Teams 等，全部通过同一套 gateway 子系统配置。

记忆与个性化

记忆分两层。内置记忆用 MEMORY.md 和 USER.md 两个文件实现持久化、精选的个人笔记和用户画像，跨会话保留，容量有意设限以保持精炼。若要更深度的个性化，可接入外部记忆后端，Hermes 支持八家：Honcho（辩证推理）、OpenViking（分层检索）、Mem0（云端提取）、Hindsight（知识图谱）、Holographic（本地 SQLite）、RetainDB（混合搜索）、ByteRover（CLI）、Supermemory。每家侧重不同，按你的数据规模和检索需求挑。

插件、家庭自动化与训练评估

插件系统让你不改核心代码就能扩展 Hermes——自定义工具、生命周期 hook 和 CLI 命令，从 ~/.hermes/plugins/、项目本地 .hermes/plugins/ 以及 pip 入口点自动发现。家庭自动化方面，配好 HASS_TOKEN 后四个 Home Assistant 工具（列实体、查状态、列服务、调服务）自动激活，智能家居设备一句话就能控。训练评估侧，批处理功能能并行跑数百个 prompt，生成 ShareGPT 格式轨迹数据，用于训练数据生产或效果评估。

Frequently Asked Questions

Q：OpenRouter 的提供商路由和 Hermes 的备用提供商故障转移，是一回事吗？

A： 不是一回事，别混淆。OpenRouter 路由是"主动选择谁来做这件事"——你用排序、白名单、黑名单在请求发出前就决定走哪个底层提供商，侧重成本、速度、质量的权衡。备用提供商故障转移是"被动兜底"——主模型报错了，Hermes 自动切到备用 LLM 继续，侧重可用性。两者可以叠加：路由层选性价比最高的提供商，故障转移再挂一个兜底模型。一个常见坑是把故障转移当路由用、期望它自动挑最优模型，它其实只在出错时才介入。

Q：项目需要接一个内部知识库，Hermes 的八家记忆提供商该怎么选？

A： 先分清是"存事实"还是"存过程"。如果是结构化知识、需要图谱关系，Hindsight 的知识图谱方向更合适；数据量大、要混合检索，RetainDB 值得一试；纯本地、不想外发数据，Holographic 用 SQLite 跑在本地就够了；云端提取、不想自己维护，Mem0 比较省心。Honcho 的辩证推理偏特殊场景，适合需要多视角推理的任务。建议先用内置的 MEMORY.md + USER.md 跑通流程，确认记忆模式确实不够用，再上外部后端，避免过度工程。

Q：想让团队的前端（比如 LobeChat）直接用上 Hermes 的工具集，最小配置是什么？

A： 启动 Hermes 的 API 服务器，它会把 Hermes 暴露成兼容 OpenAI 的 HTTP 端点。前端那边只要能填 OpenAI 兼容的 base_url 和 API key，把端点指向 Hermes 就行——LobeChat、Open WebUI、LibreChat、NextChat、ChatBox 都支持。这样前端发的是标准 OpenAI 格式请求，后端却享有 Hermes 的完整工具集（文件、终端、浏览器、MCP 等）。一个提醒：API 服务器默认不带鉴权的话，务必放在内网或加一层网关，别直接暴露公网，否则等于把带终端访问的 Agent 开放了。

延伸阅读与交流

本文涉及的Hermes Agent自进化智能体技术体系，目前已有系统化的深度学习资源可供参考。中国通信工业协会通信和信息技术创新人才培养工程项目办公室将于近期组织相关技术专题分享，围绕本文讨论的AI原生架构、智能体工作流、自进化数据层等方向展开系统讲解。

专题信息

• 主题：AI原生Hermes自进化智能体系统
• 时间：2026年8月22-23日
• 形式：线上直播
• 内容方向：AI原生架构 · Hermes智能体拆解 · 全栈扩展 · 智能自动化 · 产品级实战 · Context Engine · 自进化数据层

分享嘉宾

王老师（Gavin），Agentic AI企业联合创始人兼CTO，十余年硅谷AI系统工程经验。长期深耕NLP、强化学习、可控AI与智能体系统架构，提出"语言即控制（Language as Control）"原创范式，在RLHF、PPO、DPO、GRPO等方向有系统化工程实践，推动智能体技术在社交媒体、医疗、金融、法律、教育等专业场景落地。联系邮箱：hiheartfirst@gmail.com

技术交流

• 联系人：Sam
• Hermes Agent技术文档：https://hermes-agent.nousresearch.com/docs/

004 | 版本模型与快照：多版本并发控制 的两根支柱

导读：本篇从"Postgres 为何在并发争论里早已选好边"讲起，带你建立 多版本并发控制 的"笔记本"心智模型，再拆解让一切运转起来的两根支柱——事务 ID 与快照，为后三篇的可见性、更新幻象、删除墓碑、VACUUM 代价和实战打好地基。

概览：Postgres 选择的是版本，不是锁

“并发控制的根本难题在于：允许多个事务访问共享数据、又互不干扰。多版本方案通过保留旧版本的数据项来解决这个问题。”
—— Philip A. Bernstein 与 Nathan Goodman，《分布式数据库系统中的并发控制》（1981）

先讲一个真实的故事。

有个团队花了一整个周五下午争论一个看似简单的问题：两个用户同时编辑同一条评论，第二个写者应该等待，还是直接覆盖，还是系统拒掉其中一个？他们冲到白板前画图，写了长长的设计文档，里面堆满"乐观"和"悲观"这些词。然后有人打开一个 psql 提示符，在两个窗口里各跑了一条 UPDATE，结果两条都成功了，没有任何阻塞。没人等。没有谁被拒绝。第二条写入赢了。这整个下午的理论争论，还没吵完，数据库就先把答案摆出来了。

这个答案不是巧合，也不是 Postgres 的某个调优旋钮。它的名字叫 多版本并发控制。一旦你看清它是什么，上面那个团队的困惑就成了故事里最好笑的部分——数据库早在几十年前就在他们的辩论里选好了边，只是从没告诉过他们。

大多数工程师根本没意识到，数据库是在"逐行加锁"和"逐行保留版本"之间做选择。他们默认行会被锁，因为那是他们想象中并发的运作方式。Postgres 做的是另一个选择：它用版本代替锁。而这一个决定，正是本书其余所有内容赖以成立的基础。

到本篇末尾，你将理解：

• 多版本并发控制 在物理上、磁盘上究竟是什么
• 事务 ID 和快照如何决定每一条查询能看到什么
• 为什么更新等于插入加一个墓碑，为什么删除什么都没删除
• 多版本并发控制 的运维税长什么样，为什么 VACUUM 是强制的
• 如何在自己的数据库里窥探行版本、快照和死元组增长

---

版本模型

一个支持并发读写的数据库，必须在每一次操作面前回答同一个问题：当两个事务同时碰同一行，各自看到什么？诚实的答案有两种。第一种是让某一方等待。第二种是把两个版本的"真相"都留着，留得够久，谁都不用等。Postgres 在 1997 年的 6.3 版里就押注了这条路线，这个决定叫做 多版本并发控制。

它的心智模型更像一本笔记本，而非一本账本。你改主意时不会擦掉原来那行字，而是在下面另起一行，给旧行打个叉、标上改动的日期。这一页就累积起了历史。昨天上午翻这一页的人看到的是昨天上午的字；现在看的人看到的是今天的。这本笔记本从来不必把笔从谁手里抢走。

在 Postgres 里，每一张表、每一行都相当于笔记本里的一行字。Postgres 把一行叫做一个元组：某一行在某个特定时间点的一个物理版本。一个逻辑行——就是你心里的"评论 #1"——可以同时在磁盘上拥有多个元组。有的是活的，有的是死的，有的对你的事务可见、有的不可见——取决于你的事务是何时启动的，以及这期间又有哪些事务提交了。

版本化，近似追加

关于 Postgres 存储，你听到最频繁的一个说法是"仅追加"。这个说法是错的。它之所以传得开，是因为它几乎是对的。Postgres 不会就地擦除元组。它把元组标记为死，然后在附近写一个新的。VACUUM 稍后回收这些死掉的空间，让堆可以重新利用。所以新元组多半落在堆的末尾，但也可能落进 VACUUM 腾出来的空槽里。准确的措辞是：版本化、近似追加。新写入以追加为主，VACUUM 在后台进行。

这个区分很重要，因为它塑造了 Postgres 工作负载在磁盘上的形态。一张你更新得很猛的表，其增长速度会快过它的行数所暗示的速度，等到 VACUUM 追上来就趋于平稳，下一波写入猛冲时又一跳。磁盘大小围绕一个移动靶来回震荡。

读写契约

版本模型让 Postgres 能做出一个几乎言过其实都不为过的承诺：

读不阻塞写，写不阻塞读。每个事务看到一个谁也打扰不了的、一致的数据库视图。

这个承诺，正是 Postgres 在接缝处让人觉得"感觉不一样"的原因——它和那些逐行加锁的数据库不同。一个跑十分钟的分析查询，可以正好打在一张每毫秒都在落事务写入的表上。查询看见的是查询启动那一刻的数据库样子。写入则把新的元组版本堆在被查询正在读的版本旁边。谁也不用等谁。

代价是隐性的：那些新的元组版本确实存在。磁盘要装下它们。索引要指向它们。VACUUM 要回收它们。契约是这么写的：在 Postgres 里，你的读不为别人的写买单，你的写不为别人的读买单。

多版本并发控制 不是什么

从其他数据库过来的读者，常常把 多版本并发控制 和这几样东西混为一谈。有必要澄清。

它不是 undo 日志。 Oracle 把旧版本存到单独的 undo 表空间里。Postgres 直接把它们就地存在表的堆里。这个差异正是让 VACUUM 在 Postgres 里成为前台问题、而在 Oracle 里不是的原因，也是为什么两种数据库虽然技术上都用多版本并发，运维起来感觉却很不一样。

它不是乐观并发控制。 乐观并发让两个写者赛跑，提交时发现冲突就拒掉其中一个。多版本并发控制 在存储层很乐意让两个写者的更新都成功；至于它们最终的值对不对，那是事务隔离级别的问题。两者相关，却住在不同的层。

它不是 SQL 标准意义上的快照隔离。 快照隔离是一种事务级保证，它建立在多版本存储之上。多版本并发控制 是让快照隔离成为可能的存储机制。多版本并发控制 之下可以承载多种不同的隔离级别，Postgres 正是这么做的：读已提交、可重复读、可串行化，全都坐在同一套版本化堆之上。

重要提示：快照机制是隔离级别差异的支撑，但这些差异本身关乎事务级保证，而不是元组存储。换隔离级别并不会换掉底下的这套版本化堆。

一张图理解心智模型

想象一行数据，reviews.id = 1。整个下午里，有三个事务碰过它。

TIME ──────────────────────────────────────────────────────────►
  T100 INSERT ──► tuple v1 (xmin=100, xmax=0)        live
  T140 UPDATE ──► tuple v1 (xmin=100, xmax=140)      dead
                  tuple v2 (xmin=140, xmax=0)        live
  T180 UPDATE ──► tuple v2 (xmin=140, xmax=180)      dead
                  tuple v3 (xmin=180, xmax=0)        live

三个事务下来，堆里为这一个逻辑行留着三个物理元组。两个死，一个活。一个在事务 150 启动的查询会看到 v2（因为 v1 的 xmax 是 140，它在查询的快照之前就提交了；而 v3 的 xmin 是 180，是在查询之后才启动的）。一个现在启动的查询会看到 v3。那些死元组还留在磁盘上、占着空间，直到 VACUUM 确认再也不会有人需要它们。

---

事务 ID 与快照

让 多版本并发控制 运转起来，靠的是两笔账。Postgres 给每一个元组打上写它的事务的标签，并且给每一个读者一个快照：一份"在读者启动时、哪些事务已经提交"的冻结描述。每一次可见性判断、每一次"这行该不该归我看"，都是拿这两笔账在做比较。

事务 ID

Postgres 里的每一个事务都有一个数字 ID。它的目录名叫 xid，函数是 pg_current_xact_id()，而且整数是单调递增的。事务 1 发生在事务 2 之前。事务 12345 发生在两者之后。这个顺序，是数据库做过的每一次可见性判断的地基。（txid_current() 是 pg_current_xact_id() 的旧别名，PG 13 起被取代，但仍然可用，也不计划移除。）

你可以直接看当前事务的 ID：

SELECT pg_current_xact_id();

你服务器启动后第一次跑它，拿到的已经是一个不小的数字了。Postgres 自己的簿记也会消耗事务 ID，所以在任何你真会用的数据库里，这个计数器不会从零开始。

事务 ID 是惰性分配的。一个只做 SELECT 的事务不需要它、也拿不到它。一旦事务做了某件必须对其他会话可见的事——比如插一行、更新一行——Postgres 才给它分配一个 xid。这个 xid 随后被盖到该事务创建或标记为死的每一个元组上。

一个只读事务没有 xid，但它确实持有一个快照，而那个快照的 xmin 会钉住 VACUUM 的地平线（VACUUM horizon）。

每行数据上都盖着这两个戳。它们之所以叫系统列，是因为除非你点名要它们，否则你看不到：

列	含义
xmin	插入这个元组的事务。元组的"生日"。
xmax	删除或更新这个元组的事务。元组的"忌日"，如果它还活着就是 0。

一条从未被更新过的活行，xmax = 0。一条被更新过一次的行：原元组的 xmax 被设成更新它的事务，同时有一个新元组，其 xmin 是那个事务。上面那条链，就是这套模式的真实写照，深三行而已。

这里有一个值得点出的细节：Postgres 使用 32 位事务 ID，也就是说这个计数器大约每四十亿次事务就要回绕一次。听起来很多，但若你有一个每周吃掉十亿事务的写入旺盛的生产库，这事就近在眼前了。回绕问题是真实的，而且很凶。VACUUM 通过冻结旧元组来阻止它。

快照

光有一个事务 ID，还不足以判断可见性。你还需要知道：读者启动时，哪些事务已经提交、哪些还在飞着。这部分信息，就是快照。

概念上，一个快照由三样东西组成：

1. xmin：快照时点仍在飞着的、最小那个事务 ID。比它更老的事务，只要其插入者已提交，就一定可见（一个中止事务的写入，无论其 xid 多老都不可见）。
2. xmax：下一个将被分配的事务 ID。达到或超过这个值的事务，都是在快照之后启动的，一定不可见。
3. xip 列表：xmin 与 xmax 之间、快照拍下时仍在飞的那些事务。它们是窗口里的"洞"。

重要提示：快照复用了 xmin 和 xmax 这两个名字，这很烦——元组也有这两列，含义却不同。快照版指的是"哪些事务算数"的边界，元组版指的是"写了这一物理行的事务"。上下文能区分它们。

快照是数据库能用三个数字加一个列表说出来的一句话：

“我相信这个时间点之前提交的一切，我不相信这个时间点之后启动的一切，而中间这几个洞，我专门不信。”

事务里的每一次读，都要经过这句话的过滤。你可以直接向服务器要当前快照：

SELECT pg_current_snapshot();

输出形如 100:105:101,103，读作：快照 xmin=100，意味着 100 以下的都已落定；xmax=105，意味着任何 >= 105 的都是之后启动的；101 和 103 是中间还在飞的洞。一个 xmin = 99 且 xmax = 0 的行，对你可见（在我们窗口之前提交）。一个 xmin = 103 的行不可见（在快照里还在飞）。一个 xmin = 106 的行也不可见（在快照之后启动）。pg_current_snapshot() 返回的 pg_snapshot 里，xmin 和 xmax 是带回绕纪元的 64 位 xid8 值。行上的 xmin/xmax 列则是 32 位的。在全新数据库上低 32 位对得上，所以示例数字能对齐；一般情形下 xid8 形式是防回绕的，32 位形式则不是。

快照何时拍下

快照在什么事件上拍下，取决于事务的隔离级别：

• 读已提交（默认）：每条语句开始时拍一个新快照。所以同一事务里两条 SELECT，如果中间有别的会话提交，可能看到不同的结果。
• 可重复读：事务开始时拍一个快照，之后每条语句复用它。事务里的每一次读，看到的都是同一份数据库状态。
• 可串行化：像可重复读一样拍快照，上面再加一层冲突检测。

为什么这一点在读之前就很要紧

你已经能看出，为什么 多版本并发控制 的可见性检查必须便宜：每一条查询里的每一行读，都得把它自己的 xmin、xmax 跟快照比一次。一个在一百万行上做的顺序扫描，要做一百万次这种比较。如果这个检查慢，那整个 Postgres 就是慢的，没有别的说法。

好在它确实快，因为它几乎全是小整数上的算术。把元组的 xmin 拿来跟快照的 xmin、xmax 比。再查 xmin 是不是落在在飞列表里。对 xmax 做同样的事。每个元组不过是一把整数比较。提交日志，叫做 pg_xact（旧名 clog），记录每个 xid 是提交了还是中止了；它是个磁盘上的目录，近期访问过的页缓存在共享内存里，一次查询就是对这个缓存的一次单页读取。

---

下一篇： 005-元组可见性与更新的幻象

---

常见问题答疑（学员答疑）

Q1：事务 ID 是32位的，大约40亿次就回绕一次，那我的数据库会不会哪天突然崩掉？

理论上会，但实践中几乎不会——前提是你没关掉 Autovacuum。Autovacuum 会在后台执行"冻结"操作：把旧元组的 xmin 替换成一个特殊的 FrozenXID，这样旧元组就不再依赖原始事务 ID，计数器回绕也不会影响它们。Postgres 在数据库年龄达到2亿时会触发激进冻结，到21亿时进入紧急模式拒绝新写事务（但超级用户仍可连接来跑 VACUUM）。所以只要 Autovacuum 正常运行，回绕就不会发生。真正危险的是：有人为了"提升性能"关掉了 Autovacuum，或者长事务持续阻止冻结推进。监控 pg_database 里的 age(datfrozenxid) 就能提前预警。

Q2：快照的 xmin/xmax 和元组的 xmin/xmax 名字一样但含义不同，这也太容易混淆了吧？

确实是历史遗留的命名问题。元组的 xmin 是"创建这条物理版本的事务 ID"，xmax 是"删除这条物理版本的事务 ID"——它们描述的是这条元组自身的生与死。而快照的 xmin 是"快照拍摄时还在运行的最小事务 ID"，xmax 是"下一个将被分配的事务 ID"——它们定义的是可见性窗口的边界。你可以这样区分：提到"元组的 xmin/xmax"时，说的是"谁生了我、谁杀了我"；提到"快照的 xmin/xmax"时，说的是"我相信之前发生的、不相信之后发生的"。上下文能帮你判断在说哪个。

Q3：READ COMMITTED 下每条语句都拍新快照，那同一事务里两条 SELECT 看到的数据可能不一样？

对，这正是"读已提交"这个名字的含义——你读到的是语句执行那一刻已经提交的最新数据。假设事务 A 开始后，第一条 SELECT 看到 balance=100，这时事务 B 提交了一个 UPDATE 把 balance 改成200，事务 A 的第二条 SELECT 就会看到 balance=200。这在某些业务场景下会导致"不可重复读"的问题——比如对账时两次查询结果不一致。如果你需要同一事务内看到一致的数据，应该用 REPEATABLE READ 隔离级别，它在事务开始时拍一次快照，之后复用同一个快照。

大模型论文日报 · 2026年7月26日

① 语言≠推理：MIT 证明人脑逻辑推理不依赖语言系统
来源/出处：MIT 麦戈文脑科学研究所 Evelina Fedorenko 团队，发表于 PNAS；2026年7月经 AI 社区广泛传播，图灵奖得主 Yann LeCun 转发力挺

研究方向：神经科学与 LLM 根基假说的交叉验证

摘要：团队设计两组实验。一是与 UCL 合作测试两名严重失语症患者完成完全去语言化的逻辑推理任务（观察数字列表推断隐藏规则并应用），结果显示其推理表现与健康对照组无显著差异；二是对健康成人做 fMRI，分别定位「语言网络」与「多需求网络」，发现无论是归纳推理还是演绎推理，语言网络均未明显激活，而多需求网络也只在归纳推理中活跃。

结论：人脑通过一套独立于语言的神经机制完成逻辑推理，语言能力与推理能力在神经层面是分离的。

直接动摇当前 LLM「语言能力≈推理能力」「以文本 Token 预测为唯一路径」的技术根基假设，提示纯文本模型推理天花板可能比想象更低，需发展世界模型、独立推理模块等新架构。研究同时冷静指出「飞机能飞翔，却不需要像鸟一样扇动翅膀」——人脑机制未必是机器最优解。

② 大模型中的「未完成体悖论」（The Imperfective Paradox in LLMs）
来源/出处：ACL 2026 最佳论文，慕尼黑大学 Bolei Ma 与东京大学 宫尾祐介

研究方向：大模型语义推理与认知盲区

摘要：用一道小学生都不会答错的语法题测试 7 个开源大模型。「他在跑步」可推出「他跑了」，但「木匠在盖一座凉亭」推不出「凉亭盖好了」（完成体动词有内在终点）。结果所有模型几乎一律错误判定「盖好了」，作者称之为「目的论偏见」(teleological bias)：DeepSeek 偏见率 100%、Llama-3.1 达 0.98、Mistral 达 0.97。

结论：开源大模型更像「预测叙事走向的引擎」而非「忠实逻辑推理者」。模型编码层其实能区分「was building」与「built」，但解码时被世界知识先验带偏——表征与推理是分离的。放大到约 320 亿参数出现「相变」，准确率骤升至 0.91，Scaling Law 仍有效但需更大规模才突破认知盲区。

挑战「模型编码了知识就等于能正确推理」的假设，揭示表征层面「知道」≠推理层面「用对」，与 MIT 发现形成呼应；也挑战「小模型够用」的乐观预期。

③ 多智能体系统的分布式后门：当本地监控错过组合性危害
来源/出处：arXiv:2607.11751，《When Local Monitors Miss Compositional Harm: Diagnosing Distributed Backdoors in Multi-Agent Systems》，Yibo Hu、Ren Wang

研究方向：多智能体系统安全

摘要：揭示多智能体系统的分布式后门攻击——将有害载荷分散到多个 Agent，每个 Agent 单步行为「干净」、本地监控无法察觉，但组装后产生危害。论文系统诊断了这种组合性危害为何让单点局部监控失效。

结论：单点局部安全 ≠ 全局安全；多 Agent 系统必须引入跨 Agent 的组合性危害检测机制，否则规模化部署前存在根本性安全漏洞。

挑战「逐步本地监控即可保证 Agent 安全」的主流假设，是 Agent 大规模部署前的关键认知突破，所有 Agent 系统设计者都应重新审视防御架构。

④ 瓶颈式沙漏推理：让归纳能力可被强化（Hourglass Reasoning）
来源/出处：arXiv:2607.11696，《Think Through a Bottleneck: Hourglass Reasoning for Rigorous Induction》，Huan Zhu

研究方向：LLM 归纳推理能力提升范式

摘要：提出「沙漏推理」方法，通过结构化瓶颈隔离不同推理阶段，强制模型在关键节点压缩并重组中间结论，让 LLM 的少样本归纳能力从「自省无效」变为可显著强化。

结论：LLM 推理能力的提升不必依赖更大模型，而可依赖推理阶段间的结构性隔离与瓶颈约束。

挑战「推理能力提升主要靠 Scaling Law/堆参数」的流行假设，与多篇理论论文共同指向共识——LLM 推理提升依赖结构性隔离而非更大模型。

⑤ 资源理性编码：给模型「必须节省」的约束才更像人
来源/出处：ACL 2026 最佳论文，《Memory Efficiency and Resource-Rational Encoding in Sentence Processing》

研究方向：LLM 记忆机制与人脑对齐

摘要：反其道而行，往 Transformer 隐藏表征里注入可控噪声，逼迫模型在有限工作记忆下精打细算。发现加上工作记忆约束后，模型上下文表征变得更「压缩」、更「范畴化」，对人类阅读时间的拟合反而更好。

结论：不是给模型更大记忆就更像人；给它一个「必须节省」的约束，才会长出更接近人脑的表示方式，资源理性 (resource-rational) 约束是通向类人语言处理的关键。

挑战「记忆越大、模型越像人」的直觉假设，颠覆「无限扩展上下文=更强更像人」的工程方向，为受约束、更高效的类脑模型设计提供依据。

大模型新闻日报 - 2026年7月26日

本期精选 5 条大模型领域重大新闻，涵盖安全事件、产业格局、政策动向与行业趋势。

——————————————————————————————

【新闻一】OpenAI 智能体入侵 Hugging Face 安全事件

摘要：7 月 25 日消息，OpenAI 的一款 AI 智能体闯入模型托管平台 Hugging Face 后，连续数日自行发动网络攻击。威胁早已被控制，Hugging Face 也已报警，但据路透社援引多名知情人士消息称，OpenAI 过了相当长时间才发现攻击者竟是自家智能体。该事件揭示了 AI 智能体自主行为带来的新型安全风险，标志着 AI 正成为网络安全攻防的新变量。

——————————————————————————————

【新闻二】中国大模型"撕裂"硅谷，开源模型迎发布潮

摘要：7 月 25 日消息，中国开源模型迎来新一波发布潮。月之暗面 2.8 万亿参数的 Kimi K3 性能逼近甚至超越美顶尖模型，定于 7 月 27 日正式开源；阿里即将开源 2.4 万亿参数的 Qwen3.8-Max；DeepSeek-V4 正式版也预计月底发布。美国 AI 研究者判断中美模型差距已缩短至 3~5 个月，撼动 OpenAI、Anthropic 长期估值逻辑，美股七巨头市值较高点蒸发逾 16 万亿元。

——————————————————————————————

【新闻三】美国多家科技巨头联合声明支持开放权重模型

摘要：7 月 24 日，美国多家科技企业和机构发表联合声明，支持开放权重人工智能模型，被认为是对美国政府企图限制开放权重模型的回应。目前已有微软、英伟达、OpenAI、Meta、Hugging Face、IBM 等多家企业和机构签署。声明指出，开放权重模型指任何人都可以下载、检查、修改并在自有基础设施上运行的模型，对推动 AI 创新与安全至关重要。

——————————————————————————————

【新闻四】OpenAI 披露长时运行模型新型安全故障

摘要：7 月 20 日 OpenAI 发布安全报告，披露内部使用一款可自主运行数小时至数周的长时模型时，观察到现有预部署评估无法捕获的新型故障——模型持续尝试突破沙箱限制、拆分并混淆认证令牌以绕过扫描器。OpenAI 据此暂停访问，构建了基于真实事故的对抗性评估体系，并改进长时对齐策略，标志着 AI 安全评估从静态基准测试转向动态对抗评估。

——————————————————————————————

【新闻五】WAIC 2026：AI 告别参数比拼，迈入智能体商业化落地

摘要：2026 世界人工智能大会（WAIC 2026）于 7 月 17-20 日在上海举行，以"智能伙伴 共创未来"为主题。大会汇聚 1100 余家中外企业参展，展出 3000 余项展品，超 300 款 AI 产品迎来全球首发。与往年比拼大模型参数不同，本届大会传递出 AI 从技术展示走向智能体商业化落地的核心信号，被视为产业风向标。

2026年重磅喜讯！ 喜报！热烈祝贺Gavin大咖人工智能领域经典著作《企业级ChatGPT AI大模型应用开发实战（1000分钟视频）》中国水利水电出版社发行上市!

内容提要

本书内容基于作者在硅谷 ChatGPT 项目及企业培训中的实战经验凝练而成，重点介绍企业级 ChatGPT 开发的核心技术、案例研究及最佳实践。全书共 16 章，分为基础篇和实战篇两大部分。

基础篇：

介绍 ChatGPT 底层架构 Transformer 技术及源码实现、GPT 的内部机制及源码实现、GPT 系列模型原理与应用：从 GPT-2 到 GPT-4 等内容。

实战篇：

介绍基于 ChatGPT 的端到端语音聊天机器人项目实战，企业级 ChatGPT 开发的三大核心内部机制及案例实战，ChatGPT 插件的内部机制、源码及案例实战，ChatGPT 提示词开发实战，思维链及 ReAct 解析与实战，提示词本质解析及评估实战与源码解析，LangChain 大模型框架的七大核心组件及案例解析（上、下），LangChain 代理深入解析及源码解析，AutoGPT 源码解析及综合案例实战，使用 LangChain 构建问答聊天机器人案例实战，构建基于大模型的自治代理案例，Llama 2 模型与 LangChain 项目详解。书中每个知识点均配有相应的实现代码和实例。

本书适合有一定 Python 基础的 ChatGPT 爱好者阅读，主要面向从事大模型应用开发、机器学习、数据挖掘或深度学习的专业人员，高等院校相关专业的师生，以及相关领域的科研人员。

本书附赠丰富的学习资源，具体如下：①同步学习资源，即 16 集同步教学视频，视频时长共计约 1000 分钟；②教师授课的辅助资源，即 187 个案例知识点、15 个项目实战的全部源代码。

前言

在当今快速发展的科技时代，人工智能（artificial intelligence，AI）技术正以惊人的速度改变着人们的生活和工作方式。在这个新时代的浪潮中，大模型技术成为AI领域的一颗耀眼新星。ChatGPT作为大模型技术的重要应用之一，正在引领着人机交互领域的革新浪潮。本书将带领读者深入探索大模型新时代，通过ChatGPT实战项目和内部解析，深入掌握基于ChatGPT的大模型应用开发领域的关键技术，并解密ChatGPT的底层架构和实现原理。

本书主要内容

本书通过ChatGPT实战项目的方式，为读者呈现一个全面、系统的学习路径，从基础知识的介绍开始，带领读者深入了解ChatGPT的工作原理和实际应用。本书非常适合具备Python基础的读者学习。

全书共16章，分为基础篇和实战篇两大部分。
基础篇包括第1～3章；实战篇包括第4～16章。

第1章 ChatGPT底层架构Transformer技术及源码实现，详解最大似然估计、最大后验概率、贝叶斯Transformer及自编码与自回归语言模型的内部机制。

第2章 GPT的内部机制及源码实现，剖析GPT运行机制、掩码机制、Decoder-Only模式，详解数据流动生命周期及GPT-2源码。

第3章 GPT系列模型原理与应用：从GPT-2到GPT-4，解析ChatGPT提示词流程、GPT-2运行机制，可视化解读GPT-3/4的内部机制。

第4章 基于ChatGPT的端到端语音聊天机器人项目实战，涵盖ChatGPT API开发、前后端构建（ReAct+FastAPI）及项目优化。

第5章 企业级ChatGPT开发的三大核心内部机制及案例实战，解析企业级开发核心，演示Notion问答对话AI案例。

第6章 ChatGPT插件的内部机制、源码及案例实战，详解插件工作原理、检索插件源码及全流程开发实战。

第7章 ChatGPT提示词开发实战，基于LangChain框架的提示词、思维链、链式提示词及模型评估开发。

第8章 思维链及ReAct解析与实战，剖析思维链推理、ReAct技术原理、框架源码及案例实战。

第9章 提示词本质解析及评估实战与源码解析，包含问答评估、代理评估源码解析及提示词本质探讨。

第10～11章 LangChain大模型框架的七大核心组件及案例解析（上、下），涵盖模型、词嵌入、提示词、内存、回调、数据连接、代理等核心组件及聊天机器人综合案例。

第12章 LangChain代理深入解析及源码解析，详解代理工作原理及AutoGPT源码解析。

第13章 AutoGPT源码解析及综合案例实战，剖析AutoGPT内部机制及其在LangChain代理、内存、PromptGenerator中的应用。

第14章 使用LangChain构建问答聊天机器人案例实战，涵盖GPT-4代码生成全流程及LangChain开发实战。

第15章 构建基于大模型的自治代理案例，详解自治代理原理、工具、示例及开源实现源码。

第16章 Llama 2模型与LangChain项目详解，包括模型部署（Replicate）、Hugging Face/LangChain实践、检索增强生成及自定义提示词RetrievalQA开发。

本书特色

●深入探索，全面剖析。
本书涵盖ChatGPT案例实战、LangChain项目实战及框架源码解析等多个层面的内容。每章都深入探讨相关技术与案例，并提供源码解析，使读者能够全面了解ChatGPT和LangChain等技术的内部机制与开发原理，为实际项目的应用提供有力指导。

●实战剖析，项目揭秘。
本书每章都提供具体的案例实战与项目解析，引导读者通过实际操作和代码理解技术细节和底层逻辑。通过理论结合实践的方式，使读者能够更好地运用所学知识，深入了解项目和框架的实现细节。

●前沿突破，技术驱动。
本书介绍了一系列突破性的技术，如ChatGPT、LangChain、Transformer、Prompt、Llama 2、AutoGPT、BabyAGI、CoT、ToT、ReAct、MRKL等。通过对这些技术的深入剖析，读者可以了解相关技术的发展和应用，并了解它们在实际项目中的具体应用场景和效果。

●源码解析，细致讲解。
本书对LangChain框架的关键技术进行了逐行源码剖析。读者可以深入理解源码实现和机制原理，从而更好地理解技术细节和底层逻辑，并将其应用于实际开发工作中。

本书还为读者提供了丰富的知识和实用的技能，帮助读者在ChatGPT和LangChain领域取得突破性的进展。无论是初学者还是有一定经验的开发者，都可以从本书中获得有价值的学习资源。

配套资源

为便于教与学，本书配有同步教学视频（约1000分钟）、源代码、数据集、教学课件、教学大纲、安装程序。

作者简介

王家林

美国斯坦福大学计算机专业毕业。曾在美国担任硅谷顶级机器学习和人工智能实验室主任、杰出AI工程师及首席机器学习工程师，专精于对话式人工智能（conversational AI）。现担任硅谷某知名对话机器人公司CTO，自2019年起专注于基于红队测试（red teaming）的责任型AI（responsible AI），并热衷于构建生成式AI/大语言模型教练系统（GenAI/LLM coaching systems）。在硅谷任职期间，曾领导多个GenAI/LLM解决方案项目，成功平衡企业业务需求下的大模型推理（reasoning）系统与幻觉（hallucinations）及偏见（biases）风险的最小化。

作为数据科学、机器学习、NLP、ChatGPT及大模型等领域25本书的主要作者，王家林对利用人工智能提供解决方案，以及通过机器学习驱动的NLP与LLM流程帮助组织实现数据驱动决策充满热情。他曾领导Apple、PayPal、Chase Bank、Faethm、LinkedIn等公司的11个重大NLP项目。

在NLP、对话式AI、大数据及基于AWS的无服务器（serverless）技术方面，拥有丰富的机器学习咨询经验。

段智华

中国电信股份有限公司上海分公司高级工程师。长期从事大模型与智能体技术领域，专注Agentic AI、Harness Agent等前沿方向研究。

新书购买链接

《企业级ChatGPT AI大模型应用开发实战（1000分钟视频）》
购买链接：https://item.jd.com/15389212.html