O framework DeepAgents da LangChain

 (blog.langchain.com)
21 pontos por GN⁺ 2025-08-07 | 1 comentários | Compartilhar no WhatsApp
  • Enquanto os agentes tradicionais baseados em LLM geralmente seguem uma estrutura de "agente raso (shallow)", apenas repetindo chamadas de ferramentas, os Deep Agents são agentes de IA planejados e estruturados capazes de resolver com profundidade até tarefas complexas e de longo prazo
  • Agentes recentes como Deep Research, Manus e Claude Code implementam "agentes profundos" com capacidade de explorar tópicos mais a fundo e gerenciar contexto
    • Prompts de sistema detalhados, ferramentas de planejamento, subagentes e uso do sistema de arquivos são os elementos centrais dos "agentes profundos"
  • A LangChain lançou o pacote open source deepagents para que qualquer pessoa possa criar facilmente um deep agent adequado ao seu próprio vertical (domínio)
    • É possível configurar prompts, ferramentas e subagentes personalizados, oferecendo um framework de uso geral aplicável a várias áreas, como pesquisa e desenvolvimento

Limites dos agentes LLM existentes e características dos Deep Agents

  • Agente tradicional: o LLM roda em loop e apenas chama ferramentas → adequado apenas para contexto curto e tarefas simples de curto prazo
  • Deep Agents: conseguem decompor, planejar, acompanhar e colaborar por conta própria mesmo em objetivos de longo prazo e tarefas complexas

Os 4 elementos que compõem os Deep Agents

  1. Prompt de sistema detalhado

    • Como em casos representativos como Claude Code, usa prompts que descrevem em detalhe como usar ferramentas e exemplos de comportamento
    • Instruções complexas e exemplos few-shot induzem um raciocínio e uma execução mais "profundos"

  2. Ferramenta de planejamento (Planning)

    • Mesmo sem função real, incluir uma ferramenta de planejamento como uma "lista de tarefas" na rotina ajuda a manter o gerenciamento de contexto e a capacidade de execução
    • Mesmo sendo no-op (sem fazer nada), ela fornece contexto no prompt

  3. Subagentes (Sub Agents)

    • Criam e dividem subagentes por subtarefa, e cada agente trabalha individualmente antes de integrar os resultados
    • Mesmo problemas grandes e complexos podem ser tratados com uma estrutura paralela e de divisão de trabalho

  4. Sistema de arquivos

    • Além de trabalho real com arquivos, ele é usado como repositório de notas e contexto
    • Vários agentes e subagentes compartilham o sistema de arquivos para colaborar e manter contexto de longo prazo

O framework Deep Agents da LangChain: deepagents

  • Pacote Python open source (pip install deepagents), com configuração de prompts, ferramentas e subagentes personalizados
    • Prompt de sistema inspirado no Claude Code, mas ajustado para ser mais geral
    • Ferramenta de planejamento com lista ToDo no-op (igual ao Claude Code)
    • Suporte à criação de subagentes e personalização deles
    • Sistema de arquivos virtual usando conceitos do LangGraph (com base no estado do agente)
  • Também oferece como exemplo um agente de deep research, facilitando a criação de agentes especializados por vertical

Exemplos de uso e valor

  • Otimizado para tarefas de IA de longo prazo e multifacetadas, como pesquisa e desenvolvimento, geração de código, research e automações complexas
  • Projeto detalhado de contexto e estrutura de divisão de trabalho permitem gerar resultados mais profundos
  • Qualquer pessoa pode criar um "deep agent" adequado ao seu domínio — apontando para a próxima etapa do uso de IA

Leituras relacionadas

