Auditar, acotar, verificar, entregar: una lista de verificación práctica para herramientas y habilidades de trabajo de ChatGPT

El modelo operativo

Una ejecución fallida de un agente rara vez es un fallo del modelo. Es un fallo de alcance. El operador no sabía qué podía invocar la sesión, qué requería la tarea ni cómo demostrar el resultado. Esa brecha convierte una automatización útil en un riesgo.

Las herramientas y habilidades de trabajo son objetos distintos. Las herramientas son puntos finales invocables; las habilidades son paquetes reutilizables de instrucciones que guían cómo se usan esas herramientas. Una instantánea de referencia contiene 232 interfaces de herramientas y 44 archivos de habilidades principales completos. Esa amplitud es útil, pero también es una trampa. La disponibilidad puede cambiar con la configuración de la sesión, los permisos, las aplicaciones conectadas y los complementos instalados. El operador debe tratar la sesión, no la documentación, como la fuente de verdad.

La medida práctica es dejar de escribir indicaciones desde la memoria. Ejecuta una lista de verificación a nivel de sesión. Debe cubrir qué está disponible, cuál es la tarea, qué debe contener la indicación, cómo se verifica la salida y cómo se entrega el trabajo.

La lista de verificación de sesión en cinco pasos

1. Inventario de herramientas y habilidades disponibles. Antes de la primera indicación, lista las herramientas que la sesión puede invocar y las habilidades que puede cargar. No asumas que una capacidad existe porque existe en otro espacio de trabajo. Registra el nombre, la entrada esperada y el retorno esperado. Si una página de habilidad está disponible, lee la definición antes de usarla. Las páginas de habilidades reproducen su fuente SKILL.md completa y actual. Un inventario breve previene el fallo más común: pedirle al agente que use algo que la sesión no puede ver.
2. Clasifica la tarea como llamada a punto final o ejecución de habilidad. Una llamada a punto final es estrecha. Pide un resultado de herramienta, un comando, una búsqueda o un cambio de archivo. Una ejecución de habilidad es más amplia. Usa un paquete reutilizable de instrucciones para dar forma a un trabajo de varios pasos. Si la tarea mezcla ambas, divídela. Coloca la llamada a punto final en un paso y el flujo de trabajo dirigido por habilidad en otro. Esto mantiene la indicación auditable.
3. Acota la indicación con entrada, artefacto esperado y método de verificación. La indicación debe nombrar la entrada, la salida y la prueba. Entrada significa los archivos exactos, los datos, las restricciones y los permisos. Artefacto esperado significa el informe, el parche, la salida del comando, la actualización del ticket o el resumen. Método de verificación significa cómo confirmarás el resultado. Una indicación sin método de verificación es una solicitud de confianza, no de evidencia.
4. Verifica la salida antes de aceptar el resultado. La verificación depende de la herramienta. La herramienta exec_command ejecuta un comando en una PTY y devuelve la salida o un identificador de sesión, así que trata el identificador devuelto como un manejador abierto, no como un resultado terminado. La herramienta apply_patch edita archivos en formato libre y no debe envolver la edición en JSON. Inspecciona la diferencia, no solo la afirmación del agente. Para cualquier salida, revisa tres cosas: el tipo de artefacto, el contenido y los efectos secundarios. Si el resultado es un resumen, verifica la fuente. Si el resultado es un comando, verifica el resultado del comando. Si el resultado es un parche, verifica las líneas cambiadas.
5. Entrega con artefacto, propietario, siguiente paso del flujo de trabajo y nota de reversión. Una tarea completada no es un mensaje en un chat. Es una transferencia. La entrega debe incluir el artefacto, la persona o el sistema que lo posee, el siguiente paso del flujo de trabajo y la nota de reversión. La nota de reversión debe indicar qué deshacer si el cambio falla. Si no puedes escribir la nota de reversión, la tarea no está lista para publicarse.

Reglas que mantienen honesta la lista de verificación

• No dejes que una respuesta segura reemplace la verificación. El operador necesita un artefacto, no un tono.
• No dejes que una indicación larga oculte una prueba faltante. Si la indicación no puede decir cómo se revisará el resultado, reescríbela.
• No dejes que una sesión abierta se convierta en un marcador de posición para la finalización. Una sesión abierta es un estado, no un entregable.
• No dejes que un parche pase porque se aplicó. Un parche puede aplicarse y aun así romper el flujo de trabajo.
• No dejes que la entrega se convierta en un resumen. El siguiente responsable necesita el artefacto, el propietario, el siguiente paso y la nota de reversión.

Qué hacer cuando la sesión se desvía

Las sesiones se desvían. El modelo comienza a responder a una pregunta más amplia que la que hiciste. Asume que una herramienta está disponible. Trata un resultado parcial como final. La lista de verificación es la corrección.

Detén la ejecución. Vuelve a leer el inventario. Confirma que la herramienta o habilidad sigue dentro del alcance. Vuelve a declarar la entrada, el artefacto esperado y el método de verificación. Si la sesión no puede verificar el resultado, no lo entregues. Si la sesión no puede revertir el cambio, no lo marques como completo. Si la tarea necesita más de lo que la sesión actual puede demostrar, divídela en una tarea más pequeña y vuelve a iniciar la lista de verificación.

Las operaciones de agentes no son una demostración. Son trabajo de producción. El trabajo del operador es hacer que la sesión sea auditable. El modelo propone. La lista de verificación verifica. La entrega hace que el resultado sea utilizable.