Cómo construir agentes de IA efectivos
(anthropic.com)- Según la experiencia práctica de Anthropic, los agentes LLM exitosos suelen partir de patrones simples y combinables más que de frameworks complejos
- Los sistemas agénticos se dividen entre flujos de trabajo que siguen rutas de código definidas y agentes en los que el LLM decide dinámicamente el procedimiento y el uso de herramientas
- Muchas aplicaciones con LLM funcionan suficientemente bien con una sola llamada al modelo más búsqueda y ejemplos en contexto; la complejidad solo debería aumentar cuando las evaluaciones demuestren que mejora los resultados
- Los frameworks ayudan a empezar rápido, pero su capa de abstracción puede ocultar prompts y respuestas, dificultando el debugging
- Los agentes autónomos son fuertes para problemas abiertos, pero implican mayor costo y riesgo de acumulación de errores, por lo que requieren pruebas en sandbox, guardrails y un diseño claro de herramientas
Distinción básica de los sistemas agénticos
- Sistemas agénticos es un término amplio que se usa desde sistemas completamente autónomos que operan de forma independiente por largos periodos, hasta implementaciones que siguen flujos de trabajo predefinidos
- Anthropic considera todas estas variantes como sistemas agénticos, pero arquitectónicamente las divide en dos tipos
- Flujos de trabajo: el LLM y las herramientas se orquestan siguiendo rutas de código predefinidas
- Agentes: el LLM indica y controla dinámicamente cómo ejecutar la tarea, el procedimiento y el uso de herramientas
Criterios para decidir cuándo usar agentes
- Se recomienda que las aplicaciones con LLM empiecen con la solución más simple posible y solo aumenten la complejidad cuando haga falta
- Los sistemas agénticos están diseñados para obtener mejor desempeño en tareas a cambio de asumir latencia y costo, así que primero hay que confirmar si realmente se necesita ese intercambio
- Incluso cuando se necesita complejidad, el criterio de elección varía
- Para tareas bien definidas, los flujos de trabajo ofrecen predictibilidad y consistencia
- Para tareas que requieren flexibilidad a gran escala y toma de decisiones guiada por el modelo, los agentes son más adecuados
- Muchas aplicaciones funcionan bien con solo optimizar una llamada única al LLM con búsqueda y ejemplos en contexto
Criterios para usar frameworks
- Se presentan Claude Agent SDK, Strands Agents SDK by AWS, Rivet y Vellum como herramientas para implementar sistemas agénticos
- Estos frameworks simplifican tareas estándar de bajo nivel, como llamadas al LLM, definición y parsing de herramientas, y conexión entre llamadas, lo que acelera el arranque
- Sin embargo, la capa de abstracción adicional puede ocultar los prompts y respuestas reales, dificultando el debugging
- Incluso puede empujar a añadir complejidad innecesaria en situaciones donde una configuración simple sería suficiente
- Conviene que los desarrolladores empiecen usando directamente la API de LLM
- Muchos patrones pueden implementarse con unas pocas líneas de código
- Aunque se use un framework, hay que entender cómo funciona su código interno
- Las suposiciones incorrectas sobre el funcionamiento interno son una causa común de errores para clientes
- Se pueden ver implementaciones de ejemplo en el cookbook
Bloque de construcción básico: LLM aumentado
- El bloque de construcción básico de los sistemas agénticos es un LLM aumentado con capacidades como búsqueda, herramientas y memoria
- Los modelos actuales pueden usar activamente estas capacidades generando consultas de búsqueda por sí mismos, eligiendo la herramienta adecuada y decidiendo qué información conservar
- Al implementarlo, hay que centrarse en dos cosas
- Ajustar las capacidades al caso de uso
- Proporcionar interfaces documentadas que sean fáciles de usar para el LLM
- Como una forma de implementación, se presenta Model Context Protocol
- Los desarrolladores pueden integrarse con ecosistemas de herramientas de terceros mediante una implementación sencilla de cliente
Patrones de flujo de trabajo
-
Encadenamiento de prompts
- El encadenamiento de prompts divide una tarea en etapas secuenciales, donde cada llamada al LLM procesa la salida de la llamada anterior
- Se pueden añadir verificaciones programáticas en cada paso intermedio para comprobar que el proceso siga la ruta correcta
- Es adecuado cuando la tarea puede descomponerse limpiamente en subtareas fijas
- El principal intercambio consiste en asumir latencia para reducir la dificultad de cada llamada al LLM y así mejorar la precisión
- Ejemplos
- Generar texto de marketing y luego traducirlo a otro idioma
- Crear el esquema de un documento, verificar si cumple criterios y redactarlo a partir de ese esquema
-
Enrutamiento
- El enrutamiento clasifica la entrada y luego la envía a una tarea posterior especializada
- Permite separar responsabilidades y crear prompts más especializados
- Sin esta estructura, optimizar para un tipo de entrada puede perjudicar el rendimiento en otros tipos
- Funciona bien cuando distintas categorías requieren procesamiento separado y cuando el LLM o un modelo/algoritmo tradicional de clasificación puede clasificarlas con precisión
- Ejemplos
- Enviar consultas de atención al cliente como preguntas generales, solicitudes de reembolso o soporte técnico a procesos, prompts y herramientas distintos
- Enrutar preguntas fáciles o comunes a un modelo más pequeño y eficiente en costos como Claude Haiku 4.5, y preguntas difíciles o inusuales a un modelo más potente como Claude Sonnet 4.5
-
Paralelización
- La paralelización consiste en que el LLM procese una tarea al mismo tiempo y luego se agreguen programáticamente las salidas
- Hay dos variantes principales
- Seccionamiento: dividir la tarea en subtareas independientes y ejecutarlas en paralelo
- Votación: ejecutar la misma tarea varias veces para obtener salidas diversas
- Es efectiva cuando se puede ganar velocidad al dividir subtareas o cuando se necesitan múltiples perspectivas o intentos para lograr mayor confiabilidad
- En tareas complejas, si cada consideración queda a cargo de una llamada separada al LLM, es posible enfocarse mejor en aspectos específicos
- Ejemplos
- Guardrails donde una instancia del modelo procesa la consulta del usuario y otra revisa contenido o solicitudes inapropiadas
- Evaluaciones del rendimiento de LLM donde cada llamada analiza un aspecto distinto del desempeño del modelo
- Varios prompts revisan vulnerabilidades en código y marcan si encuentran problemas
- En evaluación de contenido inapropiado, usar varios prompts y un umbral de votación para equilibrar falsos positivos y falsos negativos
-
Orquestador-trabajador
- El patrón orquestador-trabajador hace que un LLM central descomponga dinámicamente la tarea, la delegue a LLM trabajadores y luego sintetice los resultados
- Es adecuado para tareas complejas donde no se pueden prever de antemano las subtareas necesarias
- Puede parecerse a la paralelización, pero la diferencia clave es la flexibilidad
- En la paralelización, las subtareas están predefinidas
- En orquestador-trabajador, el orquestador decide las subtareas según la entrada
- Ejemplos
- Productos de coding que realizan cambios complejos en múltiples archivos cada vez
- Tareas de búsqueda que recopilan y analizan información potencialmente relevante desde varias fuentes
-
Evaluador-optimizador
- El patrón evaluador-optimizador es una estructura en bucle donde una llamada al LLM genera una respuesta y otra la evalúa y aporta feedback
- Es especialmente efectivo cuando existen criterios de evaluación claros y la mejora iterativa aporta valor medible
- Hay dos señales de buen ajuste
- Cuando una persona expresa claramente el feedback, la respuesta del LLM realmente mejora
- El LLM puede proporcionar ese tipo de feedback
- Se parece al proceso iterativo de escritura por el que pasa un autor humano al pulir un documento
- Ejemplos
- Traducción literaria donde un LLM evaluador critica matices que el LLM traductor pudo haber pasado por alto al principio
- Tareas complejas de búsqueda donde el evaluador decide si se necesita investigación adicional
Agentes autónomos
- Los agentes empezaron a usarse en producción a medida que los LLM adquirieron capacidad para entender entradas complejas, razonar y planificar, usar herramientas de forma confiable y recuperarse de errores
- La tarea comienza con una instrucción o conversación con una persona
- Cuando la tarea queda clara, el agente planifica y opera de forma independiente
- Si necesita más información o juicio, puede volver a la persona
- Durante la ejecución, es importante obtener en cada paso señales reales de verificación desde el entorno
- Ejemplo: resultados de llamadas a herramientas, resultados de ejecución de código
- Esto permite evaluar el progreso
- El agente puede detenerse en checkpoints o bloqueos para pedir feedback humano
- Aunque muchas tareas terminan al completarse, también es común establecer condiciones de parada como un número máximo de iteraciones para mantener el control
- La implementación en sí suele ser simple
- Por lo general, un agente es un LLM que usa herramientas dentro de un bucle basado en feedback del entorno
- Por eso hay que diseñar con claridad y cuidado el conjunto de herramientas y su documentación
- Cuándo usarlos
- Problemas abiertos donde es difícil o imposible predecir la cantidad de pasos necesarios
- Tareas donde no se puede codificar una ruta fija
- Situaciones donde el LLM puede operar durante varios turnos y se requiere cierto nivel de confianza en su toma de decisiones
- Restricciones
- La autonomía viene con mayor costo y posibilidad de acumulación de errores
- Se recomiendan pruebas extensivas en entornos sandbox y guardrails adecuados
- Ejemplos
- Agentes de coding que resuelven tareas de SWE-bench que requieren editar varios archivos
- La implementación de referencia de “computer use”, donde Claude usa una computadora para realizar tareas
Combinación y personalización de patrones
- Los bloques de construcción presentados no son una receta fija, sino patrones comunes que los desarrolladores pueden ajustar y combinar según su caso de uso
- Como en todo el campo de los LLM, la clave del éxito está en medir el rendimiento e iterar sobre la implementación para mejorarla
- La complejidad solo debe añadirse cuando los resultados realmente mejoran
Principios de implementación
- En el mundo de los LLM, el éxito no consiste en construir el sistema más sofisticado, sino el sistema correcto para la necesidad
- El orden recomendado es el siguiente
- Empezar con prompts simples
- Optimizar los prompts con evaluaciones integrales
- Añadir sistemas agénticos de múltiples pasos solo cuando la solución simple no sea suficiente
- Al implementar agentes, tres principios son importantes
- Mantener la simplicidad del diseño
- Priorizar la transparencia mostrando explícitamente la etapa de planificación del agente
- Diseñar cuidadosamente la agent-computer interface, es decir, la ACI, con documentación exhaustiva de herramientas y pruebas
- Los frameworks ayudan a empezar rápido, pero al pasar a producción también puede ser necesario reducir capas de abstracción y construir con componentes base
Áreas de aplicación real
-
Soporte al cliente
- El soporte al cliente combina la interfaz familiar de chatbot con la ampliación de capacidades mediante integración de herramientas
- Hay razones por las que encaja naturalmente con agentes más abiertos
- Las interacciones de soporte siguen un flujo conversacional y a la vez requieren acceso a información y acciones externas
- Las herramientas pueden integrarse para traer datos del cliente, historial de pedidos y documentos de la base de conocimiento
- Acciones como procesar reembolsos o actualizar tickets pueden manejarse programáticamente
- El éxito puede medirse con claridad mediante la resolución definida por el usuario
- Varias empresas han demostrado la viabilidad de este enfoque con modelos de precio por uso que cobran solo por resoluciones exitosas
-
Agentes de coding
- El área de desarrollo de software ha mostrado gran potencial a medida que las capacidades de los LLM evolucionan desde autocompletado de código hasta resolución autónoma de problemas
- Hay razones por las que los agentes son efectivos
- Las soluciones de código pueden validarse con pruebas automatizadas
- Los agentes pueden usar los resultados de esas pruebas como feedback para mejorar iterativamente la solución
- El espacio del problema está bien definido y estructurado
- La calidad de la salida puede medirse objetivamente
- En la implementación de Anthropic, los agentes pueden resolver issues reales de GitHub del benchmark SWE-bench Verified usando solo la descripción del pull request
- Aunque las pruebas automatizadas ayudan a verificar funcionalidad, la revisión humana sigue siendo importante para confirmar que la solución cumpla con los requisitos más amplios del sistema
Prompt engineering para herramientas
- En cualquier sistema agéntico, las herramientas probablemente serán un componente importante
- Tools permiten que Claude interactúe con servicios externos y APIs
- En la API se especifican la estructura y la definición exactas
- Cuando Claude planifica una llamada a herramienta, la respuesta de la API incluye un tool use block
- La definición y especificación de herramientas merecen tanta atención de prompt engineering como el prompt completo
-
Elegir el formato de las herramientas
- Una misma tarea puede especificarse de varias formas
- La edición de archivos puede representarse como diff o como reescritura completa del archivo
- La salida estructurada puede devolverse como código dentro de Markdown o como código dentro de JSON
- Desde la perspectiva de ingeniería de software, estas diferencias de formato pueden parecer convertibles sin pérdida, pero para un LLM algunos formatos son mucho más difíciles de usar
- Escribir un diff exige saber cuántas líneas cambian en el encabezado del bloque antes de redactar el nuevo código
- Escribir código dentro de JSON exige además escapes de saltos de línea y comillas
- Al elegir el formato de una herramienta, hay que evitar encerrar al modelo en cargas de formato innecesarias
- Dar suficientes tokens para pensar antes de entrar a un formato sin salida
- Mantenerse cerca de formatos que el modelo haya visto naturalmente en textos de internet
- Eliminar sobrecarga de formato como contar con precisión líneas en miles de líneas de código o escapar strings de código
- Una misma tarea puede especificarse de varias formas
-
Diseño de la ACI
- Hay que invertir en el diseño de la agent-computer interface (ACI) tanto como se invierte en la interfaz humano-computadora (HCI)
- Una buena definición de herramientas suele incluir ejemplos de uso, edge cases, requisitos del formato de entrada y límites claros con otras herramientas
- Los nombres y descripciones de parámetros deben ajustarse para que el modelo los entienda con más facilidad
- Es parecido a escribir un excelente docstring para un desarrollador junior del equipo
- Esto es especialmente importante cuando hay muchas herramientas parecidas
- Hay que probar cómo el modelo usa las herramientas
- Al crear un agente para SWE-bench, se dedicó más tiempo a optimizar herramientas que el prompt completo
- El agente cometía errores con una herramienta que usaba rutas de archivo relativas después de salir del directorio raíz
- Cuando la herramienta pasó a exigir siempre rutas de archivo absolutas, el modelo pudo usar ese método sin errores
1 comentarios
Opiniones de Hacker News
Creo que este artículo sigue siendo uno de los buenos sobre este tema. En especial, me gustó que al principio definiera con claridad qué entiende por agente de IA
Aquí lo define como “un sistema en el que el LLM dirige dinámicamente su propio proceso de procesamiento y el uso de herramientas, manteniendo el control sobre cómo lograr la tarea”
También me gustó la forma en que distingue entre “agentes” y “workflows”, y explica varios patrones útiles de workflows
Dejé unas notas sobre este artículo cuando salió por primera vez: https://simonwillison.net/2024/Dec/20/building-effective-age...
Un artículo más reciente de Anthropic es https://www.anthropic.com/engineering/built-multi-agent-rese... — “How we built our multi-agent research system”, que también es muy interesante, y sobre el que recopilé notas: https://simonwillison.net/2025/Jun/14/multi-agent-research-s...
Para fines de aprendizaje me parece bien, pero la primera ventaja de un buen framework es que permite probar fácilmente LLM de distintos proveedores
Parece un intento de redefinir los workflows para diferenciarlos, pero la mayoría de los agentes no son más que workflows iterativos que llaman dinámicamente a algo según la respuesta del LLM. Los motores de workflow modernos son muy dinámicos
El consejo de que “simplifican tareas estándar de bajo nivel como llamadas a LLM, definición y parsing de herramientas, y encadenamiento de llamadas, lo que facilita empezar, pero a menudo crean capas adicionales de abstracción que ocultan los prompts y respuestas subyacentes, dificultando la depuración. También tientan a agregar complejidad cuando una configuración más simple bastaría. Recomendamos a los desarrolladores empezar usando directamente la API del LLM” me parece, por mucho, lo mejor de todo el artículo
En esencia, no tiene sentido usar un framework enorme para algo que básicamente consiste en enviar un arreglo de strings a un servicio web
En proyectos de la empresa también eliminamos LangChain y LangGraph; en la práctica no aportaban valor y solo aumentaban la complejidad. Al tener que lidiar con el boilerplate del framework, terminábamos escribiendo incluso más código que si no lo usáramos
Se podrían ejecutar todos los pasos de generación de imágenes con Stable Diffusion o escribir directamente código de shaders, pero si hay más de un flujo o tarea y estás experimentando, usar comfy-UI o un shader graph resulta mucho más ordenado
Ya pasó medio año, y en el campo de la IA eso se siente como bastante tiempo. Hace unos meses releí este artículo varias veces, pero ahora parece claro que el desarrollo de agentes llegó a un cuello de botella
Incluso el Gemini más reciente parece haber retrocedido
La orquestación multiagente es difícil de controlar y, cuanto mejor sea el rendimiento del modelo, menor será la necesidad de múltiples agentes. A la inversa, cuanto menor sea el rendimiento del modelo, más sentido de negocio tiene una IA de alcance limitado
¿Hay ejemplos de agentes que, en entornos reales de producción, le ahorren dinero a una empresa y hagan trabajo de verdadero valor? Me refiero a casos que no sean escribir texto para rellenar el espacio vacío en una bolsa de papas fritas.
https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys...
Todavía está en beta.
Según el comunicado de prensa, el chatbot de Rukaya Johaadien ofrece asistencia conversacional a estudiantes e investigadores que tienen datos de biodiversidad, pero que publican datos por primera vez o rara vez. Les ayuda a limpiar y estandarizar hojas de cálculo, crear metadatos básicos y publicar datasets bien estructurados como Darwin Core Archive en GBIF.org.
Hasta ahora, era difícil publicar a gran escala datos de alta calidad provenientes de investigaciones doctorales o de maestría, o de estudios pequeños de biodiversidad. Esto se debe a que la estandarización de datos normalmente requería conocimientos de lenguajes de programación, técnicas de gestión de datos y software especializado.
El proceso de acceder al Integrated Publishing Toolkit (IPT), la aplicación central para compartir datos en la red GBIF, también es complicado para principiantes. Como el tiempo y los recursos de los responsables de nodos son limitados, y los usuarios ocasionales tienden a olvidar cada año los procedimientos y detalles exactos, dicen que la capacitación por sí sola no alcanza para superar las barreras logísticas y lingüísticas.
Explica: “La estandarización de datos es difícil, y los biólogos no se hicieron biólogos porque les gustara programar o usar Excel, así que se descartan muchos datos potencialmente valiosos. Al ver que los modelos de lenguaje grandes se volvieron muy buenos generando código y trabajando con datos, creamos una herramienta que guía a usuarios no técnicos con preguntas cotidianas, procesa datos desordenados en la medida de lo posible y luego los publica en GBIF de forma rápida y automática”.
Para cada alerta o ticket entrante, un agente realiza una investigación previa en APIs, bases de datos, etc. relevantes para identificar falsos positivos y aportar más contexto sobre los problemas reales. Reduce el tiempo humano y acelera el procesamiento.
Usan el mismo razonamiento agéntico para tareas de exploración, y van más allá de un simple text-to-SQL: el LLM investiga durante 2 a 10 minutos en Splunk, Databricks, etc. en lugar del usuario.
Internamente cuentan con herramientas como una capa semántica sobre bases de datos y analizadores de logs, texto y dataframes a gran escala.
Probé un workflow de n8n que armé yo mismo con una configuración casi igual a la del artículo. Obtener una respuesta a una pregunta sencilla costó 3 dólares y al menos 3 minutos.
Por ahora voy a seguir usando la búsqueda normal.
Este artículo recuerda muy bien que hay que empezar con lo más simple que funcione y agregar complejidad solo cuando realmente haga falta.
Con unas pocas llamadas a LLM claramente definidas y algo de lógica ligera de pegamento, por lo general se obtiene un sistema más estable, más fácil de depurar y mucho más barato de ejecutar. Los agentes vistosos y llenos de funciones muchas veces crean más problemas de los que resuelven.
Como alguien que trabaja en una empresa que tiene agentes reales en producción, no workflows, no puedo estar más en desacuerdo con la primera frase de aquí: “usar un framework de agentes como LangGraph”.
Nosotros hicimos exactamente eso y al cabo de un mes tuvimos que tirar todo; después reconstruimos desde cero y ahora tenemos un sistema que escala bastante bien.
Para ser justos, puede haber espacio para usar frameworks de agentes. Pero el campo de los agentes todavía está demasiado verde como para que exista un framework suficientemente bueno.
En cierto sentido también pienso lo contrario: el campo de los agentes se mueve tan rápido que puede que nunca llegue a existir un framework suficientemente bueno.
Los frameworks facilitan empezar, pero una capa adicional de abstracción puede ocultar prompts y respuestas, dificultar la depuración y agregar complejidad incluso cuando una configuración más simple sería suficiente. Por eso recomiendan empezar usando directamente la API del LLM, ya que muchos patrones pueden implementarse con unas pocas líneas de código.
He visto muchos comentarios de que los equipos pragmáticos en su mayoría abandonaron cosas como LangChain, LangGraph, Haystack y Crew para irse a código interno más simple, pero todavía no tengo una idea clara de cómo se implementan en la práctica partes como las llamadas a herramientas.
Si tienes enlaces o documentación que hayas usado como base para tu trabajo, ¿podrías compartirlos?
Es un artículo de diciembre de 2024, pero por alguna razón se siente como si fuera de hace muchísimo tiempo.
Fue el artículo que me hizo volver a ver a Anthropic como un “socio práctico” para el desarrollo de herramientas de IA.
https://news.ycombinator.com/item?id=44260988
Parece que el hype por los agentes ya se calmó un poco.
La frase “usar patrones simples y componibles” resulta extrañamente tranquilizadora.
Me gusta que la máxima “haz una cosa y hazla bien” siga vigente incluso después de décadas. La componibilidad es lo mejor.