上周 Hacker News 上有个帖子拿了 570 多分，标题是「Forge: Guardrails take an 8B model from 53% to 99% on agentic tasks」。
570 分意味着什么？在 HN 上，大多数帖子能拿 10 分就算有人看了，能上 100 分是热门，上 500 基本是当天最火的内容之一。这个帖子能拿这么高分，说明它戳中了一个很多人关心但没人解决好的问题：本地小模型在 Agent 场景下到底能不能用？
答案是：裸跑不行，加 guardrails 之后行。
问题在哪
如果你试过用本地模型（7B-8B 参数级别，比如 Llama、Mistral）跑 Agent 任务，你大概率遇到过这些情况：
模型该调用工具的时候输出了一段纯文本。你让它用 JSON 格式返回函数调用，它返回了一段 Markdown 代码块里面包着的 JSON，外面还加了一句「好的，我来帮你调用这个工具」。
或者它调用了正确的工具，但参数格式错了。字符串该加引号没加，数字类型传成了字符串，必填字段漏了。
或者它在多步骤流程中跳过了关键步骤。让它先搜索再分析再输出，它直接跳到输出环节，编造了一个答案。
这些问题在 GPT-4 或 Claude 上很少出现，因为大模型见过足够多的训练数据，知道怎么正确输出 tool call。但 8B 模型的能力边界就在这里：它理解任务意图没问题，但在格式遵循和流程控制上经常翻车。
Forge 怎么解决的
Forge 的思路很简单：既然模型本身不可靠，那就在模型外面套一层可靠的框架，替它兜底。
具体来说，Forge 做了三件事：
1. Rescue Parsing（抢救式解析）
模型返回的不是合法的 tool call 格式？没关系，Forge 会尝试从模型的输出里提取它「想要」表达的工具调用。
比如模型输出了：
好的，让我帮你查一下天气。 {"tool": "get_weather", "city": "北京"}
正常框架遇到这种输出直接报格式错误。Forge 不会，它识别出这里面有一个 get_weather 调用，参数是 city=北京，然后替模型补全正确的 tool call 格式。
2. Retry Nudge（重试提示）
如果抢救也失败了（模型输出实在太离谱），Forge 不会放弃，而是给模型一个「nudge」：在下一轮对话里追加一条系统消息，明确告诉模型「你刚才的输出格式不对，请用 X 格式重新输出」。
这比直接重跑整个请求更省资源，因为模型已经「想好了」要做什么，只是格式不对。nudge 一下，大概率就能纠正过来。
3. Step Enforcement（步骤强制）
在定义 Agent 工作流的时候，你可以指定哪些步骤是必须执行的（required_steps）。Forge 会追踪模型的执行历史，如果它跳过了某个必要步骤就想结束，Forge 会强制把它拉回来。
比如流程是「搜索 → 分析 → 回答」，模型直接跳到「回答」了。Forge 检测到「搜索」这一步没执行过，于是在下一轮提示模型：你还没做搜索呢，先去搜索。
一个被忽视的设计：respond 工具
在 Forge 的代理模式（Proxy Server）中，有一个很巧妙的设计：它给模型注入了一个名为 respond 的「伪工具」。
为什么？因为小模型在同时面对「输出纯文本」和「调用工具」两种选择时，经常选错。它该调工具的时候输出文本，该输出文本的时候又试图调工具。
Forge 的做法是：永远让模型处于「调用工具」的模式。当它想对用户说话的时候，调用 respond(message="...") 这个工具。这样模型只需要做一种类型的输出（工具调用），不用在两种模式之间切换。
Proxy 层会自动把 respond 调用还原成正常的文本回复。客户端完全不知道这个 respond 工具的存在。
这个设计看起来很小，但对 8B 模型来说效果显著。消除了模式切换的认知负担。
数字说话
Forge 自带一个 26 场景的评测套件，分为基础层（18 个场景）和高级推理层（8 个场景）。
在没有 Forge 的情况下，Ministral-3 8B 在这些场景上的通过率是 53%。加上 Forge 的完整 guardrails 栈后，通过率跳到 86.5%，其中基础层接近 99%。
高级推理层（需要模型进行复杂的多步推理）通过率是 76%。这个数字不如基础层好看，但考虑到这是一个 8B 模型，已经相当可观了。
作者在 HN 评论里解释了评测方法：每个场景跑 50 次（batch_eval），取通过率。不是跑一次碰巧过了就算，而是统计意义上的稳定通过率。
为什么这件事重要
你可能会说：直接用 GPT-4 或 Claude 不就完了，何必折腾本地小模型？
有几个场景是大模型 API 覆盖不了的：
隐私场景。你的 Agent 需要处理公司内部代码、医疗记录、法律文件。数据不能出本地。
成本场景。如果你的 Agent 每天要处理几万次请求，GPT-4 的 API 费用会让你的老板心脏骤停。本地模型跑在自己的 GPU 上，边际成本趋近于零。
延迟场景。网络请求往返加上排队，API 调用的延迟通常在 1-5 秒。本地推理可以做到 200ms 级别。
离线场景。工厂车间、野外作业、飞机上。没网也得能跑。
在这些场景里，你只有本地小模型可用。Forge 证明了一件事：问题不在模型太笨，在于你没有给它足够的防护栏。
对 Agent 架构的启示
从 Co-Scientist 的多 Agent 辩论到 Forge 的 guardrails，这两天连续看到的项目都在说同一个道理：Agent 的能力不只取决于底层模型的智力，还取决于你怎么组织和约束它。
Co-Scientist 用对抗机制来提高输出质量。Forge 用格式纠错、重试机制、步骤强制来提高执行可靠性。方向不同，但本质一样：单纯指望模型「自己搞定一切」是不现实的，你需要在模型之上构建系统层面的保障。
如果把 LLM 比作一个聪明但经常犯粗心错误的实习生，guardrails 就是给他配的那个审核流程。不是不信任他的能力，是确保他的能力被正确地发挥出来。
Forge 的代码是开源的，MIT 协议，530 行核心代码。如果你在做本地 Agent 方案，值得花半小时读一遍它的 guardrails 中间件实现。
这是 AI Agent 系列的第六篇。前几篇：