CSDN 原文镜像

本文为作者 CSDN 博客的全文镜像，原文发布于 2026-08-12。为适配本站结构，仅补充了站内元数据与来源说明，正文主体保持原文内容。

• 原文链接：https://blog.csdn.net/m0_63309778/article/details/163701731
• 站内分区：Agent / Subagent 与 MAS

前言

随着 Agent 系统能力越来越复杂，一个很自然的问题会出现：

一个 Agent 是否应该负责所有事情？

假设我们正在构建一个 Research Agent，用户要求：

调研全球主要 AI Agent 平台，比较它们的技术路线、产品能力、商业模式和未来趋势，并最终形成一份研究报告。

如果只使用一个 Agent，它可能按照这样的方式顺序工作：

理解研究目标
↓
搜索 OpenAI
↓
阅读和整理资料
↓
搜索 Anthropic
↓
阅读和整理资料
↓
搜索 Google
↓
阅读和整理资料
↓
搜索 Microsoft
↓
综合所有结果
↓
生成报告

这种模式当然可以工作，但问题也很明显。

大量搜索结果、网页内容、Tool Result 和中间分析会不断进入同一个 Context Window；与此同时，很多研究方向实际上彼此独立，例如研究 OpenAI 和研究 Google 并不需要严格按照先后顺序执行。

于是很自然会演化成：

                         Lead Agent
│
┌───────────────┼───────────────┐
↓               ↓               ↓
OpenAI Research   Google Research   Anthropic Research
Agent             Agent             Agent
│               │               │
└───────────────┼───────────────┘
↓
综合结果

到这里，我们就会接触到三个经常被混在一起的概念：

Subagent、MAS（Multi-Agent System）和 Multi-Agent Parallelism。

它们看起来都意味着“有多个 Agent”，但实际上描述的是三个不同的问题。

最简单的理解是：

Subagent 讨论的是任务委派关系，MAS 讨论的是整个多 Agent 系统如何组织，而多 Agent 并行讨论的是这些 Agent 在时间上如何执行。

理解了这层关系，很多多 Agent 架构问题就会清楚很多。

---

一、Subagent：把一个明确的子任务交给另一个 Agent

Subagent，中文通常可以理解为“子智能体”。

它最典型的特征并不是模型更小，也不是能力更弱，而是：

它接受 Parent Agent 或 Lead Agent 的委派，完成一个边界相对清晰的子任务，然后把结果返回给上层 Agent。

例如一个 Coding Agent 正在进行大型项目分析。

主 Agent 当前已经需要保存：

用户需求
项目架构
当前计划
已经修改的文件
工具调用结果
历史消息

这时候主 Agent 又需要运行完整测试套件。

测试可能产生几万行日志。

如果全部进入主 Agent Context，不仅消耗大量 Token，还可能让真正重要的信息被淹没。

因此可以把测试任务委派出去：

Main Coding Agent
│
│
│  “运行所有测试，
│   分析失败原因，
│   只返回重要结论。”
↓
Test Subagent
│
├── 执行测试
├── 阅读大量日志
├── 分析失败用例
└── 压缩结果
│
↓
返回 Main Agent：

“共发现 6 个失败测试，
其中 4 个与 Refresh Token 有关，
核心问题位于 AuthService。”

这里 Test Subagent 完成自己的工作以后，责任基本就结束了。

它不需要决定：

• 整个 Coding 任务下一步做什么；
• 是否修改 AuthService；
• 是否重新设计 JWT；
• 最终任务什么时候结束。

这些责任仍然在 Main Agent。

因此，可以把 Subagent 的任务关系概括成：

“这块事情你帮我做一下，做好以后把结果告诉我。”

---

二、Subagent 真正重要的价值：Context Isolation

很多人第一次接触 Subagent 时，会认为它的价值是：

多创建一个 Agent，增加一点“智能”。

实际上，从工程角度看，Subagent 最有价值的能力之一往往是：

Context Isolation。

每个 Subagent 可以拥有自己的：

