Sub-Agent VS Agent Team：多智能体架构和上下文边界 - 今日头条.md19.3 KBit/ai/Sub-Agent VS Agent Team：多智能体架构和上下文边界 - 今日头条.md
---
title: "Sub-Agent VS Agent Team：多智能体架构和上下文边界 - 今日头条"
source_url: "https://www.toutiao.com/article/7633656474358546996/?wid=1782278265180"
source_site: "www.toutiao.com"
clipped_at: "2026-06-24T05:17:56.750135+00:00"
clipper: "aiwiki-url-ingest"
extractor: "toutiao_rendered"
---
# Sub-Agent VS Agent Team：多智能体架构和上下文边界 - 今日头条
**架构师（JiaGouX）**
我们都是架构师！
架构未来，你来不来？
最近被问最多的一个问题，是关于多智能体怎么搭。
问题大同小异：要不要拆？拆几个？谁主谁副？要不要再来一个 lead？
我自己听到这种问题，第一反应通常是先不答。因为大多数情况下，问的人已经默认了一件事：任务复杂，所以应该多 Agent。
这个默认，恰恰就是问题最常出错的地方。
读 Suryansh Tiwari 那条帖子的时候，我对一句话特别有共鸣： **真正决定架构的，不是"要不要多 Agent"，而是"这个任务到底需要哪种协作"** 。
听起来像废话，但落到工程里，区别非常具体。一个团队选错了协作方式，模型再强也救不回来；选对了，单个 Sonnet 也能把活干得很干净。
今天，我想沿着这条线把多智能体的两种主形态——Sub\-Agent 和 Agent Team——讲清楚。再往下走一层，把我自己这两年踩过的几个典型坑，连起来说一说。
# 太长不看
如果只能记一句，我会这样讲：
> 多智能体架构里，最先该判断的不是"要拆几个"，而是这些子任务 **之间是否共享同一段上下文** 。能干净切开的用 Sub\-Agent，必须共享状态的才上 Agent Team。
几个我现在比较有体感的点：
- • 大多数多 Agent 系统搭歪了，不是因为模型不够强，是从第一层就按"岗位"在拆，而不是按"上下文边界"在拆。
- • Sub\-Agent 解决的是隔离、压缩、并行。它的价值不是"多开一个 Agent"，而是把混乱的探索过程压成一个干净的结论。
- • Agent Team 解决的是持续协作和共享状态。它适合那种"前一个人改完，后面所有人都要立即知道"的任务。
- • 把按角色拆 Agent（planner→developer→tester）当默认套路，最容易在每一次 handoff 里掉信息。质量不是被一次性砸坏的，是在交接里慢慢漏光的。
- • 大多数生产级多 Agent 系统，真正用到的就那几个原语：prompt chaining、routing、parallelization、orchestrator\-worker、evaluator\-optimizer。名字越花哨的"team / swarm / crew"，越容易掩盖建模本身没做完的问题。
- • 落到选型上，我会先反问自己一句：把这两个子任务交给同一个 Agent 一次性干，会不会更省心？如果答案是"会"，那就别拆。
# 大多数多 Agent 系统，是被"岗位思维"搭歪的
先说一个在团队里反复见到的画面。
有人接到一个稍微复杂点的任务，比如"帮我审一遍这段认证模块的代码"。第一反应不是去拆任务本身，而是去拆角色：
- • 一个 Planner，负责定方案；
- • 一个 Developer，负责改代码；
- • 一个 Tester，负责跑测试；
- • 再来一个 Reviewer，负责最后把关。
讲故事很顺，PPT 也画得漂亮。但只要你真把这套接到 Claude 或者任何 LLM 后面跑一遍，就会发现一个很尴尬的现象： **每一次交接，信息都在变薄。**
Planner 知道"这块代码之前刚被重构过，所以某个看似奇怪的判断其实是有原因的"，可这条上下文没传到 Developer。
Developer 在改的时候做了几个临时取舍，比如"这次先不改 token 校验顺序，因为会影响下游的 SSO"，可这层取舍也没沉淀下来。
到了 Tester，它拿到的就是一份相对干净的代码，外加一个干瘪的描述。它能跑测试，但跑不出"这次改动到底有没有踩到原有约束"。
最后 Reviewer 看到一个看起来都过了的结果，心里反而更没底。
这不是模型不够聪明，这是 **组织方式从一开始就搭错了** 。岗位是按人类公司的分工切的，但 LLM 不是真人，它没有上下班，没有共享的茶水间记忆，也没法靠"上次开会聊过"来补齐信息。它能拿到什么上下文，就只能基于什么上下文做事。
所以原文里有一句我特别想转给所有刚开始做 Agent 编排的人：
> Design around context boundaries, not roles.
**不要按角色设计，要按上下文边界设计。**
这句话很短，但翻译成工程语言，是要重新问一遍：
- • 这两件事，需不需要看到对方的中间过程？
- • 这两件事，会不会因为对方做完了某一步就影响自己下一步？
- • 如果交给同一个 Agent 一次性做完，会不会更省心？
如果答案都偏向"是"，那它们本来就该在一个 Agent 里，强行拆只是把成本转嫁给沟通层。
我们前些日子也讨论过类似的情况，可以看看《 多 Agent 不是虚拟公司：从 Anthropic 五种模式看信息流怎么设计 》
**Sub\-Agent：解决"隔离 \+ 压缩 \+ 并行"，不是"多开一个就更智能"**
把上面这层想清楚之后，再来看 Sub\-Agent 才比较顺。
Sub\-Agent 的本质不复杂。它就是父 Agent 把一段定义清楚的工作扔出去，子 Agent 在自己的独立上下文里跑完，把 **结论** ——注意， 是结论，不是推理过程 ——回收回来。
它的几个硬约束很值得记住：
- • 子 Agent 之间 **不能直接通信** ；
- • 子 Agent **不能再生新 Agent** ；
- • 所有流量必须经过父 Agent；
- • 跑完只返回最终输出，不带中间思考。
这些约束乍一看像在限制能力，其实是在保证 **可控性** 。
我自己理解 Sub\-Agent，更愿意把它看成三件事的组合：
**第一，隔离。** 子任务在自己的上下文里跑，不会把一堆中间探索污染父上下文。这点对长任务特别关键。父 Agent 的上下文窗口是宝贵资源，你不希望 it 被一堆"我先看看、再翻翻、又试试"的中间步骤撑满。
**第二，压缩。** 子任务返回的不是过程，是结论。它把一段乱糟糟的探索压成一句干净的信号。这跟我之前聊 Skills 时讲的"过程资产"思路是一致的——真正值钱的不是中间想了什么，是最后留下了什么可复用的判断。
**第三，并行。** 既然子 Agent 之间互不通信，那它们就可以放心地并发跑。代码审查里让一个 Agent 看安全、一个 Agent 看性能、一个 Agent 看测试覆盖率，三个并行跑完再汇总，比串行串到天荒地老划算得多。
原文里的那段示例代码其实就是这种模式：
```
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition
async def main:
async for message in query(
prompt="Review the authentication module for issues",
options=ClaudeAgentOptions(
allowed_tools=["Read", "Grep", "Glob", "Agent"],
agents={
"security-reviewer": AgentDefinition(
description="Find vulnerabilities and security risks",
prompt="You are a security expert.",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
"performance-optimizer": AgentDefinition(
description="Identify performance bottlenecks",
prompt="You are a performance engineer.",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
},
),
):
print(message)
```
这里有一个很容易被忽略的细节： `description` 字段。它表面上像注释，本质上是 **路由信号** 。父 Agent 怎么把任务分给哪个 Sub\-Agent，靠的就是这一段描述。写得含糊，路由就含糊；写得边界清楚，分发也清楚。
工具描述这件事，我之前在写《 如何为 Agent 设计产品？ 》时就强调过：写给人看和写给 Agent 看，是两件不一样的事。Sub\-Agent 的 description 就是这个原则在编排层的延伸。
# Agent Team：解决"持续协作"，不是"看起来更高级"
接下来才轮到 Agent Team。
如果说 Sub\-Agent 像把一段 任务外包出去 ，做完拿结果走人，那 Agent Team 更像一个长期在一起干活的小组：有 Lead、有队员、有共享的任务板，谁动了什么大家都立刻看得到。
它的几个关键差异：
- • 上下文是 **共享** 的，不是各管各的；
- • Agent 之间可以 **直接对话** ，不用都经过父级中转；
- • 任务有持续的状态层，进度、依赖、阻塞点都在上面挂着；
- • 一个 Agent 改了什么，会影响另一个 Agent 的下一步动作。
这种结构适合什么？适合那种"做着做着会发现问题，然后需要互相调头"的任务。
最典型的例子就是软件项目本身：前端改了接口契约，后端要立刻知道；测试发现某个用例挂了，开发要能即时拿到失败上下文；产品发现需求理解错了，整个链路要回退一步。这种场景里，靠"父代理统一中转"是跑不动的，等父代理把信息一层一层传下去，黄花菜都凉了。
但 **也正因为如此，Agent Team 的成本远高于 Sub\-Agent** 。
它需要一个共享状态层（不是简单的内存共享，是要能处理冲突、可见性、版本化的那种）；
它需要节点间的通信协议；
它需要一个 Lead Agent 来仲裁分歧、推动进度、识别阻塞；
它出错时调试链路也长得多，因为问题可能不在某一个节点，而在节点之间的协作上。
我看到很多团队的问题恰恰是反过来的：本来该用 Sub\-Agent 的简单并行任务，被强行套上了"team / crew / swarm"的概念，最后跑出来的不是协作，是噪音。
所以选型上我有一句很土的口诀：
> **任务不互相依赖，就别上 team；任务必须互相依赖，就别用 sub。**
听起来像废话，但实际项目里能踩稳这条线的，已经能避开 90% 的坑。
# 让我反复想起来的，是几种朴素的编排原语
读完原文我自己有一个挺解气的感受：作者没有把多 Agent 写成"二选一神话"。
Sub\-Agent 和 Agent Team 是两种结构没错，但生产里真正在用的，其实就那几个反复出现的原语：
1. 1\. **Prompt Chaining（顺序串）** ：A 做完给 B，B 做完给 C。简单线性任务最常用，比如"先抽取 → 再翻译 → 再润色"。
2. 2\. **Routing（路由）** ：根据任务特征把它派给最合适的 Agent。客服系统里那种"先识别意图再分流"的逻辑，本质上就是这个。
3. 3\. **Parallelization（并行）** ：互不依赖的任务一起跑，最后汇总。代码审查、文档多维度分析都是这个家族的。
4. 4\. **Orchestrator–Worker（调度\-执行）** ：一个 orchestrator 拆任务、派任务、收结果，workers 各自闷头干。这个其实就是 Sub\-Agent 的标准形态。
5. 5\. **Evaluator–Optimizer（评估\-优化）** ：先生成、再评估、再迭代。需要高质量产出的场景特别管用，比如生成式报告、代码补全后的自检。
这五种里，没有任何一个是新东西。它们都是工作流里早就存在的模式，只是这一波被重新放到了 Agent 编排的语境里。
我想强调的一点是： **多 Agent 不是一个产品形态，它是一组可组合的工作流原语。**
一旦把它当产品形态来理解，团队就容易陷入"我们也要搞个 team / 我们也要搞个 swarm"的攀比。但如果把它当工具箱来理解，问题就回到了"我这个任务，到底拼什么原语最合适"。
后者才是工程问题，前者只是市场问题。
也可以看看 Anthropic 的设计： 《 多 Agent 不是虚拟公司：从 Anthropic 五种模式看信息流怎么设计 》
# 一个更实用的判断框架
如果让我把这套思路压成一张能贴在工位上的小表，大概是这样：
| 你在问的问题 | 该考虑的方向 |
| --- | --- |
| 这个任务能不能一个 Agent 干完？ | 能就先这样，别提前优化 |
| 子任务之间需不需要看到彼此的中间过程？ | 不需要 → Sub\-Agent；需要 → Agent Team |
| 子任务跑的时候要不要互相影响？ | 不要 → 并行 Sub\-Agent；要 → Team |
| 是不是只是想"看起来更高级"？ | 是 → 退回单 Agent，先把任务模型搞清楚 |
| 每一步要不要严格按业务规则走，模型不能自由发挥？ | 要 → 加确定性中间层，不要硬塞给 team |
这张表的核心，其实就是一句话： **先把任务结构搞清楚，再决定 Agent 结构。** 不要反过来。
我之前讲 Harness 的时候也聊过类似的判断： 模型越强，外面的脚手架越重要。 多 Agent 编排是脚手架的一部分，但它不是脚手架本身。一上来就堆编排，常常意味着任务建模没做完。
# 什么时候根本不需要多 Agent
最后必须留一段给"反向决策"。
不是所有任务都需要多 Agent。事实上，我现在判断要不要上多 Agent 的第一个问题是：
> **单个 Agent 能不能干完？**
只要这个答案是"能，且体感不差"，就别折腾。多 Agent 带来的并不只是性能收益，还有一长串隐藏成本：
- • 编排逻辑要写、要维护、要监控；
- • Agent 之间的契约要定义、要版本化；
- • 调试链路变长，问题定位成本上升；
- • 上下文要在多个 Agent 间一致地流转，否则就会出现"信息差导致动作错"的怪 bug；
- • 治理成本（审计、回滚、计费）跟着翻倍。
我个人的经验是， **当任务高度依赖、协调成本远大于收益，或者上下文压根没法切干净的时候，单 Agent 反而是最稳的选择。**
很多人觉得这是"退而求其次"，我倒不这么看。一个能跑通、能调试、能持续迭代的单 Agent，比一个看起来很热闹但谁都说不清在做什么的多 Agent 体系，要更接近"真的在解决问题"。
# 最后
写到这里，我自己其实是在给"多智能体架构"做一次降温。
这一波 Agent 热，名词太多、范式太多、架构图太多。Team、Swarm、Crew、Society、Hive……每隔两周就有一个新词冒出来。
但回到工程，其实只有一个最朴素的问题： **我手上这个任务，要的是隔离、压缩、并行，还是要的是持续协作、共享状态、互相影响？**
前者用 Sub\-Agent，后者用 Agent Team，两者都不要的时候直接单 Agent。
再往上配一两个朴素的编排原语，多数生产场景就够了。
如果非要给今天的讨论加一句结尾，我会借作者那句话再说一遍：
> **围绕上下文边界设计，而不是围绕角色设计；从简单结构开始，只在确定需要时再加复杂度。**
听起来像句鸡汤。但只要你真做过几次多 Agent 编排，应该都能感受到这句话背后那一层一层的代价。
少一点"看起来更高级"，多一点"任务真的需要"，比什么都管用。
说到底，架构这件事一直没什么银弹。
**没有最好的架构，只有最适合当前任务的架构。**
软件工程里这条老话，搬到 Agent 世界一样成立——甚至更成立，因为 Agent 把"协作成本"这件事放大得更明显了。
一个团队、一个任务、一段时期，合适的结构可能就是不一样的。今天用 Sub\-Agent 跑得很顺，过半年业务长出新依赖，可能就要换成 Team；反过来也成立，原本以为非协作不可的流程，把任务模型拆清楚之后，单 Agent 就够。
所以与其把 Sub\-Agent 和 Agent Team 当成两个标签去站队，不如把它们当成两种工具，按需取用。
**架构不是越精巧越好，是越能匹配你手上这件事越好。**
# 相关推文
- • 《 Agent Harness 综述：同一个模型，为什么做出来的 Agent 差这么远 》
- • 《 MCP 退潮后，CLI 又成了王？一套更务实的判断框架 》
- • 《 再看 Hermes Skills：Agent 如何自我进化？ 》
- • 《 Agent 的下一步不是更长记忆，而是会维护过程资产 》
- • 《 如何为 Agent 设计产品？ 》
如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享
**因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享**
**·END·**
```
```
相关阅读：
- 刚刚，Claude Code“代码泄露”背后：如何重新看 Agent Harness
- 大家都在讲 Harness，但它到底该怎么理解
- 模型越来越强，为什么大家却开始重写 Harness
- 如何让单个 Agent 做长任务不失真：Anthropic 给出了一套更工程化的答案
- Claude Code高手的 8 个 Claude Code 实战习惯
- 别从 README 开始：一个架构师会怎样翻 Codex 仓库
- Spec 不是代码的替代品，它是 AI Coding 的上下文管理层
- 如何让 Agents 自己设计、升级 Agents
- OpenAI怎么把开源项目维护做成工作流：Skills、AGENTS.md 和 CI 的一套组合拳
- Claude Skills 入门：把“会用 AI”变成“可复制的工程能力”
- 一套可复制的 Claude Code 配置方案：CLAUDE.md、Rules、Commands、Hooks
- Claude Code 最佳实践：把上下文变成生产力（团队可落地版）
- 把 AI 当成新同事：Agent Coding 的上下文与验证体系
- 一周写百万行的背后：Cursor长时间运行 Agent 的工程方法论
- 2026年生活重启指南
- 我真不敢相信，AI 先加速的是工程师。
- 扒一扒 Claude Cowork 系统提示词：Anthropic 如何打造数字同事
- Cowork 安全架构深度解析：从 Claude Code 到 Cowork，Anthropic 如何把“可控”做成产品
- Anthropic官方万字长文：AI Agent评估的系统化方法论
- 银弹还是枷锁？Claude Agent SDK 的架构真相
- Claude Code创始人亲授13条使用技巧
- Claude Code 内部工具开源 code-simplifier：终结 AI 屎山代码的终极方案
```
```
> > 版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
**架构师**
我们都是架构师！