观测云基于 AI Agent Teams 能力的场景实践
观测云 AI Agent Teams 致力于将可观测性数据、智能分析与自动化运维能力深度结合，打造面向企业数字化系统的智能运维助手。团队围绕日志、指标、链路、事件等多源数据，构建具备问题理解、根因分析、告警降噪、故障诊断和处置建议能力的 AI Agent 体系，帮助用户更快发现问题、定位问题并推动问题闭环。通过持续探索大模型与可观测性场景的融合，观测云 AI Agent Team 正在让复杂系统的运维分析变得更高效、更智能、更可信。
观测云 AI Agent Teams 适合以下场景：
- 为研发、运维、测试、数据分析、可观测排查、知识整理等职责创建专属 Agent；
- 按成员或角色控制 Agent 的可见和可用范围；
- 通过 Skill 固化 Agent 的工作方法，例如代码评审、测试生成、文档整理、浏览器自动化等；
- 通过 MCP 服务连接外部工具或内部系统，并按 Agent 职责分配可用能力；
- 将 Agent 接入微信、钉钉、飞书等外部 IM，让团队在熟悉的消息平台中协作；
- 创建任务或定时任务，让 Agent 围绕明确目标持续执行、记录过程并沉淀结果。
本次场景实践主要包含三类场景：
- 与 Vibe Coding Agent 结合使用，如使用 Codex 通过 MCP 调用观测云 Agent Teams 的 Agent 返回根因分析，并结合源码给出修复方案。
- 结合飞书、钉钉、企业微信、Slack 等 IM 环境，通过机器人调用观测云 Agent Teams 的 Agent，实现 @机器人即可进行问题分析。
- 在观测云 Agent Teams 的 Agent 控制台发起问题分析对话，通过调用观测云可观测数据以及如通过 kubectl 的真实业务运行情况，实现问题的根因分析和故障修复
1. 实践总览
本实践围绕自建的“观测云优选系统 Demo”建设三类 AI Agent Team 场景：源码侧 RCA、IM 群聊排障、以及从Agent控制台业务入口发起的受控恢复。三个场景共用观测数据底座，但入口、交互方式和权限边界不同。
图 1：观测云 AI Agent Team 三类实践场景总体架构
| 场景 | 入口 | 核心 Agent | 主要能力 | 适合展示 |
|---|---|---|---|---|
| 场景一 | Codex / Claude Code | RCA Agent | 结合源码、日志、链路、指标输出 RCA 与修复建议 | 研发排障、代码级定位 |
| 场景二 | 飞书/钉钉/企业微信/Slack | IM 消息排障助手 | 群聊提问、告警通知、RCA 摘要、排障协作 | 值班协同、告警到群 |
| 场景三 | 在观测云Agent 控制台界面分析包括不限于告警/Dashboard/Service/业务等 | RCA Agent + ops-controlled-mcp | 调查、审批、恢复、验证、审计闭环 | 故障自愈与受控操作 |
所有场景都要先查询证据，再输出结论。查询动作可以高频使用；写操作必须经人工确认、受控工具、最小权限和执行后验证。敏感信息不能写入文档、截图、代码仓库或聊天回复。
2. 前置准备
2.1 观测云优选系统 Demo 说明
观测云优选系统 Demo 是一个用于演示观测云 RUM + APM + Logs + AI Agent Team 故障自愈闭环的业务 Demo，名字是观测云优选系统 / guance-selfheal-demo，模拟一个真实电商下单链路，从前端业务页面发起订单，请求进入后端 Java 微服务，再经过库存、支付、Redis 等组件。通过观测云把用户操作、前端资源请求、后端链路、日志、业务标签串起来，最后用于告警、根因分析和自动自愈，如下图：
2.2 数据标签与可观测数据接入
三类场景能否准确关联，关键取决于日志、链路、指标和事件是否有统一标签。本实践建议至少统一以下标签。
| 标签 | 建议值 | 用途 |
|---|---|---|
| project | 观测云优选系统 | 统一过滤项目数据，作为 RCA 查询入口 |
| env | dev/test/staging/prod | 区分环境，避免跨环境误判 |
| service | business-web/order-service/inventory-service/payment-service | 定位服务 |
| version | 镜像 tag 或发布版本 | 关联发布变更与故障时间线 |
| key_request | checkout_submit_order | 标识关键业务请求 |
| biz_chain | selfheal_checkout | 标识业务链路 |
| biz_request_id | 业务请求唯一 ID | 串联前端日志、后端日志和 Trace |
如下图基于一些标签的数据筛选展示，做好数据标签也更好的赋能AI分析
如下链路，日志，指标，用户体验数据的关联融合，这也源于观测云内置的数据标签体系：
3. 场景一：Vibing Coding Agent 调用观测云 Agent 做源码级 RCA
第一个场景解决的是“客户带着自己的源码，向观测云 RCA Agent 发起根因分析，本次让 Codex 把 RCA 结论映射回源码修复点”。它适合研发和 SRE 在本地工作流中使用。
图 2：场景一源码侧 RCA 调用链路
3.1 创建观测云 RCA Agent
在观测云 Agent 工作台创建 RCA Agent，定义好数据访问，身份定义，权限边界，安装好即可，如图：
3.2 Codex 配置 MCP
观测云平台查找对应 MCP 相关参数准备 Workspace UUID、MCP Endpoint 和 Bearer Token。
创建新增 guanceRcaAgent mcp ，可以在 codex toml 进行配置，配置实例，token 尽量设置为环境变量形式，尽量避免明文配置。
[mcp_servers.guanceRcaAgent]
enabled = true
url = "https://agent-api.guance.com/mcp"
bearer_token_env_var = "MCP_BEARER_TOKEN"
startup_timeout_sec = 20
tool_timeout_sec = 120
[mcp_servers.guanceRcaAgent.http_headers]
x-workspace-uuid = "wksp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
accept-language = "zh"
或者在 codex 设置中配置，配置好重启 codex 。
3.3 效果验证展示
本实践中，RCA Agent 能关联 business-web、order-service、inventory-service 与 Redis 的故障链路，并指出库存服务 Redis 超时导致下单链路 500/503 级联失败。Codex 再结合源码定位到故障注入与 Redis 调用逻辑，提问实例如下：
请通过 guanceRcaAgent MCP 调用 RCA Agent， 帮我分析project=观测云优选系统 最近 30 分钟的错误日志、链路和指标，给出 RCA，并结合源码给出解决方案
展示效果如下：
场景一最佳实践：让 Codex 负责源码理解和修复建议，让 RCA Agent 负责真实观测证据查询。RCA 结论不要直接等同于生产变更，修复仍应进入 PR、CI/CD 和发布验证流程。
4. 场景二：IM 消息排障助手接入飞书，微信，钉钉等群与告警通知
第二个场景把 Agent 挂到 IM 环境中，让值班人员可以在飞书群里直接提问，也可以把观测云告警通过飞书机器人推送到群里，形成“告警到达、群内调查、结论同步”的协作链路。
图 3：场景二飞书群与 IM 消息排障助手架构
4.1 Agent 创建
如图，创建 IM 消息排障助手 Agent，定义好身份与行为边界，安装好即可。
4.2 飞书 Channel 接入步骤
- 在飞书开放平台创建企业自建应用，记录 App ID 和 App Secret。
- 在观测云 Agent 工作台进入 IM 消息排障助手 -> Channel -> 添加飞书。
- 填入 App ID 和 App Secret，完成授权并启动 Channel。
- 把机器人加入目标飞书群，例如“运维群”。
- 在群内使用 @IM 消息排障助手 发送测试问题。
- 如果无响应，优先检查 Channel 运行状态、应用权限、机器人是否已入群、事件订阅是否生效。
4.3 告警通知到飞书群
观测云告警也可以通过飞书机器人推送到同一个群，用于形成“告警 -> 群内协作 -> RCA 摘要”的闭环。
- 进入目标飞书群，点击群设置或群机器人。
- 添加自定义机器人，复制 Webhook 地址；如启用签名，记录签名密钥。
- 进入观测云 -> 监控 -> 通知对象管理 -> 新建通知对象 -> 飞书机器人。
- 填写名称、Webhook 地址和签名密钥，点击测试通知发送。
- 在告警策略或监控器中选择该通知对象。
- 如果告警聚合内容为英文，优先在监控器通知模板、告警策略模板或事件通知内容中改为中文文案。
4.4 效果实践展示
如下图告警通知，告警通知后，@@IM 消息排障助手 分析，示例如"帮我分析project为“观测云优选系统”的近30分钟的告警，并分析project为“观测云优选系统”最近30分钟的链路，日志，指标，给出 RCA 摘要。"
具体响应分析结果如下图：
5. 场景三：在Agent控制台发起业务分析调查与受控恢复
在观测云 AI Agent Team 场景中，RCA Agent 负责结合日志、链路、指标和上下文输出根因分析；ops-controlled-mcp 负责把少量安全可控的运维动作封装成 MCP 工具。二者分工明确：Agent 分析与决策建议，MCP 执行受控查询和有限恢复。
图 4：场景三告警/业务入口触发调查与受控恢复链路
5.1 组件与职责
| 组件 | 职责 | 部署位置 | 风险边界 |
|---|---|---|---|
| RCA Agent | 根因分析、影响范围判断、修复建议、调用工具 | 观测云 Agent Team + 自托管 beak-agent | 不直接持有 root 或任意 kubectl |
| stdio bridge | 把 Agent stdio 请求转发到内网 HTTP MCP | 安装 Agent 的节点 | 只读取本地 token 文件，不写业务资源 |
| ops-controlled-mcp | 暴露 K8S 状态、Pod 日志、恢复故障、重启 Deployment 等白名单工具 | K8S ops-system namespace | Token、白名单、确认口令、prod 禁写 |
| Kubernetes RBAC | 限制 MCP 可访问的 namespace 和资源 | K8S 集群 | 只绑定目标 namespace，不授予 cluster-admin |
5.2 MCP 构建与配置
| 工具 | 类型 | 用途 | 风险控制 |
|---|---|---|---|
| list_allowed_actions | 只读 | 查看允许的 namespace、deployment 和确认口令 | 无写操作 |
| get_k8s_status | 只读 | 查询 Deployment、Pod、Event 状态 | RBAC 只读 |
| get_pod_logs | 只读 | 读取指定服务或 Pod 日志 | 只允许 pods/log get |
| get_rollout_status | 只读 | 查询 Deployment 发布状态 | 只读 |
| verify_recovery | 只读 | 验证故障模式、关键接口和 rollout 状态 | 只读 |
| restore_fault_injection | 写 | 恢复 Demo Redis 故障注入 | 需要审批 + 确认口令 |
| restart_deployment | 写 | 重启白名单 Deployment | 需要审批 + 确认口令 + 禁止 prod 默认写 |
ops-controlled-mcp 部署在 ops-system 命名空间中，使用独立 ServiceAccount、Secret、Deployment 和 NodePort Service。
配置 MCP 服务，因为 MCP 为内网，本次不是直接通过观测云连接 MCP，而是通过 stdio bridge 桥接请求转发到内网 HTTP MCP，配置好 MCP 服务，如图：
配置好 MCP 服务设置为 RCA Agent 启用。
5.3 受控恢复演练效果
- RCA Agent 控制台发起调查，明确 project、时间范围。
“请分析 project=观测云优选系统 最近30分钟的错误日志、链路和指标，给出 RCA 摘要”
- RCA Agent 查询错误日志、Trace、指标、K8S 状态和 Pod 日志，RCA Agent 输出根因、影响范围、恢复计划、风险点、回滚方式和验证方式。
- 用户明确回复“确认执行”或在审批页面批准，RCA Agent 调用 ops-controlled-mcp 的写工具，例如 restore_fault_injection，执行后继续调用 verify_recovery，确认关键接口恢复、Pod Ready、错误率下降，并输出审计摘要：谁触发、做了什么、结果如何、如何验证、是否需要后续代码修复。
- Agent 控制台任务对话下，以上效果是在完全访问权限下的执行，默认权限会有 MCP 审批步骤，如下图：
6. 结语
通过这三个场景的建设，观测云 AI Agent Team 不再只是一个“问答助手”，而是逐步成为贯穿研发、运维、告警响应和业务恢复的智能协作入口。
在源码侧，研发和 SRE 可以直接基于真实日志、链路、指标和代码上下文完成根因分析，把“发现问题”推进到“定位修复点”；在 IM 场景中，Agent 可以进入飞书、钉钉等协作空间，把告警、排障过程和 RCA 摘要带到一线值班群里，减少信息搬运和沟通成本；在业务与告警触发场景中，Agent 可以结合受控 MCP 能力，在人工审批和权限边界下完成查询、验证和有限恢复，形成从发现、分析、决策到处置闭环的可审计流程，后续也可以结合CI/CD流程从定位到根因到CI/CD的流程对接等等。
这套实践的核心价值，不是让 AI 绕过人直接操作系统，而是让 AI 成为团队可靠的“智能副驾驶”：帮助用户更快看清故障事实，更稳地收敛根因，更有边界地执行恢复动作，并把每一次处置沉淀为可复用、可追溯、可持续优化的运维能力。
7. 附录
7.1 权限与风险控制模型
7.2 常见问题处理
1、RCA Agent 显示离线
- 先检查 systemctl status beak-agent 是否 active。
- 查看 journalctl -u beak-agent 或 /var/log/beak-agent/log，确认是否 websocket disconnected。
- 如服务存活但页面离线，可重启 beak-agent，并确认日志出现 websocket connected。
- 检查主机到 https://agent-api.guance.com 的网络连通性。
2、MCP 调用都要审批怎么办
当前页面如果开启 approval_mode，MCP 工具调用可能都会进入审批。最佳处理方式是保留审批，并通过工具内部确认口令保护写操作。不要为了省掉查询审批而关闭所有审批。
3、IM 群里 @Agent 没响应
- 确认 Channel 状态为运行中。
- 确认机器人已加入目标群。
- 确认飞书应用 App ID/App Secret 正确，应用权限和事件订阅已发布。
- 确认消息不是只发给普通群机器人，而是 @ 到 Agent 对应机器人。
- 如果 Agent 返回工具失败，查看 Agent 工作台任务洞察和 beak-agent 日志。
4、告警聚合内容是英文
优先检查监控器通知模板、告警策略模板、通知内容模板和事件聚合模板，把标题、摘要、影响范围和恢复建议改成中文。飞书机器人只是通道，内容语言通常由观测云告警模板决定。
7.3 参考资料
- 观测云 MCP 服务文档：https://docs.guance.com/obsy-agent-teams/mcp-services/
- 观测云 Owl 文档：https://docs.guance.com/owl/
- 观测云 Owl 故障排查：https://docs.guance.com/owl/troubleshooting/
- Model Context Protocol：https://modelcontextprotocol.io/
