Básico
Spot
Opera con criptomonedas libremente
Margen
Multiplica tus beneficios con el apalancamiento
Convertir e Inversión automática
0 Fees
Opera cualquier volumen sin tarifas ni deslizamiento
ETF
Obtén exposición a posiciones apalancadas de forma sencilla
Trading premercado
Opera nuevos tokens antes de su listado
Contrato
Accede a cientos de contratos perpetuos
CFD
Oro
Plataforma global de activos tradicionales
Opciones
Hot
Opera con opciones estándar al estilo europeo
Cuenta unificada
Maximiza la eficacia de tu capital
Trading de prueba
Introducción al trading de futuros
Prepárate para operar con futuros
Eventos de futuros
Únete a eventos para ganar recompensas
Trading de prueba
Usa fondos virtuales para probar el trading sin asumir riesgos
Lanzamiento
CandyDrop
Acumula golosinas para ganar airdrops
Launchpool
Staking rápido, ¡gana nuevos tokens con potencial!
HODLer Airdrop
Holdea GT y consigue airdrops enormes gratis
IPO Access
Accede al acceso completo a las OPV de acciones globales
Puntos Alpha
Opera activos on-chain y recibe airdrops
Puntos de futuros
Gana puntos de futuros y reclama recompensas de airdrop
Inversión
Simple Earn
Genera intereses con los tokens inactivos
Inversión automática
Invierte automáticamente de forma regular
Inversión dual
Aprovecha la volatilidad del mercado
Staking flexible
Gana recompensas con el staking flexible
Préstamo de criptomonedas
0 Fees
Usa tu cripto como garantía y pide otra en préstamo
Centro de préstamos
Centro de préstamos integral
Promociones
Centro de actividades
Únete a actividades y gana recompensas
Referido
20 USDT
Invita amigos y gana por tus referidos
Programa de afiliados
Gana recompensas de comisión exclusivas
Gate Booster
Aumenta tu influencia y gana airdrops
Anuncio
Novedades de plataforma en tiempo real
Gate Blog
Artículos del sector de las criptomonedas
Servicios VIP
Grandes descuentos en tarifas
Gestión de activos
Solución integral para la gestión de activos
Institucional
Soluciones de activos digitales: empresas
Desarrolladores (API)
Conecta con el ecosistema de aplicaciones Gate
Transferencia bancaria OTC
Deposita y retira fiat
Programa de bróker
Reembolsos generosos mediante API
AI
Gate AI
Tu compañero de IA conversacional para todo
Gate AI Bot
Usa Gate AI directamente en tu aplicación social
GateClaw
Gate Blue Lobster, listo para usar
Gate for AI Agent
Infraestructura de IA, Gate MCP, Skills y CLI
Gate Skills Hub
+10 000 habilidades
De la oficina al trading, una biblioteca de habilidades todo en uno para sacar el máximo partido a la IA
GateRouter
Elige inteligentemente entre más de 40 modelos de IA, con 0% de costos adicionales
¿por qué debes aprender Ingeniería de Harness? 5 productos, 3 escuelas, 5 principios universales en análisis completo
Sistema desglosado Harness Engineering 5 productos, 3 escuelas (OpenAI / Anthropic / ThoughtWorks), 5 principios universales, y por qué la "decadencia de Harness" te obliga a cortar a la mitad el diseño cada 6 meses. Este artículo proviene del artículo escrito por @sairahul1 en X, organizado y compilado por 動區.
(Resumen previo: Introducción a Harness Engineering (Ingeniería de AI): La última norma de programación de OpenAI, enseñándote a alcanzar fácilmente Lv.1)
(Información adicional: El CEO de YC comparte secretos de AI: El futuro pertenece a quienes construyen sistemas de interés compuesto de información)
Índice del artículo
Toggle
En febrero de 2026, un pequeño equipo de OpenAI produjo 1 millón de líneas de código de producción.
No escribieron ni una línea a mano.
Lo escribieron agentes de AI.
El sistema diseñado por humanos, que hace que los agentes sean confiables.
Este sistema ahora tiene un nombre: Harness Engineering.
En semanas, Anthropic publicó 3 artículos relacionados. ThoughtWorks lo organizó en un marco. Philipp Schmid de Hugging Face lo llama directamente "la disciplina más importante de 2026".
En 90 días, una nueva disciplina de ingeniería se formó. Y fuera del equipo de infraestructura de AI, casi nadie lo entendía.
Este artículo busca explicarlo claramente. Sin palabras vacías, sin términos académicos, solo modelos mentales que realmente necesitas para usar.
1. Definición de Harness
La definición más simple de ThoughtWorks:
Harness es todo lo que está fuera del modelo.
Quitar harness → un modelo de lenguaje que adivina en tu base de código sin control.
Agregar el harness correcto → un sistema capaz de generar código de producción.
Este nombre viene del arnés. Harness son riendas, silla de montar, bocado—dirigiendo un animal fuerte pero impredecible en una dirección útil.
No estás haciendo más inteligente al animal, estás diseñando un equipo que canalice su fuerza.
2. Analogía con OS
La mejor analogía técnica de Philipp Schmid es: Imagínalo como una computadora.
| Rol | | --- | | Corresponde a | | --- | --- | | Modelo | CPU (potencia de cálculo básica) | | Ventana de contexto | RAM (memoria de trabajo limitada y volátil) | | Harness | Sistema operativo (gestiona qué ve la CPU y cuándo lo ve) | | Agente | Aplicación que corre encima |
Tu modelo es muy potente. Pero sin un sistema operativo que gestione memoria, programación de tareas, reglas de ejecución—es solo un chip de silicio.
La mayoría corre aplicaciones sin un "sistema operativo". Por eso, sus agentes fallan en producción.
3. ¿Qué cambió en 2026?
LangChain usó el mismo modelo, corriendo en Terminal Bench 2.0 dos veces:
| Harness | | --- | Puntuación | | --- | --- | | Harness antiguo | 52.8% | | Nuevo harness | 66.5% |
El mismo modelo. Diferente harness. Una diferencia de 13.7 puntos porcentuales.
Vercel hizo lo contrario—redujo las herramientas del agente en un 80%. ¿Resultado? Mejor, no peor.
La verdad incómoda de 2026:
Si 2025 fue el año en que los agentes de AI demostraron que podían programar, 2026 es el año en que se descubre que el "entorno" es más importante que el "modelo".
4. Archivos AGENT.md / CLAUDE.md
Los productos más universales de harness.
Archivos markdown dispersos en la base de código. Cada sesión del agente lee al inicio—como un documento de onboarding para un nuevo ingeniero.
¿Qué contienen?
OpenAI llama a esto AGENT.md. Anthropic lo llama CLAUDE.md. Cursor usa .cursorrules.
Diferentes nombres, mismo principio. Una copia por módulo principal. Se actualiza con el avance del proyecto.
Sin esto: el agente en cada sesión es ciego. Con esto: el agente llega con información y empieza a trabajar.
5. Listas de características JSON (seguimiento de progreso)
Cuando un agente cruza varias sesiones para construir toda una app, cada vez que inicia su ventana de contexto está vacía. ¿Cómo sabe qué ya está hecho?
Un archivo JSON.
Cada entrada describe:
La sesión del agente lo lee al inicio—elige la de mayor prioridad fallida → implementa → marca como pass → hace commit → repite.
¿Por qué JSON y no Markdown?
Anthropic descubrió: el agente tiene menos probabilidad de sobrescribir JSON accidentalmente que Markdown.
Son detalles pequeños, pero en escenarios de 6 horas de autonomía, son cruciales.
6. Rutina de inicialización de sesión
Cada sesión se inicia de la misma forma. Siempre.
El proceso de 7 pasos de Anthropic:
Sin esto: los primeros 20 minutos el agente solo intenta entender el estado actual, repitiendo tareas. Con esto: llega con información y va directo a trabajar.
7. Contratos de Sprint
Antes de escribir una línea de código—dos agentes negocian.
Agente Generador propone:
Agente Evaluador revisa:
Ambos aprueban, entonces se inicia la implementación.
Es una revisión de diseño. Pero ambos son IA.
¿Por qué es importante?
En una misma ronda, planificar y ejecutar con un solo agente produce resultados poco confiables. La etapa de "planificación"—aunque sea con IA—mejora mucho la calidad del resultado.
8. Plantillas de tareas estructuradas
Antes de programar, el harness analiza realmente la base de código.
Produce un mapa de impacto fundamentado:
Luego comienza la implementación.
Suena obvio, pero la mayoría de los equipos lo omiten.
El agente adivina la estructura de archivos, inventa API inexistentes, crea cosas que no encajan con la código base.
Primero tener un contexto fundamentado, luego ejecutar → mejor calidad de salida.
9. La escuela de OpenAI: Prioridad al entorno
El equipo de Codex de OpenAI tiene un problema absurdo:
En esa escala, no puedes revisar línea por línea. Por eso, no lo hacen.
En su lugar—diseñan el entorno tan exhaustivamente que el agente desde el principio produce salidas "revisables".
Sus métodos
Filosofía: Diseña el entorno. Luego deja que el agente corra.
Evidencias
Aplicación Sora en Android. 4 ingenieros. 28 días. #1 en Play Store. 99.9% sin fallos.
Codex procesa internamente el 70% de los PRs semanalmente.
10. La escuela de Anthropic: Separar "hacer" y "revisar"
Anthropic enfrenta otro problema:
Cuando piden al agente evaluar su propia salida, se alaba a sí mismo con confianza—aunque para observadores humanos, la calidad es claramente mediocre.
Autoevaluación no funciona. El agente es tanto estudiante como profesor, y se da calificación A+.
Su solución: 3 agentes especializados
| Agente | | --- | | Trabajo | | --- | --- | | Planner | Transforma un prompt de 2 frases en especificaciones completas del producto | | Generator | Implementa en un sprint a la vez | | Evaluator | Prueba automatizada en navegador, como un usuario real |
Percepción: hacer que un "evaluador independiente" sea exigente, es mucho más fácil que hacer que un generador sea exigente con su propio trabajo.
Resultados (Pruebas A/B)
| Configuración | | --- | | Costo | | Tiempo | | Resultado | | --- | --- | --- | --- | | Solo agente (sin harness) | $9 | 20 min | App defectuosa | | Harness completo | $200 | 6 horas | Software funcional + UI refinada |
11. La escuela de ThoughtWorks: Marco 2×2
ThoughtWorks aborda desde diferentes ángulos—no hacen productos, sino que observan cómo más de 50 equipos fallan en los mismos aspectos.
Su percepción: clasificar cada control de harness en dos ejes
Eje 1: ¿Cuándo funciona?
Eje 2: ¿Cómo funciona?
Matriz 2×2
| | | --- | | Feedforward (directrices) | | Feedback (sensores) | | --- | --- | --- | | Computacional | sistema de tipos, linter, reglas arquitectónicas | suite de tests, cobertura, tests de mutación | | Inferencial | documentos de especificaciones, restricciones | revisores de código con LLM, verificadores de comportamiento |
No usar solo feedforward o solo feedback. Se necesitan ambos.
12. Principio 1: Contexto supera instrucciones
Diferentes equipos, mismo hallazgo:
Conectar con archivos reales → adaptar el código a la base. Partir de descripciones vagas → caminos ilusorios y API inventadas.
Antes de que el agente escriba, asegúrate de que sepa dónde está.
13. Principio 2: La planificación y ejecución deben separarse
Cada enfoque descubre que: planificar y ejecutar en la misma ronda produce resultados poco confiables.
La planificación no necesariamente debe ser humana, pero debe ser una etapa separada, y su resultado debe ser revisado antes de comenzar.
14. Principio 3: La retroalimentación no puede comprometerse
Tres enfoques de las escuelas en este principio:
| Escuela | | --- | | Fuente de feedback | | --- | --- | | OpenAI | Pruebas automatizadas + CI | | Anthropic | Otro LLM | | ThoughtWorks | Ambos combinados |
Comparten la idea: quién provee feedback puede variar. Pero no hay debate: el feedback es necesario.
15. Principio 4: Solo una cosa a la vez
Intentar hacer muchas cosas con un solo agente:
La rutina de Anthropic: leer progreso → escoger UNA feature → implementar → hacer commit → repetir.
El "principio de progresión gradual" es la clave del éxito de cualquier harness.
16. Principio 5: La base de código es el documento
Nadie mantiene una base de conocimientos aparte para el agente. El repositorio es la única verdad.
Si una regla, restricción o decisión arquitectónica no está en la base de código → el agente no la sabrá.
Implicaciones prácticas
17. La decadencia de Harness (Harness Decay) es real
Cuando Anthropic actualizó de Opus 4.5 a 4.6—la descomposición del sprint (que antes era imprescindible) se volvió un peso muerto.
El avance en la planificación del modelo hizo que esa parte sobrara.
Las componentes de harness que en marzo aún soportaban, en abril se convirtieron en sobrecarga.
Luego, con Opus 4.7—el modelo empezó a verificar sus propias salidas, y la función del evaluador se redujo aún más.
Esto es la decadencia de Harness
| Versión del modelo | | --- | Estado de harness | | --- | --- | | Opus 4.5 | Desglose de sprint + evaluación en cada sprint | | Opus 4.6 | Sin desglose de sprint + evaluación única (ahorra 38% en costos) | | Opus 4.7 | El modelo verifica sus salidas → rol del evaluador se reduce aún más |
Construir para eliminar (Build to Delete)
Philipp Schmid recomienda: "Construir para eliminar."
Al diseñar cada componente de harness, pensar en que pueda ser removido.
Probar periódicamente cada componente—apagarlo y verificar si la calidad del output se mantiene. Si no hay diferencia → eliminarlo.
| Equipo | | --- | Reestructuración en 6 meses | | --- | --- | | Manus | Reestructura harness 5 veces | | LangChain | Reorganiza 3 veces en un año | | Vercel | Elimina el 80% de herramientas → mejor rendimiento |
No son signos de mal diseño. Es la consecuencia natural de "construir sobre modelos en rápida evolución".
19. La realidad de los costos
Datos honestos del test A/B de Anthropic:
| Configuración | | --- | | Costo | | Tiempo | | Resultado | | --- | --- | --- | --- | | Solo agente (sin harness) | $9 | 20 min | UI se rompe, núcleo dañado | | Harness completo (Opus 4.5) | $200 | 6 horas | Software funcional + UI refinada, física correcta |
22 veces más caro—para un producto que realmente funciona, no solo una demo con pantallazos.
¿Vale la pena? Depende del costo que te represente una versión defectuosa en tu equipo.
Pero aquí no se habla de lo que no se dice
La combinación harness + modelo es evolutiva.
Un harness de $200, al subir un modelo, cuesta solo $124.
| Línea de tendencia | | --- | | Mejor modelo = harness más simple = menor costo por ejecución = resultados más rápidos |
Resumen completo
Qué es harness
5 productos de harness
3 escuelas
5 principios universales
La paradoja
Los ingenieros que ganan en 2026 no escriben el mejor código. Son quienes diseñan las mejores restricciones—y están dispuestos a desechar esas restricciones cuando dejan de ser rentables.