Engenharia de comportamento agêntico

Os LLMs (modelos de linguagem grande) são não determinísticos por natureza. A mesma entrada pode nem sempre produzir a mesma saída. Métodos de teste tradicionais lutam para considerar essa variabilidade. Como você pode adaptar seu processo de desenvolvimento para ter a confiança de que seu sistema funcionará consistentemente conforme o esperado?

A transformação de IA empresarial levanta mais questões: Como você protege e governa o conhecimento proprietário? Como você projeta um comportamento confiável? Como você usa evidências de execução para melhorar o sistema ao longo do tempo?

A ABE (engenharia de comportamento agêntico), conforme proposto por este artigo, é uma metodologia independente de plataforma para especificar, fundamentar, controlar, verificar e observar o comportamento dos agentes de IA. A metodologia ajuda você a esclarecer as necessidades do usuário e do sistema, definir resultados esperados, impor limites de execução e verificar as alterações com base em cenários representativos. Os testes tradicionais podem confirmar que uma implementação específica funciona conforme o esperado, mas geralmente não detectam totalmente o descompasso comportamental causado por alterações em modelos, prompts, ferramentas ou fontes de dados. A ABE aborda esse desafio tornando o comportamento desejado explícito e continuamente verificável, permitindo que as equipes evoluam sistemas agênticos sem perder a confiança em seus resultados.

Conceitos principais

O artefato chave em ABE é o contrato de comportamento. O contrato define o comportamento necessário separadamente da implementação para que as expectativas permaneçam explícitas e verificáveis conforme o sistema muda. Em sistemas agênticos, modelos, prompts, implementações de ferramentas, fontes de conhecimento, memória, políticas, orquestração e acesso do usuário podem mudar ao longo do tempo. Use contratos de comportamento para avaliar o efeito dessas alterações no comportamento necessário para identificar o descompasso e resolvê-lo.

Contrato de comportamento

Um contrato de comportamento define o que um agente deve e não deve fazer em uma situação limitada. Especifica:

• A situação, os atores e o escopo no qual o contrato se aplica.
• Desfechos aceitáveis e características de resultado necessárias.
• Conclusões, divulgações, ações e efeitos colaterais proibidos.
• Evidência necessária antes que o agente possa concluir ou agir.
• Comportamento quando as evidências são insuficientes ou as dependências falham.
• Escalonamento, aprovação e condições de parada.

O contrato torna explícitos os requisitos aplicáveis de segurança e de IA responsável. Defina esses requisitos durante o design para que sua equipe possa incorporá-los à implementação e verificação desde o início. Para obter diretrizes sobre como definir responsabilidades e políticas específicas de carga de trabalho, consulte IA Responsável em cargas de trabalho do Azure.

Um contrato de comportamento compartilha um princípio com design por contrato: tornar as obrigações de software explícitas. Ele define o comportamento necessário sem prescrever uma implementação, de modo que os requisitos podem permanecer estáveis conforme a implementação muda.

Use um contrato para uma situação delimitada e vários cenários para as variações. Crie outro contrato quando os atores, a autoridade, as evidências necessárias ou os resultados aceitáveis mudarem materialmente.

As equipes de produto e engenharia mantêm em conjunto o contrato de comportamento como um ativo com versão. O Product Owner, com suporte de especialistas em domínio, aprova o comportamento pretendido e os resultados esperados. A engenharia é coautora de restrições técnicas e requisitos de evidência e mantém definições de cenário testáveis, cobertura, controle de versão e verificação.

Examine as alterações nas expectativas comportamentais em conjunto e execute a revisão de segurança e risco quando necessário. A manutenção técnica que preserva essas expectativas deve seguir o processo de revisão de engenharia da equipe. Para obter diretrizes relacionadas, consulte propriedade da especificação funcional e responsabilidades da estratégia de teste.

Exemplo: aprovar revisões de produtos de baixo risco

Um site de varejo exige que sua equipe de padrões verifique as avaliações de produtos de clientes em relação a uma política de uso aceitável antes da publicação. A equipe de carga de trabalho deseja que um agente aprove envios de baixo risco, e envie casos de maior risco ou incertos para a equipe de padrões. A meta é reduzir a revisão manual, mantendo os padrões de publicação do site.

A tabela a seguir apresenta um contrato de comportamento com controle de versão para este agente.

Você pode manter o contrato em JSON, YAML, Markdown, um documento Word ou PDF. Escolha um formato que seus product owners, especialistas em domínio e engenheiros possam examinar e versionar juntos. JSON ou YAML podem facilitar a leitura de campos individuais por ferramentas. Qualquer formato escolhido, mantenha uma versão autoritativa e vincule cenários e resultados de avaliação a ela.

Neste exemplo, a política permite comentários negativos sobre produtos e requer revisão humana de envios que contêm informações pessoais. Um cliente envia:

