把一项任务交给 Agent 后，它可能很快告诉你“完成了”。但结果是否正确、执行过程是否符合要求、遇到异常是否处理得当，还需要证据来判断。
本文面向初次接触 Agent 评测的同学，通过私人助理小明的出行故事和户型改造案例，介绍 Agent 的基本概念，以及如何设计评测用例、解读结果，并用评测支持版本比较和业务决策。
后续文章将介绍如何使用评测平台开展实际评测。
假设小明是你的私人助理，也负责开车接送。今天早上，你告诉他：
我要从家里出发，上午 10 点前到杭州西湖的指定入口。请安排路线，开车送我过去，尽量少花时间。
小明先确认具体入口和可以出发的时间，再查询路况、比较路线，安排出发。他记得你偏好少走路，因此也会考虑停车点与入口的距离。
途中遇到堵车，他重新查看路况、调整路线，并告知新的预计到达时间；如果已经无法按时到达，就及时说明，与你确认后续安排。最后，他把你送到约定地点。
你交给小明的是目标，由他组织行动、使用工具，并根据实际情况调整。小明就是这个故事里的 Agent。
Agent 是能够围绕目标，自主决定下一步行动，使用工具执行，并根据反馈调整的智能系统。用小明的故事，可以理解几个常见概念。Memory 中的信息也要结合当前情况核实，过去的路线经验不能代替最新路况。
各产品的实现不同，不一定具备上述全部组件。模型提供理解与决策能力，程序则组织工具、信息和执行流程，共同推进任务。
AI Agent 也可以使用工具完成查资料、处理数据、修改设计方案等任务。评测范围要与产品能力一致：
不能把“声称完成”当成“已经完成”。
小明说“送到了”，我们仍需要检查三个方面。
Agent 评测，就是在约定条件下让 Agent 执行任务，收集结果和过程证据，再按事先确定的标准判断它做得怎么样。 除了验证是否达标，评测也可以用于版本改进、方案选型和竞品对标。
评测标准要结合场景。正常路况下要求按时送达；客观上无法按时到达时，应检查它是否如实说明限制、提供合理替代安排。
断言用于检查要求，是否阻断通过需要提前约定。Rubric 是“按什么评”，Judge 是“由谁或什么来评”。
常见的评判方式有三类，可以根据检查项组合使用。
一条 Case 可以同时使用三类方式：规则检查时间，模型评价说明质量，人工复核争议。被测 Agent 和负责评分的 Judge 是不同角色，Judge 本身也需要验证。
明确目标与标准 → 设计 Case 并组成 Suite → 执行 Trial → 采集证据 → 判断结果 → 归因与改进 → 回归验证。
同一条 Case 可以运行多次，同一个 Suite 可以用于比较不同版本或候选方案。前提是记录清楚 Agent 版本、工具与环境条件、评测集和评分规则版本，避免把测试条件变化误认为能力变化。
以出行中的路线规划环节为例，评测 Agent 能否给出满足要求的方案。
原始需求是：
从家里出发，上午 10 点前到西湖指定入口，尽量少花时间。
设计用例时，先把模糊的要求写清楚：
先定义什么算成功，再让 Agent 执行。
假设地图工具固定返回以下三个候选方案（教学模拟数据）：
现在，就可以把需求写成一条评测用例：
将这条 Case 交给 Agent 执行一次，就得到一个 Trial。假设它回答：
推荐 B 路线。09:10 出发，驾驶 30 分钟、停车 5 分钟、步行 5 分钟，预计 09:50 到达。总行程 40 分钟，是三个候选中最短的方案。
不能只看“25 分钟驾驶”就认定它最快。
本例用规则核对候选路线、总耗时和到达时间，用模型或人工评价说明是否清楚；出现争议时再复核。各项判断标准都应在执行前约定。
一条正常用例还不够。围绕同一目标，补充条件变化，就能逐步形成评测集。
为每个场景写清条件和期望行为，再执行、留证、判断。用例数量之外，更要看重要场景是否得到覆盖。
先确认是否有足够证据判断，再检查要求是否满足：
证据不足或存在争议时，单独标记“无法判断／待复核”，不要默认通过。
工具报错也不一定是 ERROR：如果用例本来就在测试工具异常，就应判断 Agent 的应对是否合格。异常先归因，再决定修复、补跑还是改进 Agent；补跑后也要保留首次记录。
一组结果不能只看平均分，需要结合三个问题：
- 质量是否满足要求？
- 表现是否稳定？ 同一关键用例重复运行，是否经常得到不同结果？一次通过不能证明一直可靠。
- 耗时与成本是否可接受？ 任务完成了，但反复调用工具、耗时过长，也可能不适合业务使用。
报告通过率时，要写清哪些运行计入分母；计算平均分时，要注明可评分样本数。错误和待复核项应单独展示，不能从报告中消失。评测还要回答：相比旧版，提升了多少、哪些地方退化？相比其他方案或竞品，优势与差距在哪里？
以一组模拟结果为例：同一组 100 条用例上，旧版通过 70 条，新版通过 82 条，通过率提升了 12 个百分点。
逐条对比可能发现：
改善：17 条原先失败的用例变为通过。
退化：5 条原先通过的用例变为失败。
如果这 5 条涉及关键业务，就不能只看总体提升。
比较时，重点关注：
- 提升与退化：哪些任务变好，哪些任务变差，是否涉及关键场景。
- 稳定性与开销：改善能否重复出现，是否伴随明显增加的耗时和成本。
- 条件是否可比：用例、工具环境、评分标准是否一致；条件变化较大时，先对齐口径或重跑基线。
版本比较通常以线上版本或上一版本为基线，选型和对标则比较候选方案或竞品。只能观察部分能力时，应明确比较范围。历史多轮结果有助于判断改善是否持续。有提升不等于已经达标，总体变好也不能掩盖关键场景退化。
某户型改造 Agent 可以根据设计师的要求，调用设计工具完成拆墙、调整门窗、修改房间等操作。一轮评测包含 54 条用例，结果如下：
8 条执行错误，需要先定位原因。
应结合日志确认是平台、依赖、Agent 还是评分器的问题。基础设施异常修复后补跑；Agent 自身循环或异常处理不当，则按约定记录为能力问题。补跑不能覆盖首次记录。
82 分仍然失败，因为关键要求没有满足。
一条用例总分为 82 分，但关键状态检查未通过，视觉质量也低于门槛。户改任务中，目标墙未删除、非目标门窗被误改、产物无法继续编辑，都可能触发阻断。高分不能抵消这类问题。
200 毫米墙厚，需要读取结构化数据。
图片可以判断空间布局和整体变化，却难以稳定确认墙厚是否为 200 毫米。这类精确要求应读取结构化字段，统一单位并约定容差；视觉评测用于补充检查布局与非目标区域变化。
质量得分 94 分，但单次消耗了 250,317 Token。
该用例质量判定通过，但占本批已记录 Agent Token 的 44.56%。应结合任务复杂度、上下文长度和调用轨迹，检查是否存在重复规划或无效重试。质量通过不代表成本可接受，实际费用还需按模型和工具的计费规则计算。
发布门槛应在评测前约定，结合业务风险和使用范围，至少明确以下内容：
这轮户改评测还需完成错误归因、关键失败复核和成本排查，补充历史对比与回归结果，再对照门槛形成发布建议。
将重要问题对应到 Case、执行轨迹和业务影响，修复后复验，再把代表性场景加入回归集。确实需要修改用例或评分规则时，记录业务依据与版本，并重新评估受影响的结果。
Agent评测最终要帮助团队回答：它能否满足业务要求，相比历史版本、其他方案或竞品有哪些优势与差距，质量、可靠性和成本是否可接受，以及下一步应如何选择、改进和使用。
Agent 评测不是一次性的"考试"，而是贯穿 Agent 能力演进全过程的持续验证机制。从最初把模糊需求写清楚，到设计覆盖正常与异常场景的用例集，再到执行、判分、归因、改进和回归——每一步都在帮助团队把"感觉它还行"变成"有证据证明它在哪些场景下能做到什么程度"。
对业务决策者而言，评测报告的价值不在于一个通过率数字，而在于它能回答三个核心问题：当前版本是否满足业务红线、相比历史版本或竞品究竟提升了什么又退化在哪里、质量和成本的平衡点是否可接受。无论你是刚开始接触 Agent 的产品经理、QA 工程师，还是需要为上线决策拍板的业务负责人，建立一套可重复、可对比、可追溯的评测体系，都是让 Agent 从"能用"走向"可靠"的必经之路。
