Expansión de la herramienta del agente y controlabilidad del sistema.

Una situación común es evaluar un sistema de Agente. Lo primero que hay que mirar es “cuántas herramientas puede aceptar”.

Puede verificar bases de datos, enviar mensajes, modificar órdenes de trabajo, emitir scripts y operar navegadores. Ciertamente parece más un sistema que realmente funciona que un modelo de solo chat. Así que es fácil para el equipo ir en esta dirección: si conectamos algunas herramientas más, otorgamos más permisos y hacemos que los enlaces sean más automáticos, el sistema será más fuerte.

El problema es que ser fuerte no significa ser controlable.

Mi juicio es: ** La controlabilidad del sistema del Agente no depende de la cantidad de herramientas, sino de la convergencia del estado, los límites de permisos y la reserva de fallas. Cuando hay cada vez más herramientas, contextos cada vez más prolongados y más efectos secundarios de las acciones, sin restricciones claras y mecanismos de convergencia, el sistema generalmente será más difícil de predecir. **

Hay muchas herramientas, la solución es el rango operable; controlable, la solución es si los resultados pueden contenerse

La solución de las “herramientas ajustables” es que el Agente ya no solo da sugerencias, sino que puede afectar directamente al sistema real.

Se trata de una ampliación de la capacidad, no de una cuestión falsa.

Pero una vez que el sistema pasa de “responder preguntas” a “realizar acciones”, el enfoque de ingeniería cambia. Ya no es necesario juzgar si el contenido de salida suena como habla humana, sino juzgar:

• ¿Qué hizo exactamente esta vez?
• Haz este movimiento en lugar de otro movimiento más seguro;
• Qué tan amplio será el impacto si comete un error;
• Cuando falla en el medio, ¿el sistema se detendrá, volverá a intentarlo o dejará la mitad de un conjunto de efectos secundarios?
• La próxima vez que llegue una solicitud similar, ¿tomará un camino completamente diferente?

En otras palabras, a medida que aumenta el número de herramientas, la complejidad pasa de “problemas de corrección del texto” a “problemas de previsibilidad del comportamiento del sistema”.

Estos dos tipos de problemas no son de la misma magnitud.

Un modelo que sólo puede responder preguntas suele ser ruido cognitivo si comete errores; Si un Agente puede ajustar más de una docena de herramientas, una vez que no haya restricciones, si comete errores será ruido de acción y si comete errores será ruido del sistema.

Lo primero que realmente se sale de control es a menudo el Estado.

Muchos equipos arruinan al Agente y la primera reacción es que el modelo es inestable. De hecho, muchos problemas se encuentran fuera del modelo.

Por ejemplo, un proceso común:

• El agente primero verifica el sistema de órdenes de trabajo y obtiene las tareas a procesar;
• Buscar nuevamente en la base de conocimientos para encontrar métodos de eliminación históricos;
• Luego llame a la consulta de la base de datos;
• Enviar otro mensaje al grupo de trabajo;
• Agregar un registro de disposición final.

Cada paso de este enlace es “razonable”, pero mientras el estado intermedio no esté claramente definido, el sistema encontrará rápidamente estos problemas:

• El estado de la orden de trabajo ha sido cambiado a Procesando, pero la notificación no ha sido enviada;
• Se ha ejecutado la consulta a la base de datos, pero los resultados no han sido registrados en el registro final;
• El mensaje ha sido enviado al grupo, pero los pasos posteriores fallaron, pero el mundo exterior pensó que el asunto había sido solucionado;
• Después de truncar la ventana de contexto, no está seguro de qué acciones se han realizado antes cuando continúa la segunda ronda de ejecución.

Estos son el sistema carece de un mecanismo de convergencia estatal.

Un Agente que puede realizar acciones sin una máquina de estado de tareas clara básicamente está encadenando efectos secundarios de varios pasos en la inferencia del lenguaje natural.

Esto se ve muy bien en la demostración, pero es difícil de implementar en producción.

Los límites de los permisos no están claros y el Agente puede cambiar fácilmente de “poder hacer cosas” a “hacer demasiadas cosas”.

Otro malentendido común es considerar el acceso a las herramientas como un inventario de capacidades.