A bateria durou apenas uma hora. Eu não compraria de novo.

A decisão esperada é aprovar o envio. O registro de decisão cita a regra de política aplicável e explica que o texto descreve uma experiência de produto e não contém nenhum conteúdo que exija revisão humana de acordo com esta política.

Se o envio incluir informações pessoais, a decisão esperada é enviá-la para revisão humana e mantê-la não publicada. Se a política atual não puder ser recuperada, a submissão também permanecerá não publicada.

O aplicativo impõe permissões e verifica o envio antes de publicar uma revisão aprovada. Para avaliar a decisão do agente, compare-a com a decisão esperada da equipe de padrões para esse envio.

Biblioteca de cenários

A biblioteca de cenários transforma o contrato de comportamento em cenários concretos de usuário. Cada cenário define uma consulta ou tarefa, evidências e condições de dependência e um resultado esperado. Ele aplica o contrato comportamental sem alterar os requisitos do contrato.

Especialistas em produtos e domínios validam cenários e resultados esperados. A equipe de Engenharia mantém as definições e a cobertura do contrato.

A tabela a seguir mostra como a biblioteca de cenários aplica o contrato de comportamento a situações representativas para o agente de revisão de produto:

Inicie o teste com casos sintéticos: envios fictícios e respostas simuladas do serviço de políticas. A coleta de dados de referência pode impedir a equipe de engenharia de concluir a implementação de recursos. Casos sintéticos expõem lacunas no contrato ou na implementação e dão aos especialistas do domínio tempo para concluir a curadoria da verdade de referência.

Use casos sintéticos para orientar especialistas no assunto (SMEs) na coleta de casos reais de carga de trabalho para um conjunto de dados de referência separado. O conjunto de dados golden expande os cenários usando a mesma estrutura: consultas reais, evidências correspondentes e resultados esperados validados por SME. Um cenário pode ter muitos casos dourados.

Para o cenário de revisão negativa, a equipe de padrões coleta envios reais que criticam um produto, mas atendem à política de publicação. Eles preservam as entradas de teste aprovadas e a versão da política aplicável e, em seguida, estabelecem a decisão esperada. Coleção de guias de casos sintéticos. Eles não são promovidos para o conjunto de dados golden.

A verdade fundamental é um resultado esperado validado pelo domínio ou uma evidência de suporte em que a correção pode ser estabelecida, não a saída registrada de um agente. Consulte Usar os dados corretos para avaliação.

Use os cenários durante uma prova de conceito para comparar implementações em relação ao mesmo contrato e aos mesmos limites de custo e latência. No agente de revisão de produto, você testaria as decisões de aprovação e os encaminhamentos em relação aos resultados esperados da equipe de padrões. Registre o design e as compensações em um registro de decisão de arquitetura e mantenha os cenários para testes de regressão.

Vincule cada caso ao cenário e à versão do contrato e registre se ele é sintético ou vem de dados reais da carga de trabalho. Mantenha cenários independentes de prompts para que o comportamento necessário permaneça testável conforme a implementação é alterada.

Adicione casos de limite e revise falhas de produção. Se os limites de segurança estiverem no escopo, inclua cenários de injeção de prompt, uso indevido e exfiltração provenientes de red teaming de IA e modelagem de ameaças.

Mantenha o desenvolvimento, a regressão e os conjuntos de versões protegidas separados. Reserve alguns casos de teste para verificação de lançamento e não os use para desenvolver ou ajustar a implementação. Restrinja o acesso a esses casos e seus resultados esperados. Se um caso orientar uma alteração de implementação, mova-o para o pacote de regressão e substitua-o por outro caso validado por especialistas em domínio.

Faixa operacional

O envelope operacional abrange um subconjunto dos requisitos não funcionais da carga de trabalho. Ele define limites de recursos e execução, como latência, custo, uso de token, novas tentativas, chamadas de ferramenta e tempo gasto aguardando aprovação.

O contrato define o comportamento correto. O envelope define os limites operacionais nos quais o sistema deve operar. Um contrato pode referenciar uma versão de envelope operacional quando esses limites fazem parte de seus critérios de aceitação. Versione o envelope de forma independente para que os limites operacionais possam ser alterados sem redefinir os requisitos comportamentais que não foram alterados. Contratos de comportamento e envelopes operacionais não exigem uma relação um-para-um.

Replay

Design para reprodução

Reprodução, como o nome sugere, reexecuta as etapas de inferência do sistema, fornecendo respostas coletadas de ferramentas e APIs ou resultados de RAG. Essa abordagem ajuda você a ajustar seu prompt e identificar qualquer evidência ausente. Ele evita chamadas repetidas para APIs ativas ou ferramentas MCP (Protocolo de Contexto de Modelo), que podem ser dispendiosas, limitadas por taxa ou retornar dados que mudam ao longo do tempo.

