10 -- Agent Team：从指令驱动到"任务自治"的组织飞跃
自己查自己的死结
子代理是下属：做完就走。但"做完就走"解决不了一个结构性问题------
Agent 写代码 --> Agent 审自己 --> "看起来不错"
Coder 写代码 --> Reviewer 审 --> "第 42 行空指针" --> Coder 修复同一个模型写代码又审代码，确认偏见无解。更深层地说，单一 agent 找到支持证据就停下，不会主动寻找反驳自己的证据。 多个独立调查者互相挑战，才能收敛到真相。
子代理做不到。第 05 章的三条结构性限制封死了这条路：
- 临时性------做完销毁，无法自主认领下一个任务。
- 单向通信------只能返回结果给调用者，A 不能告诉 B "你的 schema 有问题"。
- 无角色身份------没有名字，无法实现 Coder + Reviewer 的角色博弈。
子代理是下属。我们需要的是同事------有名字、能互相交流、会主动找活干。
从命令到自组织
Agent Teams 不仅仅是多了几个 Agent，而是部署了一个网状结构的自组织系统。"Team" 本身成为了核心单元，而不是某个具体的 Agent：
- Lead (Main Agent) 转型为架构师 。它的工作不再是"盯着干活"，而是"搭建系统"：初始化 Shared Task List ，招募 Teammates，注入初始目标，然后退后。
- Shared Task List 成为团队的心脏。它接管了调度权。Lead 不需要给每个 Teammate 派活，Teammate 是对着 Task List 工作（Self-Assigned）。
- Teammates 形成协作网络。它们不仅能看到任务，还能看到彼此。Teammate A 可以告诉 Teammate B "你的代码我看过了"，而不需要经过 Lead 传话。
在 Team 模式下，Lead Agent 即使离线（或去处理其他用户请求），这个 Team 依然能作为一个独立的、拥有持久化状态的实体继续运转，直到 Task List 被清空。
子代理还是队友：一个判据
| 维度 | 子代理 | 队友 |
|---|---|---|
| 生命周期 | 做完即销毁 | 持续运行，主动找活 |
| 通信 | 单向返回结果 | 双向 inbox，自由通信 |
| 任务获取 | 被动：被告知做什么 | 主动：扫描 Task Board 认领 |
| 身份 | 匿名，用完即弃 | 有名字、角色、持久记忆 |
判据：这些 agent 之间需要对话吗？
- "读这个文件总结一下"------子代理。单人任务，做完就走。
- "三个人分别从安全、性能、测试覆盖三个角度审查同一个 PR"------团队。审查者之间需要互相看到对方的发现，交叉验证。
两者可以共存：Lead 随时可以派子代理做快速探索，再把结果通过 inbox 传给队友。
不销毁的 agent：Active-Idle-Shutdown
子代理是线性的：spawn、execute、destroy。Teammate 是循环状态机------做完不走，等下一件事。
spawn
当前任务完成
新消息 / 认领到任务
shutdown_request / 空闲超时 / abort
使用工具、调用模型、完成任务
每 2s 检查 inbox 和 Task Board
释放持有的任务，退出
Active 就是普通 agent 循环。Idle 是 Teammate 与子代理的本质区别：任务完成后不销毁，有事就重新进入 Active。Shutdown 有三种触发------Lead 发 shutdown_request、空闲超过 60 秒、外部 abort 信号。
无论哪种退出方式，Teammate 都会把 in_progress 的任务回退为 pending，让其他队友认领。崩溃不会让任务永远卡住。
Inbox：持久化的消息信箱
每个队友有一个以自己名字命名的信箱，Lead 也有。通信不是函数调用，不是共享内存------而是持久化存储上的读写。
为什么？进程隔离、可观察性、崩溃恢复，一个机制同时满足。每个 Teammate 在独立上下文中运行，持久化存储天然解耦------不需要传递对象引用，哪怕未来拆成独立进程，通信协议零改动。信箱本身就是人类可读的通信日志；进程崩溃时，未读消息仍在存储里。
消息分四种：message（点对点）、broadcast（一对多）、shutdown_request（Lead 请求关闭）、shutdown_response（队友确认关闭）。前两种承载业务协作，后两种管理生命周期。
Task Board：从个人看板到共享任务池
第 08 篇的 Task Board 在团队模式下获得全新角色：所有 Teammates 共享的任务池，无需中央调度器。
Lead 把大任务拆解成多个 Task，声明好依赖关系，放到 Task Board 上。之后 Lead 不再分配------Teammates 在 Idle 阶段自动扫描，寻找同时满足三个条件的任务：pending + 无 owner + 无阻塞依赖。
认领使用"读-检-写"模式最小化竞态窗口：先读任务列表找到候选，再读一次确认未被认领，然后写入 owner。不需要锁，竞态概率被压到极低。
完成一个任务后，第 08 篇的依赖解锁机制自动释放下游。其他 Teammate 在下一次 Idle 轮询时发现新任务------流水线自动流转。三个角色各安其位：Lead 负责拆，Task Board 负责调度，Teammate 负责做。
身份注入：压缩不能抹掉"我是谁"
第 07 篇的自动摘要可能压缩掉队友的身份信息------名字、团队、通信能力。丢了身份，Inbox 和 Task Board 全部失效。
解决方案和 Task Board 注入（第 08 篇）如出一辙------中间件在每次推理前重新注入：
[Teammate Identity]
你是团队 "api-migration" 中的队友 "backend-dev"。
你可以给特定队友发消息，也可以向全体广播。
你可以创建、更新、查看共享任务。无论上下文怎么被压缩，这段身份提示每轮可见。
两个设计陷阱
Spawn 时给足上下文
队友没有 Lead 的对话历史，Spawn prompt 是它获取上下文的唯一渠道：
差: "你是后端开发者"
好: "你是后端开发者。项目使用 XX 框架 + YY 语言，
数据库是 ZZ。当前任务是把用户接口从旧协议
迁移到新协议。接口定义文件在 <具体路径>。"文件冲突：多 agent 的静默杀手
两个队友同时编辑同一个文件------没有锁、没有 merge，后写入的直接覆盖先写入的，静默丢失，零报错。
预防方式是在任务拆分阶段按文件或模块划好边界。如果多人确实需要修改同一个文件，设置依赖关系让它们串行执行。
团队的独特优势：竞争性假设验证
最能体现团队不可替代性的是科学辩论结构：多个 agent 各持一个假设独立调查，通过 inbox 交叉验证，收敛到真正的根因。
用户: "生产环境 API 响应时间从 200ms 飙到 3s，找原因"
Lead 拆分任务 (无依赖, 全部并行):
#1 "假设: 数据库查询变慢了" --> db-investigator
#2 "假设: 内存泄漏导致 GC" --> memory-investigator
#3 "假设: 上游服务超时" --> network-investigator
db-investigator:
--> 查慢查询日志 --> 发现全表扫描
--> 广播: "发现 users 表缺少索引"
network-investigator:
--> 检查上游 --> 无异常
--> 发消息给 db-investigator:
"上游正常, 全表扫描很可能是根因,
请检查是不是最近的 migration 删了索引"
db-investigator:
--> 检查 migration 历史 --> 确认: 昨天的 migration
误删了 email 字段的索引单 agent 顺序调查，发现全表扫描就会报告"找到原因了"------不会验证是不是根因。团队模式下，network-investigator 排除了网络因素后，主动提示 db-investigator 深挖索引变更，最终收敛到真正的根因。
协作全景：所有机制串联
用户: "把旧版接口迁移到新协议"
Lead: 建团队 api-migration, 拆任务 #1~#4(含依赖), 招 3 个队友, 然后不再干活
api-designer: 认领 #1 --> 完成 --> #2,#3 解锁
backend-dev & frontend-dev: 并行认领 #2,#3 --> frontend-dev 发消息确认兼容性
backend-dev: 收到消息 --> 认领 #4 --> 完成集成测试
Lead: 确认全部完成 --> 解散团队 --> 交付用户Lead 全程三件事：建团队、拆任务、招队友。认领、执行、队友间通信、依赖解锁全部自动流转，不需要逐人调度。
终章：回顾旅程
十篇教程，回答了一条递进的问题链------每一步解决上一步暴露的瓶颈：
01 模型路由 "用什么模型？"
| --> 但不能和环境交互
02 Shell 工具 "怎么让模型看到真实世界？"
| --> 但只能执行一次
03 循环闭环 "怎么让模型自己试错？"
| --> 但轮次多了会忘记目标
04 Todo 计划 "怎么防止注意力漂移？"
| --> 但所有工作挤在同一个上下文里
05 子代理 "怎么隔离上下文噪音？"
| --> 但复杂操作每次都要从零推理
06 技能系统 "怎么避免重复推理？"
| --> 但上下文窗口终会被填满
07 记忆管理 "窗口满了怎么办？"
| --> 但压缩会摧毁会话中的 TodoList
08 任务看板 "怎么让状态不丢？"
| --> 但任务只能串行执行
09 后台执行 "怎么并行？"
| --> 但单 agent 自己审计自己会有盲区
10 多 Agent "怎么互相审查？"
--> 多角色协作，从独奏到交响乐这条链告诉我们：构建可靠的 AI Agent 不是一个"设计"问题，而是一个"演进"问题。 从最简单的 while 循环开始，让真实场景中的问题推着你往前走。
十篇教程中反复出现的设计模式，构成了 Agent 工程的设计原语：
- 中间件注入------不能丢失的状态，每轮推理前重新注入
- 持久化存储作为共享状态------对话历史私有，存储共享
- 推送优于轮询------完成时主动通知，而非被动查询
- 乐观并发------不用重锁，用"读-检-写"最小化竞态窗口
- 优雅降级------崩溃时释放资源而非永久占用
认出它们，就掌握了 Agent 工程的骨架。
全系列的核心信念在此得到最终验证：Model IS the Agent。 我们写的每一行代码都不是在让系统"变聪明"------模型本身就是智能的来源。路由、工具、循环、压缩、任务、团队------都是脚手架：给它合适的工具、控制上下文的质量、在它偏航时拉回来、让多个实例互相校验。
全部架构，归根结底回答一个问题：如何让模型在正确的约束下，发挥出最大的能力？