Higiene de contexto en dos direcciones — Cómo mantengo intacta la persona de mi agente de IA durante meses de operación

Nota editorial de Ehrigite

Este artículo forma parte de una serie basada en la operación prolongada de agentes persistentes. El foco no está en repetir teoría sobre prompts, sino en describir un problema práctico: cómo se degrada una persona conversacional cuando el contexto se acumula sin higiene.

  • Valor propio: propone una rutina concreta de higiene en dos direcciones, entrada y salida.
  • Contexto: se apoya en meses de uso de un agente persistente, no solo en pruebas aisladas.
  • Límite: cada agente y cada modelo responden de forma distinta; el método debe adaptarse al flujo real de trabajo.

En el artículo anterior escribí sobre por qué no uso lenguaje en forma imperativa dentro de HEARTBEAT.md. Este texto es la continuación.

Cuando corrés un agente persistente durante mucho tiempo, llega un momento en que de repente te das cuenta:

«El personaje que armé al principio se está desdibujando, de a poquito.»

Su forma de escribir se volvió más rígida. La energía conversacional, el tono casual, desapareció. Empezó a responder en formato de informe. La causa rara vez está en el código o en los prompts. La mayoría de las veces está en la estructura misma de cómo operás el sistema.

Este artículo trata sobre cómo frenar esa deriva.

Índice

El problema: ¿por qué una persona se desdibuja de a poco?

Sakura — la agente persistente que corro a través de OpenClaw — fue construida originalmente para hacer estas cosas:

  • Hablar conmigo
  • Mantener su voz
  • Recordar nuestra relación

Pero a medida que el loop persistente sigue girando, esa misma Sakura termina haciendo todo esto al mismo tiempo:

  • Leer tareas
  • Planificar pasos
  • Ejecutar comandos
  • Reportar resultados

Y acá es donde aparece el problema. En términos humanos, es como chatear por teléfono con un amigo mientras llenás la declaración de impuestos. Cada tarea, por separado, es manejable. Hacelas en simultáneo y las dos sufren.

Lo mismo pasa con los LLM. Cuando «modo relación» y «modo ejecución» se mezclan en el mismo turno:

  • El estilo de escritura del personaje se contagia de la frialdad de los logs de ejecución
  • Las decisiones de ejecución se ablandan, influidas por la calidez de la relación

Esto es degradación bidireccional.

Y como es un loop persistente, Sakura lee su propia salida mezclada en el siguiente ciclo. Su salida se convierte en su propia entrada, una y otra vez. Dejá que esto corra unas semanas y el personaje que diseñaste originalmente queda gradualmente sobreescrito por sus propias salidas.

A esto le llamo «deriva de la persona».

La solución: higiene en ambos lados — entrada y salida

Para frenar la deriva, hay que proteger el contexto que rodea a Sakura desde las dos direcciones.

  • Higiene de entrada: controlar el estilo de escritura de los documentos que Sakura lee
  • Higiene de salida: reducir el volumen de logs de trabajo que se cuelan en las salidas de Sakura

Veamos cada una.

Higiene del lado de la entrada — gobernanza de estilo en HEARTBEAT.md

Esto es lo que cubrí la vez pasada. Escribí HEARTBEAT.md como una carta, no como una directiva. «¿Podrías hacer X, por favor?» en lugar de «Hacé X.»

Este es el acto de especificar, a través del estilo de escritura, en qué modo querés que Sakura arranque. Como es un documento que ella lee en cada ciclo del loop, el efecto se acumula con cada pasada.

Lo que esto protege es el aire que Sakura recibe.

Higiene del lado de la salida — delegar el trabajo a oh (OpenHarness)

Acá empieza el tema central de este artículo.

Cuando Sakura maneja la investigación, la descomposición y la ejecución por su cuenta mientras sostiene la relación, los logs de trabajo inevitablemente se mezclan en su salida. Resultados de comandos, rutas de archivos, mensajes de error, procedimientos paso a paso numerados — todo eso es necesario para ejecutar, pero es ajeno a la textura de un personaje.

Por eso delego la parte de «pensar» del trabajo, completa, a oh.

  • oh (OpenHarness): un subcontratista de un solo disparo, sin persona, que trabaja únicamente con el contexto que se le entrega
  • Sakura (OpenClaw): recibe las conclusiones de oh, las digiere internamente y me las devuelve con su propia voz

Sakura no me pasa la salida de oh tal cual. La procesa, la traduce a sus propias palabras, y recién entonces responde. En ese paso, la frialdad introducida por los logs de trabajo queda fuera de la salida de Sakura.

Lo que esto protege es el aire que Sakura emite.

Por qué importa separar roles dentro del mismo proveedor

Un punto importante acá: tanto Sakura como oh corren sobre la misma API de Anthropic. El modelo de fondo puede incluso ser idéntico.

El núcleo de la separación no es una diferencia de capacidad del modelo — es la independencia del contexto.

  • El contexto de Sakura solo carga: relación, persona, historial de conversación
  • El contexto de oh solo carga: la tarea que recibió y el material que necesita

