企业 Agent 上线验收：回答正确之后，还要验证什么？

演示环境里，用户问一句、Agent 回一句，往往显得进展很快。真正准备上线时，团队会遇到另一类问题：用户表达不完整怎么办？检索到两份相互矛盾的资料怎么办？接口超时但系统其实已经创建了记录怎么办？这些情况决定它能不能进入业务流程，单看几条回答是否通顺并不能给出结论。

先把任务终点写清楚

验收对象最好从“一轮对话”换成“一项业务任务”。例如，用户希望查询符合条件的记录并准备一份待审核任务。测试要说明允许读取哪些数据、结果需要包含哪些字段、缺少信息时要追问什么、什么操作必须由有权限的人确认。任务输入、预期结果和禁止动作都写清楚，业务团队才知道自己究竟在验收什么。

查询、判断和写入需要不同的通过条件

知识问答要核对引用来源、版本和适用范围；只读查询要确认对象、筛选条件、时间范围和当前用户权限；写入操作则要继续检查参数校验、重复提交保护、操作预览、确认记录和后端实际状态。对职责不清或依据冲突的请求，合格表现可能是停下来补问或转交，而不是勉强给出一个肯定答案。

测试样本要覆盖真实边界

测试样本可以从业务人员最近遇到的问题里整理，但进入测试集前要按企业的数据规则脱敏。除了常见问法，也要保留边界样本：用户漏填关键信息、资料已经失效、账户没有权限、工具返回部分数据、用户中途取消，以及执行结果不确定。只挑容易通过的演示问题，会让评测结果失去参考价值。

指标要回答任务有没有完成

指标应对应任务结果。任务完成率只统计满足全部必要条件的有效任务；依据检查要看答案是否被当前资料支持，而不是只看是否出现引用；工具评测要检查调用是否成功、参数是否符合业务规则；接管评测则要看系统是否在正确时机停下，并把足够的上下文交给人工。延迟和成本也应按成功完成的任务观察，因为低成本但反复失败的调用并没有真正节省业务投入。

安全边界不能被平均分冲掉

平均得分不能覆盖所有风险。把知识问答和带写入权限的任务混成一个总分，高频简单问题可能掩盖少数但严重的错误路径。对越权查询、未确认写入、错误的高风险指引等负面样本，应设成单独的上线门槛；门槛由业务、安全和系统负责人结合任务风险与现有基线确定，不照搬一组看起来漂亮的通用百分比。

变更后回归，失败要有负责人

验收也不是一次性签字。模型、提示词、知识版本、检索配置、权限映射或工具接口变化，都可能改变任务结果。每次改动按影响范围回归相关场景，并保留版本、测试样本、结果和未通过项。若关键样本退化，应能暂停扩大使用或回退到上一版本，而不是等一线用户报错后才发现差异。

一次有用的验收会，结束时应留下失败原因和负责人的对应关系：答案没依据，回到知识来源或检索；工具参数不合规，回到接口契约与校验；权限判断错误，回到身份和授权链路；异常没有安全退出，则要修流程和人工接管。把问题定位到具体责任环节，才能让下一轮测试验证修复是否有效。

宜天信达的企业智能体建设可结合业务任务、知识、受控工具和现有审批流程设计上线验收。项目启动时，建议先选一类边界清晰的真实任务，由业务负责人准备样本、IT 团队核验调用与运行记录、安全负责人确认权限和拒绝场景，再一起确定试点范围。