Coletar dados de replay em produção. Remover ou mascarar dados confidenciais de acordo com a política antes da análise ou revisão do SME. Preserve os payloads de resposta e argumentos de solicitação sem alterar o significado do caso. Se a redação remover as evidências necessárias, use um acessório aprovado e documente a limitação.

Peça a um SME para revisar e coletar dados derivados da produção antes de adicioná-los ao conjunto de dados dourado ou usá-los para criar duplas de teste. Os duplos de teste podem simular respostas, para que o replay possa dar suporte a cenários novos e existentes sem a necessidade de dados de produção. Consulte respostas simuladas com o Dev Proxy e conjuntos de dados de avaliação no Microsoft Foundry.

Configurar e executar a reprodução

Controle a versão dos conjuntos de dados de reprodução que você usa para avaliação e teste de regressão. Para comparar uma atualização com a linha de base, execute ambas as implementações na mesma versão do conjunto de dados, usando os mesmos casos e versões do avaliador. Mantenha outras condições de teste consistentes, exceto pela alteração que você está testando. Ao adicionar ou revisar casos, crie uma nova versão do conjunto de dados e execute novamente ambas as implementações.

Durante o desenvolvimento, você pode reproduzir um conjunto menor de casos para verificar o comportamento que você está alterando. Se você ainda não tiver respostas gravadas para um novo cenário, use respostas simuladas e rotule-as no conjunto de dados.

Escolha a finalidade da execução:

A configuração de execução vai além do conjunto de dados e dos avaliadores. Ele também inclui prompt, modelo, servidores de API/MCP, bibliotecas de suporte e muito mais. Ao executar avaliações, você precisa ter uma hipótese clara e alterações correlacionadas para garantir que cada execução altere apenas um conjunto mínimo. Isso permite que você avalie corretamente o impacto e evite executar a mesma atualização várias vezes devido a falhas de manutenção de registros.

Replay não substitui testes de unidade ou integração. Cada teste verifica um aspecto diferente do sistema de software e eles são igualmente importantes. Confira Testar e avaliar cargas de trabalho de IA.

O diagrama a seguir mostra o processo de replay compartilhado.

Exemplo: verificar uma alteração de agente de avaliação de produto

Suponha que a versão 42 do agente de revisão de produtos aprove um envio que deveria ter ido para a equipe de padrões porque contém informações pessoais. A equipe prepara o caso usando as salvaguardas de dados de replay e usa um teste de desenvolvimento focado enquanto revisa a implementação para o candidato 43.

1. Configure uma execução de avaliação para o candidato 43. O conjunto de dados de avaliação precisa incluir casos normais, bem como avaliações negativas em conformidade, submissões incertas e falhas de dependência. Atualize-o com casos que testam o recurso (regra de informações pessoais). A atualização cria uma nova versão do conjunto de dados. Execute a avaliação e a linha de base no novo conjunto de dados. Reproduza o conjunto de dados completo para medir a precisão da decisão, o custo e a latência por cenário.

2. Atualize o conjunto de dados de verificação de release com o novo caso de uso e obtenha uma versão atualizada. Faça referência à versão expandida do conjunto de dados e defina limites de aceitação. Reproduza o candidato 43 e a linha de base 42 com o mesmo conjunto expandido e a evidência registrada.

3. Verifique os casos existentes e novos em relação às expectativas revisadas. Espere approve para comentários negativos em conformidade e human_review para envios contendo informações pessoais. Confirme se as submissões que aguardam revisão humana permanecem não publicadas.

4. Salve os resultados e rastreamentos por caso com versões de configuração. Calcular métricas para cada cenário. Use os resultados da avaliação para melhorar a implementação e os resultados da verificação de versão para decidir se o candidato pode ser lançado. Uma melhoria geral não invalida um requisito obrigatório com falha.

Architecture

Para usar a metodologia ABE para projetar os recursos da carga de trabalho, comece com a descoberta de problemas e capture o comportamento esperado em um contrato. Em seguida, decida se a carga de trabalho precisa de execução direcionada pelo agente. Trabalhe com o proprietário do negócio e a equipe de engenharia para esclarecer as necessidades e suposições do usuário. Derive cenários dos contratos de comportamento, identifique o conhecimento e as evidências de que o sistema precisa e decida quais controles o sistema ao redor deve impor.

O contrato de comportamento e a biblioteca de cenários conectam o sistema de dois loops e orientam a implementação e o aprimoramento. O loop interno do desenvolvedor verifica as alterações antes do lançamento. O loop externo de produção coleta evidências de execução e comentários para identificar falhas ou requisitos alterados.

