Forge - herramienta que impulsa modelos de 8B de 53% a 99% en tareas de agentes con guardrails

• Forge es una capa de confiabilidad para el tool calling de LLM autoalojados, enfocada en mejorar la estabilidad de modelos locales pequeños en flujos de trabajo de agentes de varios pasos
• Sus funciones clave incluyen rescue parsing para recuperar llamadas a herramientas incorrectas, inducción de reintentos, aplicación forzada de pasos obligatorios, presupuesto de tokens consciente de VRAM y compresión jerárquica de contexto
• Actualmente, la configuración autoalojada líder, Ministral-3 8B Instruct Q8 sobre llama-server, registra 86.5% en 26 escenarios de evaluación y 76% en el nivel más difícil
• Hay tres formas de uso: delegar todo el bucle del agente a WorkflowRunner, insertar el middleware de Guardrails en un bucle de orquestación existente o aplicarlo de forma transparente con un servidor proxy compatible con OpenAI
• WorkflowRunner gestiona el prompt del sistema, la ejecución de herramientas, la compresión de contexto y los guardrails, mientras que SlotWorker añade colas con prioridad y apropiación preventiva automática a ranuras compartidas de inferencia en GPU
• El servidor proxy se ejecuta con python -m forge.proxy y se coloca entre clientes compatibles con OpenAI como opencode, Continue y aider, y el servidor local del modelo para aplicar guardrails
• El proxy inyecta automáticamente una herramienta sintética respond en solicitudes con herramientas para hacer que el modelo llame a respond(message="...") en lugar de devolver texto normal, y en la respuesta la elimina para que al cliente le parezca una respuesta de texto estándar
• Los backends compatibles son Ollama, llama-server (llama.cpp), Llamafile y Anthropic; llama-server ofrece el mejor rendimiento y control, Ollama una configuración sencilla, Llamafile ejecución en un solo binario y Anthropic una línea base de frontera y flujos de trabajo híbridos
• La instalación se puede hacer con pip install forge-guardrails; el cliente de Anthropic se añade con pip install "forge-guardrails[anthropic]"; los requisitos son Python 3.12+ y un backend de LLM en ejecución
• El arnés de evaluación mide la confiabilidad del tool calling de varios pasos en combinaciones de modelos y backends con 26 escenarios, divididos en niveles basados en OG-18 y 8 niveles de advanced_reasoning
• La configuración de pruebas incluye 865 pruebas unitarias deterministas que no requieren backend de LLM y un arnés de evaluación contra backends reales
• El framework de guardrails de Forge y su ablation study fueron publicados como Forge: A Reliability Layer for Self-Hosted LLM Tool-Calling, y su licencia es MIT

[GN⁺]

Comentarios de Hacker News

• Me gusta trabajar en esta área y me resulta útil, pero evito los LLM basados en la nube y uso principalmente modelos locales de 4B~30A3B parámetros
  Así que, aunque no tengo una gran intuición sobre el rendimiento o la precisión de los LLM más recientes, sí creo conocer bien el nivel que se puede esperar de los modelos locales y sus cuellos de botella
  Le eché un vistazo rápido al artículo y leí el resumen, y aunque menciona que con ajustes simples puede volverse 10 veces más rápido o más lento, las métricas y los datos parecen centrarse casi solo en la precisión. Habría que hablar de la velocidad
  En especial, en flujos de trabajo tipo agente y con modelos locales, para mí la precisión de llamadas a funciones/herramientas no ha sido un gran problema desde la época de QwenCoder3 durante los últimos 6~12 meses; la clave es la gestión del contexto y el impacto en el tiempo. Si el agente cambia mucho el prompt, se rompen optimizaciones de tiempo como el caché de prompts
  Y aquí parece que además se agregan capas y wrappers como guardrails y reintentos, lo cual en modelos locales, sobre todo para uso como agente, puede volverlo inutilizable por la latencia
  Perdón si esto ya lo abordaron directamente, pero se habla demasiado poco del impacto en el tiempo y eso da la impresión de que se está ocultando o exagerando la mejora real. Me gustaría escuchar experiencias sobre velocidad. También me preocupa un poco que nadie más lo haya señalado; me hace pensar si soy yo el que está haciendo algo mal o si en realidad casi nadie usa modelos locales de verdad

• Llevo tiempo diciendo que, con un harness bien hecho, incluso los modelos locales pequeños pueden rendir sorprendentemente bien
  Si es un sistema que puede intentar de todo, mientras le impidas dar resultados incorrectos en el proceso, al final puede acertar

  • El problema es que la calidad se parece a la de darle a un junior tiempo ilimitado y decirle que siga probando enfoques hasta llegar a la meta
    Si la tarea es lo bastante compleja, incluso los modelos de última generación tienen este problema, y en los modelos pequeños se amplifica aún más
  • Me gusta ese encuadre. Trabajando en esto, los modelos pequeños me han parecido bastante impresionantes
    Su razonamiento también es bastante bueno y en muchos casos es suficiente. A veces solo hay que empujarlos un poco de vuelta al camino y ellos lo resuelven solos
  • Si lo entendí bien, la razón por la que el modelo puede acertar es que sabe cuándo está equivocado

