兩個 agent 之間的握手協議

為什麼要協議？

s09 裡 send_message 就能傳任何內容。但兩個 agent 要關於某件事達成共識（例如 "我要關機了，可以嗎？"）時，光發字符串不夠——你需要：

• 請求有明確身分（request_id），這樣回應能對號入座。
• 狀態機：pending → approved | rejected，每個狀態的後果清晰。
• 一致的欄位：雙方都知道 approve: true 意味著什麼。

這就是 shutdown_request / shutdown_response / plan_approval / plan_approval_response 存在的原因。

Shutdown 協定全流程

lead 想讓 alice 下班：

lead:
  # 发 shutdown_request，服务端记 request_id
  req_id = uuid4()[:8]
  shutdown_requests[req_id] = {"target": "alice", "status": "pending"}
  send("alice", "shutdown_request", extra={"request_id": req_id})

alice:
  # 下轮 loop 读邮箱，看到 shutdown_request
  # 决定：做完手头的活再回，approve 一下
  tool_use("shutdown_response", request_id=req_id, approve=True)

lead:
  # 收到 shutdown_response，更新 tracker 到 approved
  shutdown_requests[req_id]["status"] = "approved"
  # alice 线程自己检测到 shutdown 接受，设 status=shutdown 退出循环

Shutdown FSM 視覺化

看狀態機走每一步。 alice 還可以 reject——說「我在做關鍵工作，現在不能停」。

Plan Approval · 同樣的模式，不同的域

teammate 在開大動作前提交 plan 請 lead 核准：

alice:
  tool_use("plan_approval", plan="我打算把 auth 模块全部用 jwt 重写")
  # alice 继续 idle 等 lead

lead:
  # 看到 alice 的 plan_approval_response 请求
  tool_use("plan_approval", request_id="...", approve=False,
           feedback="先别动 auth，我们下月要做整体 refactor")

看 s10 原始碼會發現：兩個協定用的是完全相同的 request_id 追蹤模式－只是換了字典名（shutdown_requests vs plan_requests）。這就是「一個模式，兩個域」。

為什麼不抽像出一個通用 Protocol 基底類別？ s10 刻意不抽象。原因：現在只有兩個協議，抽象的收益還不明顯；明確寫兩份每個都能獨立理解。等有了第四、第五項協議再提煉也不遲（rule of three）。

{}