System Prompt
Context Window
Tool Set
Permission
Memory
Execution State

这意味着，大量只与当前子任务相关的信息不需要进入 Main Agent。

例如 Research 场景：

                        Lead Agent
│
┌───────────────┼───────────────┐
↓               ↓               ↓
Research A      Research B       Research C
Context A       Context B        Context C
80K             70K              90K
│               │               │
↓               ↓               ↓
Summary         Summary          Summary
└───────────────┼───────────────┘
↓
Lead Agent Context

三个 Research Agent 可能总共阅读几十万 Token 的资料。

但 Lead Agent 最终只接收：

3K Summary
+
4K Summary
+
3K Summary

相当于 Subagent 帮主 Agent完成了一次上下文压缩。

Anthropic 在 Claude Research 多 Agent 系统的实践中，也把这种架构描述为一种有效的“压缩”机制：Subagent 使用独立 Context Window 进行大量探索，再把最有价值的信息返回 Lead Agent。

这也是为什么 Research、日志分析、测试、代码搜索、文档阅读等场景特别适合 Subagent。

---

三、Subagent 做的通常是什么任务？

Subagent 最适合的是：

目标明确、边界清晰、完成后能够产生一个结果的子任务。

例如 Coding Agent 可以委派：

搜索整个仓库中 JWT 相关代码

分析这一批失败测试

检查某个模块安全问题

阅读 Spring Boot 迁移文档

总结最近一次 Git Diff

检查数据库 Schema

分析某一个接口的调用链

这些任务可能并不简单。

一个 Security Subagent 甚至可以运行十分钟、调用几十次 Tool。

但是从整个系统角度看，它仍然只负责：

Security Analysis

完成后返回：

SecurityReport

然后由 Parent Agent 决定接下来怎么办。

因此 Subagent 的核心不是：

任务简单

而是：

责任边界清晰

---

四、MAS：从“派一个助手”升级成“组织一个 Agent 团队”

MAS 全称：

Multi-Agent System，多智能体系统。

它关注的问题比 Subagent 更高一层。

Subagent讨论：

某块工作交给谁？

MAS 讨论：

多个能够自主推理和行动的 Agent，应该如何组成一个系统，共同完成一个复杂目标？

假设我们的目标是：

完成一次大型支付系统升级。

MAS 可能设计成：

                   Payment Migration MAS
│
┌─────────────────┼─────────────────┐
↓                 ↓                 ↓
Architecture Agent    Backend Agent    Security Agent
│                 │                 │
│                 ↓                 │
│             Test Agent            │
│                 │                 │
└─────────────────┼─────────────────┘
↓
Review Agent
↓
最终结果

这里 Backend Agent 不只是：

帮 Main Agent 修改一个文件。

它的职责可能是：

负责整个 Backend Migration，直到满足升级目标。

Security Agent 也不是简单：

扫描一下安全问题。

而可能是：

持续负责整个升级过程中的安全风险，必要时要求 Backend Agent 修改方案。

这种任务责任已经比普通 Subagent 更完整。

所以可以用一句非常直白的话区分：

Subagent 更像“帮我完成这块工作”。

MAS Agent 更像“你负责这个领域，我们一起把整个项目做完”。

---

五、两者在任务上的最大区别：Task-oriented 和 Role-oriented

这是 Subagent 与 MAS 最值得讲清楚的地方。

假设主任务是：

完成一次 Java 17 → Java 21 的大型项目升级。

如果采用 Subagent 模式：

                   Main Coding Agent
│
┌────────────┼────────────┐
↓            ↓            ↓
Dependency       Test        Documentation
Subagent      Subagent        Subagent

Main Agent 仍然承担核心任务。

它会：

分析架构
制定升级方案
修改核心代码
决定执行顺序
处理冲突
判断是否完成

Subagent 则负责一些明确工作：

Dependency Subagent
→ 分析依赖兼容性

Test Subagent
→ 执行测试并总结错误

