Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Alcance de la herramienta
Existen dos enfoques para desarrollar herramientas: granulares y pormenorizadas.
Granular
En un enfoque detallado, crearía una herramienta por API, acción o consulta. Por ejemplo, puedes crearcreate_issue, get_issue add_labelassign_issue, y close_issue herramientas para tu repositorio de Git. Esto permitiría al LLM realizar llamadas granulares a cada API y organizar cada una de ellas según sea necesario. Considere la siguiente pregunta: «Cree un problema para el servicio del producto denominado «Query solo devuelve resultados parciales», etiquételo como error y de alta prioridad y asígnelo a Alice». La siguiente imagen muestra cómo respondería un tool-per-API enfoque a esta solicitud.
En este enfoque, el indicador del sistema y todas las definiciones de herramientas registradas se proporcionan al LLM en cada llamada. Esto consume más contexto e implica una penalización de latencia, ya que cada llamada a la herramienta representa una llamada individual al LLM. También aumenta la complejidad de la gestión de los errores en el flujo de trabajo.
Básicos
Un enfoque detallado o basado en el flujo de trabajo serían las herramientas orientadas al flujo de trabajo. La herramienta se centra en la intención del usuario más que en la estructura de la API. end-to-end En lugar de una tool-per-API, tienes una herramienta que llama a varias de forma determinista. APIs Usando el ejemplo anterior del repositorio de Git, puedes crear una create_and_setup_issue herramienta a la que el agente llame una vez. La implementación de la herramienta crea el problema, añade etiquetas y lo asigna a un usuario en función de los parámetros proporcionados a la herramienta. La siguiente imagen muestra cómo un enfoque detallado procesaría el mismo mensaje.
Este enfoque muestra cómo toda la complejidad permanece oculta en la capa LLM. Cuando la lógica de orquestación está integrada en la implementación de la herramienta, todos los pasos secuenciales (el registro, la lógica de reintento, los disyuntores y la limitación de velocidad) se realizan de forma determinista en la herramienta. El enfoque basado en el flujo de trabajo facilita que el LLM invoque la herramienta correcta con los parámetros correctos. Es importante tener en cuenta que es posible que algunas API ya proporcionen la intención del flujo de trabajo, como la API Amazon EC2RunInstances. En estos casos, a tool-per-API podría proporcionar el diseño orientado al flujo de trabajo que desea.
Sin embargo, las herramientas también pueden resultar demasiado gruesas. Si su única herramienta de flujo de trabajo intenta hacer demasiadas cosas y tiene muchos parámetros posibles, el LLM puede tener dificultades para razonar sobre cómo utilizar correctamente la herramienta. También puede crear problemas con la selección de parámetros y la gestión de errores. Por lo tanto, el desarrollo de herramientas debe lograr un equilibrio que se ajuste a la intención del usuario y evite que la funcionalidad de una sola herramienta sea insuficiente o excesiva. Le recomendamos que diseñe las herramientas en función de los flujos de trabajo completos de los usuarios, agrupando las operaciones que suelen producirse juntas (como tres o más llamadas a la API). También le recomendamos que descomponga las herramientas que superen ocho o más parámetros o que gestionen varias intenciones de usuario distintas. Realice pruebas con indicaciones reales para comprobar que los agentes pueden utilizar correctamente cada herramienta.
Si tiene flujos de trabajo complejos y dinámicos que no se pueden resumir fácilmente como una herramienta determinista, podría considerar la posibilidad de utilizar el patrón. agent-as-tool En lugar de que su agente principal intente organizar tareas complejas en un flujo de trabajo, un agente especializado puede actuar como una herramienta. Este tipo de herramientas permiten implementar procesos avanzados de toma de decisiones y ramificaciones, y pueden gestionar errores y reintentar una lógica que no se puede gestionar fácilmente en un código determinista. Es similar, pero distinto, al protocolo Agent2Agent
Le recomendamos que comience con el análisis del flujo de trabajo mapeando los flujos de trabajo de los usuarios más comunes para identificar las capacidades principales que necesita cada agente. Esto establece su conjunto de herramientas mínimo viable. Basándonos en nuestra experiencia en el desarrollo de servidores MCP a escala, recomendamos las siguientes prácticas. Cuando estas prácticas entren en conflicto, priorice la intención del usuario y el flujo de trabajo.
Mejores prácticas para determinar el alcance de las herramientas MCP
-
Piense en las historias de los usuarios y agrupe las operaciones comunes: las herramientas deberían mapearse directamente para completar las interacciones de los usuarios, en lugar de requerir la organización de varias operaciones. Si los flujos de trabajo suelen requerir tres o más llamadas independientes, combínelas en una sola herramienta. Esto reduce la carga cognitiva del LLM, minimiza el número de llamadas a las herramientas, reduce el consumo de contexto y la latencia necesarios para completar las tareas, y mejora la precisión y la latencia.
-
Limite los parámetros a ocho o menos: si una herramienta supera los ocho parámetros, descompóngala en varias herramientas. LLMs tienen problemas con la selección de parámetros a medida que aumenta la complejidad.
nota
Si las operaciones de agrupación requieren más de ocho parámetros, priorice la agrupación por encima del recuento de parámetros, ya que simplificar el flujo de trabajo es más valioso que limitar estrictamente los parámetros.
-
Operaciones de lectura y escritura separadas: proporcione diferentes herramientas para leer los datos y modificarlos. Esta separación hace explícito cuándo los agentes realizan operaciones potencialmente destructivas, permite diferentes políticas de autorización y reduce el riesgo de modificaciones no deseadas durante la recopilación de información.
-
Proporcione valores predeterminados razonables: diseñe herramientas de modo que el LLM necesite especificar solo los parámetros que son específicos de la solicitud individual. Los valores predeterminados reducen la complejidad de los parámetros y mejoran la precisión de la selección de herramientas al minimizar la información sobre la que el LLM debe razonar.
-
Prefiera la ejecución determinista: haga que la ejecución y la salida de la herramienta sean deterministas siempre que sea posible. Las herramientas deterministas son más fiables y fáciles de probar. Para flujos de trabajo complejos que requieren una orquestación inteligente, una lógica de ramificación o una gestión avanzada de errores que no se pueden gestionar fácilmente en un código determinista, considere la posibilidad de utilizar agentes especializados como herramientas. Sin embargo, utilice este patrón de forma selectiva porque añade complejidad.
