从 ReAct 到长期 Agent Runtime：Hermes 的五个关键设计

2.1 “自进化”首先不是在线训练#

Hermes 官方将自己描述为带有内置学习闭环的自改进 Agent，但这里的“学习”不应该被误解为运行时梯度下降，或者模型不断修改自身权重。GitHub README

Hermes 更接近一种运行时经验外化：

1
模型参数没有改变
2
但模型下次获得的事实、历史证据和操作流程更加完整

它增长的不是底层模型的通用智力上限，而是系统对特定用户、环境和工作流的熟悉程度。

这类学习通常比在线训练更适合个人 Agent 和生产 Agent，原因很直接：

• 成本更低，不需要准备训练数据与重新部署模型。
• 结果可见，经验会落在文件或数据库中。
• 内容可编辑，错误记忆和过时流程可以被修正。
• 变更可审计，可以设置人工审批门。
• 特定知识可以按需加载，不必永久占据上下文。

2.2 Memory、Skill 与 Session 的三层分工#

Hermes 没有把所有经验塞进一个“大记忆库”，而是拆成三种不同资产：

可以把它们压缩成一句话：

Memory 记录是什么，Skill 记录怎么做，Session 记录当时发生了什么。

Hermes 的内置 Memory 主要由 MEMORY.md 与 USER.md 组成。前者保存环境事实、约定和已学到的信息，后者保存用户偏好、沟通方式和长期期待。它们被刻意设计得相对紧凑，避免 Memory 变成第二份聊天记录。Persistent Memory

Skill 则是按需加载的程序性知识文档。官方文档将其描述为 Agent 的 procedural memory，并采用渐进式披露：Agent 先看到 Skill 索引，只有任务真正相关时才加载完整 SKILL.md，必要时再读取附属参考文件。Skills System

Session Store 保存的是更完整的证据链。session_search 使用 SQLite FTS5 在历史会话中做全文检索，返回数据库里的真实消息片段，而不是临时让另一个 LLM 编一段“历史总结”。Sessions

这三者很像一间工程团队的知识系统：

1
Memory  = 墙上的长期约定
2
Skill   = 经过整理的操作手册
3
Session = 可回放的事故档案

2.3 闭环学习是如何发生的#

Hermes 的学习闭环可以表示为：

图 2：Hermes 自进化闭环，将真实任务经验沉淀为 Memory 与 Skill

图示说明：这是一条概念闭环。后台复盘与写入审批是否启用取决于配置；启用审批时，系统会先暂存变更提案，批准后才持久化，Skill 通常按任务需要检索和加载。

系统在一轮任务完成后，可以通过后台复盘识别两类高价值信息：

1. 值得长期保留的事实，例如“生产环境只能通过只读账号查询数据库”。
2. 值得复用的流程，例如“退款工作流卡住时，应先检查 Temporal Activity，再检查 Outbox 事务与 MQ 消费位点”。

Agent 也可以在前台主动使用 skill_manage 创建、编辑、Patch 或删除 Skill。官方 Prompt 会鼓励它在以下情况沉淀流程：

• 找到一套值得重复执行的多步骤方法。
• 经历错误路径后发现真正有效的方案。
• 用户纠正了它的做法。

其中 patch 比整份覆盖更有代表性。它允许 Skill 像代码一样局部演化：

1
第一次：记录可用流程
2
第二次：补充异常分支
3
第三次：吸收用户纠正
4
第四次：删除过时步骤

Skill 因而不只是一个静态 Prompt，而是一份可以持续维护的操作手册。

2.4 自进化为什么必须带审批门#

自动学习听起来迷人，但错误经验同样会被自动放大。

假设 Agent 在一次偶然事件中得出错误结论：

1
“看到消费延迟时，重启所有消费者通常能解决问题。”

如果这条经验直接写入 Skill，下一次 Agent 可能更加稳定、更加自信地做错事。所谓自进化，很容易滑向“自动给错误镀上一层永久漆”。

