Anthropic《Building agents》深度解读：何时把 Subagent 折叠回主 Agent 循环

Anthropic《Building agents: When to fold subagents into your main agent loop》深度解读

原文：Building agents: When to fold subagents into your main agent loop
作者：Diane Sarkis
发布时间：2026-10-22
官方链接：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
本文目的：解释 Anthropic 为什么开始建议减少不必要的 Subagents，以及这对 Claude Code、Skills、Tools、Agent Teams 和实际软件开发工作流意味着什么。

一、这篇文章到底在说什么

这篇文章的核心不是：

“不要使用 Subagents。”

也不是：

“Markdown 文件永远比 Agent 更好。”

Anthropic 真正表达的是：

不要把每一种职责、每一个团队、每一种问题类型都机械地做成一个独立 Agent。

随着模型能力增强，很多过去需要通过：

• Router Agent
• Planner Agent
• Domain Agent
• Tester Agent
• Reviewer Agent
• Orchestrator Agent

来完成的工作，现在可以更简单地放回：

一个主 Agent
+
Skills
+
Tools / MCP
+
按需加载的上下文

也就是说，Anthropic 推荐的是：

优先构建一个能力足够强、上下文连续的主 Agent；只有在存在明确收益时，再增加 Subagent。

二、Anthropic 为什么开始反思“多 Agent”

以前设计 AI Agent 系统时，很容易形成这种结构：

User
│
▼
Router Agent
│
▼
Planner Agent
│
├── Frontend Agent
├── Backend Agent
├── Security Agent
├── Tester Agent
└── Reviewer Agent
│
▼
Orchestrator

看起来非常“专业”。

每个 Agent：

• 职责明确；
• Prompt 独立；
• Context 独立；
• Tools 独立。

但 Anthropic 在企业客户中观察到了一个现实问题：

系统往往不是因为 Agent 不够多而失败，而是因为 Agent 太多导致上下文交接、Prompt 管理和协调成本失控。

文章提到的典型问题包括：

1. Context 丢失

每个 Subagent 都有自己的上下文。

例如：

Planner
↓ summary
Developer
↓ summary
Tester
↓ summary
Reviewer

每次交接都需要把原始上下文压缩成摘要。

这相当于不断进行：

完整信息
↓
摘要
↓
二次摘要
↓
再次摘要

最终容易出现所谓的：

Telephone Game（传话游戏）

信息在不断转交过程中逐渐失真。

2. Subagent 膨胀

企业很容易按照组织架构创建 Agent。

例如：

Sales Agent
Marketing Agent
Finance Agent
Support Agent
CRM Agent
Order Agent
Shipping Agent
Refund Agent
…

最终可能出现几十甚至几百个 Subagent。

每个团队都维护：

自己的 Prompt
自己的 Tools
自己的 Evals
自己的规则

最后没有人真正负责整体 Agent 的端到端质量。

Anthropic 将这种现象与 Conway’s Law 联系起来：

系统架构开始复制公司的组织架构。

但组织架构并不一定是最好的 Agent 架构。

3. Frankenprompt

如果多个团队都往 System Prompt 中增加规则，就容易出现一个巨大的：

Frankenprompt

也就是：

多个团队拼出来的“弗兰肯斯坦 Prompt”。

例如：

营销团队：
必须积极推荐产品。

风控团队：
不要主动推荐产品。

客服团队：
尽量回答所有问题。

法务团队：
遇到不确定内容必须拒绝。

最后模型面对大量互相冲突的指令。

4. Latency 增加

一次调用可能变成：

Main
↓
Router
↓
Planner
↓
Domain Agent
↓
Reviewer
↓
Main

每一层都是一次独立模型调用。

Anthropic 提到，有客户在比较多 Agent Harness 和单 Agent Loop 后发现：

单 Agent Loop 的运行时间大约可以快 2 倍。

三、Anthropic 的核心建议：Single Agent Loop

Anthropic 推荐的目标架构是：

User
│
▼
Main Agent
│
┌────────┼────────┐
▼ ▼ ▼
Skills Tools Memory
│ │
└────────┼────────┘
▼
Main Agent
│
▼
Result

核心特点是：

一个模型
一个主要 Context Window
一个开放式 Tool Loop

主 Agent：

而不是：

Planner 负责计划
Developer 负责执行
Reviewer 负责检查

四、为什么“同一个 Agent 完成规划和执行”反而可能更好

这是文章非常重要的一个观点。

传统设计：

Planner
↓
生成 Plan
↓
Executor
↓
执行 Plan

问题在于：

Executor 在执行过程中可能发现：

原来的 Plan 不合理

但是 Planner 已经不在当前上下文里。

于是需要：

