Forge：用 Guardrails 把小模型变成可靠的 Agent，8B 模型能力从 53% 提升到 99%

原文来源：antoinezambelli/forge — 一个用于自托管 LLM 工具调用和多步骤 Agent 工作流的 Python 框架，通过 Guardrails 机制将 8B 模型的 Agent 任务准确率从 53% 提升到 99%。

小模型的 Agent 困境

大语言模型在聊天和文本生成上已经相当成熟，但要让它们真正"做事"——调用 API、查询数据库、操作文件系统——就完全是另一回事了。这个能力通常被称为 工具调用（Tool Calling） 或 函数调用（Function Calling）。

问题在于，顶尖的闭源模型（如 Claude、GPT-4）固然擅长这类任务，但高昂的 API 费用、数据隐私顾虑和网络延迟让很多团队望而却步。反过来，自托管的开源小模型（8B 参数级别）虽然成本低、隐私好，但在工具调用这类结构化任务上的表现却常常令人失望——它们会编造不存在的工具名称、把参数格式搞错、在需要调用工具时却直接输出文本，或者在多步骤任务中忘记上下文衔接。

这正是 Forge 要解决的核心问题。

什么是 Forge？

Forge 是一个 Python 框架，定位为自托管 LLM 工具调用的可靠性层（Reliability Layer）。它不负责编排多 Agent 系统，也不试图做大模型框架——它只做一件事：让自托管模型在工具调用时不出错。

项目由 Antoine Zambelli 开发，于 2026 年 5 月登上 Hacker News 首页（687 票），在 GitHub 上已获得超过 2000 星，当前版本为 v0.7.4。项目的核心论文《Forge: A Reliability Layer for Self-Hosted LLM Tool-Calling》已被 ACM 收录（DOI: 10.1145/3786335.3813193）。

最引人注目的数据是：通过 Guardrails 机制，一个 8B 参数的开源模型在 Agent 任务上的准确率从 53% 提升到了 99%。作者同时也用 Sonnet 4.6 做了对比测试，在 v0.6.0 的评估中，Sonnet 4.6 从 85% 提升到了 98%。

Guardrails：Forge 的核心机制

Forge 的 Guardrails 是一套可组合的可靠性保障层，在模型推理的输入输出路径上施加多层校验。它不是一次性的 Prompt 优化，而是一个基于"失败-纠正-重试"闭环的系统级方案。

具体来说，Guardrails 包含以下几个关键组件：

1. 响应验证（Response Validation）

模型每次返回的工具调用都会经过严格校验。Forge 会逐一检查：调用的工具名称是否存在于已注册的工具列表中？参数结构是否匹配预期的 JSON Schema？如果校验不通过，模型不会拿到"蒙混过关"的机会。

2. 救援解析（Rescue Parsing）

小模型在输出工具调用时经常出现格式问题——有时把 JSON 包在代码块里，有时用 Mistral 风格的 [TOOL_CALLS]name{args} 格式，有时用 Qwen 的 <tool_call> XML 格式。救援解析器专门处理这些"格式瑕疵"：它从各种非标准格式中提取出结构化的工具调用，重新包装为规范的 OpenAI tool_calls 格式再向下游传递。作者特别指出，这对于 Mistral 家族的模型来说是最实用的改进之一。

3. 重试循环与错误追踪（Retry Loop + Error Tracking）

如果验证失败怎么办？Forge 不会直接将错误返回给用户，而是启动内部重试。在默认配置下（最多重试 3 次），Forge 会将校验失败的具体原因以工具结果消息的形式反馈给模型，让模型有机会修正后再尝试。从客户端角度看，这就像一次请求多花了几个毫秒——完全透明。

4. 合成 respond 工具注入

这可能是最巧妙的设计之一。当请求中包含工具时，Forge 会自动注入一个名为 respond 的合成工具。模型如果要输出纯文本响应，必须调用这个 respond 工具，而不是直接输出文本。Forge 在将响应返回给客户端之前会剥离 respond 调用，让客户端看到的是一次正常的文本响应（finish_reason: "stop"）。

为什么这么做？因为 8B 级别的小模型无法可靠地判断"什么时候该调用工具，什么时候该直接回答"。强行给它们这种判断力，结果就是频繁出错。respond 工具把二元选择（工具 vs 文本）变成了统一的选择（永远调用工具），让模型只需要做好参数填充即可。这是一个"认知降维"的策略——把模型的自由选择空间缩小到它真正能驾驭的范围。

三种使用方式

Forge 提供了三种不同层次的使用方式，适应从"零改造成本"到"深度集成"的不同需求。

