La idea de Harness de Anthropic: la infraestructura de agentes avanza hacia un Agent OS

Fri, 10 Apr 2026 09:22:56 +0800

Anthropic publicó recientemente una práctica de ingeniería sobre Harness. En la superficie habla de implementación de producto, pero en realidad responde a una pregunta de más largo plazo:

Cuando las capacidades de los modelos cambian continuamente, ¿qué capas de un sistema Agent deben permanecer estables y cuáles deberían poder reemplazarse con rapidez?

Juicio Central

Mi lectura principal de este artículo es que la infraestructura de agentes se parecerá cada vez más a un Agent OS ligero.

El punto no es “fijar en código el mejor flujo de hoy”, sino “definir abstracciones de sistema estables a largo plazo”.

Por Qué Esto Importa

Muchos frameworks de agentes suelen tener estos problemas:

convierten carencias temporales del modelo en arquitectura permanente
confunden la ingeniería de prompts con límites del sistema
convierten un parche útil una vez en una dependencia de largo plazo

Los modelos se harán más fuertes. Un parche razonable hoy puede ser deuda técnica mañana.

La Solución de Anthropic: de un Harness Concreto a un Meta-Harness

Esta idea no promete una forma fija de orquestación, sino que abstrae tres interfaces estables:

session: historial recuperable de eventos y estado
harness: bucle de razonamiento y planificación (brain)
sandbox: entorno de ejecución y capacidades de herramientas (hands)

Una vez separadas, el sistema es más fácil de reemplazar, recuperar y ampliar.

1) Session No Es la Ventana de Contexto

Una idea clave es: Session no equivale al contexto del modelo.

Session debería ser un registro de eventos consultable, reproducible y recuperable, no una concatenación del historial que se introduce directamente en el modelo.

El valor de hacerlo así:

trimming no significa que la historia desaparezca
compaction no significa que los hechos se pierdan
la recuperación tras un fallo puede volver a la capa de eventos, en vez de depender de una memoria resumida

2) Harness Es una Capa de Orquestación Reemplazable

Harness debería centrarse en la planificación y la ejecución, no en poseer estado de negocio.

Una interfaz ideal se parece más a:

execute(name, input) -> string

Esto significa que el modelo solo necesita saber “qué capacidad puedo invocar”, sin quedar atado a un dispositivo, contenedor o sistema operativo concreto.

3) Sandbox Son las “Manos”, No el “Cerebro”

Cuando brain y hands están desacoplados:

el entorno de herramientas puede evolucionar de forma independiente
distintas infraestructuras pueden conectarse en paralelo
no hace falta precalentar un entorno de ejecución completo para cada sesión

Esto mejora directamente el arranque y la capacidad de escalar.

Ideas Sobre Rendimiento y Seguridad

Esta separación normalmente mejora a la vez el rendimiento y la seguridad.

En rendimiento:

se puede iniciar primero el brain y levantar las hands bajo demanda
se reduce la latencia hasta el primer token (TTFT)

En seguridad:

no se exponen credenciales de alto valor directamente al modelo
se usan proxy / vault controlados para acceso indirecto a credenciales
los límites de seguridad se construyen sobre restricciones del sistema, no sobre “el modelo no debería poder hacerlo”

Session on KnightLi Blog