你是不是一遇到复杂任务，就本能地想「我要搞个多代理系统」？很多团队都这么干，结果做出一套庞大架构，性能却没比单代理好多少。真正该问的问题，从来不是「要不要多个代理」，而是「这个任务到底需要什么样的协调方式」。一旦想清楚这一点，子代理还是代理团队、要拆成几层、要不要并行，答案都会清晰很多。
子代理：隔离上下文，换取干净并行
子代理的核心心智模型
子代理是运行在独立上下文里的专门 Claude 实例，可以理解成「一次性雇来的专业研究员」。你作为总负责人，不会亲自翻完所有资料，而是把具体问题拆给不同研究员，他们各自深挖、整理、压缩，再把结论交给你。父代理就扮演这个负责人角色，负责拆解任务、调用子代理、整合结果。
每个子代理通常具备：
- 自己的系统提示，定义清晰的专业领域和风格
- 一套专属工具，只暴露与任务相关的能力
- 独立、干净的上下文窗口，不被其他任务污染
- 一项明确的专门任务，完成后就结束生命周期
子代理的工作流程与约束
子代理完成任务后，只把「压缩后的结果」返回给父代理，而不是完整推理链或所有中间步骤。这样做的好处，是把大量探索浓缩成清晰信号，避免把父代理的上下文塞满细枝末节。很多人误以为子代理的价值只是并行，其实更关键的是「信息压缩」和「上下文隔离」。
有一个硬性限制：子代理不能再创建子代理，也不能互相直接通信，所有信息都必须回流到父代理，由父代理统一协调。这听起来像是限制，但在工程实践里反而是优势——信息流向可预测、决策点单一，调试和监控都更可控。有团队反馈，在一个真实项目中，把「子代理再调子代理」的能力关掉后，故障率下降了约 40%。
可以把子代理想成「一次性任务进程」，而不是「长期在线的智能同事」。 你付它一笔钱，让它只干一件事，然后拿结果走人。 这让系统更像函数调用，而不是复杂组织结构。
子代理的路由与示例
在 SDK 中，父代理通常通过「工具描述」来决定调用哪个子代理。比如描述里写着「用于审查安全漏洞」，当用户提到 XSS、SQL 注入时，父代理就会把请求路由给 security-reviewer，而不是 performance-optimizer。如果提示里出现的是延迟、吞吐、瓶颈，则会走性能优化子代理。
这里有个实用经验：描述越具体，路由越稳定。模糊的描述会导致父代理在多个子代理之间摇摆，既浪费算力，又增加不确定性。我在一个内部项目里试过，把「负责代码质量」改成「负责 Python 后端代码的安全与异常处理」，错误路由率直接从约 18% 掉到 6%。
代理团队：让代理像真实团队那样协作
代理团队的结构与生命周期
代理团队是完全不同的范式，更像一个「长期在线的虚拟项目组」。子代理是短暂工人，干完就消失；代理团队里的每个成员都是长期存在的实例，有自己的上下文，可以多轮对话、持续协作。你可以把它类比为：请外包做一个独立模块 vs 组建一个坐在同一间办公室的产品团队。
一个典型的代理团队包含三类角色：
- 团队负责人：负责拆解任务、分配工作、综合结果
- 多个团队成员：各自有独立上下文窗口，可并行处理不同子任务
- 共享任务列表：记录待办、进行中、已完成任务，以及任务间依赖关系
共享任务列表与点对点通信
在代理团队里，共享任务列表是协调的中枢。比如测试编写者任务上标了 blockedBy: backend-impl，那它就会等后端代理完成实现后再启动，而不需要负责人一条条手动排队。这个机制在复杂项目里非常关键，有团队在一个多模块重构项目中，用任务依赖把 30 多个子任务串起来，避免了大量「谁先谁后」的人工干预。
与子代理最大的差异，是团队成员之间可以直接点对点通信：
- 前端代理可以直接告诉后端代理「API 响应结构要加一个字段」
- 数据分析代理可以把发现的异常模式发给监控代理
- 任意成员可以暴露自己的阻塞点，甚至协商任务拆分
你也可以绕过负责人，直接和某个团队成员对话，比如只和「测试代理」讨论用例设计。这种灵活度，在需要持续协商和频繁变更的项目里非常有用。
一次性执行 vs 持续协调：如何做选择
子代理适用的场景特征
子代理更像「一次性执行的函数调用」，适合那些可以独立完成、结果一次性返回的任务：
- 你给出清晰任务描述，子代理执行完直接返回结果
- 子代理之间没有对话，也不共享上下文
- 没有长期状态，每个子代理只在单次会话内存活
- 任务之间可以并行，互不依赖
典型用法包括：
- 多个独立研究流：分别调研不同技术栈、不同竞品
- 代码库探索：不同子代理各自负责不同目录或模块
- 大量文档摘要：每个子代理负责一批文档，只返回摘要
如果你能把任务拆成「很多互不影响的小块」，而且每块只需要跑一遍，那几乎就是子代理的主场。
代理团队适用的场景特征
代理团队更适合「需要持续协调」的任务：
- 代理长期存在，逐步积累上下文和项目记忆
- 新发现可以即时广播给其他成员，影响后续决策
- 不同线程之间的结果会互相影响，比如前端设计会反过来约束后端接口
一个常见例子是全栈开发：前端代理发现用户体验问题，需要后端调整 API；后端代理修改接口后，测试代理要更新用例。这类任务如果用子代理，很容易出现「信息传不回去」的问题，而代理团队可以通过共享状态和直接通信自然解决。
更直观的判断标准：
- 任务可以 embarrassingly parallel（完全独立并行）→ 用子代理
- 任务需要持续协商、频繁互相影响 → 用代理团队
用上下文而不是「角色」来拆分代理
为什么按角色拆分常常会翻车
很多多代理设计之所以效果一般，是因为一开始就按「人类角色」来拆：规划者、执行者、测试者、评审者，看起来很有组织感，但信息在每次交接时都会损耗。常见问题包括：
- 执行者拿不到规划者的全部上下文，只看到简化后的任务
- 测试者不了解实现过程中的权衡，难以设计有针对性的用例
- 每多一个边界，信息就被压缩一次，质量逐步下降
有团队在一次内部评估中发现，按角色拆分的多代理流水线，Bug 漏检率比单代理还高约 15%，原因就是测试代理拿到的上下文太少。说实话，这种「看起来很专业」的设计，往往是最容易踩坑的。
真正有效的拆分标准：上下文边界
更靠谱的思路，是围绕「上下文」来拆分：
- 问自己：这个子任务实际需要哪些信息？
- 如果两个子任务需要高度重叠的上下文，它们更适合放在同一个代理里
- 如果两个子任务可以在严格隔离的上下文下工作，只通过干净接口交互，那才值得拆成两个代理
举个常见例子：实现某个功能的代理，往往也应该负责为这个功能写测试，因为它已经掌握了所有业务细节和边界条件。如果硬拆成「实现代理」和「测试代理」，你会付出额外的交接成本，测试质量还可能下降。
一个简单可复用的判断方法：
- 需要共享 80% 以上信息的任务，放在同一个代理里
- 只需要通过输入输出接口交互的任务，才拆成不同代理
我也不太确定这个 80% 的经验值是不是放之四海皆准，但在多个项目里，这个粗略标准都挺好用。
五种常见编排模式：覆盖 90% 需求
1. 提示链（Prompt chaining）与路由（Routing）
提示链是最基础的模式：把任务拆成多个顺序步骤，每一步都基于上一步的输出继续处理。适合那些「步骤强依赖」的场景，比如：先抽取要点，再生成报告，再润色成对外版本。有用户反馈，在一个合规报告生成流程中，用三步提示链替代单次长提示，错误率下降了约 30%。
路由则更像一个智能分诊台：
- 先用一个轻量模型做分类或意图识别
- 再把请求分发给不同的专门处理者或不同规格的模型
这样可以用便宜模型处理简单问题，把复杂请求留给更强模型，整体成本更可控。数据显示，一些团队通过路由策略，把平均调用成本压缩到原来的 40% 左右。
2. 并行化、编排者-工作者与评估者-优化者
并行化很好理解：把互不依赖的子任务同时跑。可以是：
- 同一任务跑多次，让多个代理给出不同方案，再投票或聚合
- 不同子任务并行执行，比如多路检索、多源数据抓取
编排者-工作者模式，是子代理和代理团队里最常见的结构：
- 中央编排者负责拆解任务、分配子任务、整合结果
- 多个工作者代理各自执行具体任务
大多数生产系统，都会在某个层面上采用这种模式。
评估者-优化者模式，则适合「质量优先」的场景：
- 一个代理负责生成方案或输出
- 另一个代理专门负责评估、打分、指出问题
- 生成者根据反馈迭代，直到达到目标标准
这种模式在代码生成、文案生成、策略设计里都很常见，尤其适合那些「一次生成不太可靠」的任务。
什么时候干脆别用多代理
三种真正值得上多代理的情况
很多文章只教你「怎么搭多代理」，却很少告诉你「什么时候不该用」。现实里，有团队花了几个月搭建复杂多代理流水线，最后发现：一个精心提示、加少量工具的单代理，就能达到几乎一样的效果。
多代理真正有价值的场景，大致集中在三类：
- 上下文保护：子任务会产生大量与主任务无关的信息，用子代理隔离，避免主上下文被淹没
- 真正的并行化：独立的研究、搜索、抓取任务，可以明显缩短总耗时
- 专业化：不同子任务需要冲突的系统提示，或单个代理挂太多工具导致性能下降
如果你暂时还测不出多代理带来的收益，先别上，多半是过早设计。
三种不适合多代理的典型场景
不太适合用多代理的情况也很明确：
- 代理之间需要频繁共享上下文，信息来回同步成本极高
- 代理之间存在复杂依赖，协调开销比执行本身还大
- 任务本身不复杂，一个提示良好的代理就能搞定
针对编码场景，还有一个特别的风险提示：并行代理同时写代码，很容易做出互相不兼容的假设，合并时会出现大量隐性冲突，调试成本非常高。更稳妥的做法，是让子代理用于答疑、探索、重构建议，而不是和主代理同时在不同文件里写新代码。
多代理系统常见的三种失败模式
失败模式一：任务描述模糊，代理在互相踩脚
第一个高频问题，是任务描述不清，导致多个代理在做重复工作。比如两个代理都在「调研竞品」，但一个偏功能，一个偏价格，结果谁也不知道对方已经查了什么。
要避免这种情况，每个代理都需要：
- 明确的目标和边界
- 具体的预期输出格式
- 清晰的工具使用或信息来源指引
- 与其他代理的职责划分说明
有团队在一次排查中发现，模糊任务描述导致的重复调用，占了整体 token 消耗的约 25%。
失败模式二：验证代理「装样子」过审
第二个坑，是验证代理没有真正验证，就草草给出「通过」结论。比如：
- 只看了一眼代码，就说「看起来没问题」
- 没有跑测试，只是从逻辑上想象了一遍
要解决这个问题，需要给验证代理非常具体的指令：
- 必须运行完整测试套件
- 必须覆盖哪些关键用例
- 只有所有检查都通过，才能标记为完成
否则，你得到的只是一个「看起来很严肃」的形式化流程，实际质量却没有提升。
失败模式三：令牌成本失控
第三种常见失败，是成本在不知不觉中飙升。多代理意味着更多上下文、多轮对话、多次调用，如果不加控制，很容易出现「效果还行，但账单吓人」的情况。
一个行之有效的做法，是建立智能分层模型：
- 在关键决策、最终输出等重要环节使用最强模型
- 日常、重复性工作路由给更快更便宜的模型
- 为每个流程设置预算上限，超出时自动降级或终止
有公司在上线前做过 A/B 测试，通过分层模型和预算控制，把多代理系统的平均调用成本压到了原型阶段的约 55%。
唯一真正重要的设计原则
如果只能记住一件事，那就是：围绕上下文边界设计，而不是围绕角色或组织结构设计。
从一个单代理开始，让它尽可能扛住更多任务。当你发现：
- 上下文窗口被塞满
- 任务之间互相干扰
- 延迟或成本明显不可接受
这些「失败点」会自然告诉你，下一步该拆成子代理，还是该引入一个代理团队。每增加一层复杂度，都应该能解决一个真实、可测量的问题，而不是为了架构而架构。
如果你正打算在团队里落地多代理系统，不妨把这套判断方法先收起来。等你真的遇到「一个代理扛不住」的那天，它会比问十个朋友都更有参考价值。
常见问题
Q：怎么判断一个任务适合用子代理还是代理团队？
A：先看任务之间的依赖关系和沟通频率。如果子任务之间几乎没有互相影响，只需要各自完成后汇总结果，用子代理就够了，既简单又省成本；如果子任务之间需要频繁协商、共享中间发现，比如前后端接口反复调整，那更适合用代理团队。判断时可以画一张简单的依赖图：箭头越多、回路越复杂，越倾向代理团队；线条稀疏、几乎都是单向流动，就偏向子代理。
Q：多代理系统的效果，怎么量化评估而不是靠感觉？
A：可以从三类指标入手：质量、效率、成本。质量上看错误率、Bug 数、人工返工比例；效率上看端到端完成时间、并行度带来的加速比；成本上看平均 token 消耗和高峰期资源占用。建议先用单代理跑一版基线，再用多代理跑同一批任务，对比这三类指标。如果质量和效率没有明显提升，甚至成本更高，就说明当前拆分方式不值得保留，应该回退或重新设计。
Q：在编码场景中，怎样安全地使用子代理而不搞乱代码库？
A：更安全的做法是让子代理承担「辅助角色」，而不是直接并行写核心代码。比如让子代理负责：阅读文档并总结接口、为现有函数写测试、给出重构建议、生成示例用法，而主代理或人工负责最终合并和关键实现。原因在于并行写代码很容易产生隐性冲突，比如不同文件里对同一数据结构的假设不一致。建议为子代理限定只读或局部写权限，并在合并前强制通过统一的测试和代码审查流程。
Q：如何避免多代理系统里任务描述模糊、边界不清的问题？
A：可以给每个代理设计一份「任务卡片」，里面包含四个要素：目标（要达成什么）、输入（可以用哪些信息）、输出（必须产出什么格式的结果）、边界（不该做什么）。在实现上，可以把这四点写进系统提示或工具描述中，并在日志里记录每次调用时的任务卡片内容。这样一旦出现重复工作或职责冲突，可以快速回溯是哪张卡片定义不清，再迭代优化，而不是盲目调参。
Q：多代理系统的成本总是超预算，有没有简单的控制策略？
A：可以从「分层模型 + 预算护栏」两方面入手。分层模型指的是：把流程拆成高价值环节和低价值环节，高价值环节用强模型，低价值环节用小模型或规则引擎；预算护栏则是在系统层面设置每个请求、每个用户、每天的 token 上限，接近上限时自动降级策略，比如减少中间结果的保留、关闭某些非关键子代理。实践中，很多团队通过这两招，就能在不牺牲太多效果的前提下，把成本压到一个可接受区间。
