Cómo evaluar un arnés abierto de agentes antes de un piloto de producción

Un arnés abierto de agentes puede resultar atractivo porque hace visibles más elementos del sistema de agentes. En vez de recibir una experiencia terminada de investigación o automatización, un equipo técnico puede elegir modelos, conectar herramientas, establecer límites de almacenamiento, añadir instrucciones reutilizables y decidir dónde se ejecuta el trabajo. Estas decisiones pueden aportar valor. También convierten el entorno de ejecución en algo que el equipo debe operar y revisar.

DeerFlow es un ejemplo útil de esa decisión. Su repositorio oficial presenta un arnés abierto de agentes para trabajos de larga duración, con modelos, herramientas, memoria, entornos de ejecución y habilidades configurables. Los mantenedores marcaron la versión 2.0.0 como una versión estable en junio de 2026. Es un hito técnico más claro que una aparición posterior en una lista de popularidad, pero no demuestra que una implementación concreta vaya a ser fiable, segura o económica.

Gráfico del repositorio incluido en el paquete fuente terminado. Ilustra el contexto del proyecto DeerFlow, no un despliegue de cliente ni un resultado medido de forma independiente.

Empiece por el flujo de trabajo, no por el framework

Un piloto debe comenzar con una tarea acotada que ya tenga una persona responsable. Los buenos candidatos tienen una entrada definida, una salida observable y un punto claro en el que una persona pueda juzgar el resultado. Por ejemplo, un equipo puede pedir a un agente que convierta un pequeño conjunto de documentos públicos de producto en una comparación con citas, que clasifique una clase limitada de tickets de soporte en borradores o que prepare un resumen de cambios a partir de un repositorio aprobado.

Anote los criterios de éxito antes de configurar el arnés. Incluya exactitud factual, calidad de las fuentes, aprobaciones requeridas, tiempo de finalización, coste de modelos y herramientas, y la cantidad de correcciones del revisor. Un informe fluido o una ejecución que finaliza correctamente no basta. El resultado debe ser útil para el flujo de trabajo al que pretende servir.

Conserve una línea de base más simple. Compare el arnés con un buen flujo de un solo agente que use prompt y herramientas, o con el producto gestionado que el equipo ya utiliza. La delegación en varios pasos solo merece la pena si mejora un resultado medido, como la cobertura, la recuperación o el tiempo de revisión. Más agentes también pueden implicar más llamadas a modelos, conclusiones intermedias en conflicto y más lugares donde los permisos pueden configurarse mal.

Separe la capacidad del modelo de la responsabilidad del entorno de ejecución

Un modelo puede razonar, escribir y llamar a una herramienta, pero un sistema de agentes en producción tiene responsabilidades adicionales. Debe decidir qué herramientas puede usar una tarea, conservar o descartar estado, gestionar una solicitud fallida, informar de lo ocurrido y detenerse con seguridad cuando interviene una persona. Un arnés abierto puede exponer esas decisiones en vez de ocultarlas tras una interfaz alojada.

Esta visibilidad solo es útil si el equipo asigna responsabilidades. Haga un inventario de los proveedores de modelos, servicios de búsqueda o recuperación, servidores MCP, almacenes de archivos, secretos, colas y ubicaciones de artefactos generados que toca el flujo. Para cada uno, registre los datos que recibe, las credenciales que usa, la persona responsable y el comportamiento esperado ante un fallo. Una implementación local todavía puede enviar datos a un proveedor externo de modelo o búsqueda si esas conexiones están configuradas. El código abierto por sí solo no hace privada la ejecución.

El repositorio de DeerFlow describe herramientas para trabajo web, archivos y ejecución de comandos. Son capacidades, no un modelo de permisos. Trate cada herramienta como un límite que hay que probar. Empiece con acceso de solo lectura o con un proyecto desechable. Añada capacidad de escritura solo después de conocer el objetivo exacto, el paso de aprobación, el registro de auditoría y el método de recuperación. Una instrucción en el prompt como «no leas este archivo» no es un límite de contención.

Pruebe primero la ruta menos indulgente