Conéctalo al navegador y dale acceso a cualquier fondo; Cuando se conecta a Shell, la mayoría de los comandos se pueden ejecutar de forma predeterminada; Cuando esté conectado al sistema de mensajería, puede notificar proactivamente a cualquier grupo de forma predeterminada; Conéctese a la base de datos y otorgue permisos mixtos de lectura y escritura.

En la superficie, esto hace que el Agente sea más versátil, pero en realidad está apostando por la controlabilidad del sistema para evitar errores en una sola inferencia.

Esto es peligroso porque el riesgo del agente es que llame a una herramienta de alto efecto secundario en un contexto localmente razonable pero globalmente incorrecto.

Por ejemplo:

• Debería haber verificado el estado, pero en su lugar ejecuté el script de reparación;
• Se suponía que sólo debía responder al usuario actual, pero la notificación se envió al grupo;
• Sólo debería leer datos, pero se llamó a la interfaz de actualización;
• Sólo debería continuar después de la revisión humana, pero la “acción sugerida” se cambió directamente a “acción ejecutada”.

Por lo tanto, el objetivo del diseño de límites de permiso es separar las acciones con altos efectos secundarios del razonamiento de alta incertidumbre.

Si una acción causará un daño real si es incorrecta una vez, no debe colocarse en la misma capa de automatización que las acciones de consulta ordinarias.

Con más herramientas organizadas, el fracaso ya no es solo un “error”, sino un estado semiacabado.

Por supuesto, los sistemas de software ordinarios también fallan, pero el fallo de los sistemas de Agentes tiene un problema adicional: a menudo es un fallo medio completo en herramientas, sistemas y límites semánticos.

Por ejemplo:

1. Primero cree una tarea de procesamiento en Jira;
2. Vaya a Slack para enviar una notificación;
3. Ajuste la API interna para extraer el registro nuevamente;
4. Finalmente escriba el resumen en la base de conocimientos.

¿Qué debería hacer el sistema si falla el paso tres?

• ¿Revertir una tarea de Jira? -¿Eliminar la notificación recién enviada?
• ¿Se retuvo la tarea pero se interrumpió el procesamiento de indicadores?
• ¿Dejar que otro Agente se haga cargo?

El enfoque más tabú aquí es entender el “manejo de fallas” como preguntarle al modelo nuevamente.

Porque muchos fracasos ya son efectos secundarios. Lo que realmente se necesita es:

• Qué pasos se pueden volver a intentar;
• qué pasos deben ser idempotentes;
• Qué pasos sólo se pueden continuar después de la confirmación manual;
• qué acciones externas deben dejar un rastro de auditoría;
• Después de que se interrumpe un enlace, ¿dónde se volverá a conectar la próxima vez que se restablezca?

Si no están definidos, el Agente parece estar automatizando, pero en realidad está creando trabajo posterior manual.

El núcleo de la controlabilidad radica en “¿convegerá?”

Cada vez me inclino más a considerar el sistema de agentes como un sistema de flujo de trabajo con capacidad de razonamiento, en lugar de un portal completo que puede chatear.

Esto quiere decir que a la hora de diseñarlo lo primero que hay que responder es:

• Si la tarea está claramente iniciada, procesada, pendiente de confirmación, completada o fallida;
• Qué herramientas se pueden llamar en cada estado;
• Qué resultados se pueden presentar directamente y cuáles deben revisarse;
• Una vez perdido el contexto, ¿puede el sistema recuperarse del estado externo en lugar de depender de la recuperación del modelo?
• Si existen registros responsables de entradas, salidas y ejecución de cada acción.

Estas cosas no suenan sexys, pero determinan si Agent es un sistema que se puede ampliar gradualmente o un juguete que sólo se puede demostrar en rincones de bajo riesgo.

Un estándar de juicio muy simple es: ** Si cambia temporalmente el modelo a un nivel más débil, la eficiencia del sistema solo disminuirá; Si se eliminan la máquina de estado, los límites de permisos y el mecanismo de reversión, el sistema no podrá conectarse inmediatamente. **

Esto muestra que la verdadera base es la capacidad de convergencia del sistema.

Un contraejemplo común: tratar al Agente como un coordinador universal

Muchas plataformas internas eventualmente crecerán hasta convertirse en algo muy similar a una “plataforma intermedia de IA”:

