智能体项目最容易出现的一种尴尬是：演示时惊艳，上线后没人用；或者上线后感觉"还行"，但没人说得清到底好不好。原因很简单——智能体的输出是不确定的，同样的问题问两次，答案措辞可能都不一样。传统软件那套"能不能跑通"的验收方式，在这里完全失效。

所以找合肥智能体开发公司做项目，签约前必须先谈清楚一件事：用什么标准判断它"做成了"。这篇内容把业界已经相对成熟的智能体评测框架、具体指标阈值、评测集构建方法以及合同层面的验收条款讲清楚，让验收从"感觉不错"变成"数据说话"。

一、为什么智能体不能按传统软件验收

传统软件测试假设确定性：同样输入必然得到同样输出，一个功能要么通过要么失败。智能体恰恰相反，它具有三个特性，决定了验收方式必须换一套逻辑。

结论是：智能体的验收必须是统计式的——不是问"这个功能通不通"，而是问"在多少条代表性样本上，有多少比例的输出达到了质量标准"。这也就意味着，验收的第一步不是写代码，而是先建评测集。

二、三层评测框架与具体阈值

目前业界普遍采用三层结构来评估一个智能体：任务完成层（是不是把事做对了）、输出质量层（做得有多好）、运行可靠性层（在生产环境下是否稳定）。三层缺一不可，只看其中任何一层都会给出错误结论。

第一层：任务完成度

这一层回答"它有没有完成被交代的任务"，核心指标包括任务成功率、部分完成率、拒答率、幻觉率、工具调用准确率、步骤完成率。不同用途的智能体，最低门槛差别很大。

第二层：输出质量

任务做完了，还得看做得对不对、全不全、说不说得清楚。这一层的指标包括事实准确性、信息完整性、相关性、逻辑连贯性、一致性、引用准确性。评分方式有四种，各有取舍：人工评分为金标准但成本高、模型评分可规模化但需校准、自动化指标（如文本相似度）快但和真实质量相关性弱、评分量表法结构化但需要事先设计好标准。实务中通常是组合使用。

第三层：运行可靠性

这一层最容易被忽视，却直接决定上线后会不会翻车。生产环境的可用基准通常包括：延迟 P95 控制在 15 秒以内、错误率低于 2%、系统可用性不低于 99.5%。多步流程的智能体还要额外关注并发下的性能衰减，以及对话轮次变长后质量是否下滑。

三、一张可用的验收评分卡

把上面的指标整合成一张带权重和阈值的评分卡，验收时就能直接对照打分。任何单项低于最低阈值，无论总分多少都应阻断上线——这是评分卡设计里最重要的一条硬规则。

权重要根据场景风险调整：面向外部客户的智能体应把安全权重提得更高，内部自动化工具则更看重准确率与效率。这张表本身也应当作为合同附件，写清每个指标的定义与测量方法，避免验收时对"准确率"三个字各说各话。

四、评测集怎么建：比代码更该先做的东西

评测集的质量直接决定验收结论是否可信。用一堆简单问题去测，只会得到虚假的安心感。

• 规模：单一窄流程 50 条即可起步，覆盖面较广的智能体建议 150 至 200 条，生产级部署通常要求 500 条以上。
• 构成比例：约 60% 典型场景、25% 困难场景、15% 需要拒答或转人工的场景。边界与例外案例应占两到三成。
• 来源：素材应尽量取自真实业务历史，而不是技术人员想象出来的问题。
• 标准答案的确认人：应由业务负责人确认"什么算做对了"，而不是由技术团队自行定义。
• 持续维护：评测集是活的。每个季度应把生产环境中暴露失败的真实案例补进去，因为这些恰恰是当初没预料到的情况。

用一个模型给另一个模型打分（业界称为模型裁判）在实践中很常见，但必须先校准。典型做法是先由人工对 30 至 50 条样本打分，再与模型评分对比，观察模型偏袒的方向。已知的偏差包括：偏好更长、更自信的表述，对数字和日期的判断偏弱，对风格与自己相近的内容打分更宽松。因此有一条实用分工原则——凡是能被确定性校验的内容，比如金额、日期、单据号、编号、必填字段是否存在，一律用代码来查，不要交给模型；模型只负责判断需要理解语义的部分，比如答案是否与标准一致、语气是否合适、有没有漏掉重要提醒。裁判模型最好与被测模型不是同一个，并且使用写明的、有版本号的评分标准。

五、回归测试：最被低估的风险

运行智能体最大的风险，往往来自一次你不曾计划的变更：模型厂商发布了新版本、旧版本下线、某个配置被调整，智能体的行为就悄悄变了。这种变化通常很不均匀——95% 的情况表现一模一样，5% 开始给出不同结果。系统没有宕机，没人报警，但质量已经在流失。

应对方式是把评测集固化为回归测试：每次模型切换、提示词调整、知识库更新后，重跑同一套测评样本，与上一次的分数对比。分数下降超过设定幅度即触发告警。同时在生产环境持续抽样，建议对 5% 到 10% 的真实输出做自动质量检查，异常结果进入人工复核队列。

六、阈值该怎么定：这是业务决策，不是技术决策

一个经常被忽略的事实是：验收阈值的高低不是技术团队能决定的。给业务人员起草邮件文案的助手，85% 的准确率可能完全够用；而一个会直接写入财务系统的智能体，99% 有时仍然不够。因为不同类型的智能体，犯错的代价差异极大。

还有一项很少出现在供应商方案里、但对团队信任至关重要的指标：智能体是否正确识别出"这种情况我不该自己做主"，并主动转交人工。行业里把它理解为"知止率"。一个从不犹豫、什么活都敢接的智能体，看起来能力强，实际风险很高。签约前把这一项单独写进验收清单，是非常划算的动作。安徽好牛软件有限公司在为合肥本地企业设计智能体验收方案时，习惯把评测集、评分卡与人机边界规则一并交付，客户拿到的不是一份演示，而是一套上线后可以自己持续跑的质量基线。

常见问题解答

Q1：智能体准确率多少才算合格？

没有统一答案，取决于用途与犯错代价。客服类通常要求任务成功率 80% 以上、目标 90%；文档处理类要求更高，一般 85% 起步、目标 95%。关键是签约前把阈值写进合同，而不是上线后再讨论。

Q2：评测集该由谁来做？

由业务方与技术方共同完成。业务方负责提供真实场景样本并确认"什么算做对"，技术方负责组织、标注与自动化评测流程。全部交给技术团队自拟样本，评测结果往往过于乐观。

Q3：上线之后还需要一直测吗？

需要。模型更新、提示词调整、知识库变动都可能导致行为变化，且这种变化通常是静默的。建议每次变更后重跑回归测试，并在生产中持续抽样监测。

Q4：怎么防止供应商只报喜不报忧？

要求提供评测集的原始样本与逐条结果，而不是一个总结数字。同时要求给出失败案例清单及处理策略。愿意把失败样本摆到桌面上的团队，通常才是真正做过生产级项目的团队。

Q5：怎么判断一家合肥智能体开发公司懂不懂评测？

问三个具体问题：评测集有多少条、其中边界案例占多少、模型换版本后怎么验证没有退化。如果对方答不出这些问题，说明项目还没有走到生产级的思考深度。安徽好牛软件在合肥本地的智能体项目中，把评测集与评分卡作为交付物的一部分，客户的验收动作可以照着执行，而不是凭印象判断。