1. Proxy 服务器（代理模式）

这是最受欢迎的入口。Forge 的 Proxy 模式是一个轻量 HTTP 代理服务器，运行在客户端和本地模型后端之间，同时支持 OpenAI Chat Completions API 和 Anthropic Messages API（/v1/messages）两种协议。

使用方式极其简单：

# 外部模式——你自己启动后端，Forge 做代理
python -m forge.proxy --backend-url http://localhost:8080 --port 8081
 
# 托管模式——Forge 同时启动后端和代理
python -m forge.proxy --backend llamaserver --gguf path/to/model.gguf --port 8081

然后，你可以把任何兼容 OpenAI API 的工具（opencode、Continue、aider、Cline）甚至 Claude Code 指向这个代理。Claude Code 用户只需设置环境变量 ANTHROPIC_BASE_URL=http://localhost:8081 就可以用本地模型做 Agent 工作，而 Claude Code 本身浑然不觉。

对于代理模式下支持的 Guardrails 功能，每个 POST /v1/chat/completions 请求会经过响应验证、救援解析、重试循环和合成 respond 工具注入这四个环节。不过，代理模式受限于单次请求的上下文——像步骤顺序强制、上下文压缩等功能需要在 WorkflowRunner 中才能使用。

2. WorkflowRunner（工作流运行器）

如果你想在 Python 中直接构建 Agent 应用，WorkflowRunner 提供了完整的生命周期管理。你定义工具集、选择后端、然后运行结构化的 Agent 循环。

import asyncio
from pydantic import BaseModel, Field
from forge import (
    Workflow, ToolDef, ToolSpec,
    WorkflowRunner, LlamafileClient,
    ContextManager, TieredCompact,
)
 
def get_weather(city: str) -> str:
    return f"72°F and sunny in {city}"
 
class GetWeatherParams(BaseModel):
    city: str = Field(description="City name")
 
workflow = Workflow(
    name="weather",
    description="Look up weather for a city.",
    tools={
        "get_weather": ToolDef(
            spec=ToolSpec(
                name="get_weather",
                description="Get current weather",
                parameters=GetWeatherParams,
            ),
            callable=get_weather,
        ),
    },
    required_steps=[],
    terminal_tool="get_weather",
    system_prompt_template="You are a helpful assistant. Use the available tools.",
)
 
async def main():
    client = LlamafileClient(
        gguf_path="path/to/Ministral-3-8B-Instruct-2512-Q8_0.gguf",
        mode="native",
        recommended_sampling=True,
    )
    ctx = ContextManager(strategy=TieredCompact(keep_recent=2), budget_tokens=8192)
    runner = WorkflowRunner(client=client, context_manager=ctx)
    await runner.run(workflow, "What's the weather in Paris?")
 
asyncio.run(main())

在这个模式下，你可以利用 required_steps（必需步骤）、prerequisites（前置条件）和 terminal_tool（终止工具）来约束工作流。上下文管理器提供层级压缩策略（TieredCompact、SlidingWindowCompact），自动管理 Token 预算，避免长会话中的上下文膨胀。

WorkflowRunner 还内置了 SlotWorker 机制——优先队列的推理槽位共享系统，支持自动抢占（auto-preemption）。如果你构建的是多 Agent 架构，多个专职工工作流需要共享一块 GPU 推理资源，SlotWorker 能帮你高效调度。

3. Guardrails 中间件

如果你已经有自己的一套编排系统，不想换框架，Forge 的 Guardrails 可以当作中间件插入到你的工作流中。你掌握循环控制权，Forge 负责校验响应、救援格式错误的工具调用、强制执行必需步骤。

这种模式通过 Guardrails 外观类（facade）暴露完整的功能栈，适合已有基础设施的团队做增量引入。

支持的模型后端

Forge 支持五种后端，覆盖了当前自托管 LLM 的主流方案：

作者推荐使用 llama-server——在 26 个评估场景中，前十名配置全部运行在 llama-server 上。

评估体系与数据

Forge 拥有一个完善的评估框架，包含 26 个评估场景，分为 OG-18 基础层和 8 个高级推理场景。评估指标通过 JSONL 格式输出，支持批量运行和自动恢复。

核心数据点（来自 v0.7.0 评估）：

• 8B 本地模型 + Forge Guardrails：从个位数提升到 84%
• 8B 本地模型从 53% 提升到 99%（针对特定工作负载）
• Sonnet 4.6：从 85% 提升到 98%（v0.6.0 数据）

