Este es otro artículo de lectura obligada para los estudiantes que quieran aprender más sobre ingeniería de contexto. Este artículo analiza cómo solucionar el problema de tener demasiadas herramientas MCP. Quienes se dedican al desarrollo de agentes y utilizan numerosas herramientas MCP saben que el principal inconveniente es que consumen demasiado contexto, lo que no solo incrementa los costos, sino que también afecta la calidad de la inferencia y la generación. Otro problema es que los resultados intermedios devueltos por la herramienta MCP también consumen mucho espacio de contexto. Mientras leía este artículo, no pude evitar elogiar a Manus. Han explorado la ingeniería contextual en profundidad, y las técnicas de ingeniería que comparten son muy similares a las que ya han compartido anteriormente (más adelante publicaré en los comentarios los artículos relacionados con Manus que compartí antes). El enfoque de Anthropic también es muy simple y directo: tratar el "código" como una herramienta y luego llamar a MCP desde el código. Hacer esto tiene muchas ventajas: 1. Se resolvió el problema de demasiadas definiciones de herramientas en los avisos del sistema. No es necesario cargar todas las herramientas MCP en el símbolo del sistema; solo necesita definir una herramienta de "código". ¿Y si necesitamos herramientas? Todo este código se encuentra almacenado en un directorio unificado. Puede encontrar la herramienta adecuada buscando en el directorio. Por ejemplo, aquí tiene un ejemplo de directorio del artículo: servidores ├── google-drive │ ├── getDocument.ts │ ├── ... (otras herramientas) │ └── index.ts ├── Salesforce │ ├── updateRecord.ts │ ├── ... (otras herramientas) │ └── index.ts └── ... (otros servidores) ¿Y si no encuentras las herramientas que necesitas? ¡Escribe una ahora mismo! Puedes guardarla y usarla de nuevo la próxima vez. 2. Se resolvió el problema de los resultados devueltos excesivamente largos por la herramienta MCP. Por ejemplo, si queremos usar la herramienta MPC para obtener 10 000 filas de datos y luego filtrarlas y transformarlas para obtener los datos que cumplen con los requisitos, primero podemos llamar a la herramienta MPC desde el código para obtener estas 10 000 filas de datos, luego filtrarlas desde el código y, finalmente, devolver solo 5 entradas de datos. De esta manera, el contexto solo necesita conservar esas 5 entradas de datos filtradas, en lugar de las 10 000 entradas de datos originales. 3. Se solucionó el problema de privacidad de datos. Si utiliza la herramienta MCP directamente, los datos que devuelve deben cargarse en el contexto y subirse al LLM cada vez. Puede usar código para procesar los datos confidenciales dos veces antes de añadirlos al contexto. 4. Persistencia de los resultados intermedios y acumulación de habilidades El código puede escribir algunos resultados intermedios en un archivo y guardarlos en el disco duro. Por un lado, esto no ocupa espacio de contexto y, por otro, permite guardarlos desde el disco duro en cualquier momento para evitar llamadas repetidas a MCP. Además, aunque gran parte del código se genera temporalmente, este código generado temporalmente se puede guardar y acumular como «habilidades». Con la adición del archivo SKILL.MD, se puede reutilizar repetidamente, al igual que las habilidades en Claude Code.
Quizás algunos recuerden a Voyager, un agente de Minecraft creado por @DrJimFan y su equipo en 2023. Podía programar habilidax.com/DrJimFan/statu…s para usarlas más tarde y, en definitiva, permitirle al agente realizar muchas acciones en Minecraft. Viéndolo ahora, estaba bastante adelantado a su tiempo.
@DrJimFan Manus dividió las herramientas en tres capas, predefinió muchas herramientas dex.com/dotey/status/1… al agente recuperarlas directamente a través del sistema de archivos, y también escribió código Python en tiempo real para crear herramientas.
La presentación inicial de Manus, "Ingeniex.com/dotey/status/1…tes de IA: Lecciones aprendidas de la creación de Manus",...
Tradubaoyu.io/blog/code-exec…/t.co/YXBXYDv0e4