Hermes 因此为 Memory 与 Skill 写入提供可选审批机制。开启 write_approval 后，变更不会立即进入后续会话，而是先被暂存，用户可以查看 Diff、批准或拒绝。Skills System

1
memory:
2
  write_approval: true
3

4
skills:
5
  write_approval: true

这带来一个重要转变：

Agent 学习不再是不可见的黑盒变化，而是一次可以检查、拒绝和回滚的状态提交。

从生产架构角度看，这比“Agent 会自己学习”更重要。学习能力决定上限，治理能力决定它是否敢被放进真实系统。

2.5 自进化还需要遗忘#

长期积累并不天然等于长期进步。Skill 越来越多后，会出现重复、冲突、失效和无人使用的问题。

Hermes 当前还提供 Curator 机制，用于管理 Agent 创建的 Skill 生命周期，例如将长期未使用的 Skill 标记为 stale 或归档，同时允许固定关键 Skill，防止自动清理。Curator

这揭示了另一个容易被忽略的设计原则：

一个会学习的系统，也必须会整理和遗忘，否则记忆最终会变成上下文沼泽。

3.1 一次 RPC 为什么不够#

最简单的 Agent-to-Agent 调用通常长这样：

1
ask_agent(question) -> answer

它适合一次性问答，却无法自然处理持续任务：

• 第二次调用是否知道第一次谈了什么？
• 对端 Agent 是否能继续使用自己的记忆、工具和凭证？
• 调用方是否每次都要重新发送完整背景？
• 长任务如何查询、取消、订阅或接收异步结果？

当远程 Agent 只是一个无状态函数时，所谓多 Agent 协作往往只是“把工具名称换成了 Agent 名称”。

Hermes 的 A2A 设计更接近两个独立运行时之间的持续协作。

3.2 contextId 是跨 Agent 关系的会话锚点#

Hermes 的 A2A 插件支持双向通信：Hermes 可以作为客户端调用其他兼容 A2A 的 Agent，也可以作为服务端接收外部 Agent 的任务。出站 a2a Toolset 默认关闭，需要按平台启用；入站服务还需要启用 A2A Gateway Platform。出站工具 a2a_call 支持传入 context_id，a2a_history 则可以重新读取已经持久化的 A2A 对话。A2A

图 3：会话级 A2A，通过 contextId 延续跨 Agent 多轮协作

图示说明：为了突出会话连续性，图中将客户端适配层与本地历史持久化层独立画出；Hermes 工具接口中的实际参数名是 context_id，历史由调用侧持久化，不是远端 Agent 直接写入。

这里真正重要的不是多了一个参数，而是状态归属发生了变化：

1
主 Agent 保留主任务上下文
2
远程 Agent 保留自己的运行时状态
3
contextId 只负责把双方围绕同一任务的对话串起来

因此，主 Agent 不必复制远程 Agent 的所有工具、凭证与历史。远程 Agent 也不是被压扁成一个 HTTP 函数，它仍然拥有自己的完整工作环境。

3.3 Hermes 同时支持出站与入站#

Hermes 的出站 A2A 工具包括：

入站方向上，Hermes 暴露 Agent Card、JSON-RPC 2.0 方法、流式返回与长任务通知能力。外部任务会被注入真实的 Gateway Session，并继续使用该 Profile 自己的 Memory、Skill 和 Tools。对话按照 A2A contextId 组织，因此外部 Peer 可以进行连续多轮交流。A2A

这使 Hermes 可以同时扮演两种角色：

1
A2A Client：发现并调用外部专业 Agent
2
A2A Server：把自己暴露为可发现、可持续对话的 Agent 服务

3.4 会话级 A2A 带来的四个价值#

第一，连续性。

一个复杂任务可以自然地分多轮推进：

1
第一轮：分析现象
2
第二轮：补充日志
3
第三轮：验证假设
4
第四轮：确认修复

不需要每次重新铺设背景。

第二，权限边界。

生产 SRE Agent 可以持有生产环境的只读凭证，代码 Agent 可以持有代码仓库权限，主 Agent 只负责编排。权限不必集中到一个“超级 Agent”身上。

第三，跨框架协作。

