观测云笔记作为可观测数据基础设施中的知识层级,支持tagKV精确关联业务实体、chartblock内嵌图表证据、etag并发控制及createdSource来源标记。人、ObsyAICopilot与GuanceAIAgentTeams共同使用:人类沉淀故障处理经验,AI辅助生成分析笔记,Agent将其转化为长期记忆,实现知识复用。
你刚花了一个小时解决了一个 Redis 故障。三个月后,一模一样的问题又来了。上次的排障记录?大概率还在某个同事的本地 Markdown 文件里,文件名大概长这样:redis-issue-202603-final-v2-really-final.md。你@了那位同事,他没回。于是,你又从头排查了一遍。
说白了,这就是知识的“蒸发”。现在不仅人类面临这个问题,连智能体也在重复“学习”同一个故障。观测云笔记,就是冲着这个痛点来的。
长期稳定更新的攒劲资源: >>>点此立即查看<<<
观测云笔记可以理解为可观测数据基础设施里,一个专门承载知识的层级。它的核心数据结构大致如下:
// notebookV2.ts
interface NotebookV2 {
...
content // Markdown,支持 chart block
tags // 普通标签,比如 "copilot", "redis"
tagKV // 关联业务标签,比如 service: inner-api
createdSource //用于标记手工或 AI 创建来源
etag // 并发控制,防止覆盖
...
}
几个关键的设计理念:
service、host、dashboard、database 等业务实体。你在 inner-api 服务的详情页看到的“笔记”,本质上就是该服务自己的“记忆”。
故障处理完,写一篇复盘笔记:
标题:frontend-proxy 5xx 排查记录
标签:service: frontend-proxy, alert: high-error-rate
内容:
- 14:23 告警触发,错误率从 0.1% 飙升至 12%
- 14:25 定位到 upstream 连接超时
- 14:30 调整 nginx proxy_timeout,恢复
- 根因:上次部署引入了新的上游服务,未调整超时配置

生成的笔记会自动绑定业务标签 service: frontend-proxy。三个月后,如果同一个服务再次告警,新同事打开服务详情页,在“相关笔记”里就能直接找到这篇记录——不用再满世界问人了。


当 frontend-proxy 出现接口异常,你写成了笔记。下次任何人检索“frontend-proxy 异常”,这篇笔记就会排在搜索结果最前面。

笔记里可以嵌入当时的查询和图表。如果有人隔段时间来问“当时查的哪个指标?用的什么 DQL?”,打开笔记,当时的分析路径和图表证据都还在。


Obsy AI Copilot 在分析完告警、日志、仪表板后,会自动判断这次结论是否值得沉淀,并给出一个结构化的建议。你确认后,它就会自动创建一篇笔记。举个例子,当它分析出某个仪表板数据缺失时,会生成一篇《xxx仪表板数据缺失分析》:
这篇笔记会自动绑定到具体的 dashboard 上。今后任何人在查看该仪表板时,都能在“相关笔记”里看到这份诊断。

笔记会成为 AI Agent 团队不断迭代、持续更新的长期记忆层。
Agent 在处理问题前,会按照 service、host、alert、incident、tagKV 等维度,自动召回相关的笔记,从中学习人类的处理经验,从而提高自身执行任务的准确度。
简单来说,这是一个正向循环:人用笔记沉淀经过验证的问题处理经验,Obsy AI Copilot 辅助人类创建并沉淀高价值的分析结果,最后,Agent Teams 将这些笔记转化为团队可持续复用的长期记忆,进而提升 AI 自动处理问题的能力。
在观测云控制台找到「笔记」模块,点击「新建笔记」,或者打开右上角的「Obsy AI」,让 Obsy AI Copilot 帮你生成第一份 AI 笔记,看看它是如何结构化地呈现分析结果的。
笔记,让经验留下来,让 Agent 学会用。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述