• Conéctese a cualquier sistema;
• Quiero aceptar cualquier solicitud;
• Intenta completar todas las acciones automáticamente;
• Pensé que mientras hiciera las palabras clave un poco más detalladas, podría eliminar el riesgo.

El mayor problema de esta ruta es que su complejidad marginal es muy pobre.

Porque cuantos más tipos de solicitudes haya, más compleja será la semántica de la herramienta y mayor será el número de combinaciones de rutas de éxito y rutas de fracaso. Originalmente solo necesitaba “verificar los registros de lanzamiento”, pero luego se convirtió en:

• Verificar registros;
• Juicio de anormalidad;
• Decidir si retroceder;
• Enviar notificaciones;
• Cambiar estado;
• Generar revisión;
• Base de conocimientos actualizada.

Parece un circuito cerrado completamente automatizado. De hecho, con cada paso adicional, el sistema agrega una capa de coherencia de efectos secundarios y costos de interpretación de permisos.

Al final, lo que realmente consume el tiempo del equipo suele ser:

• Este paso se ejecutará solo;
• El mismo problema tomó caminos diferentes hoy y ayer;
• Se ha modificado el sistema externo, pero los registros internos no se han mantenido actualizados;
• Después del accidente, es difícil restaurar lo que el Agente confiaba en ese momento.

Esto equivale a entregar demasiadas acciones de alta incertidumbre a un proceso de razonamiento que carece de límites. **

Un enfoque más estable es automatizar capas en lugar de apilar herramientas en forma plana.

Si realmente desea que el sistema del Agente sea controlable, le recomiendo estratificarlo según los riesgos y efectos secundarios:

1. Capa de bajo riesgo: consulta y resumen

Primero, deje que el Agente lea, recupere, resuma y redacte.

Incluso si el juicio de este tipo de acción no es perfecto, generalmente no cambia directamente el estado externo y es más adecuado aumentar la cantidad primero.

2. Capa de riesgo medio: acción de un solo paso con limitaciones

Por ejemplo, solo puede cambiar un campo en un estado de orden de trabajo específico, solo puede responder a la sesión actual y solo puede realizar operaciones en la lista de permitidos explícita.

La clave aquí es comprimir el espacio de acción para que sea lo suficientemente estrecho como para que el costo de los errores sea aceptable.

3. Capa de alto riesgo: aprobación explícita y ejecución de reversión

Siempre que se trate de eliminación de datos, operaciones por lotes, escritura entre sistemas, notificaciones salientes y ejecución de scripts en el entorno de producción, los mecanismos de revisión humana, auditoría y reversión deben ponerse en primer plano, en lugar de dejarlos para su corrección posterior.

Un Agente verdaderamente maduro sabe lo que se debe hacer automáticamente, lo que sólo se puede sugerir y lo que nunca se debe hacer directamente.

Límites aplicables

Este artículo analiza principalmente:

• Un agente interno conectado a múltiples herramientas;
• Agente basado en procesos con efectos secundarios externos reales;
• Escenarios de orquestación que involucran operaciones entre sistemas, como mensajes, órdenes de trabajo, bases de datos, scripts, navegadores, etc.

Si el Agente todavía está atrapado en tareas de bajo efecto secundario, como “ayudar a los usuarios a resumir páginas web” y “ayudar al servicio de atención al cliente a redactar respuestas”, tener más herramientas no necesariamente conduce a una pérdida inmediata de control, porque la mayoría de los errores aún permanecen en la capa de texto.

El verdadero problema surge cuando el sistema comienza a cambiar directamente el estado externo. En ese momento, ya nos enfrentábamos a un diseño restringido al estilo de un sistema distribuido.

Resumen

El agente puede llamar a más herramientas, lo que efectivamente hará que el sistema sea más útil.

Pero “más útil” y “más controlable” no son palabras que vayan en la misma dirección.

Cuando la complejidad de las acciones, los efectos secundarios y el contexto aumentan juntos, lo que realmente determina el límite superior del sistema es a menudo si el estado de activación puede converger, si los límites de los permisos son claros y si la activación se puede detener y restaurar de manera estable después de una falla.

De lo contrario, cuantas más herramientas estén conectadas, más se parecerá el sistema a un ejecutivo con fuertes capacidades pero difícil de predecir.