四类指标各有用途
动作成功率反映任务闭环是否稳定，工具失败率暴露接口健康度，越权拦截说明边界正被试探，人工接管则体现置信度不足。四类指标要一起看，只看其中一个很容易得出错误结论，比如成功率高但接管率也高，实际是系统在硬撑。
工具变更要走回归
上游接口改字段、改错误码、改限流，都会让智能体突然失效。工具变更应纳入通知机制，收到变更后先跑一遍回归用例，再决定是否需要调整编排；跳过回归直接上线，往往在业务高峰期出现问题，排查也更困难。
评测集要持续扩充
每周把线上出现的新提问方式补进评测集，尤其是被人工接管或拒答的样本。评测集长期不扩充，回归结果会越来越乐观，而真实表现却在下降；扩充时应标注来源与判定结论，避免把错误样本当成标准答案。
权限按月复审
每月核对动作清单与权限档位是否仍与业务需要匹配，收回长期未使用的执行权限。权限只增不减是常见现象，半年后往往没人说得清哪些动作能自动执行；定期复审能让权限面保持在可控范围，也便于交接。
保留可回退的配置版本
每次修改提示词、工具路由或权限配置，都保留可回退的版本与变更说明。智能体的问题往往在改动后一到两周才显现，没有版本记录时排查只能靠猜；有版本记录则可以先回退再定位，把影响控制在最小范围。
适用与不适用
适合谁
- 已上线、开始承担真实业务的智能体
- 多工具编排、依赖多个外部接口的项目
- 准备扩大灰度范围、需要按周投入运维的团队
不适合谁
- 仍处于原型阶段、尚无真实用户的试验
- 不接受日志留存与权限复审的场景
典型场景
某银行的智能体在运行第四个月出现批量失败，排查发现上游工单接口调整了错误码。由于此前未建立变更通知与回归机制，问题在业务高峰才被发现。团队随后补上接口变更通知、回归用例与配置版本记录，并把权限复审排进月度例会，同类问题未再出现。
可执行步骤
- 按动作成功率、工具失败率、越权拦截与接管率四类指标建看板，作为日常观察基线
- 与上游系统约定接口变更通知，收到变更后先跑回归再决定是否调整编排
- 每周把接管与拒答样本补进评测集，标注判定结论并注明来源日期，便于事后追溯
- 每月复审动作清单与权限档位，收回长期未使用的执行权限，权限面因此可控
常见坑
- 只看动作成功率，忽略接管率与越权拦截，系统在硬撑却被当成运行良好，风险会累积到难以挽回。
- 上游接口变更没有通知机制，智能体突然失效，业务高峰才被发现，临时修补往往顾此失彼，影响时间也被拉长。
- 评测集长期不扩充，回归结果越来越乐观，真实表现却在下降，团队容易对系统能力产生误判，也浪费预算。
- 权限只增不减，半年后没人说得清哪些动作能自动执行，交接与审计都变得困难，整改也缺少依据。
自检与验收清单
- 四类运维指标是否有统一看板与一致口径，并有人定期查看
- 工具变更是否有通知与回归流程，是否留有回归用例
- 评测集是否每周扩充，样本来源与判定结论是否留档
- 权限与动作清单是否按月复审，结论是否书面留存
常见问题
智能体运维和普通系统差在哪？
多了动作执行与边界两类问题。普通系统看可用性与错误率即可，智能体还要看它调用了什么工具、是否越权、结果是否被人工接管；这些指标需要专门的埋点与看板，靠通用监控很难覆盖。
多久做一次权限复审？
建议按月，至少按季度。复审内容包括动作清单是否仍被使用、权限档位是否仍匹配业务需要、审批人是否仍在岗。复审结论要留档，既便于交接，也能在审计时说明权限管理的实际执行情况。
出现批量失败先做什么？
先回退到上一个稳定配置，再定位是工具、提示词还是权限变更导致。顺序不能颠倒：边排查边运行会让错误持续扩散，而回退只需几分钟，能把影响面控制在最小范围，也给排查留出时间。