一个 Agent 包打天下，是多数自动化效率低的根源

很多团队把 Agent 用到一定深度后都会撞上同一堵墙，让一个 Agent 干所有活，效率不升反降。三个症状最典型，上下文窗口被研究、编码、审查三类任务轮番占满，前面聊过的细节被压缩丢失；长任务跑到一半进程崩溃，中间状态全部蒸发，从头再来；需要人拍板的决策点没法优雅地挂起，要么干等要么跳过。

这三个病的共同根源是单点，所有职责压在一个进程、一份上下文上，任何一环出问题都是全局问题。解法不是换一个更聪明的模型，是把「一个全能 Agent」拆成「多个专精 Agent 各做各的事」，再给它们一套协作机制。这篇以 Hermes 的两套互补机制为例，把多 Agent 编排的骨架拆开，一块跨进程的持久化看板，一种进程内的子代理委派，以及它们各自的适用边界。

一块不会消失的白板

先看 Kanban 持久化任务板。它的本质是一个 SQLite 数据库，所有 Agent 共享，每个任务是一行记录，每次交接是一条人人可读的日志。通俗讲就是一块共享白板，你把任务贴上去，不同的 Agent 走到白板前认领自己的卡片，做完把结果写在卡片背面，白板不会因为某个 Agent 下班而消失。进程退出、机器重启、第二天再来，卡片都在，之前干到哪一步也都在，这就是「持久化」三个字的全部价值。

任务在六列之间流转。Triage 是原始想法，一句话需求扔进来先落这里。Todo 是排队区，等依赖就位。Ready 是万事俱备，等调度器认领。In Progress 是某个 Agent 正在干，按角色分组一目了然。Blocked 是卡住了，可能是 Worker 在等人工输入，也可能是连续失败触发了熔断器，总之它诚实地喊停，而不是带着问题继续跑。Done 是完成，结果已写入，下游可读。调度器每六十秒做一轮巡检，看到 Ready 里有匹配的任务，就为对应的专精 Agent 派生一个独立进程去干活，干活的 Agent 还会定期心跳汇报进度，死没死、跑到哪，白板上看得清清楚楚。

两个设计细节值得 FDE 划重点。一是依赖引擎，任务可以挂父子关系，设计数据库结构、实现接口、编写测试串成依赖链，父任务不完成，子任务永远停在 Todo 不会被误启动，同一角色的多个任务按优先级串行执行，避免两个同名 Agent 抢资源，这是流水线的地基。二是工具集的硬隔离，干活的 Worker 只能看任务、交任务、报阻塞、写进度；调度的 Orchestrator 只能建任务、排依赖、解阻塞。这个分割不是建议，是系统强制的约束，Worker 不许分发，Orchestrator 不许动手，越权的口子从机制上焊死了。

多 Agent 协作的要义不是让谁更聪明，是让每个角色只看得见自己该看的东西。

九种阵型，常用的其实就三种

看板支持九种协作模式，名字听着唬人，常用的就三种。

最常用的是并行阵型，N 个同角色 Agent 分头做同类任务，比如五个角度的研究同时铺开，谁先做完谁先交。其次是流水线阵型，不同角色串成链，侦察员搜集、编辑加工、写手成稿，一张卡片流过整条线，出来一份每日简报，配合前面说的依赖引擎，上一站没交货下一站绝不空转。第三种最容易被低估，人工闸门模式，Worker 干到需要拍板的节点自动挂起，人在卡片上留一句话，它解除阻塞继续跑。架构选型这种必须人来定的决策，就该走这个模式，机器不越权，人也不被打扰，人和机器的边界在这一刻划得清清楚楚。

剩下几种按需取用，多 Agent 投票选优，三个研究员各查各的再由一个审查员挑最优答案。长期值守的知识库维护。在消息里点名某个 Agent 处理。一个角色批量耕耘几十个频道的农场模式，做矩阵账号运营时会爱上它。还有把一句话需求自动展开成完整规格的需求分解，需求池的自动化入口。阵型是拿来选的，不是拿来背的，遇到具体任务想清楚「这些活是并行、串行还是需要人把关」，阵型自然浮现。

