As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Escopo da ferramenta
Há duas abordagens para o desenvolvimento de ferramentas: granular e granulada.
Granular
Em uma abordagem granular, você criaria uma ferramenta por API, ação ou consulta. Por exemplo, você pode criarcreate_issue,get_issue, add_labelassign_issue, e close_issue ferramentas para seu repositório Git. Isso permitiria que o LLM fizesse chamadas granulares para cada API e orquestrasse cada uma conforme necessário. Considere o seguinte aviso: “Crie um problema para o serviço do produto chamado 'A consulta retorna apenas resultados parciais', rotule-o como um bug e de alta prioridade e atribua-o a Alice”. A imagem a seguir mostra como uma tool-per-API abordagem responderia a essa solicitação.
Nessa abordagem, o prompt do sistema e cada definição de ferramenta registrada são fornecidos ao LLM em cada chamada. Isso consome contexto adicional e incorre em uma penalidade de latência porque cada chamada de ferramenta representa uma chamada individual para o LLM. Também aumenta a complexidade de lidar com erros no fluxo de trabalho.
Baixa granularidade
Uma abordagem granulada ou orientada por fluxo de trabalho seriam ferramentas orientadas ao fluxo de trabalho. A ferramenta se concentra na intenção end-to-end do usuário em vez da estrutura da API. Em vez de uma tool-per-API, você tem uma ferramenta que chama muitos de forma determinística. APIs Usando o exemplo anterior do repositório Git, você pode criar uma create_and_setup_issue ferramenta que é chamada uma vez pelo agente. A implementação da ferramenta cria o problema, adiciona rótulos e o atribui a um usuário, com base nos parâmetros fornecidos à ferramenta. A imagem a seguir mostra como uma abordagem granulada processaria o mesmo prompt.
Essa abordagem mostra como toda a complexidade permanece oculta da camada LLM. Quando a lógica de orquestração é incorporada à implementação da ferramenta, todas as etapas sequenciais, o registro, a lógica de repetição, os disjuntores e a limitação de taxa são executadas de forma determinística na ferramenta. A abordagem orientada pelo fluxo de trabalho torna mais simples para o LLM invocar a ferramenta correta com os parâmetros certos. É importante observar que algumas APIs podem já fornecer a intenção do fluxo de trabalho, como a API do Amazon RunInstances EC2. Nesses casos, a tool-per-API pode fornecer o design orientado ao fluxo de trabalho que você deseja.
No entanto, as ferramentas também podem se tornar muito grossas. Se sua única ferramenta de fluxo de trabalho tentar fazer muitas coisas e tiver muitos parâmetros possíveis, o LLM poderá ter dificuldade em raciocinar sobre como usar a ferramenta corretamente. Também pode criar desafios com a seleção de parâmetros e o tratamento de erros. Portanto, o desenvolvimento de ferramentas deve encontrar um equilíbrio que se alinhe à intenção do usuário e evite pouca ou muita funcionalidade em uma única ferramenta. Recomendamos que você crie ferramentas com base em fluxos de trabalho completos do usuário, agrupando operações que normalmente ocorrem juntas (como três ou mais chamadas de API). Também recomendamos que você decomponha ferramentas que excedam oito ou mais parâmetros ou lidem com várias intenções de usuário distintas. Teste com instruções reais para verificar se os agentes podem usar cada ferramenta corretamente.
Se você tiver fluxos de trabalho complexos e dinâmicos que não podem ser facilmente encapsulados como uma ferramenta determinística, considere usar o padrão. agent-as-tool Em vez de seu agente principal tentar orquestrar tarefas complexas em um fluxo de trabalho, um agente especializado pode atuar como uma ferramenta. Esses tipos de ferramentas podem implementar tomadas de decisão e ramificações avançadas, além de lidar com erros e repetir a lógica que não pode ser facilmente gerenciada em código determinístico. Isso é semelhante, mas distinto do protocolo Agent2Agent (A2A
Recomendamos que você comece com a análise do fluxo de trabalho mapeando os fluxos de trabalho mais comuns dos usuários para identificar os principais recursos de que cada agente precisa. Isso estabelece seu conjunto mínimo de ferramentas viável. Com base em nossa experiência no desenvolvimento de servidores MCP em grande escala, recomendamos as seguintes práticas. Quando essas práticas entrarem em conflito, priorize a intenção do usuário e o fluxo de trabalho.
Melhores práticas para o escopo da ferramenta MCP
-
Pense em histórias de usuários e agrupe operações comuns — as ferramentas devem ser mapeadas diretamente para concluir as interações do usuário, em vez de exigir a orquestração de várias operações. Se os fluxos de trabalho normalmente exigirem três ou mais chamadas separadas, combine-as em uma única ferramenta. Isso reduz a carga cognitiva no LLM, minimiza o número de chamadas de ferramentas, reduz o consumo de contexto e a latência necessários para concluir tarefas e melhora a precisão e a latência.
-
Limite os parâmetros a oito ou menos — Se uma ferramenta exceder oito parâmetros, decomponha-a em várias ferramentas. LLMs lutam com a seleção de parâmetros à medida que a complexidade aumenta.
nota
Se as operações de agrupamento exigirem mais de oito parâmetros, priorize o agrupamento em vez da contagem de parâmetros, pois simplificar o fluxo de trabalho é mais valioso do que limites estritos de parâmetros.
-
Operações separadas de leitura e gravação — forneça ferramentas diferentes para ler dados e modificá-los. Essa separação torna explícito quando os agentes estão realizando operações potencialmente destrutivas, permite políticas de autorização diferentes e reduz o risco de modificações não intencionais durante a coleta de informações.
-
Forneça padrões razoáveis — Crie ferramentas para que o LLM precise especificar somente os parâmetros específicos da solicitação individual. Os padrões reduzem a complexidade dos parâmetros e melhoram a precisão da seleção de ferramentas, minimizando as informações sobre as quais o LLM deve raciocinar.
-
Prefira a execução determinística — Torne a execução da ferramenta e a saída determinísticas quando possível. As ferramentas determinísticas são mais confiáveis e fáceis de testar. Para fluxos de trabalho complexos que exigem orquestração inteligente, lógica de ramificação ou tratamento avançado de erros que não podem ser facilmente gerenciados em código determinístico, considere usar agentes especializados como ferramentas. No entanto, use esse padrão seletivamente porque ele adiciona complexidade.
