Diatriba aleatoria sobre dónde estamos con los agentes de IA:

Algunos no los llaman agentes, pero los "agentes de flujo de trabajo" con flujos deterministas están en todas partes y funcionan. cualquiera puede crear agentes de flujo de trabajo simples, incluso comenzando con herramientas sin código como Zapier y n8n. Los agentes de flujo de trabajo complejos requieren mucha más reflexión para construir de manera confiable y eficiente. un flujo de trabajo complejo para un caso de uso común y valioso, con integraciones relevantes integradas, puede ser independiente como negocio, y también un gran GTM para expandirse más tarde a otros flujos de trabajo o trabajos más autónomos.

Los agentes más dinámicos / autónomos están comenzando a funcionar y son útiles para la investigación (especialmente si están basados en la web) y la codificación. menos confiable una vez que comience a agregar más fuentes de datos (por ejemplo, API). Los agentes de solo lectura se sienten seguros y fáciles de probar, pero dejar que los agentes autónomos actúen (escriban) da miedo. (Idea aleatoria sobre esto: sería genial si herramientas como un CRM le permitieran "bifurcar" un espejo de desarrollo y ejecutar experimentos de automatización que pueda revertir o fusionar).

Los agentes dinámicos funcionan bien cuando pueden (1) crear y realizar un buen plan y (2) ejecutar las tareas correctamente, mientras (3) encuentran el contexto adecuado para alimentar cada paso (tanto la planificación como cada tarea). Finalmente, necesita (4) reflexionar a lo largo del camino (ya sea con o sin participación humana) para que pueda ajustar el plan de manera adecuada y también mejorar la forma en que ejecuta las tareas fallidas o de bajo rendimiento.

Planificación de tareas: capacidades de razonamiento de LLM Funciona bien para listas de tareas simples que no requieren contexto privado (como una investigación profunda, solo una serie de búsquedas web mientras se resume). Si desea investigar muchas entidades, la investigación profunda no funciona tan bien porque la gestión de la lista de tareas es relativamente básica. Las herramientas de IA basadas en hojas de cálculo funcionan mejor para investigar muchas entidades porque está descargando efectivamente la administración de tareas a la hoja de cálculo, ya que pasar largas listas de tareas entre indicaciones no funciona aquí. La gestión de tareas en Coding Agents funciona con problemas simples, código simple o cuando está comenzando desde cero. Una vez que ingresa a proyectos preexistentes más complejos, son menos confiables, y los desarrolladores aumentan la confiabilidad al documentar cómo funciona y se organiza su código (archivos .md), lo que permite al agente crear listas de tareas mejor informadas. El código complejo requiere más documentos y, finalmente, extraer dinámicamente solo el contexto relevante de esos documentos. Mucha gente / empresas tiene fuertes opiniones indocumentadas sobre el orden / enfoque / herramientas correctas para abordar un proyecto, y necesitamos más enfoques para documentar esto por adelantado y sobre la marcha. Otra razón por la que los agentes de codificación e investigación basados en la web funcionan bien es que todos usan el mismo conjunto de herramientas, por lo que no es necesario "aprender" a usar esas herramientas (más sobre esto a continuación).

Ejecución de tareas: Las tareas suelen ser llamadas a la API (que requieren autenticación y comprensión de cómo usar la API y la estructura de datos subyacente, que puede ser única como en un CRM o una base de datos con tablas/columnas personalizadas), razonamiento de LLM (por ejemplo, resumir), una combinación e incluso agentes de flujo de trabajo*. Un agente de investigación es realmente solo una búsqueda web y un resumen en un bucle. los agentes de codificación son CRUD en su base de código y tal vez la búsqueda web de API de aprendizaje. La autenticación y el acceso básico a la API se sienten resueltos (los MCP encajan aquí), pero me gustaría ver más sobre el contexto específico de la herramienta (pregunte al usuario, pero también analice la conexión inicial, profundice en los datos existentes para comprender cómo se usa la herramienta, cómo se estructuran los datos, para qué escenarios / proyectos usamos la herramienta), los errores / reflexión / retroalimentación deben convertirse en aprendizajes organizados que se retroalimentan como contexto cuando sea relevante. Las mismas herramientas se pueden usar para diferentes propósitos y de diferentes maneras entre organizaciones y necesitamos capturar / documentar esto de alguna manera para ejecutar bien las tareas.

