智能体团队

Agent 团队让多个成员在各自的上下文中协作，完成一个目标。共享任务表记录归属和进度，消息传递成员之间需要的信息。任务完成不会自动更新其他成员的理解；接口变化仍需传达给使用它的成员。

可以把它看成三名工程师，各有一本笔记，共用一块任务板。勾选“构建 API”只说明工作完成，并没有告诉别人响应字段已从 name 改成 display_name。连接页面前，前端需要知道这个变化。

适合并行的工作可以交给不同成员，同时安排信息交换。本例中 API 和页面布局可以并行，数据绑定要等两者完成。增加成员不能消除这项依赖。

智能体团队如何工作

负责人 Lead 协调目标，Backend 负责 API，Frontend 负责页面。每个成员的私有上下文保存自己的任务和已收到的证据。任务板独立记录任务、负责人、前置条件和状态；认领机制避免两个成员认领同一项任务。

邮箱是另一处信息存放位置。后端可以把接口契约直接发给前端。消息先进入前端邮箱，送入上下文后才能供下一步决策使用。发送者不必等接收者用完这些信息。

Claude Code 的文档介绍了成员私有上下文、共享任务、接收者邮箱和自动送达机制。本课用预先编排的执行顺序展示它们，不是 Claude 选择任务或生成代码的录制。Agent 团队官方文档

本例有三个任务：

前两个任务可以并行，第三个要等两者完成。依赖关系决定任务何时可以开始，却不会把接口契约写入前端上下文。

逐步演示

默认选择发送更新（Send update），API 字段为 display_name。前端已有的契约使用 name，目标页面应显示 Ada。

分配任务

负责人收到个人资料页面的目标。后端收到使用 display_name 构建 API 的任务；前端收到布局和绑定任务，以及已有的 name 契约。两者上下文独立，后端收到新字段不会自动替换前端记录。

负责人创建三个任务。后端认领 t1，前端认领 t2，两项任务进入进行中状态。任务开始前，认领操作为每项任务确定一个负责人。

完成 API，发送接口契约

后端生成 {"display_name":"Ada"}，把 t1 标为完成。前端仍在制作布局。此刻，任务板显示 t1 完成，前端邮箱为空，上下文中的字段仍是 name。

后端发送一条消息，说明 API 字段是 display_name。消息进入前端邮箱，不经过负责人上下文。消息还在邮箱中等待时，前端上下文仍保留旧字段。

前端完成布局，把 t2 标为完成。两个前置任务都已结束，t3 现在可以开始。在模拟的下一个轮次边界，消息自动送入前端上下文，已知字段从 name 改为 display_name，邮箱清空。这里的送达时点是示意，不是模型延迟测量。

构建绑定，验证结果

前端认领 t3，根据自己上下文中的字段构建读取 response.display_name 的绑定，再把 t3 标为完成。任务板已有三项完成记录，但集成结果尚未验证。

前端把实际绑定键报告给负责人。报告先进入负责人邮箱，再进入上下文。负责人结合报告和 API 产物执行读取：用 display_name 读取 {"display_name":"Ada"}，得到 Ada。个人资料预览此时才显示这个值。检查前，姓名栏保持空白，因为构建绑定不等于验证结果。

结束时成员处于空闲状态，上下文仍保留，可以继续接受任务。完成一项任务不等于关闭会话。

为什么任务全部完成，集成仍会失败

保持 display_name，切换到仅更新状态（Status only）；也可以选择契约已过期（Stale contract）场景，跳到检查步骤。这个对照移除了后端发给前端的接口消息，任务、归属、依赖和 API 响应均不变。前端仍向负责人报告结果，但报告中的绑定键取自前端当前的上下文。

前端到达接收边界时，邮箱为空。这种策略也不读取 API 产物，因此已知字段仍是 name。它构建 response.name，完成任务。负责人用这个键读取 {"display_name":"Ada"}，找不到对应属性。

三项任务全都完成，预览却显示姓名不可用（Name unavailable）。完成状态证明记录中的工作单元结束，不能证明独立产出的两个结果相互兼容。

保持仅更新状态，把 API 字段改为 name，集成就会通过，因为响应仍符合前端原有契约。这个对照说明：接口未变时成功，不能证明协调策略能处理接口变化。

设计协作流程时，要确定哪些信息需要跨越任务边界。可以发送消息、读取共享产物、把契约写进任务说明，或让负责人转达。本例失败路径省略了这些方式，展示的是信息缺失，并非 Agent 无法检查共享文件。

何时值得使用团队

成员能各自负责一部分，又需要交流发现时，团队较合适，例如同时修改 API 和页面，或分别审查设计的不同部分。只需返回单个结果的任务可以交给子 Agent。若任务逐项依赖，或所有人都要编辑同一个文件，单个会话通常更省协调工作。独立上下文也增加词元成本；本动画没有测量成本或加速效果。使用场景与取舍

拆分前，列出每个使用方需要的信息。本例的交接应说明读取哪个字段、给出响应示例，并指出哪个使用方要修改。同时，为集成检查指定负责人。若前端仍假设字段是 name，一句“API 完成了”与任务完成标记留下的信息缺口相同。

边界情况

• 邮箱为空。 没有更新，已知字段就不变。模拟器不会从完成状态推断 display_name。
• 只完成一个前置任务。 即使 t1 完成，只要 t2 未完成，t3 仍不能开始。
• 重复认领。 一个任务已有负责人后，模拟器拒绝第二次认领。但实际项目中，不同任务仍可能写同一个文件，需要单独协调文件归属。
• 消息发给其他人。 发给 Frontend 的消息不会更新 Lead 的上下文；发给 Lead 的报告也不会更新 Backend 的上下文。
• 重复送达。 本模型不会把已经消费过的消息 ID 再次写入接收者上下文。
• 契约不变。 字段仍是 name 时，仅更新状态策略也能通过；此时发送更新不会改变输出值。

常见错误

• 把任务板当成完整共享记忆。 状态说明哪些工作结束，不包含其他成员工作的全部细节。
• 把发送消息当成理解消息。 消息排队与进入上下文是不同状态；即使已经收到，也不能保证实际 Agent 会正确使用。
• 所有消息都经过负责人。 成员可以直接交换接口细节，无需把双方全部对话复制给协调者。
• 用增加成员解决信息缺失。 新成员同样需要前置信息。应拆分独立工作，并明确交换哪些信息。
• 省略集成检查。 独立任务可能产出不兼容的结果。确认整体目标完成前，要把产物放在一起验证。

本课的简化

本课是确定性演示，不能代替正式培训或所用 Agent 运行时的文档。任务、分工和顺序均已编排。浏览器计算认领、依赖检查、邮箱送达、上下文更新、响应对象、绑定和集成读取，不运行 LLM。实际 Agent 可能读取产物或提问，不一定遵循这里的顺序。演示省略送达失败、重试、权限检查、文件冲突和会话关闭处理。播放时间不代表模型执行时间，也不能证明加速效果。