1. 为什么"评测问题清单"比评测报告更值得先要

企业采购 Agent 这件事，过去两年我参与过七八轮，从最初被 vendor 的 demo 惊艳到后来被 POC 结果打脸，中间踩的坑基本都指向同一个根源：我们在错误的阶段问了错误的问题。大多数团队拿到 vendor 的评测报告，看到"任务完成率 92%""平均响应 1.8 秒"这类数字就心动，但真正上线三个月后才发现，那些数字是在 vendor 精心挑选的 50 条测试用例上跑出来的，而你的业务场景里全是长尾。

所以这篇东西不是教你怎么读评测报告，而是教你在签合同之前，该拿哪 10 个问题去拷问 vendor。这 10 个问题覆盖了评测方法论、数据集构成、指标定义、失败归因、成本模型、安全边界、可复现性等维度。适合正在做 Agent 选型的技术负责人、AI 平台架构师、以及被老板要求"两周内给出选型结论"的倒霉蛋。

我先说一个反直觉的结论：vendor 给你的评测分数，参考价值不超过 30%。真正有价值的是你问出这 10 个问题后，对方回答时的犹豫、含糊和转移话题——那些地方才是产品真实的软肋。下面逐个拆。

2. 问题一：你们的评测数据集是怎么构造的，能不能给我看采样分布

这是所有问题的起点，也是最容易被 vendor 用"商业机密"搪塞过去的一个。但你必须坚持，因为数据集的构造方式直接决定了评测分数的含金量。

2.1 自建数据集 vs 公开 benchmark 的陷阱

很多 vendor 会告诉你"我们在 GAIA、SWE-bench、AgentBench 上都跑过"。听起来很权威，但你要追问的是：这些公开 benchmark 和我的业务场景重合度有多少。GAIA 偏通用助理任务，SWE-bench 偏代码修复，如果你的场景是保险理赔单据审核，这两个 benchmark 的分数基本没有迁移性。

我见过一个 vendor 拿着 SWE-bench 78% 的分数来卖"企业级 Agent 平台"，结果客户是做合同审查的，POC 一跑完成率不到 40%。这不是 vendor 撒谎，是 benchmark 选错了。

2.2 采样分布必须问清楚的四个维度

你要让 vendor 给出评测集的采样分布，具体到：

提示：如果 vendor 说"数据集是内部资产不能外泄"，你可以退一步要求他们提供脱敏后的采样统计报告，包括每个维度的条数、分布比例、以及 3-5 条脱敏样例。连这个都给不出来的，基本可以判定评测是拍脑袋的。

2.3 一个真实的对比案例

去年我帮一家做跨境电商客服的团队选型，两家 vendor 都报了"任务完成率 90%+"。我让他们各自提供采样分布，结果 A 家的评测集里 70% 是单轮问答类任务，B 家是 55% 多轮工具调用任务。实际 POC 时，A 家在多轮场景下完成率掉到 52%，B 家保持在 81%。同样的 90%，含金量差了一倍。

3. 问题二：你们的"任务完成率"到底怎么定义的

这是最容易被文字游戏坑的地方。几乎每家 vendor 都会报"任务完成率"，但定义千差万别，你必须逼他们给出精确的判定标准。

3.1 三种常见的完成率定义及其水分

我把见过的定义归成三类：

• 严格匹配：Agent 的最终输出和标准答案完全一致（或经过规则归一化后一致）。这种最实，但分数通常最低。
• LLM-as-Judge：用另一个大模型来打分判断任务是否完成。这种水分最大，因为 judge 模型的宽松度可以直接调。
• 人工抽检：人工标注一部分判断完成情况。这种最贵，vendor 一般只在关键客户上做。

你要问的是：你们用的是哪一种，如果是 LLM-as-Judge，judge 模型是什么，prompt 是什么，有没有做过 judge 和人工标注的一致性校验。

3.2 部分完成怎么算

真实业务里，一个任务往往是部分完成的。比如"帮我把这份合同里的风险条款标出来并生成报告"，Agent 标出了 8 条风险中的 6 条，报告也生成了但格式有误。这算完成还是没完成？

如果 vendor 的定义是"只要生成了报告就算完成"，那这个分数就是虚的。你要追问：有没有部分完成（partial completion）的评分机制，权重怎么分配。一个成熟的评测体系应该有细粒度的评分，而不是二元的成功/失败。

