辅助智能体与智能体团队的核心区别

输入一条提示词：「帮我做一个虚构AI初创公司的落地页。」片刻之后屏幕一分为三。蓝色标记的前端开发智能体、绿色的后端开发智能体、黄色的QA智能体同时苏醒，各自在自己的领域开始工作。接下来发生的事，和辅助智能体截然不同。

前端开发者向后端开发者发送了一条消息。QA智能体向两位开发者发出了修改请求。智能体们在互相对话。

这就是智能体团队（Agent Teams）。

辅助智能体与智能体团队的区别在于沟通结构。辅助智能体是单向的（One-way）。主会话发出提示词后，辅助智能体执行任务，将结果返回主会话。在这个过程中，辅助智能体之间无法沟通。即便并行运行，它们也各自处于隔离状态。

智能体团队是双向的（Two-way）。团队成员之间可以互发消息，可以互相分配任务，共同维护一份共享任务列表。不必经过主会话，成员之间就能直接沟通。

[图26-1] 辅助智能体 vs 智能体团队沟通结构对比：辅助智能体仅有与主会话之间的单向箭头；智能体团队则存在成员间的双向箭头以及共享任务列表

这一结构性差异带来的结果是巨大的。

在辅助智能体架构下，当你请求「重构代码并编写测试」时，主会话分别向重构智能体和测试编写智能体派发任务。两个智能体各自独立完成工作，将各自的结果提交给主会话，由主会话来汇总。

问题在于：重构智能体可能修改了函数签名，而测试编写智能体仍按原有签名来编写测试。它们之间无法对话，也就无从察觉这种不一致。

在智能体团队架构下，情形完全不同。重构智能体修改了函数签名后，可以直接向测试编写智能体发消息：「这个函数的签名已经改了，请留意。」测试编写智能体据此编写出与新接口一致的测试。QA智能体若发现问题，可以直接向相关智能体提出修改请求，无需绕道主会话。

智能体团队中有一个担任团队负责人（Team Lead）角色的主编排器，功能类似项目经理。它负责创建智能体、初始化任务列表、监控整体进度、检查结果质量。但并非所有沟通都要经过这个编排器。团队成员在需要时可以直接沟通。

共享任务列表与相互任务分配

让智能体团队实现协作的核心基础设施，是共享任务列表（Shared Task List）。

主编排器创建智能体团队后，做的第一件事就是构建任务列表。前端开发、后端API实现、测试编写、QA验证等条目一一列出，每个条目都指定了负责人。

这份任务列表是「共享」的，这一点至关重要。所有团队成员都能看到完整的任务列表，完成自己的工作后更新状态，也能查看其他成员的进度。而与辅助智能体有决定性区别的是：团队成员可以向其他成员分配新的任务。

在一次演示中，这个机制展现得淋漓尽致。前端开发者和后端开发者各自完成工作后，将成果交给QA智能体。QA智能体检查代码后发现了3个严重问题，随即将这些问题打回给前端和后端开发者，并分别给他们分配了修复任务。

两位开发者完成修复后再次提交给QA智能体。第二轮检查中，QA智能体判定全部通过。三个严重问题均已解决。

[图26-2] 基于共享任务列表的协作流程：前端、后端完成工作 → QA智能体检查 → 发现3个问题 → 分别分配给各开发者修复 → 二次检查 → 通过

整个过程中，主编排器持续监控全局流程并提供状态更新，但QA智能体要求开发者智能体进行修复的沟通是直接发生的，没有经过主编排器中转。这是团队成员之间的直接沟通。

团队成员通过消息发送工具（Send Message Tool）互相传递消息。在提示词中写明「完成工作后请向前端开发者发送消息」，智能体就会直接把消息发给对应的团队成员。

重构智能体与测试编写智能体的协作场景

通过一个具体场景，来跟踪智能体团队的运作方式。

用户在主会话中提出请求：「把这个模块重构一下，加上测试。」

主会话分析请求，发现需要两个专业领域：重构和测试编写。主会话检索可用智能体，找到重构智能体和测试编写智能体。

如果用辅助智能体方式，流程是这样的：主会话向重构智能体发送「请重构这个模块」的提示词，同时向测试编写智能体发送「请为这个模块编写测试」的提示词。两个智能体并行工作，各自的结果返回主会话，由主会话进行汇总。

重构后的代码可能需要相应调整测试。这个调整要么由主会话亲自完成，要么需要再次调用测试编写智能体。

如果用智能体团队方式，流程就不一样了。主编排器组建一个「重构 + 测试」团队，创建共享任务列表。

重构智能体先开始工作：提取函数、重命名变量、整理接口。完成后向测试编写智能体发消息：「重构已完成，变更后的函数签名如下。」测试编写智能体根据这些信息编写测试，产出的测试精确反映了变更后的接口。

如果测试运行后有部分未通过呢？测试编写智能体可以向重构智能体发消息：「这个函数的返回类型与文档不符，请确认。」重构智能体核查后做出修改，再次运行测试。这种往返迭代在团队内部自行完成。

[图26-3] 智能体团队协作场景详细流程：重构智能体工作 → 向测试智能体传递变更内容 → 编写测试 → 失败时向重构智能体反馈修改意见 → 修改 → 重新测试 → 通过 → 向主编排器报告完成

