把模型能力与代理产品效果分开评测

同一个 Qwen3-4B 智能体，模型评测拿到 42/70，没过发布门槛；接上完整产品流程后却拿到 46/70，通过了。作者追查后发现，全部增益都来自一条「别停在那里什么也不干」的规则，而他颇为得意的参数修复没有带来分数变化。

这篇案例最值得程序员借鉴的，是把模型能力、产品表现和组件贡献分开测。否则，你可能花两天优化一个根本看不到产品逻辑的指标，再把正确输出误认成自己代码的功劳。

同一个模型，为什么会有两份成绩

作者开发的是本地运行的公司注册智能体：Qwen3-4B，采用 4-bit 量化，通过 MLX 运行，调用 Lovie Formation MCP server 的 195 个工具，处理美国公司注册流程。

2026 年 8 月的评测包含 70 个流程用例，每个用例跑 3 个随机种子，使用生产环境采样设置，各评分维度以多数投票确定结果。其中 14 个核心用例作为发布门槛，至少通过 12/14。

模型评测通道直接调用 engine.generate，只评分模型发出的第一个工具调用。基线是 42/70，核心用例 11/14，因此未通过。

问题是，这条通道不运行编排器。步骤映射、支付占位符拦截、参数转换，以及作者新增的两项保护规则，都不会参与执行。作者却曾把这个分数当成产品指标，连续优化了两天。

模型评测衡量模型输出，产品评测衡量完整流程，两份成绩必须分开保存。

为此，作者增加 system-golden 产品评测通道：沿用同一组测试数据，运行真实对话循环，评分对象改成经过修复、重新提示和保护规则后，服务器实际收到的调用。

它通过 DryRunMCP 避免写入真实业务数据。工具 schema 和服务器指令取自真实端点，匿名调用 tools/list 就够用；callTool 则记录请求并返回模拟成功。测试会走到名称、地址、股东等环节，不能为了测分真的创建公司记录。

最终产品通道拿到 46/70，并通过发布门槛。原文没有给出产品通道具体的核心用例分数。这也不是模型升级前后的对比，而是同一个模型在两种测量范围下的结果。

真正挣到分数的，是一次有限重试

作者给两项保护逻辑分别加了环境变量开关：LOVIE_NO_STALL_BOUNCE 和 LOVIE_NO_ARG_REPAIR，关闭后重跑产品评测，以确认增益来自哪里。

结果很直接：从 42/70 到 46/70，全部提升来自停滞规则，也就是 stall rule。

这条规则检查助手是否既没有调用工具，也没有向用户提问。如果两件事都没做，就重新提示一次，让模型继续处理当前回合。

它有明确的失败样本支撑。在更早的 78 用例评测中，28 个基线失败里有 27 个没有调用工具；其中 14 个既不调用，也不提问。例如模型表示「我会选择 C corporation，继续吧」，随后没有任何动作。

在这个产品的任务流程里，这类回合不应被视为完成。不过，规则不能只写成一句宽泛判断。作者用测试固定了几个边界：

• 不指定下一步必须调用哪个工具，否则遇到应该展示选项的情况，可能逼模型编造参数。
• 避开合理结束，包括提问、转而询问的拒绝、工具执行后的收尾总结、普通聊天，以及调用被拒绝的情况。
• 每回合最多触发一次，第二次仍然停滞就结束，避免无限循环。

拒绝类别仍保持 8/8，作者没有观察到重新提示导致模型编造地址。这个结果支持当前测试集里的表现，但不能直接推到其他业务。

参数修复没有加分，为什么还保留

ArgumentRepair 根据工具自己的 inputSchema 整理参数，处理扁平值与包装值之间的转换、嵌套对象和数组，以及能够唯一匹配的枚举规范化，例如把 LLC 转成 ENTITY_TYPE_LLC。

它的约束是只调整模型已经给出的内容：不增加字段，不删除字段，遇到有歧义的枚举就保持原样。

可实际评测里，没有任何类别的分数变化。

作者此前做过一次冒烟测试，看到最终执行的调用包含 ENTITY_TYPE_LLC，便把它当成修复生效的证据。后来才发现，模型原本就输出了这个值，修复代码根本没有贡献。

输出正确，只能证明这次结果正确，不能证明某个中间组件起了作用。

作者仍然保留了它，理由是维护成本：过去的实现依靠一份经历线上事故后不断增长的四字段硬编码列表，现在改为从工具契约推导规则。这是代码维护上的取舍，不能包装成已经验证的准确率提升。

我的判断

我认同把发布门槛放在产品通道。用户接触的是完整产品，编排器能稳定处理的错误，应该计入产品能力；同时保留模型通道，才能判断后续训练是否真的改善了模型本身。

但 46/70 的含义需要收窄。DryRunMCP 返回模拟成功，这套评测能检查服务器收到什么调用，却无法据此证明真实工具执行、业务状态变化和最终注册结果都正确。通过 12/14 的核心门槛，也不等于其余流程已经可靠。

停滞规则尤其依赖任务边界。作者已经专门排除了普通聊天和合理收尾，一般团队不能把「不调用工具也不提问」直接设为所有助手的错误。它在这里有效，靠的是业务定义和边界测试。

原文提供了关闭组件重测的归因结果，却没有给出重复评测的波动范围，也没有比较其他重试策略。可以认可这次四个用例的增益，暂时不能认定一次重新提示就是普遍最优方案。

能拿来做什么

• 给日常 AI 编程助手同时记录模型原始工具调用和编排后实际执行的调用，用同一组任务分别评分，让模型问题与产品修复能够独立观察。
• 在 Node 编排层新增重试、参数修复或拦截逻辑时，同时提供环境变量开关，并固定测试数据与随机种子重跑，确认到底是哪段代码贡献了提升。
• 对会写入业务数据的 MCP 工具，参考 DryRunMCP 保留真实契约、记录调用、模拟返回，再另外验证真实执行链路，避免把请求正确当成业务完成。
• 保留参数修复前后的记录。即使最终调用正确，也要检查输入是否真的被修改；维护性改善与评测分数改善应分别说明。