A2A 解决的是进程、机器、团队和框架之间的通信。对端可以是另一套 Hermes，也可以是基于其他 A2A SDK 构建的 Agent。

第四，服务化。

一个专业 Agent 可以通过 Agent Card 描述能力，被其他 Agent 发现并调用。它开始具备类似微服务的边界，但通信对象不再只是函数，而是带状态、工具和任务生命周期的智能运行时。

3.5 A2A、Delegation 与 Bot Mode 不要混为一谈#

Hermes 同时提供临时子 Agent、长期 Bot 和 A2A。三者都与“多 Agent”有关，但解决的是不同问题：

可以用三句话区分：

1
Delegation 解决“临时找一个助手”
2
Bot Mode 解决“长期养一个同事”
3
A2A 解决“如何与外部组织通信”

官方文档也明确建议：同一机器内的临时并行优先使用 Delegation，而 A2A 更适合跨进程、机器和框架边界。Subagent Delegation

3.6 A2A 的安全边界#

远程 Agent 的输出本质上仍然是不可信输入。Hermes 的 A2A 安全模型包括本地默认绑定、Peer 凭证、速率限制、远程输入过滤、出站凭证形态脱敏、审计日志和单个 contextId 的往返上限。A2A

这说明 A2A 协议只解决通信与任务状态，不自动保证对端结论可信。真正的生产系统仍然需要：

• 身份认证与最小权限授权。
• 对高风险工具设置审批。
• 对外部结果进行事实校验。
• 为自动往返设置上限，防止两个 Agent 无限“礼貌互聊”。
• 为长任务提供超时、取消、查询和通知机制。

4.1 为什么一次性子 Agent 无法承担长期岗位#

临时子 Agent 很适合处理独立任务，但它很难成为一个真正长期存在的角色：

• 今天的 Research Agent 和明天的是不是同一个角色？
• 它有没有自己的 Memory 和 Skill？
• 它能否固定使用特定模型和工具集？
• 它能否拥有独立的凭证策略与长期会话？
• 它能否运行自己的定时任务？

Hermes 的答案不是再发明一种新的 Bot 对象，而是把已有 Profile 提升为长期角色。

官方文档对 Bot 的定义非常直接：Bot 就是 Hermes Profile。每个 Profile 在自己的目录下拥有隔离配置、Memory、Skills 与 Chat History，Bot Mode 只是将这种底层状态域呈现为可管理的长期 Agent 名册。凭证策略可以按 Profile 管理，但当前默认创建流程可能共享 OAuth / Token Pool，不能把“独立 Profile”直接理解为“凭证天然完全隔离”。Bot Mode

图 4：Bot Mode 中每个长期角色拥有隔离的 Profile 与状态资产

这带来一句非常关键的设计判断：

长期 Agent 的最小单位不是一次模型调用，也不是一段角色 Prompt，而是一个拥有独立状态边界的 Profile。

4.2 Canonical Bot Chat：长期关系需要稳定的会话锚点#

每个 Bot 创建时都会拥有一个固定、持久化的 Canonical Bot Chat。它不是普通的临时会话，而是这个角色持续工作的主要入口。Bot Mode

为什么需要这个锚点？

因为长期身份必须和长期状态绑定：

1
固定角色
2
  + 独立 Profile
3
  + 固定会话锚点
4
  + 可检索历史
5
  = 可持续的 Agent 关系

Hermes 甚至会避免在 Canonical Bot Chat 中通过 /new 直接切断关系，而是倾向使用上下文压缩来刷新工作集，同时保留同一条长期会话链。

这与普通聊天机器人有本质区别。普通机器人强调“每次回复像同一个人”，Bot Mode 强调“它真的是同一个状态主体”。

4.3 message_agent：带身份的异步任务交接#

在 Bot Mode 管理的 Canonical Bot Chat 中，Bot 可以通过 message_agent 给另一个 Bot 发送消息；普通会话和群聊成员 Session 不会获得这个工具：

1
message_agent(
2
    target="researcher",
3
    message="请检查 A2A 1.0 中 contextId 的会话语义，并给出官方依据。"
4
)