• Me da gusto ver que alguien construyó mucho mejor algo para lo que yo quería hacerme tiempo. Una pregunta es si, por ejemplo, hay espacio para paralelizar en un bucle de reintentos
  Los modelos locales normalmente pueden manejar bastante bien una cantidad limitada de solicitudes concurrentes, quizá del orden de dos dígitos, incluso en hardware de consumo, y eso puede elevar los tokens efectivos por segundo más de 10 veces
  Llevo tiempo pensando en flujos de trabajo que aprovechen eso, y “arregla este error”, aunque no sea perfecto, parece que podría servir. Me interesa saber cómo lo ven

• Tengo algunas ideas en esta área y las estoy metiendo en mi harness. Mi harness está bastante especializado, así que no sé qué tan generalizable sea
  Divido el problema en una ejecución planificada, y le doy al agente ejecutor un plan inicial que incluye objetivos explícitos, como qué herramientas llamar y cuáles son los criterios de una ejecución exitosa. El harness ejecuta ese plan en orden
  En cada paso que incluye llamadas a herramientas, descompongo la llamada en componentes. El harness le pide al agente valores válidos de parámetros para los argumentos actuales de la herramienta, y la definición de la herramienta tiene validadores para cada argumento. Si la validación falla, el harness rebobina la conversación e inyecta la razón del fallo en el siguiente intento
  Cuando sale una respuesta válida para un argumento, pasa al siguiente, y cuando todos los argumentos están llenos, llama la herramienta. Le pasa al agente el valor esperado inicial, el valor real y cualquier error que haya ocurrido, y le pregunta si está satisfecho con el resultado
  Si no lo está, el agente da una razón, y el harness rebobina la conversación, mete la razón del reintento y vuelve a empezar el proceso de llamada a herramienta desde cero
  El agente puede pedir una replanificación si detecta defectos en el plan inicial, y el harness también intenta replanificar si hay demasiados fallos consecutivos
  Este enfoque es bastante efectivo para reducir los fallos en llamadas a herramientas. Una ventaja es que el subagente recibe un historial de conversación perfecto, sin errores. Aunque todavía no he hecho benchmarks para ver si la tasa real de finalización de tareas es mejor

  • Hice experimentos con una filosofía parecida en un harness de coding tipo agente basado en modelos pequeños, y lo construí sobre forge
    Sobre rebobinar la conversación, implementé un plegado de llamadas a herramientas parecido para el agente principal, o sea, el que conversa con el usuario. Cuando terminaba la tarea, plegaba el registro de llamadas a herramientas para mantener limpio el contexto; era más una cuestión de higiene que de tamaño
    La parte donde el harness interroga al modelo es un poco distinta, y no he probado ese enfoque. Forge depende de la autocorrección del modelo para evitar modos de error dedicados, pero si se pudiera abstraer y automatizar el proceso de preguntas con base en algo como esquemas, parecería posible
    En general, me gusta el aspecto de mantener un historial limpio, pero en herramientas con muchos argumentos parece que podría haber muchas más idas y vueltas que con “dejar que falle una vez y luego darle un empujón”. Aun así, es una idea interesante para escenarios o tareas más difíciles
  • Estoy usando Strix Halo y, como se vuelve lento con contexto largo, pensé en el mismo enfoque. Con esto quizá se podría mantener un contexto de menos de 10 mil tokens
    Si con modelos pequeños se pudiera superar 50k tokens/segundo, sería bastante grande
    Pero por ahora estoy ocupado con trabajo de la empresa y otros proyectos, así que solo he probado unas cuantas docenas de prompts para ver si es posible
  • Por curiosidad, estoy construyendo uno yo mismo con gemma4, y me sorprende lo lejos que está llegando

• Excelente. Ahora mismo no puedo usar inferencia local por costos, pero cuando uso modelos pequeños con OpenRouter me preocupaban las llamadas a herramientas
  Estoy construyendo Dokimasia (do-kee-ma-see-ah), un framework de pruebas de argumentos con prioridad en pytest, y me gustaría escuchar opiniones: https://github.com/deevus/dokimasia
  Puede que las pruebas de argumentos no sean algo que Forge necesite, pero como están construyendo herramientas de IA bastante a fondo, pensé que quizá tendrían ideas

  • Es una idea interesante. Básicamente parece formalizar una capa de abstracción para probar varios tipos de integraciones dentro del ecosistema de IA, como MCP o skills
    Parece estar un nivel por encima de Forge, más orientado a probar flujos de trabajo reales y los puntos de integración que aparecen en ellos, como qué herramienta ofrece acceso vía MCP
    No parece que hubiera gran problema en superponer ambos
    Lo que me da curiosidad es cómo manejan la no determinación de estos modelos. A veces hacen bien la llamada a herramienta, y a veces escupen JSON inválido. ¿La suite de pruebas intenta varias veces?

