El framework DeepAgents de LangChain

 (blog.langchain.com)
21 puntos por GN⁺ 2025-08-07 | 1 comentarios | Compartir por WhatsApp
  • Los agentes tradicionales basados en LLM suelen tener una estructura de “agentes superficiales”, donde simplemente repiten llamadas a herramientas, pero Deep Agents son agentes de IA planificados y estructurados capaces de resolver con profundidad tareas complejas y de largo plazo
  • Agentes recientes como Deep Research, Manus y Claude Code implementan “agentes profundos” capaces de explorar temas más a fondo y gestionar mejor el contexto
    • Prompts de sistema detallados, herramientas de planificación, subagentes y uso del sistema de archivos son la clave de estos “agentes profundos”
  • LangChain publicó el paquete open source deepagents para que cualquiera pueda crear fácilmente un deep agent adaptado a su vertical (dominio)
    • Permite configurar prompts, herramientas y subagentes personalizados, y ofrece un framework de propósito general aplicable a áreas como investigación y desarrollo

Limitaciones de los agentes LLM tradicionales y características de los Deep Agents

  • Agente tradicional: el LLM entra en un bucle y solo llama herramientas → adecuado solo para contextos cortos y tareas breves o simples
  • Deep Agents: pueden descomponer, planificar, dar seguimiento y colaborar por sí mismos incluso en metas de largo plazo y tareas complejas

Los 4 elementos que componen a los Deep Agents

  1. Prompts de sistema detallados

    • Como en casos representativos como Claude Code, se usan prompts que especifican en detalle cómo usar herramientas y ejemplos de comportamiento
    • Instrucciones complejas y ejemplos few-shot impulsan un pensamiento y una ejecución más “profundos”

  2. Herramientas de planificación

    • Aunque no tengan una función real, incluir herramientas de planificación como una lista de pendientes dentro de la rutina ayuda a gestionar el contexto y mantener la capacidad de ejecución
    • Incluso si son no-op (no hacen nada), aportan contexto dentro del prompt

  3. Subagentes (Sub Agents)

    • Se crean y dividen subagentes por subtarea, y cada agente trabaja de forma independiente antes de integrar los resultados
    • Incluso problemas grandes o complejos pueden resolverse con una estructura paralela y de división del trabajo

  4. Sistema de archivos

    • No solo sirve para trabajo real con archivos, sino también como almacén de notas y contexto
    • Varios agentes y subagentes comparten el sistema de archivos para colaborar y mantener el contexto a largo plazo

El framework Deep Agents de LangChain: deepagents

  • Paquete open source de Python (pip install deepagents), con configuración de prompts, herramientas y subagentes personalizados
    • Prompt de sistema inspirado en Claude Code, ajustado para ser más general
    • Herramienta de planificación de lista ToDo no-op (igual que en Claude Code)
    • Permite crear subagentes y definirlos de forma personalizada
    • Sistema de archivos virtual basado en conceptos de LangGraph (usando el estado del agente)
  • También ofrece como ejemplo un agente de deep research, lo que facilita crear agentes especializados por vertical

