2 つのエージェント間のハンドシェイク プロトコル

なぜ合意なのか？

s09 では、send_message は任意のコンテンツをアップロードできます。しかし、2 人のエージェントが何かについて合意したい場合（「シャットダウンしたいのですが、いいですか？」など）、文字列を送信するだけでは十分ではありません。

• リクエストには明確な ID (request_id) があるため、レスポンスは正確です。
• ステート マシン: 保留中 → 承認済み |拒否された場合、各州の結果は明らかです。
• 一貫したフィールド: 双方とも approve: true の意味を知っています。

これが、shutdown_request / shutdown_response / plan_approval / plan_approval_response が存在する理由です。

シャットダウンプロトコル全体のプロセス

リードはアリスに仕事を辞めてほしいと思っています:

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 退出循环

シャットダウン FSM の視覚化

ステート マシンの各ステップを監視します。アリスは、「私は重要な仕事をしているので、今はやめられません」と言って拒否することもできます。

計画の承認 · 同じモデル、異なるドメイン

チームメイトは大きな動きを開始する前に計画を提出し、承認を得るために主導してください:

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 ソース コードを見ると、次のことがわかります。2 つのプロトコルはまったく同じ request_id 追跡モードを使用しています - 辞書名が変更されているだけです (shutdown_requests と plan_requests)。これは「1 つのモデル、2 つのドメイン」です。

なぜ汎用の Protocol 基本クラスを抽象化してはいけないのでしょうか? s10 は意図的に抽象的ではありません。理由: 現在プロトコルは 2 つだけであり、抽象化の利点はまだ明らかではありません。 2 つを明示的に記述すると、それぞれを独立して理解できます。 4 番目と 5 番目のプロトコル (3 つのルール) を改良するのに遅すぎることはありません。

{}