Executor
↓
告诉 Orchestrator
↓
重新调用 Planner
↓
Planner 修改 Plan
↓
返回 Executor

协调成本非常高。

Single Agent Loop 则是：

Main Agent
↓
制定 Plan
↓
执行
↓
发现新信息
↓
直接修改自己的 Plan
↓
继续执行

计划和执行处于同一个上下文里。

所以：

计划不是一次性的静态产物，而是 Agent 在执行过程中持续更新的工作状态。

五、Skills 为什么变得越来越重要

文章中一个非常关键的观点是：

很多过去放在 Domain Subagent Prompt 里的知识，现在更适合放进 Skill。

例如以前：

Security Agent

System Prompt:
– JWT 检查方式
– RBAC 检查方式
– SQL Injection 检查规则
– XSS 检查规则
– Secret 管理规则

现在可以变成：

Main Agent

Skills
└── security-review/
└── SKILL.md

当任务涉及安全审查时：

Main Agent
↓
发现安全任务
↓
加载 security-review Skill
↓
执行

如果没有安全任务：

Skill 不加载

这就是：

Progressive Disclosure（渐进式披露）

六、Progressive Disclosure 是什么

传统 Prompt：

System Prompt
├── 前端规范
├── 后端规范
├── 安全规范
├── 测试规范
├── Git 规范
├── API 规范
├── 数据库规范
└── 部署规范

所有内容一开始全部进入上下文。

问题是：

Context 很大
+
很多内容当前任务根本用不到

Progressive Disclosure 则是：

Main Agent
│
├── Skill 描述（很短）
├── Skill 描述（很短）
├── Skill 描述（很短）
└── Skill 描述（很短）

模型先看到：

skill name
description

只有真正需要时才加载：

完整 SKILL.md

因此可以同时做到：

能力很多
+
初始 Context 很小

Anthropic 还提到，Claude Code 通过类似的按需披露机制，针对更先进模型将系统 Prompt 大幅缩减。

七、Skill、Tool、Knowledge、Agent 应该分别放什么

可以用下面这个判断方式。

Skill

适合放：

How to do the work

也就是：

• 工作步骤；
• 判断规则；
• 最佳实践；
• 团队规范；
• 操作流程；
• 专业方法论。

例如：

code-review/SKILL.md
debugging/SKILL.md
vue-best-practices/SKILL.md
security-review/SKILL.md

Tool / MCP

适合：

Do something

例如：

查询数据库
调用 GitHub
读取 Notion
调用浏览器
执行 Playwright
读取 CI
创建 Issue

Tool 更强调：

动作
+
实时数据
+
固定输入输出

Knowledge Base

适合：

Reference information

例如：

公司政策
API 文档
产品说明
业务字典
指标定义

Agent 不需要一直加载。

需要的时候：

Search
↓
Retrieve
↓
Use

Subagent

适合：

需要独立 Context

例如：

• 独立 Research；
• 黑盒 Verification；
• 大量代码搜索；
• 并行独立任务；
• 工具或系统 Prompt 存在明显冲突。

八、什么时候仍然应该使用 Subagent

Anthropic 并没有否定 Subagents。

文章明确给出了三个非常重要的判断条件。

场景 1：Context Pollution

假设：

Main Agent

需要读取：

100 个日志文件

但最后只需要：

根因
+
3 条证据

如果全部日志都进入 Main Context：

Context 爆炸

更好的方式：

Main Agent
↓
Log Analysis Subagent
↓
读取大量日志
↓
返回 300 tokens 摘要

Subagent Context 用完即可丢弃。

这就是：

Context Isolation。

场景 2：真正可以并行

例如：

调查 Vue 性能问题
调查 Node API 问题
调查数据库慢查询

三件事情互相独立。

可以：

Main
│
┌────────┼────────┐
▼ ▼ ▼
Agent A Agent B Agent C

最后 Main 汇总。

这种情况下 Multi-Agent 很有价值。

场景 3：工具或指令冲突

例如 Main Agent 同时有：

40 个 MCP Tools

并且覆盖：

GitHub
Notion
CRM
Database
Cloud
Slack
Payments

模型开始：

选错 Tool

此时可以把不同领域隔离：

CRM Agent
GitHub Agent
Finance Agent

不过 Anthropic 同时建议：

在拆 Agent 前，先考虑 Tool Search / Deferred Loading。

也就是：

不要一次加载 40 个工具

先让模型动态查找 Tool。

九、为什么“Planner / Developer / Tester / Reviewer”这种拆分经常有问题

这是文章对软件开发 Agent 非常有意义的一点。

看起来合理：

Planner
↓
Developer
↓
Tester
↓
Reviewer

但这些任务实际上共享大量 Context。

