Seu agente não precisa de todas as ferramentas em seu contexto

O [agente de IA] de DynoTable(/docs/dynamodb-ai-chat) pode alcançar 38 ferramentas. Raramente vê todos eles de uma vez. Onde traçamos a linha entre o que o modelo obtém imediatamente e o que ele procurava acabou sendo o mais decisão consequente em todo o kit de ferramentas, e a linha acabou em lugar nenhum perto de onde o colocamos pela primeira vez.

Construímos um mecanismo de descoberta para que o modelo começasse com um pequeno conjunto e procure o resto. Então vimos modelos baratos usá-lo e movemos 27 de as 38 ferramentas de volta ao núcleo sempre visível. O mecanismo sobreviveu. Nosso teoria sobre quem precisava disso, não.

Aprendemos isso construindo uma superfície de ferramenta para modelos que não podem ser confiável para ir procurar.

Uma ferramenta que o modelo nunca chama ainda custa para você

Cada ferramenta que você expõe tem seu nome, sua descrição e seu esquema de entrada completo, serializado na solicitação antes que o usuário digite qualquer coisa. Trinta e oito de isso não é grátis.

Os tokens são a metade menor da conta. O custo real é a precisão da seleção: quanto mais opções quase idênticas um modelo varre, mais frequentemente ele escolhe as errado. Nosso catálogo está cheio de opções quase idênticas de propósito. Cinco de nossas ferramentas existem duas vezes, openTable e proposeOpenTable, openWorkbench e proposeOpenWorkbench e assim por diante. Cada par faz a mesma coisa; um faz imediatamente, o outro emite um chip no qual o usuário clica primeiro. Essa distinção é resistente parasegurança e quase invisível em um apartamento lista de nomes.

Oa própria orientação do cliente leva exatamente a este ponto: carregar cada definição de ferramenta antecipadamente desperdiça tokens, adiciona latência e degrada o desempenho do modelo. Concordar com isso é fácil. Decidindo qual as ferramentas perdem seu lugar é onde fica interessante.

Construímos uma ferramenta de pesquisa. O modelo de chão não ligaria para isso.

O mecanismo é de dois níveis. Um conjunto de ferramentas está ativo desde a primeira etapa. O o restante fica invisível até que o modelo chame searchTools(query), que pontua o cataloga nomes, descrições e palavras-chave, retorna as correspondências e as adiciona ao conjunto de ferramentas que o modelo pode recorrer nas etapas subsequentes.

Em seguida, comparamos com nosso modelo de piso. Não sintonizamos este agente contra um modelo de fronteira, ele funciona suas próprias credenciais da Bedrock, então as pessoas escolhem modelos baratos e otimizamos para o mais barato. Questionado sobre um anexo arquivo, esse modelo foi procurar na lista de guias abertas. Isso raramente chamada de ferramenta de pesquisa. Qualquer coisa que não fosse diretamente visível não existia para ele.

Esse resultado mata o design óbvio. Se a descoberta for o único caminho para uma ferramenta, cada solicitação que precisa dessa ferramenta depende da escolha do modelo, e os modelos com maior probabilidade de precisar de ajuda são os menos propensos a solicitá-la.

Então a divisão deixou de ser “núcleo pequeno, cauda grande” e virou uma questão sobre a solicitação, não a ferramenta: a frase do usuário nomeia a ferramenta? Os 11 as ferramentas que mantivemos detectáveis são aquelas em que a resposta é sim. "Exportar isso to CSV" faz uma busca de modelo para export. "Mostre-me os pedidos do mês passado" faz não obrigue-o a procurar uma ferramenta de configuração de filtro, para que ela permaneça alinhada. Índice estatísticas, especificações salvas, introspecção de relacionamento e mudança gradual superfícies são todas as coisas que um usuário pede pelo nome quando deseja, e nunca implicitamente.

Vinte e sete em linha não é um número que teríamos defendido antecipadamente. É o número que sobreviveu ao contato com o modelo contra o qual enviamos.

A corrida que teria tornado a descoberta silenciosamente inútil

A descoberta tem uma restrição de tempo que é fácil de errar e difícil de perceber.

Quando a ferramenta de pesquisa retorna correspondências, esses nomes devem ingressar no conjunto permitido antes que a próxima etapa do modelo seja preparada. O lugar óbvio para fazer isso é o gancho que é acionado quando uma etapa é concluída. Esse gancho está documentado para disparar, em alguns Versões do SDK, após a preparação da próxima etapa, o que significa a mutação pousa um passo tarde demais.

O modo de falha é desagradável. O modelo pesquisa. Obtém uma nomenclatura de resultado correta a ferramenta de que necessita. Ele chama essa ferramenta na próxima etapa e é informado à ferramenta não existe. Intermitente, dependendo de qual versão do SDK você resolveu, e parece um modelo estúpido, em vez de um corredor quebrado.

