Anthropic Subagent：多智能体时代的架构革命

当单智能体撞上天花板

如果你最近用过 Claude Code 或者 Deep Research,可能会有个感觉:这玩意儿好像比之前聪明了不少。

不是错觉。Anthropic 在 2025 年悄悄上线了一个多智能体架构,内部测试显示性能提升超过 90%。但代价也很明显——Token 消耗是单智能体的 15 倍。

这就引出了一个有意思的问题:为什么要搞多智能体?单个 AI 不够用吗?

答案藏在一个老生常谈但确实致命的问题里:上下文窗口。

上下文:AI 智能体的阿喀琉斯之踵

我们先回到第一性原理:AI 模型本质上是一个函数,输入是上下文(context),输出是响应。上下文包括对话历史、工具调用结果、外部文档、中间推理……随着任务复杂度上升,上下文会越来越长。

问题来了:

1. 上下文腐烂(Context Rot):当上下文窗口填满,LLM 的实际表现会显著下降。虽然厂商宣传支持 200k、500k tokens,但实际有效上下文往往 < 256k tokens。

2. 成本爆炸:按 token 收费的模式下,上下文无节制增长意味着成本线性甚至超线性增长。

3. 信息噪音:当你让 AI 做一个复杂任务(比如代码审查),它需要读几十个文件、运行多个检查工具。所有这些中间信息都会塞进上下文,最后你想问个简单问题,AI 却在一堆无关细节里迷失了。

这就是为什么单智能体会撞天花板。

Subagent:把大脑分区

Anthropic 的答案很简单:既然一个大脑装不下,那就分成多个小脑。

这就是 Subagent(子智能体)的核心思想。架构大概是这样:

用户请求
    ↓
Lead Agent(领导者智能体)
    ↓ 分解任务
    ├─→ Subagent 1:搜索相关代码
    ├─→ Subagent 2:分析安全漏洞
    ├─→ Subagent 3:检查测试覆盖率
    └─→ Subagent 4:审查代码风格
         ↓ 并行执行
    ← ← ← ← 汇总结果
    ↓
Lead Agent 综合分析
    ↓
返回给用户

关键设计原则

1. 任务分解:Lead Agent 负责把复杂请求拆成多个子任务
2. 并行执行:多个 Subagent 同时工作,每个有自己的上下文窗口
3. 上下文隔离:Subagent 的工作细节不会污染 Lead Agent 的上下文
4. 结果压缩:Subagent 只返回最重要的发现,而不是全部中间过程

举个实际例子。假设你在用 Claude Code 做代码审查:

• 单智能体模式:读文件 A、读文件 B、读文件 C……上下文越来越长,最后可能因为 token 限制放弃某些文件。

• 多智能体模式:

  • Subagent 1 负责读文件 A-D,找出安全问题 → 返回 3 个关键漏洞
  • Subagent 2 负责读文件 E-H,检查性能 → 返回 2 个性能瓶颈
  • Subagent 3 负责读测试文件,评估覆盖率 → 返回覆盖率报告
  • Lead Agent 综合这些压缩后的结果,给出完整审查报告

从 Lead Agent 的视角看,它只收到了几百个 token 的总结,而不是几万个 token 的原始数据。

从理论到实践:Claude Code 中的 Subagent

如果你是 Claude Code 的用户,可能已经在不知不觉中用上了 Subagent。

Claude Code 通过 Task 工具来调用 Subagent。比如当你让 Claude "研究一下这个项目的认证流程",它可能会:

1. 主智能体分析你的请求
2. 通过 Task 工具启动一个 Explore 类型的 Subagent
3. Subagent 探索代码库,读取相关文件,理解认证逻辑
4. Subagent 返回总结:"这个项目用 JWT + OAuth2,核心逻辑在 auth/service.ts:120,有个潜在的 token 刷新问题"
5. 主智能体基于这个总结继续对话

这个过程中,Subagent 可能读了 20 个文件,但主智能体的上下文只增加了几百个 token。

实战技巧

如果你想更好地利用 Subagent,有几个技巧:

1. 明确子任务边界:给 AI 清晰的指令,比如"用 Subagent 分析安全问题,用另一个 Subagent 检查性能"。

2. 并行思维:把能并行的任务列出来,让多个 Subagent 同时跑。代码审查从"几分钟"缩短到"几秒钟"的秘诀就在这。

3. 工具权限分离:不同的 Subagent 可以有不同的工具访问权限。比如安全审查的 Subagent 可以访问敏感 API,而代码风格检查的 Subagent 不需要。

代价与权衡

说了这么多好处,得泼盆冷水:多智能体不是银弹。

最直接的问题是成本。15 倍的 Token 消耗意味着,如果你在用 API 调用 Claude,账单会直接起飞。

Anthropic 自己也承认:多智能体系统最适合结果价值远大于成本的任务。

什么算"结果价值远大于成本"?

• ✅ 复杂的技术研究(Deep Research)
• ✅ 大型代码库的全面审查
• ✅ 需要综合多个数据源的决策分析
• ❌ 简单的代码补全
• ❌ 日常对话
• ❌ 单文件修改

另一个挑战是编排复杂度。你需要设计好:

• Lead Agent 的任务分解策略
• Subagent 的职责边界
• 结果如何汇总和去重
• 错误如何处理和回退

这不是简单的"开启多智能体"就能解决的,需要对任务有深入理解。

多智能体的未来:编排模式的演进

如果把视角拉高,会发现 Anthropic 的 Subagent 只是多智能体编排的一个实现。业界正在探索的编排模式还有:

1. Orchestrator-Worker 模式(Anthropic 采用的):中央编排器 + 并行工作者
2. Group Chat 模式:多个智能体通过共享对话解决问题
3. Hierarchical 模式:多层智能体,高层监督低层
4. Event-Driven 模式:基于事件驱动的智能体协作

每种模式适合不同场景。比如 Group Chat 更适合需要"辩论"和"讨论"的创意任务,而 Hierarchical 更适合大规模企业级工作流。

微软还在推 Model Context Protocol (MCP),让不同平台的智能体能够安全共享上下文。想象一下:你的个人 AI 助手可以把任务委派给专业的代码审查 AI、专业的数据分析 AI,它们各自有独立的上下文和专长。

这个方向很有意思:AI 智能体的未来不是单打独斗,而是团队协作。

写在最后

Anthropic 的 Subagent 架构本质上是在回答一个问题:如何让 AI 处理超越单个上下文窗口的复杂任务?

答案是分而治之:

• 用 Lead Agent 负责战略规划
• 用 Subagent 负责战术执行
• 用上下文隔离保护主对话清晰度
• 用并行执行提升效率

这不是什么革命性的创新,更像是把软件工程里的微服务、分布式系统思想应用到 AI 上。但正是这种"把成熟范式迁移到新领域"的做法,让多智能体系统真正可用了。

当然,15 倍的成本不是开玩笑。这意味着多智能体现阶段还是"奢侈品",适合高价值任务。但随着模型推理成本持续下降(这几乎是必然趋势),多智能体会越来越普及。

也许不久的将来,我们回头看单智能体,就像现在看单线程程序一样:能用,但为什么不并行呢?

参考资料:

• Anthropic Engineering Blog: Multi-Agent Research System
• Microsoft Learn: AI Agent Orchestration Patterns
• Claude Code Documentation: Subagents
• Industry Research: Context Window Management 2025

相关阅读推荐:

• Claude Code 可扩展性深度解析
• Cursor vs GitHub Copilot 完整对比