从看见问题到解决问题，Agent 正重新定义可观测

Vibe Coding 正在批量生产“日抛型软件”。它们可以在一天内被搭出来，却未必经得起一周后的真实业务流量、权限调用和故障追责。Gartner 预警，到 2028 年，公民开发者采用 Prompt-to-App 的方式可能使软件缺陷增加 2500%，并触发软件质量与可靠性危机。 “这些软件的产生，在目前传统的运维架构下是灾难”。观测云创始人&CEO 蒋烁淼在做客 InfoQ《C 位面对面》栏目时表示，这些软件一旦接入数据库、部署到服务器、开始承接真实业务，就成为一套需要持续运行、维护和治理的 Online System，同样需要日志、指标、链路、告警、权限控制和故障响应。但问题是，这些运维工具往往分散在不同系统中，运维团队需要为不断涌现的小应用逐个接入、配置和兜底。 更严峻的是，在 Agent 批量进入业务场景的当下，企业系统里的参与者不再只有人。过去那套围绕机器和服务展开的运维逻辑，接不住这些新的变量。今天再讨论可观测，面对的是一套新的运行逻辑。 为什么 Agent 爆发后，可观测更重要了？当可观测 Agent 开始自动诊断、修复问题，人类工程师的能力边界在哪里？在本期《C 位面对面》中，InfoQ 极客传媒总编辑&总经理王一鹏对话观测云创始人&CEO 蒋烁淼，一起聊聊 Agent 时代，可观测的变与不变。 Agent 爆发后，可观测更重要了 如果在 2018 年谈论可观测，大多数人的理解，大概还停留在指标、日志和链路追踪。但放到今天，再用这个“三件套”概括可观测性，显然太过狭隘了。 一个真实运行的系统，不只有几组指标和几条调用链。用户在页面上的行为事件、服务之间的依赖关系、应用运行时的内存状态、主机与服务的拓扑变化，都会影响最终的业务结果。比如，程序运行变慢的背后，可能存在内存泄露，这类问题往往需要通过 Profiling 生成的火焰图来定位，它是一种二进制格式，并不属于传统“指标、日志、链路追踪”中的任何一类。 在蒋烁淼看来，真正意义上的可观测，是“全面无死角的体检”，尽可能完整地记录系统运行中的信号，让团队能够还原系统发生了什么。 在 AI 技术出现之前，这件事的难点是数据太多、太专业。以 Profiling 生成的火焰图为例，它包含 I/O wait、内存对象大小、CPU 热点等信息，一般只有经验丰富的“老法师”才看得懂。但在 AI 技术出现以后，Agent 开始有机会承担读数据的工作：它可以跨越指标、日志、调用链、拓扑和运行时数据，先拼出系统的整体状态，再帮助工程师定位问题。 更深层的变化是，Agent 本身也在成为新的观测对象。 过去，运维团队主要观察的是服务器、容器、数据库和服务调用。随着越来越多的 Agent 开始深入业务，运维团队还需要看到 Agent 做了什么、调用了哪些工具、访问了哪些数据、是否越过了权限边界，以及每一步动作对业务系统造成了什么影响。 这也催生出一个新的方向：ABA，即 Agent Behavior Analytics，面向 Agent 行为本身的分析。“我们已经具备了这个功能。包括 OpenClaw、Hermes、Claude Code、Codex，都可以将数据收集到观测云平台上进行追踪。”蒋烁淼认为，在 AI 时代，无论是软件自身还是其运行时系统，都可以借助 Agent 更精准地捕获各类信号。帮助人类更高效地理解系统状态，也能反哺 Agent 自身，持续优化软件系统的运行表现。 不过，Agent 可观测并不等于把员工电脑上的每一个 Agent 都监控起来。像 Claude Code、Codex 这类桌面端 Agent，本质上更接近客户端软件。真正需要被看见的，是它们进入企业系统之后留下的行为轨迹：是否访问了 OA、调用了什么业务接口、读取了哪些数据、最终在系统中产生了什么操作。 蒋烁淼认为，最理想的 Agent 观测入口，是统一的 AI 网关。当模型调用、Token 收发和工具调用都经过这里，企业才能建立起一条可追溯的行为链路。 此外，当企业内非技术部门的人都能用 Vibe Coding 随手搭出一套上线生产环境的系统时，这些“影子 IT”天然就处于可观测的盲区。它们已经在生产环境里跑着，却没有任何人知道它们的状态。 这也是为什么，行业已经默契地将可观测摆在重要位置。Gartner 预测，到 2028 年，40% 已经部署 AI 的组织将采用专门的 AI 可观测工具，用于监测模型性能、偏差和输出。背后的逻辑很简单，当 AI 开始参与业务决策和执行，企业首先要解决的，就是要知道它正在做什么、为什么这么做，以及出了问题后如何追溯。 可观测平台，正在变成系统的“统一上下文” 当系统里同时跑着人、软件和 Agent，可观测平台承担的角色将发生什么变化？蒋烁淼的判断是：可观测性平台更像是系统的统一上下文平台。 无论是人类工程师，还是 Agent，要想做出正确判断，都需要依赖足够完整的上下文。对人类工程师来说，上下文决定了排障效率，如果数据没接全、日志没到位，再资深的专家也无从下手；对 Agent 来说，上下文决定它会不会陷入幻觉。 “任何人也好，AI 也好，它只能看到自己的事实，看不到的事实就是猜，猜就是幻觉，可能对，也可能错。你给出足够的上下文，它才能做出准确的判断。”蒋烁淼认为，当下模型本身的能力差距正在缩小，真正让不同 Agent 拉开差距的一大关键，就是拥有独特的上下文。 围绕这一判断，观测云的产品思路也在发生“变与不变”。 不变的是底层能力。数据采集、海量实时写入、低延迟查询，这些看起来不那么 AI 的能力，反而构成了统一上下文平台最难替代的部分。 蒋烁淼表示，观测云长期积累的数据采集能力不会变，这也是其与其他厂商的差异化之一。目前，观测云 DataKit 支持超过 600 种数据采集，能把数据接进来，也能理解不同技术栈里的字段含义、数据结构和标准化方式，让这些数据最终能够被统一查询、统一关联。不管使用者是人，还是 Agent，只有数据结构足够统一，后续分析才有基础。 另一个不变的核心底层能力是数据库。可观测平台的一大壁垒，在于采集足够多的数据后，能否低成本地处理、关联和理解这些数据。 据了解，观测云早在几年前就开始自研数据库，为了应对传统监控数据库在写入性能与查询性能上的局限，其自研的 GuanceDB 3.0 采用了完全存算分离的架构，将计算节点与存储节点彻底解耦。通过统一的数据管理、标签体系和查询语言（DQL），观测云实现了对全链路数据的深度关联。这种“数据湖仓一体化”的设计，也让跨团队协作不再需要频繁切换工具，沟通成本显著降低。 变的是产品交互与自动化方式。过去，Dashboard、低代码页面、人工编排的 Workflow，核心使用者都是人，需要人来手动搭建界面、设计流程。当 Agent 也成为可观测平台的使用者后，交互方式自然也需要发生变化。 比如，用户想要什么样的大屏、什么样的页面，可能完全不需要通过低代码工具一点点拖拽配置，几句自然语言描述，就能让 Agent 基于平台数据和 API 自动生成页面。 Workflow 也会发生类似的变化。过去告警出现后，人需要提前画好流程，设定每一步该怎么处理。如果 Agent 能够理解事件上