Documentation Subagent
→ 查询迁移文档

它们完成以后，把结果交给 Main Agent。

这种模式本质是：

Main Agent
=
Project Owner

Subagent
=
Task Worker

---

如果使用 MAS，情况会变成：

                    Java Migration MAS
│
┌───────────────────┼───────────────────┐
↓                   ↓                   ↓
Architecture Agent   Backend Agent      Dependency Agent
│                   │                   │
│              Test Agent               │
│                   │                   │
└───────────────────┼───────────────────┘
↓
Review Agent

这里不同 Agent 对不同领域负责。

Backend Agent 的 Goal 可能是：

确保所有 Backend 代码能够在 Java 21 上正确运行。

Test Agent 的 Goal 是：

确保升级后的系统满足测试和回归要求。

Dependency Agent 的 Goal 是：

确保所有依赖版本兼容，并解决 Breaking Changes。

也就是说，MAS 中 Agent 的任务往往更加：

Role-oriented
Goal-oriented

而 Subagent 的任务更像：

Task-oriented

这并不是绝对规则，但非常适合作为工程上的判断方式。

---

六、判断 Subagent 和 MAS 最实用的问题：谁对最终目标负责？

这是区分两者最好用的方法。

假设有一个 Agent 负责：

找出仓库中所有 JWT 相关代码。

输入：

Repository

输出：

17 个相关文件
8 个主要调用链
3 个风险点

结果返回以后，它的任务就结束了。

这非常像：

Subagent

至于：

JWT 应该怎么改？

应该先改 Backend 还是 Frontend？

需要修改数据库吗？

什么时候算迁移完成？

都由上层 Agent 决定。

---

而 MAS 中一个 Security Agent 可能承担：

确保整个 JWT 改造不存在明显安全问题。

这个 Agent 可能需要：

分析方案
↓
检查 Backend 修改
↓
发现风险
↓
要求 Backend Agent 调整
↓
重新审核
↓
运行安全测试
↓
确认满足目标

它不是完成一次“扫描”就结束。

它需要持续对一个职责目标负责。

所以可以把二者概括成：

Subagent

Input
↓
Task
↓
Result
↓
Return to Parent

而 MAS Agent 更接近：

Role
↓
Goal
↓
Observe system
↓
Act / Collaborate
↓
Evaluate
↓
Continue
↓
Goal satisfied

---

七、但 Subagent 和 MAS 并不是互斥关系

这里很容易产生另一个误区：

Subagent 架构
VS
MAS 架构

实际上 Subagent 完全可以是 MAS 中的一种组织形式。

例如：

                       MAS
│
Lead Agent
│
┌──────────┼──────────┐
↓          ↓          ↓
Subagent   Subagent   Subagent

这是：

Hierarchical MAS。

但 MAS 还可以有其他形态。

例如 Handoff：

Triage Agent
↓
Handoff
↓
Refund Agent

或者 Peer Collaboration：

Agent A ↔ Agent B ↔ Agent C

或者 Graph：

              Agent A
/       \
Agent B      Agent C
\       /
Aggregator

所以：

Subagent 是 MAS 中非常常见的一种 Agent 关系，但 MAS 不等于 Subagent。

---

八、Manager 和 Handoff 是两种非常典型的 MAS

OpenAI Agents SDK 对这一点给出了非常清晰的区分。

第一种是：

Manager Pattern

                      Manager Agent
│
┌─────────────┼─────────────┐
↓             ↓             ↓
Search Agent   Finance Agent  Writing Agent

Manager 一直掌握用户会话。

其他 Agent 更像专业能力。

它们执行完以后：

Result
↓
Manager

最终回答仍然由 Manager 生成。

OpenAI 将这种方式称为：

Agents as Tools

这与 Subagent 思路非常接近。

---

第二种是：

Handoff Pattern

例如：

用户
↓
Triage Agent
↓
判断：退款问题
↓
Handoff
↓
Refund Agent
↓
直接和用户继续交互

这时候 Refund Agent 不再只是：

