# 看不见的智能体，你根本没法运行 思科今年的一项调查发现，大多数公司正在运行自己无法妥善监控的智能体。一句话就道出了全部问题。智能体的失败方式和普通软件不一样——它会返回一个漂漂亮亮的成功，背地里却悄悄做错了事，而你只能在它行为的完整轨迹里看到，而不是在最终输出里。「智能体可观测性」之所以在 2026 年成为一门独立学科，原因正在于此。看清你的智能体到底做了什么——这个不起眼的能力，正在成为试点和生产之间的那条分界线。 - **Author:** Fedor Chishchin - **Published:** 2026-06-07 - **Tags:** methodology, agents, architecture - **Source:** https://fedorthinks.com/zh/blog/you-cant-run-what-you-cant-watch --- 有一个让人悄悄心惊的发现：思科今年的一项调查报告称， **71% 的组织正在运行自己无法妥善监控的 AI 智能体。** 把这句话还原成它本来的意思—— 大多数部署了智能体的团队，根本没有可靠的办法看清这些智能体在做什么。他们把某个自主运行的东西 放进了自己的业务里，然后闭上了眼睛。 这听起来很草率，但其实是个很容易掉进去的陷阱，因为智能体打破了常规监控所依赖的种种假设。 而业界的回应——一个一年前 [几乎还不存在](https://www.digitalapplied.com/blog/ai-agent-observability-2026-tracing-monitoring-stack-guide) 的全新品类，叫做**智能体可观测性**——恰恰说明了这个问题有多真实。哪怕你永远不会为它买一款工具， 这件事也值得理解，因为底下的道理很简单：看不见的东西，你就没法运行。 ## 智能体的失败，看上去像是成功 普通软件失败时声音很大。它抛出错误，返回 500，崩溃。你的监控就是为了抓住这种情况而建的。 智能体可不会给你这个面子。 智能体 [失败的方式看上去像成功](https://www.braintrust.dev/articles/agent-observability-complete-guide-2026)： 一个格式完美却错误的答案，一次根本不需要的工具调用，一个语法上有效、语义上却是胡来的动作。 它返回一个干净的 HTTP 200 和一个自信满满的结果，可实际上做错了事。这正是我在 [智能体对着错误的目标宣布胜利](/blog/agents-cant-finish-the-job) 一文里写过的同一种失败—— 而从外面看，这种失败是*看不见的*。什么都没报错。仪表盘是绿的。智能体悄悄把这个案例处理错了， 然后就继续往下走了。 这就是为什么传统监控在这里救不了你。盯着响应码和延迟，只能告诉你智能体*跑过了*。 它完全不能告诉你智能体做的事对不对——而「跑成功了，但做错了」恰恰是智能体的招牌失败模式。 ## 失败藏在轨迹里，不在输出里 智能体难以观察还有第二个原因。它们的错误通常不在任何单独一步里——而在*序列*里。 一个智能体读取、决定、调用工具、读取结果、再决定、再调用另一个工具。每一次单独的调用看上去 都完全正常，而整条路径却悄悄偏离了轨道。正如一份指南所说，多轮失败 [在单次调用这个层面是看不见的，只有在完整的因果轨迹里才会显现](https://www.braintrust.dev/articles/agent-observability-complete-guide-2026)。 所以观察一个智能体，不等于记录它的最终答案。它意味着把整条链条都捕捉下来——每一次模型调用、 每一次工具执行、每一个推理步骤——作为一条你可以回放、可以跟着走的轨迹。这种差别在出事故时尤为明显： 有这条轨迹的团队，能在几分钟内回答「它为什么这么做」；而没有埋点的大多数团队， 只能耸耸肩,重跑一遍，盼着这次它表现得不一样。随着智能体走进碰钱、碰客户的工作里， 这道鸿沟就不再是「有了更好」那么轻松了。 ## 这是「看，而不是批准」不光鲜的另一半 我一直主张，工作的重心正在从 [批准每一步转向观察整个系统](/blog/from-approving-to-watching)—— 制定策略，在某些地方看起来不对劲时介入。让人不太舒服的后续是：你只能观察你已经埋了点的东西。 如果你根本没有轨迹可监控，「我会盯着它」就是一句空话。整个「看，不批准」的模式， 悄悄假设了一个可观测性层，而大多数团队跳过了搭建它这一步。 这正是企业级厂商正抢着填补的缺口。Hyland 新推出的 [Control Tower](https://www.helpnetsecurity.com/2026/06/01/hyland-platform-innovations/) 被定位成一个指挥中心，它对照 KPI 跟踪智能体，并能在某个智能体越过护栏时实时暂停或调整它—— 而它的智能体生命周期管理，把智能体框定成一个你从设计一路管理到退役的东西，而不是一个 你启动后就忘掉的东西。剥掉企业级的包装，道理还是同一个：没有监督的智能体扩张不叫扩张，叫赌博。 ## 实际该怎么做 你不需要一个平台才能认真对待这个原则。哪怕是个人项目： - **追踪整个会话，而不只是结果。** 按顺序记录每一次工具调用和每一个决定，这样出问题时 你能回放路径，而不是靠猜。最终输出是最没有信息量、最不值得留的东西。 - **盯住「成功了，但做错了」，而不只是错误。** 你的告警应该抓住语义层面的失败—— 那个返回了 200 却做错事的智能体——这意味着要对照标准去评估输出，而不只是确认它跑过了。 - **把智能体当成有生命周期的东西来对待。** 它会随着模型更新、世界变化而漂移； 这种漂移大多是在演示之后悄悄发生的。给它定个周期重新检查，就像你会定期审查任何 一个可能悄悄腐烂的系统一样。 - **如果你看不见它，就别让它无人监督地行动。** 老实说就一条规则：一个你观察不到的智能体， 就是一个你不该让它单独去做任何有后果的事的智能体。 ## 归根结底 关于智能体那个激动人心的故事，讲的是自主——它们替你去做事，不用你管。不光鲜的真相是： 没有可观测性的自主不是独立，而只是失明。一个像普通软件那样失败的智能体，你能抓住。一个靠递给你 一个自信满满、打着绿色对勾的错误答案来失败的智能体，只有当你建好了「看一眼」的能力时， 你才抓得住。 所以在你让一个智能体去运行任何要紧的东西之前，问一个朴素的问题：如果它此刻做错了事， 我会知道吗？如果答案是不会，那你手里就不是一个生产级的智能体。你手里是一个没人监控的智能体—— 而那不过是一起还没被人注意到的事故罢了。