注意这些数据是针对 26 个评估场景的完整套件。具体到不同工作负载，提升幅度有所差异，但趋势一致：Guardrails 对所有模型都有正向作用，对小模型的提升幅度尤其显著。

这个结论的深层意义在于：Guardrails 缩小了开源模型与闭源前沿模型之间的差距。当一个 8B 模型经过 Guardrails 处理后能达到 99% 的准确率，那在很多实际场景中，你就不再需要为 Claude 或 GPT-4 付费了。

与其他工具的对比

LangChain / LangGraph

LangChain 是当前最流行的 LLM 应用框架，但它的定位是"编排"——管理链、Agent、检索增强生成（RAG）等高层抽象。LangGraph 更近一步，提供了有状态图编排。但这些框架在工具调用的可靠性层面做得不够深。

Forge 的定位是补充性工具：它可以嵌入到 LangChain 的工作流内，也可以独立使用。两者解决的问题层次不同——LangChain 解决"如何编排"，Forge 解决"如何不出错"。

值得注意的是，Forge 明确声明自己不是 Agent 编排器（not an agent orchestrator），也不试图做多 Agent 系统、DAG 规划器或跨 Agent 协调。它的专注本身就是一个设计优势。

其他 Guardrails 方案

市面上也有一些 Guardrails 工具（如 NVIDIA NeMo Guardrails），但它们的重点通常是内容安全（防止有害输出、合规检查），而非工具调用的结构可靠性。Forge 填补的是工具调用这个细分领域——响应格式验证、救援解析、重试策略、合成工具注入——这些是内容安全框架不会触及的层面。

适用场景

Forge 最适合以下场景：

1. 自托管模型做 Agent 工作。 如果你因为数据隐私、成本或延迟原因不能使用闭源 API，Forge 是目前让开源小模型变得"能用"的最佳方案之一。

2. 本地代码助手。 通过 Proxy 模式，你可以让 Continue、opencode、aider、Cline 等工具使用本地模型，同时获得与顶级闭源模型接近的 Agent 能力。

3. Claude Code 本地化。 一个特别有趣的用例：用 Forge Proxy 让 Claude Code 使用本地开源模型。Claude Code 是 Anthropic 的终端 Agent 工具，通常只能搭配 Anthropic API。Forge 通过代理兼容 Anthropic Messages API，让 Claude Code 可以"认为"自己在和 Claude 对话，实际上背后跑的是本地模型。

4. 多 Agent 系统共享推理资源。 SlotWorker 机制让多个专职工件流共享 GPU 推理槽位，适合构建复杂的多 Agent 架构。

5. 生产环境可靠性要求高的工具调用。 如果你的 Agent 应用面向用户、不能出错，Forge 的 Guardrails 提供了多层保障——即使底层模型升级或更换，这些保障依然有效。

架构设计亮点

从项目的源码结构可以看出作者的设计哲学。src/forge/ 目录结构清晰：

• guardrails/ — Guardrails 外观类、响应校验器、步骤强制器、错误追踪器
• clients/ — 各类后端的客户端抽象（相同协议，不同实现）
• context/ — 上下文管理器与压缩策略（NoCompact、TieredCompact、SlidingWindowCompact）
• proxy/ — 代理服务器、请求处理、消息格式转换
• core/ — 核心工作流定义、推理循环、运行器

项目拥有 865 个确定性单元测试（无需 LLM 后端即可运行），代码覆盖率通过 Codecov 追踪。这种测试密度在 LLM 应用框架中相当罕见——大多数同类项目高度依赖"与模型一起跑"的集成测试，而 Forge 花了大量精力在确定性测试上，这是它能在快速迭代中保持可靠性的基础。

快速上手

Forge 的安装非常简洁：

pip install forge-guardrails                # 基础版
pip install "forge-guardrails[anthropic]"   # 含 Anthropic 客户端

最小要求是 Python 3.12+ 和一个运行的 LLM 后端。项目已发布在 PyPI 上，可以使用 pip install forge-guardrails 一键安装。

写在最后

Forge 的核心理念值得所有 LLM 应用开发者思考：不要指望模型变得更聪明，而是让系统变得更宽容。 在一个模型能力短期内难以突破的阶段，通过在系统层面构建容错和纠正机制，可以让现有模型的实际表现大幅提升。Guardrails 将小模型的工具调用准确率从 53% 拉到 99%，这不只是一个技术突破，更是一种设计范式——可靠性可以独立于模型能力，通过系统架构来保障。

如果你正在用本地模型构建 Agent 应用，或者纠结于"要不要为了 Agent 能力放弃自托管方案"，Forge 值得一试。它可能会改变你对"小模型能做什么"的判断。