2026-08-01T05:02:08.260Z
Ingeniería de contexto para los agentes de AI: auditoría del ciclo de contexto de Manus
Convierta las lecciones de ingeniería de contexto de Manus en recibos para la estabilidad de caché, la continuidad de las herramientas, el contexto restablecible, la evidencia de fallas, el progreso y los resultados.
La respuesta práctica a Ingeniería de contexto para agentes AI: Lecciones de la construcción de manuales es no copiar seis trucos rápidos. Convierte cada lección en una invariante que puedas inspeccionar durante una carrera. Un prefijo estable debe tener una versión y un hash. Una herramienta mencionada en la historia todavía debe tener un esquema resuelvable. El material compacto debe tener una referencia restablecible. El objetivo actual debe tener un límite de revisión y frescura. Las acciones fallidas deben dejar pruebas redactadas. Las acciones repetidas deben compararse con los cambios de salida. Un informe terminal debe requerir aún un recibo de resultado. Eso te da un contrato de salud en contexto. Puede distinguir entre una carrera eficiente, una carrera recuperable, una carrera haciendo progresos útiles, y una carrera que en realidad es segura de llamar completa. Los hits de caché y los recuentos de tokens más bajos ayudan, pero ninguno demuestra que el agente guardó la evidencia requerida para terminar correctamente. Lea las lecciones de Manus como afirmaciones con límites El Trabajo de ingeniería de Manus original describe las opciones de diseño local alcanzadas durante la construcción de su marco de agentes. Su autor informa una relación promedio de token de entrada a salida de aproximadamente 100:1 para Manus y argumenta que el comportamiento de prefijo cache por lo tanto importa mucho para la latencia y el costo. El artículo recomienda: Mantener el prefijo inmediato estable y la determinación de la serialización determinista; enmascarar las acciones en lugar de eliminar las definiciones de herramientas en medio de la ejecución; externalizar el contexto de grandes dimensiones a los archivos restablecibles; reescribir una lista de tareas para que el objetivo vuelva a la atención reciente; conservar las acciones y observaciones fallidas para que el modelo pueda adaptarse; introducir variaciones controladas para resistir patrones de comportamiento repetitivos. Estas son hipótesis de ingeniería útiles, no umbrales universales. Las cachées de los proveedores difieren. Algunos tiempos de ejecución pueden versionar esquemas históricos de herramientas de forma segura. Una URL puede ser conservada pero más tarde se vuelve inaccesible. Las huellas crudas pueden contener secretos. Repetir el objetivo cada ocho pasos es un valor de prueba, no una ley general. Las pruebas independientes también defienden que la capacidad de contexto anunciada sea considerada como una garantía de salud. Anthropic s Orientación de ingeniería contextual enmarca el contexto como el estado completo de inferencia instrucciones del sistema, herramientas, datos externos y historial de mensajes y recomienda mantener el conjunto de señales altas más pequeño que admita el comportamiento deseado. También describe la recuperación justo en el tiempo, la divulgación progresiva, la compactación, las notas estructuradas y la separación de múltiples agentes como diferentes estrategias con diferentes costos. Los modelos controlados por Chromas Evaluación de la rotura del contexto probaron 18 modelos mientras variaba la longitud de entrada y se informó de degradación no uniforme. Los distractores, la distancia semántica y la estructura del pajar cambiaron el rendimiento. La implicación operativa es modesta pero importante: dentro del límite del contexto no es un veredicto. Todavía necesitas pruebas de que el contexto actual apoya la decisión actual. Construir un recibo para seis mutaciones de contexto Captura hashes y contadores, no las instrucciones crudas. Se puede adjuntar un recibo útil a cada punto de decisión: Los campos responden a preguntas separadas. Prefijo estabilidad es una verificación de eficiencia. Registra la versión estable de la plantilla y un hash de contenido sobre el prefijo cachéable. Excluir valores volátiles como un sello de tiempo por solicitud de ese prefijo cuando el tiempo de ejecución lo permita. Un cambio de hash no es automáticamente un error de tarea: si la salida útil todavía se mueve, clasifique la ejecución como degradada e investigue la interrupción. Continuidad del esquema de herramientas es una verificación de la integridad de la decisión. Mantenga un registro de esquemas con versiones o una traducción explícita de las llamadas de herramientas históricas a su contrato definidor. Si una acción previa dice browser fetch pero el contexto actual ya no define esa acción o una versión compatible, el modelo puede estar razonando desde un registro incompleto. Eso debería bloquear un veredicto saludable. Restaurable contexto externo es una verificación de recuperación. Un camino de archivo, clave de objeto, consulta o URL es solo una referencia. Combínalo con una digestión de integridad cuando sea posible, una última verificación de accesibilidad, alcance y la operación que lo restablezca. La eliminación de un documento de la ventana en vivo mientras se conserva una referencia verificada es una compresión reversible. Arrojarlo sin ninguna referencia utilizable es pérdida de evidencia. Objectivo de frescura es un control de atención. Una revisión del plan de tareas debe identificar el objetivo activo, las limitaciones aceptadas, los hitos completados y la próxima decisión. Medir su edad en pasos o tiempo. No agregue infinitamente planos duplicados; actualice un recibo compacto cuando el trabajo cambie significativamente o su límite de frescura expire. Retición de fallas es una verificación de aprendizaje y auditoría. Cuenta las acciones fallidas y los registros de fallas conservados. Almacenar la clase de error, la herramienta, la identidad de intento, la decisión de retoma, y un digest redactadono de salida cruda arbitraria. Si se produjeron dos fallas pero solo queda un registro seguro, no se puede justificar un retraso posterior a partir de pruebas completas. La repetición frente al progreso es una verificación de deriva. Una acción repetida no es un bucle en sí misma: la paginado, las encuestas y los retries limitados pueden ser legítimos. Combine una firma de acción con un contador de delta de salida, frescura objetiva, estado de dependencia y presupuesto de nuevo. Tres acciones repetidas con artefactos cambiados pueden funcionar; tres sin delta estatal merecen un veredicto de riesgo de bucle. Las lecciones de prefijo estable y variación controlada no son contradictorias. Mantenga determinista el prefijo cachéable y los contratos de herramientas. Aplicar la variación necesaria después de ese prefijo en ejemplos, observaciones de acción o una política de selección limitada y medir si cambia el progreso útil. Aplicar una regla de prioridad en lugar de promediar las señales No desplome estos campos en una puntuación opaca. Una corriente barata con prefijo estable con contexto irrecuperable no es en su mayoría saludable. Utilice la prioridad: 1. unsafe las referencias históricas de las herramientas no se resuelven, no se pueden restaurar pruebas compactadas o desaparece un registro de fallas; 2. loop risk el objetivo es obsoleto y las acciones se repiten sin cambios de salida; 3. unverified el agente notifica la finalización terminal sin un recibo de resultado válido; 4. healthy pasará cada invariante de contexto y se verificará el resultado específico de la tarea; 5. Degraded la integridad del contexto permanece intacta, pero el prefijo churn u otro defecto de eficiencia está presente; 6. Working pasan invariantes, cambios de salida útiles, y la ejecución no es terminal. Este ordenamiento hace deliberadamente que los fracasos de integridad sean más fuertes que las ganancias de eficiencia. El dispositivo de acompañamiento cambia una condición a la vez: Resultado esperado: Los ocho casos incluyen un resultado verificado, un progreso intermedio útil, un cambio de prefijo, una derivación del esquema de herramientas, una compactación irreversible, pruebas de fallas borradas, repetición de objetivos obsoletos y una finalización reportada sin recibo. Un resultado es intencionalmente inconveniente: el caso cache churn es degradado , no inseguro. Su prefijo cambió, pero los esquemas, las referencias, los fracasos y el progreso útil permanecen intactos. Por el contrario, irreversible compaction es unsafe aunque su prefijo es estable. Esa es la diferencia entre un problema de costes y un problema de pruebas. Verifique el recibo sin recoger la conversación El recibo debe revelar si existe evidencia sin subir la prueba misma. Para el prefijo, mantenga un identificador de plantilla y digeste. Para las herramientas, retenga la versión del esquema, el nombre de la acción y el resultado de compatibilidad. Para el contexto externo, mantenga una referencia de alcance, digestación, recuento de bytes, resultado de accesibilidad y tiempo de frescura. Para fallas, mantenga una clase redactada y el identificador de intento. Para progresar, retenga hashes o contadores para los artefactos esperados. Mantenga las instrucciones, las respuestas, las credenciales, las cargas útiles de herramientas en bruto y los caminos absolutos del host fuera de la telemetría compartida a menos que un contrato de datos explícito y separado los requiera. Utilice tres pruebas antes de adoptar el contrato. Primero, ejecuta una repetición de mutación única . Comience con un elemento conocido y cambie sólo un campo. El veredicto debe cambiar por la razón que esperas. Si la eliminación de una referencia restablecible deja el estado sano, la regla es demasiado débil. En segundo lugar, ejecuta un canario redacción . Coloque un secreto sintético en una carga útil de fracaso, procesarlo a través del constructor de recibos, y afirme que el secreto está ausente mientras la clase de error y la decisión de retomar la prueba sobreviven. La retención de la "materia equivocada" no autoriza la retención de contenido sensible. En tercer lugar, ejecuta un contraejemplo de resultado Z . Enviar al clasificador un mensaje de agente terminal mientras se retiene el recibo de entrega real. Debe devolver unverified . A continuación, añadir la verificación específica de tarea a digest de archivo, prueba de aprobación, lectura de API de destino o aprobación humana y confirmar que sólo este cambio permite healthy . El control de resultados es necesariamente específico del flujo de trabajo. Una tarea de investigación puede requerir una cobertura de la fuente citada y un informe guardado. Una tarea de despliegue puede requerir una respuesta de salud en vivo y la paridad de versiones. Una tarea de correo electrónico puede requerir la lectura del buzón de destino. No hay prueba de que se haya logrado un objetivo arbitrario. Usar el contrato como límite, no como reclamo de producto La publicación de Manus es valiosa porque expone las tensiones reales del diseño: eficiencia de caché frente al contexto mutable, ventanas más pequeñas frente a pérdida irreversible, comportamiento estable frente a repetición y limpieza de errores frente a evidencia de aprendizaje. El movimiento operativo es hacer que esas tensiones sean inspectables. Adoptad el contrato cuando podáis responder a estas preguntas por una carrera real: ¿Cambió el prefijo cachéable, y se esperaba eso? ¿Puede interpretarse todavía cada acción de herramienta histórica? ¿Se puede restaurar y comprobar la integridad de cada observación omitida? ¿Es el objetivo actual lo suficientemente fresco para la próxima decisión? ¿Todas las acciones fallidas dejaron pruebas seguras? ¿Las acciones repetidas cambian el estado de la tarea? ¿Qué recibo separado prueba el resultado solicitado? Si no se conoce la respuesta de integridad, conserve unknown o unsafe ; no se fabrique en verde. Si sólo se degrada la eficiencia mientras la evidencia y el progreso permanecen sólidos, mantenga el funcionamiento y resuelva el problema de los costes por separado. Sidewisp se encuentra actualmente en versión preliminar privada. Su experiencia pública es un sitio web de acceso temprano y una demostración interactiva; la recopilación de agentes de producción y la salud y el monitoreo de contexto no se envían generalmente. La dirección del producto prevista es transformar pruebas como la frescura, la continuidad del contexto, el progreso útil y los resultados verificados en una visión clara de la salud, manteniendo visibles las incertidumbres y los límites de aprobación.