Expansão da ferramenta do agente e controlabilidade do sistema

Uma situação comum é avaliar um sistema Agente. A primeira coisa que você observa é “quantas ferramentas ele pode aceitar”.

Ele pode verificar bancos de dados, enviar mensagens, modificar ordens de serviço, emitir scripts e operar navegadores. Certamente parece mais um sistema verdadeiramente funcional do que um modelo apenas de chat. Então é fácil para a equipe seguir nessa direção: se conectarmos mais algumas ferramentas, concedermos mais permissões e tornarmos os links mais automáticos, o sistema ficará mais forte.

O problema é que ser forte não significa ser controlável.

Meu julgamento é: **A controlabilidade do sistema Agente não depende do número de ferramentas, mas da convergência de estado, limites de permissão e fallback de falhas. Quando houver cada vez mais chamadas de ferramentas, contextos cada vez mais longos e cada vez mais efeitos secundários das ações, sem restrições claras e mecanismos de convergência, o sistema tornar-se-á geralmente mais difícil de prever. **

Existem muitas ferramentas, a solução é a faixa operável; controlável, a solução é se os resultados podem ser contidos

A solução das “ferramentas ajustáveis” é que o Agente não apenas dá sugestões, mas pode afetar diretamente o sistema real.

Isto é expansão de capacidade, não um problema falso.

Mas assim que o sistema passa de “responder perguntas” para “realizar ações”, o foco da engenharia muda. Não é mais necessário julgar se o conteúdo de saída soa como fala humana, mas sim julgar:

• O que exatamente fez desta vez;
• Faça este movimento em vez de outro movimento mais seguro;
• Qual será o impacto caso você cometa um erro;
• Quando falha no meio, o sistema irá parar, tentar novamente ou deixar meio conjunto de efeitos colaterais?
• Da próxima vez que vier um pedido semelhante, ele seguirá um caminho completamente diferente?

Em outras palavras, à medida que o número de ferramentas aumenta, a complexidade passa de “problemas de correção de texto” para “problemas de previsibilidade do comportamento do sistema”.

Esses dois tipos de problemas não são da mesma magnitude.

Um modelo que só consegue responder a perguntas geralmente é um ruído cognitivo se cometer erros; se um Agente puder ajustar mais de uma dezena de ferramentas, uma vez que não há restrições, se cometer erros será ruído de ação, e se cometer erros será ruído de sistema.

O que realmente sai do controle primeiro geralmente é o estado.

Muitas equipes bagunçam o Agente, e a primeira reação é que o modelo fica instável. Na verdade, muitos problemas estão fora do modelo.

Por exemplo, um processo comum:

• O agente primeiro verifica o sistema de ordens de serviço e recebe as tarefas a serem processadas;
• Pesquise novamente a base de conhecimento para encontrar métodos históricos de descarte;
• Em seguida chame a consulta ao banco de dados;
• Enviar outra mensagem para o grupo de plantão;
• Adicione um registro de disposição final.

Cada etapa deste link é “razoável”, mas enquanto o estado intermediário não estiver claramente definido, o sistema encontrará rapidamente estes problemas:

• O status da ordem de serviço foi alterado para Processando, mas a notificação não foi enviada;
• A consulta ao banco de dados foi executada, mas os resultados não foram registrados no registro final;
• A mensagem foi enviada ao grupo, mas as etapas subsequentes falharam, mas o mundo exterior achou que o assunto havia sido resolvido;
• Após a janela de contexto ser truncada, não há certeza de quais ações foram executadas antes, quando a segunda rodada de execução continua.

Estes são o sistema carece de um mecanismo de convergência de estado.

Um agente que pode executar ações sem uma máquina de estado de tarefa clara está essencialmente apenas encadeando efeitos colaterais de várias etapas na inferência de linguagem natural.

Isso parece ótimo na demonstração, mas é difícil de implementar na produção.

Os limites das permissões não são claros e o Agente pode facilmente mudar de “ser capaz de fazer coisas” para “fazer muitas coisas”

Outro mal-entendido comum é considerar o acesso à ferramenta como um inventário de capacidade.