给 Triage Agent 帮个忙。

它直接接管整个后续流程。

所以：

Manager / Subagent

强调集中控制。

Handoff

则把控制权交给其他 Agent。

这也是 MAS 需要解决的问题：

控制权到底在哪里？

---

九、Multi-Agent Parallelism：这是执行方式，不是组织方式

接下来是第三个容易被混淆的概念：

多 Agent 并行。

假设一个 Research MAS 中有：

Market Agent
Technology Agent
Policy Agent

可以串行：

Market
↓
Technology
↓
Policy

也可以并行：

           ┌── Market Agent
│
Research ──┼── Technology Agent
│
└── Policy Agent

所以：

MAS 回答“谁和谁协作”，Parallelism 回答“谁和谁同时执行”。

Google ADK 的 ParallelAgent 就是一种非常典型的 Workflow Agent：它会同时启动多个 Subagent，用于彼此独立的任务。

需要特别注意：

只有相对独立的任务才真正适合并行。

例如：

研究 OpenAI
研究 Anthropic
研究 Google

非常适合。

但：

设计数据库
↓
根据数据库设计 API
↓
根据 API 编写 Frontend

显然存在依赖。

不能为了“多 Agent”强行全部并行。

---

十、多 Agent 并行最大的难题：共享状态和冲突

真正创建几个并行 Agent并不困难。

困难的是：

它们是否会互相干扰？

Research Agent 通常比较安全：

Agent A
读资料

Agent B
读另一批资料

因为大部分操作都是 Read。

但 Coding Agent 就复杂很多：

Agent A
修改 AuthService

Agent B
同时也修改 AuthService

很容易出现：

代码覆盖
Merge Conflict
状态不一致

因此 Coding MAS 往往需要：

独立 Workspace
Git Branch
Task Lock
File Ownership
Merge Strategy

而 Research MAS 则更多需要：

Context Isolation
Search Boundary
Result Aggregation

这也说明：

多 Agent 系统并没有一个通用的最佳架构。

系统的 Domain 会决定最难解决的问题是什么。

---

十一、真实案例：Anthropic Claude Research

Anthropic 公开介绍的 Claude Research，是理解 Subagent、MAS 和并行 Agent 非常好的真实案例。

其核心结构可以简化为：

User Research Query
↓
Lead Research Agent
↓
理解问题
制定 Research Plan
↓
┌──────────────┬──────────────┐
↓              ↓              ↓
Research Subagent A  Subagent B    Subagent C
│              │              │
Web Search      Web Search      Web Search
│              │              │
Tool Calls      Tool Calls      Tool Calls
│              │              │
└──────────────┼──────────────┘
↓
Lead Research Agent
↓
综合
↓
Citation Agent
↓
Final Report

这里正好能够对应前面三个概念。

Subagent

Lead Researcher 把不同研究方向委派给不同 Research Subagent。

每个 Subagent 有自己的 Context Window，并独立搜索、阅读、分析，再把结果压缩给 Lead Agent。

MAS

Lead Agent、多个 Research Subagent 和 Citation Agent 共同构成整个 Research Multi-Agent System。

Parallelism

多个 Research Subagent 可以同时搜索不同研究方向。

而每个 Subagent 内部甚至还可以同时发起多个 Web Search。

因此形成：

Agent Parallelism
×
Tool Parallelism

---

十二、Anthropic 案例为什么能获得明显收益

Research 是非常适合多 Agent 的场景。

因为它天然存在大量独立探索路径。

例如：

调研全球主要 AI Agent Framework。

可以拆成：

OpenAI
Anthropic
Google
Microsoft
开源生态
商业产品

这些方向并不需要互相等待。

所以并行 Agent 可以直接增加：

搜索宽度
Tool Call Budget
Context Capacity
探索路径数量

Anthropic 在内部 Research Evaluation 中报告，多 Agent Research 系统相较单独 Lead Agent 获得了明显质量提升，同时通过两层并行显著降低复杂研究任务的总体耗时。

