Forge 是开发者 Antoine Zambelli 在 5 月中旬开源的一个工具约束层（Tool Constraints Layer）。仓库放出来不到一周，GitHub Star 已经突破 1.4k，热度集中在一个具体数字上：在 BFCL（Berkeley Function-Calling Leaderboard）的 Multi-Step 子任务上，把 Llama-3.1-8B 从基线 53.4% 拉到了 99.1% 的工具调用成功率。
它解决的是哪一类失败
小模型在 Tool Use 上最常见的失败不是”完全不会用”，而是参数构造出错——少传字段、字段类型不对、嵌套结构丢括号。Forge 的做法是把这些错误从模型推理过程中抽出来交给一个专用的有限状态机处理：当模型输出一个 tool call 时，Forge 先用工具的 JSON Schema 做语法层校验，校验失败就把具体错误位置注入回 prompt，让模型只重写出错的那个字段，而不是从头再来。
这是一个工程层的思路，不依赖 RLHF 或者重新微调。仓库里给的 ablation 显示，去掉错误位置注入只保留通用 retry，成功率会从 99.1% 掉回 71.2%——具体到字段的反馈才是关键，而不是简单的”再试一次”。
性能账本
Forge 自己披露了几个工程指标：在单次工具调用场景下，包装一层中间层会带来约 12% 的额外延迟；多步任务里因为减少了反复重试，端到端延迟反而下降约 18%。token 开销层面，错误位置注入的平均 prompt 增量在 60 token 左右，对 8B 级别模型基本无感。
作者 Antoine Zambelli 在 README 里写得很直白：”Forge 不是要让 8B 模型变成 70B，它只是把 8B 在 Tool Use 上的稳定性问题从’模型问题’重新定义成了’编排问题’。能省的 GPU 成本还是会省。”
可复用的工程做法
Forge 真正有意思的不是 99.1% 这个具体分数，而是它示范了一种可以推广的工程姿态：当模型能力存在已知短板，与其等下一代模型，不如把短板包出去交给确定性更高的传统软件层处理。Tool Use 是这种姿态最容易落地的场景，结构化输出和长程记忆是下一批候选。这个项目对中小团队的参考价值，比对头部实验室更明显——因为头部团队会直接换更大的模型，而中小团队需要让 8B 撑起现有业务。
参考链接：