A correção é alterar o conjunto permitido dentro da própria execução da ferramenta de pesquisa, que é garantido para ser concluído antes que o loop avance. Isso é uma linha diferença em onde uma declaração reside, e é a diferença entre um mecanismo de descoberta funcional e que falha uma fração do tempo para razões que ninguém atribuirá corretamente.

Três pesquisas e depois pare

A pesquisa é limitada a 3 chamadas por turno do agente. O quarto retorna isso em vez disso de corrida:

{"error": "search-budget-exhausted", "budgetCap": 3}

O limite existe por causa de um loop específico. A modelo procura, não encontra o que imaginou, procura novamente por um sinônimo, também não encontra e queima todo o seu orçamento de etapas dentro da ferramenta de pesquisa sem nunca tocar no banco de dados. Limitá-lo força uma decisão, comprometa-se com uma das ferramentas já encontrou, ou pergunte ao usuário, no ponto em que mais pesquisas pararam de pagar.

A mensagem de erro quando um modelo chama uma ferramenta que não descobriu segue o mesmo princípio que usamos para cada validador no agente:

Tool 'startExport' not in active set. Call searchTools(query='startExport')
to discover it, or use one of: <inline tool names>

Uma rejeição que nomeia a ação de recuperação custa uma etapa extra. Uma rejeição isso apenas diz que não custa o turno.

Uma linha por ferramenta, todo o resto derivado

Cada ferramenta é declarada uma vez, em uma única lista simples, e a linha carrega o toda a identidade da ferramenta: seu nome e descrição, as palavras-chave que a pesquisa corresponde ativado, se ele inicia in-line ou detectável, em qual nível ele é executado e como ele é exposto em MCP.

Essas camadas são tão importantes quanto a divisão de visibilidade. Vinte e uma ferramentas são silencioso, lê aquela execução sem interromper ninguém. Dezesseis estão bloqueados atrás da escada de autorização. Exatamente um não pertence a nenhum dos dois, porque o a ferramenta de pesquisa não é um recurso que o agente usa em seus dados; faz parte do loop em si. MCP a exposição é um terceiro eixo na mesma linha: somente leitura, teste, completo, ou excluído completamente, quais são as três ferramentas.

A regra que mantém isso honesto é que todas as outras listas no sistema são derivado dessas linhas , o conjunto de camadas silenciosas, as camadas de escopo MCP, o conjunto com escopo de gravação e nenhum deles é mantido manualmente. Um silêncio mantido à mão lista ao lado de uma lista MCP mantida à mão é exatamente como uma ferramenta termina corretamente bloqueada no chat e silenciosamente desbloqueado para um cliente externo.

A restrição que não prevíamos é que a lista de declarações deve conter zero importações de tempo de execução. Ele é compartilhado pela interface do desktop e pelo back-end, e um uma única importação atinge, transitivamente, uma dependência criptográfica somente do Node por meio de um implementação da ferramenta. Coloque isso no pacote do navegador e o aplicativo falhará em carga do módulo. Nem o verificador de tipo nem os testes de unidade detectam, ambos resolvem a importação felizmente. O que pega é um teste que lê o arquivo como texto e falha em qualquer declaração de importação, o que parece grosseiro até o primeiro vez que isso te salva.

Quais transferências se você estiver construindo uma

Conte suas ferramentas antes de defender sua arquitetura. A divisão certa é uma medição, não um princípio.
Teste a descoberta em relação ao seu modelo mais fraco. Um modelo de fronteira irá procurar quando deveria; isso não diz nada sobre o modelo escolhido pelos usuários.
Decida a visibilidade determinando se a frase do próprio usuário nomeia a ferramenta. Ferramentas invocado implicitamente pertence ao inline; ferramentas que as pessoas pedem pelo nome podem ser encontradas.
Verifique quando os step hooks do seu framework realmente disparam antes de colocar qualquer coisa sensível à ordem em um.
Limite as meta-ferramentas. Qualquer coisa que possa ser chamada repetidamente sem tocar o mercado imobiliário será, e uma etapa do orçamento gasto na pesquisa é uma perda de tempo.
Faça com que os erros da ferramenta não descoberta nomeiem a chamada de recuperação, da mesma forma que qualquer outra erro do validador.
Declare cada ferramenta uma vez e derive todas as outras listas dela. Dois guardados à mão listas das mesmas ferramentas eventualmente discordam, e a discordância aparece em um limite de segurança.
Se um módulo carrega uma restrição de carga que seu compilador não consegue expressar, escreva o teste bruto que o aplica como texto.

Onde isso funciona

Tudo isso vem dentro do DynoTable's catálogo de ferramentas, consultas com reconhecimento de esquema por conta própria

credenciais, com gravações que só chegam a um área de preparação revisável. As mesmas declarações impulsionam o servidor MCP ao qual os agentes externos se conectam, onde o nível de exposição em cada linha torna-se o escopo concedido a um cliente externo; como tornamos isso seguro (OAuth, consentimento, isolamento de credenciais) é uma história separada.

E a camada por baixo de tudo isso, os validadores que fazem cada uma dessas ferramentas sobrevivível por um modelo barato, é sua própria postagem.