为什么通过验收的 Agent 仍会逐渐失效
传统系统的规则主要写在代码里。输入符合约定，输出通常可以重复预测。Agent 的行为则同时取决于模型、提示与政策、检索到的知识、工具返回值、会话上下文和用户表达。
其中任何一项变化，都可能改变最终结果。
例如，一项退款政策更新后，旧知识仍被检索；CRM 接口增加字段后，Agent 继续按旧结构提交；营销活动带来大量过去未见过的问题，人工接管突然上升；模型版本升级后，平均回答更自然，却在某类审批动作上变得激进。
这些问题不一定表现为系统报错。Agent 可能完成了整段对话，也调用了正确接口，只是在业务判断上逐渐偏离预期。这种“看起来能用”的退化，比直接宕机更难发现。
NIST 在 2026 年发布的部署后 AI 监测报告中，将监测分为功能、运行、人因、安全、合规和大规模影响六类，并特别指出性能退化与漂移、分散日志以及人工监测难以随快速部署扩展等现实障碍。换言之，API 可用率和响应时延只能说明系统在运行，不能证明它仍在正确工作。
真正需要运营的，是“行为版本”
许多团队已经有模型版本、提示词版本和知识库版本，却依然无法回答：当前生产环境中的 Agent，究竟按照哪一套业务行为在工作？
企业应把下面这些要素组合成一个可追踪的“行为版本”：
只有形成行为版本，团队才能在投诉增加时复现当时的决策条件，在模型或政策变化时判断影响范围，也能将新旧版本放在同一批真实任务上比较。否则，每次“优化”都可能只是局部调整，没人知道它改善了什么，又破坏了什么。
- 适用的业务范围与禁止事项；
- 可使用的知识、数据和工具；
- 每类动作的权限与审批条件；
- 必须转人工或停止执行的边界；
- 用于验证结果、过程和风险的测试集；
- 与该版本对应的模型、提示、规则及依赖系统。
把真实业务信号变成改进队列
上线后的数据很多，但日志本身不会自动产生改进。企业需要先定义哪些信号值得进入运营闭环。
最有价值的信号通常不是总会话量，而是例外：客户重复表达、工具调用失败、低置信度回答、人工改写、人工接管、申诉、撤销动作，以及任务完成后仍再次联系的情况。它们揭示了测试集没有覆盖的表达、政策冲突和流程断点。
但“减少转人工”不能成为唯一目标。转人工可能代表 Agent 能力不足，也可能代表风险控制正在正确工作。OpenAI 公布 Presence 在其英文电话支持中的数据称，该系统可在无人协助下解决 75% 的来电问题，改进循环在 10 天内将人工接管比例降低了 15 个百分点。这些是供应商披露的早期产品数据，不能直接推算到其他企业；更重要的是，企业应同时检查独立解决后的客户结果、错误动作、投诉和返工，而不是只追求更高自动化率。
一个可运行的改进队列，至少要为每个问题记录发生频率、业务损失、风险等级、影响人群、可复现案例和责任人。高频不等于高优先级：偶发的越权付款，可能比大量措辞不自然更值得立即处理。
修改 Agent，也要像发布生产软件一样受控
Agent 优化最危险的误区，是看到一段失败对话后直接改提示词，然后立即覆盖生产版本。一次局部修复可能改变大量未被观察到的行为。
更稳妥的变更流程包括四步：
先复现
保留当时的输入、知识快照、工具响应、行为版本和完整执行轨迹，确认问题能够在受控环境中重现。无法复现的问题，不宜靠猜测修改。
再扩充测试
不要只把单个失败案例加入测试集，还要补充同类表达、相邻政策、边界条件和对抗场景。修复一个例子，不代表解决了一类问题。
比较新旧版本
新版本既要通过新增案例，也要回归核心业务场景。比较指标不仅包括最终答案，还应覆盖工具选择、动作参数、政策遵循、人工升级时机和完成任务所需成本。
小范围发布并可回退
按照业务、渠道、地区或流量比例逐步放量，预设停止条件，并确保行为版本可快速回退。模型升级、知识更新、工具接口变化和政策修改，都应进入同一套变更管理，而不是由不同团队各自上线。
“人在回路中”必须成为一项有产能的服务
很多方案写着“必要时转人工”，却没有定义谁来接、多久接、接手时能看到什么，也没有安排专家处理新出现的复杂问题。
结果往往是 Agent 把最困难、最模糊、风险最高的任务集中交给人，人工团队的平均处理难度反而上升。如果企业只按原有工单量配置人员，接管队列很快会成为新的瓶颈。
因此，人工接管需要像正式服务一样设计：
人不是 Agent 失败后的兜底按钮，而是感知业务变化、校准判断边界的重要组成部分。
- 明确不同风险等级的接管时限和责任岗位；
- 将上下文、已核验信息、已执行动作和未决问题完整交给人工；
- 区分正常的风险升级与本可避免的能力缺口；
- 将人工修正转化为可审核的测试案例和规则候选；
- 监测专家负荷，防止自动化率提升掩盖人工难度上升。
企业在采购阶段就该问清楚运营责任
Presence 目前仅向符合条件的企业提供有限范围的一般可用服务，由 OpenAI 的前线部署工程师及部分系统集成商主导，并非自助式产品。这也说明，复杂 Agent 的生产化仍包含大量场景诊断、系统连接、评测和持续改进工作。
无论企业选择平台厂商、集成商还是自建团队，都应在合同和项目范围中回答：
如果这些问题没有答案，企业买到的可能只是一个能上线的 Agent，而不是一个能长期工作的业务能力。
- 上线后由谁查看生产质量信号，频率是多少？
- 谁判断问题来自模型、知识、政策、工具还是流程？
- 谁拥有行为版本的批准权和紧急停止权？
- 模型及外部系统升级后，谁负责影响评估与回归测试？
- 真实会话如何脱敏、留存并转化为测试资产？
- 人工接管的成本、容量和改进责任由谁承担？
上线不是交付完成，而是证据开始积累
实验室测试只能覆盖企业已经想到的问题。真实生产环境才会暴露客户如何表达、政策哪里冲突、系统如何异常，以及员工在何处不愿意信任 Agent。
成熟的企业不会把这些例外当作零散故障，而会把它们转化为一条持续循环：生产信号进入问题队列，问题沉淀为测试资产，修改形成新的行为版本，版本经过回归和审批后逐步发布，再由新的真实结果验证。
因此，企业级 AI 的长期壁垒未必只是模型能力，而是组织能否比别人更快、更稳妥地把真实使用转化为可靠改进。
当企业下一次讨论“Agent 什么时候上线”时，还应该追问一句：上线之后，谁每天负责让它继续符合业务？