例如：

Developer 知道：

为什么这里用了这种实现

Tester 不知道。

Tester 发现：

某个测试失败

然后需要把信息传给 Developer。

Developer 修复后：

Reviewer 又需要重新理解整个 Feature

于是产生大量：

handoff

Anthropic 在另一篇关于 Multi-Agent 的文章中称这种方式为：

Problem-centric decomposition

按照“工作类型”拆 Agent。

而更推荐的是：

Context-centric decomposition

按照“上下文边界”拆。

十、Context-centric decomposition

错误拆分：

Feature A

Planner
Developer
Tester
Reviewer

更合理：

Feature A
└── Agent A
├── Design
├── Implement
└── Test

Feature B：

Feature B
└── Agent B
├── Design
├── Implement
└── Test

如果 Feature A 和 Feature B 独立：

Lead
│
┌───────┴───────┐
▼ ▼
Agent A Agent B
Feature A Feature B

这样上下文不会来回传递。

十一、为什么 Verification Agent 是特殊例外

Verification 是最适合独立 Agent 的场景之一。

原因：

Verifier 不需要知道：

你为什么这么写

它只需要知道：

Requirements
+
Artifact
+
Acceptance Criteria

然后判断：

PASS / FAIL

例如：

Developer
↓
Implementation
↓
Verifier
↓
Run Test
↓
PASS / FAIL

这种模式叫：

Generator-Verifier

它具有非常干净的 Context Boundary。

所以：

code-reviewer
security-reviewer
black-box tester

往往仍然适合作为独立 Subagent。

十二、这篇文章对 Claude Code 的实际意义

放到 Claude Code 中，可以理解为：

不推荐

~/.claude/agents/

planner.md
developer.md
frontend.md
backend.md
tester.md
debugger.md
reviewer.md
architect.md
security.md
writer.md
git-master.md
…

然后每个任务：

Main
↓
Planner
↓
Developer
↓
Tester
↓
Reviewer

更推荐

Claude Code Main Agent
│
├── CLAUDE.md
│
├── Skills
│ ├── debugging
│ ├── testing
│ ├── vue-best-practices
│ ├── security
│ └── refactoring
│
├── Tools / MCP
│
├── Subagents
│ └── 少量真正需要 Context Isolation 的 Agent
│
└── Agent Teams
└── 复杂且真正可并行时才使用

十三、对我们刚才配置的三个 Agent 的重新评估

我们之前配置了：

code-reviewer
test-engineer
debugger

结合这篇 Anthropic 新文章，更合理的判断如下。

十四、Code Reviewer 为什么值得继续保留

代码审查最大的价值之一就是：

Fresh Eyes

如果 Main Agent：

自己设计
自己开发
自己测试
自己 Review

它容易沿用自己原来的假设。

而独立 Reviewer：

Requirements
+
Git Diff
+
Tests

重新判断：

实现到底正确吗？

非常符合 Anthropic 所说的：

Black-box verification

因此推荐保留：

~/.claude/agents/code-reviewer.md

十五、Test Engineer 为什么更适合 Skill

假设主 Agent刚刚：

实现 Feature

它已经知道：

业务需求
代码结构
边界条件
修改原因

此时让另一个 Tester Agent：

重新读取所有代码
重新理解需求
重新理解 Feature

会增加重复 Context。

更合理：

Main Agent
↓
加载 testing Skill
↓
设计测试
↓
运行 Test
↓
修复

只有：

真正需要黑盒验收

时才启动独立 Test Agent。

十六、Debugger 为什么通常更适合 Skill

Debug 本质上非常依赖：

之前发生了什么

比如 Main Agent 已经知道：

刚修改了哪些文件
刚运行了什么测试
出现了什么 Error
尝试过哪些方案

如果此时切到 Debugger Agent：

需要重新把这些 Context 传过去

容易损失信息。

因此通常：

Main Agent
+
diagnosing-bugs Skill

更好。

只有当 Debug 任务本身：

需要读取非常大量日志

或者：

需要独立调查

才适合 Subagent。

十七、推荐的新 Claude Code 架构

结合 Anthropic 这篇文章，推荐：

Claude Code Main Agent
│
├── Global CLAUDE.md
│
│ └── 开发原则 / 安全边界 / 编排原则
│
├── Skills
│ ├── debugging
│ ├── testing
│ ├── refactoring
│ ├── security-review
│ ├── frontend-design
│ └── framework-best-practices
│
├── Tools / MCP
│
├── Knowledge
│
├── Subagents
│ └── code-reviewer
│
└── Agent Teams
└── 真正独立、可并行的大任务

十八、Agent Teams 应该什么时候启动

不要因为：

任务复杂

就一定启动 Team。

