博客Forge 开源项目实测：Ministral 8B + 护栏让 Agent 多步任务成功率从 53% 飙到 99.3%，反超 Claude Sonnet 12 个百分点。本文拆解护栏技术原理、成本对比、反面教训与自建工程清单，帮企业决策者做模型选型。
2026 年 5 月，ACM CAIS 会议接收了一篇来自 TI（德州仪器）AI 总监 Antoine Zambelli 的论文——他开源的项目 Forge 把一台搭载 Ministral 8B 的消费级显卡，在 Agent 多步任务上跑出了 99.3% 的完成率。同一个模型不加护栏时，基线只有 53%。[HN 讨论]
这不是模型能力的差距，是工程层的差距。对于正在做企业 AI 应用开发的团队，这条 46 个百分点的提升曲线，比任何模型排行榜都值得研究。
Forge 的核心逻辑不是让模型变聪明，而是把"模型会犯错"当作既定事实，围绕模型构建约束层。它不修改权重、不微调、不换 prompt——只在模型输入输出两侧加了三道护栏。
Agent 在调用工具、返回结构化结果时，8B 模型经常输出格式错乱——JSON 少括号、字段名拼错、甚至把自然语言和结构化数据混在一起。Forge 在每次模型输出后强制做 schema 校验，不符合预期格式的输出直接拦截，不让它进入下一步。这一步拦截了大约 30% 的初始失败——这些失败不是"模型不懂"，而是"模型说不清楚"。
格式对了不代表内容对了。Forge 在关键步骤上设置断言——比如"返回的金额必须为正数""返回的文件路径必须存在"。断言失败时自动触发重试，把上一次的错误信息注入 prompt，让模型自己修正。据项目方在 HN 讨论中透露，护栏本身的 Python 逻辑开销在毫秒级，重试引入的额外 LLM 调用在秒级，整体延迟增幅约 30–60%，但成功率从 53% 拉到 83%——值不值一目了然。
多步 Agent 任务中最致命的失败模式不是某一步错了，而是错误在后续步骤中被放大——一步幻觉导致后续三步全部跑偏。Forge 在每一步完成后做状态快照，后续步骤检测到不可恢复的错误时回退到上一个快照点重新规划。这套机制把剩余失败率从 17% 进一步压到 0.7%。
最终效果：Ministral 8B（12GB 显存、二手显卡约 $250）配合 Forge 跑出 99.3%，Claude Sonnet 无护栏裸跑只有 87.2%。一个 8B 本地模型反超头部闭源 API 12 个百分点。
企业做 Agent 模型选型不能只看成功率。把单任务推理成本、延迟和成功率放在一张表里，决策逻辑立刻清晰了：
| 方案 | 单任务推理成本 | 延迟（p95） | 成功率 |
|---|---|---|---|
| GPT-5.5 级旗舰模型（云端 API） | $0.12–0.35 | 2.5–6 秒 | 85–92% |
| Claude Sonnet（云端 API） | $0.08–0.25 | 1.8–5 秒 | 87.2% |
| Ministral 8B 裸跑（本地） | ~$0.002 | 0.6–2 秒 | 53% |
| Ministral 8B + Forge 护栏 | ~$0.005 | 1.2–4 秒 | 99.3% |
三条线画出来很清楚：旗舰模型贵但裸跑成功率也不到 95%；8B 裸跑便宜但不靠谱；8B + Forge 在成本仅增加约 2.5 倍的前提下，成功率从 53% 拉到 99.3%。用 1/25 的单任务成本，拿到比旗舰模型高 7–14 个百分点的成功率——这就是护栏的价值。
2025 年底，一家做智能客服 Agent 的 SaaS 团队（日均约 5000 次 Agent 调用）把核心流程全部接在某旗舰模型上。最初两周一切正常，但进入 12 月业务高峰期后问题集中爆发：
团队紧急评估后决定切到 8B 本地模型 + 自建护栏。改造周期约 3 周，最终结果：
Forge 论文中记录的 76 个百分点 swing（同一模型、同一权重、同一量化，不同后端从 7% 跳到 83%）印证了同一件事：很多团队花大价钱买旗舰模型，实际上买的是"基础设施债"——模型本身的原始能力差异远小于工程层差异。我们在 Agent 工程化的深度分析中也得出过一致判断：95% 的失败根因在工程侧，不在模型侧。
| 评估维度 | 倾向大模型（70B+ API） | 倾向小模型（≤13B + 护栏） |
|---|---|---|
| 任务复杂度 | 开放域推理、多步复杂规划、需要广域知识 | 领域收窄、步骤可枚举、有明确正确/错误边界 |
| 容错率 | 低容错（金融交易、医疗建议）需一次性正确 | 中高容错（客服、内容生成、数据处理），允许重试纠正 |
| 延迟敏感度 | 不敏感（批处理、异步任务） | 高敏感（实时对话、在线服务），本地推理 P95 ≤ 2 秒 |
| 预算约束 | 预算充裕，日均调用 < 1000 次 | 预算收紧，日均调用 > 3000 次，本地推理边际成本趋近零 |
一条经验法则：如果你的 Agent 任务可以清晰描述"什么是正确的输出"，就应该优先评估小模型 + 护栏路线。护栏本质上是用工程确定性弥补模型概率性——工程确定性可以测试、可以度量、可以持续优化。概率性只能换模型。关于整体架构选型的更多讨论，企业 AI 应用开发实战指南 中有更完整的体系化拆解。
Forge 是开源的（Apache 2.0），核心逻辑约 2,000 行 Python。但即便不用 Forge，任何企业在落地 Agent 时也必须实现以下四项护栏——缺任何一项，生产环境迟早出事故。企业 AI Agent 从 Demo 到生产环境的工程化决策 中，我们把这套思路总结成了五个关键节点，护栏工程是其中承重最大的一环。
1. 输入校验。 Agent 从上游（用户输入、API 回调、数据库读取）拿到的一切数据，必须过一层 sanitization：长度截断、类型检查、注入检测。8B 模型对异常输入的容错能力远弱于大模型——输入侧出问题会连锁引发幻觉。用一个 20 行的 Pydantic model 就能拦截大量脏数据。
2. 输出格式约束。 每次 LLM 输出后立刻做 JSON Schema / regex 校验。不合格的输出不要试图"修复"——直接构造一个包含错误信息的重试 prompt 发回去。做对的成本远低于"将就用"。
3. 异常回退。 至少实现两层：单步重试（同 prompt + 错误上下文，上限 3 次）和步骤回退（回到上一个检查点重新规划）。超过重试上限直接降级到人工兜底或预设响应——不要让 Agent 无限循环。
4. 幻觉检测。 对于涉及事实性声明的输出（"订单号 88421 已发货"），在进入下一步之前做一次反向校验——拿声明去查数据库或调用确认 API。对不上就阻断并触发重试。
这四项不是"高级功能"。Forge 的数据告诉我们：不加护栏的 8B 是 53%，加了是 99.3%。46 个百分点的差距，全靠这几层工程实现。
不一定"稳定超过"，但在可枚举正确性的任务上，护栏可以显著缩小差距甚至反超。Forge 的 99.3% vs Sonnet 的 87.2% 是真实数据，前提是任务有明确的正确/错误判定标准。对于开放域创意写作、复杂策略推理等"没有标准答案"的场景，大模型的优势仍然显著。
护栏是一次性工程投入，API 是持续性成本。Forge 核心逻辑约 2,000 行 Python，一个中等规模工程团队 2–3 周可完成集成适配。如果日均调用量超过 2,000 次，护栏的一次性开发成本通常在 2–4 个月内被 API 节省覆盖。之后每多跑一天都是净节省。
12GB 显存即可运行 Ministral 8B（4-bit 量化后更低）。二手 RTX 3060 12GB 约 ¥600–800，全新 RTX 4060 Ti 16GB 约 ¥3,000。企业场景建议上 RTX 4090 24GB 做并发推理，单卡可支撑日均 3,000–5,000 次调用的轻量 Agent 场景。
Forge 在论文中主要基于 Ministral 8B 做验证，但其护栏层是模型无关的——任何支持 OpenAI 兼容 API 的模型都可以接入。项目已开源在 GitHub，采用 Apache 2.0 协议，企业可自由使用和修改。
在企业 AI 应用开发中，模型选型不是越大越好——护栏工程才是拉开成功率的关键变量。优码云（umayun）在帮助企业落地 Agent 方案时，始终将护栏工程作为交付标准的一部分。如果你的团队正在评估 Agent 模型选型，或者已有方案遇到成功率瓶颈，可以联系我们做一次技术评估——我们会基于你的具体任务场景，给出选型建议和护栏实现方案。