Ejemplos de uso y valor

  • Optimizado para tareas de IA de largo plazo y compuestas, como investigación y desarrollo, generación de código, research y automatización compleja
  • El diseño detallado del contexto y la estructura de división del trabajo permiten generar resultados más profundos
  • Cualquiera puede construir un “deep agent” adaptado a su dominio, lo que apunta al siguiente paso en el uso de la IA

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-07
Opiniones de Hacker News

  • Soy el autor. Últimamente me ha impresionado cómo una serie de agentes como claude code, manus y deep research ejecutan especialmente bien tareas de largo alcance. En la práctica, por dentro un LLM entra en un loop y va llamando herramientas. Pero si haces eso sin pensarlo, aparece el problema de que el LLM no logra resolver bien tareas complejas o largas. Entonces me dio curiosidad cómo otros agentes sí lo consiguen. Lo que encontré en común fue lo siguiente: 1) usan herramientas de planificación 2) usan subagentes 3) usan una estructura que descarga contexto, como un sistema de archivos 4) diseñan prompts de sistema detallados (el prompt engineering sigue siendo importante). Cada una de estas técnicas ya existía, pero no son formas de trabajo que se usen ampliamente al desarrollar agentes en la práctica. Creo que la idea importante es justamente esta combinación. Se agradece feedback

  • Viendo varias opiniones, también estoy de acuerdo en que el concepto de deep agents al final no es tan distinto de la combinación agent + tool. Para mí, los puntos clave son los siguientes. 1) para el conocimiento base hace falta usar un buen LLM 2) es importante un prompt que guíe bien al LLM (para convertirlo en agente) 3) las funciones que no requieren juicio aparte se implementan como herramientas 4) cuando el flujo de agent+tool se vuelve complejo, se divide en subagentes con prompts enfocados y pocas herramientas para separar cada dominio

    • Al final, parece que esto evolucionará hacia un modelo de "coordinador" donde el agente de nivel superior decide qué hay que hacer y asigna qué agente es el adecuado para ese trabajo. Esta estructura puede continuar de forma recursiva (por ejemplo, un agente por cada producto, y ese agente se divide en agentes para frontend/backend). En esta estructura, los agentes que realmente ejecutan el trabajo solo necesitan concentrarse en un contexto y herramientas limitados, y el agente superior solo necesita saber qué pueden hacer los subagentes

  • Creo que deep agents = agentes con planificación añadida + combinación de herramientas para agentes, así que al final se parece a los agentes de siempre. Me decepciona un poco que LangChain parezca envolver incluso ideas simples de forma innecesariamente compleja y crear términos o conceptos nuevos solo para promocionarlos. Claro, supongo que si quieren vender más LangSmith, no les queda otra

    • Antes hacía este tipo de consultoría. No diría que es exactamente lo mismo, pero en esencia es un truco bastante común. Tomas algo ordinario, lo presentas como si fuera teatro, creas tu propia terminología y taxonomía, y luego la vendes. El siguiente paso es llenar de SEO tu propio concepto. Solo hay que subirse a keywords populares como deep * y agent... Pensar en estas cosas al final da esa sensación de que en entornos corporativos se te va drenando el alma

  • Se parece bastante a lo que esperaba. Ahora que ya está claro que escribir servidores MCP a mano no está funcionando tan bien, hace falta una forma nueva para subirse rápido a la ola. Últimamente la tendencia es crear agentes directamente, como gemini o claude code. La barrera de entrada es baja, tienen cierta utilidad, no hace falta conocimiento profundo de IA y además son fáciles de promocionar. Es como el enfoque de “cursor for X”, pero incluso se puede llevar a producto más rápido. Parece que van a aparecer muchísimos agentes de coding hechos así, aunque por ahora no se siente muy novedoso. Aun así, si se puede arrancar tan rápido, lo veo de forma positiva porque intuitivamente el valor de clones de claude code hechos a las apuradas va a converger pronto a 0

  • Sigo revisando y analizando el código de este repo https://github.com/ghuntley/claude-code-source-code-deobfuscation El autor hizo ingeniería inversa de Claude Code y explica bien la arquitectura. Cambié el enlace a un repo mejor

    • ¿Alguien puede explicar qué muestra esto? Solo parece un readme enorme y comandos del sistema

  • Estoy creando un agent cli+library de propósito general en rust: https://github.com/fdietze/alors Todavía está en una etapa temprana, pero ya lo estoy usando incluso para desarrollarlo. Se agradece feedback

  • En mi opinión, Junie de Jetbrains fue el primero en tener una función de lista de tareas de altísima calidad, y fue lo que más me gustó. Dejé de usarlo cuando pasó a ser de pago, pero en ese momento Junie era lento y cuidadoso. Cursor seguía sobrescribiendo archivos que no tenían problemas, y Claude se sentía como un punto intermedio

    • Cursor también ofrece una UI dedicada para la todo list y empuja al agente a usarla (la UX en sí está bien, pero no puedes ver directamente un archivo aparte). kiro de amazon usa un enfoque donde gestiona tanto las tareas como la especificación en tasks.md. Como ya hay muchas herramientas, al final conviene elegir la que mejor te funcione

  • La parte más interesante está completamente oculta. La clave es cómo se gestionan las tool calls, desde el parsing hasta la ejecución

  • Separar el contexto con sub agent es el verdadero punto innovador. Lo demás es solo un langgraph react agent

    • Tiene valor, pero en realidad no es una idea totalmente nueva

  • Me gustaría saber si hay más información sobre la parte donde la herramienta de todo list es un no-op. Quiero entender exactamente cómo funciona

    • Si quieres verlo directamente en código, nuestro agente Sketch usa la herramienta de TODO list de esta manera: https://github.com/boldsoftware/sketch/blob/main/claudetool/todo.go Hacer que el agente la use es relativamente fácil. La mayor parte del trabajo está en hacer que se vea en la UI
    • Tengo la misma pregunta. No entiendo bien qué significa. Pero claramente parece una de las razones por las que Claude Code destaca
    • Yo creo que en realidad es solo una función simple de concat. Muchas técnicas de prompting realmente útiles suelen ser fáciles de implementar. Por eso sorprende aún más lo lejos que llega una idea tan simple como TODO. (En entornos serios, los frameworks de agentes sí son difíciles. Por ejemplo, dar con la combinación y configuración correctas es muy complicado, y en infraestructura hay que cubrir multitenancy, multithreading, streaming, cancelación, etc.). Coincido totalmente en que la TODO list es importante. Incluso cosas como la competencia de análisis de logs de seguridad de louie.ai se aceleran muchísimo gracias a este método. Evita que el CoT se rompa tras unas pocas vueltas. Un aha moment interesante fue que usar nested todo (A.2.i...) funciona bien, y desde la perspectiva del LLM igual está linearizado, así que no le cuesta procesarlo. Nosotros, en vez de claude code, lo gestionamos internamente con un prompt de planificación de este estilo: https://github.com/graphistry/louie-py/blob/main/ai/prompts/PLAN.md
    • En el contexto solo se registra el hecho de que hubo una tool call. En realidad no vuelve a traer los datos de la todo list en sí
    • Según entiendo, sería algo así como simplemente un prompt que le dice que escriba una TODO list