视频 06 来源笔记：Agent Team 团队协作

来源元信息

• 讲者：小单说AI
• Bilibili：BV1Jx5h6oEzV
• 本地字幕：从零实现自己的agent第六期：Agent Team团队协作.ai-zh.srt
• 字幕覆盖：00:00:00–00:09:39
• 对照材料：bilibili-transcripts/06-Agent-Team团队协作.txt、ppt/第六期-agent团队协作.html
• 对应代码：step10_agent_team.py

按时间顺序的主题窗口

[00:00:00–00:01:08] 从临时派工到持续协作

Subagent 适合一次性探索，但 coder 写、reviewer 审、coder 再改的流程需要固定角色反复通信。Agent Team 解决的是持续组织，而不是一次调用隔离。

[00:01:08–00:01:49] 生命周期差异

Subagent 执行完即销毁；Team 成员被招入后完成当前任务会进入空闲，之后仍可收消息。成熟系统可以同时拥有临时子代理和长期团队。

[00:01:49–00:02:27] 团队的三个必要部分

总控理解目标、拆分和汇总；固定成员各自在独立循环工作；通信机制负责消息传递。仅仅调用多个模型不能称为团队。

[00:02:27–00:03:17] 文件收件箱

教学实现为每个成员使用一个 JSON 文件：发送是追加消息，读取是解析后清空。消息含类型、发送者、内容和时间戳。

[00:03:17–00:04:06] 成员花名册与状态

配置文件记录名称、角色和 working / idle / shutdown / offline。重启时原先的运行线程不复存在，因此需要把旧成员标为离线并显式召回。

[00:04:06–00:04:33] 队友循环

成员读取 Inbox，把消息加入自己的上下文，调用模型与工具完成任务，给总控回报，将状态改回空闲，再等待下一条消息。

[00:04:33–00:05:15] 五个团队工具

spawn_teammate 召入成员，list_teammates 查状态，send_message 单发，read_inbox 收回报，broadcast 群发。总控由此获得显式调度能力。

[00:05:15–00:05:59] 四层结构

总控、固定队友、团队花名册和消息总线共同构成 Team。身份、状态、通信和调度缺一不可。

[00:05:59–00:07:00] 一次完整闭环

用户要求 Alice 编码、Bob 审查；总控召入两人并登记；Alice 写文件并回报；总控再派 Bob；Bob 审核后回报；总控向用户汇总。

[00:07:00–00:08:20] 运行演示

日志依序显示招募、发消息、写文件、审查、读取 Inbox 和最终报告。状态与消息让整个协作链路可以被观察。

[00:08:20–00:08:37] 解散团队

总控查看状态后关闭成员。关闭不仅是提示词动作，还应终止线程、持久化状态并处理未读消息。

[00:08:37–00:09:39] 仓库与项目入口

视频指向 step10_agent_team.py、对应文档、PPT 和 Emperor Agent。固定仓库已把录制时的“09”顺序推进为累计 Step 10。

主教学论点

多 Agent 的关键不是模型数量，而是组织协议：谁负责什么、当前是什么状态、消息如何传、谁能调度、失败如何收敛。Agent Team 是带身份和生命周期的状态系统。

状态与消息流

offline → spawn → idle → message queued → working → report → idle
                                      └─ failure → report(error) → idle
idle/working → shutdown_requested → shutdown

消息至少需要 message_id、发送者、接收者、类型、内容、创建时间和处理状态。生产系统还应有幂等键、确认、重试与死信处理。

演示序列

1. 召入 alice/coder 与 bob/reviewer。
2. 查看配置中两人的身份和状态。
3. 给 Alice 发编码消息。
4. Alice 写文件并回报，状态回到 idle。
5. 总控把产物交给 Bob 审核。
6. Bob 返回证据，总控汇总。
7. 查看未读消息与成员状态，再解散。

术语与纠正

• 自动字幕中的 configure.json 对应团队配置；具体文件名以固定代码为准。
• worker 的口述应理解为状态 working。
• “read = 读取后清空”是教学实现，不等同于可靠消息队列的消费确认。
• 仓库当前是 step10_agent_team.py，视频画面中的 09 是早期编号。

需要工程限定的说法

• 读取后立即清空可能在进程崩溃时丢消息，也会有并发读写竞争。
• 文件 Inbox 适合单机教学，不适合多进程或跨机器协作。
• 固定成员的上下文会长期增长，需要各自的压缩、预算和权限。
• reviewer 的自然语言“通过”不是确定性审核；代码应再跑测试与静态检查。
• 多 Agent 可能放大错误和成本，只有可分解、可验证的任务才可能受益。

来源映射

• CAE：step10_agent_team.py、doc/step10_agent_team.md。
• 《深入理解 AI Agent》：第 10 章协作分类、管理者模式、通信控制和失败模式；第 4 章异步 Agent。
• 必做实验：chapter10/staged-system-prompt、chapter10/parallel-web-research。
• Mini Emperor：当前项目尚未实现持久 Team；可复用 AgentEvent 设计团队事件，并将 GitLab ReviewAgent/VerifierAgent 作为双角色协作案例。
• 进入正文：book/06-Agent-Team.md。

内容差异与待核对

• PPT 比视频更明确地把结构拆为“总控、收件箱、状态机、持久线程、团队工具、运行链路”。
• 仓库文本稿说“解析后清空”，未说明原子性；正文必须把这是教学简化写清楚。
• 视频演示的 coder/reviewer 流程与用户要求的 GitLab MR 自动审核高度相关，但后者还需要 CI 身份、证据行号和合并门禁。