都说要用”更强的 Agent”，我却搭了一套分工系统

用 Agent 做交付 · 机制系列 01

过去几个月，我把个人和团队的大量日常工作交给了 AI Agent。被问得最多的问题是：为什么不等着用一个更强的模型、一个更全能的 Agent，一步到位？

我的答案可能和多数人预期相反：我从来没有在找”一个更强的 Agent”，我在搭的是一套分工系统。 这套系统的核心是两个角色的组合：

• 一个常驻型 Agent（我用的框架叫 Hermes，下文直接这么称呼），有持久记忆、长期在线、挂着定时任务；
• 一个专家型编码 Agent（Codex），按需调用，干完活就退场，交付物走代码审查。

这个组合用了几个月之后，我可以先给结论：决定交付质量的不是单个 Agent 的智商，而是角色边界的清晰度。 下面讲为什么。

一个全能 Agent，为什么是伪命题

问题出在上下文带宽。

一个 Agent 要同时做好两件事——“记得所有事”和”专心干一件事”——在工程上是矛盾的。常驻型工作要求宽上下文：它要知道上周做过什么、客户的偏好、哪个通道登录态快过期。专家型工作要求窄而深的上下文：改一段代码时，最理想的输入就是这份代码、这个 bug——多出来的任何背景信息都是噪音。

让一个上下文又宽又深的 Agent 同时干两类活，等于让一个人既当前台总管又当封闭开发的工程师。 每次切换，前一件事的上下文就会污染后一件事的判断。这在人类组织里早有答案——分岗。Agent 团队同理。

Hermes 解决”连续性”：跨会话记忆让它在周一接的需求周五还能续上；定时任务让例行工作不需要任何人记得去触发。Codex 解决”专业深度”：每次任务开独立 worktree，产出是 diff，可以用审查代码的标准验收；干完即走，不留上下文负担。

两者的接口是任务与回执，不是共享上下文。管家把需求写成明确的工单派出去，专家交回带证据的交付物，管家负责验收和归档。

说一个被推翻过的选择，供参考。早期我试过”一个 Agent 修到底”：所有代码任务也让常驻 Agent 直接写。结果是它的记忆里很快堆满了某个脚本第 37 行为什么这么写之类的细节，而真正需要长期记住的客户偏好、例行节奏反而被挤占。上下文是最贵的资源，必须按角色预算分配——这是那次失败教我的。

一次真实的分工实录

用一个真实发生的事说明这套分工怎么运转（细节做了脱敏）。

某天下午我发现一个例行任务连续三天没有任何产出——定时任务在跑，但悄悄失败了，没有任何告警。这是常驻型 Agent 的典型失职场景，也是它最该主动发现的事。

处理过程是这样的：

1. 管家侧先定位：查定时任务的运行记录，发现是它依赖的浏览器调试通道挂了——登录态还在，进程没了。这类”环境层”故障不需要写代码，Hermes 自己拉起通道、验证、恢复，20 分钟闭环。
2. 但发现了更深的问题：排查中发现同一个功能存在三份分叉的脚本——正式版、某次应急改出来的现场版、封装版，行为不一致。这属于工程债，需要代码层面的收敛。
3. 派单给专家：Hermes 把”三份脚本合并、现场改动回流进正式版、删除临时版”写成工单，含验收标准（合并后跑通全链路、临时文件清零），派给 Codex。
4. 专家交付：Codex 在独立分支完成合并，diff 清晰可审，验收通过后合并，并顺手把”临时脚本 48 小时内必须回流”写进了规范。

全程我不在场。晚上我看到的是一条汇报：故障原因、修复动作、沉淀出的新规矩。

三条原则，换别的框架也成立

回头看，这套”Hermes + Codex”组合的本质是三条原则，它们不依赖任何具体工具：

1. 按上下文特征分岗，而不是按能力分岗。“能不能干”不重要，“该不该让它一直记着”才重要。需要长期记忆的活给常驻角色，需要深度专注的活给按需角色。
2. **接口用任务与回执，不用共享上下文。**角色之间传递的是带验收标准的工单和带证据的交付物，而不是”你去看一下我之前的聊天记录”。后者是多 Agent 系统最大的隐性成本。
3. **验收标准写在派单里，不写在人的脑子里。**工单里没有验收标准的任务，一定会返工；有验收标准的任务，专家 Agent 的完成质量可以稳定复现。

我的团队现在有多个常驻 Agent 分管不同业务条线，但结构不变：每个都是”管家 + 按需专家”的组合单元。下一篇讲这套系统的另外两道闸——为什么所有工程动作必须走 GitHub 协作流和令牌机制。

（本文全部案例来自本人多 Agent 系统的真实运行记录，细节已脱敏。观点仅供参考。）