这里很重要的一点是：

Multi-Agent 并不是凭空让单个模型变聪明了。

它更像是给整个系统增加：

更多 Token Budget
+
更多 Context Window
+
更多 Tool Calls
+
更多并行探索路径

然后通过 Lead Agent 把这些探索结果组织起来。

---

十三、这个案例真正值得学习的是 Delegation

Anthropic 实践中一个非常典型的问题是：

Lead Agent 创建了多个 Subagent，但几个 Agent 做了几乎一样的事情。

如果 Parent Agent 只告诉三个 Agent：

调研 AI Agent 产品。

三个 Agent 很可能都去搜索：

OpenAI
Anthropic
Google

产生大量重复劳动。

所以优秀的 Task Delegation 应该明确：

Objective

Scope / Boundary

Expected Output

Allowed Sources / Tools

Stop Condition

例如：

Subagent A
只负责 OpenAI 和微软生态。

Subagent B
只负责 Anthropic 和 Google。

Subagent C
只调查开源 Agent Framework。

最终分别返回：
产品能力、技术路线、商业模式、核心来源。

这时候每个 Agent 的探索空间才真正互补。

因此 MAS 的难点从来不是：

spawn 5 agents

而是：

如何正确拆任务，让五个 Agent 做五件真正不同而有价值的事情。

---

十四、为什么 Agent 越多不一定越好

Multi-Agent 有一个非常现实的问题：

贵。

一个普通 Chat 可能只调用一次模型。

一个 Agent 可能调用：

10 次模型
+
20 次 Tool

一个 MAS 又可能同时拥有：

1 Lead Agent
+
5 Subagents
+
1 Citation Agent

整个 Token 消耗会迅速增长。

Anthropic 的生产实践也指出，Multi-Agent 的 Token 消耗明显高于普通对话和单 Agent。

所以不能因为：

Multi-Agent 更先进

就所有请求都创建五个 Agent。

更合理的是根据任务复杂度分配 Agent Budget。

例如：

简单事实问题
→ 单 Agent

简单子任务
→ Main Agent + 1 Subagent

多方向比较
→ 2~3 个并行 Subagent

复杂开放式 Research
→ 完整 MAS

因此真正的生产问题是：

这次任务值得花多少 Agent Budget？

---

十五、什么时候应该用 Subagent，什么时候升级 MAS

可以用责任边界来判断。

如果主 Agent 能明确说：

我只需要另一个 Agent帮我完成一件事情，然后把结果给我。

优先考虑：

Subagent

例如：

搜索代码
分析测试
查询资料
做一次安全 Review

如果问题变成：

这个目标需要多个不同角色长期负责各自领域，并持续互相协作。

更适合：

MAS

例如：

完整软件项目开发

大型 Research

企业尽调

复杂数据分析

自动化运营

而是否并行，则继续问：

这些任务之间有没有强依赖？

没有：

Parallel

有：

Sequential / DAG / Workflow

于是可以形成一个很实用的决策过程：

一个 Agent 能做好吗？
│
┌───┴────┐
│        │
能       不能
│        │
单 Agent   ↓
能否拆成明确子任务？
│
┌───┴────┐
│        │
能       不能
│        │
Subagent   重新设计
│
↓
是否需要多个角色长期协作？
│
┌───┴────┐
│        │
否       是
│        │
Subagent     MAS
│
↓
子任务是否相互独立？
│
┌───┴────┐
│        │
是       否
│        │
Parallel   Workflow

---

十六、大厂实践可以总结成什么

结合 Anthropic、OpenAI、Google 和 Microsoft 当前的 Agent 体系，可以得到一套比较一致的工程原则。

第一，能用单 Agent 解决，就不要急着上 MAS。

多 Agent 引入的不只是更多能力，还有更多 Token、状态、调度、Trace 和失败模式。

第二，Subagent 应该小而专。

一个 Subagent 最好有明确职责、Prompt、Tool 和 Permission。