A ABE organiza esse trabalho em cinco responsabilidades de engenharia: especificar, fundamentar, controlar, verificar e observar. Essas responsabilidades são lógicas, não cinco serviços necessários ou etapas sequenciais de runtime. O trabalho em uma única funcionalidade pode abranger várias responsabilidades.

A IA responsável e a segurança são preocupações transversais em todas as cinco responsabilidades do sistema. A responsabilidade de especificar torna explícitas as expectativas de IA responsável e os requisitos de segurança nos contratos de comportamento. A responsabilidade de controle implementa as regras de acesso e as proteções de execução que dão suporte a esses requisitos.

Especificação e fundamentação fornecem verificações antecipadas sobre a preparação e a viabilidade do projeto. Especificar estabelece o problema e o que significa êxito. Ground avalia se as informações necessárias estão disponíveis e utilizáveis de acordo com os requisitos de acesso aplicáveis. Use essas descobertas para identificar lacunas antes de se comprometer com a implementação e, depois, validar as suposições restantes em uma prova de conceito. Para obter mais informações, consulte Alinhar a estratégia técnica com os requisitos de negócios.

Use o contrato de comportamento e a biblioteca de cenários para comparar projetos viáveis. Uma implementação determinística ou um fluxo de trabalho fixo com etapas assistidas por modelo podem atender aos requisitos. Escolha uma abordagem agentiva quando a avaliação demonstrar benefícios que justifiquem seu custo, latência e complexidade operacional adicionais. Para obter diretrizes sobre como escolher uma abordagem de execução, consulte fluxos de trabalho fixos versus sistemas direcionados por agente.

Especificar

Use o pensamento de design para entender a necessidade real do usuário antes de escolher o que e como automatizar. Trabalhe com usuários, responsáveis pelo negócio e especialistas no assunto (SMEs) para concordar com resultados aceitáveis, restrições e comportamento em caso de falha.

Registre esses requisitos em um contrato de comportamento versionado e derive cenários de teste para criar a biblioteca de cenários. As equipes de produto e engenharia revisam as alterações no comportamento esperado em conjunto. Para resolver questões de IA responsável e segurança, envolva especialistas em domínio, especialistas em risco e especialistas em segurança. Versione o contrato de comportamento e a biblioteca de cenários. As notas de versão devem identificar o contrato e a versão publicada e com suporte da biblioteca de cenários.

Examine as alterações de requisitos juntamente com o roteiro do produto e verifique novamente a implementação em relação a elas. Para cargas de trabalho de vários agentes, defina um contrato de ponta a ponta e adicione contratos de transferência em que as responsabilidades, os requisitos de evidência ou as permissões são alterados.

Para o agente de revisão de produto, entre em acordo com a equipe de padrões sobre quais envios se qualificam para aprovação automática, quando a revisão humana é necessária e como lidar com uma política indisponível ou uma fila de revisão.

O diagrama a seguir mostra como o contrato de comportamento e a biblioteca de cenários orientam a implementação e a verificação. Use a biblioteca de cenários para orientar a curadoria do conjunto de dados dourado e definir critérios de avaliação. Relatar resultados por cenário, incluindo o número de casos testados, de modo que uma pontuação geral não oculte lacunas. As constatações revisadas da avaliação e da produção podem levar a atualizações na biblioteca de cenários ou no contrato de comportamento.

Para técnicas de descoberta, confira Conduzir pesquisa de usuário e compartilhar os insights.

Terra

Básica rege o conhecimento e as evidências que você passa ao seu agente, incluindo informações recuperadas, respostas de ferramentas, regras de negócios e memória. Ele prepara informações relevantes e autorizadas para cada tarefa, preservando sua origem e autoridade. A procedência, o frescor e a sensibilidade são alguns dos principais atributos que precisam ser representados corretamente.

Para preparar informações governadas para o agente:

• Selecione fontes autoritativas e atribua proprietários para mantê-las.
• Identifique os requisitos de acesso e preserve os metadados de permissão e confidencialidade para a responsabilidade de controle .
• Prepare as informações em um formato que o agente pode usar sem perder seu significado comercial, origem ou versão.

Durante o design, verifique se as fontes podem fornecer as evidências que o contrato de comportamento exige. Para o agente de revisão de produto, vincule cada avaliação ao texto da submissão completo, à revisão e à versão da política aplicável. Se as evidências necessárias estiverem ausentes ou inacessíveis, resolva o problema de dados ou de acesso, restrinja o escopo ou adie a funcionalidade afetada.

Em runtime, a camada de recuperação informa se uma pesquisa retornou dados, não encontrou correspondências ou falhou. O aplicativo usa esse status, juntamente com os metadados de evidência, para determinar se deve prosseguir ou seguir a resposta do contrato em caso de evidência insuficiente.

