LEARN CLAUDE CODE
S10: Team Protocols — request-response 协议
问题：缺少结构化握手
S09 的 MessageBus 可以传递任意消息，但某些关键操作需要结构化的请求-响应模式。两个典型场景：
- 优雅关机：Lead 想关掉一个 Teammate，但不能直接杀进程——队友可能正在写文件。需要一个"请求关机 → 确认关机"的握手。
- 计划审批：Teammate 制定了一个执行计划，需要 Lead 审核通过才能执行。需要一个"提交计划 → 批准/拒绝"的握手。
没有协议时的混乱：
Lead: "请关闭"
Teammate: (正在写文件，没看到消息)
Lead: (等了10秒) "关了没？"
Teammate: "还没，我在写文件"
Lead: "好的等你"
Teammate: "好了，可以关了"
Lead: "那关吧"
── 纯文本通信，没有状态追踪，容易出错 ──
有协议时的精确：
Lead → shutdown_request(id=req-001)
Teammate: 完成当前操作
Teammate → shutdown_response(correlation_id=req-001, status=done)
Lead: 确认关闭，清理资源
解法：Correlation ID + FSM
两个协议（关机和计划审批）使用完全相同的模式：
- 请求方发送一条带有唯一
correlation_id的请求消息 - 请求方在本地创建一个有限状态机（FSM），初始状态为
pending - 响应方收到请求后处理，发回带有相同
correlation_id的响应 - 请求方根据响应内容将 FSM 转换为
approved、rejected或done
Correlation ID + FSM 模式：
Lead (请求方) Teammate (响应方)
│ │
│ shutdown_request │
│ { correlation_id: "req-001" } │
│ ──────────────────────────────────► │
│ │
FSM: pending 收到请求
│ 完成手头工作
│ │
│ shutdown_response │
│ { correlation_id: "req-001", │
│ status: "done" } │
│ ◄────────────────────────────────── │
│ │
FSM: pending → done 进程退出
│
确认关闭，清理资源
┌─────────┐ 收到响应(approved) ┌──────────┐
│ pending │ ────────────────────► │ approved │
└─────────┘ └──────────┘
│ 收到响应(rejected) ┌──────────┐
└──────────────────────────► │ rejected │
└──────────┘
两个协议的统一模式
| 维度 | 关机协议 | 计划审批协议 |
|---|---|---|
| 请求消息类型 | shutdown_request | plan_approval_request |
| 响应消息类型 | shutdown_response | plan_approval_response |
| 请求方 | Lead | Teammate |
| 响应方 | Teammate | Lead |
| FSM 终态 | done | approved / rejected |
| 超时处理 | 强制终止 | 默认拒绝 |
| 关键保证 | 队友有机会完成手头任务 | 危险操作必须 Lead 审批 |
对比：无协议 vs 有协议
| 维度 | 纯文本消息（S09） | 结构化协议（S10） |
|---|---|---|
| 关联性 | 没有——不知道回复对应哪个请求 | correlation_id 精确关联 |
| 状态追踪 | 靠 LLM 记忆 | FSM 确定性追踪 |
| 超时 | 无法检测 | FSM 可设置超时自动转态 |
| 可靠性 | 依赖 LLM 正确解析自然语言 | 结构化 JSON，机器可解析 |
对应官方工具
SendMessageTool 的结构化消息类型
官方 SendMessageTool 不仅支持普通文本消息，还内置了结构化消息类型。shutdown_request、shutdown_response、plan_approval_response 等都是 SendMessageTool 的消息类型参数。协议逻辑（correlation ID 匹配、状态转换）由框架自动处理。
关键洞察：Correlation ID + FSM 是分布式系统的经典模式——和微服务里的 Saga 模式、数据库的两阶段提交本质相同。在 AI 代理系统中引入这个模式，意味着多代理协作不再依赖 LLM 的"理解能力"，而是靠确定性的状态机保证正确性。