第三，Parent → Subagent 的委派必须有清晰 Contract。

否则多 Agent 很容易产生重复工作。

第四，只有独立任务才真正适合 Parallel。

任务之间存在依赖时，更适合 Workflow / DAG。

第五，MAS 中必须明确最终控制权。

可以是 Manager，也可以通过 Handoff 转移。

第六，Context Isolation 是多 Agent 最重要的收益之一。

不要让所有 Subagent 原始 Tool Log 都重新进入 Lead Context。

第七，Shared State 必须显式设计。

尤其在 Coding、数据修改、业务操作场景中，要处理并发写入和 Conflict。

第八，Agent 数量和 Token Budget 必须受控。

不要允许 Orchestrator 无限 spawn Agent。

第九，Multi-Agent 必须配套 Trace、Metrics、Cost 和 Eval。

因为系统真正出现问题以后，你需要知道：

哪个 Agent
为什么被创建
拿到了什么任务
调用了什么 Tool
消耗了多少 Token
返回了什么
为什么最终结果错误

---

结语

Subagent、MAS 和多 Agent 并行虽然经常同时出现，但其实分别描述三个不同的问题。

Subagent 关注任务委派：

这个明确的子任务交给谁做？

MAS 关注系统组织：

多个拥有独立目标、Context 和能力的 Agent，应该如何共同完成一个复杂目标？

Multi-Agent Parallelism 关注执行调度：

这些彼此独立的 Agent 工作是否可以同时执行？

而 Subagent 与 MAS 在“做什么任务”上的真正区别，可以用一句非常简单的话概括：

Subagent 更像“这块事情你帮我做完，然后把结果给我”。

MAS 更像“这个项目我们几个角色分工合作，一起把最终目标完成”。

因此，一个典型的 Subagent 任务具有清晰的输入、输出和任务边界。

一个 MAS Agent 则更可能承担一个持续性的职责目标，需要不断观察系统、采取行动，并与其他 Agent 协作直到目标达成。

Anthropic Claude Research 是一个很典型的例子：

Lead Agent
+
Specialized Subagents
+
Parallel Research
+
Result Aggregation
+
Citation Validation

这里 Subagent 解决专业任务拆分，MAS 解决整个系统的多 Agent 协作，而 Parallelism 让多个独立研究方向能够同时推进。

所以真正成熟的 Multi-Agent Architecture，从来不是：

多创建几个 Agent

而是：

正确拆分任务
+
清晰定义责任
+
隔离 Context
+
合理进行 Delegation
+
只并行独立工作
+
显式管理 Shared State
+
控制 Agent Budget
+
正确汇总结果
+
完整 Observability

只有这些能力同时存在时，多 Agent 才真正从：

“多个模型同时跑”

变成：

“多个智能体作为一个有组织的团队共同完成复杂目标”。

参考资料

Anthropic Engineering — How we built our multi-agent research system
重点介绍 Claude Research 的 Lead Agent、Subagent、并行 Research、Delegation、Context Compression、成本与评测实践。

Anthropic Claude Code Documentation — Subagents
介绍 Subagent 的独立 Context Window、System Prompt、Tool、Permission，以及串行和并行使用方式。

OpenAI Agents SDK — Multi-agent orchestration
介绍 Manager / Agents-as-Tools、Handoff、Code Orchestration 与 LLM Orchestration。

Google Agent Development Kit — Parallel workflow agents
介绍 ParallelAgent、独立执行分支以及 Shared State、并发访问等问题。

Microsoft AutoGen AgentChat
提供 Selector Group Chat、Swarm、GraphFlow 等不同 MAS Coordination Pattern。

Anthropic Engineering — Building effective agents
强调从简单 Agent 和可组合 Workflow 开始，只有在复杂度确实需要时才升级到 Multi-Agent。

Anthropic Engineering — Building a C compiler with a team of parallel Claudes
展示 Coding 多 Agent 场景中 Task Lock、独立 Workspace、并行修改和共享代码库协调问题。