Mantenha as definições de negócios e as regras em ativos versionados controlados pela carga de trabalho, independentemente de prompts e modelos. Use um contrato de dados ou um modelo semântico para definir a estrutura e o significado das informações trocadas com outros agentes e sistemas.

A tabela a seguir distingue as definições de negócios das evidências de uma solicitação específica. Uma plataforma de ontologia ou modelo semântico pode ajudar a organizar essas definições quando agentes e sistemas precisam de conceitos e relacionamentos de negócios compartilhados.

Para obter exemplos de implementação, consulte vinculação de dados de ontologia do Fabric (versão prévia) e modelos semânticos do Power BI.

Você pode estabelecer um mecanismo de regras ou um fluxo de trabalho para aplicar regras de negócios no código determinístico antes de passar os resultados para o agente. Teste essas regras repetidamente em casos revisados por especialistas da área para verificar se a implementação corresponde à política pretendida e reduzir a incerteza de implementação.

Ao montar o contexto, identifique a origem e a autoridade das orientações de negócios, das evidências atuais e da memória. Defina o que o agente pode gravar na memória e por quanto tempo retê-la. A memória não deve substituir registros autoritativos e não pode ser tratada da mesma forma que prompts ou instruções.

O diagrama a seguir mostra como preparar e combinar conhecimento, evidência e memória para o agente.

Controle

O controle protege a carga de trabalho por meio de autenticação, autorização e governança de runtime. Ele estabelece quem pode acessar o sistema, o que cada chamador e agente pode fazer e quais ações exigem aprovação. Imponha essas decisões no código do aplicativo e nos serviços conectados, não no modelo.

Siga as práticas recomendadas de segurança e realize a modelagem de ameaças para decidir quais proteções de runtime implementar. Um DFD (diagrama de fluxo de dados) mostra como as informações se movem entre solicitantes, agentes, ferramentas e armazenamentos de dados, inclusive onde o fluxo de informações cruza os limites de confiança. Use esta análise para determinar onde aplicar verificações de acesso, restringir o compartilhamento de dados e exigir aprovações.

Esses limites de confiança fazem parte da sua defesa contra ataques. Por exemplo, o conteúdo recuperado ou as respostas da ferramenta podem conter instruções mal-intencionadas. As verificações de acesso e as etapas de aprovação ainda deverão ser aplicadas se o modelo seguir essas instruções. Siga os princípios de defesa em profundidade e Confiança Zero. Combine esses controles com outras defesas contra injeção de prompt, em vez de tratar uma proteção como suficiente.

Autentique as identidades do chamador e do agente e autorize cada ação de ferramenta e acesso a dados com base na tarefa e no recurso de destino. Aplique privilégio mínimo e aplique os requisitos de acesso identificados na responsabilidade básica. Ao delegar o trabalho, preserve o contexto de autorização do chamador e as referências de evidências e verifique novamente as permissões em cada transferência. A delegação não deve expandir a autoridade. Se o acesso for negado, siga o caminho de parada ou escalonamento definido em vez de contornar a negativa de acesso por meio de outra ferramenta ou agente.

A governança de runtime também impõe aprovações necessárias, etapas de fluxo de trabalho obrigatórias e limites de envelope operacional, como orçamentos e limites de taxa. Execute novamente somente as operações que são seguras de repetir. Quando um limite for atingido, siga o comportamento de stop ou fallback do contrato. Esses controles complementam o design de resiliência mais amplo da carga de trabalho.

No exemplo do agente de revisão de produto, o acesso é limitado à submissão atribuída, à política aplicável e às ações de moderação. O fluxo de trabalho de publicação verifica as permissões, a revisão de envio e a versão da política antes de publicar uma revisão aprovada. Mantenha as alterações de política e as ações de conta do cliente fora das permissões do agente.

O diagrama a seguir mostra como as ações propostas são avaliadas e registradas.

Para obter um exemplo de recuperação de informações, confira Projetar uma solução segura de inferência RAG multilocatário. Para obter diretrizes sobre identidade e proteção em camadas, consulte Identidade, acesso e privilégio mínimo e Princípios de design de segurança.

Para obter exemplos de controles de execução implementados por meio da orquestração de fluxo de trabalho, consulte padrões de vários agentes orientados ao fluxo de trabalho.

Verificar

Verify combina verificações de caso único com avaliação no nível do conjunto de dados no loop interno do desenvolvedor.

Verificar um único caso

Durante a implementação, execute ou reproduza um caso de teste usando respostas gravadas ou simuladas. Inspecione o rastreamento de execução para comparar as evidências, as chamadas de ferramenta, as decisões de controle e o resultado com o contrato de comportamento e o cenário. Use as descobertas para depurar e refinar a implementação.

Avaliações

Realize avaliações em um conjunto de dados com controle de versão para avaliar o comportamento em cenários compatíveis. Defina métricas e limites de aceitação do contrato comportamental. A tabela a seguir descreve cenários e medidas associadas para o agente de revisão de produto.

