AI Agent POC 验收指标设计

“回答准确率达到多少”只是验收问题的一部分。一个可复核的 AI Agent POC 指标，还要写清任务范围、样本来源、分子分母、判定依据和通过条件。否则，同一个百分比可能对应完全不同的工作量，也可能掩盖没有执行成功的业务动作。

本文面向企业智能体试点，讨论通用验收设计，不提供适用于所有项目的统一合格线。本站交付流程将任务完成、来源引用、系统链路、权限与人工确认列为试点检查项；下面把这些方向进一步拆成可以留存证据、重算结果的记录方法。

先约定任务与通过证据

先写一张任务卡，再选指标。任务卡至少包括谁在什么权限下发起请求、允许使用哪些资料和接口、需要形成什么结果，以及哪些动作必须先得到人工确认。问答、资料整理和业务写入可以在同一次试点中出现，但不能用同一种“成功”定义混算。

例如，以下是一个假设的制造企业设备报修场景：只要求整理报修草稿时，字段完整且能定位依据可能已经满足目标；如果还要求写入业务系统，就需要核对报修记录是否存在、设备标识是否正确、审批状态是否符合约定。聊天界面出现“已完成”，并不能单独作为后一个任务的验收证据。

按任务预先列出可观察证据，例如依据章节及版本、实际输出、权限判定、人工确认和业务回执。留存范围应与测试权限和数据制度一致，不为验收额外复制不必要的敏感原文。跨步骤证据如何关联，可参照智能体审计日志的记录边界。

把样本按预期行为分层

样本应对应真实使用范围，既包含常见任务，也包含容易暴露边界的问题。可以先按预期行为建立五组，而不是把所有问题都归为“应该答对”。下面是工程设计建议，不是固定比例要求。

• 可以直接处理：资料有效、输入完整、账号有权限，能够依据约定完成任务。
• 需要澄清：设备名称重名、时间范围缺失或业务对象不明确，正确行为是先补充信息，而不是猜测。
• 缺少可靠依据：知识库没有覆盖问题，或资料过期、互相冲突，应按规则说明限制或交由人工处理。
• 没有相应权限：资料或工具超出当前角色范围，检查是否在规定边界拦截，且不在答案中泄露受限内容。
• 执行遇到异常：接口超时、结果未确认、流程取消或重试，检查异常状态和接手路径，不把“已发送请求”当成任务完成。

每条样本还应记录业务类别、来源日期、难度与风险标签。统计报告同时展示各组样本量和结果，避免大量简单问答把少量权限错误稀释掉。合成样本可以补充罕见情形，但要标明来源，并由熟悉业务的人确认场景成立；不能据此声称已经覆盖真实生产分布。

正式验收使用的样本与日常调优样本应分开管理。NIST 的 AITE 评测说明采用隔离的盲测数据以降低训练与测试数据污染风险。企业试点可借鉴“保留未用于调优的测试集”这一思路，但不意味着参加了该计划或获得任何认证。

每个指标都写清分子和分母

指标名称后面应直接写公式、适用样本和边界处理。以下定义用于说明口径，项目可以调整，但必须在验收前约定，不能看到结果后再改变分母。

• 来源定位通过率：正确定位到有效依据的样本数，除以预先标注为“需要且存在可用依据”的样本数。命中文档不等于答案正确，还要另查关键结论是否被该依据支持。
• 应拒答样本通过率：按规则拒答或转人工、且未泄露或编造内容的样本数，除以预先标注的应拒答样本数。资料不足与权限不足应分组报告。
• 误拒答率：本应允许回答且具有充分依据、却被错误拒答的样本数，除以这类应答样本总数。只提高拒答数量，可能牺牲正常业务的可用性。
• 越权测试拦截率：在约定控制点成功阻止越权访问或动作的样本数，除以有效越权测试样本数。还要列出每个失败用例，不能只给一个平均分。
• 业务结果通过率：达到任务卡全部必需结果与过程条件的任务数，除以纳入该项评测的有效任务数。部分完成、等待确认和无法核实的结果分别记录，不静默计作成功。

举一个纯计算示例：某组有 40 条“依据充分且当前角色可回答”的样本，其中 6 条被错误拒答，误拒答率就是 6/40，也就是 15%。这个数字仅说明计算方式，不是本站实测或建议阈值。另一组如果没有任何应拒答样本，应标为未测或不适用，不能填写 100% 通过。