3.3 追问话术模板

我一般会这样问：

"假设一个任务需要 5 步，Agent 完成了前 4 步，第 5 步调用了错误的工具但最终输出看起来是对的。在你们的评测里，这个 case 算完成吗？请给出你们判定逻辑的具体规则。"

这个问题 vendor 很难糊弄，因为一旦给出规则，你就能判断他们的评测严谨度。

4. 问题三：失败案例的归因分析能不能给我看

只看成功率的评测报告都是耍流氓。真正能反映 Agent 能力的，是失败案例的归因分布。这个问题能问出 vendor 对自家产品的理解深度。

4.1 失败归因应该分几类

一个合格的失败归因体系至少应该区分：

1. 规划失败：任务拆解错了，方向就偏了
2. 工具调用失败：选错工具、参数错误、工具返回异常没处理
3. 上下文丢失：多轮对话中遗忘了关键信息
4. 幻觉：编造了不存在的事实或工具
5. 格式错误：输出不符合预期格式导致下游解析失败
6. 超时/资源耗尽：任务没跑完就中断了

你要问 vendor：你们的失败案例里，这六类各占多少比例。如果 vendor 只能给出"失败率 10%"这种笼统数字，说明他们根本没做归因分析，评测就是跑个分。

4.2 归因分布揭示的产品成熟度

我总结了一个经验规律：

• 如果规划失败占比最高（>40%），说明 Agent 的推理能力还不行，可能是基座模型或 prompt 工程的问题。
• 如果工具调用失败占比最高，说明工具生态和错误处理机制不成熟。
• 如果上下文丢失占比高，说明记忆管理是短板，长任务场景要谨慎。
• 如果幻觉占比高，说明缺乏事实校验机制，企业场景慎用。

不同归因对应不同的改进路径，也对应不同的采购风险。你拿着这个分布，就能判断这个 Agent 在你的场景里会不会翻车。

4.3 要求看原始失败日志

如果 vendor 愿意，让他们提供 5-10 条脱敏的失败日志，包括完整的 trace（思考链、工具调用序列、最终输出）。看失败日志比看成功案例有用十倍，因为成功案例往往是精心挑选的，而失败日志能暴露真实的工程水平。

5. 问题四：评测的可复现性怎么保证

这个问题直接戳中很多 vendor 的软肋。因为 Agent 系统有随机性（temperature、采样、工具返回的不确定性），同一套评测跑两次结果可能不一样。你要问的是：你们的评测跑了几次，方差是多少，有没有做显著性检验。

5.1 单次评测的分数没有意义

一个负责任的评测应该报告多次运行的均值和标准差。比如"任务完成率 88% ± 3%（5 次运行）"就比"任务完成率 88%"可信得多。如果 vendor 只给单次分数，你要追问方差。

我见过最离谱的案例：某 vendor 报 91%，客户自己复现跑了 5 次，结果在 76%-89% 之间波动，均值 82%。这个差距足以影响采购决策。

5.2 环境依赖要问清楚

Agent 评测对环境的敏感度很高，你要问：

• 评测时的模型版本是什么（基座模型更新会显著影响结果）
• 温度参数设的多少
• 工具集是完整版还是精简版
• 并发数是多少（高并发下性能会下降）
• 超时阈值设的多少

这些参数任何一个变了，分数都可能大幅波动。让 vendor 把这些写进评测报告，作为合同附件。

5.3 要求现场复现

最硬核的做法：要求 vendor 在你的环境里，用你的数据，现场跑一遍评测。哪怕只跑 20 条，也比看他们的报告强。这一步能筛掉 80% 的吹牛 vendor。

6. 问题五：成本和延迟的评测数据在哪里

企业采购 Agent，性能和成本是两条腿。很多 vendor 只报准确率，不报成本和延迟，这是耍滑头。你要主动问。

6.1 单任务成本的完整口径

"单任务成本"这个数字，不同 vendor 的口径能差 5 倍。你要问清楚包含哪些：

• 基座模型的 token 消耗（输入+输出）
• 工具调用的 API 费用
• 向量检索/记忆存储的费用
• 重试和失败任务的成本摊销
• 如果用了多 Agent 协作，所有 Agent 的成本都要算

