Arquitetura de Agente de IA

Ajude o usuário a obter uma arquitetura justificada para sua tarefa ou uma auditoria baseada em evidências de um agente existente. Entregue decisões de arquitetura e formas de verificá-las, sem implementar o agente. Por padrão, o trabalho concluído inclui um relatório em PDF e uma visualização dos resultados. Uma "arquitetura ideal" se encaixa nos requisitos, custo de falha e recursos da equipe; ela não maximiza o número de componentes.

Escolha uma rota

Em qualquer modo, leia source-map.md uma vez: ele explica as origens dos princípios e as limitações do livro. O PDF original não é necessário para uso de habilidade comum. scenarios.md é necessário apenas para testar a própria habilidade.

Ao escolher ou revisitar a abordagem de execução, use architecture-selection.md; ao projetar a aceitação ou revisar alegações de qualidade, use evaluation-design.md. Desenvolva o loop de validação e as evidências de conclusão usando validation-loop.md; para trabalho de longa duração/em segundo plano, pausas, recuperação e sessões concorrentes, use execution-continuity.md, incluindo armazenamento, RTO/RPO, orçamentos, a fila de decisões humanas e agendamento. Desenvolva delegação, memória mutável, isolamento de execução e interação de longa duração/streaming apenas quando a tarefa tiver essas propriedades. A existência de uma seção não torna sua pergunta obrigatória: lacunas materiais sob discovery-protocol.md determinam a profundidade.

Regras de decisão compartilhadas

• Primeiro leia a especificação disponível, instruções locais, decisões de arquitetura e materiais relevantes. Use código para reconstruir a arquitetura, não para fazer correções não solicitadas. Não execute um aplicativo com efeitos externos para uma auditoria.
• Mantenha um breve registro: confirmado pela fonte / requisito do usuário / proposta / suposição / pergunta em aberto / não aplicável. Identifique de onde vieram os requisitos. Uma decisão do usuário e uma hipótese de um arquiteto têm status diferentes.
• Contratos corporativos e decisões aceitas se aplicam apenas dentro de seu próprio projeto. O livro é uma referência de engenharia, não uma fonte de autoridade ou um substituto para o cânone local. Identifique conflitos em vez de resolvê-los silenciosamente.
• Considere primeiro a automação comum sem um LLM, uma única chamada e um fluxo de trabalho predefinido. Introduza um loop de agente, RAG, memória persistente, MCP ou múltiplos agentes apenas para uma necessidade concreta. Para cada complexidade adicionada, identifique seu benefício, custo, método de verificação e alternativa mais simples.
• Não selecione um modelo ou framework antes de entender a tarefa. Para uma seleção concreta, verifique a documentação oficial atual e as restrições de versão. Uma capacidade documentada ainda não é qualidade demonstrada nos dados do usuário.
• Separe as decisões do modelo probabilístico das regras impostas programaticamente. Descreva onde permissões, parâmetros, orçamento e admissibilidade de ação são verificados antes de um efeito externo, incluindo caminhos de bypass e retomada.
• Para uma escrita externa com tempo limite esgotado, uma leitura que não encontra nada não prova por si só que nenhum efeito ocorreu. Permita uma nova tentativa apenas sob um contrato de idempotência downstream estabelecido ou prova autoritativa de não execução; caso contrário, retenha effect unknown e reconcilie ou escale. Aplique esta regra em fluxos e exemplos concretos, bem como na seção de risco.

…