Contexto: Imagina ser un nuevo empleado en una empresa. Aprendes mucho durante la incorporación (y cuanto mejor sea la incorporación, más efectivo serás desde el principio), y luego está el aprendizaje en el trabajo que se divide en aprender de la experiencia de la organización ("así es como hacemos las cosas") y aprender de la propia experiencia, que antes era más predominante en las grandes organizaciones. La gestión del contexto es similar. hay capas de contexto como meta (usuario / empresa), proyecto / departamento específico, tarea específica, herramienta específica, etc. hemos evolucionado de simples indicaciones del sistema a estrategias RAG híbridas (vector, palabra clave, gráfico), pero más allá de tener los datos / contexto, necesitamos orientación sobre cuándo y cómo recuperar el contexto, de lo que vemos las primeras versiones de hoy, pero mucho margen de mejora. Esto no es simplemente un problema técnico, sino también un problema comercial, ya que básicamente necesita crear un documento de incorporación que cubra todos los escenarios que espera. A medida que los proyectos se vuelven más complicados, se necesita más consideración para podar correctamente el contexto para que solo se incluya información relevante en el aviso, al tiempo que se minimiza el contexto irrelevante.

Reflexión: tenemos herramientas de monitoreo de agentes que cubren los costos de LLM / API, la observación, pero asignar el éxito / fracaso es un desafío: un área en la que los agentes de codificación tienen una ventaja sobre otros es una forma determinista de notar fallas (a través de pruebas del código). Para muchas otras tareas agenciales, todavía estamos descubriendo la forma correcta de recopilar información humana para mejorar la producción futura. AFAIK, la reflexión hoy en día es humana, donde la retroalimentación se alimenta en gran medida a los desarrolladores humanos para mejorar el agente, pero el desbloqueo llega cuando descubrimos cómo convertir la reflexión en superación personal, donde el agente toma información de las fallas en la generación de listas de tareas y la ejecución de tareas para hacerlo mejor la próxima vez. Básicamente, la reflexión debe convertirse en un contexto bien organizado que pueda ser utilizado en indicaciones cuando y solo cuando sea relevante. esto evoluciona hacia piezas de ajuste fino del agente, y luego entornos de RL agenticos, todavía se siente bastante temprano aquí

* Anteriormente mencioné la entrega de tareas a los agentes de flujo de trabajo, lo que comienza a tener sentido cuando su agente se beneficiaría de no tener agentes de flujo de trabajo como herramientas (en lugar de descubrir una lista de tareas conocida cada vez) o cuando su sistema es lo suficientemente complicado como para que los agentes especializados con contexto y herramientas especializadas funcionen mejor. O si está aprovechando agentes creados por otras personas (un patrón que comencé a ver aquí son los puntos finales de API de lenguaje natural para facilitar la colaboración de los agentes).

si tuviéramos la calidad del modelo actual con una ventana de contenido infinita (sin degradación de la calidad), computación infinita, almacenamiento infinito, acceso al navegador y un método de pago, un solo bucle LLM probablemente sea suficiente para hacer mucho el punto sin sentido anterior (nada es infinito) es que la orquestación de agentes se trata en gran medida de administrar las limitaciones mediante la arquitectura de formas de descargar el trabajo del LLM a través de la estructura y el código.

Los agentes en producción vienen en varios sabores: como herramientas internas, como un producto independiente que combina varias herramientas e integrados como una característica de una herramienta principal. pueden ser genéricos o especializados. Los agentes de chat, voz y segundo plano parecen ser la interfaz de usuario más común para activar flujos agenciales.

¿Qué más me estoy perdiendo?