观测云笔记焕新上线：人与智能体的共同知识库
你刚花了 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 学会用。