什么时候拆 subagent：上下文装不下、职责说不清、失败会传染
上一讲结束，我们留了个尾巴：一个 Agent 带着三个规范 skill 已经能干活了。可任务一大，让它一个人又写需求、又画原型、又出方案、又写代码——它还是容易乱。什么时候该把这些角色拆给不同的 Agent 呢？拆错了又会怎么样？
这一讲先把话说在前面：多 Agent 编排是现在最被滥用的概念之一。很多团队一上来就拆七八个 Agent，看起来很高级，结果又贵又乱。拆不拆，先看出没出现信号，而不是看酷不酷。
问题一：一个 Agent 扛所有，会出什么问题？
先搞清楚”扛所有”到底哪里难受。让 sdd-site-agent 一个 Agent 走完整条链路（需求→原型→架构→编码），三个毛病会随着任务变大一起爆发：
上下文膨胀 需求讨论 + 原型细节 + 架构决策 + 代码文件
全挤在一个窗口里——第 3 讲讲过的，注意力被稀释
职责混乱 写着代码，上下文里还漂着需求文档的措辞讨论，
角色的知识互相干扰
失败传染 需求理解错了一步，后面全错——而且翻回去看，
根本找不到是哪一步开始错的三个毛病其实指向同一个根因：一个上下文窗口，装不下多个角色的完整世界。
问题二：什么时候该拆？信号是哪几个？
拆分的判断信号就三个，出现任意一个，才考虑拆：
信号一：上下文装不下
任务产生的中间内容，多到窗口装不下或开始腐烂
信号二：职责说不清
一个 Agent 的提示词里塞了两个以上角色的职责
信号三：失败会传染
一步错全链条错，且无法隔离和定位反过来，三个信号一个都没有，就别拆。拆分的代价非常实在，三笔账都得认：
- 贵——Anthropic 实测过：多 Agent 系统的 token 消耗，大约是普通对话的15 倍。官方原话是——这个模式只在高价值任务上才划算；
- 信息损耗——子 Agent看不到主 Agent 的对话历史。它需要的每一份上下文，都得由主 Agent 显式写进”任务书”传给它。传少了它干错，传多了预算爆炸；
- 协调成本——谁拆任务、谁验收、结果怎么汇总，全是新要设计的机制。
像不像公司拆部门？一个人干是全栈，十个人干就要配管理、配流程、配文档——人多了，产出未必多，但沟通成本一定涨。拆 Agent 和拆部门，是同一个道理。（沈剑管过几百人的技术团队，组织拆分这件事，倍儿熟。）
问题三：拆完，怎么协作？
真要拆，主流的模式是 orchestrator-worker 模式（编排者-工作者）：
主 Agent（编排者）
拆任务：把大任务拆成子任务
派活：给每个子 Agent 写"任务书"（显式传递上下文）
汇总：收齐结果，组装成最终产出
子 Agent（工作者）
各自一个干净的上下文窗口
专注一个子任务，不受其他角色干扰
干完返回浓缩摘要，不返回全部过程最关键的机制在最后一句：子 Agent 返回的是浓缩摘要，而不是全部过程。Anthropic 的多 Agent 研究系统里，每个子 Agent 可能用掉几万 token 做探索，但只把 1000-2000 token 的精华交回主 Agent。发现没有？这正是第 3 讲 just-in-time 思想的多 Agent 版——主 Agent 的上下文里只留指针（摘要），细节留在子 Agent 那里。
这套机制的效果有硬数据撑着：Anthropic 内部研究评测里，多 Agent 系统（强模型做主、快模型做子）比单 Agent 高出 90.2%。而且在研究类任务上，token 消耗量解释了 80% 的性能差异。说白了，多 Agent 的本质，就是给任务配上超出单窗口上限的 token 总量。
所以多 Agent 不是”人多力量大”，是”窗户多了屋子亮”。每个子 Agent 一扇干净的窗户，阳光才照得进来。
落到 sdd-site-agent：拆不拆？怎么拆？
回到贯穿项目，用三个信号过一遍：
v1（当前）：不拆
需求→原型→架构→代码，步骤可预测，
单 Agent + 三个 skill 按需加载，窗口够用
什么时候拆：编码阶段
整个站点的代码生成，中间内容爆炸——信号一命中
拆出「编码子 Agent」：
任务书：架构方案 + 架构规范 skill（显式传递）
上下文边界：不带需求讨论历史（不需要）
返回：代码文件清单 + 关键实现决策摘要注意这个决策的克制。不是上来就拆四个 Agent——需求 Agent、原型 Agent、架构 Agent、编码 Agent。前三个角色每个的产出都不大，单 Agent 顺序做完全够用。只有编码这一步的中间内容会爆炸，所以只拆它。信号驱动，而不是对称驱动。
实操演练（约 25 分钟）
两步必做，做完本讲的核心手感就到手了。
检验一下
①sdd-site-agent 拆分决策文档：什么任务拆、拆什么、任务书传什么、返回什么摘要——第 9 讲的评估对象就是它；
②一份”子 Agent 任务书”模板：任务描述/规范引用/输入材料/返回格式四段式——以后拆任何子 Agent 都套这个模板。
你如果想深挖一层，读这两篇：Anthropic · Building effective agents（orchestrator-workers 模式）和 Anthropic · 多 Agent 研究系统（90.2%、15 倍、80% 的出处）
第二篇是一个完整的多 Agent 系统实战复盘，怎么拆任务、怎么传上下文、踩了哪些坑，全是第一线细节。
但还有一个没解决的问题：Agent 拆好了、跑起来了——可它干得对不对？生成的需求文档、代码，没有标准答案，怎么验收？验收不了，又怎么迭代？——第 9 讲，我们讲评估与迭代。
知其然，知其所以然。思路比结论更重要。