消息会进入目标 Bot 的 Canonical Chat，目标 Bot 使用自己的模型、Memory、Skill、工具和权限处理。发送方先得到接收确认，回复随后以后台完成通知的形式返回。官方将这种交付描述为 fire-and-forget。Bot Mode

这一点很有工程味：

1
函数调用强调同步返回值
2
Bot 消息强调任务归属与异步交付

它更接近团队中的工作交接，而不是在一个函数栈里嵌套调用。

4.4 Group Chat：共享的是房间，不是大脑#

Bot 群聊最容易产生一个误解：所有 Bot 是否共用同一份上下文？

Hermes 的设计并不是把多个 Agent 塞进同一条模型历史，而是让每个成员保留自己的 Group: <name> Session。房间共享消息投影，但每个 Bot 的推理仍然发生在自己的 Profile 与会话中。Bot Mode

图 5：Group Chat 共享房间消息，但每个 Bot 保留独立会话上下文

图示说明：隔离的是 Bot 内部的身份、Memory、权限和推理上下文；一旦某个 Bot 把结论发回房间，该消息就会成为共享投影的一部分。

因此：

1
共享的是协作空间
2
隔离的是身份、记忆、权限和推理上下文

Hermes 还通过轮次和消息数量上限约束群聊，避免多个 Bot 在无人干预时形成一场永不散会的数字圆桌。

4.5 Bot Mode 是组织模型，A2A 是通信协议#

Bot Mode 回答的是：

我的长期 Agent 团队由哪些岗位组成？每个岗位拥有什么状态和职责？

A2A 回答的是：

两个独立 Agent 运行时如何跨边界发现能力、交换任务并延续会话？

两者可以组合，但不能互相替代。一个团队可以在同一套 Hermes 中使用 Bot Mode 管理，也可以通过 A2A 调用外部公司的专业 Agent。前者像组织架构，后者像跨组织通信协议。

5.1 Agent Loop 中隐藏的 Token 黑洞#

很多 Agent 任务表面上需要“智能”，实际过程却包含大量机械步骤：

1
搜索第 1 个文件 -> 读取 -> 判断
2
搜索第 2 个文件 -> 读取 -> 判断
3
搜索第 3 个文件 -> 读取 -> 判断
4
……

如果每一步都回到 LLM：

• 模型调用轮数不断增加。
• 大量中间结果涌入上下文。
• Token 成本快速上升。
• 循环与条件分支变得不够稳定。
• 模型的注意力被日志、文件和重复状态稀释。

这就像让架构师亲自数仓库里的每一颗螺丝，既昂贵，也浪费真正需要判断力的脑力。

5.2 Hermes 的异构执行分工#

execute_code 的核心思想不是“Agent 会写 Python”，而是明确区分两类工作：

1
LLM：理解目标、选择策略、编写控制逻辑、解释最终结果
2
Python：循环、过滤、聚合、Join、条件判断、批量工具调用

官方实现中，Agent 生成 Python 脚本，Hermes 同时生成 hermes_tools.py 工具 Stub。脚本运行在子进程中，通过 RPC 通道把工具调用发回 Hermes。只有脚本写入标准输出的内容返回 LLM，中间工具结果不会逐条进入模型上下文。Code Execution

图 6：execute_code 通过子进程与 RPC 批量调用 Hermes 工具；子进程隔离本身不等同于完整安全沙箱

这里有三个特别值得注意的设计点。

5.3 工具调用仍然回到 Hermes 权限系统#

Python 脚本并不是绕过 Hermes 直接拿走所有凭证。它通过 RPC 调用 Hermes 已注册的工具，因此工具注册、权限控制、执行环境和错误包装仍然由 Hermes 负责。

这避免了两种极端：

1
极端一：所有控制流都由 LLM 一步步完成
2
极端二：把全部系统权限直接交给任意生成脚本

execute_code 位于二者之间：程序拥有控制流能力，但工具能力仍然经过 Agent Runtime 管理。

5.4 中间结果不再污染主上下文#