Compare o candidato e a linha de base usando o mesmo conjunto de dados e as mesmas versões do avaliador. Para obter mais informações, consulte Configurar e executar replay.

Relatar resultados por cenário para que as pontuações agregadas não ocultem regressões. Repita os casos de teste para verificar a consistência. Defina o número de execuções e critérios de aceitação antes da avaliação. Registre o contrato de comportamento, o conjunto de dados, o avaliador e as versões do limite com os resultados.

Teste casos de execução longa e comportamento de falha nos limites operacionais. Defina as contagens de etapas e chamadas de ferramenta, mas exija um caminho exato somente quando o contrato especificar um. Para cargas de trabalho de vários agentes, teste as transferências, bem como os resultados de ponta a ponta.

Execute essas verificações junto com testes de unidade e integração. Bloquear lançamentos que não atingem os limites de cenário exigidos. Para obter orientações de lançamento, consulte a lista de verificação de caminho de adoção.

Observar

Observe analisa as execuções de produção para identificar comportamentos bem-sucedidos, falhas e suas causas. O sistema deve coletar comentários do usuário para facilitar a análise. Inicie a análise com a classificação de cenário:

1. Classifique as execuções registradas usando o contexto da tarefa e da execução. Corresponda cada execução de teste ao cenário aplicável e às versões do contrato. Sinalizar casos desconhecidos ou ambíguos para revisão.

2. Compare o resultado com o comportamento esperado do cenário e combine essas informações com os comentários do usuário para avaliar o êxito ou a falha. Deixe os casos não avaliados quando a evidência for insuficiente.

3. Investigue falhas usando rastreamentos e comentários do revisor. Agrupar descobertas por causa, como lacunas de conhecimento, falhas de implementação ou dependência ou requisitos pouco claros.

4. Tenha proprietários de produtos, especialistas em domínio e engenheiros que revisem as descobertas e decidam o que mudar. Valide os resultados esperados antes de adicionar casos preparados à cobertura de regressão. Registre o motivo de cada alteração e verifique-o antes da liberação.

No exemplo do agente de revisão de produto, rotear um envio que contém informações pessoais para revisão humana, mantendo-o não publicado é um comportamento bem-sucedido. Aprová-lo é um exemplo de uma falha. Uma solicitação para dar suporte a revisões de imagem identifica uma possível alteração de escopo.

Registre a entrada da tarefa, as solicitações e as respostas da ferramenta, o conteúdo recuperado fornecido ao modelo e a saída. Preserve versões de origem, decisões de controle e falhas. Vincule os comentários do usuário e do revisor à execução e à versão. Minimize dados capturados, aplique limites de acesso e retenção, e siga as orientações de preparo de dados de reprodução antes da análise ou da curadoria do conjunto de dados.

Para obter um exemplo de conexão de resultados de produção à avaliação, consulte o loop de qualidade de observabilidade do agente.

Lista de verificação do caminho de adoção

Comece com uma implementação mínima viável em torno de um comportamento consequente em sua carga de trabalho.

A menor implementação útil do ABE não é uma plataforma. Este é um comportamento explícito, reproduzível, avaliado e restrito. O primeiro loop de trabalho está em especificar e verificar. Evite criar uma plataforma ampla antes que a equipe possa usar um contrato para prevenir, detectar ou diagnosticar um problema comportamental real.

1. Selecione uma situação limitada e relevante, identifique os responsáveis de produto e de engenharia e envolva especialistas no domínio.
2. Escreva um contrato de comportamento analisado, incluindo evidências e estados de falha.
3. Defina cenários para casos normais, de limite, de evidências insuficientes e de falha de dependência. Gere casos sintéticos desses cenários para iniciar o teste.
4. Use os casos sintéticos para orientar os SMEs na coleta e na curadoria de casos de carga de trabalho reais para um conjunto de dados de referência separado.
5. Capturar ou simular respostas estáveis de ferramenta e conhecimento para reprodução.
6. Adicione verificações determinísticas e apenas os avaliadores baseados em julgamento necessários para o contrato.
7. Execute os cenários em integração contínua e bloqueie as liberações em falhas críticas.
8. Registre informações suficientes de execuções de produção para identificar o contrato, a implementação, o caminho da evidência e o resultado.
9. Transforme os achados de produção revisados em cenários de regressão.

Alterações em prompts, configurações de modelo e código do aplicativo podem alterar o comportamento do agente. Valide essas alterações antes de usá-las em produção. Registre as versões testadas, a configuração de avaliação e os resultados. Siga as práticas de implantação seguras para introduzir alterações gradualmente e planejar como se recuperar se elas causarem problemas. Inclua alterações de configuração no plano de recuperação.