给新同事发邮件的艺术

另一套机制是进程内的子代理委派，它和看板互补而非替代，解决的是「手头这件事需要帮手但不必建流水线」的场景。委派出去的每个子代理有三个特性，全新的对话，完全不知道父代理聊过什么；受限的工具箱，只开放你指定的那几样；独立的会话状态，中间过程不占父代理的上下文，干完只交回摘要。

这里藏着整套机制里最重要的一条铁律，子代理完全不知道你的对话。你要它干活，所有背景必须写进目标描述和上下文字段里，具体到文件名、错误信息、数据来源和根因猜测。举个对的比例，别写修复那个报错，要写修复接口文件第几行的类型错误，上下文里带上完整的报错信息、涉及的函数名、数据从哪来、初步判断的根因是什么。类比很简单，这是给一个全新同事发邮件，他不知道你之前做过什么，邮件写得越模糊，他跑偏得越远。老雷见过太多委派失败的案例，问题都不在模型，在那封「邮件」只写了一句话。

用好了收益巨大，官方归纳的五种委派模式，每种解决一类特定问题，挑三个最值钱的讲。

并行研究，三个子代理分头调研三个技术方向，每个独立搜索独立总结，彼此完全隔离，结论不会交叉污染，父代理最后汇总成连贯的简报。方案对比是它的变体，评估 A 方案和评估 B 方案的子代理互相不知道对方存在，各自给出独立判断，避免了「先入为主」这类人类评审的老毛病。代码审查是另一个妙用，子代理带着全新视角审视代码，你写代码时的所有假设它都不知道，恰恰因此它看得见你的盲区。

还有一条隐藏的省钱打法值得单独说，先采集后分析。机械化的数据收集交给便宜的执行环节连跑十几次调用，把结果攒齐，再喂给一次昂贵的干净推理做深度分析。便宜的干粗活，昂贵的干判断，顺序别搞反，反过来的成本曲线非常难看。叠加模型杠杆，主 Agent 用贵模型做规划和综合，子代理统一配便宜快速的模型干具体活，三路并行研究的组合拳打下来，总成本能压掉八成以上。

两种机制怎么选，别贪深度

最后给一张选型对照。生命周期，子代理委派是同步的，父任务里干完即走；看板是持久的，跨重启存活。人工参与，委派不可挂起，看板可以阻塞等人。跨 Agent 协作，委派只有父子关系，看板是核心能力，任意专精 Agent 都能认领。进程模型，一个跑在线程里，一个是独立系统进程。还有一个常被忽略的维度是可发现性，委派的子代理活在父任务的上下文里，外人看不见；看板有全局面板，所有任务谁在干、卡在哪，团队任何人打开就能查。一句话，短平快的并行帮手用委派，要追溯、要挂起、要多人可见的协作上看板。

调优只提醒一件事，控制嵌套深度。并发数配三、嵌套层数配三，理论上能炸出二十七个并发叶子代理，每多一层，开销和失控风险翻着倍地涨。层数保持默认的一层，真需要嵌套编排的复杂任务，交给看板的依赖引擎去管，它有保护机制，不会失控。深度这种参数，宁可保守，失控一次的排查成本够你保守一年。

编排的本质是分工加交接，机制只是把分工写成了代码。

收个尾。回头看那三个症状，上下文挤爆、状态蒸发、人机交接卡死，病根都是把所有职责压在一个 Agent 身上。拆职责、定边界、选对协作机制，这三步走完，多 Agent 系统才真正开始比单 Agent 快，而且快得有据可查，每一步交接都有记录，出了问题能定位到具体环节，这比快本身更接近「生产可用」四个字。

老雷的建议是从一个真实的流水线任务开始试，比如把内容生产拆成采集、加工、审查三站，跑通一条线，比读十篇编排理论都管用。