假设任务需要检查 100 个服务配置。传统 Agent 可能读取 100 份结果，再把大部分内容重新发送给模型。

execute_code 可以在脚本中完成筛选：

1
from hermes_tools import search_files, read_file
2
import json
3

4
matches = search_files(
5
    "timeout",
6
    path="services/",
7
    file_glob="*.yaml",
8
    limit=100,
9
)
10

11
abnormal = []
12

13
for match in matches.get("matches", []):
14
    content = read_file(match["path"])["content"]
15
    if "timeout: 0" in content or "timeout: -1" in content:
16
        abnormal.append(match["path"])
17

18
print(json.dumps({
19
    "checked": len(matches.get("matches", [])),
20
    "abnormal_files": abnormal,
21
}, ensure_ascii=False, indent=2))

模型最终只需要看到：

1
{
2
  "checked": 100,
3
  "abnormal_files": [
4
    "services/refund-api.yaml",
5
    "services/payment-worker.yaml"
6
  ]
7
}

它不必吞下 100 份配置文件，注意力从数据搬运回到了根因判断。

5.5 execute_code 最适合哪些任务#

适合：

• 对大量文件、页面或记录循环处理。
• 按条件筛选异常项。
• 对多个工具结果做聚合或 Join。
• 批量修改文件并统计结果。
• 执行测试后只提取失败摘要。
• 多阶段检索后只保留高价值证据。

不一定适合：

• 只执行一个简单 Shell 命令。
• 需要长时间交互的终端程序。
• 主要难点是语义判断，而不是数据处理。
• 高风险写操作尚未建立权限与审批边界。

可以将它与 Terminal 简单区分：

5.6 程序执行仍然需要沙箱#

官方实现会给子进程精简环境，默认剥离 API Key、Token 与凭证，脚本主要通过 RPC 使用工具，并支持超时、进程组终止和不同后端传输方式。Code Execution

但工程上仍然应该继续限制：

• 可调用的 Toolset。
• 文件系统读写范围。
• 网络访问范围。
• CPU、内存和执行时长。
• 高风险操作的人工批准。

execute_code 提升的是执行效率，不是取消安全边界的许可证。

6.1 长期 Agent 不可能把一切都塞进窗口#

一个持续运行的 Agent 会不断产生：

• 用户消息与模型回答。
• 工具调用参数和原始结果。
• 项目上下文文件。
• Memory 与用户档案。
• Skill 索引和 Skill 正文。
• 多 Agent 协作轨迹。
• 压缩摘要和恢复线索。

即使上下文窗口越来越大，把全部历史永久塞进去仍然不是好设计。问题不仅是 Token 成本，还有“lost in the middle”、噪声增加、Prompt Cache 失效和重要约束被淹没。

Hermes 的核心思路可以概括为：

上下文只承载当前任务所需的高价值工作集，完整历史交给外部存储，并在需要时检索回来。

6.2 三层 Prompt 装配#

Hermes 将系统 Prompt 按顺序拆成三层：Prompt Assembly

1. stable：身份、工具与模型指导、Skills 提示、环境与平台提示。
2. context：调用方传入的系统信息与项目 Context Files。
3. volatile：Memory 快照、用户档案、外部 Memory Provider 信息、时间和会话元数据。

图 7：Stable、Context 与 Volatile 三层 Prompt 装配模型

这种拆分不是单纯为了代码整洁，它直接影响：

• 指令优先级是否清晰。
• Prompt 前缀是否稳定。
• Provider 侧缓存能否复用。
• Memory 语义是否容易理解。
• 临时上下文是否会污染长期状态。

Hermes 会尽量保持系统 Prompt 前缀稳定。Memory 与用户档案以快照形式进入 Prompt，写入持久化文件不意味着在当前模型调用链中随意重写既有历史。通常会在明确的 Prompt 重建点，例如新会话或上下文压缩后，重新装配快照。这个取舍牺牲了一部分“每秒刷新”的即时感，换来更好的缓存命中和会话一致性。Prompt Assembly

