📺 Vídeo de estudio recomendado hoy: https://www.youtube.com/watch?v=6_BcCthVvb8
El Arte de la Ingeniería de Contexto: Cómo Construir Agentes Eficaces
La ingeniería de contexto ha surgido como el nuevo campo de batalla para los desarrolladores de IA, desplazando al tradicional “prompt engineering” en la creación de agentes autónomos. A medida que los agentes operan durante más tiempo y utilizan más herramientas, la gestión inteligente de lo que entra y sale de la ventana de contexto determina el éxito o el fracaso del sistema.
Pregunta central: ¿Cómo podemos evitar la degradación del rendimiento de los agentes cuando el historial de mensajes crece de forma descontrolada?
Puntos clave
- El fenómeno del “Context Rot” o putrefacción del contexto degrada la precisión de los modelos a medida que aumenta la carga de tokens.
- La diferenciación crítica entre compactación (reversible mediante sistema de archivos) y resumen (irreversible mediante esquemas).
- Arquitectura de espacio de acción en tres capas: funciones atómicas, utilidades de sandbox y paquetes/APIs.
- El uso de esquemas estructurados como “contratos” para la comunicación entre agentes y la reducción de información.
⏱️ Tiempo de lectura: aprox. 8 minutos · Te ahorra unos 53 minutos frente a ver el vídeo.
¿Quieres tomar notas mientras ves el vídeo? Haz clic en la imagen de abajo y deja que AI Notebook extraiga los puntos clave por ti 👇
El Surgimiento de la Ingeniería de Contexto
Más allá del Prompt Engineering
La ingeniería de contexto surge como respuesta crítica al crecimiento desmesurado de mensajes que los agentes autónomos generan al invocar herramientas de forma recursiva y libre.
Mientras que el prompt engineering se centraba en cómo hablarle al modelo, esta nueva disciplina gestiona qué información debe estar presente para evitar que el rendimiento se degrade ante ventanas de contexto saturadas, un fenómeno conocido técnicamente como la putrefacción del contexto o “context rot”.
Cuando un agente realiza una tarea compleja, puede llegar a ejecutar hasta cincuenta llamadas a herramientas diferentes, lo que provoca una acumulación masiva de datos en el historial. Si no se gestiona esta información, la precisión disminuye y el coste de computación se dispara. Por ello, la ingeniería de contexto se define hoy como el arte y la ciencia de llenar la ventana de contexto con la información precisa y necesaria para el siguiente paso del agente, optimizando cada token utilizado.
💡 Profundizando
Q: ¿Por qué no simplemente usar modelos con ventanas de contexto de un millón de tokens?
A: Porque aunque el modelo lo soporte, el fenómeno “Context Rot” hace que la atención se disperse y el modelo empiece a alucinar o repetir errores.
Q: ¿Cuándo ocurre exactamente la degradación del rendimiento?
A: Generalmente, los modelos empiezan a perder eficacia entre los 128k y los 200k tokens, mucho antes de alcanzar sus límites teóricos.
Estrategias de Reducción: Compactación vs. Resumen
Manteniendo la Reversibilidad
En el desarrollo de Manus, el equipo aprendió que no toda reducción de contexto es igual, separando las operaciones en compactación técnica y resumen semántico.
La compactación es un proceso reversible donde la información se externaliza al sistema de archivos del agente. Si una herramienta escribe un archivo largo, el historial solo guarda la ruta, eliminando el contenido masivo pero manteniendo la capacidad de recuperarlo mediante una lectura posterior si es necesario.
El resumen, por el contrario, es una operación destructiva e irreversible que condensa la información mediante un nuevo paso por el LLM. Para que este proceso no resulte en pérdida de datos críticos, Pete recomienda encarecidamente el uso de esquemas estructurados en lugar de resúmenes de texto libre. Al obligar al modelo a llenar campos específicos como “objetivos cumplidos” o “archivos modificados”, se garantiza que los puntos clave de la misión permanezcan intactos mientras se eliminan miles de tokens de ruido innecesario.
💡 Profundizando
Q: ¿Cuál es el umbral para activar estas reducciones?
A: Se recomienda activar la compactación al llegar a los 128k tokens y dejar el resumen como último recurso cuando la compactación ya no libera espacio suficiente.
Q: ¿Cómo se evita que el modelo pierda el hilo tras un resumen?
A: La clave es mantener siempre las últimas 2 o 3 llamadas a herramientas en formato completo para que el agente conserve su “memoria a corto plazo” intacta.
Espacio de Acción en Tres Capas
Optimizando la Ejecución del Agente
Para evitar la confusión de contexto causada por tener demasiadas herramientas disponibles simultáneamente, Manus utiliza una estructura jerárquica que delega la complejidad fuera del LLM.
La primera capa consiste en funciones atómicas integradas directamente en el esquema de llamadas del modelo, como lectura de archivos o navegación básica. Estas son universales y altamente predecibles.
La segunda capa traslada la lógica a utilidades de sandbox dentro de un entorno Linux. Aquí, el agente utiliza comandos de terminal para ejecutar herramientas complejas sin saturar su ventana de contexto con descripciones de funciones. Por último, la tercera capa utiliza paquetes de Python y APIs autorizadas, donde el agente escribe scripts para procesar grandes volúmenes de datos localmente. Esto permite que el modelo solo reciba el resultado final procesado, en lugar de inundar el contexto con datos crudos de mercado financiero o registros extensos de bases de datos.
💡 Profundizando
Q: ¿Cuántas herramientas debería tener un agente en su contexto principal?
A: Pete sugiere un máximo de 20 a 30 herramientas atómicas para evitar la confusión y el desperdicio de tokens en la caché.
Q: ¿Cómo aprende el agente a usar las herramientas del sandbox?
A: Se le proporciona un directorio específico y se le instruye para usar el comando --help cuando necesite entender una utilidad nueva, imitando el comportamiento de un programador humano.
Conclusiones Clave
La ingeniería de contexto no consiste en añadir capas de complejidad, sino en simplificar la tarea del modelo para que pueda centrarse en el razonamiento puro. La lección más importante de Manus tras múltiples iteraciones es la importancia de confiar en la capacidad creciente de los modelos base mientras se eliminan “trucos” arquitectónicos innecesarios que solo añaden latencia.
El uso de sistemas de archivos externos como memoria de trabajo y la implementación de sub-agentes con esquemas de salida estrictos actúan como contratos que mantienen la coherencia del sistema. Al final del día, el éxito de un agente depende de un equilibrio delicado entre lo que el modelo sabe, lo que puede recuperar y lo que elige olvidar deliberadamente para seguir operando con eficiencia.
Preguntas y Respuestas
Q1: ¿Por qué Manus prefiere el sistema de archivos sobre las bases de datos vectoriales (RAG)?
A: En sesiones de agentes dinámicos, construir un índice vectorial sobre la marcha es demasiado lento. El uso de comandos como grep y glob sobre el sistema de archivos es mucho más eficiente para el acceso rápido a la información.
Q2: ¿Cómo manejan la comunicación entre múltiples agentes sin saturar el contexto?
A: Utilizamos un patrón de “agente como herramienta” (Agent-as-a-Tool). El agente principal define un esquema de salida (un contrato) y el sub-agente debe devolver el resultado siguiendo estrictamente ese formato mediante decodificación restringida.
Q3: ¿Qué opinan sobre el uso de modelos de código abierto frente a modelos propietarios?
A: Actualmente, el coste de gestionar la caché de KV (Key-Value) en modelos abiertos a gran escala es superior al uso de APIs como Anthropic o Gemini, que ofrecen gestión de caché optimizada y mayor capacidad de razonamiento.
Q4: ¿Cómo se gestionan las correcciones del usuario en sesiones largas?
A: Implementamos un sistema de “conocimiento explícito”. Cuando un usuario corrige un comportamiento (como el uso de fuentes específicas en gráficos), el agente propone guardar esa regla en su memoria a largo plazo para futuras sesiones.
Q5: ¿Cuál es el mayor error al diseñar la arquitectura de un agente hoy?
A: El “over-engineering”. Muchos desarrolladores crean demasiados sub-agentes basados en roles humanos (diseñador, programador, etc.), lo cual es ineficiente. Es mejor tener menos agentes con propósitos funcionales claros y ventanas de contexto limpias.
Q6: ¿Cómo aseguran la seguridad en un sandbox conectado a internet?
A: Monitorizamos el tráfico saliente para evitar la fuga de tokens y requerimos confirmación manual del usuario para acciones sensibles dentro del navegador o cambios críticos en el sistema.
