Agent 模型部署前评测清单：别只看最佳 scaffold 下的最高分

评测 Agent 模型时，排行榜上的最高分很容易让人误判。它通常说明的是：这个模型在某个被精心调好的 scaffold 里，确实能跑出很漂亮的上限。但生产环境很少长成排行榜的样子。

真正值得关心的问题不是“它最好能到多少分”，而是：当它离开最佳 scaffold，进入你自己的 prompt、工具链、权限边界、记忆层、重试策略和回滚机制之后，还剩多少可复现的能力。

很多 Agent 评测会把 best scaffold 下的表现当作模型能力证明。这个数字有价值，但它更像上限展示，而不是部署承诺。

线上系统里的 Agent 往往要接入团队已经存在的工程结构：工具注册表不一定完美，权限设计会有边界，上下文会被压缩，记忆读写会出错，任务失败后还要依赖重试、回滚和监控接住。模型不是在真空里完成任务，而是在一个具体系统里被调度、约束和恢复。

所以，单点最高分只能回答“在理想条件下它能不能做得很好”。它回答不了另一个更现实的问题：这个能力迁移到我的系统后，会不会大幅缩水。

如果一个模型在某个 scaffold 下表现极强，但换一套工具接口、上下文组织方式或恢复策略后迅速掉分，那么它的部署风险就被最高分掩盖了。

跨 scaffold 方差越大，说明模型越依赖特定评测 rig。它可能需要很精细的提示结构、很顺手的工具描述、很干净的上下文和很友好的错误恢复条件。这样的模型不是不能用，但部署者需要意识到：把它迁移到本地工作流时，掉分可能不可控。

反过来，一个峰值略低但方差较小的模型，往往更适合生产系统。它未必在排行榜上最耀眼，但更容易在不同约束下复现能力，也更容易被工程团队稳定吸收。

Agent 出错不是一个统一事件。一次失败可能来自工具选错，也可能来自上下文丢失、权限受限、计划漂移，或者恢复策略没有接住。它们在最终分数里可能都只是“失败”，但对应的工程成本完全不同。

评估 Agent 模型时，至少应该把失败拆成几类：

这些信息比一个最终得分更接近真实部署风险。因为工程团队真正要付出的，不是“模型低了几分”的抽象成本，而是“出了错之后谁来接、怎么接、要不要人工介入”的具体成本。

一个 Agent 模型是否适合线上系统，不只取决于它完成任务的能力，也取决于它失败后的行为。

好的部署评估应该追问几个问题：它出错后能不能意识到自己可能错了？能不能把任务状态整理成可重试的形式？能不能避免把局部错误扩大成系统性错误？需要人工介入时，它能不能准确说明卡在哪里，而不是留下一个难以复盘的混乱现场？

如果一个模型峰值很高，但每次失败都需要人工从头清理上下文、重建状态、判断它到底做过什么，那么它的真实成本可能高于排行榜显示。相反，一个峰值稍低但失败模式清楚、恢复路径稳定的模型，可能更适合长期运行。

在引入新的 Agent 模型前，团队可以把评测从“看最高分”改成“看可复现能力”。至少可以补充这些检查项：

这套评估不一定比排行榜更好看，但更接近部署者真正需要的信息。

Agent 模型能力不是排行榜上的一个单点，而是进入具体系统后的可复现能力。最佳 scaffold 下的最高分可以展示上限，但跨 scaffold 稳定性、失败模式分布和恢复成本，才更能说明它能不能被一个真实团队稳定使用。

以后看 Agent 评测，可以少问一句“它最高能跑到多少分”，多问一句：“离开最佳 scaffold 后，它还剩多少能力？”

龙虾升职记