6.3 热、温、冷三级信息模型#

可以用操作系统的工作集模型理解 Hermes：

图 8：热、温、冷三级信息模型与按需上下文恢复

图示说明：热、温、冷是本文用于解释工作集的分析模型。Hermes 官方明确持久化的是 Session 元数据与消息，并通过 SQLite FTS5 检索；附件、文件与业务事件是否完整归档取决于接入平台和存储配置。

这个模型揭示了一个关键区别：

1
Persistence 负责“不能丢”
2
Context 负责“现在需要看什么”

Hermes 保存完整 Session，不代表每轮都必须把完整 Session 重新发给模型。

6.4 Session Search：把历史变成可检索档案#

session_search 支持搜索、围绕某条消息滚动、读取完整会话和浏览近期会话。搜索由 SQLite FTS5 完成，可以使用关键词、短语、布尔表达式和前缀查询。Sessions

例如用户说：

我们上周讨论过退款幂等，你把当时的结论找出来。

Agent 不需要要求用户重新解释，也不必把全部历史放进当前窗口。它可以先搜索相关 Session，再只恢复命中位置附近的消息。

这比“把所有历史摘要成一段长期记忆”更可靠，因为：

• 原始消息仍然存在。
• 可以看到当时的上下文和证据。
• 需要更多细节时可以继续向前或向后滚动。
• 不会把一次错误总结当成唯一历史版本。

Memory 像便签，Session Search 像档案室。便签负责快速提醒，档案室负责在争议出现时提供原始记录。

6.5 Skill 的渐进式加载#

Skill 解决的是另一类上下文浪费：系统可能拥有几十甚至几百份 SOP，但当前任务只需要其中一份。

Hermes 使用渐进式披露：

1
Level 0：只暴露 Skill 名称、描述和分类
2
Level 1：任务匹配后加载完整 SKILL.md
3
Level 2：需要时再读取 Skill 的特定参考文件

这让 Skill 更像按需换入的代码页，而不是永久钉在系统 Prompt 上的长文档。Skills System

6.6 双层压缩：压缩工作集，而不是销毁历史#

Hermes 当前采用双层上下文压缩思路：Agent 内部的 Context Engine 根据真实 Token 使用量决定是否压缩，Gateway 侧则在消息进入 Agent 前提供 Session Hygiene 安全兜底。默认 Context Engine 可以被插件替换。Context Compression

图 9：Gateway 与 Context Engine 组成双层上下文压缩机制

理想的压缩结果不是简单删除最早消息，而是保留：

1
关键初始约束
2
+ 中间历史的结构化摘要
3
+ 最近的原始消息尾部
4
+ 可通过 Session Search 恢复的持久化历史

因此，压缩的本质是调整当前工作集，而不是焚毁档案。

6.7 上下文管理的三个否定句#

Hermes 的上下文哲学可以用三句话概括：

1
不是所有历史都应该成为当前上下文。
2
不是所有知识都应该永久常驻。
3
不是所有工具结果都值得让模型阅读。

这也是 session_search、Skill 渐进式加载、execute_code 和压缩系统能够彼此咬合的原因。它们都在做同一件事：把稀缺的模型注意力留给真正需要判断的内容。

8.1 场景#

用户向 Main Bot 提问：

昨晚有一批退款工作流一直卡在处理中，帮我定位根因，并给出可验证的修复方案。

系统中存在三个角色：

• Main Bot：理解需求、拆解任务、汇总证据。
• Code Bot：拥有代码仓库读取权限，熟悉 Temporal、Outbox 与退款幂等实现。
• Prod SRE Agent：运行在生产运维网络，通过 A2A 暴露只读诊断能力。

8.2 调用链#

图 10：退款工作流故障排查的端到端多 Agent 调用链

图示说明：图中的工具调用是概念伪代码。实际首次 a2a_call 通常不自造 contextId，而是接收服务端返回的 opaque contextId，后续调用再通过 context_id 复用。

8.3 每个机制承担了什么#

上下文管理

Main Bot 在开始时只加载相关项目事实、退款排障 Skill 和历史命中片段，而不是把整个项目所有会话塞进上下文。

