路由不是分发，边界不是装饰：一套多 Agent 系统应如何被组织
谈多 Agent，很容易陷入一种过度兴奋的叙事：仿佛只要把 research、writer、coding、ops 这些角色接进同一条工作流，系统就会自然变得更聪明，复杂任务也会自动被拆解、推进并交付。但真正把多 Agent 用进日常工作之后，问题很快会变得具体而且不那么浪漫：谁来决定要不要拆？拆给谁？拆到什么程度？多个 Agent 之间如果出现冲突，谁负责收口？哪些动作可以自动执行，哪些必须停在人工确认之前？
这些问题决定了一件事：多 Agent 系统真正难的，不是“能不能调动更多模型”，而是“如何在分工之后仍然保证系统可控”。如果这个问题没有被认真回答，多 Agent 很容易退化成一种昂贵而嘈杂的转述系统；看起来大家都在忙，实际上责任在扩散，错误在放大，返工在增加。
所以，这篇文章不打算讨论“多 Agent 很厉害”。更值得写的，是另外三个问题：系统何时应该拆、如何拆、拆完之后如何保持可控。 在我自己的工作流里，Slinna 负责主协调，research、writer、coding、ops 作为 specialist 参与执行。真正让我越来越确信的一点是：多 Agent 的价值，不在于多几个脑子，而在于少一些混乱。
一、多 Agent 解决的，不是“更聪明”，而是“更可控的分工”
对单 Agent 系统来说，最常见的问题往往是能力覆盖不足：它需要同时理解需求、检索信息、产出方案、执行动作、校验结果，还要在必要时给出面向人的解释。理论上，一个足够强的模型也许都能做；但工程上，这种“都能做”往往意味着另外几件事：职责混在一起、上下文堆在一起、判断标准冲突在一起、失败原因也糊在一起。
多 Agent 的真正价值，不在于凭空制造更强的智能，而在于把复杂任务拆成一组职责更清晰、上下文更聚焦、权限更受限、结果更可审计的工作单元。research 负责事实与外部信息，writer 负责结构与表达，coding 负责实现与验证，ops 负责运行状态、风险与治理；主协调者负责决定是否拆分、如何路由、何时收口。这种设计带来的提升，不是“每个 agent 都更聪明”，而是系统更容易判断谁该做什么、谁不该做什么、哪一步出了问题、该在哪里回退。
换句话说，多 Agent 最重要的收益不是智力叠加，而是复杂性管理。
这也是为什么我越来越不相信“只要上下文足够长，一个超级单 Agent 就能替代多 Agent”的说法。对低复杂度任务，这个判断常常成立；但一旦任务同时涉及不同工具、不同风险等级、不同交付标准，以及长链路状态传递，单 Agent 的问题就不再是“能不能做”，而是“出了错之后还能不能定位、限权、止损和复盘”。多 Agent 不是为了证明系统更先进，而是为了把错误限制在局部，把责任落到节点。
二、什么时候应该拆，什么时候不该拆
这可能是多 Agent 设计里最容易被浪漫化、也最需要冷静判断的问题。不是任务一复杂就应该拆，也不是看到几个 specialist 就应该想办法把每件事都分发出去。拆分不是默认值，而是一种结构性选择。只有在它确实降低耦合、降低认知负担、提高审计性时，拆分才有意义。
我更倾向用下面几个标准来判断“什么时候值得拆”：
第一，任务是否天然分层，且每层输入输出可以定义清楚。如果 research 的产出能以结构化方式交给 writer，ops 的诊断结果能直接成为 coding 的输入，这种任务适合拆。相反，如果每一步都高度依赖前一步的细碎语境、边做边改目标、频繁返工，拆分只会制造 handoff 成本。
第二，不同子任务是否需要完全不同的工具集或权限。检索、写作、代码修改、运行排障，本来就不应该由同一个高权限单元无差别完成。按 agent 切开权限边界，比在一个大 agent 里不断切换角色更安全，也更容易审计。
第三，单 Agent 是否已经开始承受明显的上下文拥堵。当一个系统既要记住目标，又要处理细节，又要追踪状态，还要兼顾表达质量与风险控制时，上下文越长，不一定越稳。很多时候，过度共享上下文并不是协作，而是在共享污染。
第四，任务是否需要可追责、可回放的过程记录。如果你需要知道是谁检索了什么、谁提出了哪个判断、谁批准了哪一步动作，多 Agent 的边界天然更适合形成审计链。
第五，失败是否需要被局部隔离。某个 specialist 的失败，不应该污染整条链路；能在局部失败、局部降级、局部回退，是多 Agent 真正有价值的场景。
反过来，下面这些情况通常不值得拆：任务很短、目标很明确、单步即可完成；子任务高度耦合，根本定义不出稳定接口；多个角色都“能做一点”，但没有明确 owner；或者更直白一点，路由的成本已经高于执行本身的成本。多 Agent 不是默认答案。很多时候，单 Agent 才是更快、更稳、更诚实的方案。
三、如何拆：拆的不是步骤，而是职责、判断权、交付物与风险
多 Agent 设计里另一个常见误区，是按流程机械切段：先 research，再 writer，再 coding，再 ops，或者反过来按工具切分。这样的系统表面上很整齐，实际上很容易走向两个坏结果：要么 handoff 过多，链路被拉得很长；要么多个 agent 同时对同一个模糊目标“共同负责”，最终无人真正对结果负责。
真正有效的拆法，应该优先考虑四件事。
第一，按职责拆。谁负责事实，谁负责表达，谁负责实现，谁负责运行与风险判断，谁负责最终收口。职责边界的意义，不是让角色名字更好看，而是让问题出现时能快速定位责任。
第二，按判断权拆。不是每个 agent 都有资格下结论，也不是每个 agent 都有权发起下一步动作。research 可以提供事实与判断依据，但不应默认替系统做最终策略决策；writer 可以重构表达，但不应擅自改写事实前提；ops 可以提出降级与风险建议，但高风险动作仍应由主协调者或人工确认后执行。
第三，按交付物拆。一个成熟的多 Agent 系统，不应该让 specialist 输出“长篇感受”，而应该输出可校验、可复用的工件：研究摘要、对比清单、补丁、测试结果、运行诊断、对外说明草稿。拆分的价值，不只在过程分工，更在交付物清晰。
第四，按风险拆。只读任务、内部可回滚任务、高风险外部动作，必须被放在不同的控制路径里。高风险动作如果没有硬边界，再强的编排也会在一次误路由后变成事故放大器。
所以，好的拆分并不会让系统显得更热闹；它会让系统里的责任更清晰、交接更短、审计更容易、止损更明确。好的拆分，结果应是责任更清晰，而不是沟通更热闹。
四、路由的本质，不是发任务，而是匹配合适的判断机制
很多人一提 router，会先想到“分类”和“分发”。这当然没错，但不够。一个成熟的路由器，绝不只是把任务从 A 丢给 B；它真正做的是：根据任务类型、风险等级、工具需求、输出形式和终止条件，决定谁应该处理、谁只能提供支持、谁不能碰这件事，以及什么时候必须停下来请求确认。
所以我越来越倾向一句比较重的话：路由最重要的工作，不是分配任务，而是阻止错误的人做错误的事。
从工程角度看，路由层至少应该做到几件事。
首先，先按任务类型路由，而不是先按 agent 名字路由。先判断这是研究、写作、编码还是运维问题，再决定交给谁；否则角色会先于问题，导致系统为了使用某个 specialist 而扭曲任务。
其次，一个任务只能有一个 owner。其他 agent 可以协作，但不能“共同负责”。没有 owner，最后就一定会出现重复产出、责任模糊、结论冲突，而所有这些问题都会在最终交付时压到用户面前。
再次，路由最好基于结构化任务单，而不是原始聊天全文。在真实系统里，specialist 最好接收的是一张清晰的 task card：
- goal
- constraints
- inputs
- expected_output
- deadline
这比把一整段历史对话直接转发过去稳定得多。对 specialist 来说，长上下文并不天然意味着高质量；很多时候，它意味着更多噪音、更多误读、更多未经筛选的假设。
最后，路由必须有停止条件。最多重路由几次、最多跨 agent 几跳、什么时候强制收口、什么时候交还给人，这些规则不写清楚，多 Agent 很快就会进入 ping-pong：这个觉得像 research，那个觉得像 writer，再转 coding，又回来 ops。系统不是不会工作，而是不知道该在哪里停。
五、边界为什么比能力更重要
如果说路由决定了一件事该交给谁，那么边界决定的，是这个“谁”到底能做什么、能看到什么、能改什么，以及在什么地方必须停下。没有边界，多 Agent 不是协作，而是相互污染。
边界至少有四层。
第一层是职责边界。research 不负责最终定稿，writer 不负责技术根因，coding 不负责外部发送，ops 不负责改写业务目标。成熟系统的标志，不是每个 agent 都很能干，而是每个 agent 都知道自己不该做什么。
第二层是信息边界。不是所有上下文都应该被广播给所有 agent。多 Agent 的价值之一，恰恰是通过最小必要上下文分发，降低认知负担、降低泄露面、降低幻觉继承。共享一切上下文，看起来是在协同，实际上常常是在共享污染。
第三层是权限边界。research 可以看外部信息，但不应改仓库；coding 可以改代码，但不应直接对外发送；ops 可以做诊断，但不应默认拥有所有高风险变更权。权限边界必须先于能力边界；否则“我能做”很快会变成“我顺手就做了”。
第四层是确认与回退边界。只读任务可以自动执行，可回滚内部动作可以低门槛确认，高风险外部动作必须停在人机边界之前。系统还要知道：某个 specialist 失败后，是重试、降级、换路由，还是直接请求人工。没有回退策略，编排系统只会把失败放大。
这也是为什么我认同一个看起来不够性感、但非常接近现实的判断：边界确实会让系统慢一点，但也正因为如此，它才真正有资格被上线。
六、一个最小可行的多 Agent 工作流
比抽象原则更能说明问题的，往往是一个足够小、又足够真的工作流。
假设用户说：“排查线上接口超时，并给我一段发给团队的说明。”
如果没有组织，多 Agent 很容易失控：research 去查资料，ops 去看日志，coding 开始猜是不是连接池问题，writer 先写了一段对外说明，最后每个人都做了一点，没人对最终结果负责。
更合理的组织方式是这样的：
- Slinna 先做主域判断：这件事的核心不是写说明，而是排障，所以 owner 是 ops。
- ops 输出结构化结果：当前症状、初步根因、证据、风险等级、是否需要代码变更。
- 只有在 ops 判断需要实现修复时，才拉 coding：coding 输出补丁、测试结果、回滚方式。
- 只有在事实框架稳定后，才拉 writer：writer 基于已经收敛的事实生成对团队说明，而不是反过来替技术判断做包装。
- Slinna 最终收口：整合诊断、修复、说明，检查是否有高风险动作需要人工确认，再交付给用户。
这个流程看起来并不花哨，但它把多 Agent 最关键的几件事都落实了：有 owner、有 handoff、有边界、有停止条件，也有最终收口。多 Agent 不是 everybody jump in，而是让每一段协作都发生在合适的位置。
七、真正的难点常常不在能力，而在治理
当一个多 Agent 系统走出 demo，开始承担真实任务时，难题通常不再是“某个 agent 会不会做”，而是“整条链路是否稳定、可追踪、可复盘、可止损”。
很多失败，不是因为模型不够强，而是因为治理太弱。
比如任务被派给了错误 specialist；比如上游在交接时丢掉了关键约束，下游在错误前提上高质量执行；比如多个 specialist 并发工作，却产出相互冲突的结论；比如某个外部工具超时，整条链路没有降级路径；再比如失败重试时没有幂等设计，导致系统重复发送消息、重复创建动作。所有这些问题，都不是“智能不够”，而是典型的系统工程问题。
这也是为什么一套可用的多 Agent 系统，必须认真面对治理问题：
- 任务要有统一 ID，便于跨 agent 追踪
- 路由决策要留日志，不只是留输出
- token、时间、工具调用次数都要有预算
- 超时要能传播取消信号，不能无限等待
- 失败要有降级路径，而不是全链路卡死
- 高风险动作必须停在人工确认之前
- 审批和外部写操作要可审计、可幂等
- specialist 的权限与工作区要隔离
这些事情写出来并不酷，但它们才真正决定一套多 Agent 系统能不能上线。能力决定上限，治理决定下限。
八、多 Agent 不是神话，而是一种组织设计
我现在越来越愿意把多 Agent 理解为一种组织设计问题，而不是一种能力神话。
它不是把一个超级助手复制成几个名字不同的分身，也不是让系统“显得像一个团队”就算成功。真正成熟的多 Agent 设计，应该回答的是：什么时候由主协调者直接处理，什么时候交给 specialist，什么信息必须共享，什么信息必须隔离，谁有权判断，谁只能提供输入，哪个节点负责收口，哪个节点必须把高风险动作交还给人。
如果这些问题没有回答清楚，多 Agent 只会把单点混乱，升级成系统性混乱。相反，如果这些问题被认真组织起来，多 Agent 才会开始表现出它真正的价值：降低耦合，减少认知负担，提高可审计性，并把复杂任务从“一个大脑硬扛一切”变成“一个协调者管理多个可控模块”。
所以我给多 Agent 的判断，最终会落在一句并不炫目的话上：
路由不是分发，边界不是装饰。
前者决定任务如何进入正确路径，后者决定系统如何在复杂性增长之后仍然保持秩序。一个系统如果只能把任务分出去，却不能把责任收回来，那它不是编排系统，只是排队系统。真正可用的多 Agent，不以热闹为荣，而以清晰、稳定和可控为目标。