企业级Agent采购评测指南：10个必问问题与选型框架

1. 先搞清楚企业买 Agent 到底在买什么很多团队在采购 Agent 产品时第一反应是看演示。厂商派个售前工程师过来打开一个精心准备的界面输入一段话Agent 噼里啪啦调了几个工具、查了几条数据、生成了一份看起来像模像样的报告会议室里一片点头。然后合同就签了。三个月后业务方开始抱怨怎么换个问法就答非所问怎么并发一上来就排队怎么接内部系统还要额外收一笔“集成费”这时候再回头看合同发现里面写的全是“智能”“高效”“领先”这类形容词没有一个能拿来验收的硬指标。我经历过不止一次这种局面。所以现在但凡有朋友问我“某某 Agent 产品能不能买”我都不直接回答而是先反问一句你打算拿什么问题去问 vendor问对了问题答案自己就浮出来了问错了问题你只会得到一堆漂亮的 PPT。这篇东西就是把我这些年踩坑攒下来的“提问清单”整理出来。它不针对任何具体厂商也不推荐任何产品就是一套采购前的评测框架。适合正在做 Agent 选型的技术负责人、架构师、采购决策者也适合刚接触 Agent 开发、想搞清楚“企业级”三个字到底意味着什么的工程师。核心就一句话别问 vendor 能做什么要问它在什么条件下做不到什么。2. 为什么“评测问题”比“功能清单”更重要2.1 功能清单是厂商的主场评测问题是你的主场功能清单这个东西本质上是厂商定义的游戏规则。它列出来的每一条都是它已经做好的、能演示的、有把握的。你拿着这份清单去对比看似在做选择题实际上是在厂商画好的圈里打转。而评测问题是另一回事。它问的是边界、是代价、是失败模式。比如“你这个 Agent 支持多少并发”是功能问题“当并发超过设计上限时系统是排队、降级还是直接报错报错信息里能不能定位到是哪个环节堵住了”就是评测问题。前者厂商可以答“支持高并发”后者它必须给出具体机制。我个人的经验是一场选型会如果 vendor 讲的时间超过 40%这场会基本白开。你要做的是把话题拽到你的场景里让它回答你的问题而不是让它表演它的产品。2.2 企业场景和 Demo 场景之间隔着一条河Demo 场景有几个隐含假设数据是干净的、网络是稳定的、用户是配合的、任务是单步的、失败是可以重来的。企业场景恰恰相反数据散在十几个系统里、网络偶尔抽风、用户会输入各种奇怪的东西、任务往往要跨部门流转、失败可能意味着真金白银的损失。所以评测问题的设计逻辑应该是沿着企业真实链路去拆从用户输入进来到 Agent 理解意图到它调用工具到工具返回结果到它组织答案到答案被业务系统消费——每一个环节都可能出问题每一个环节都值得问一句“这里如果出问题你怎么让我知道、怎么让我控制”。2.3 一个反直觉的判断越“聪明”的 Agent 越需要问清楚早期规则型机器人行为是可预测的出问题也好排查。现在的 Agent 引入了大模型做推理和规划能力上去了但不确定性也上去了。同一个输入两次运行可能走不同的工具调用路径。这对企业来说是把双刃剑灵活性的代价是可解释性和可复现性下降。所以面对越“智能”的 Agent越要问清楚它的决策边界在哪里、有没有兜底机制、能不能把推理过程暴露出来。这不是不信任技术而是企业采购的基本素养——你得知道你在为什么买单以及买回来的东西在什么情况下会失控。3. 采购前必问的 10 个评测问题逐条拆解下面这 10 个问题我按“从外到内、从能力到治理”的顺序排。每个问题我都会说清楚为什么问、期望听到什么答案、听到什么答案要警惕。3.1 问题一你的评测集是怎么构建的能不能给我看原始样本这是我最看重的一个问题没有之一。因为 Agent 的能力宣称最终都要落到“在什么数据上测出来的”这个问题上。一个靠谱的 vendor应该能告诉你评测集覆盖了哪些任务类型、样本量多大、正负样本比例如何、有没有做交叉验证、标注一致性怎么保证。如果它支支吾吾只说“我们内部有大量测试”那基本可以判定它的“准确率 95%”是挑出来的。注意不要接受“我们用的是公开榜单”这种回答。公开榜单和你的业务场景之间差距可能比你想的大得多。你要的是它在你这类任务上的表现证据。3.2 问题二任务失败时系统怎么定义失败、怎么上报失败企业最怕的不是 Agent 做错而是做错了还不告诉你。所以这个问题问的是可观测性。期望的答案应该包含失败分类理解失败、工具调用失败、超时、权限不足、结果校验不通过等、失败日志的粒度能不能定位到具体哪一步、失败后的重试策略、以及失败率的口径定义是按请求算还是按任务算。如果 vendor 说“我们成功率很高基本不会失败”这句话本身就是最大的风险信号。任何分布式系统都会失败区别只在于失败被不被看见。3.3 问题三工具调用的权限模型是什么能不能做到最小权限Agent 要干活就得调工具调工具就有权限问题。这里要问的是Agent 以什么身份调用外部系统是共享账号还是独立身份权限粒度能细到什么程度能不能做到“这个 Agent 只能读订单表不能写”更进一步要问凭证怎么管理是明文配置、环境变量还是有专门的密钥管理凭证轮换方不方便这些细节决定了你上线之后的安全审计能不能过。3.4 问题四多步任务的中间状态存在哪断了能不能续企业任务经常是长链路先查数据、再分析、再生成文档、再走审批。如果第三步挂了是从头再来还是能从断点续上这直接关系到成本和用户体验。要问清楚中间状态working memory存在哪里、存多久、能不能查询、能不能人工干预。有些 Agent 框架把状态放在内存里进程一重启就全没了这在生产环境是不可接受的。3.5 问题五并发上来之后性能曲线是什么样的“支持高并发”是一句废话。你要问的是在多少并发下P99 延迟是多少超过这个点之后系统是线性劣化还是断崖式崩溃有没有限流和排队机制排队时用户看到的是什么我一般会要求 vendor 提供一个压测报告哪怕是自己环境里跑的。如果它拿不出来你可以要求做一次联合压测把这条写进采购前的验证环节。3.6 问题六模型换了、版本升级了我的评测结果还作数吗Agent 的能力高度依赖底层模型。今天测得好不代表下个月模型升级后还好。所以要问模型版本怎么管理升级是强制的还是可选的升级前会不会通知有没有回归测试机制这个问题的潜台词是我要的是可预期的稳定性不是每次升级都开盲盒。3.7 问题七数据不出域能不能做到出域的话怎么脱敏这是合规红线问题。要问清楚Agent 的推理是在本地还是云端如果云端数据传过去之后怎么处理、存不存、存多久能不能配置脱敏规则有没有数据处理的书面承诺不同行业的合规要求不一样但问法是一样的我的数据流向哪里我能不能控制。3.8 问题八出问题的时候你的支持响应是什么级别企业采购买的不只是软件还有服务。要问SLA 怎么定义故障响应时间多长有没有专属支持通道版本更新频率如何重大故障有没有补偿机制这些问题听起来像商务问题但它们直接影响你上线后的运维成本。我见过太多团队买的时候只谈功能上线后才发现提个工单三天没人理。3.9 问题九能不能做 A/B 测试能不能灰度发布Agent 的行为会变所以你需要一套机制来验证“新版本是不是真的更好”。要问支不支持流量切分能不能按用户、按任务类型灰度评测指标能不能自定义没有这套机制你每次升级都是全量赌博。3.10 问题十如果我要换掉你迁移成本有多高这个问题最得罪人但最该问。要问配置能不能导出对话历史能不能带走工具集成是不是标准协议有没有厂商锁定的地方一个健康的采购关系应该建立在“我随时可以走但我选择留下”的基础上而不是“我被绑死了所以走不了”。4. 把这 10 个问题变成一张可执行的评测表光有问题不够得把它变成能打分、能对比的东西。我一般会做一张表每个问题拆成几个可验证的子项现场问、现场记会后打分。4.1 评测维度与权重设计不同企业关注点不一样权重可以调。下面这张表是我常用的默认权重供参考。维度对应问题权重验证方式评测透明度问题一15%要求提供评测集样本与标注说明可观测性问题二15%现场演示失败日志与告警权限与安全问题三、七20%要求提供权限模型文档与合规承诺状态与可靠性问题四、五15%联合压测 断点续传演示版本与治理问题六、九15%要求提供升级策略与灰度方案服务与迁移问题八、十20%审阅 SLA 条款与数据导出能力权重不是拍脑袋定的。安全和服务这两块我给得高是因为它们出问题的代价最大而且事后补救最难。4.2 现场提问的顺序和节奏提问顺序也有讲究。我一般先问评测透明度因为这个问题最能看出 vendor 的底气。答得好的后面可以聊得深答得虚的后面就得加倍警惕。然后是可观测性和权限这两块是技术硬骨头需要 vendor 的技术人员在场售前一个人往往答不上来。如果对方只派了销售你可以直接说“这几个问题需要你们技术同学来答”这本身就是一次筛选。最后问服务和迁移这部分偏商务但一定要在技术确认之后再谈否则容易被“我们服务很好”这种话带偏。4.3 打分之外记录“回避的问题”比打分更重要的是记录哪些问题被回避了。一个 vendor 如果对某个问题反复绕开、用形容词代替具体机制、或者说“这个我们后面再聊”那这个问题就是你的风险点。我的习惯是每个被回避的问题都标红会后单独跟进。如果跟进两次还是含糊基本可以判定这块它没做好或者不想让你知道。5. 实操一次完整的 Agent 选型评测现场记录光讲框架有点干我拿一次真实的选型经历来串一遍。那次是帮一个做供应链的团队选 Agent 平台场景是“自动处理供应商询价邮件并生成比价报告”。5.1 评测前的准备把问题变成场景脚本我们没有直接拿着 10 个问题去问而是先写了一个场景脚本给 Agent 一封真实的询价邮件脱敏后看它能不能提取关键信息、调用内部价格库、生成对比表、并标注异常项。然后把这 10 个问题嵌进这个脚本的执行过程里。比如在它调用价格库的时候我们问权限模型在它生成报告的时候我们问结果校验在故意制造一个超时的时候我们问失败上报。这样问的好处是vendor 没法用准备好的话术应付因为它必须在你设计的场景里实时反应。5.2 现场三个让我印象深刻的回答第一个回答关于评测集。那家 vendor 直接打开了一个内部看板展示了他们在类似询价任务上的评测结果包括失败案例的截图。这个动作让我对他们的信任度直接拉满——敢给你看失败案例的通常是真的做过评测。第二个回答关于并发。我们问 P99 延迟对方没有直接给数字而是说“我们的延迟主要花在模型推理上工具调用部分很快所以延迟曲线和模型服务的负载强相关”。这个回答很诚实也很有信息量——它告诉我们瓶颈在哪以及他们清楚瓶颈在哪。第三个回答关于迁移。对方说“配置可以导出成 YAML对话历史可以走 API 拉取工具集成用的是标准协议”。这三句话直接打消了我们最大的顾虑。5.3 现场两个让我警惕的信号第一个信号是关于权限。我们问能不能做到“只读订单表”对方说“可以配置”但当我们追问“配置在哪里、能不能现场看一下”时对方开始翻文档翻了五分钟没找到。这说明这个能力可能存在但没被产品化用起来会很别扭。第二个信号是关于失败上报。我们故意让一个工具调用超时结果系统只是转了个圈然后说“抱歉我无法完成”。没有错误码、没有日志入口、没有重试提示。这个体验在企业场景里是致命的。5.4 评测后的决策不选“最强”的选“最可控”的最后我们选的那家不是演示最炫的也不是宣称准确率最高的而是在失败处理、权限控制、迁移能力上答得最清楚的。因为供应链场景对错误的容忍度很低一次错误的比价可能导致采购决策失误所以我们宁可要一个能力边界清晰、出问题能定位的 Agent也不要一个“什么都能做但说不清怎么做”的。这个决策逻辑我觉得适用于大多数企业场景。6. 常见问题与避坑指南6.1 常见问题速查表现象可能原因排查方向演示很好试用就拉胯演示用的是精选样本要求用你的真实数据做 POC准确率很高但业务不买账评测指标和业务目标脱节重新定义验收指标拉业务方参与并发一上来就超时架构是单点或同步阻塞要求压测报告看瓶颈在哪换个问法就答错意图识别泛化能力不足要求提供意图覆盖测试结果升级后行为变了缺少回归测试和灰度机制要求版本管理和灰度方案想换厂商发现换不掉配置和数据被锁定采购前确认导出能力6.2 三个我踩过的坑第一个坑只看准确率不看召回率。早期选型时我们被一个“准确率 98%”的数字吸引上线后发现它为了保准确率大量任务直接返回“无法处理”。对企业来说该做的没做和做错了一样糟糕甚至更糟因为你还得人工兜底。第二个坑忽略冷启动成本。有些 Agent 需要大量配置和调优才能达到宣称效果这部分工作量 vendor 不会主动说。问清楚“达到你演示的效果我需要投入多少人天”。第三个坑把 POC 做成 Demo。POC 应该是用你的数据、你的流程、你的异常场景去压测而不是让 vendor 再表演一遍。POC 的验收标准要提前写死否则很容易变成“感觉还行”。6.3 一个实用的谈判技巧把“评测通过”写进合同。具体做法是在采购前和 vendor 一起定义一组验收用例明确通过标准写进合同附件。这样如果上线后达不到你有依据。这个动作本身也会筛掉一批不敢承诺的 vendor。7. 我个人在实际操作中的几点体会第一评测问题要问在采购前不要问在采购后。采购前你是甲方问什么对方都得答采购后你再问就变成“需求变更”了。第二技术问题一定要技术人员来答。售前的话术再漂亮也替代不了技术细节。如果对方派不出技术人员说明它要么不重视你要么技术团队本身就不够硬。第三不要追求“全能 Agent”。企业场景里一个在特定任务上稳定可靠的 Agent价值远大于一个什么都能聊但什么都不精的通用 Agent。评测的时候聚焦你的核心场景别被花哨的附加功能带偏。第四把评测当成一次学习。问这 10 个问题的过程也是你梳理自己需求、明确自己边界的过程。很多时候问完一圈你会发现真正要解决的问题比一开始想的清晰多了。最后分享一个小技巧如果 vendor 说“这个功能我们下个版本会有”你就问“下个版本什么时候能不能写进合同”。能写进去的才是承诺写不进去的都是画饼。