Nota del autor: este artículo explica en 5 pasos cómo diseñar puertas de aceptación para agentes, de modo que un agente de ejecución prolongada tenga un final claro, retroalimentación fiable y costos controlables.
Cuando un agente lleva horas o incluso días ejecutándose y devuelve un resultado que parece completo, pero nadie se atreve a fusionarlo directamente, ese es un problema habitual en muchos equipos de desarrollo. Este artículo presenta el método de diseño en 5 pasos para las puertas de aceptación de agentes, que te ayuda a definir “terminado” como un estándar que la máquina puede comprobar repetidamente antes de lanzar una tarea de larga duración.
El 27 de octubre de 2026, Gregory Kurtzer, uno de los fundadores de CentOS, anunció el proyecto Ginux. Según los informes, en 11 días, apoyándose principalmente en una tarea de Codex que se ejecutaba de forma continua, dejó alrededor de 139.000 líneas de código e hizo que este kernel independiente arrancara Rocky Linux 10 y ejecutara systemd. Cuando le preguntaron cómo devolver a la senda correcta a un agente que se había desviado, su respuesta fue sencilla: poner muchas puertas de aceptación.
Esto no es otra colección de trucos de indicaciones; este artículo se centra en la estructura de ingeniería de la que realmente dependen las tareas de larga duración: objetivos, puertas de aceptación, evidencia, regresión y condiciones de parada.
Valor clave: al terminar este artículo, podrás escribir un conjunto de puertas de aceptación para agentes en tu propio proyecto y decidir qué partes se delegan a la máquina y qué decisiones deben quedar necesariamente en manos de las personas.
Aspectos clave de los puntos de control de aceptación del Agente
Los puntos de control de aceptación del Agente son un conjunto de verificaciones predefinidas y repetibles. Le indican al Agente si el resultado actual cumple con lo esperado y también muestran a las personas qué evidencia vale la pena revisar.
| Punto | Descripción | Valor |
|---|---|---|
| Criterios de aceptación definidos de antemano | Antes de lanzar una tarea larga, dejar claros el objetivo final y los objetivos por etapas | Evita que el Agente confunda un éxito parcial con la finalización completa |
| Puntos de control ejecutables | Se determinan con comandos, scripts, CI o resultados reales de ejecución | El Agente puede iterar por su cuenta sin esperar a una persona |
| Verificar el comportamiento del sistema | Prestar atención a cómo se comporta el programa cuando se ejecuta de verdad | Detectar salidas erróneas que “parecen creíbles” |
| Responsabilidades por capas entre humanos y máquina | La persona define la arquitectura y la aceptación; el Agente implementa y hace pruebas de regresión | La persona deja de ser el eslabón más lento del bucle |
| Presupuesto bajo control | Definir de antemano el número de fallos, el consumo y las condiciones de pausa | Evitar que una tarea larga siga consumiendo recursos en la dirección equivocada |
Los puntos de control de aceptación del Agente en el caso Ginux
Kurtzer no le pasó directamente al Agente la tarea de “escribir un kernel”, sino que eligió controles estrictos como si un programa del espacio de usuario de Linux puede ejecutarse o si systemd puede arrancar. systemd depende de muchos componentes del sistema y es el proceso central para arrancar y operar todo el sistema, así que es una buena prueba para comprobar si el kernel es realmente utilizable.
El proyecto funciona con dos bucles que se complementan. El bucle externo lo lidera la persona: va desde la visión, la arquitectura y las restricciones, y los puntos de control de aceptación, hasta revisar el comportamiento real y decidir si corregir o aceptar. El bucle interno lo completa el Agente: implementa, compila y ejecuta en QEMU, mide y analiza fallos, corrige y hace pruebas de regresión, una y otra vez.
Kurtzer también advierte que muchos fallos producen salidas muy creíbles, pero que en realidad violan la semántica, los requisitos de aislamiento o el comportamiento del ciclo de vida. Si faltan puntos de control, es fácil terminar con código que por fuera parece funcionar, pero cuya estructura es muy débil.
Por qué los puntos de control de aceptación del Agente deben ejecutarse automáticamente
La ingeniera de Cursor Lauren Tan también considera que la validación es la habilidad más importante al usar Agentes. Cuando habla de validación, se refiere a hacer que el Agente ejecute el código de verdad, recoja trazas de CPU o instantáneas del heap, abra el simulador de iOS y use la aplicación como lo haría una persona usuaria.
Ella ha contado públicamente que puede integrar 4000 PR al entorno de producción cada mes. Incluso si una persona revisara cada PR solo 5 minutos, en total serían unas 333 horas, así que un sistema de revisión a esa escala tiene que poder funcionar sin intervención humana. Este caso extremo genera bastante debate, pero ilustra una idea que también sirve para cualquier equipo normal: el Agente puede seguir trabajando solo si es capaz de comprobar su propia salida; cuando no puede hacerlo, lo único que le queda es entregarte el diff y detenerse.
El doble bucle del diagrama se puede trasladar directamente a proyectos cotidianos. Si quieres que modelos distintos se encarguen de la implementación y la revisión, puedes acceder a través de APIYI apiyi.com y después incorporar la invocación del modelo al bucle interno.
Guía rápida para las puertas de aceptación de Agent: método de diseño en 5 pasos
A continuación usamos una tarea habitual como ejemplo: hacer que Agent migre un servicio REST antiguo a un framework nuevo y mantenga intactos los clientes existentes. Puedes sustituir las comprobaciones del ejemplo por los procesos de compilación, pruebas y despliegue de tu propio proyecto.
Paso 1: definir el estado final a nivel de sistema para la puerta de aceptación de Agent
Primero escribe una frase observable que describa qué debería ocurrir en el sistema cuando termine la tarea. «Completar la migración del servicio» es demasiado vago; «con el mismo lote de solicitudes de replay, los códigos de estado y los campos clave de la respuesta de los servicios antiguo y nuevo coinciden» sí se puede verificar.
Un buen estado final suele provenir de una ruta de uso real. El estado final de Ginux es que Rocky Linux 10 llegue a ejecutarse en multi-user.target de systemd; el de una aplicación web puede ser que el flujo principal de usuario funcione de principio a fin; y el de una tarea de datos, que la salida coincida con el conjunto de datos de referencia.
Paso 2: Dividir el control de aceptación del Agent en cinco capas
Una sola retroalimentación de la prueba final es demasiado lenta, y cuando el Agent falla también es difícil localizar el problema. Lo recomendable es establecer los controles según el coste de ejecución, de menor a mayor, para que las comprobaciones baratas atrapen primero los errores evidentes.
| Nivel de control | Qué se verifica | Ejemplo | Acción tras el fallo |
|---|---|---|---|
| L1 Restricciones estáticas | Formato, tipos, límites de dependencias | Prohibir importaciones cruzadas entre módulos | El Agent corrige de inmediato |
| L2 Comportamiento unitario | Lógica de funciones y módulos | Pruebas unitarias del núcleo | El Agent localiza y corrige |
| L3 Contrato de integración | Interfaces, base de datos, dependencias externas | Pruebas de contrato de interfaz | El Agent compara las diferencias y revisa |
| L4 Operación del sistema | Comportamiento real del servicio completo | Arrancar el servicio y reproducir peticiones | El Agent recopila logs y datos de rendimiento |
| L5 Aceptación humana | Arquitectura, riesgos y decisiones de negocio | Revisar el paquete de evidencias y decidir si se integra | La persona aporta nuevas restricciones o detiene la tarea |
La arquitectura Dune de Lauren Tan ofrece un ejemplo extremo de L1. Reestructuró el proyecto a través de más de 600 PR y usó CI para validar el grafo de dependencias, asegurando que los directorios main y renderer de Electron no se importaran entre sí, además de desactivar useEffect y prohibir la escritura de comentarios. Es posible que estas reglas no encajen en tu base de código, pero la práctica de convertir las restricciones del equipo en comprobaciones automáticas merece la pena tomarse como referencia.
Paso 3: Convertir los puntos de control de aceptación del agente en tarjetas ejecutables
Cada punto de control debería tener una tarjeta breve, ubicada en la documentación del proyecto que el agente puede leer al iniciar. Una vez que la tarjeta está bien escrita, el agente no necesita adivinar “qué significa aprobar”, y las personas también pueden rastrear la evidencia a partir de ella.
| Campo | Requisito de llenado | Ejemplo de migración de servicio |
|---|---|---|
| Nombre del punto de control | Nombrarlo por comportamiento | Consistencia de reproducción de solicitudes |
| Entorno de ejecución | Versión y dependencias fijas | Entorno de prueba aislado con instantánea de datos fija |
| Punto de entrada de ejecución | Proporcionar un comando claro | make gate-replay (comando de ejemplo) |
| Criterio de aprobación | Usar resultados comparables | Códigos de estado y campos clave totalmente consistentes |
| Artefacto de evidencia | Guardar archivos revisables | Informe de diferencias, registros del servicio, registros de rendimiento |
| Reglas de protección | Indicar lo que no se puede modificar | Muestras de aceptación y script de validación de solo lectura |
| Estrategia de fallo | Explicar la siguiente acción | Si el mismo error no se resuelve durante 3 rondas consecutivas, pausar |
Entre ellas, las reglas de protección son las que más fácilmente se pasan por alto. El agente tiende a elegir el camino más fácil a corto plazo; si puede modificar las muestras de aceptación o relajar el script de validación, los resultados de las pruebas pierden sentido. Se recomienda colocar esta parte en un directorio protegido y revisar los cambios relacionados en CI.
Paso 4: Hacer que los puntos de control de aceptación del Agent entren en un ciclo de regresión automática
Incorpora el bucle interno en la descripción de la tarea: primero completa un cambio pequeño, ejecuta el punto de control del nivel actual, lee la evidencia de fallo, corrige y vuelve a ejecutar los puntos de control que ya pasaban antes. La regresión aquí es clave; de lo contrario, el Agent podría arreglar una cosa y romper silenciosamente otra.
Al final de cada ronda, haz que el Agent registre qué cambió, qué puntos de control ejecutó, los resultados y los problemas pendientes. En tareas largas, el contexto no deja de crecer, y este registro ayuda a que las sesiones posteriores recuperen el estado rápidamente, además de facilitar que una persona juzgue si está avanzando de verdad o dando vueltas en el mismo sitio.
Los puntos de control de aceptación también deben protegerse contra los «falsos aprobados». Estas situaciones son especialmente habituales en ejecuciones prolongadas:
| Tipo de falso aprobado | Síntoma típico | Defensa correspondiente |
|---|---|---|
| Pruebas modificadas | Se eliminan casos fallidos o se relajan los criterios | Archivos de aceptación de solo lectura, CI revisa los cambios |
| Solo se prueba el camino feliz | Las peticiones normales pasan, los escenarios anómalos se caen | Añadir inyección de fallos y muestras de borde |
| Simulaciones que sustituyen dependencias reales | Los mocks están todos en verde, el entorno de integración falla | L4 debe ejecutar el servicio real |
| Salida que parece correcta pero semanticamente errónea | Logs completos, comportamiento del ciclo de vida incorrecto | Comparar estado, secuencia temporal y efectos secundarios |
| Éxito local que oculta riesgos | Sube una métrica individual, baja la estabilidad global | Ejecutar regresión completa en cada hito |
Paso 5: Establecer puntos de decisión humana y condiciones de parada para las puertas de aceptación del agente
El trabajo humano debe concentrarse en los juicios que al agente le cuesta sustituir. Kurtzer se encarga de la arquitectura, los objetivos de compatibilidad con Linux, el modelo operativo, la interpretación de fallos y las decisiones de parada; cuando no está satisfecho con el código generado por el agente, incluso apaga el IDE, contiene el impulso de modificarlo a mano y, en su lugar, ofrece nuevas indicaciones.
Se recomienda establecer al menos tres tipos de condiciones de pausa: varios fallos en la misma puerta de aceptación, que el agente intente modificar contenido protegido y que el consumo de la tarea se acerque al presupuesto. Tras una pausa, el foco de la revisión también debería desplazarse al paquete de evidencias: primero revisar el comportamiento del sistema y los riesgos, y después decidir si vale la pena leer el diff a fondo.
Consejo para empezar rápido: elige primero un hito pequeño que puedas completar en un día y escribe solo de 3 a 5 fichas de puertas de aceptación. APIYI apiyi.com ofrece acceso por API a los modelos de las series GPT, Claude y otras mencionadas en este artículo, y es compatible con los formatos de interfaz de OpenAI y Anthropic. Las herramientas existentes normalmente solo necesitan ajustar la dirección de la interfaz y la clave API según la documentación; los modelos disponibles pueden confirmarse en la página de precios de APIYI.
Cómo las puertas de aceptación del agente cambian el costo de las tareas largas
El costo de una tarea larga no puede medirse solo por “cuántos tokens se usaron en total”. El artículo menciona que los tokens que contabiliza la página principal de Cursor incluyen al menos cuatro categorías: entrada normal, salida del modelo, escritura en caché y lectura de caché, y sus precios varían mucho. La comunidad llegó a estimar la factura con el mismo consumo de 1,5 billones de tokens, y los resultados variaban muchísimo según el algoritmo; la principal discrepancia venía del criterio de facturación y del porcentaje de caché.
| Concepto de facturación | Fuente principal en tareas largas | Método de control | Criterio de precio |
|---|---|---|---|
| Entrada normal | Descripción de la tarea, logs, fragmentos de código | Enviar solo las evidencias relacionadas con el fallo | Según los datos reales de la página de precios de APIYI |
| Salida del modelo | Código, análisis y planes de revisión | Limitar el alcance de la salida en cada ronda | Según los datos reales de la página de precios de APIYI |
| Escritura en caché | Contexto estable nuevo o modificado | Mantener estable la estructura de reglas del proyecto | Según los datos reales de la página de precios de APIYI |
| Lectura de caché | Contexto reutilizado en varias rondas | Observar los aciertos y evitar cambiar el prefijo con frecuencia | Según los datos reales de la página de precios de APIYI |
El costo total de los casos públicos sirve para entender la escala del proyecto, pero no puede convertirse directamente en un precio unitario. Se informó que el costo de las llamadas a la API de Ginux fue de unos 8000 dólares, y que el experimento de Nicholas Carlini de construir un compilador de C con 16 agentes Claude en paralelo costó alrededor de 20 000 dólares. Los modelos, el uso de caché y la estructura de las tareas detrás de estas cifras son distintos, así que tu proyecto aún necesita su propio cálculo.
Una opción más confiable es completar primero un hito completo, registrar el uso de las cuatro categorías de tokens y el número de fallos en las puertas de aceptación, y luego calcular con los datos actuales de la página de precios de APIYI https://docs.apiyi.com/models. El presupuesto así obtenido parte de la forma real de tus tareas y es más confiable que aplicar sin más el precio unitario promedio de otra persona.
Lo que la imagen anterior quiere mostrar es que las puertas de aceptación también consumen recursos, pero permiten que los fallos salgan a la luz antes. Para un equipo común, el objetivo debería ser obtener suficiente confianza con un presupuesto limitado, no exigir la validación completa más costosa para cada cambio.
Preguntas frecuentes sobre los puntos de control de aceptación de Agent
Q1: ¿Qué es un punto de control de aceptación de Agent?
Es un punto de verificación ejecutable definido de antemano para determinar si los resultados de una etapa del Agent cumplen con el estándar. Un punto de control completo incluye entorno de ejecución, punto de entrada de ejecución, criterios de aprobación, artefactos de evidencia y estrategia de fallo.
Q2: ¿Cuál es la diferencia entre un punto de control de aceptación de Agent y un CI normal?
CI es un vehículo de ejecución habitual, mientras que el punto de control de aceptación es un diseño de control de tareas más completo. Además de determinar si el código pasa las pruebas, también debe definir el comportamiento del sistema, la evidencia, el alcance de la regresión, los puntos de decisión humana y las condiciones de pausa.
Q3: ¿Cuándo es obligatorio diseñar puntos de control de aceptación de Agent?
Cuando la tarea requiere varias rondas de modificación, abarca varios módulos, tiene un tiempo de ejecución largo o los errores en la salida son difíciles de detectar a simple vista, conviene diseñarlos desde el principio. Para un script pequeño de una sola vez se puede simplificar, pero al menos hay que definir una forma de validación que se pueda ejecutar.
Q4: Con los puntos de control de aceptación de Agent, ¿sigue siendo necesaria una revisión de código manual?
Sí. Los puntos de control automáticos son adecuados para evaluar criterios conocidos; los humanos siguen siendo responsables de la selección de arquitectura, las compensaciones de riesgo y la aceptación final. Kurtzer también destaca que la experiencia sigue siendo esencial para juzgar si los resultados están completos y si un éxito parcial conlleva riesgos a nivel de sistema.
Q5: ¿Cómo conectar un modelo a través de la API para ejecutar este flujo?
1. Regístrese en APIYI (apiyi.com) y cree una clave API.
2. Consulte el centro de documentación `docs.apiyi.com`, confirme la dirección del endpoint y el método de invocación.
3. Según la herramienta, elija el formato de API de OpenAI o Anthropic y complete la configuración.
4. En `https://docs.apiyi.com/models`, confirme el modelo y el precio antes de lanzar una prueba piloto a pequeña escala.
Q6: Cuando el presupuesto es limitado, ¿cómo simplificar los puntos de control de aceptación de Agent?
Priorice los puntos de control L1 y L2 de bajo costo y ejecútelos en cada ronda; deje L3 y L4 para cuando la funcionalidad esté completa o para hitos clave. Las estadísticas de Jellyfish sobre 12 000 desarrolladores muestran que un usuario típico utiliza aproximadamente 51 millones de tokens al mes, una diferencia enorme respecto a los casos extremos; por lo tanto, la frecuencia de validación debe determinarse según el riesgo de la tarea. Para los costos del modelo, tome como referencia los datos reales de la página de precios de APIYI.
Q7: ¿Cuáles son las limitaciones de los puntos de control de aceptación de Agent?
Los puntos de control solo pueden cubrir los riesgos definidos; que todas las pruebas pasen no significa que el código sea apto para el mantenimiento a largo plazo. Ginux puede arrancar Rocky Linux 10, pero aún le queda un largo camino para alcanzar un kernel de nivel de producción: el soporte de hardware, la estabilidad de la interfaz, la revisión de seguridad y el mantenimiento de la comunidad no se pueden demostrar con una sola ejecución. Las críticas de la comunidad al modelo de PR de alta frecuencia también nos recuerdan que debemos prestar atención continua a la mantenibilidad del código.
Aspectos clave de los puntos de control de aceptación del Agent
- Define primero la meta final: describe la finalización de la tarea mediante comportamientos observables del sistema y evita objetivos difusos.
- Los puntos de control deben estar por capas: avanza progresivamente desde las restricciones estáticas hasta la ejecución real y la aceptación humana.
- Hay que conservar las evidencias: guarda en cada ejecución los registros, los informes de diferencias y los registros de rendimiento.
- Los criterios no se pueden modificar: las muestras y los scripts de aceptación deben estar protegidos para evitar que el Agent tome atajos.
- La regresión debe ser algo habitual: después de corregir un problema nuevo, vuelve a ejecutar los puntos de control relacionados que ya se habían superado.
- El humano mantiene la decisión: la arquitectura, el riesgo, la parada y la aceptación final las decide el responsable.
- Prueba primero el coste: valida a pequeña escala con APIYI apiyi.com y después calcula el presupuesto según la página de precios.
Conclusión: construir flujos de trabajo autónomos a partir de los puntos de control de aceptación del Agent
Que un Agent pueda trabajar de forma autónoma durante mucho tiempo depende de si tiene objetivos claros y una retroalimentación fiable. Al diseñar puntos de control de aceptación para un Agent, conviene tener presentes tres ideas:
- Convertir «terminado» en un estándar ejecutable: haz que el Agent juzgue su progreso a partir de los resultados de ejecución.
- Dejar que la máquina se encargue de la verificación de alta frecuencia: acorta el ciclo de retroalimentación con puntos de control por capas, regresión automática y paquetes de evidencias.
- Reservar los juicios clave a las personas: que el responsable decida la dirección de la arquitectura, los límites de riesgo y el momento de detenerse.
Te sugiero empezar con el próximo encargo de tamaño medio: primero escribe la ficha del punto de control y luego pon en marcha el Agent. Cuando necesites probar distintos modelos, puedes integrarte a través de APIYI apiyi.com usando interfaces compatibles con los formatos de OpenAI y Anthropic; los métodos de configuración están en el centro de documentación docs.apiyi.com, y los precios de los modelos y los criterios de facturación se rigen por los datos reales de https://docs.apiyi.com/models.
📚 Referencias
- InfoQ – Reportaje sobre el proyecto Ginux: el proceso y los criterios de aceptación de Codex al construir un kernel compatible con Linux
- Enlace:
infoq.cn/article/OiyNEtFwV05opvsLTcvK -
Descripción: incluye el doble bucle HDAE, el tamaño del proyecto y un análisis de sus limitaciones.
-
InfoQ – Reportaje sobre la factura de tokens de un ingeniero de Cursor: flujos de trabajo intensivos con agentes y la controversia sobre los costos
- Enlace:
infoq.cn/article/q9iebpvFozfy4bgCYUyE -
Descripción: incluye el ciclo cerrado de validación, la arquitectura Dune y las críticas de la comunidad.
-
Informe técnico de Ginux: informe técnico del proyecto publicado por Gregory Kurtzer
- Enlace:
zenodo.org/records/23682548 -
Descripción: recomendable para profundizar en los objetivos de la investigación, la metodología y los límites de los resultados.
-
Repositorio de Ginux en GitHub: código fuente del proyecto
- Enlace:
github.com/gmkurtzer/ginux -
Descripción: permite consultar el código del proyecto y la información sobre la licencia de código abierto.
-
Documentación y página de precios de APIYI: configuración de la interfaz y precios de los modelos
- Enlace a la documentación:
docs.apiyi.com - Enlace a precios:
https://docs.apiyi.com/models - Descripción: para modelos, precios y criterios de facturación, toma como referencia los datos reales que aparecen en la página.
Autor: equipo técnico de APIYI
Intercambio técnico: te invitamos a visitar APIYI apiyi.com para conversar sobre prácticas de ingeniería de agentes. Encontrarás más material de integración en el centro de documentación docs.apiyi.com.
