观测云笔记焕新上线：人与智能体的共同知识库

你刚花了 1 小时解决了一个 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   // 并发控制，防止覆盖
  ...
}

几个关键设计：

tagKV 绑定业务对象。不是 #标签，是精确关联到某个service、host、dashboard、database 这些实体。你在 inner-api 的服务详情页看到的"笔记"是服务本身的记忆。
chart block 嵌入图表证据。笔记里可以保留当时的 DQL 查询和图表。结论是查询里真实跑出来的数据。
etag / ifMatch 防覆盖。多人协作时，保存前检查版本，避免静默覆盖。
createdSource 追踪来源。人写的、Obsy AI Copilot 生成的还是观测 AI Agent Teams 创建的，能清楚分清。质量责任链清晰。

人，Obsy AI Copilot，Guance AI Agent Teams 如何玩转笔记？

人类：把故障处理经验资产化

1、故障复盘

故障排查完写篇笔记：

标题：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。三个月后如果同服务告警，新同事打开服务详情页就能"相关笔记"里直接看到这篇，不需要再问上次怎么解决的。

2、轻松搜索

frontend-proxy 接口异常 → 写成笔记。下次任何人检索 frontend-proxy 异常，第一篇就是。

3、图表证据保全

笔记里支持嵌入当时的查询和图表。如果一段时间后有人问"当时怎么查的？指标名是什么？"，打开笔记，DQL 语句和图标块都在。

4、自由团队协作

笔记支持设置为仅自己可见，作为故障排查过程中的中间产物供个人参考
笔记也支持与公开给团队/工作空间成员，录入团队知识库，成为经过验证的经验
多人编辑时不覆盖，冲突时提示

Obsy AI copilot ：协助人类生成笔记，沉淀故障处理经验

当 Copilot 分析完告警、日志、仪表板..会自动判断这次结论是否值得沉淀，然后返回一个结构化建议，你确认后会自动替你创建笔记。举个例子，Obsy AI Copilot 分析仪表板数据缺失，生成《xxx仪表板数据缺失分析》：

结论：16 个图表均无有效数据
根因：模板变量 #{service} 未绑定，查询条件无法匹配
建议：整理绑定模板变量，验证数据采集

绑定具体的 dashboard。后续如果有任何人查看该仪表板，这篇诊断就在"相关笔记"里。

Guance AI Agent Teams：持续从笔记知识库学习，提升执行准确度

笔记会成为AI智能体团队不断的迭代更新的长期记忆层。

Agent 在分析前能按 service、host、alert、incident、tagKV 自动召回相关笔记，总结人类经验，提升执行准确度。

人用笔记沉淀经过验证的问题处理经验，Obsy AI copilot 辅助人类创造笔记，沉淀高价值分析结果，最后 Agent Teams 把这些笔记变成团队可持续复用的长期记忆，提升智能体自动处理时的执行准确度。

现在开始使用

在观测云控制台「笔记」-「新建笔记」，或者打开右上角「Obsy AI」，让 Obsy AI Copilot 辅助你生成第一份 AI 笔记，看看它怎么结构化分析结果。

笔记让经验留下来，让 Agent 学会用。