把 AI 智能体当软件管,还是当员工管?

PART 01

它不是一段服务，而是一个会自己做决定的岗位

传统软件崩了会报错，日志里查得到。智能体不一样：它可以全程返回 200，状态码正常，给出的判断却越来越离谱。工具选错、语气跑偏、答案编得像模像样却站不住脚——这些都不会触发可用性告警。

智能体的故障不再宕机，而在悄悄跑偏。

所以不能只用服务可用性指标管它，它更接近一个岗位：不只看他来没来上班，还要看活干得对不对。

2026 年 9 月 Guild.ai 的一份调研把这个落差摆得很清楚：96.4% 的 IT 决策者相信自家有完整准确的智能体清单，但只有 42.7% 有集中监控面板，31% 能用自动开关立刻停掉异常智能体；66.7% 的组织过去一年至少发生过一次智能体相关运营事件。自信和能力之间，差的是一整套运行机制。

PART 02

四类信号，先说清楚什么叫生病

运维的第一步不是建看板，是定义异常。通常要盯四类信号。

一是质量漂移。同样的输入，输出准确率慢慢往下走。公开的治理资料给过参考阈值：任务完成率比上线基线掉 3 个百分点以上就该报警。这种变化不会自己说话，只能靠抽样比对发现。

二是工具调用失败。智能体调外部接口和代码解释器，正常情况下也有 3% 到 15% 的失败率，这是公开指南的经验区间。难点是这个数字本身正常，你要盯的是走向，不是绝对值。

三是成本异常。多轮对话里单次会话的 token 消耗会滚雪球，尤其当工具调用又触发新一轮推理时。账单上涨往往是最早的异常信号，最容易被当成业务量涨了。

四是越界行为。只被授权查询客户库的智能体，在某些提示词条件下尝试写入；本该总结文档的，被诱导去调一个不该碰的接口。Dynatrace 2026 年针对 919 位负责人的调研中，安全合规以 52% 与规模化监控困难的 51% 并列成为最大障碍。

账单上涨往往是最早出现的异常信号。

PART 03

先有具名责任人，再谈监控工具

很多团队的第一反应是先上一套可观测平台。但答案有点反直觉：真正拉开差距的是责任归属，不是工具。

乾元云数在项目复盘里常看到的情况是，监控工具早就买了，告警却没人认领。多份 2026 年企业调研指向同一结论：进入生产环境的智能体绝大多数都有具名责任人，且这个人有权在不逐级上报的前提下做决策；所有权不清往往和监控缺失绑在一起，没人负责就没人建看板。

所以顺序是：上线前先写下三样东西——归谁（写人名，不写部门）、出问题谁能一键停掉、它变了什么要记下来。第三样最容易被忽略：提示词改了一版、知识库换了一批、底层模型升了一次级，每一次都要留记录，否则三个月后你解释不清它为什么变了。

没人负责，就没人建看板；没人建看板，就没人在第一时间发现异常。

PART 04

值班不是盯屏幕，是三个固定节奏

运维最容易被做成装个看板然后没人看。更实际的做法，是把检查嵌进已有的工作节奏。

每周，责任人抽样二十条左右的真实输出，人工判一遍质量。这一步没有替代方案，自动评分只能告诉你分布变了，不能告诉你对不对。

每次变更，跑一遍回归评测集：公开数据显示，每次提示词变更都跑自动评测的团队，生产回滚率约 9%；不跑的是 47%。

每季度，复盘一次去留。业务口径变了、使用人已经不用它了，该下线就下线。急停开关也要在这个节奏里演练一次——一个依赖故障智能体本身、或依赖某位管理员刚好在岗才能触发的开关，等于没有。

急停开关不演练，就等于没有。

乾元云数在服务客户时的观察是：智能体项目真正拉开差距的，往往不是谁的模型更强，而是谁先把运行机制建起来了。

写在最后

智能体不像服务器，买回来挂着就能跑。它更像一个刚入职的岗位，需要有人带、有人看、有人定期评估。

把谁来管这件事在上线前写清楚，比上线后再补一套监控省事得多。你家的智能体现在是谁在管，是具名的人，还是大家都在管？欢迎留言。

上线只是起点，会管才是能力——四类信号、具名责任人、三个节奏，缺一样都会在某个凌晨出其不意。

如果这篇对你有启发，欢迎点赞、在看、转发给正在搭智能体的同事。

— END —