Conecte-o ao navegador e dê acesso a qualquer plano de fundo; Quando conectado ao Shell, a maioria dos comandos pode ser executada por padrão; Quando conectado ao sistema de mensagens, você pode notificar proativamente qualquer grupo por padrão; Conecte-se ao banco de dados e conceda permissões mistas de leitura e gravação.

Superficialmente, isso torna o Agente mais versátil, mas na verdade ele aposta na controlabilidade do sistema para evitar erros em uma única inferência.

Isso é perigoso porque o risco do agente é chamar uma ferramenta de alto efeito colateral em um contexto localmente razoável, mas globalmente errado.

Por exemplo:

• Eu deveria apenas ter verificado o status, mas em vez disso executei o script de reparo;
• Era para responder apenas ao usuário atual, mas a notificação foi enviada para o grupo;
• Deveria apenas ler dados, mas a interface de atualização foi chamada;
• Só deveria continuar após revisão humana, mas a “ação sugerida” foi diretamente alterada para “ação executada”.

Portanto, o foco do desenho dos limites de permissão é separar as ações de alto efeito colateral do raciocínio de alta incerteza.

Se uma ação causará danos reais se for errada uma vez, ela não deve ser colocada na mesma camada de automação que as ações de consulta comuns.

Com mais ferramentas organizadas, a falha não é mais apenas um “erro”, mas um estado semiconcluído.

É claro que os sistemas de software comuns também falham, mas a falha dos sistemas Agentes traz um problema adicional: muitas vezes é uma falha semicompleta em ferramentas, sistemas e fronteiras semânticas.

Por exemplo:

1. Primeiro crie uma tarefa de processamento no Jira;
2. Acesse o Slack para enviar notificação;
3. Ajuste a API interna para puxar o log novamente;
4. Por fim, escreva o resumo na base de conhecimento.

O que o sistema deve fazer se a etapa três falhar?

• Reverter uma tarefa do Jira? -Excluir notificação que acabou de ser enviada?
• Tarefa retida, mas processamento de sinalizadores interrompido?
• Deixar outro Agente assumir?

A abordagem mais tabu aqui é entender o “tratamento de falhas” como perguntar novamente ao modelo.

Porque muitas falhas já são efeitos colaterais. O que é realmente necessário é:

• Quais etapas podem ser repetidas;
• Quais passos devem ser idempotentes;
• Quais etapas só poderão ser continuadas após confirmação manual;
• Quais ações externas devem deixar trilha de auditoria;
• Após a interrupção de um link, onde ele será reconectado na próxima vez que for restaurado?

Se estes não forem definidos, o Agente parece estar automatizando, mas na verdade está criando o trabalho manual posterior.

O núcleo da controlabilidade está em “irá convergir?”

Estou cada vez mais inclinado a considerar o sistema Agente como um sistema de fluxo de trabalho com capacidades de raciocínio, em vez de um portal completo que pode conversar.

Isso significa que ao projetá-lo, a primeira coisa a responder é:

• Se a tarefa está claramente iniciada, em processamento, com confirmação pendente, concluída ou com status de falha;
• Quais ferramentas podem ser acionadas em cada estado;
• Quais resultados podem ser submetidos diretamente e quais devem ser revisados;
• Após a perda do contexto, o sistema pode se recuperar do estado externo em vez de depender da recuperação do modelo;
• Se existem registros de entrada, saída e execução responsáveis ​​para cada ação.

Essas coisas não parecem atraentes, mas determinam se o Agent é um sistema que pode ser gradualmente ampliado ou um brinquedo que só pode ser demonstrado em cantos de baixo risco.

Um padrão de julgamento muito simples é: **Se você alterar temporariamente o modelo para um nível mais fraco, a eficiência do sistema só diminuirá; se a máquina de estado, os limites de permissão e o mecanismo de reversão forem removidos, o sistema não poderá ficar online imediatamente. **

Isto mostra que a verdadeira base é a capacidade de convergência do sistema.

Um contra-exemplo comum: tratar o Agente como um coordenador universal

Muitas plataformas internas acabarão por se transformar em algo muito semelhante a uma “plataforma intermediária de IA”:

