🔧 不是越大越好——2B小模型配好"框架"竟能碾压大模型裸跑

费曼曾说："一个理论的优雅不在于它有多复杂，而在于你用多简单的前提解释了多复杂的现象。"今天要讲的发现恰好翻转了这句话——有时候，把一个简单的东西包装得体，它能爆发出远超你预期的力量。

引子：小而精，还是大而笨？

过去两年，AI 领域的叙事一直是"大力出奇迹"。GPT-4 有 1.7 万亿参数，Claude 有几千亿。似乎参数越多，智慧越高。

但一篇刚刚发表的实验论文给出了一个反直觉的结论：对于操作型任务，2-3B 参数的小模型配上一个精心设计的"执行框架（harness）"，可以媲美甚至超越裸奔的大模型。 关键不在模型的"脑子"多大，而在你给它穿的"盔甲"多好。

第一章：三个框架的对比实验

研究者设计了一个巧妙的实验。同一个小模型（2-3B 参数），三种不同的框架：

条件一：裸跑（Model-Only）

直接给模型一个提示词，期待它返回正确格式的结果。没有框架，没有纠错，全靠自己。

条件二：轻壳（Minimal-Shell）

在提示词外加了一层轻薄的包装——加了一些 XML 标签来标记输入输出的边界。比裸跑多一层格式约束。

条件三：四阶段流水线（4-Stage Pipeline）

一个精心设计的执行框架，包含四个阶段：

1. Plan（规划）：让模型先"想清楚"要做什么，输出一个执行计划
2. Execute（执行）：按照计划逐步执行
3. Verify（验证）：检查执行结果是否符合预期，是否符合格式要求
4. Recover（恢复）：如果验证失败，自动回溯、修正、重新执行

第二章：出乎意料的结果

24 个操作型任务上的测试结果：

两个最重要的发现：

发现一：轻壳反而更差

最反直觉的是——给模型加轻壳（minimal-shell，加格式标签）后，成功率不升反降。出现了"非单调现象"（non-monotonic phenomenon）。这意味着：半吊子的框架比没有框架更糟糕。 要么不做，要做就做完整——四阶段的完整流水线。

发现二：小模型 + 好框架 ≈ 大模型裸跑

一个 Gemma4 2B 加上四阶段流水线，在 21 个任务上达到了 95.2% 的成功率。有效输出（格式正确 + 内容可验证）的成功率是 100%。Bare model 只有 42.9%——而且不仅仅是输出质量差，而是连格式都崩溃了——LLaMA 3.2 3B 在复杂格式要求下直接放弃了 JSON 格式。

第三章：为什么框架比模型大小更重要？

"脚手架崩溃"

论文提出了一个叫**脚手架崩溃（Scaffold Collapse）**的概念：当模型的输出格式要求复杂时（比如要求返回特定结构的 JSON），缺乏外部框架支撑的模型会在高认知负荷下放弃格式约束——直接输出自由文本，导致整个任务的流水线断裂。

四阶段流水线通过"验证+恢复"阶段解决了这个问题：即使模型在某一步崩溃了，框架会检测到格式错误，自动回退，让模型重新生成。

消融实验：每一步的贡献

论文做了消融实验来衡量四个阶段的各自贡献：

• 规划阶段贡献了约 24.7% 的总增益
• 恢复阶段也贡献了约 24.7% 的总增益
• 验证捕获率（VCR）= 0.625——62.5% 的错误在验证阶段被捕获

规划 + 恢复 = 一半的增益。 这说明小模型的短板不是"不会做"，而是"不会规划做事的顺序"和"做错了不知道怎么修"。

第四章：工程哲学——"模型是引擎，框架是底盘"

这篇论文的洞见可以概括为：

一个大模型裸跑，就像一个装了大马力引擎但没有方向盘和刹车的车——直线加速很快，但一转弯就撞墙。

小模型加上好的执行框架（规划、验证、恢复），就像一个装了中等引擎但有四轮驱动、防抱死刹车和车道保持系统的车——马力小，但稳定性高得多，最终到达目的地的成功率也高得多。

这颠覆了 AI 领域的一个隐性假设："要更可靠，就得更大的模型。" 这篇论文用数据说：不一定。在操作型任务（需要多步执行、格式约束、错误恢复）中，框架设计的优先级应该高于模型规模的扩展。

论文信息

• 标题: It's Not the Size: Harness Design Determines Operational Stability in Small Language Models
• 作者: Yong-eun Cho
• arXiv: 2605.12129
• 核心发现: 四阶段流水线（Plan→Execute→Verify→Recover）让小模型达到0.952成功率

#小模型 #执行框架 #流水线设计 #AI工程 #任务可靠性 #费曼风格 #智柴外脑