1 comentários

 
GN⁺ 2025-08-07
Comentários do Hacker News

  • Sou o autor. Ultimamente, fiquei impressionado com como uma série de agentes como claude code, manus e deep research executam especialmente bem tarefas de longo prazo. Na prática, por dentro, o LLM fica em loop chamando ferramentas. Mas, se você fizer isso sem pensar muito, surge o problema de o LLM não conseguir lidar direito com tarefas complexas ou longas. Então fiquei curioso sobre como outros agentes resolvem isso. O que encontrei em comum foi o seguinte: 1) usam uma ferramenta de planejamento 2) usam subagentes 3) usam uma estrutura que faz offloading de contexto, como um sistema de arquivos 4) projetam prompts de sistema detalhados (prompt engineering ainda é importante). Cada item já existia antes, mas não são formas tão amplamente usadas quando se desenvolvem agentes na prática. Acho que a percepção importante está justamente nessa combinação. Feedback é bem-vindo

  • Pensando nas várias opiniões, concordo que o conceito de deep agents no fim também não é tão diferente da combinação agent + tool. Para mim, os pontos centrais são os seguintes. 1) para o conhecimento básico, é preciso usar um bom LLM 2) o prompt para guiar corretamente o LLM é importante (transformá-lo em agente) 3) funcionalidades que não exigem julgamento separado devem ser implementadas como ferramentas 4) quando o fluxo agent+tool fica complexo, ele deve ser dividido em subagentes com prompts focados e poucas ferramentas, separando cada domínio

    • No fim, parece que isso vai evoluir para um modelo de “coordenador”, em que o agente de nível mais alto escolhe o que precisa ser feito e distribui para qual agente é mais adequado para aquela tarefa. Essa estrutura pode continuar recursivamente (ex.: há um agente para cada produto, e esse agente se ramifica em agentes responsáveis por trabalho de frontend/backend). Nessa estrutura, os agentes que realmente executam o trabalho só precisam focar em contexto e ferramentas limitados, e o agente superior só precisa entender o que os subagentes conseguem fazer

  • Acho que deep agents = agente com planejamento adicionado + combinação de ferramentas de agente, então no fim é parecido com agentes que já existiam. É uma pena que a LangChain pareça sempre empacotar até conceitos simples de forma complicada e criar termos ou conceitos novos sem necessidade para promover isso. Claro, para vender mais LangSmith talvez não tenha jeito

    • Eu fazia esse tipo de consultoria no passado. Não dá para dizer que é exatamente igual, mas, em essência, é um truque comum. Você embrulha algo banal como se fosse um espetáculo, cria sua própria terminologia e taxonomia, e vende isso. O próximo passo é inundar SEO com o seu conceito. Dá para surfar em palavras-chave populares como deep * e agent... quando penso nesse tipo de coisa, no fundo dá uma sensação de esvaziamento da alma no ambiente corporativo

  • É mais ou menos o resultado que eu esperava. Agora que ficou claro que escrever servidores MCP diretamente não está funcionando muito bem, a situação pede um método novo que possa pegar embalo rápido. A tendência hoje é construir agentes diretamente, como gemini ou claude code. A barreira de entrada é baixa, há alguma utilidade, não exige conhecimento profundo de IA e é fácil de divulgar. É tipo a abordagem “cursor for X”, mas dá para transformar em produto ainda mais rápido. Acho que vai surgir uma quantidade enorme desses agentes de programação, mas por enquanto ainda não parece haver muita novidade. Mesmo assim, vejo de forma positiva que, se dá para começar tão rápido assim, o valor de clones intuitivos de claude code deve convergir para zero em breve

  • Estou acompanhando e analisando continuamente o código deste repositório https://github.com/ghuntley/claude-code-source-code-deobfuscation O autor faz engenharia reversa do Claude Code e explica bem a arquitetura. Troquei o link para um repositório melhor

    • Você pode explicar o que isso mostra? Para mim, parece que só há um readme enorme e comandos de sistema

  • Estou criando uma cli+biblioteca de agente genérica em rust: https://github.com/fdietze/alors Ainda está no começo do desenvolvimento, mas já estou usando para desenvolver ela mesma. Feedback é bem-vindo

  • Na minha visão, o Junie da Jetbrains foi o primeiro a ter uma funcionalidade de to do list realmente de altíssima qualidade, e foi o que mais gostei. Depois que virou pago, não usei mais, mas naquela época o Junie era lento e cuidadoso. O Cursor continuava sobrescrevendo até arquivos sem problema, e o Claude parecia algo intermediário entre os dois

    • O Cursor também oferece uma UI dedicada para to do list e induz o agente a usá-la (a UX em si é boa, mas você não consegue ver diretamente um arquivo separado). O kiro da amazon usa uma abordagem em que gerencia tanto o que deve ser feito quanto a especificação em tasks.md. Como agora existem muitas ferramentas, basta escolher a que se adapta melhor a você

  • A parte mais interessante está totalmente escondida. O ponto crucial é como ele gerencia as tool calls desde o parsing até a execução

  • Separar o contexto com subagentes é realmente o ponto inovador. O resto é só um agente react do langgraph

    • Isso tem valor, mas não é exatamente uma ideia totalmente nova

  • Gostaria de saber se há mais informação sobre a parte em que a ferramenta de to do list é um no-op. Quero entender exatamente como isso funciona

    • Se quiser ver direto no código, o Sketch agent que criamos usa a ferramenta de TODO list mais ou menos assim: https://github.com/boldsoftware/sketch/blob/main/claudetool/todo.go Fazer o agente usar isso é relativamente fácil. A maior parte do trabalho está em exibir isso na UI
    • Mesma pergunta. Não entendi muito bem o que isso significa. Mas claramente parece ser uma das razões pelas quais o Claude Code é excelente
    • Na minha opinião, é só uma funcionalidade simples de concat. Na prática, técnicas de prompt realmente úteis quase sempre são simples de implementar. Justamente por isso é ainda mais surpreendente que a ideia simples de TODO vá tão longe! (Em ambientes sérios, frameworks de agentes são difíceis mesmo. Ex.: acertar a combinação e a configuração certas é realmente complicado, e na infraestrutura há muita coisa a cobrir, como multitenancy, multithreading, streaming, cancelamento etc.). Concordo totalmente que a TODO list é importante. Coisas como a competição de análise de logs de segurança da louie.ai também ficam muito mais rápidas graças a esse método. Isso evita que o CoT se degrade depois de apenas alguns turnos. Um aha moment interessante foi perceber que usar TODOs aninhados (A.2.i...) funciona bem e, do ponto de vista do LLM, como no fim isso é linearizado, não é difícil de processar. Em vez de claude code, nós gerenciamos internamente com um prompt de plano desse tipo: https://github.com/graphistry/louie-py/blob/main/ai/prompts/PLAN.md
    • Só o fato de que houve uma tool call é registrado no contexto. Os dados reais da to do list em si não são carregados de volta
    • Pelo que entendo, é basicamente algo como um prompt dizendo para escrever uma TODO list