AIOps 和 AgentOps，观测云已经实现了。
AI 概念插图 / 从分散的异常信号，到共同完成的工程工作
过去的 AIOps，都是骗人的。
作为观测云 CEO，我知道这句话很重。我的批评针对一个承诺：把告警降噪、异常检测、规则自动化这些局部能力，包装成已经能够理解系统、解决问题的完整智能，然后让客户为这个承诺付钱。
出了故障，平台提醒你异常了，工程师开始查日志；平台列出几个可能原因，工程师继续翻代码；平台生成一份分析报告，工程师负责修改、测试、发布，再回头确认问题有没有解决。智能化的名字换了几轮，最费力的工作还在人手里。
算法当然有价值，减少告警也能节约时间。但如果承诺的是替团队承担工程工作，最后交付的却只是更多需要人处理的提示，这个承诺就没有兑现。尤其当一个系统给出的建议永远是“请检查相关配置”，客户完全有理由追问：我买来的智能，到底替我做了什么？
今天，我愿意用观测云自己的实践回答这个问题。我们已经让 AI 参与真实系统的调查与修复，并把这套能力连接到代码、开发工具和团队协作中。真正的 AIOps 已经落地，而它的价值正在覆盖整个软件开发过程。
先说两件已经发生的事
第一件就在观测云内部。我们团队已经通过 AI Agent 收集和使用自身系统产生的可观测性数据，开展系统异常分析、故障定位和问题修复。很多编码修复过程已经半自动化，AI 完成调查和代码修改，人主要负责审核。
这带来的变化很具体。过去，工程师拿到一条告警，需要从零开始搜集材料，形成判断，再把判断变成代码。现在，在这些已经半自动化的修复任务中，工程师可以直接审查 AI 提交的判断与改动：证据是否支持结论，修改是否准确，验证是否充分。
人的专业能力依然重要，而且有了更集中的使用方式。大量查找、比对和编写工作交给 AI，工程师把精力放在判断与把关上。观测云自己的系统每天都要运行，我们对这套能力的要求，来自真实的生产责任。
第二件来自一个客户。一个 bug，客户排查了三天，始终没有结果。我们帮助客户通过一个 AI，用了 25 分钟定位到具体源代码，并给出修复建议。
3 天
客户此前排查，尚未定位
25 分钟
一个 AI 定位源码并给出修复建议
三天，二十五分钟。这里真正值得 CTO 注意的，还有结果的具体程度：问题已经被推进到源代码层面，工程师拿到的是可以核对、可以继续处理的定位与建议。原先长时间没有进展的调查，终于能够进入修复阶段。
这一次定位不能代表所有故障都能在二十五分钟解决，但它已经说明，AI 可以承担有实质价值的工程调查。对正在等待结果的团队来说，生产力的提升就体现在这里。
观测云为什么能够做到？答案在下面这五组相互连接的能力里
第一，完整采集现场信号，把数据关联起来，再让它们具有语义。
很多人一提可观测性，仍然只想到 MLT：Metrics、Logs、Traces，也就是指标、日志和链路。这三类数据很重要，但真实问题经常跨越它们的边界。一个接口慢，可能要查到函数；用户操作失败，需要还原他之前做了什么；异常突然出现，还得知道刚刚发布或修改了什么。
观测云采集和组织的信号覆盖这些调查需要：
Metrics、Logs、Traces：
记录系统状态、执行细节和请求路径，帮助确定异常范围并追查经过。
Profiling：
把 CPU、内存、I/O 等消耗推进到方法和调用栈，为代码级性能调查提供证据。
RUM Events：
记录真实用户的访问、交互、前端错误与体验变化，看到系统在用户那里实际表现如何。
Session Replay：
还原已采集会话中的操作现场，为理解错误发生前后的过程提供线索。
Security Context：
将身份、访问、权限以及安全事件相关信息纳入调查，帮助判断异常背后的安全背景。
Change Events：
保留发布、配置和基础设施变更线索，支持比较变化前后的系统表现。
错误聚合：
把重复报错归并成可持续追踪的问题，呈现发生次数、分布和演变，避免调查淹没在同类记录中。
AI 概念插图 / 多种信号在关联与语义中形成可用的上下文
这些能力能够沿着问题继续深入。例如，开启相应采集后，链路与 Profiling 的关联可以把一次慢请求推进到耗时方法；错误详情则可以根据已有数据关联链路、日志、用户会话与重放，帮助核对现场。
产品实景｜调用链分析：请求火焰图、服务耗时占比与关联日志入口（观测云演示环境）
接下来更关键的一步，是让这些记录指向同一个系统、同一次请求、同一个版本。服务、资源、环境、版本、请求和会话标识，把分散信号连接起来；依赖关系、团队归属、责任与业务含义，再构成 AI 可以使用的语义层。
AI 需要知道，眼前这个服务属于哪条业务路径，依赖什么，谁负责，什么表现才算符合目标。观测云的统一目录提供实体、关系、归属和观测入口的组织能力，让系统知识有地方保存和使用。完整的语义也需要团队维护必要的业务信息，模型无法凭空猜出你的责任划分与业务目标。
产品实景｜统一目录：系统属性、组成实体与观测入口（观测云演示环境）
我们强调完整采集，指的是具备覆盖主要工程调查信号的体系。具体能查到什么，取决于实际接入、采样、保留和关联配置。把这些基础做好，AI 才能沿着线索追下去。
第二，AI Native，让平台能力可以直接被 Agent 调用。
AI 做调查，需要反复取证。先看异常集中在哪里，再看相关请求和版本，发现新的线索后继续查。调查路线会随着结果改变，平台必须支持这种工作方式。
观测云把大量查询、分析和管理能力开放为面向 AI 调用的 API 与工具，并通过 MCP、CLI 接入 Agent。OWL 提供指标、日志、事件、APM、RUM 等平台能力的工具入口，让 Agent 能发现数据、执行查询，再根据返回结果决定下一步。
另一个入口是 obs-mcp，它把 Agent Teams 的任务协作能力接入支持 MCP 的 AI 客户端。开发者在本地使用 coding Agent 时，就能接入观测 Agent 的调查能力。直接查询平台数据、委托专业 Agent 调查，两种方式都能让本地开发工作获得生产环境的依据。
第三，Agent 能主动查代码、找知识，持续补足上下文。
生产数据给出了现场，源码解释系统为什么这样运行，外部文档则能帮助核对组件行为和已知问题。有效调查经常需要同时使用这几类材料。
Agent Teams 内置的 git-rg 及配套 Skill，允许 Agent 在授权范围内检索客户的 GitHub、GitLab 代码库，查找函数、配置和错误信息，并定位到文件与行号。调查可以指定分支、标签或提交，让正在阅读的源码与目标版本对应。
产品实景｜Agent 技能：git-rg 远程代码搜索与可观测性分析（观测云演示环境）
Agent 还能够使用网页搜索能力，从互联网上查找相关技术文档、已知问题和知识，补充任务上下文。外部资料需要结合版本与现场证据核对，再形成可以验证的判断。查到一篇相似故障文章，是新的线索；能解释当前系统的表现，才有理由推进修复。
第四，把 Agent 加入飞书、钉钉，让它成为同事。
工程协作大量发生在群里。告警在那里出现，负责人在那里讨论，调查结果也在那里交接。AI 要承担工作，就应该能进入这些日常流程。
观测云支持将 Agent 接入飞书、钉钉等消息渠道。团队可以在研发群、值班群或项目群中向它提问、分配任务、补充上下文，并继续追问结果。配置好事件接入后，告警或外部系统消息还能自动触发调查，再把分析投递到指定会话。
它可以承担巡检、异常分析、发布跟进等职责。大家能够在熟悉的协作空间里，把一件具体工作交给它，再检查它交回来的结果。“成为同事”的含义，就落实在接任务、推进工作和交付结果这些事情上。
第五，让 Agent 之间协作，把线上问题接到本地代码修改。
线上观测 Agent 能取得运行数据，本地 coding Agent 能访问开发工作区、修改代码和运行测试。把它们连接起来，调查结果就有了直接进入修复的路径。
开发者配置好 obs-mcp 后，可以让本地 coding Agent 委托观测 Agent 调查线上问题，取得证据与结论，再在本地自动编写修复代码、执行必要验证。材料不够时，它还能继续请求调查；工程师随后审核改动和验证结果。
Agent Teams 内部也提供 A2A 任务委派：一个 Agent 可以把专业工作交给另一个已授权 Agent，再汇总结果继续推进。当前这项原生 A2A 能力处于 Beta，适用于 Agent Teams 服务内的 Agent；外部 coding Agent 通过 MCP 参与任务协作。这两条连接路径各有清晰的使用范围。
产品实景｜Agent 协作（Beta）：名片、能力说明与调用授权入口（观测云演示环境）
由此，工程师可以把工作分给具有不同数据、工具和专业能力的 Agent。线上调查与本地开发开始连续进行，人也能分别检查调查依据、代码改动和最终效果。
把这套协作放到一次问题处理中，就容易理解了
下面是一个说明工作方式的示例，独立于前面的客户案例。假设团队已经接入相关数据，为观测 Agent 配好事件触发和消息渠道，本地 coding Agent 也已连接 MCP，并获得相应的任务和代码权限。
一次发布之后，线上错误增加。事件触发观测 Agent 调查，它比较异常时间、受影响版本和请求，关联错误、日志、链路与变更记录，把已经确认的事实、待验证的原因和影响范围发到飞书群里。
本地 coding Agent 通过 MCP 获取调查结果，检查对应版本的代码。若它需要判断某个输入是否在线上触发了特定路径，可以继续委托观测 Agent 查询。两边通过新的证据修正判断，直到形成足以支持修改的依据。
随后，coding Agent 在本地编写修复，运行与问题相关的测试，把代码差异、修改理由和验证结果交给工程师。工程师完成审核，团队按既有流程发布。
发布之后，观测 Agent 继续检查受影响请求的错误、延迟与体验是否改善。如果结果不符合预期，调查还要继续；确认有效后，团队将结论与处理方法沉淀下来，供后续任务使用。
这条工作链成立，需要客户端处于可用状态，任务、工具与权限已经接通。MCP 提供协作入口，实际执行仍发生在各自配置好的环境中。
在这样的流程里，AI 接手了调查、代码编写和验证中的大量执行工作。工程师能够把注意力集中到几个关键判断上：结论是否成立，修改是否正确，发布后是否真的改善。
走到这里，AIOps 已经不足以概括它的价值
同一套能力还可以向需求和设计阶段延伸。产品提出一个改进需求时，团队可以先让 Agent 分析真实用户在哪些步骤反复失败、等待或退出，结合业务结果判断优先级。需求讨论从一开始就有运行事实参与，技术团队也更容易说清要改善什么。
进入设计阶段，可以结合服务依赖、历史性能和已有故障，检查方案会影响哪些路径，并提前定义上线后如何判断成败。到了开发阶段，coding Agent 既能读代码，也能通过观测 Agent 获取生产背景，了解哪些路径使用频繁、哪些边界真实出现过。
测试同样受益。线上错误、用户操作和历史问题可以帮助团队补充有价值的回归场景，验证修改是否覆盖实际遭遇。观测云已有面向代码评审、测试和发布前检查的 Agent 应用场景，这些工作能够按团队需要配置相应的工具和环境。
发布时，把变更记录与系统表现联系起来；上线后，继续检查稳定性、用户体验和业务目标。结果再进入下一轮需求、设计与开发。同一批事实由产品、研发、测试和运维共同使用，Agent 也能够在各阶段接续工作。
这就是我所说的全智能：智能参与软件开发的整个过程，运行中的事实持续影响下一次决策。人定义目标、约束和关键选择，Agent 在授权范围内执行，系统产生的结果又回到团队面前接受检查。
我们愿意用这个标准接受检验
今天的观测云已经能够支持这样的工程协作。我们自己在用，客户也已经获得了具体结果。模型能力很重要，围绕模型建立的完整体系同样重要：数据要采得到，信号要关联得上，语义要说得清，工具要调用得到，代码与知识要查得进去，任务要推进得下去，结果还要验证得出来。
其中任何一环长期依赖工程师手工补齐，都可能让智能再次停在承诺上。把整条工作链打通，才有资格说 AIOps 真正落地了。
作为观测云 CEO，我愿意明确宣布：我们已经把 AI 带进真实工程工作，并让它从运维现场延伸到软件开发全过程。请拿一个真实问题来检验我们，看 Agent 能取得什么证据、推进到哪一步、交付什么结果，以及你的团队因此节省了多少工作。
过去，客户为 AI 的承诺付钱。今天，观测云应该用完成的工作，证明这笔投入的价值。
什么是观测云？
观测云是一款 AI 时代的全域数据观测平台，全面覆盖 App、Web、后端、中间件、基础设施与云平台的全链路监控，集成 650+ 主流技术栈与云服务。连接开发、运维与业务团队，打破数据孤岛，以海量数据与统一为核心，让企业实现数据的统一存储、统一查询与统一展示，最终让一切数据都能被理解与利用，让云上数据成为企业可执行的洞察。已服务1000+ 家企业，覆盖 AI、金融、零售、制造等行业。
- 上一篇：睿创微电子发布新型红外探测器封装方案——BCoS封装，让集成更简单高效
- 下一篇：