Desenvolva com base neste primeiro loop à medida que você aprende o que sua carga de trabalho precisa. Quando agentes e sistemas precisam de definições e relações de negócios compartilhadas, um modelo de dados semânticos pode fornecer essa base. Quando as decisões seguem regras de negócios explícitas, um mecanismo de regras pode aplicar essas regras fora do modelo. Mantenha os controles de acesso e as evidências de execução que sua carga de trabalho requer desde o início e expanda o monitoramento e a automação como os riscos e as descobertas de produção justificam isso.

Implementar o ABE no Azure

A ABE é agnóstica em relação à plataforma. Azure fornece serviços que você pode usar para dar suporte a suas cinco responsabilidades de engenharia.

O diagrama a seguir mapeia cada responsabilidade do ABE para Azure serviços a serem considerados para sua carga de trabalho.

Para cada responsabilidade de engenharia, combine Azure funcionalidades com os contratos, controles e processos de revisão que sua equipe mantém.

Antes de escolher qualquer serviço Azure, verifique se seus recursos, regiões e APIs se encaixam em sua carga de trabalho. Prefira serviços de GA (disponibilidade geral) e controles de propriedade do aplicativo para verificações de aplicação obrigatória e liberação. Alguns dos recursos mencionados nas seções a seguir são recursos de visualização e podem não ser adequados para sua carga de trabalho.

Especificar no Azure

Mantenha contratos, cenários, envelopes operacionais e configurações de reprodução em seu repositório Git existente, por exemplo, Azure Repos ou GitHub. Siga as responsabilidades de revisão compartilhada quando uma alteração afetar o comportamento esperado. Use a revisão de engenharia para manutenção técnica.

Básica no Azure

Conecte o agente às fontes autoritativas que você identificou para a responsabilidade básica. Para o agente de avaliação de produtos, você começa com as APIs de aplicativo existentes do site para recuperar submissões e a política aprovada no momento.

Quando precisar de recuperação entre fontes de conhecimento, considere Recuperação por meio de agentes da Pesquisa de IA do Azure. Ele pode retornar conteúdo fundamentado com referências opcionais de origem e um log de atividades. Meça o custo e a latência da abordagem de recuperação selecionada.

Se os dados corporativos já estiverem no Microsoft Fabric, a ferramenta Fabric IQ poderá conectar agentes do Microsoft Foundry a modelos semânticos e itens de ontologia. A integração e a funcionalidade de ontologia estão em versão preliminar. Verifique como a conexão se autentica, quais dados ela pode acessar e se os dados podem deixar o limite de conformidade Azure.

Controle a versão das definições semânticas separadamente da implementação do agente e registre suas versões com a evidência de teste. integração do Git do Fabric dá suporte a itens de ontologia na versão prévia.

Controlar e executar no Azure

Você pode executar agentes de prompt e agentes hospedados personalizados no Serviço de Agente do Foundry. Para outros requisitos de runtime ou implantação, considere AKS, Aplicativos de Contêiner do Azure ou Serviço de Aplicativo do Azure. Confira Escolha um serviço de computação do Azure para comparar opções. Implemente suas regras de autorização, aprovação e execução no aplicativo e nos serviços conectados.

Para agentes do Foundry, use Microsoft Entra identidades de agente para conexões mcp e agente a agente com suporte. Quando o agente atua para um usuário, verifique a autoridade do usuário e a autoridade do agente. Antes do lançamento, verifique a identidade e as permissões que o agente usará em runtime.

Gerenciamento de API do Azure pode controlar pontos de extremidade MCP compartilhados por meio de políticas de autenticação, limites de taxa e cotas. Use o middleware do Agent Framework para adicionar verificações definidas pelo aplicativo para ferramentas de funções que a estrutura executa. Para ferramentas que são executadas fora desse limite, imponha autorização obrigatória e políticas obrigatórias em um gateway ou serviço downstream.

Quando uma ação precisar de confirmação humana, use a aprovação de função-ferramenta. Se as aprovações de fluxo de trabalho precisarem sobreviver a uma reinicialização, configure o armazenamento de checkpoint persistente e restaure o estado de aprovação pendente antes de permitir a execução. Para ferramentas que alteram o estado, valide as entradas e adicione proteções de idempotency no executor de ação. Configurações de controle e orquestração de versão com a implementação.

Os Prompt Shields no Segurança de Conteúdo de IA do Azure podem detectar tentativas de injeção de prompt em prompts de usuário e documentos de embasamento. Combine estas verificações com a autorização. Defina como a carga de trabalho responde ao conteúdo bloqueado no contrato de comportamento e teste essa resposta.

Para o agente de revisão de produto, o acesso de leitura é concedido a envios atribuídos e à política atual. O acesso de gravação é restrito às operações de moderação que aprovam um envio ou o encaminham para revisão humana. As verificações de versão de submissão e política são impostas no fluxo de trabalho da publicação.

