Modelos de design de agente AI: Escolha-se por Contenção de falha

Os padrões de design do agente AI devem ser escolhidos pelo limite de falha que pode operar. Comece com uma chamada direta de modelo ou um agente com ferramentas. Adicionar etapas sequenciais, ramificações paralelas, transferências especializadas ou um ciclo de revisão somente quando um requisito de carga de trabalho medido justifica a nova topologiae somente quando você pode registrar a evidência que a topologia precisa. Essa resposta é menos glamorosa do que atrair uma frota de agentes colaboradores. Também é mais fácil de defeitos, mais barato de executar e mais difícil confundir com um sistema saudável quando parte do trabalho desapareceu. A regra central é simples: Cada nova execução cria uma dívida de provas. Não adicione a borda até que possa nomear o seu estado falso verde e o recibo que o refutar. Este artigo aplica essa regra a seis opções comuns: uma chamada de modelo direta, um único agente, um pipeline sequencial, ventilador paralelo, transferência especialista e um ciclo de revisão limitado. Inclui um selector determinista reproduzido contra seis cargas de trabalho. Comece por baixo de agent a menos que a tarefa ganhe autonomia Um diagrama de arquitetura deve começar com o mecanismo menos poderoso que possa satisfazer o contrato de tarefa. Uma classificação ou tradução de um passo geralmente não necessita nem de ferramentas nem de um ciclo de agentes. A questão da saúde é simplesmente se a produção atende a uma afirmação definida. Um único agente torna se útil quando a tarefa é aberta o suficiente para exigir várias decisões ou chamadas de ferramentas. Um agente de apoio a pedidos, por exemplo, pode interpretar um pedido, recuperar um pedido e compor uma resposta. Ainda tem um proprietário e um local para verificar o resultado. Isto é coerente com as orientações oficiais atuais. Guia de padrões de agentes do Google Clouds diz para definir a complexidade da tarefa, latência, custo e envolvimento humano requisitos antes de selecionar um padrão. Recomenda começar com um agente durante o desenvolvimento inicial e observa que os projetos de vários agentes adicionam avaliação, segurança, confiabilidade e preocupações de custo. O Centro de Arquitetura Azure recomenda igualmente a menor complexidade que satisfaça com fiabilidade os requisitos; ele chama a coordenação de custos, latência e modos de falha adicionais em sistemas multi agentes. Use este primeiro limite de decisão: Propriedade de carga de trabalho Default razoável Prova de conclusão Uma transformação limitada, sem ferramentas. Convocatória de modelo direta A saída passa a afirmação de tarefa Várias decisões dentro de um domínio Agente único com ferramentas Os efeitos necessários das ferramentas e o resultado final são verificados Estações fixas com dependências estritas Pipeline sequencial Cada fase consumiu a versão antecessora esperada Subtarefas independentes cuja latência é importante Ventilador paralelo Cada ramo requerido é contabilizado antes da agregação Roteamento dinâmico entre domínios ou autoridades distintos Transferência de especialistas Um receptor aceitou a propriedade e pode retomar a partir de um cursor duradouro A revisão deve continuar até que uma condição mensurável se mantenha Localização limitada O progresso mudou, o verificador passou e o orçamento de iteração manteve se A mesa é por padrão, não é um desenho automático. Uma chamada direta pode ainda ser insegura se a sua saída desencadear uma ação irreversível. Um único agente pode ainda ser muito amplo se tiver dezenas de ferramentas com permissões incompatíveis. O padrão segue a carga de trabalho e o limite de autoridade. A restrição importante consiste em evitar o tratamento da decomposição como de livre confiabilidade. Dividir uma tarefa entre mais componentes pode melhorar a especialização, a latência ou o isolamento de segurança. Também cria estados mais parciais. O operador deve ser capaz de dizer em que estado ocupa a corrida sem ler uma mensagem final persuasiva. Faça com que cada topologia pague a sua dívida de evidências O Orientações de AWS descreve os padrões de agentes como blocos de construção reutilizáveis e compostos. A reutilização é valiosa, mas a composição muda o que significa "feito". Um componente do relatório de sucesso é apenas a evidência da atividade. A questão útil é saber se toda a topologia produziu o resultado pretendido. Sequenciais: provar a cadeia, não a última etapa Um padrão sequencial é adequado quando a ordem dos estágios faz parte da correcção: extrair, validar, aprovar e depois publicar. O caso falso verde aparece quando uma fase posterior corre após uma fase anterior falhar, usar saída obsoleta ou produzir uma versão incompatível. Dê a cada etapa um recibo que contenha pelo menos: A identificação de execução e a identificação do estágio; O recibo ou o hash de entrada do antecessor; O hash de saída ou o ID de efeito duradouro; Estado terminal e tempo de conclusão; A afirmação que permite a próxima etapa. A próxima etapa deve rejeitar um antecessor perdido ou incompatível em vez de adivinhar. Um evento final publish completed não pode reparar um recibo de validação ausente. Paralelamente: congelar a adesão antes da conclusão da contagem A extensão paralela é justificada quando os ramos independentes reduzem a latência ou recolhem evidências distintas. Seu fracasso característico é um coletor que retorna uma resposta polida enquanto um ramo necessário está ausente, duplicado, atrasado ou baseado em entrada obsoleta. Congelar um manifesto de ramo antes do envio. Marcar os ramos necessários ou opcionais. Então, define um quórum sobre o manifesto congelado, não sobre quais as respostas que aconteceram de chegar. O coletor precisa de identidade de ramo, versão de entrada, status terminal, identidade de efeito e frescura. Tres respostas recebidas não são suficientes se forem necessárias quatro. Transferência: transferência de propriedade, não apenas contexto Uma transferência especialista é útil quando o próximo agente precisa de um domínio diferente, conjunto de ferramentas ou limite de permissão. Ele falha silenciosamente quando o remetente relata transferido mas o receptor nunca aceitou o trabalhoou aceitou o sem o estado necessário para continuar. Uma transferência duradoura requer dois lados: 1. O remetente registra o receptor previsto, a identificação de trabalho, a versão contextual e o resultado restante; 2. O receptor registra a aceitação, a sua época de propriedade e um cursor de currículo. Até a aceitação existir, o trabalho está à espera do remetente. Após a aceitação, só o receptor pode cometer o próximo efeito. Isto evita uma lacuna ambígua e reduz o duplicado de trabalho após as reapreciações. Loop: progresso orçamental, não apenas iterações Um ciclo de verificação de gerador crítica ou de reparação verificação é adequado quando a qualidade melhora através de uma avaliação repetida. Não é apropriado apenas porque o primeiro resultado pode ser fraco. O circuito deve ter um sinal de progresso mensurável, um verificador e uma condição de parada. Registo: Número de iterações e máximo; prazo e custo restante; As impressões digitais de entrada e saída; um delta de progresso específico de domínio; Resultado do verificador; razão para continuar, parar ou escalar. Um ciclo que repete diferentes redações sem alterar testes, restrições ou o artefato esperado é ativo, mas não progride. Pára o antes de consumir o orçamento final necessário para preservar provas, recuar ou perguntar a alguém. Repete uma regra de seleção antes de adotar o diagrama Convertei os limites anteriores em um pequeno selector determinista. Prefere deliberadamente padrões mais simples. A prioridade é explícita para que uma carga de trabalho que precisa de um verificador iterativo não caia acidentalmente na categoria sequencial apenas porque seus passos têm uma ordem. O artefato completo usa pattern cases.json , select agent pattern.mjs , e um relatório esperado. Faça isso com: A repetição de seis casos produziu a paridade exata esperada: Carga de trabalho Padrão selecionado Receita obrigatória Classificar uma mensagem Convocatória de modelo direta Asserção de entrada/saída Procure uma ordem e responda. Agente único Manifesto de execução, recibos de efeitos de ferramenta, afirmação de resultados Extracção, revisão, publicação Sequenciais Cadeia de recepção de estágio, versão de entrada, estado de parada na falha Pesquisar quatro fontes independentes Ventilador paralelo Manifesto do ramo congelado, quórum exigido, afirmação agregada Apoio de rota para um especialista Transferência de especialistas Receita de propriedade, cursor de prossecução, afirmação final Revisar o código até os testes passarem Localização limitada Orçamento de iteração, delta de progresso, veredicto do verificador Todas as seis recomendações coincidem, e todas as seis emitem uma obrigação de prova distinta. Esse segundo resultado importa mais do que a precisão do selector. Um nome de modelo sem o seu contrato de recepção é uma preferência de design, não uma decisão operacional. Três observações surgiram da repetição. Primeiro, a topologia mapeia a ambigüidade para a evidência. Os estágios sequenciais criam ambiguidade de conclusão parcial; ramos paralelos criam ambiguidade de adesão; transferências criam ambiguidade de propriedade; loops criam ambiguidade de terminação. Em segundo lugar, a mesma afirmação final continua necessária em todos os padrões. Um manifesto completo da sucursal prova a contabilidade da sucursal, não que o relatório reunido tenha respondido à pergunta do cliente. Um recibo de entrega prova a propriedade, não a entrega. Um veredicto de crítico que passa prova apenas os critérios que o crítico realmente avaliou. Em terceiro lugar, os gatilhos de migração são mais confiáveis do que o entusiasmo por padrões. Afaste se de um agente quando as evidências mostram sobrecarga de ferramentas, um limite de segurança rigoroso, latência independente ou uma falha recorrente que a topologia mais simples não pode conter. Multi agent é mais escalável não é um gatilho mensurável. Tratar o padrão como um contrato operacional Antes da implementação, escreva um contrato de uma página para o padrão escolhido: I Resultado pretendido: Que artefacto ou efeito observável deve existir? A Autoridade: Qual componente pode fazer cada alteração reversível ou irreversível? Membro: Que estágios, ramos ou especialistas pertencem a esta corrida? Progresso: O que muda quando avança um trabalho útil? Espera: Que dependência ou decisão humana suspende legitimamente o trabalho? Falha: Que evidência separa um erro transitório de uma corrida bloqueada? Completamento: Quais verificações deterministas eliminam o trabalho? Budget: O que limita o tempo, as retemptadas, os tokens e os efeitos colaterais? Em seguida, injetar a falha característica da topologia antes do lançamento. Remova um recibo de fase sequencial. Deixe cair um ramo paralelo necessário. Adiar a aceitação da entrega. Retorna um artefato inalterado de uma iteração de revisão. O sistema deve ficar bloqueado, aguardando ou incerto. Há aqui uma limitação prática. O selector não pode provar que a descrição da carga de trabalho é correta. Não mede a qualidade do modelo, a disponibilidade do fornecedor ou a fiabilidade real de uma estrutura. Um esquema de recibo também não pode provar que a sua implementação emite eventos verdadeiros. Avaliar o padrão escolhido com aparelhos em forma de produção, injeção de falha e verificações de resultados no nível do destino. A questão de revisão mais segura não é, portanto, Qual é o melhor padrão de design do agente AI? É: Qual é o padrão menos complexo que satisfaz esta carga de trabalho, e podemos provar os seus novos estados parciais sem inspecionar o conteúdo privado? Se a resposta for uma chamada direta ou um agente, guarda a. Se a resposta for uma topologia mais complexa, faça com que os seus recibos façam parte do projeto em vez de um projeto de monitorização posterior. O Sidewisp destina se a adicionar uma camada de saúde em torno dos tempos de execução dos agentes existentes, com atenção à acessibilidade, ao progresso útil, ao contexto, às ferramentas, aos resultados e ao custo. A Sidewisp está atualmente em prévia privada. O seu site público e demonstração interativa estão ao vivo, mas a coleção de agentes de produção e os adaptadores de tempo de execução não são enviados no repositório atual do site. Se esta abordagem de evidências coincidir com a forma como deseja operar agentes, pode juntar se à lista de espera de pré visualização privada.