《Agent原理，架构与实践》
第8讲：多Agent编排
准备起一个新的系列《Agent原理，架构与实践》。目标不贪心：
1. 希望每篇文章有1-2个点能让大家有收获；
2. 希望不被骂；
本期第八讲，咱们开始。
上一讲完结，此时工具有了，规范skill也有了，sdd-site-agent已经能干活了。可任务一大，又写需求、又画原型、又出方案、又写代码，还是容易出问题。那么问题来了：什么时候该把这些角色拆给不同的Agent？
分享之前，先说下我的个人观点：多Agent编排是现在最被滥用的概念之一。很多团队一上来就拆七八个Agent，看起来很高级，结果又贵又乱。拆不拆，并不是看酷不酷，而是看...
【1】问题一：一个Agent，可能存在什么问题？
我们得先搞清楚单Agent的不足。
让sdd-site-agent一个Agent走完整条链路（需求→原型→架构→编码），随着任务变大，三个问题会逐步凸显。
问题一，上下文膨胀：需求讨论+原型细节+架构决策+代码文件，全挤在一个上下文窗口里。第3讲讲过，注意力被稀释；
问题二，职责混乱：代码写着写着，又来了一个需求的讨论，角色的知识会互相干扰；
问题三，失败传染：需求理解错了一步，后面全错。而且翻回去看，根本找不到是哪一步开始错的。
画外音：三个问题，指向同一个根因，同一个上下文窗口，装不下所有上下文。
【2】问题二：subagent，什么时候该拆？判断标准哪几个？
拆分的判断标准无非就三个，出现任意一个信号，才考虑拆：
信号一，上下文装不下：任务产生的中间内容，多到窗口装不下或开始上下文腐烂；
信号二，职责说不清：一个Agent的提示词里，塞了两个以上角色的职责；
信号三，失败会传染：一步错全链条错，且无法隔离和定位；
反过来，三个信号一个都没有，就不要轻易拆分。拆分多个subagent有可能带来哪些问题呢？
第一，贵。Anthropic实测过：多Agent系统的token消耗，大约是普通对话的15倍。因此，这个模式只在更高价值任务上才划算；
第二，信息损耗。子Agent看不到主Agent的对话历史。它需要的每一份上下文，都得由主Agent显式写进"任务书"传给它。传少了它容易做错，传多了token爆炸。
第三，协调成本。谁拆任务、谁验收、结果怎么汇总，全是新要设计的机制。
像不像公司拆部门？一个人干是全栈，十个人干就要配管理、配流程、配文档——人多了，产出未必多，但沟通成本一定高。拆Agent和拆部门，是同一个道理。
画外音：我带过几百人的技术团队，组织设计，组织管理，没想的那么简单，很多时候，小团队作战反而效率更高。
【3】问题三：subagent拆完，Agent之间怎么协作？
主流的模式是orchestrator-worker模式（编排者-工作者）。
主Agent（编排者）：
1. 拆任务——把大任务拆成子任务；
2. 派活——给每个子Agent写"任务书"（显式传递上下文）；
3. 汇总——收齐结果，组装成最终产出。
子Agent（工作者）：
1. 各自一个干净的上下文窗口；
2. 专注一个子任务，不受其他角色干扰；
3. 干完返回浓缩摘要，不返回全部过程。
Anthropic的多Agent研究系统里，每个子Agent可能用掉几万token做探索，但只把1000-2000个token的精华交回主Agent。
画外音：这是第3讲just-in-time思想的多Agent版：主Agent的上下文里只留结论，细节留在子Agent那里。
【4】我们的sdd-site-agent：拆不拆subagent？怎么拆？
回到我们的贯穿项目，三个信号过一遍：四步骤整体流程，可以不拆。需求→原型→架构→代码，步骤可预测，单Agent+三个skill按需加载，窗口够用。
什么时候拆？
编码阶段。
整个站点的代码生成，中间内容爆炸，符合信号1，可以拆出"编码子Agent"：
1. 任务书：架构方案+架构规范skill（显式传递）；
2. 上下文边界：不带需求讨论历史（不需要）；
3. 返回：代码文件清单+关键实现决策摘要。
注意这个决策的克制。不是上来就拆四个Agent——需求Agent、原型Agent、架构Agent、编码Agent。前三个角色每个的产出都不大，单Agent顺序做完全够用。只有编码这一步的中间内容会爆炸，所以只需要拆它。
【5】简单总结
希望今天这一讲，把多Agent编排的边界划清楚了：
1. 拆不拆，看三个信号：上下文装不装得下、职责说不说得清、失败会不会传染——一个都没有，就别拆；
2. 拆分的代价是：费用贵、信息损耗大、协调成本高；
3. 最常见的协作模式是orchestrator-worker模式：主Agent派活收摘要，子Agent干完留细节。
补充阅读：《Agent skill规范》
https://www.anthropic.com/research/multi-agent-research-system
工具有了，规范有了，编码子Agent也拆好了，Agent跑起来了。可它干得对不对？生成的需求文档、代码，没有标准答案，怎么验收？验收不了，又怎么迭代？
下一讲，咱们聊聊Agent的评估与迭代。
欢迎持续关注，让我们一起，一步一步，实现自己业务专属的mini-agent。
知其然，知其所以然。
思路比结论更重要。
===全文完==
PS：公众号只能贴静态图文，无法用js实时互动，在线版设计了课后习题与实操演练，欢迎阅读原文体验。
文章原文
