别急着堆 Subagent，先看能不能折回主 Agent Loop
这篇文章的真正贡献不是“单 Agent 永远赢”，而是把架构判断推进到三个更硬的问题：上下文归谁、信息何时加载、迁移是否可评测。
核心判断
Subagent 仍有价值，但很多企业把组织结构复制成了 Agent 架构。真正的替代方案是 Skills + Tool Search + Knowledge Base。
单个 Agent Loop 因上下文膨胀出现可度量的性能退化，或多个任务需要用可丢弃的新鲜上下文并行处理，或单个 Agent 难以选择合适工具、系统提示词存在冲突指令时，才使用 Subagent。
Use subagents when a single agent loop hits measurable performance degradation from context bloat, or multiple tasks need to be tackled in parallel with fresh context windows that can be discarded once the task is done, or a single agent struggles to select appropriate tools or there are conflicting instructions in the system prompt.
上下文隔离
并行探索、黑盒验证、可丢弃上下文，避免主上下文被一次性材料污染。
按部门拆分
每个团队一个专家 Agent，结果是 Subagent sprawl、Frankenprompt 和局部 eval。
能力包化
领域流程进 Skill，动作与权限进 Tool，参考资料进 Knowledge Base。
运行时模型
单 Loop 不是把所有 prompt 堆在一起，而是把“领域专家”变成按需加载的信息和工具。
主 Agent Loop
一个模型持续持有任务上下文。第一轮写下计划；每轮可以输出一批 tool calls；harness 并行执行并把原始结果回传；模型根据真实结果修订计划、继续调用、询问用户或输出答案。
Harness 边界
应用代码不再做领域路由和规划，只保留 turn/cost budget、write gate、工具执行、错误处理、验证器、记忆与上下文管理。
Skills
把原 specialist prompt 中的流程、规则和判断标准变成按需加载的文档。它没有独立上下文，不并发执行，只是让主模型知道“这类工作怎么做”。
Tools / MCP
承担动作、实时数据读取、固定 shape 返回、权限校验和前置条件检查。工具返回模型可理解的 plain refusal，而不是抛出只有程序员能懂的异常。
Tool Search
工具目录仍全量发送给 API，但用 defer_loading: true 阻止其进入初始上下文；模型需要时先搜索，再展开 3–5 个相关工具。
Knowledge Base
政策、规格、指标定义等偶尔需要的材料，通过 lookup/search 工具获取，或作为 Skill 内 reference file，而不是由代码预先拼进 prompt。
架构拆解
复杂性没有被消灭，只是从运行时 Agent 数量转移到描述质量、权限边界和评测治理。
| 部件 | 职责 | 交互关系 | 折回后位置 |
|---|---|---|---|
| Main model | 目标理解、计划、工具选择、综合 | 唯一长期持有完整任务上下文 | 主 Agent Loop |
| Harness | 批调用、预算、写权限、重试、上下文 | 包住模型，不替模型做领域决策 | 应用代码 |
| Skill | 领域流程、步骤、判断标准 | 按需加载进主上下文 | 替代 specialist prompt |
| Tool / MCP | 动作、实时数据、结构化结果、权限 | 返回原始紧凑事实 | 替代专家能力面 |
| Tool Search | 搜索并展开少量工具定义 | 维持大工具库的选择准确率 | 防上下文污染 |
| Knowledge base | 偶尔需要的参考资料 | 模型调用 lookup/search | 替代静态 RAG 拼接 |
| Subagent | 并行探索、黑盒验证、强隔离 | 作为 tool 或 handoff | 仅在确有价值时保留 |
单 Loop 的收益
- 计划者和执行者同一上下文，可随真实工具结果改计划
- 减少有损摘要和嵌套模型循环
- 并行的是工具批调用，不是必须并行的模型推理
- 品牌语气、规则和输出护栏更容易一致
单 Loop 的成本
- 主上下文更重，必须做分层加载与压缩
- Skill 描述、Tool schema、工具权限成为新的治理对象
- 弱模型可能路由和工具选择更不稳定
- 端到端 eval 必须覆盖所有生产链路
迁移算法
不要一刀切重构。一次只折一个 Subagent，用同一套端到端 eval 前后比较，并看任务翻转。
盘点
列出每个 subagent 的输入输出、上下文、调用频率、连续调用关系、owner、prompt、工具和 eval。
建基线
至少 10 个 golden examples，覆盖每条生产 agent chain 和每条不能违反的规则；每个任务跑多次。
分类
fold、merge、as-tool、keep。紧耦合且共享数据的先合并；需要隔离/并行的保留。
折叠
把 prompt 变 Skill，把 API 调用封装成按用户意图分组的 MCP tools，一次只动一个。
比较
看 task completion、latency、model calls、tokens、cost，更要看哪些任务从对变错或从错变对。
治理
小中央团队拥有 system prompt 和共享 eval；领域团队拥有 Skills、Tools 和局部 eval，发布前审查。
选型决策
判断标准不是流行架构，而是共享上下文带来增益，还是污染判断。
| 场景 | 推荐 | 原因 |
|---|---|---|
| 客服、报价、运营操作 | 单 Loop + Skills + Tools | 步骤强耦合，共享上下文减少交接错误 |
| 覆盖多部门的员工助手 | 主 Loop + Tool Search | 避免工具和 prompt 爆炸 |
| 深度研究 | 并行 Subagents | 独立路径探索，用完丢弃上下文 |
| 代码实现 + 审查 | Worker + 独立 Verifier | 验证者避免继承 worker 的确认偏差 |
| 高权限写操作 | 单 Loop + 工具内审批 | 权限必须在边界强制执行 |
| 旧模型 / 弱模型 | 显式编排 | 规划与工具选择能力不足时结构兜底 |
| 强隔离 / 合规 | 独立 Agent 或服务 | 隔离、审计、权限优先于共享上下文 |
压力测试
官方文章有产品导向，也有方法学价值。别把它读成无条件站队。
模型足够强
结论依赖新模型的规划、工具选择和自检能力；旧模型或低成本模型仍可能需要显式 router/planner。
共享上下文有益
适合强耦合业务链路；研究、审查、并行探索反而受益于隔离。Anthropic 自己的 deep research 曾采用多 Agent。
组织能治理
没有 DRI、eval 和审查，Subagent sprawl 只会变成 Skill sprawl + Tool sprawl。
任何单一架构都不如背后的原则重要：度量，一次改一件事，保留经受住验证的东西。
Any one architecture is less important than the principle behind it: measure, change one thing at a time, and keep what holds up.
对话推演
把决策压缩成一次工程讨论：什么时候折，什么时候留。
问题 1：多 Agent 图是在解决任务，还是在解决组织？
如果每个框对应一个团队，而不是对应上下文边界，架构已经变成了 org chart。
问题 2：上下文应该共享还是隔离？
共享能连接证据链，隔离能避免污染与膨胀。报价、客服适合共享；研究、验证适合隔离。
问题 3：权限放在哪里？
放在工具边界和审批门，而不是靠“专家 Agent 的人格”约束。
问题 4：怎么判断迁移成功？
同一套端到端 eval，多次运行，比较任务翻转，而不是只看平均分。
问题 5：新的复杂性在哪？
Skill 描述、Tool schema、知识检索、权限语义和 eval 所有权。
可执行清单
如果你现在有一套 Orchestrator + 多 Specialist，先从这九件事开始。