用 world-model-optimizer 把大模型推理路径蒸馏到轻量化 Agent 的实操心得

最近在优化 Agent 运行成本时发现，单纯靠 Prompt Engineering 已经触碰到天花板了。在很多实际业务场景中，我们习惯性地调用 Claude 3.5 或 GPT-4o 这种 Frontier 级别模型，但复盘后发现 80% 的任务逻辑其实非常固定，用 7B 甚至更小的模型完全能跑通。

很多人的第一反应是做微调（Fine-tuning），但实操下来效果往往不佳。因为传统的微调关注的是结果分布，而 Agent 场景最核心的是“推理路径”。如果小模型只学会了模仿最终答案，在面对稍微变化的输入时，很容易出现逻辑崩坏。最近我尝试了开源工具 world-model-optimizer，它的核心逻辑不是让小模型去“模仿”答案，而是通过蒸馏大模型的推理路径（Reasoning Path），让轻量化模型在特定场景下接管任务。

整个实操工作流分为三个阶段，这里分享一些细节。

首先是构建模拟环境。这是最关键的一步，因为如果没有验证集，你根本不知道小模型在接管任务后是否出现了逻辑偏差。我使用了 wmo build 命令，其核心逻辑是利用已有的 Agent 运行轨迹（Traces）作为信号。简单来说，就是把之前由大模型成功执行的任务记录提取出来，搭建成一个模拟环境。这样在后续优化阶段，我们可以通过对比实际输出与 Traces 记录的差异，量化模型能力的损耗，而不是靠体感来判断。

接下来的第二步是执行模型优化，运行 wmo optimize。这个过程在底层其实同时完成了三件事。第一是 CoT（思维链）的蒸馏，将大模型在处理复杂任务时的中间推理步骤传递给小模型，让它学会“如何思考”而非直接给答案；第二是训练一个路由（Router）机制，决定请求的分发逻辑；第三是进行 Token 压缩（Compaction），去掉推理路径中的冗余噪音，提高推理效率。

最后一步是部署服务。通过 wmo serve 启动端点后，后端会形成一套动态路由机制。此时的架构变成了：请求进入 → 路由判断 → (简单任务 → 优化后的小模型) / (复杂任务 → Frontier 模型)。

这种方案最核心的价值在于解决了 Agent 规模化部署时的成本痛点。在实际测试中，如果将特定领域的推理逻辑蒸馏到 7B 规模的模型中，响应速度会有质的提升，且在保证成功率的前提下，API 成本能降低一个数量级。对于那些需要频繁调用工具、处理大量重复逻辑的 Agent 场景，这种“大模型带小模型”的路由方案比全量调用昂贵模型要高效得多。