• Conecte-se a qualquer sistema;
• Quero aceitar qualquer solicitação;
• Tente concluir todas as ações automaticamente;
• Achei que contanto que deixasse as palavras um pouco mais detalhadas, poderia suprimir o risco.

O maior problema desta rota é que a sua complexidade marginal é muito fraca.

Porque quanto mais tipos de solicitação houver, mais complexa será a semântica da ferramenta e maior será o número de combinações de caminhos de sucesso e caminhos de falha. Originalmente eu só precisava “verificar os registros de lançamento”, mas depois ficou:

• Verificar registros;
• Julgamento de anormalidade;
• Decida se deseja reverter;
• Enviar notificações;
• Alterar status;
• Gerar revisão;
• Base de conhecimento atualizada.

Parece um circuito fechado automatizado completo. Na verdade, a cada etapa adicional, o sistema adiciona uma camada de consistência de efeitos colaterais e custos de interpretação de permissão.

No final das contas, o que realmente consome o tempo da equipe é muitas vezes:

• Esta etapa será executada por si só;
• O mesmo problema tomou rumos diferentes hoje e ontem;
• O sistema externo foi alterado, mas os registros internos não acompanharam;
• Após o acidente, é difícil restabelecer aquilo em que o Agente confiava na época.

Isto significa entregar demasiadas ações de elevada incerteza a um processo de raciocínio que carece de limites. **

Uma abordagem mais estável é a automação em camadas, em vez de empilhar as ferramentas de maneira plana.

Se você realmente deseja tornar o sistema do Agente controlável, recomendo colocá-lo em camadas de acordo com riscos e efeitos colaterais:

1. Camada de baixo risco: consulta e resumo

Primeiro, deixe o Agente fazer a leitura, recuperação, resumo e rascunho.

Mesmo que o julgamento deste tipo de acção não seja perfeito, normalmente não altera directamente o estado externo, sendo mais adequado para aumentar primeiro o montante.

2. Camada de risco médio: ação em uma única etapa com restrições

Por exemplo, você só pode alterar um campo em um status específico de ordem de serviço, só pode responder à sessão atual e só pode executar operações na lista de permissões explícita.

A chave aqui é comprimir o espaço de ação para que seja estreito o suficiente para tornar aceitável o custo dos erros.

3. Camada de alto risco: aprovação explícita e execução de reversão

Sempre que a exclusão de dados, as operações em lote, a gravação entre sistemas, as notificações de saída e a execução de scripts do ambiente de produção estiverem envolvidas, a revisão humana, a auditoria e os mecanismos de reversão devem ser colocados em primeiro plano, em vez de serem deixados para correção posteriormente.

Um Agente verdadeiramente maduro sabe o que deve ser feito automaticamente, o que só pode ser sugerido e o que nunca deve ser feito diretamente.

Limites aplicáveis

Este artigo discute principalmente:

• Um agente interno conectado a múltiplas ferramentas;
• Agente baseado em processo com efeitos colaterais externos reais;
• Cenários de orquestração envolvendo operações entre sistemas, como mensagens, ordens de serviço, bancos de dados, scripts, navegadores, etc.

Se o Agente ainda estiver preso em tarefas com poucos efeitos colaterais, como “ajudar os usuários a resumir as páginas da web” e “ajudar o atendimento ao cliente a redigir respostas”, ter mais ferramentas pode não levar necessariamente à perda imediata de controle, porque a maioria dos erros ainda permanece na camada de texto.

O verdadeiro problema surge quando o sistema começa a mudar diretamente o estado externo. Naquela época, já enfrentávamos um design restrito no estilo de sistema distribuído.

Resumo

O agente pode chamar mais ferramentas, o que de fato tornará o sistema mais útil.

Mas “mais útil” e “mais controlável” não são palavras na mesma direção.

Quando a complexidade das ações, dos efeitos colaterais e do contexto aumenta em conjunto, o que realmente determina o limite superior do sistema é muitas vezes se o estado de ativação pode ser convergido, se os limites de permissão são claros e se a ativação pode ser interrompida de forma estável e restaurada após uma falha.

Caso contrário, quanto mais ferramentas estiverem conectadas, mais o sistema se tornará um executivo com fortes capacidades, mas difícil de prever.