La ruta ideal rara vez revela si un entorno de agentes está listo para un uso más amplio. Ejercite los límites que provocan fallos operativos reales: tiempo de espera de una herramienta, modelo no disponible, resultado no válido de un conector, ejecución cancelada, reinicio de un servicio y reintento tras trabajo parcial. Compruebe que el sistema muestre el paso responsable y que el siguiente intento reutilice un estado seguro en lugar de repetir un efecto externo.

Para una tarea que lee material interno, pruebe también el aislamiento. Confirme que los archivos, notas y resultados intermedios de un usuario no puedan recuperarse desde la tarea de otro. Para una tarea que ejecuta código o llega a servicios externos, valide el sandbox, las rutas montadas, las rutas de red y el alcance de los secretos en la configuración que realmente se desplegará. Las instrucciones del prompt no son un límite técnico de contención.

Las notas de la versión 2.0 de DeerFlow describen trabajo sobre estado persistente, trazado, correcciones de seguridad y comportamiento de memoria. Son áreas útiles que inspeccionar durante un piloto. No eliminan la necesidad de probar la combinación seleccionada de modelo, proveedor, sandbox y herramientas. La configuración desplegada, y no un diagrama de arquitectura, es lo que determina el riesgo.

Convierta la observabilidad en parte de la decisión de producto

Un sistema de agentes fiable necesita evidencia que permita a un revisor reconstruir un resultado relevante. Conserve la entrada de la tarea, las llamadas de herramientas pertinentes, las referencias de fuentes, las versiones del modelo y del flujo, las decisiones intermedias importantes, el artefacto final y el registro de aprobación. Evite conservar más contenido personal o sensible del que necesita el flujo; un rastro de auditoría útil debe tener un límite de retención documentado.

Revise el rastro con las personas que operarán el sistema. ¿Pueden ver por qué se detuvo una tarea? ¿Pueden distinguir un rechazo del modelo, una fuente deficiente, un fallo de herramienta y una aprobación pendiente? ¿Pueden identificar qué modelo o conector provocó un coste inesperado? Si la respuesta es no, puede ser difícil mejorar el sistema aunque una demostración parezca exitosa.

Aquí también merece escrutinio la personalización. Los mantenedores de DeerFlow han debatido una arquitectura de extensiones porque, de otro modo, las adiciones transversales podrían exigir cambios en rutas del entorno de ejecución que evolucionan rápido. Esa propuesta es evidencia de una preocupación real de mantenimiento, no una capacidad prometida. Los equipos deben preguntar qué personalizaciones pueden versionarse como extensiones compatibles, cuáles requieren un fork y cómo se probará un flujo fijado a una versión antes de una actualización.

Decida con evidencia reversible

Un piloto no tiene por qué terminar en una decisión de sustitución completa. Un resultado razonable puede ser un flujo interno limitado, un entorno solo de investigación o la decisión de esperar una historia más estable de extensiones y operaciones. Lo importante es que la decisión pueda explicarse con evidencia, no con métricas de popularidad.

Use un registro de decisión breve con cuatro columnas: observación, evidencia de respaldo, riesgo sin resolver y próximo responsable. Algunos ejemplos son una puntuación de cobertura de fuentes del piloto, un registro de los permisos realmente ejercidos, el coste de una ejecución terminada, una prueba de recuperación fallida y una corrección planificada. Vincule cada conclusión a una configuración y una ejecución de prueba, no a un número de estrellas ni a una afirmación de marketing.

Antes de ampliar el alcance, fije las versiones que pasaron, conserve entradas de prueba que se puedan retener con seguridad, documente los pasos de reversión y establezca una fecha de revisión. Ejecute de nuevo el mismo flujo de aceptación tras actualizar un modelo, herramienta, prompt, sandbox o arnés. Esto es especialmente importante en sistemas de agentes abiertos porque un cambio en cualquier capa puede alterar el comportamiento de todo el flujo.

La pregunta central, por tanto, no es si un arnés abierto es mejor que un agente alojado. Es si asumir la orquestación crea suficiente valor medible para este flujo de trabajo como para justificar la nueva responsabilidad operativa. Empiece en pequeño, pruebe los límites que una demostración omite y amplíe solo cuando la evidencia siga siendo sólida.