用真实 Agent 轨迹微调 35B 模型，小模型低成本追上大 Judge

LangChain 和 Fireworks 的实验给出了一个清楚的信号：用真实 Agent 运行轨迹微调 35B 模型，已经能在 Agent 输出评估这类任务上追平甚至超过更大的前沿 Judge，同时把推理成本压得很低。

窄任务追平大模型，数据成了新壁垒

他们拿 Qwen-3.5-35B，用两个 Agent 产品里的多轮交互 trace 做训练。标注不是全靠模型，而是模型辅助加人工复核，重点抓错误信号。结果显示，微调后的 35B 模型评估 Agent 输出时能跟更大 Judge 直接竞争，推理成本却明显更低。

这类评估任务本来就适合专门化模型。它核心不是开放域推理，而是识别 Agent 和用户、工具、上下文之间的交互模式。通用大模型带了太多这个任务用不上的能力和成本。

有生产 trace 的团队，优势开始具体起来

| 市场常见判断 | 实验数据说明 | 思考方式的变化 | 实际影响 | |---|---|---|---| | 开源模型可以在窄任务上缩小差距 | 35B 模型只靠 chat-langchain 和 Fleet 的 trace，就追平了前沿 Judge | 研究团队会重新想：是不是每个评测都得调用最大模型 | 专门化模型会加速 Agent 可观测性建设，直接冲击 API 成本高的服务商 | | 对评估模型来说，数据质量比参数规模更关键 | 通过过滤和混合标注，在 18–24% 正向错误率下形成了相对可靠的 ground truth | 公司会更重视沉淀自己的生产 trace，而不是单纯换模型供应商 | 拥有真实用户反馈闭环的平台，会建立研究实验室难复制的长期优势 | | 成本下降会改变监控范围 | 在生产 trace 上，推理成本最高能降低 100 倍 | 小团队也开始负担得起全量 trace 监控 | Fireworks 这类推理层会从纯模型构建方手中分走更多价值 | | 泛化结论仍需要跨领域验证 | 研究用来自两个不同 Agent 产品的 holdout set 检查迁移效果 | 单一环境下的 Judge 结果会受到更多审视 | 好用的错误检测器会逐渐变成基础设施，而不是单独的护城河 |

• 生产 trace 越多，Judge 越容易变强；Judge 越强，又越能挖出可迭代的高质量信号。
• 继续依赖前沿模型 API 做 Judge 的团队，会一直背着累积的成本劣势。
• 训练中即使跳过 tool call，用户和助手之间的交互模式本身也已经带了关键错误信号。

单看 benchmark 分数，容易低估真正发生的变化：价值正在从通用大模型规模，转向基于特定领域数据的蒸馏和专门化。

现实结论很简单。已经拥有生产 trace 并具备微调能力的团队，会更快提升 Agent 可靠性；而继续追无差异化的参数规模，在这种成本结构下吸引力明显下降。

Verdict: 这条叙事对已经有真实 Agent 流量和生产 trace 的 builder 还偏早，对纯交易者和被动持币者基本没关系；真正占优的是拥有用户闭环、能持续收集 trace、并把数据转成评估模型的产品团队和基础设施团队。