
Seu roteador combinou a palavra-chave certa na frase errada
Curadoria, tradução e análise: Redação Triplo Hub.
Se o seu agente executa um roteador de palavras-chave ou intenções rápido na frente do modelo, provavelmente ele responde a cada solicitação de uma de duas maneiras. Ele dispara uma ferramenta ou passa a solicitação para o LLM. Isso cobre "o que está na minha agenda hoje." Não cobre "construa um fluxo de trabalho que verifique minha agenda e e-mail." Seu roteador vê minha agenda nessa frase, e não está errado em fazê-lo. Ele está apenas respondendo a uma pergunta menor do que a que o usuário fez.
Eu descobri que meu roteador estava fazendo exatamente isso. A correção levou dois commits ao longo de dois dias, e o segundo foi um bug que eu não teria adivinhado.
"construa um fluxo de trabalho que verifique minha agenda" retornou uma lista de agenda em 75
Meus documentos de planejamento anunciam três frases como a entrada para o construtor de fluxo de trabalho. No dia 25 de agosto, executei as três contra o roteador ao vivo em vez de confiar nos documentos:
construa um fluxo de trabalho que verifique minha agenda e e-mail → auto-rota 75
→ google-calendar::list-events, correspondido em "minha agenda"
toda manhã resuma minha agenda e e-mails não lidos → o mesmo
sempre que um PR for aceito, verifique CI e me avise → silencioso, sem sinal
Isso foi duas falhas diferentes. As duas primeiras deram uma resposta errada confiante: você pede uma automação e recebe os eventos de hoje. A terceira não deu resposta alguma. As frases que os documentos chamam de porta da frente eram as frases que o roteador lidava pior.
Isso não era novo. Meu sistema de memória já tinha uma nota antiga de que o roteador "pode disparar automaticamente ferramentas MCP com base em correspondências de palavras-chave em prosa sem argumentos extraídos," e outra sobre ele disparando chamadas de captura de tela e informações de disco em um prompt tão simples quanto "Oi." O caso do fluxo de trabalho foi a mesma falha com um disfarce melhor, porque a correspondência parecia correta.
Retido é uma terceira resposta entre disparar e ignorar
O que foi enviado adiciona um terceiro resultado. Quando a frase contém um cronograma explícito ou frase de gatilho ("toda manhã", "sempre que ") ou uma palavra de fluxo de trabalho explícita ("fluxo de trabalho", "automação"), o roteador retém a auto-rota. Ele não executa list-events. Ele escreve um marcador de oferta de fluxo de trabalho no contexto da conversa. A camada de chat vê esse marcador e envia a frase para o planejador, e o endpoint do planejador nunca executa um passo. Você recebe de volta um gráfico proposto que pode ler, editar ou ignorar.
Três resultados, não dois
A assimetria de custo decidiu o design. Se uma retenção é um falso positivo, você recebe uma oferta que ignora. Se um disparo automático é um falso positivo, algo é executado, e para uma ferramenta que envia ou escreve, isso não pode ser revertido.
Superar "minha agenda" com palavras-chave de gráfico foi o primeiro design, e eu o abandonei
A correção óbvia era registrar palavras-chave como "construa um fluxo de trabalho" com uma pontuação mais alta do que "minha agenda," para que a rota do gráfico vença. Comecei a escrevê-la e parei. Isso é uma guerra de lances dentro de uma tabela onde a correspondência da agenda não está errada, apenas incompleta. Cada palavra-chave adicionada depois teria que vencer essa luta novamente, e eventualmente uma não venceria.
Então eu segurei a rota em vez de superá-la. Nenhum limite foi movido. O motor já fazia isso para um caso diferente: uma mutação roteada por palavra-chave cujos parâmetros foram adivinhados é retida e oferecida, não executada. Eu reutilizei esse movimento para um novo gatilho. Também mantive o gatilho estreito de propósito. Uma cadeia and simples não conta. "Verifique minha agenda e e-mail" é um pedido razoável para duas leituras, não um pedido para construir algo, e tratar cada conjunção como um fluxo de trabalho teria transformado o planejador em um segundo padrão ruim.
Isso foi D1. Os testes passaram, e o CLI que imprime o que o roteador faria com um prompt disse RETIDO para as três frases.
A próxima mensagem do Telegram analisou <untrusted_channel_message e nada mais
Na noite seguinte, enviei uma daquelas frases do Telegram. Eu recebi uma resposta do modelo e nenhum plano. A resposta do modelo descreveu uma habilidade programada real com precisão, o que tornou pior, porque parecia um comportamento intencional.
Eu executei a mesma sondagem duas vezes. Na frase simples, disse RETIDO. Na frase exatamente como o Telegram a entrega, o roteador relatou isso como sua janela de análise:
untrusted_channel_message channel="telegram from="…
O roteador pega a primeira linha não vazia da conversa como o texto a classificar. Em uma conversa de canal, essa linha é a tag de abertura do envelope de conteúdo não confiável que envolve mensagens externas. Cada verificação de palavra-chave e o novo portão de fluxo de trabalho viam apenas o envelope. Nenhum marcador de oferta foi escrito, então a verificação messageCarriesWorkflowOffer do console em llm.ts não encontrou oferta e enviou a conversa para o modelo.
Esse foi o quarto lugar onde o envelope quebrou em uma noite. Ele já havia quebrado o autor da receita e o correspondedor de portão, e em julho quebrou a consulta de memória do gateway. O extrator já tinha uma carve-out para o próprio Mensagem nova do usuário: wrapper do gateway. A correção adicionou o mesmo tipo de carve-out uma camada abaixo, e funciona junto com o existente. Os testes em Rust agora usam o envelope literal como entrada. 993 testes de biblioteca e 2.055 testes binários passaram antes que a versão de lançamento fosse trocada.
Algo engraçado aconteceu enquanto eu redigia isso. O gancho de prompt na minha sessão de codificação correspondeu a "minha agenda" dentro do resumo de escrita, rotulou-o como "correspondido dentro da prosa," e não o executou. A mesma classe de falha aparece em cada camada que lê texto.
Duas propriedades que um roteador tem ou não tem
A primeira propriedade: um roteador que pode executar tem um resultado que não é nem disparar nem passar. Verifique seu código para um valor de retorno, enum ou ramificação que signifique "eu correspondi, e estou me recusando a agir com base na correspondência." Se os únicos resultados são "chamar a ferramenta" e "entregar ao LLM," então cada correspondência correta, mas incompleta, é executada.
A segunda propriedade: a decisão do roteador é invariante sob cada envelope de transporte. Para cada wrapper w que seu sistema coloca em torno do texto do usuário (tags de canal, respostas citadas, preâmbulos de anexos, a própria moldura do gateway), route(w(s)) == route(s). Isso é verdadeiro para o seu roteador ou falso, e é barato de testar.
Uma reprodução de 40 linhas que encontra ambas as falhas em seu roteador
Leve a função de classificar do seu roteador, onde quer que ela viva. Copie os envelopes reais dos seus próprios logs. Não escreva envelopes que você acha que lo
Empresas brasileiras que utilizam agentes de IA devem estar atentas à forma como suas ferramentas interpretam comandos. Um roteador que não reconhece nuances em solicitações pode levar a resultados insatisfatórios. É crucial revisar e ajustar a lógica de roteamento para garantir que as respostas sejam precisas e relevantes, especialmente em contextos de automação. A ação prática recomendada é realizar testes regulares nas funções de roteamento para identificar e corrigir falhas.