我一般会要求 vendor 给出一个典型任务的完整成本拆解表，而不是一个笼统的"平均 0.5 元/任务"。

6.2 延迟要分 P50 和 P99

平均延迟是最没用的指标。你要问P50、P90、P99 延迟分别是多少。因为用户体验由 P99 决定，一个 P99 延迟 30 秒的 Agent，在交互场景里是不可用的。

6.3 并发下的性能衰减

热词里有个"ai agent 怎么扛并发"，这恰恰是企业最关心的问题。你要问 vendor：并发从 1 提到 100 时，延迟和成功率怎么变化。很多 Agent 在低并发下表现良好，一上并发就雪崩，因为工具调用、模型 API 都有速率限制。

让 vendor 提供一张并发-延迟-成功率的曲线图，比任何文字描述都有说服力。

7. 问题六：Agent 的记忆和上下文管理策略是什么

长任务场景下，记忆管理是 Agent 的生死线。这个问题能区分"玩具 Agent"和"企业级 Agent"。

7.1 记忆的三种类型要分清

• 工作记忆（working memory）：当前任务执行过程中的临时状态，通常放在上下文窗口里
• 短期记忆：跨轮对话的历史，需要压缩和检索
• 长期记忆：跨会话的知识沉淀，通常存向量库

你要问 vendor：这三种记忆分别怎么实现，容量上限是多少，检索策略是什么。热词里"agent 存储 working memory"就是这个话题。

7.2 上下文超限怎么处理

真实任务很容易超出上下文窗口。你要问：当上下文快满时，Agent 怎么处理。常见策略有：

• 滑动窗口：丢弃最老的消息（简单但会丢关键信息）
• 摘要压缩：用 LLM 把历史压缩成摘要（有信息损失）
• 检索增强：把历史存起来，按需检索（工程复杂但效果好）

不同策略对应不同的任务长度上限。如果你的业务有超长任务（比如处理一份 200 页的合同），必须问清楚这个。

7.3 记忆的一致性怎么保证

多轮任务里，Agent 可能在不同轮次对同一事实产生矛盾记忆。你要问：有没有记忆一致性校验机制。这个问题很多 vendor 答不上来，说明他们的记忆管理还停留在"塞进上下文"的原始阶段。

8. 问题七：工具调用的错误处理和重试机制

Agent 和普通 LLM 最大的区别就是会调用工具。工具调用失败是常态，错误处理能力直接决定 Agent 的鲁棒性。

8.1 工具失败的分类处理

你要问 vendor：当工具返回错误时，Agent 怎么处理。成熟的系统应该区分：

• 可重试错误（网络超时、限流）：自动重试，带退避
• 参数错误：修正参数后重试
• 工具不可用：切换到备用工具或降级方案
• 业务错误（比如查询无结果）：调整策略而非盲目重试

如果 vendor 的回答是"我们会重试三次"，那太粗糙了。要追问重试的退避策略、最大重试次数、以及重试失败后的兜底逻辑。

8.2 工具调用的可观测性

企业场景必须能追溯每一次工具调用。你要问：有没有完整的工具调用日志，包括入参、出参、耗时、是否重试。这个日志在排查问题时是救命的。

8.3 工具生态的开放性

如果你的业务需要接入内部系统，要问：支持自定义工具吗，接入方式是什么（API/插件/MCP），有没有工具市场。热词里"agent skill""agent skill教程"反映的就是这个需求。工具生态的丰富度和开放性，决定了 Agent 能不能真正落地到你的业务。

9. 问题八：安全边界和权限控制怎么做

企业采购 Agent，安全是一票否决项。热词里"agent安全"排在前列，说明这是行业共识。你要问的问题必须具体。

9.1 权限的最小化原则

Agent 能调用哪些工具、访问哪些数据，必须有细粒度控制。你要问：

• 支持按角色/按任务分配工具权限吗
• 敏感操作（如写数据库、发邮件）有没有二次确认机制
• 有没有操作审计日志，记录谁在什么时候让 Agent 做了什么

9.2 提示注入和数据泄露防护

Agent 会读取外部内容（网页、文档、邮件），这些内容里可能藏有恶意指令。你要问：有没有提示注入（prompt injection）的防护机制。这是当前 Agent 安全的最大风险点。

同时要问：Agent 处理的数据会不会被用于训练，有没有数据隔离保证。企业数据泄露的后果不用我多说。