• La ambigüedad en llamadas a herramientas también la vivo con modelos de frontera. Uso a diario Claude Code, Codex y Gemini CLI en paralelo para desarrollo, y el modo de fallo más común es cuando grep/find termina con código de salida 1, o sea, sin coincidencias
  El modelo lo interpreta no como “la búsqueda se ejecutó y no encontró nada”, sino como “la herramienta falló”, y en vez de rendirse o ampliar el rango de búsqueda, solo reintenta con cambios mínimos de sintaxis
  La capa de reintento-con-empujón corresponde casi 1:1 con algo que yo hago manualmente varias veces por hora. Algo como: “No, la herramienta no falló; simplemente ese archivo no tiene ese patrón. Prueba X”
  Parece correcto codificar eso a nivel de framework
  Me interesa saber si también vieron que este tipo de guardrails reduce la brecha con modelos pequeños de frontera en tareas largas. Mi intuición es que una diferencia de 87→99 en Sonnet no se va a mantener igual al pasar de unas 50 etapas, porque después de eso el drift de contexto domina más que la semántica de reintentos

  • Al menos en modelos de frontera grandes, definitivamente llevan ventaja en ese punto. Solo que no tuve tiempo de formalizar esos resultados
    Como pista útil, forge técnicamente se enfoca en la ejecución de llamadas a herramientas, no en la calidad del modelo. La respuesta real es esta
    En modelos pequeños del rango 14B, el factor limitante era la atención efectiva. Aunque todo quepa de sobra dentro del tamaño de ventana de contexto de entrenamiento, después de cierto punto empieza a verse degradación. No tengo números exactos, pero modelos como Opus pueden seguir mucho más tiempo en ese punto
    También construí una función de plegado del historial de mensajes de llamadas a herramientas que algún día quizá use directamente en forge. Básicamente organiza el historial de mensajes de forma inteligente para que el modelo pierda menos el hilo
    Aun así, la suite de evaluación de coding del harness tipo agente incluye tareas de refactorización y de agregar funcionalidades, y todas se ejecutan en repositorios sandbox reales. Incluso los modelos pequeños pueden llevar ese tipo de tareas hasta 50~60 llamadas a herramientas. Eso sí, no creo que les asignara más de una de esas tareas en la misma sesión

• Esto ya es otro tema, pero si alguien está en Texas Instruments, me pregunto si podría averiguar cuál terminó siendo el estado de la propiedad intelectual de la máquina Lisp TI Explorer
  Sé quién posee la propiedad intelectual de Genera, pero no he podido averiguar lo del Lisp OS de TI

  • ¿Quién tiene la propiedad intelectual de Genera?

• Para quienes piensan más ampliamente en el stack de “seguridad de agentes”, esta dirección se siente complementaria a cosas como kontext-cli de Kontext (github.com/kontext-dev/kontext-cli) o OneCLI (github.com/onecli/onecli)

• Hay una parte que dice: “Los mismos pesos de Mistral-Nemo 12B obtienen 7% de precisión en llamadas a funciones nativas de llama-server y 83% en modo prompt de Llamafile”
  Yo pensaba que Llamafile era solo el modelo y llama.cpp empaquetados en un único binario; entonces, ¿esta diferencia es entre que Llamafile inyecte un prompt de sistema por defecto y llamar al endpoint crudo de llama-server sin harness?
  Esto parece comparar manzanas con pay de manzana, y faltan ingredientes intermedios

  • A mí también me sorprendió. En el artículo pusieron un ejemplo extremo pero real. En este caso es posible que la plantilla nativa de llamadas a funciones haya funcionado
    Pero eso no explica la diferencia de casi +4 pp entre el prompt de Lamaserver y llamafile, ni la diferencia de cerca de +30 pp de Ollama, que queda casi a mitad de camino entre llamaserver nativo y llamafile
    El backend de serving afectó a casi todas las familias de modelos, y realmente casi nunca había visto que se hablara de esta parte

• Esta dirección es realmente excelente. Incluso con modelos bonsai de 1 bit están saliendo resultados ridículamente buenos y además se lleva bien con lmstudio
  Ahora ya es completamente realista poner una 7900XTX en un equipo sobrante, dejarlo en el sótano, lanzarle un objetivo absurdo y olvidarte de él