智能体项目验收怎么答：功能、效果、稳定性、安全合规四层框架

《核心观点》

1. 答「智能体项目怎么验收」如果只说「看功能是否正常、测试通过就算完成」，等于主动丢分，面试官真正想听的是候选人有没有落地思维。
2. 验收要分成功能、效果、稳定性、安全合规四个维度：分别确认智能体能不能按设计完成规划与工具调用、输出质量与业务指标是否达标、长时间运行和异常场景下是否可靠、数据与权限是否可控。
3. 企业级项目里效果和稳定性往往比功能更关键——功能再完整，效果不稳定、动不动输出错误，仍然上不了线。
4. 效果验收要把技术指标翻译成业务指标。以售后工单智能体为例，技术侧看意图识别准确率与工具调用成功率，业务侧看工单自动解决率、平均处理时长、转人工率与用户满意度。
5. 稳定性验收必须包含异常场景：连续运行测试、并发压力测试、故障注入、工具超时、输入扰动；主动提出「错误恢复率」这类量化口径，比如连续 100 次异常任务中自行恢复到正确路径的比例不低于 85%，比空谈稳定更有说服力。
6. 安全合规是企业级交付的必查项，涉及数据脱敏、工具调用最小权限、生成内容审核、关键操作留痕；验证方式是模拟越权请求、注入敏感信息、检查日志完整性。
7. 现场组织顺序：先给四层结论，再展开效果验收并举一个场景例子，接着讲稳定性与恢复机制并带量化指标，补一句安全合规，最后落到「不仅确认系统能用，还要确认敢用、值得用」。
8. 这道题的本质是实验室思维到落地思维的切换——从只关心模型输出好不好，转向关心业务指标、异常恢复、安全合规和长期维护。

《参考解析》

四层的顺序对应交付风险的递进。 功能验收回答「做出来了没有」，效果验收回答「做出来的东西有没有用」，稳定性回答「在真实环境里连续跑不跑得住」，安全合规回答「出事之后谁担责」。面试官从这个顺序里看的是交付视角，只在功能层打转的候选人，通常没经历过上线后被真实流量和脏数据打脸的阶段。答的时候可以顺带说明每层的验收主体不同：功能由开发自测加用例覆盖，效果需要业务方一起定口径，稳定性靠压测和演练，合规往往由安全团队签字，层次感自然就出来了。

业务指标要从智能体在链路里的位置倒推。 同一个智能体放在不同位置，验收指标完全不同：替人处理一线工单，看自动解决率、平均处理时长、转人工率；给人做辅助建议，看采纳率、修改率和人均处理量；嵌在转化链路里，看转化率与投诉率。挑选原则有三条——业务方不看模型日志也能观测到、变化能被归因、指标本身有历史基线可比。面试里最容易加分的动作是主动补一句「这个指标怎么取、多久看一次、掉到什么程度要回滚」，因为指标只有配上阈值和动作才算验收标准，否则只是一组好看的数字。

「错误恢复率」这类指标要讲清分母、判据和处理动作。 一个站得住的定义需要三件事：异常样本从哪来（故障注入、历史失败日志回放、线上采样，三类难度不同要分开统计）、什么算「恢复到正确路径」（跑完剩余步骤且结果通过校验，中途重试成功但结果错的不能算）、失败之后走哪条分支（重试、降级到人工、返回部分结果并标注）。分母建议用「进入异常分支的任务数」而不是总任务数，否则正常任务会稀释掉真实问题；再补上观测方式——每次异常落一条结构化日志，含错误类型、重试次数、最终状态，这个数字才可信。

安全合规要给出可执行的验证用例。 只说「我们会做脱敏和权限控制」是空话，落到用例才有分：拿一个只有部分数据权限的账号去请求全量数据、在用户输入里塞提示注入指令看输出是否被约束、构造超范围工具调用来验证权限边界、检查日志能不能还原「谁在什么时间让智能体调了什么工具、参数和返回是什么」。脱敏还要分清做在哪一层——落库前、进模型前、还是出模型后，三者防的东西并不一样。

这类回答有两个常见的丢分方向。 一种是只讲技术指标和测试用例，听起来像测试岗的通识答案，缺业务味；另一种是堆业务词却说不清怎么测，听起来像产品培训。稳妥的做法是每一层都给「一个可执行动作 + 一个数字」：功能层给用例覆盖率和通过率，效果层给一组业务指标与基线，稳定性层给异常场景清单与恢复率，合规层给越权与注入用例。最后收在「能不能用、敢不敢用、值不值得用」，正好把四层串成一条线。