Árbol de conocimiento
Seguridad ofensiva
Shells
Transferencia de archivos
Aplicaciones web
Harness de agente
Un modelo por sí solo no lee un repositorio, ejecuta comandos ni conoce las reglas de un proyecto. El harness es el programa que coloca esas piezas alrededor del modelo y mantiene el bucle de agente.
El modelo propone decisiones. El harness prepara el contexto, expone tools, ejecuta las acciones en un runtime y devuelve los resultados. Codex, Claude Code y OpenCode son ejemplos de harnesses con decisiones diferentes sobre esas piezas.
Instrucciones del proyecto
Los ficheros de instrucciones permiten que el agente conozca reglas que no están en la petición inmediata del usuario. Codex utiliza AGENTS.md, Claude Code utiliza CLAUDE.md y OpenCode soporta sus propias reglas y mecanismos de compatibilidad.
El nombre del fichero es una convención del harness. Lo importante es que el programa lo descubre y acaba introduciendo sus instrucciones en el contexto del modelo. Por eso deben ser concretas y enfocadas: un manual enorme se vuelve input repetido en muchas inferencias.
Skills y tools
Una skill explica cómo abordar una clase de tarea. Puede incluir instrucciones, referencias y scripts. Por ejemplo, una skill para revisar un documento puede indicar qué comprobar y proporcionar un script que valide de forma determinista la estructura del fichero.
Una tool es una capacidad que el modelo puede pedir que se ejecute: leer un fichero, lanzar un comando o consultar una API. El harness presenta la definición al modelo, recibe la tool call y ejecuta la operación. Este recorrido se desarrolla en Uso de herramientas.
Runtime
Las acciones ocurren en algún entorno. Puede ser una shell local, una VM, un sandbox o un workspace cloud. El runtime determina qué ficheros, binarios, red y servicios están disponibles.
El mismo modelo puede resolver una tarea en un harness y fallar en otro porque cambian las instrucciones, las tools o el entorno. Si un test runner no está instalado o el repositorio no está montado, el modelo no puede compensarlo con una respuesta mejor.
Comprobaciones deterministas
No todo debe resolverlo el LLM. Si hay que contar findings, validar JSON o ejecutar tests, un script puede hacer la parte mecánica y devolver un resultado preciso. El modelo queda para interpretar ese resultado y decidir qué hacer después.
En este repositorio, por ejemplo, las reglas editoriales guían al agente, pero npm run test:content comprueba invariantes que no deberían depender de que el modelo las recuerde. El harness permite combinar ambos tipos de trabajo dentro de la misma tarea.
Resultados y observabilidad
Para entender un run conviene poder ver las tool calls, sus resultados, los errores, el uso de tokens y las validaciones ejecutadas. No hace falta una arquitectura especial para empezar: un historial claro de comandos y resultados ya permite distinguir si falló el modelo, una tool o el entorno.
El harness también decide cuánto resultado vuelve al contexto. Puede conservar un log completo en un fichero y enviar al modelo solo las líneas relevantes, una decisión que conecta con la ingeniería de contexto.