应该检查：

能否真正独立并行？

例如：

适合 Team

Monorepo

Agent A → Admin
Agent B → H5
Agent C → Backend

接口已经明确，各模块独立。

不适合 Team

登录 Feature

Planner
↓
Developer
↓
Tester
↓
Reviewer

它们高度共享 Context。

这种更适合：

Main Agent
+
Skills
+
最后独立 Reviewer

十九、Anthropic 推荐的 Multi-Agent 判断公式

可以简化成：

是否存在真实 Context 问题？
│
├── 否
│ ↓
│ Single Agent
│
└── 是
│
▼
能否按 Context 独立拆分？
│
┌────┴────┐
│ │
否 是
│ │
Single Agent Subagent
+ Skills / Team

还要继续问：

是否真正需要并行？

如果：

No

那么通常：

Subagent > Agent Team

如果：

Yes

才考虑：

Agent Team

二十、对 Agent 开发的几个重要结论

结论 1

更多 Agent：

≠

更强系统。

结论 2

Agent 应该按照：

Context Boundary

拆分。

而不是：

Job Title

拆分。

结论 3

专业知识优先放：

Skill

而不是：

Specialist Agent

结论 4

实时能力放：

Tool / MCP

结论 5

大量参考资料放：

Knowledge / Search

结论 6

真正需要：

独立 Context
+
并行
+
特殊权限

时，再创建 Subagent。

二十一、对你当前配置的具体建议

你现在已经配置：

~/.claude/agents/
├── code-reviewer.md
├── test-engineer.md
└── debugger.md

不需要马上删除。

建议先调整使用策略：

code-reviewer
→ 默认允许独立 Subagent

test-engineer
→ 优先让 Main Agent + testing Skill
→ 黑盒验收时才调用 Agent

debugger
→ 优先 Main Agent + diagnosing-bugs Skill
→ 大量日志 / 独立 RCA 时才调用 Agent

你的全局 CLAUDE.md 中继续保留：

Prefer the simplest execution strategy.

以及：

Use Agent Teams only when substantial parallelism
or independent context provides clear benefits.

这与 Anthropic 的最新方向是一致的。

二十二、一个更合理的 Coding Agent Loop

推荐：

User Requirement
│
▼
Main Agent
│
├── Analyze
│
├── Plan
│
├── Implement
│
├── Load Testing Skill
│
├── Run Tests
│
├── Load Debug Skill if needed
│
└── Fix
│
▼
Code Reviewer
Independent
│
┌─────┴─────┐
▼ ▼
PASS FAIL
│
▼
Main Agent
│
└── Fix → Verify

只有任务天然独立时：

Main Agent / Team Lead
│
┌──────┼──────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└──────┼──────┘
▼
Integrate

二十三、文章最值得记住的一句话

如果把这篇文章浓缩成一句工程原则：

不要因为某个能力“听起来像一个岗位”，就为它创建一个 Agent；只有当独立上下文本身能带来明确收益时，才应该创建 Subagent。

进一步可以总结为：

Instructions → Skill
Actions → Tool
Knowledge → Retrieval
Isolation → Subagent
Parallelism → Agent Team

这是一套非常实用的 Agent 架构判断方式。

二十四、最终总结

Anthropic 的方向已经从：

“为每种能力创建一个 Agent”

逐渐转向：

“让一个强大的 Main Agent
通过 Progressive Disclosure
动态获得 Skills、Tools 和 Context”

Subagents 仍然非常重要。

但它们应该解决的是：

Context Isolation
Parallelism
Specialized Tool / Instruction Boundaries
Black-box Verification

而不是：

组织架构映射
岗位模拟
为了 Multi-Agent 而 Multi-Agent

对于 Claude Code 开发体系，一个比较合理的最终形态是：

Main Agent
+
CLAUDE.md
+
Skills
+
Tools / MCP
+
少量 Verification Subagents
+
按需 Agent Teams

这比维护十几个甚至几十个固定 Agent 更简单、更便宜，也更符合 Anthropic 当前推荐的 Agent 架构方向。

参考资料

推荐行动项

如果你正在搭建 Claude Code Agent 开发体系，建议按下面顺序优化：

1. 保持一个强 Main Agent
2. 精简 CLAUDE.md
3. 把专业流程沉淀为 Skills
4. 把实时动作放进 Tools / MCP
5. 保留少量真正独立的 Verification Agent
6. Agent Teams 只用于天然可并行任务
7. 用 Evals 比较 Single-Agent 与 Multi-Agent 的真实效果
8. 不因为“理论上更专业”而增加 Agent

最终目标不是：

Agent 越多越好

而是：

用最少的架构复杂度
获得最高的任务完成质量。