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 能够理解事件上下文，并结合 Runbook 在可控边界内做判断，Workflow 就有可能变成 Agent 自循环、自决策的一部分。
“我们要推行的方案肯定是面向未来的 AI-Driven 自动化，而不是人类画流程图的自动化。虽然这件事可能目前存在争议，但如果放眼五年后，AI 不可能还以人类指手画脚的方式运行。”蒋烁淼表示，AI 的优势在于，它可以持续、细致地参与到每一次工作流和事件处理中。“它的注意力可能会飘散，但它不会偷懒。”
但要让 AI 实现这种持续、细致的参与，一个巨大的前提是，整个链路的信息完全贯通。现实却是，研发、运维和业务之间的上下文往往彼此割裂，数据不少，但能支撑决策和行动的却不多。从打通上下文，到让人和 Agent 都能看懂数据，再到让 Agent 真正能在生产环境中可靠行动——观测云的思路是，沿着这三层问题逐层下探。
从看得懂到能上岗，观测 Agent 进入工作流
第一层，是先打通上下文。
研发、运维和业务之间长期存在上下文断层。过去，生产环境里的数据往往掌握在运维手里，研发看到的是代码和本地环境，业务看到的是用户反馈和业务结果。一旦线上出现问题，几方需要反复沟通，排障效率很大程度上取决于人能不能把上下文说清楚。到了 Vibe Coding 时代，这种割裂感进一步加剧。代码生成的速度更快了，如果 Coding Agent 看不到线上真实运行态数据，它对问题的判断就只能停留在代码和局部信息里。蒋烁淼把这种状态形容为“幻觉对幻觉的大厮杀”：研发看不到生产环境的数据，就只能猜；AI 看不到真实上下文，也只能猜。
观测云 OWL 试图解决的，就是这层矛盾。它能提供 CLI 和 MCP Server 两种接入形态，将观测云的指标、日志、事件、监控器、仪表板、APM 等核心能力封装为标准化工具。研发工程师可以将 OWL 装到 Claude Code 或 Codex 等主流 Coding Agent 中，直接让 AI 自动查询生产环境的观测数据并执行根因分析，不需要获得生产环境的任何访问密钥。
第二层，是让人和 Agent 都能看懂数据。
可观测平台长期面临的一大矛盾是，数据越采越全，使用门槛也越来越高。面对复杂的查询语言和数据模型，业务和研发人员往往无从下手。
这正是 Obsy AI Copilot 想要解决的核心问题。蒋烁淼提到，早期的 Obsy AI Copilot 的底层形态更接近 Dify 这类固定工作流：看到日志后，按既定流程做定位分析，最后生成总结。目前，Obsy AI Copilot 底层 Runtime 已经被更新为更接近 Manager Agent 的形态，它不是一个纯粹 ChatBot，是注册了 Skill、上下文和大量 System Prompt 的 Agent。
比如，用户看到一条日志，可以让它分析相关性；不知道监控器怎么配，可以让它帮忙配置；需要迁移或新建 Dashboard，也可以直接用自然语言描述需求，让它根据观测对象、指标 Schema 和数据结构自动生成。
“Obsy AI Copilot 本质上，就是帮助人类更好地在自己的界面中使用观测云产品，更好地和各种 Agent 做验证。除了早期 1.0 版本里比较简单的日志问答、产品使用帮助之外，我们现在也引入了更多能力，比如自动帮客户配置监控器，以及用自然语言生成 Dashboard。”蒋烁淼表示，过去做 Dashboard 是可观测平台里非常重的工作，用户既要理解自己的观测对象，也要熟悉平台采集的指标。现在，用户可以直接描述需求，AI 会根据观测对象、指标 Schema 和数据结构，自动生成对应的仪表盘。
第三层，是让 Agent 真正能在生产环境中可靠行动。
在真实生产环境里，发现问题只是开始。一个完整闭环，还需要有人，或者说有 Agent，继续完成诊断、协同和行动。全新升级的 Guance AI Agent Teams，瞄准的正是这个环节：帮助企业构建可落地、可协作、可执行的 AI 工作团队。它可以被放进飞书、钉钉、微信等协作场景中，用户可以在群聊里直接问它问题。并且它更主动，可以围绕生产环境事件持续参与分析和协同。
但生产环境里的 Agent 一旦具备行动能力，风险也会随之上升。蒋烁淼提到，观测云在产品设计上做了明确区分：放在 IM 和普通会话里的 Agent 默认是只读的，只能查数，不能执行危险操作；真正涉及操作的能力，会放在 Task 页面里，并由企业把允许 AI 执行的动作封装成 API。
与通用 Agent 相比，Guance AI Agent Teams 的区别不是重新发明一个 Agent Runtime。蒋烁淼认为，单纯从 Runtime 角度看，今天搭一个 Agent 并不难，真正难的是把 Agent 放进具体场景里，给它足够准确的上下文、合理的角色定位，以及可持续积累的记忆。
这种“场景记忆”也是观测云正在强化的能力。据了解，观测云的“笔记”功能过去主要用于故障发生时记录分析过程，现在已经升级为由 AI 自动生成故障笔记：当用户与 AI 完成一次问题排查对话后，AI 会将分析过程、处置经验和相关结论沉淀到平台中，人类也可以随时查看。7 月 3 日，观测云笔记宣布更新，成为 Guance AI Agent Teams 不断迭代更新的长期记忆层，让 Agent 团队能够持续学习，提升执行准确度。这也是观测 Agent 从“看得懂”走向“能上岗”的关键一步。
此外，Guance AI Agent Teams 还有内建的排障方法论，能把告警分诊、影响面判断、假设生成、证据收集、根因定位、动作建议、审批执行、结果验证这些流程产品化，并将治理能力作为产品能力交付：默认只读、最小权限、高风险动作审批、操作留痕、证据链可追溯、处置后可验证。
从 OWL 到 Obsy AI Copilot，再到 Guance AI Agent Teams，观测云正在重构一条完整的故障处理链路。OWL 负责打通数据与工具的连接，让上下文不再割裂；Obsy AI Copilot 负责降低理解门槛，让人看得懂、验证得了；Guance AI Agent Teams 负责在权限和边界的约束下，将诊断和行动推进到生产环境最后一公里。
三层能力叠加起来，构成了可观测性从“看得懂”到“调得动”再到“控得住”的完整闭环。
结束语：Agent 负责执行，Builder 负责定义结果
当我们重新审视可观测性的价值时，会越来越清晰地发现，Agent 没有削弱可观测性的价值，反而把它从后台推到了系统中央。
过去十年，AIOps 这个概念被反复提起，但如果一个系统连完整的运行态上下文都没有，所谓智能运维就无从谈起。蒋烁淼对 AIOps 的判断很直接，“不管是 AI 还是人类，或者哪怕你用算法去驱动，如果你连整个系统发生了什么的上下文都没有，这真的不叫 AIOps，这叫做神仙 Ops。”
这也是为什么，在 Agent 时代，可观测的重要性能够被重新放大。AI 要判断，就需要事实；要行动，就需要边界；要减少幻觉，就需要足够完整、实时、可验证的上下文。没有这些，Agent 只是把人的猜测换成了机器的猜测。从 OWL 到 Obsy AI Copilot，再到 Guance AI Agent Teams，观测云试图重构的，正是这样一套工作方式。
但这并不意味着人会退出循环。蒋烁淼认为，人类工程师的角色会变得更重要，只是关键能力变了。过去，工程师的价值常常体现在亲手写代码、手动查问题、逐步执行流程。未来，当 Agent 可以完成越来越多执行动作，人更关键的能力会变成：能不能提出正确的问题，能不能定义清楚目标，能不能提供足够上下文，能不能验证 AI 给出的结果。
蒋烁淼把这类人称为 Builder——这是一类更懂技术架构、能活用工具、能把大问题拆成小问题，并对最终结果负责的人。
当一个团队里每个人都是 Builder 而不只是 Coder，企业的研发和运维模式会发生什么变化？这会是一个更好协作的时代，还是一个超级个体孤军奋战的时代？这些问题，将留给每一位正在思考 AI Native 工程体系的人去回答。
