Agent 评测不是模型考试，而是系统验收

很多关于 Agent 的讨论，最后都会回到一个看似简单的问题：这个模型够不够强？

但在真实生产里，Agent 的失败往往不是单个模型“不够聪明”。它可能来自脚手架设计、上下文保留、工具证据吸收、工作区依赖、客户端差异、权限边界和运行环境。继续只盯模型榜单，很容易低估真正的风险。

Agent 评测如果只像模型考试，就会把系统问题误读成模型问题。更合理的方式，是把它当成上线前的系统验收。

榜单分数不能直接等于生产可靠性

模型榜单有价值，它能帮助团队理解模型在特定任务集、特定提示方式和特定评测 harness 下的能力边界。但榜单分数不能直接推出生产可靠性。

生产里的 Agent 不是在一个干净、静态、理想化的题库里答题。它要面对真实账号、真实权限、真实网络、真实工具、真实代码库，以及会不断变化的上下文。任务可能失败，工具可能延迟，检索结果可能不完整，工作区里也可能有历史约定和隐藏依赖。

这些因素一旦进入链路，评测对象就不再是“模型本身”，而是模型与运行系统的组合。

如果一个 Agent 在 benchmark 中表现很好，但评测没有记录它的配置、工具契约、上下文策略和工作区依赖，那么这个分数只能说明它在某条被包装过的路径上跑通了任务，不能说明它能稳定迁移到生产。

工具调用成功不代表证据被吸收

Agent 系统里有一个常见假象：工具调用链跑通了，就以为 Agent 正确使用了工具。

实际并不一定。Agent 可能调用了搜索、读取了文件、拿到了测试结果，却没有让这些证据改变下一步决策。它仍然沿着原先的判断继续行动，只是中途多了一次工具调用记录。

所以评测不能只看“有没有调用工具”，还要看“工具输出是否改变了行为”。

比如，一个代码 Agent 运行测试后，如果测试失败，它是否能定位失败原因、调整修改策略，并避免重复提交同一类错误？一个浏览器 Agent 看到页面状态变化后，是否会更新自己的下一步操作，而不是继续点击不存在的按钮？一个检索型 Agent 拿到新证据后，是否会修正答案，而不是把证据当成装饰性的引用？

这类能力可以称为工具证据 uptake。它不是工具可用性的测试，而是证据进入决策链路的测试。

工作区依赖是隐藏变量

很多 Agent 评测会弱化工作区本身的影响，但工作区往往是决定成败的关键变量。

真实项目里，代码结构、配置文件、文档、历史决策、命名习惯、目录约定、已有脚本和团队偏好，都会影响 Agent 表现。一个 Agent 能否完成任务，不只取决于模型是否理解自然语言，也取决于它是否学到了项目里的实际依赖关系。

这也是为什么同一个模型，在不同工作区里的表现可能差很多。它不是换了题目，而是换了系统环境。

因此，Agent 评测需要记录工作区依赖图：它读了哪些文件，依赖了哪些配置，使用了哪些脚本，采纳了哪些历史约定，哪些上下文被保留，哪些上下文被淘汰。没有这些记录，失败很难复现，成功也很难解释。

测试环境可能制造虚假确定性

本地模拟器、测试浏览器和理想化客户端能提高调试效率，但也可能制造虚假确定性。

在测试环境里，账号权限可能已经准备好，网络状态更稳定，页面结构更可控，工具输出更干净，失败路径也更少。Agent 在这样的环境里表现稳定，并不代表它进入真实客户端后也会稳定。

真实环境会带来更多分布差异：登录态过期、权限不足、接口限流、页面加载延迟、文件状态变化、并发写入、外部服务波动。这些问题不是模型升级就能自动消除的，它们属于系统验收的一部分。

如果评测刻意抹平这些差异，团队会得到一个漂亮但脆弱的结论：Agent 看起来已经可用，直到真实用户、真实数据和真实权限进入链路。

更强模型不能替代系统修复

换更强模型当然可能带来提升。它可能更会推理、更会补全上下文、更能处理复杂指令，也更能从混乱信息中找出线索。

但更强模型不能自动修复脚手架、检索链路、状态记录和工具契约的问题。

如果 retrieval pipeline 把关键证据排在后面，模型再强也可能读不到；如果上下文淘汰策略把历史决策删掉，模型再强也只能重新猜；如果工具输出没有结构化进入决策，模型再强也可能把它当成普通文本；如果状态记录不完整，失败就很难定位。

把所有问题都归因于模型能力，会让团队错过真正应该修的系统层。

把 Agent 评测改成系统验收

更有价值的 Agent 评测，至少应该记录四类东西。

第一是配置向量：这次 Agent 在什么模型、提示词、工具版本、权限范围、上下文策略和运行参数下工作。没有配置向量，分数就缺少可复现性。

第二是工作区依赖图：Agent 依赖了哪些项目知识、文件结构、配置和历史约定。没有依赖图，就很难判断成功来自通用能力，还是来自某些隐含上下文。

第三是工具证据 uptake：工具输出是否真的改变了下一步判断和行动。没有这个维度，工具调用链再完整，也可能只是表面跑通。

第四是真实环境差异：测试环境和生产环境有哪些差别，包括账号、权限、网络、客户端、数据状态和外部服务。没有这个对照，评测结果就很容易被误迁移。

Agent benchmark 不该只回答“模型会不会做题”，而应该回答“这套系统能不能上线”。分数可以是入口，但不能是终点。真正可靠的 Agent 评测，要把模型、脚手架、工具、上下文和环境放在一起看；否则，越精确的分数，越可能给团队一种错误的确定感。