Verificar no Azure

Você pode armazenar casos de reprodução preparados e resultados de teste no Armazenamento de Blobs do Azure. Referencie versões específicas do conjunto de dados em suas configurações de reprodução e vincule casos derivados de produção às execuções de origem. Restrinja o acesso a casos de controle protegidos e evidências de produção retidas. Siga as diretrizes de arquitetura Armazenamento de Blobs para acesso baseado em identidade, proteção de dados e retenção.

Usando conjuntos de dados de avaliação do Foundry, você pode pontuar respostas concluídas ou enviar entradas para um agente para gerar e avaliar novas respostas. Para reprodução controlada, configure os adaptadores de dependência antes de invocar o agente. Publique conjuntos de dados como cópias de execução da biblioteca de cenários governada e aplique as mesmas restrições de acesso de holdout.

Utilize verificações determinísticas para critérios com valores ou regras de referência explícitos e use avaliadores baseados em modelo para critérios baseados em julgamento. Os avaliadores personalizados do Foundry dão suporte a ambas as abordagens, bem como endpoints de pontuação externos.

Para o agente de revisão de produto, uma verificação baseada em código pode comparar a decisão estruturada com a decisão esperada da equipe de padrões. Um avaliador baseado em modelo pode avaliar se a explicação e a regra de política citada dão suporte a essa decisão, considerando o texto enviado. Avaliadores de rubrica e avaliadores personalizados estão em versão prévia.

Verifique a compatibilidade da ferramenta do avaliador antes de usar pontuações em uma porta. Para conversas contendo Pesquisa de IA do Azure ou chamadas do agente de dados do Fabric, não use resultados tool_call_accuracy, tool_input_accuracy, tool_output_utilization, tool_call_success ou groundedness. Use asserções de contrato determinísticas ou outro método de avaliação compatível.

Salve os resultados e rastreamentos por caso com a configuração que os produziu. Aplique critérios de release no pipeline e bloqueie a release se um cenário necessário falhar. Use os mesmos casos e versões do avaliador ao comparar implementações. Se você treinar modelos personalizados em Azure Machine Learning, inclua suas versões na configuração.

Observe no Azure

O rastreamento do Foundry usa o recurso do Azure Monitor Application Insights conectado ao projeto. Instrumente a ferramenta do seu aplicativo e o código de recuperação para capturar qualquer evidência adicional necessária.

Decida qual conteúdo você precisa gravar. A integração de rastreamento do lado do cliente do Foundry inclui configurações para gravar o conteúdo da mensagem. Verifique se a instrumentação captura as respostas necessárias da ferramenta e o conteúdo recuperado juntamente com nomes de operação e tempos. Minimize ou oculte conteúdos confidenciais antes da exportação de telemetria. Mantenha apenas as evidências permitidas pela política de dados.

Considere usar a avaliação de traces (versão prévia) para avaliar os traces retidos do Application Insights que atendem aos requisitos de saneamento. Ele pontua interações existentes sem executar novamente solicitações, incluindo rastreamentos OpenTelemetry compatíveis de agentes fora do Foundry. Use essas pontuações para investigar o comportamento de produção e verifique as alterações de implementação resultantes por meio de reprodução e avaliação antes da liberação. Esse recurso está em versão prévia pública, não tem contrato de nível de serviço e não é recomendado para cargas de trabalho de produção. Não confie nisso para decisões de monitoramento de produção ou lançamento.

Use consultas do Log Analytics e alertas do Azure Monitor para investigar falhas comportamentais e violações de envelope operacional. A exibição de detalhes do Application Insights Agent, atualmente em versão prévia, pode ajudá-lo a investigar execuções individuais. Alimente descobertas revisadas e casos preparados no próximo ciclo de alteração e reexecução.

Contributors

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

• Yang Song | Engenheiro de Software Principal

Outros colaboradores:

• Chad Kittel | Engenheiro de Software Principal
• Bryan Ostdiek | Cientista de Dados Principal
• Peter Parker | Engenheiro principal de soluções, estrategista e arquiteto de nuvem de IA do Azure
• Rama Pyarasani | Gerente de engenharia multidisciplinar alocada em campo
• Ronnie Yates | Gerente Geral, Forward Deployed Engineering

Para ver perfis de LinkedIn não públicos, entre em LinkedIn.

Próximas Etapas 

• Agentes na Microsoft Foundry
• Avaliar seus agentes de IA
• Recuperação agêntica no Pesquisa de IA do Azure 
• Monitorar agentes de IA com o Application Insights
• Contratos Comportamentais do Agente (artigo de pesquisa)

Recursos relacionados

• Padrões de projeto para agentes de IA
• Geração aumentada por recuperação por meio de agentes
• operações de machine learning