使用T-Mux终端时，可以直观地观察这个过程。屏幕分割显示各智能体的工作进展。蓝色智能体在重构代码的同时，绿色智能体处于等待状态；收到消息的瞬间，绿色智能体立即开始编写测试。这些都能实时看到。需要的话，还可以直接向某个智能体发送消息，给出额外指令。

构建智能体团队时应遵循的架构原则

智能体团队很强大，但如果构建不当，结果可能是成本高昂、产出混乱。以下是组建团队时应遵守的原则。

明确角色：为每个智能体划定专属领域

团队中的每个智能体都应拥有自己专属的文件和专属的产出物。多个智能体修改同一个文件，就有互相覆盖的风险。在提示词中明确指定：前端开发者只修改前端文件，后端开发者只修改后端文件。

产出物的定义也要具体。「写出好代码」太模糊；「实现REST API端点，并在/tests/文件夹中为每个端点生成对应的测试文件」才算清晰。要让智能体明确知道该产出什么、存放在哪里。

沟通协议：设计谁在什么时候对谁说话

智能体之间能够自由对话，不等于可以不设计沟通结构。在提示词中显式定义沟通流程，效果要好得多。

「后端开发完成后，请将API规格传递给前端开发者。」「所有开发完成后，请将成果提交给QA智能体。」「QA发现问题时，请向相关文件的负责智能体提出修改请求。」这样显式指定后，智能体就能理解依赖关系，按正确的顺序推进工作。

指定接收方时用名字也很重要。「发给其他智能体」太模糊，「发给前端开发者智能体」才准确。

防止冲突：确保智能体之间不互相干扰

文件所有权前面已经提到。除此之外还有几种防冲突策略。

权限预授权：如果智能体每次都因权限确认而中断，整个工作流就会变慢。在项目配置或本机配置中预先批准特定命令，工作就能顺畅进行。团队成员继承主会话的权限，所以在主会话中设置绕过模式（Bypass Mode），所有成员就拥有相同的权限。

计划审批模式（Plan Approval Mode）：可以设定团队成员在开始工作前先制定计划，由主编排器审批后才执行。初期建议由用户亲自审批每份计划；等熟悉了团队的运作方式后，再把审批权委托给主会话，这样比较实际。把团队中的某一个成员指定为计划审核与审批的专职角色，也是可行的方案。

优雅关闭（Graceful Shutdown）：任务结束后，主编排器会向每位成员发送关闭请求：「请保存工作并退出。」成员如果还有未完成的任务，可以回复「我还没做完」。等所有成员确认完成后，团队才会解散。强制关闭可能导致工作处于未清理状态，所以走正常关闭流程更安全。

团队规模与成本

智能体团队的每位成员都运行独立的会话。3个智能体，成本大约是3倍；5个就是5倍。

建议的团队规模是3到5人。超过10人的大规模智能体集群（Swarm），成本会急剧攀升，协调复杂度也随之成比例增长。

[表 25-1] 智能体团队适用性判断标准

如果任务可以按顺序处理，辅助智能体就够了。智能体之间不需要沟通的话，辅助智能体反而更好。如果多个智能体需要修改同一个文件，无论是智能体团队还是辅助智能体，都需要重新设计架构。

智能体团队配置方法

智能体团队是实验性功能（Experimental Feature），默认处于关闭状态。要启用它，需要在项目的 .claude/settings.local.json 中添加环境变量。从 Claude Code 官方文档的智能体团队页面复制相应的 JSON，粘贴到配置文件中即可。

调用智能体团队的提示词结构遵循以下模式。

1. 目标设定：明确整个团队需要达成的目标。成员被唤醒时没有任何上下文，所以主会话必须清晰地传达目标。2. 团队组建：类似「用 Sonnet 模型组建一个3人团队」这样，指定团队规模和模型。3. 角色定义：具体描述每位成员的角色、负责领域和沟通对象。4.

最终产出物定义：明确主会话期望从团队工作中获得的最终交付物。

[图 26-4] 智能体团队提示词结构：目标 → 团队组建 → 各角色指令（含沟通对象） → 最终产出物定义]

在 T-Mux 终端中运行智能体团队时，可以通过分屏实时观察每个智能体的工作状态。一旦发现某个智能体走偏了方向，可以及早终止，避免不必要的成本浪费。IDE 扩展无法详细查看智能体的内部思考过程，因此对于复杂的智能体团队任务，T-Mux 环境更合适。

辅助智能体是在主会话指挥下独立工作的专家。智能体团队是朝着共同目标相互沟通、协作的团队。两者都是强大的工具，但适用场景不同。需要快速高效地委派任务时选辅助智能体，面对复杂的相互依赖关系和高质量要求时选智能体团队。

根据实际情况灵活组合这两种架构，是 Claude Code 操作者的核心能力，也是将技能与智能体串联起来、设计工作流的下一步基础。

人工智能专家 金京镇律师

AI法律政策专家 · 前国会议员 · 著有多部作品

如果这本书曾在您身边短暂停留，请支持我们，让下一个故事得以问世。

（自愿赞助账户：农协 302-1096-0948-81 户名：金京镇）