比较 AI 智能体，演示里顺利完成一次任务，并不等于它能稳定胜任日常工作。更有参考价值的横向评测，应让不同工具在相同任务、数据、权限和评分标准下反复运行，并同时记录任务结果、人工接管、耗时与总成本。这样得到的不是一张脱离场景的排行榜，而是一份可复核的选型依据。
先定义要测的工作，而不是先挑指标
测试任务应来自真实流程：有明确输入、实际约束和可检查的结果。例如，整理一批资料并按指定字段生成表格，或根据订单记录归类问题并完成规定的后续操作。不要只写“处理客户问题”这类宽泛要求；应说明资料范围、输出格式、允许使用的工具、禁止执行的操作，以及哪些结果算合格。
可把任务分成三类：
- 常规任务：输入完整、步骤较少，用来观察基本执行能力。
- 边界任务：资料缺失、指令含糊或工具返回异常，用来观察智能体会否追问、重试或安全停止。
- 高风险任务：涉及发送信息、修改记录或触发外部操作，用来检验权限控制与人工确认机制。
每个测试用例都应保存原始输入、环境状态、工具权限、预期结果和评分规则。涉及企业数据时，优先使用脱敏数据或可控测试环境，避免让测试本身造成真实业务影响。
把条件固定下来，让结果可复现
横向测试容易失真的原因，往往不是指标太少，而是不同工具面对的条件不一样。正式测试前，先固定任务文本、数据版本、可用工具、权限范围、超时时间和运行环境；记录测试日期、产品版本及关键配置。若产品无法提供相同模型或参数设置，也应把差异写入报告，避免把环境差异误当成智能体能力差异。
单次运行只能说明一次表现，不能说明稳定性。对同一任务进行多次独立运行，保留成功、失败和异常中断记录，并分别报告结果。不要只挑最好的一次，也不要在看到失败后临时改任务，却不对其他产品做同样调整。
智能体是由模型、工具调用、流程编排和状态管理等部分共同构成的系统，因此评测应检查完整任务链，而不只是最后生成的文字。InfoQ 关于智能体评估的实践讨论也指出，单轮文本指标难以覆盖智能体在真实环境中的动态行为。参考：InfoQ：AI 智能体实践评估。
任务完成率要看“是否达标”，不只看“有没有输出”
建议在测试前为每项任务写好验收标准，并区分必要条件与加分项。比如，必要条件可以是字段完整、数据准确、操作未越权；表达清晰或排版整齐则可作为质量评分项。这样能避免把“生成了一份看似完整的答案”误记为任务成功。
一个简单的统计口径是：
任务完成率 = 达到预设验收标准的运行次数 ÷ 总运行次数
报告时应同时说明“成功”的判定规则、总运行次数和失败类型。若部分完成也有业务价值，可另列“部分完成率”，但不要把部分完成和完整成功混为一谈。对于需要人工复核才能交付的结果，还应报告复核后通过的比例，而不是只统计智能体自报完成。
评分可以分层：先判断关键结果是否正确，再检查完整性、格式、可追溯性和安全边界。对于可程序化核验的内容，尽量用固定规则检查；对需要人工判断的部分，采用统一评分表，并由评审者依据相同标准打分。涉及判断分歧时，应保留分歧记录，而不是只给出一个没有说明的总分。
人工接管要记次数，也要记原因和投入
“人工接管”需要先定义清楚。人工补充信息、纠正错误、批准高风险操作、手动完成未完成步骤，都可能属于接管，但它们的业务含义不同。建议至少记录：
- 接管发生的时间和任务环节；
- 接管原因，例如信息不足、工具失败、结果错误或需要权限确认；
- 人工采取了什么动作；
- 人工实际投入的时间；
- 接管后任务是否完成，以及是否仍需复核。
可以报告每次运行的平均接管次数、发生接管的运行比例，以及人工处理时间。若某类接管是企业主动设置的安全确认，不宜简单视作智能体失败；应与因智能体错误或流程卡住导致的接管分开统计。这样才能看清人工介入是必要的治理环节，还是额外的返工负担。
成本比较要覆盖一次任务的完整链路
只比较模型调用费用，容易低估使用成本。实际评估时，可按单次任务统计以下项目：
- 模型及工具调用费用；
- 重试、失败运行和额外调用产生的费用；
- 平台、部署或运行环境的分摊成本；
- 人工接管、复核和修正所需的人力成本。
可以用统一公式估算：
单次任务总成本 = 调用与运行费用 + 人工处理成本 + 复核修正成本
计价口径要写明，例如人工成本采用企业内部的哪类工时标准，固定费用按什么周期或任务量分摊。若暂时无法可靠估算某一项，应单独披露，不要把它当作零成本。
耗时也要拆开看：记录从开始到交付的总历时，同时记录智能体运行时间和人工处理时间。总历时反映业务等待体验，人工时间反映员工投入，两者不能互相替代。测试中若包含排队、接口等待或外部系统响应，也应说明是否计入，确保不同产品的比较口径一致。
用综合结果辅助决策，不让单项排名替代采购判断
建议用一张评测表同时呈现任务完成率、结果质量、稳定性、人工接管、总耗时和单次总成本，并标注测试条件与主要限制。不要把所有维度过早压成一个总分：权重不同，排名就可能不同。对管理者而言，关键是这些权重是否贴合本企业的流程风险与预算；对产品经理和开发者而言，失败类型往往比总分更能指出下一步该改什么。
AWS 的智能体质量评估实践将任务完成、决策准确性、效率和安全性等纳入评估视角，可作为构建多维指标表的参考：AWS：Agent 质量评估。但任何框架都需要结合具体任务调整，不能仅凭指标名称判断某个工具适合生产部署。
【软盟资讯观察】
趋势判断：智能体评测的重点正在从“能否生成答案”转向“能否在约束下完成流程”。对企业来说，结果质量、工具调用、权限边界和人工复核需要放在同一条任务链中观察，评测才更接近实际使用。
机会与风险：可复现的任务集能帮助团队发现流程中的高频瓶颈，也能让采购比较从功能演示转向业务验证。但测试环境与生产环境往往存在差异，短期表现不应直接外推为长期稳定性；数据权限、操作风险和异常处理也不能被低成本或高完成率掩盖。
冷思考：综合评分看起来便于排序，却可能隐藏不同维度之间的取舍。对低风险任务，速度和成本可能更重要；对涉及外部操作或关键业务记录的任务，安全确认与可审计性可能更重要。评测结果应帮助组织提出更好的采购问题，而不是替组织做出采购结论。