测试中出现的超时、工具异常和人工接手通常也是观察结果，不能为了提高分数事后删去。确需剔除损坏样本或不属于约定范围的输入时，保留原因、审批人与剔除数量，同时披露原始样本量和最终分母。

基线、耗时与人工工作量

先用现有流程测一轮基线，再比较智能体方案。尽量保持任务类别、资料版本、完成标准和参与者条件可比，并说明无法保持一致的部分。验收关注的是在同等要求下是否有所改善，而不是拿外部案例的漂亮数字套用到本项目。

耗时要明确起止点。模型开始输出、完整回答生成和业务结果可确认，可能是三个不同时间。如果流程需要人工确认，应分别报告机器处理时间、等待时间与人工处理时间，不用更短的一段时间代表端到端耗时。报告尾部耗时指标时，也应提供样本量和测试负载。

人工工作量可以记录每个任务的核对、修改、接手与异常处理时间。持续使用情况则作为另一类运营观察：约定时间窗口、目标任务机会、可使用人员范围和有效使用定义。短期点击次数既不能替代结果质量，也不能单独证明项目会进入生产。

评分分歧与独立复测

判定人应按责任共同确定，而不是一律由供应商自评或一律交给某个岗位。业务代表判断结果是否可用，技术人员核对链路和回执，安全人员检查相应权限边界；争议样本由预先约定的复核人处理。对于关键指标，可以先让两位评审独立判断一部分样本，记录分歧，再统一评分说明。

规则明确的字段、状态和记录存在性适合自动检查；回答是否充分、引用是否真正支持结论，往往还需要人工复核。若采用模型评分，应先用人工标注样本检查一致性，不把评分模型的输出直接当作事实。OpenAI 的评测最佳实践也强调任务针对性、人工校准和边界情形，且指出模型评审可能受答案顺序或篇幅影响。

验收集一旦被用于逐条修改提示词、检索规则或工具参数，就已经参与了调优。保留它用于回归，同时补充新的独立样本进行复测。每次记录模型、提示词、知识版本、权限配置和工具版本；修改了什么，就检查对应影响范围以及关键边界是否退化。

验收记录与上线门槛

一条可复核的验收记录至少要包含下列内容。NIST AI RMF Playbook 的 Measure 2.1强调保存测试集、指标与测试工具等细节，以支持重复和一致的测量；这里将这一原则转成便于项目执行的字段清单。

• 样本：稳定编号、任务类别、输入、数据来源、预期行为、角色和授权范围。
• 版本：测试日期、环境、模型、提示词、知识、工具和权限配置版本。
• 判断：指标定义、分子分母、参考依据、评分规则、判定人与分歧处理。
• 证据：实际输出、必要回执、关联记录标识、观察耗时和受控证据位置。
• 结论：通过、未通过、未测或不适用，失败原因、剔除理由、整改责任与复测安排。

阈值应结合基线、风险和业务可接受程度提前确定。严重越权、未获批准的写入等关键问题，可以按项目约定设置独立停止条件，不被其他项目的高分抵消。不过，一轮样本中没有发现错误，也不证明系统今后永远不会出错。

验收结论不必只有“全面上线”和“项目失败”。如果证据支持，可以限定用户、资料或只读功能进行下一阶段验证，同时列出未开放范围、人工接手方式和退出条件。这是范围受控的下一步，不是把未通过项包装成已经合格。

一轮可执行的验收顺序

1. 冻结任务范围、有效依据和禁止动作，为每类任务写出通过证据。
2. 按预期行为准备样本，区分调优集、回归集和独立验收集。
3. 约定指标公式、剔除规则、判定责任和通过门槛，采集现有流程基线。
4. 在记录完整版本的环境中执行，保存失败、超时、拒答和人工接手结果。
5. 处理评分分歧，按样本组报告数量、结果与限制，不仅汇总平均分。
6. 针对问题整改并复测，由记录支持继续试点、限定开放或暂停推进的决定。

POC 验收的价值，是让下一步决定能够被解释和复核。比起先约定一个看起来很高的准确率，把样本、口径和证据写完整，才能更清楚地看见智能体在哪些任务上可用、哪些边界仍需处理。