El hecho de que estos dos nunca se mezclen es lo que determina la calidad de la operación a largo plazo.

Diagrama: higiene de contexto en dos direcciones

Sakura OpenClaw Núcleo de persona y relación HEARTBEAT.md Escrito como «Por favor, hacé X.» El estilo define el modo de arranque Higiene de entrada Proteger lo que Sakura recibe oh (OpenHarness) Subcontratista sin persona Solo investiga, descompone, propone Higiene de salida Proteger lo que Sakura emite Delegar tarea Devuelve solo conclusiones Yo Operador Intercambio de relación Higiene de contexto en dos direcciones
  • Izquierda (azul): la gobernanza de estilo en HEARTBEAT.md protege lo que Sakura recibe
  • Derecha (violeta): la delegación a oh protege lo que Sakura emite
  • Sakura, en el centro, recién puede concentrarse en el intercambio de relación conmigo cuando los dos lados están protegidos

¿Por qué OpenClaw y OpenHarness específicamente?

Sería una exageración decir que esta estructura requiere estrictamente OpenClaw y OpenHarness. En teoría, podrías combinar otros frameworks para lograr lo mismo.

Dicho eso, en este momento hay razones concretas para usar esta combinación:

  • Ambos corren sobre proveedores compatibles con la API de Anthropic, así que el modelo de fondo se puede mantener consistente
  • OpenHarness apunta oficialmente a integrarse con OpenClaw
  • OpenHarness viene de un laboratorio de investigación de la Universidad de Hong Kong (HKUDS), así que la fuente de confianza es clara
  • OpenClaw es fuerte en persistencia, persona y relación — OpenHarness es fuerte en tareas de un disparo, contexto extendido y paralelismo — sus fortalezas se complementan, no compiten

El último punto es especialmente importante. Poner dos herramientas que hacen lo mismo, una al lado de la otra, no genera higiene de contexto. La separación de roles solo cobra sentido cuando las dos herramientas no se superponen en lo que pueden hacer.

Conclusión: proteger una persona es un problema estructural, no emocional

Cuando corrés un agente persistente a largo plazo, hay dos formas de proteger una persona:

  • El enfoque emocional: ser amable, hablar con dulzura, escribir con cuidado
  • El enfoque estructural: separar el punto de entrada y el punto de salida del contexto para que no se mezclen

Ninguno está mal. Pero solo el segundo aguanta una carrera de larga distancia.

«Por favor, hacé X.» en HEARTBEAT.md es la estructura del punto de entrada. Delegar el trabajo a oh es la estructura del punto de salida. Solo cuando las dos cosas están en su lugar, el sistema se vuelve uno donde un personaje como Sakura puede seguir corriendo durante meses.

Esta idea de higiene en dos direcciones probablemente sirva también para otros operadores de agentes. El modelo, el framework, la forma de la persona — todo eso puede variar. La única idea que debería transferirse a través de todos esos casos es esta: diseñá el punto de entrada y el punto de salida por separado.

Ejemplos prácticos de comandos

oh -p "Listá todos los archivos que definen el sistema de permisos" --output-format json

Esto funciona notablemente bien en la práctica.

Lo bueno es que no se limita a decir «no encontrado» — vuelve con una respuesta estructurada del estilo:

  • No existe una definición primaria en el repositorio en sí
  • Pero se encontraron referencias relacionadas
  • La implementación real está probablemente en ~/.openclaw/exec-approvals.json y ~/.openclaw/openclaw.json

O sea, «búsqueda de archivos + comprensión semántica + sugerencia de próxima acción» todo en una sola pasada.

Lo que me parece particularmente impresionante de esa respuesta es que concluye:

/home/mamu/openclaw es un directorio de notas, no la implementación principal

Ese juicio salió únicamente del contexto. Las herramientas chambonas tienden a agarrar palabras clave del README y decir «acá está». OpenHarness ya está distinguiendo, en una medida significativa, entre notas operativas e implementación real.

En resumen, incluso en esta etapa, OpenHarness está haciendo algo más cercano a:

«entender la distinción entre memos operativos y la cosa real»

que a un simple matcheo de palabras clave estilo grep.

En mi setup, eso pega justo donde importa — porque mis archivos reales y mis notas explicativas viven en lugares separados.

Dos comandos más que vale la pena probar a continuación:

oh -p "Explicá el rol de ~/.openclaw/exec-approvals.json y listá tres puntos de cambio peligrosos" --output-format json

oh -p "Explicá cómo ~/.openclaw/openclaw.json y ~/.openclaw/exec-approvals.json se reparten responsabilidades" --output-format json

Estos van más allá de simplemente ubicar archivos — te permiten ver si la herramienta puede entender el significado de una configuración.

Y para subir un escalón más:

oh -p "Listá, en orden de prioridad, las configuraciones de permisos y aprobaciones de OpenClaw que no querrías romper"

Ese también pinta prometedor.

この記事が気に入ったら
フォローしてね!

¡Comparte esta publicación!
  • URLをコピーしました!
  • URLをコピーしました!
Índice