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 给出评测集的采样分布具体到维度要问的具体内容为什么重要任务类型分布单步任务/多步任务/需要工具调用的任务各占多少多步任务才是 Agent 的真实难点难度分布简单/中等/困难的比例困难任务的定义标准全是简单任务的 95% 没有意义领域分布覆盖了哪些垂直领域每个领域多少条判断和你的业务重合度来源分布人工构造/真实日志/合成数据各占多少合成数据容易过拟合提示如果 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-Judgejudge 模型是什么prompt 是什么有没有做过 judge 和人工标注的一致性校验。3.2 部分完成怎么算真实业务里一个任务往往是部分完成的。比如帮我把这份合同里的风险条款标出来并生成报告Agent 标出了 8 条风险中的 6 条报告也生成了但格式有误。这算完成还是没完成如果 vendor 的定义是只要生成了报告就算完成那这个分数就是虚的。你要追问有没有部分完成partial completion的评分机制权重怎么分配。一个成熟的评测体系应该有细粒度的评分而不是二元的成功/失败。3.3 追问话术模板我一般会这样问假设一个任务需要 5 步Agent 完成了前 4 步第 5 步调用了错误的工具但最终输出看起来是对的。在你们的评测里这个 case 算完成吗请给出你们判定逻辑的具体规则。这个问题 vendor 很难糊弄因为一旦给出规则你就能判断他们的评测严谨度。4. 问题三失败案例的归因分析能不能给我看只看成功率的评测报告都是耍流氓。真正能反映 Agent 能力的是失败案例的归因分布。这个问题能问出 vendor 对自家产品的理解深度。4.1 失败归因应该分几类一个合格的失败归因体系至少应该区分规划失败任务拆解错了方向就偏了工具调用失败选错工具、参数错误、工具返回异常没处理上下文丢失多轮对话中遗忘了关键信息幻觉编造了不存在的事实或工具格式错误输出不符合预期格式导致下游解析失败超时/资源耗尽任务没跑完就中断了你要问 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在交互场景里是不可用的。指标含义企业场景参考阈值P50 延迟一半请求快于此交互场景 3sP90 延迟90% 请求快于此 8sP99 延迟99% 请求快于此 20s吞吐量每秒可处理任务数按业务峰值定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 skillagent 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 应该有一套适配流程场景梳理把你的业务任务拆解成 Agent 可执行的形式数据准备构造你的场景专属评测集通常 100-500 条基线评测用你的数据跑一遍看真实分数调优prompt 优化、工具适配、记忆策略调整回归验证调优后重新评测确认没有退化你要问 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 沟通时逐项打分。下面是我自己用的版本你可以直接抄。序号问题关键追问点权重1评测数据集构造采样分布、领域重合度高2完成率定义判定标准、部分完成处理高3失败归因归因分类、原始日志高4可复现性方差、环境参数、现场复现高5成本和延迟完整口径、P99、并发曲线高6记忆管理三类记忆、超限处理、一致性中7工具错误处理分类重试、可观测性、开放性高8安全边界权限、注入防护、沙盒高9场景适配方法论、周期、验收标准高10退出机制分阶段验收、资产归属、数据迁移中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 个问题能帮你少踩几个坑。