9.3 沙盒和资源限制

热词里"显示更新 agent 沙盒""docker 容器里的 ros2 humble"都指向沙盒话题。你要问：Agent 执行代码或命令时，是在沙盒里吗，资源限制（CPU/内存/网络）怎么设。没有沙盒的 Agent 执行代码，等于把服务器裸奔。

10. 问题九：评测结果和实际业务的 gap 怎么弥合

这是最务实的一个问题。vendor 的评测分数再高，和你的业务之间总有 gap。你要问的是：你们怎么帮客户做场景适配，适配周期多长，适配后的效果怎么验证。

10.1 场景适配的方法论

成熟的 vendor 应该有一套适配流程：

1. 场景梳理：把你的业务任务拆解成 Agent 可执行的形式
2. 数据准备：构造你的场景专属评测集（通常 100-500 条）
3. 基线评测：用你的数据跑一遍，看真实分数
4. 调优：prompt 优化、工具适配、记忆策略调整
5. 回归验证：调优后重新评测，确认没有退化

你要问 vendor：这套流程你们做过多少次，平均适配周期多长，适配后的提升幅度是多少。

10.2 适配的边界

要问清楚：哪些适配是包含在合同里的，哪些要额外收费。很多 vendor 报价时只含基础版，适配要另算，最后总价翻倍。

10.3 效果验收标准

合同里必须写清楚验收标准。我建议用你的场景专属评测集作为验收依据，而不是 vendor 的通用评测。验收指标至少包括：任务完成率、P99 延迟、单任务成本、失败归因分布。

11. 问题十：如果效果不达标，退出机制是什么

最后一个问题，也是最容易被忽略的：如果 POC 或上线后效果不达标，怎么办。这个问题 vendor 最不愿意回答，但你必须问。

11.1 分阶段验收和付款

建议把合同拆成几个阶段：

• POC 阶段：小范围验证，达标才进入下一阶段
• 试点阶段：真实业务小流量跑，观察稳定性
• 推广阶段：全量上线

每个阶段设明确的验收指标和付款节点。这样即使效果不达标，你的损失也可控。

11.2 数据和模型的归属

要问清楚：适配过程中产生的数据、prompt、微调模型归谁。如果 vendor 跑路，你能不能拿着这些资产换一家继续做。这个条款能极大降低你的锁定风险。

11.3 退出时的数据迁移

如果决定不合作了，你的数据能不能完整导出，格式是什么。有些 vendor 用私有格式存数据，退出时导不出来，你就被绑架了。

12. 把这 10 个问题变成一张采购检查表

上面 10 个问题，我建议你整理成一张表，在每次 vendor 沟通时逐项打分。下面是我自己用的版本，你可以直接抄。

12.1 怎么用这张表

每次和 vendor 沟通后，给每个问题打分（1-5 分），加权求和。低于 3.5 分的 vendor 直接淘汰，不要浪费时间。我试过这个方法，能把选型周期从两个月压缩到三周，而且选出来的 vendor 上线后翻车率明显更低。

12.2 一个容易被忽略的细节

问这些问题的时候，一定要让 vendor 的售前和技术同时在场。售前会包装，技术会露馅。当技术回答不上来售前吹的牛时，你就知道真实水平了。我见过太多次售前说"我们支持无限上下文"，技术当场纠正"其实是 128K"，这种场面比任何评测报告都有信息量。

12.3 关于"vendor/autoload.php"这类热词的提醒

热词里出现了"vendor/autoload.php"，这是 PHP 的依赖加载机制，和 Agent 采购没关系，应该是搜索噪音。但这也提醒我们：选型时不要被技术名词唬住。有些 vendor 会用一堆术语包装产品，你要做的是穿透术语，问到底层能力和真实数据。上面这 10 个问题，本质上就是帮你穿透包装的工具。

最后分享一个我自己的习惯：每次 vendor 沟通完，我会在 24 小时内把关键回答整理成文档，标注哪些是"明确回答"、哪些是"含糊其辞"、哪些是"拒绝回答"。拒绝回答的问题，往往就是产品最大的短板。这份文档在后续谈判和合同条款设计时，价值极高。选 Agent 这件事，问对问题比看对报告重要得多，希望这 10 个问题能帮你少踩几个坑。