Protocolo de apretón de manos entre dos agentes

¿Por qué un acuerdo?

En s09, send_message puede enviar cualquier contenido. Pero cuando dos agentes quieren llegar a un consenso sobre algo (como "Quiero cerrar, ¿puedo?"), simplemente enviar una cadena no es suficiente: necesitas:

• La solicitud tiene una identidad clara (request_id) para que la respuesta sea precisa.
• Máquina de estados: pendiente → aprobado | rechazadas, las consecuencias de cada estado son claras.
• Campos coherentes: ambas partes saben lo que significa aprobar: verdadero.

Esta es la razón por la que existe shutdown_request / shutdown_response / plan_approval / plan_approval_response.

Protocolo de apagado de todo el proceso

El líder quiere que Alice salga del trabajo:

cliente potencial:
  # Enviar Shutdown_request, el servidor registra request_id
  req_id = uuid4()[:8]
  Shutdown_requests[req_id] = {"objetivo": "alice", "status": "pendiente"}
  enviar("alice", "shutdown_request", extra={"request_id": req_id})

Alicia:
  # Lea el buzón en el siguiente bucle y vea Shutdown_request
  # Decisión: terminar el trabajo en cuestión antes de regresar y aprobar
  tool_use("shutdown_response", request_id=req_id, aprobar=Verdadero)

plomo:
  # Recibir respuesta_desconexión, actualizar el rastreador a aprobado
  Shutdown_requests[req_id]["status"] = "aprobado"
  # El subproceso alice detecta la aceptación del cierre y establece status=shutdown para salir del bucle

Apagar visualización FSM

Observa cada paso de la máquina de estados. Alice también puede rechazarlo diciendo: "Estoy haciendo un trabajo crítico y no puedo parar ahora".

Aprobación del Plan · Mismo modelo, diferente dominio

Un compañero de equipo envía un plan antes de lanzar un gran movimiento y solicita su aprobación:

alicia:
  tool_use("plan_approval", plan="Planeo reescribir todos los módulos de autenticación con jwt")
  # alice continúa inactiva y espera una pista

plomo:
  # Ver la solicitud plan_approval_response de Alice
  tool_use("plan_approval", request_id="...", aprobar=Falso,
           feedback="No toques la autenticación todavía, haremos una refactorización general el próximo mes")

Si observa el código fuente del s10, encontrará: Los dos protocolos utilizan exactamente el mismo modo de seguimiento request_id: solo se cambian los nombres del diccionario (shutdown_requests vs plan_requests). Se trata de "un modelo, dos dominios".

¿Por qué no abstraer una clase base de protocolo genérica? s10 no es deliberadamente abstracto. Motivo: ahora solo existen dos protocolos y los beneficios de la abstracción aún no son obvios; si escribes dos explícitamente, cada uno se puede entender de forma independiente. No será demasiado tarde para perfeccionar los protocolos cuarto y quinto (regla de tres).

{}