看不见的智能体，你根本没法运行

有一个让人悄悄心惊的发现：思科今年的一项调查报告称， 71% 的组织正在运行自己无法妥善监控的 AI 智能体。 把这句话还原成它本来的意思—— 大多数部署了智能体的团队，根本没有可靠的办法看清这些智能体在做什么。他们把某个自主运行的东西 放进了自己的业务里，然后闭上了眼睛。

这听起来很草率，但其实是个很容易掉进去的陷阱，因为智能体打破了常规监控所依赖的种种假设。 而业界的回应——一个一年前 几乎还不存在 的全新品类，叫做智能体可观测性——恰恰说明了这个问题有多真实。哪怕你永远不会为它买一款工具， 这件事也值得理解，因为底下的道理很简单：看不见的东西，你就没法运行。

智能体的失败，看上去像是成功

普通软件失败时声音很大。它抛出错误，返回 500，崩溃。你的监控就是为了抓住这种情况而建的。 智能体可不会给你这个面子。

智能体 失败的方式看上去像成功： 一个格式完美却错误的答案，一次根本不需要的工具调用，一个语法上有效、语义上却是胡来的动作。 它返回一个干净的 HTTP 200 和一个自信满满的结果，可实际上做错了事。这正是我在 智能体对着错误的目标宣布胜利 一文里写过的同一种失败—— 而从外面看，这种失败是看不见的。什么都没报错。仪表盘是绿的。智能体悄悄把这个案例处理错了， 然后就继续往下走了。

这就是为什么传统监控在这里救不了你。盯着响应码和延迟，只能告诉你智能体跑过了。 它完全不能告诉你智能体做的事对不对——而「跑成功了，但做错了」恰恰是智能体的招牌失败模式。

失败藏在轨迹里，不在输出里

智能体难以观察还有第二个原因。它们的错误通常不在任何单独一步里——而在序列里。 一个智能体读取、决定、调用工具、读取结果、再决定、再调用另一个工具。每一次单独的调用看上去 都完全正常，而整条路径却悄悄偏离了轨道。正如一份指南所说，多轮失败 在单次调用这个层面是看不见的，只有在完整的因果轨迹里才会显现。

所以观察一个智能体，不等于记录它的最终答案。它意味着把整条链条都捕捉下来——每一次模型调用、 每一次工具执行、每一个推理步骤——作为一条你可以回放、可以跟着走的轨迹。这种差别在出事故时尤为明显： 有这条轨迹的团队，能在几分钟内回答「它为什么这么做」；而没有埋点的大多数团队， 只能耸耸肩,重跑一遍，盼着这次它表现得不一样。随着智能体走进碰钱、碰客户的工作里， 这道鸿沟就不再是「有了更好」那么轻松了。

这是「看，而不是批准」不光鲜的另一半

我一直主张，工作的重心正在从 批准每一步转向观察整个系统—— 制定策略，在某些地方看起来不对劲时介入。让人不太舒服的后续是：你只能观察你已经埋了点的东西。 如果你根本没有轨迹可监控，「我会盯着它」就是一句空话。整个「看，不批准」的模式， 悄悄假设了一个可观测性层，而大多数团队跳过了搭建它这一步。

这正是企业级厂商正抢着填补的缺口。Hyland 新推出的 Control Tower 被定位成一个指挥中心，它对照 KPI 跟踪智能体，并能在某个智能体越过护栏时实时暂停或调整它—— 而它的智能体生命周期管理，把智能体框定成一个你从设计一路管理到退役的东西，而不是一个 你启动后就忘掉的东西。剥掉企业级的包装，道理还是同一个：没有监督的智能体扩张不叫扩张，叫赌博。

实际该怎么做

你不需要一个平台才能认真对待这个原则。哪怕是个人项目：

• 追踪整个会话，而不只是结果。 按顺序记录每一次工具调用和每一个决定，这样出问题时 你能回放路径，而不是靠猜。最终输出是最没有信息量、最不值得留的东西。
• 盯住「成功了，但做错了」，而不只是错误。 你的告警应该抓住语义层面的失败—— 那个返回了 200 却做错事的智能体——这意味着要对照标准去评估输出，而不只是确认它跑过了。
• 把智能体当成有生命周期的东西来对待。 它会随着模型更新、世界变化而漂移； 这种漂移大多是在演示之后悄悄发生的。给它定个周期重新检查，就像你会定期审查任何 一个可能悄悄腐烂的系统一样。
• 如果你看不见它，就别让它无人监督地行动。 老实说就一条规则：一个你观察不到的智能体， 就是一个你不该让它单独去做任何有后果的事的智能体。

归根结底

关于智能体那个激动人心的故事，讲的是自主——它们替你去做事，不用你管。不光鲜的真相是： 没有可观测性的自主不是独立，而只是失明。一个像普通软件那样失败的智能体，你能抓住。一个靠递给你 一个自信满满、打着绿色对勾的错误答案来失败的智能体，只有当你建好了「看一眼」的能力时， 你才抓得住。

所以在你让一个智能体去运行任何要紧的东西之前，问一个朴素的问题：如果它此刻做错了事， 我会知道吗？如果答案是不会，那你手里就不是一个生产级的智能体。你手里是一个没人监控的智能体—— 而那不过是一起还没被人注意到的事故罢了。