Bot Mode

Code Bot 是长期存在的代码岗位。它拥有独立 Memory、Skill、模型配置与仓库权限，不是每次临时生成的陌生子 Agent。

会话级 A2A

Main Bot 首次调用生产 SRE Agent 后保存服务端返回的 opaque contextId，后续通过 context_id 复用它来维持事故会话。修复后的第二轮排查可以沿用同一上下文，不必重新解释事故时间线。

execute_code

Code Bot 用脚本批量搜索 Workflow、Activity、Outbox 与消费者代码。SRE Agent 用脚本聚合日志、工作流状态、消息记录和数据库指标。只有筛选后的调用链与异常时间线进入模型上下文。

自进化闭环

假设本次最终发现：消费者先写入幂等标记，随后退款状态更新失败且 offset 未提交；重试消息又被幂等检查短路，导致工作流一直停在处理中。任务结束后，Background Review 可以提出两项变更：

1
Memory：该消费者会先写幂等标记，再更新退款状态，并使用手动提交位点
2
Skill：在退款卡住排查流程中新增“核对状态更新、幂等标记与 offset 提交顺序”步骤

用户审核后，新的经验进入后续任务。

下一次遇到类似事故，Hermes 不必重新摸索整条路径。这就是闭环学习真正产生价值的地方：任务不只被完成，还改变了系统下一次完成任务的起点。

9.1 最适合的场景#

Hermes 特别适合这些任务：

• 长期个人助手与团队助手。
• 代码库维护、审查与自动化。
• 研究、信息搜集与证据汇总。
• 运维诊断与事件响应。
• 跨系统、跨工具的复杂自动化。
• 多个专业 Agent 的长期协作。
• 需要持续积累 SOP 的重复性知识工作。

这些任务的共同特征是：过程复杂、状态持续、经验可复用，但每次任务又需要一定判断力。

9.2 自进化不等于模型能力无限增长#

Memory 与 Skill 能让 Agent 更熟悉环境，但不能无限突破底层模型的推理能力。错误理解仍然可能发生，Skill 也可能把局部经验错误推广到更大范围。

因此，关键流程需要：

• 明确适用条件。
• 保存证据与反例。
• 对高风险变更启用审批。
• 定期清理过时 Skill。

9.3 A2A 不等于可信计算#

A2A 让 Agent 能发现、调用并延续会话，但不会自动证明对端身份、数据真实性或结论正确性。

远程 Agent 的结果应被视为带来源的外部证据，而不是天然真理。尤其涉及生产、资金、医疗或法律时，系统仍需要严格授权、审计和人工复核。

9.4 Bot 越多不一定越强#

长期 Bot 会带来新的组织成本：

• 模型与基础设施费用。
• 权限和凭证管理。
• 角色职责重叠。
• 多 Agent 消息冲突。
• 会话和 Skill 的重复建设。

Bot Mode 的价值在于清晰分工，而不是把每个小功能都包装成一个人格化 Bot。一个团队最危险的状态不是人少，而是所有人都在开会。

9.5 execute_code 不能替代安全沙箱#

程序化工具调用可以显著降低 Token 成本，但也提高了批量操作能力。一次错误循环可能在几秒内放大为大量错误写入。

因此，批量修改、生产环境操作和外部系统写入仍应配置：

• 最小权限 Toolset。
• 容器或远程沙箱。
• 资源与时间限制。
• 幂等设计。
• 审批和回滚机制。

9.6 Agent 不应替代确定性业务状态机#

支付、退款、库存、账务这类核心流程需要一致性、重试、幂等和审计。它们应该由数据库事务、状态机或工作流引擎负责。

更合理的职责分工是：

1
Temporal / 状态机 / 数据库
2
负责确定性执行、重试、一致性和审计
3

4
Hermes Agent
5
负责理解意图、制定计划、诊断异常、调用受控工具和沉淀经验

Hermes 可以成为聪明的调度员、研究员和诊断者，但不应该成为没有确定性约束的资金账本。