Ir al contenido

Las cuatro capas de un sistema de agentes son loop, graph, harness y meta-harness. Cuando un agente consume tokens, declara la tarea completa y luego falla las pruebas, generalmente es un problema de arquitectura, no de prompting. El loop verifica el trabajo con evidencia externa. El graph decide hacia dónde va la ejecución a continuación. El harness es el entorno operativo del modelo: herramientas, permisos, memoria, contexto, registro. El meta-harness gobierna muchos harnesses para que el contexto y la política puedan moverse entre agentes. Mercury Core está construido como el harness y el meta-harness. Este loop no es Mercury Loop, el servicio gestionado.

Arquitectura de agentes, bucles de verificación, grafos de flujo de trabajo, harnesses de agentes, gobernanza de meta-harness, sistemas operativos humano-agente, límites de ingeniería de prompts, Mercury Core, Booster Packs, memoria OpenClaw

Mercury Technology Solutions, Mercury Core, Mercury Flux, Mercury Loop, OpenClaw, Booster Pack, Unified Bus, infraestructura Agent-native

[ SYS: MERCURY_CORE // FIELD_NOTES ]

Notas de campo sobre sistemas agentic

Las Cuatro Capas de un
Sistema de Agentes

Un agente consume tokens, declara la tarea completa y luego falla las pruebas. Eso es generalmente un problema de arquitectura, no de prompting. Aquí está la pila, y cómo encontrar qué capa falló.

Cuatro capas de tiempo de ejecución. Construye desde el loop hacia arriba.

En resumen

Cuáles son las cuatro capas de un sistema de agentes

  • Los agentes de AI suelen fallar por la arquitectura, no por el prompting: un mejor prompt no puede crear una herramienta, puerta, ruta o política faltante.
  • Las cuatro capas de tiempo de ejecución son loop (verificar trabajo), graph (enrutar trabajo), harness (exponer capacidad) y meta-harness (gobernar muchos harnesses).
  • Un loop confiable se detiene ante evidencia externa: una prueba superada, una compilación exitosa, una salida validada, nunca en la autoevaluación del modelo.
  • Mercury Core es el sistema operativo construido como el harness y el meta-harness: una memoria, una interfaz, una capa de política.
  • El loop en esta página es un patrón de tiempo de ejecución. Mercury Loop es un producto diferente: un servicio administrado que evita que el SO se desvíe.
La pila

Cuatro capas de un vistazo

Las cuatro capas de un sistema de agentes: el trabajo, el fallo y la solución antes de que reescribas el prompt.
CapaTrabajoFalloSolución primero
LoopVerificar el trabajo hasta que la evidencia diga pararEl agente “completa” sin una prueba, compilación o puerta de validaciónAñadir una condición de parada medible
GraphDecidir a dónde va la ejecución a continuaciónRuta incorrecta, sin respaldo, traspasos improvisadosHacer explícos los ramales, reintentos y especialistas
HarnessExponer herramientas, memoria, permisos, contexto, registroEl modelo entiende la tarea pero no puede acceder a lo que necesitaExponer la capacidad faltante: un Booster Pack en Mercury Core
Meta-harnessGobernar muchos harnesses; mover el contexto bajo una única políticaClaude Code, Codex y agentes internos como silos descoordinadosPolítica compartida, aislamiento y contexto portátil: el sustrato Core
Capa 01 — Loop

¿Qué es un agent loop?

Un agent loop es la unidad más pequeña de agencia: actuar, verificar el resultado y luego detenerse o reintentar.

Un agente confiable nunca se detiene porque el modelo cree que el trabajo se ve correcto. Se detiene ante evidencia externa: una prueba superada, una compilación verde, una salida validada.

Act → check → (fix) → done

Observe cómo el agent intenta la tarea dos veces. El primer intento parece terminado, pero la verificación discrepa. Solo el segundo intento pasa la puerta.

Act
Check
Reintentar
Terminado

Loop inactivo. Ejecútalo para ver una verificación fallida y luego una puerta que pasa.

La regla

Condición de parada

Detenerse en condiciones medibles: las pruebas pasan, la compilación tiene éxito, la salida es válida, nunca en la autoevaluación del modelo.

Modo de fallo

Sin verificación, un agent declara con confianza el éxito mientras la tarea sigue incompleta.

Capa 02 — Graph

¿Qué es un agent graph?

Un agent graph decide a dónde va la ejecución a continuación: ramas, reintentos, traspasos a especialistas, rutas de fallback y estado compartido.

Un loop decide si la ejecución continúa. Un graph decide a dónde va. Una vez que un flujo de trabajo tiene múltiples rutas, el graph las hace explícitas, inspeccionables y controlables.

Tarea nueva
Ruta estándar
Agente especialista
Reintentar / fallback
Degradar
Entregado
Ruta por clase de tarea
Traspaso
Después de N fallos

Graph inactivo. Enruta una tarea para observar cómo una ruta estándar falla y pasa a una especialista.

Capa 03 — Harness

¿Qué es un agent harness?

Un agent harness es el entorno operativo del modelo: herramientas, APIs, archivos, memoria, permisos, contexto y logging.

El modelo proporciona el razonamiento; el harness determina lo que ese razonamiento puede hacer realmente. La capacidad del modelo y la capacidad del agente no son lo mismo.

Tools
Lo que el agente puede tocar e invocar
Permissions
Lo que se le permite hacer
Memory
Lo que recuerda entre ejecuciones
Context
Lo que puede ver ahora mismo
Logging
Lo que se puede auditar después
Missing tool
Ningún prompt arregla esto. El agente se detiene aquí.
La prueba del harness

El modelo puede entender exactamente cómo resolver una tarea. Pero si la herramienta, fuente de datos o permiso requerido no se exponen a través del harness, el agente aún no puede completarla.

Cinco capacidades hacen que el modelo sea operativo. Una brecha hace que todo falle, sin importar lo bueno que sea el prompt.

Capa 04 — Meta-harness

¿Qué es un meta-harness?

Un meta-harness es la capa común por encima de múltiples harnesses de agentes: orquestación, gobernanza, aislamiento, política compartida y contexto portable.

Los equipos reales ejecutan Claude Code, Codex, agentes internos y especialistas en dominio lado a lado, cada uno con sus propias herramientas, sesiones, políticas y entorno de ejecución. Sin un meta-harness, los humanos se convierten en la capa de copiar y pegar entre jardines vallados.

Meta-harness · portabilidad compartida de políticas / gobernanza / contexto
Agent A
Code harness
Agent B
Research harness
Agent C
Domain specialist

El punto móvil es el contexto: un resultado validado o un estado compartido que cruza de un harness a otro bajo una capa de política, en lugar de ser copiado y pegado entre jardines vallados.

El diagnóstico de una línea

Un prompt mejor no puede compensar por una capacidad faltante.

— heurística de triaje, arquitectura de agentes

Pero hacer prompts sigue siendo parte de la solución

La heurística se trata de ordenar, no de desestimar. La ingeniería de prompts es real y valiosa: moldea cuán bien el modelo utiliza lo que expone el harness. Simplemente no puede crear lo que el harness nunca expuso.

La secuencia correcta: arreglar la capa primero (añadir la herramienta, la puerta, la ruta, la política), luego ajustar el prompt para usar esa capacidad bien. Hacer prompts sobre un stack roto es barniz sobre una cimentación agrietada.

Uso en campo

Cuatro preguntas antes de reescribir el prompt

01

Fallo del Loop

El agente “completa” sin evidencia
¿Hay alguna prueba, construcción o validación que realmente controle la finalización?
02

Fallo del Grafo

Ruta incorrecta, sin respaldo, callejón sin salida
¿Son las ramas, los reintentos y los traspasos explícitos, o improvisados en cada ejecución?
03

Fallo del Harness

El agente carece de herramienta, datos o permiso
¿El entorno expone lo que la tarea realmente requiere?
04

Fallo del Meta-harness

Los agentes no pueden compartir política ni contexto
¿Hay gobernanza en toda su flota de agentes, o N silos no coordinados?
Por qué esto está bajo Mercury Core

El diagnóstico. Luego el sustrato.

Estas cuatro capas de tiempo de ejecución son la razón por la que un prompt mejor todavía falla cuando falta el harness. Mercury Core es el sistema operativo construido como ese harness y el meta-harness encima: una memoria, una interfaz, una capa de política.

Las cinco capas de memoria en Core son cómo el SO almacena la verdad. OpenClaw es ese tejido.Las cuatro capas de esta página son cómo se permite que funcione el trabajo.

A Booster Pack es cómo Core expone una herramienta, una vista y un esquema de memoria juntos: el arnés, conectado.

El loop de esta página es la puerta de tiempo de ejecución: actuar, verificar, detenerse ante evidencia. Mercury Loop el producto es algo diferente: un servicio gestionado que evita que el sistema operativo se desvíe del negocio.

Cuando la puerta es un pase de modelo, Mercury Flux enruta el modelo capaz más económico y se detiene en pruebas antes de que se implemente cualquier cosa.

Siguiente paso

Instale las capas. No pule el prompt.

Si la falla se debe a la falta de herramientas, memoria compartida o política de la flota, la siguiente página es el sistema operativo, no otro paquete de prompts.

Preguntas Frecuentes

FAQ de arquitectura de agentes

¿Cuáles son las cuatro capas de un sistema de agentes?

Loop, graph, harness y meta-harness. El loop verifica el trabajo contra evidencia externa. El graph decide a dónde va la ejecución a continuación. El harness es el entorno operativo del modelo: herramientas, permisos, memoria, contexto, registro. El meta-harness gobierna muchos harnesses para que el contexto y la política puedan moverse entre agentes en lugar de copiarse y pegarse.

¿Por qué fallan los agentes de IA incluso con un buen prompt?

Porque el prompting no puede crear lo que el harness nunca expuso. Si falta la condición de parada, la ruta, la herramienta o la política compartida, el modelo aún puede razonar correctamente y la ejecución sigue fallando. Diagnostique la capa primero, luego ajuste el prompt.

¿Es un 'agent loop' lo mismo que Mercury Loop?

No. Un 'agent loop' es un patrón de tiempo de ejecución: actuar, verificar, detenerse ante evidencia. Mercury Loop es un servicio gestionado que despliega agentes Entry, Analyst e Implementer para encontrar y cerrar la deriva de infraestructura. Misma palabra, producto diferente.

¿Cómo se relaciona esto con Mercury Core y OpenClaw?

OpenClaw es la memoria jerárquica de cinco capas de Mercury Core: cómo almacena la verdad el sistema operativo. Estas cuatro capas de tiempo de ejecución son cómo se permite que se ejecute el trabajo. Core se construye como el 'harness' y el meta-harness: humanos y agentes comparten memoria, interfaz y política. Un Booster Pack empaqueta una herramienta, un panel de control y un esquema de memoria en ese 'harness'.

¿Por qué un prompt mejor no puede solucionar una herramienta faltante?

El 'prompting' moldea qué tan bien utiliza el modelo lo que expone el 'harness'. No puede crear una herramienta, permiso, fuente de datos o política que el entorno nunca haya ofrecido. Arregla la capa primero, luego ajusta el 'prompt'.

¿Qué es un meta-harness?

La capa común por encima de múltiples entornos de agentes. Los equipos ya ejecutan Claude Code, Codex, agentes internos y especialistas lado a lado. Sin un meta-harness, cada uno es un jardín amurallado. Con uno, comparten política, aislamiento y contexto portátil. Esa es la tesis de Mercury Core: dejar de usar a los humanos como capa de integración.

¿Cómo se diagnostica qué capa de agente falló?

Hazte cuatro preguntas antes de reescribir el 'prompt'. Loop: ¿hay una prueba que controle la finalización? Graph: ¿son explícitos los ramales y los traspasos? Harness: ¿expone el entorno la herramienta, el dato o el permiso que necesita la tarea? Meta-harness: ¿pueden los agentes compartir política y contexto, o son N silos no coordinados?
Definiciones

Términos de arquitectura de agentes utilizados en esta página

Agent loop
Actuar, verificar, detenerse ante evidencia externa. No es Mercury Loop, el servicio gestionado.
Agent graph
Rutas explícitas, reintentos, traspasos especializados, fallbacks y estado compartido.
Agent harness
El entorno operativo del modelo: herramientas, permisos, memoria, contexto, registro.
Meta-harness
Gobernanza a través de muchos harnesses: política compartida y contexto portátil. El trabajo de Mercury Core.

Published 2 September 2026. Concept distilled from public discussion on agent architecture (Rishi, @RishiUvaach). Frame and implementation: Mercury Technology Solutions.