Tutorial
Como implementar o Padrão Plan-and-Execute com Claude e MCP?
O padrão Plan-and-Execute separa a lógica do agente Claude em duas etapas: um Planejador, que decompõe uma meta complexa em uma lista estruturada de subtarefas, e um Executor, que processa cada item individualmente utilizando ferramentas via MCP. Essa arquitetura reduz alucinações, evita loops infinitos comuns no padrão ReAct e permite que o sistema revise o plano caso uma ferramenta retorne um erro inesperado durante a execução.
À medida que os agentes de IA se tornam mais autônomos, desenvolvedores enfrentam o desafio de manter a consistência em tarefas de longa duração. O padrão tradicional de ‘Reasoning and Acting’ (ReAct), onde o modelo decide o próximo passo a cada iteração, é excelente para tarefas curtas, mas tende a divergir do objetivo original em processos que exigem dez ou mais chamadas de ferramentas. É aqui que entra o padrão Plan-and-Execute, uma arquitetura que traz rigor e previsibilidade ao uso do Claude com o Model Context Protocol (MCP).
O que diferencia o Plan-and-Execute do ReAct tradicional?
No padrão ReAct, o Claude funciona como um motor de ‘próximo passo’. Ele analisa a situação, executa uma ferramenta e decide o que fazer em seguida. Embora flexível, esse fluxo consome muito contexto e pode resultar em ’esquecimento’ do objetivo principal.
No Plan-and-Execute, introduzimos uma separação de preocupações. O primeiro passo é o planejamento: o Claude recebe o objetivo e gera um DAG (Grafo Acíclico Dirigido) ou uma lista sequencial de passos. Somente após a validação desse plano, o Executor entra em cena. O Executor foca apenas na subtarefa atual, o que permite usar modelos menores e mais rápidos, como o Claude 3.5 Haiku, para a execução, enquanto o Claude 3.5 Sonnet atua como o arquiteto do plano. De acordo com a documentação da Anthropic, essa modularização é chave para sistemas robustos.
Como estruturar o Prompt do Planejador para o Claude?
O segredo de um bom planejamento reside na estruturação da saída. Recomendamos o uso de tags XML para delimitar o plano. O prompt deve instruir o Claude a decompor o problema sem tentar resolvê-lo imediatamente.
Exemplo de estrutura de saída esperada:
<plan>: Lista de passos numerados.<dependencies>: Quais passos dependem de saídas de passos anteriores.<tool_hints>: Quais servidores MCP devem ser consultados em cada etapa.
Ao utilizar o Model Context Protocol, o Planejador já deve ter acesso às definições das ferramentas (tools) para saber o que é possível executar, mas ele não as chama diretamente; ele apenas as referencia no plano.
Como integrar o Executor com Servidores MCP?
O Executor recebe o contexto da subtarefa e os resultados das etapas anteriores. Para cada passo do plano, o Executor realiza a chamada de ferramenta via MCP. Uma vantagem técnica crucial aqui é o isolamento do contexto.
| Recurso | Benefício no Plan-and-Execute |
|---|---|
| Token Economy | O Executor não precisa de todo o histórico do planejamento, apenas do passo atual. |
| Paralelização | Subtarefas sem dependências podem ser disparadas simultaneamente para diferentes servidores MCP. |
| Debugging | É fácil identificar se o erro foi no planejamento (lógica) ou na execução (ferramenta). |
Para implementar isso, você deve configurar um cliente MCP que gerencie as sessões. Segundo as docs do MCP, o cliente atua como o orquestrador que roteia as instruções do Executor para os servidores específicos (como bancos de dados SQL, APIs de busca ou sistemas de arquivos).
Como gerenciar erros e o ‘Re-planning’ dinâmico?
Planos raramente sobrevivem intactos ao contato com a realidade. Se um servidor MCP retornar um erro (ex: ‘permissão negada’ ou ‘registro não encontrado’), o Executor deve devolver esse feedback para o Planejador, e não tentar resolver o problema sozinho.
Este ciclo de feedback cria um agente resiliente. O Planejador analisa o erro, atualiza o restante do plano e fornece um novo roteiro ao Executor. Esse processo é muito mais estável do que o ReAct, onde um erro muitas vezes faz o modelo entrar em um loop repetitivo de tentativas frustradas. Recomenda-se utilizar as técnicas de Chain of Thought dentro do Planejador para que ele explique por que está alterando a rota.
Quais ferramentas facilitam essa implementação em 2026?
Embora você possa construir essa orquestração manualmente usando o SDK nativo da Anthropic, frameworks que suportam grafos de estado (como LangGraph ou instâncias customizadas de orquestradores MCP) são ideais. A chave é garantir que o estado do plano seja persistente.
Se você está usando o Claude Code, notará que ele já aplica nuances desse padrão ao analisar repositórios inteiros: ele primeiro mapeia a estrutura (plan) antes de sugerir edições (execute). Para sistemas personalizados, a implementação de um ‘Supervisor’ que valide se o Executor concluiu o passo conforme o planejado eleva a taxa de sucesso de 70% para mais de 95% em tarefas de integração de dados.
Leia mais no site
- MCP via WebSocket vs. Stdio: Qual a melhor arquitetura para agentes?
- Como implementar a arquitetura Router-Worker com Claude e MCP?
- MCP Server vs. Custom Tools: Quando usar cada abordagem no Claude?
- Como implementar Memória Persistente em Agentes Claude via MCP e SQLite?
- Como usar o MCP como barramento de estado para múltiplos Agentes Claude?
Perguntas frequentes
Quando devo preferir Plan-and-Execute em vez de ReAct?
Use Plan-and-Execute quando a tarefa for complexa (mais de 5 passos), exigir o uso de múltiplas ferramentas MCP distintas ou quando a previsibilidade for mais importante que a velocidade. O ReAct é melhor para diálogos simples e consultas rápidas onde o próximo passo é óbvio.
O padrão Plan-and-Execute gasta mais tokens?
Inicialmente sim, devido à etapa extra de planejamento. No entanto, em workflows longos, ele economiza tokens ao evitar que o Executor carregue logs de ferramentas irrelevantes de passos anteriores, mantendo o contexto focado apenas na subtarefa atual.