Resumo Técnico: Decomposição de Tarefa Estruturada em Tempo de Execução para Sistemas de Codificação Agêntica

Declaração do Problema

Os sistemas atuais de codificação agêntica (por exemplo, aqueles construídos sobre AutoGen, LangGraph e Claude Code) frequentemente dependem de prompts monolíticos para codificar a lógica da tarefa, o fluxo de controle e a geração de saída. Embora frameworks recentes tenham introduzido abstrações programáticas para orquestração, suas estratégias de decomposição de tarefas são tipicamente estáticas, o que significa que a estrutura da tarefa é fixa no momento do projeto.

Essa abordagem arquitetural leva a três desafios principais de engenharia de produção:

1. Comportamento Frágil: Os sistemas lutam para se adaptar quando as saídas intermediárias são inválidas ou quando condições de ramificação surgem em tempo de execução.
2. Baixa Depurabilidade: As falhas são difíceis de isolar dentro de um único contexto de prompt grande.
3. Recuperação Custosa: Quando uma etapa falha, o sistema frequentemente requer uma reexecução completa do pipeline ou a reexecução de todas as subtarefas a jusante, resultando em altos custos de tokens e latência.

A questão central abordada é se a decomposição de tarefas por si só reduz os custos de recuperação, ou se o ramificação em tempo de execução baseada em sinais intermediários validados é o mecanismo necessário para eficiência.

Metodologia

Os autores propõem a Decomposição de Tarefa Estruturada em Tempo de Execução (RSTD), um padrão arquitetural que externaliza as decisões de partição de tarefas do texto de prompt estático para fluxo de controle executável.

Arquitetura Central

O sistema separa orquestração, gerenciamento de estado e inferência de LLM em três camadas distintas:

1. Motor de Decomposição: Governa a partição de tarefas em tempo de execução usando lógica condicional autorizada pelo desenvolvedor. As decisões de ramificação são resolvidas dinamicamente com base em sinais de tempo de execução:
   • Resultados de validação de esquema.
   • Conteúdo de saída (por exemplo, resultados não vazios ou limites de confiança).
   • Status de conclusão da subtarefa.
2. Operadores de Julgamento: As chamadas de LLM são escopadas para tarefas de raciocínio únicas com requisitos de saída explícitos e validados por esquema. Se a validação falhar, o sistema aciona um prompt de reparo direcionado em vez de uma reexecução completa do pipeline.
3. Gerenciador de Estado: Persiste resultados intermediários validados chaveados por identificador de subtarefa. As subtarefas a jusante acessam o estado anterior explicitamente por chave, garantindo contexto limitado por chamada.

Configuração Experimental

Os autores avaliaram o RSTD contra duas linhas de base em duas cargas de trabalho de engenharia de software (10 execuções cada):

• Monolítico: Toda a lógica da tarefa codificada em um único prompt.
• Decomposição Estática: O mesmo grafo de subtarefas do RSTD, mas executado sequencialmente sem ramificação em tempo de execução (execução fixa).
• RSTD: A abordagem proposta com ramificação controlada em tempo de execução e retry seletivo.

Cargas de Trabalho:

1. Depuração de Código Multiarquivo: Um pipeline Python com três bugs causalmente ordenados em dois arquivos.
2. Análise de Causa Raiz (RCA) do Kubernetes: Diagnosticar um evento OOMKill envolvendo análise de logs, detecção de anomalias e planejamento de remediação.

Métricas: Consumo de tokens (custo de retry), latência e correção. As taxas naturais de falha de validação de esquema foram baixas (0–2%), portanto, o "custo de retry" foi medido sob falha simulada (entrada a montante estruturalmente malformada) para isolar os custos de recuperação arquitetural.

Principais Resultados

1. A Decomposição Estática Não Garante Redução de Custos

Contrariando a suposição de que quebrar tarefas é inerentemente mais eficiente, a linha de base de Decomposição Estática frequentemente aumentou os custos de retry em comparação com a linha de base Monolítica.

• RCA do Kubernetes: O custo de retry estático foi de 1.632 ± 145 tokens, excedendo a linha de base Monolítica (904 ± 17 tokens) em 80,5%. Isso ocorreu porque a execução sequencial fixa forçou a reexecução de todas as subtarefas a jusante (3, 4 e 5) após uma falha na subtarefa 3.
• Depuração Multiarquivo: O custo de retry estático (933 tokens) foi 32,7% maior que o Monolítico (703 tokens) devido à reexecução em cascata de tarefas a jusante.

2. O RSTD Alcança Economias Significativas de Recuperação

Ao fazer retry apenas na subtarefa falhada enquanto preserva o estado válido a montante, o RSTD reduziu drasticamente os custos de recuperação:

• RCA do Kubernetes: O custo de retry do RSTD caiu para 436 ± 132 tokens, uma redução de 51,7% sobre o Monolítico e uma redução de 73,2% sobre a Decomposição Estática.
• Depuração Multiarquivo: O custo de retry do RSTD foi de 460 tokens, uma redução de 34,6% sobre o Monolítico.

3. Sobrecarga e Correção

• Correção: Todas as configurações alcançaram 100% de correção em todas as 10 execuções para ambas as cargas de trabalho.
• Sobrecarga de Linha de Base: O RSTD incorre em um custo de tokens de linha de base mais alto durante a execução bem-sucedida (por exemplo, 2.225 tokens versus 703 tokens na depuração) devido a múltiplas chamadas de API e sobrecarga do framework.
• Latência: A sobrecarga do framework representou aproximadamente 18% da latência total de relógio de parede. A lacuna de latência entre agentes monolíticos e decompostos foi impulsionada principalmente por viagens de ida e volta adicionais de API, e não por ineficiência de orquestração.

Significado e Alegações

O artigo afirma que o ramificação em tempo de execução, e não apenas a estrutura de decomposição, é o mecanismo primário para reduzir os custos de recuperação em sistemas agênticos.

• Distinção Arquitetural: O RSTD distingue-se de frameworks existentes (DSPy, LangGraph, AutoGen) ao externalizar o fluxo de controle. Diferentemente das Declarações do DSPy, que otimizam prompts dentro de um módulo, o RSTD impede que saídas malformadas alcancem subtarefas a jusante, bloqueando transições de estado.
• Implicações Operacionais:
  • Retry Seletivo: Permite recuperação eficiente em custos ao isolar falhas em subtarefas individuais.
  • AgentOps Direcionado: Os limites de subtarefa fornecem pontos de instrumentação naturais para monitoramento e depuração.
  • Substituição de Modelo: A arquitetura permite que diferentes modelos sejam atribuídos a subtarefas específicas sem reconfigurar a camada de orquestração.

Os autores concluem que, embora o RSTD introduza uma sobrecarga fixa para execuções bem-sucedidas, é o padrão superior para cenários de produção onde as taxas de falha são não triviais ou onde as subtarefas envolvem reingestão de contexto dispendiosa. O estudo destaca que simplesmente decompor tarefas estaticamente é insuficiente; é necessário um fluxo de controle dinâmico e validado para prevenir custos de reexecução em cascata.