Team Protocols — 队友之间要有约定

问题

上一篇文章我们介绍了团队 Agent，这样让 Agent 的队友能干活了，但可惜协调是松散的：Lead 发消息，队友回复，没有结构化的协议。两个场景暴露了问题：

关机：Lead 想让 Alice 关机。直接杀线程，Alice 写了一半的文件留在磁盘上。但很显然我们不希望是这样的，应该是Lead 发请求，Alice 确认收尾后关机。
计划审批：Bob 想重构认证模块，属于高风险操作。应该先让 Lead 看 Bob 的计划，审批通过后再动手。

这两个场景结构完全一样：一方发请求，另一方给回复，请求和回复通过同一个 ID 关联。

解决方案

Team Protocols — 队友之间要有约定

上面的 Agent循环我们就不多说了，重点来说说新增的这个新增的通信协议。简单来说，他就是把 Agent 之间的通信内容结构规范化了，就像在 OA 里面我们之间说话没有什么规范可言，想到哪里说到哪里，这样虽然可以沟通了，但效率不高，于是我们规范了一个模板，让所有人对接都按照这套规范来说话和答复。

工作原理

利用id 识别请求

AI 不同于人，人可以自动识别到几个问题抓紧的逻辑对应关系（其实有时候也需要利用回复功能），AI 怎么知道发来这么多消息，到底对应着什么问题和回答呢？答案就是只要是一个问题，整个流程过程中都用同一个 request_id，在下面的示例代码中就可以看到。

@dataclass
class ProtocolState:
    request_id: str      # 唯一 ID，如 "req_004281"
    type: str            # "shutdown" | "plan_approval"
    sender: str          # 发起方
    target: str          # 接收方
    status: str          # pending | approved | rejected
    payload: str         # 计划文本或关机原因
    created_at: float    # 时间戳

pending_requests: dict[str, ProtocolState] = {}

四步协议流程

以关机为例，完整链路：

① Lead 发请求
   req_id = new_request_id()           # "req_004281"
   pending_requests[req_id] = ProtocolState(type="shutdown", status="pending", ...)
   BUS.send("lead", "alice", "shutdown_request", metadata={"request_id": req_id})
② 队友收到 → dispatch
   inbox = BUS.read_inbox("alice")
   msg_type = msg["type"]              # "shutdown_request"
   → 路由到 handle_shutdown_request()
③ 队友回复
   BUS.send("alice", "lead", "shutdown_response",
            metadata={"request_id": req_id, "approve": True})
④ Lead 收响应 → match
   match_response("shutdown_response", req_id, approve=True)
   pending_requests[req_id].status = "approved"

request_id 是贯穿全链路的关联键，请求带着它出去，回复带着它回来。