بروتوكول تفاوض بين وكيلين

لماذا نحتاج بروتوكولات؟

في s09 يستطيع send_message نقل أي محتوى. لكن حين يحتاج وكيلان التوافق على أمر محدد (مثل «أريد إيقاف التشغيل، هل تقبل؟»)، إرسال نص مجرد لا يكفي — أنت تحتاج:

• هوية واضحة للطلب (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

شاهد آلة الحالة تسير خطوة بخطوة. يمكن لـ alice أيضاً الرفض — بأن تقول «أنا في مهمة حرجة، لا أستطيع الإيقاف الآن».

Plan Approval · النمط ذاته في مجال مختلف

يُقدّم teammate خطة للموافقة قبل إجراء تغييرات كبيرة:

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 الآن، نخطط لإعادة بنية شاملة الشهر القادم")

إن راجعت كود s10 ستجد: كلا البروتوكولين يستخدمان نفس نمط تتبع request_id — مع اختلاف اسم القاموس فقط (shutdown_requests مقابل plan_requests). هذا هو «نمط واحد، مجالان».

لماذا لا نستخرج قاعدة Protocol مجردة؟ s10 يتعمد عدم الاستخراج. السبب: الآن بروتوكولان فقط، فائدة الاستخراج غير واضحة؛ كتابة نسختين مستقلتين أسهل فهماً لكل منهما. حين يصل العدد إلى الرابع والخامس يكون التنقيح مناسباً (rule of three).

{}