兩個 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）。

{}