# 还在用原始对话框？教你用 Obsidian Canvas 与 Agent 协作
**作者**: 阿哲Phil
**日期**: 2026-07-12T12:53:21.000Z
**来源**: [https://x.com/Formulasearch/status/2076288803786887245](https://x.com/Formulasearch/status/2076288803786887245)
---
知识库让 Agent 理解你的过去，Canvas 让你们共同面对现在。
我们现在和 AI 沟通，几乎都在使用同一种界面：对话框。你说一句，AI 回一句，继续追问，再继续往下聊。处理一个小问题、改一段文案、检查几行代码，这种方式没有任何问题，但当任务开始变复杂，对话框很快就会暴露出它的局限。
比如，你正在和 Agent 讨论一个新产品。前十轮在聊用户需求，接着开始拆功能、画流程、规划页面，再往后又涉及技术限制、内容结构、任务分工和后续迭代。聊到几十轮以后，你会越来越频繁地说：
"回到刚才第三个方案。"
"不是这个流程，是前面修改过的版本。"
"这个功能已经删掉了。"
"你把旧方案和新方案混在一起了。"
"先别继续，重新帮我整理一下。"
这种时候，问题往往出在工具上，而不是模型。对话框太原始了。 它只能把所有内容按照时间顺序，一条接一条地向下堆积，但复杂工作很少是线性的。
## 一、对话记录，不等于项目状态
对话框最擅长保存的是：
> 我们曾经说过什么。
但一个项目需要表达的，是另一件事：
> 现在到底是什么状态。
这两者差别很大。在一段几十轮的对话中，你可能先提出方案 A，后来改成方案 B，又在某个细节上保留了方案 A 的一部分。聊天记录完整保留了这个过程，但聊天记录不会明确告诉你：
- 现在采用的是哪个方案；
- 哪些内容已经确定；
- 哪些决定已经被推翻；
- 哪些问题仍然没有答案；
- 当前工作卡在哪里；
- 下一步应该由谁做什么。
Agent 可能记得全部过程，却无法稳定判断哪一部分代表"当前版本"。于是，随着对话越来越长，人开始承担一项额外工作：维护 Agent 的上下文。 你不再只是推进项目，你还要不断提醒它哪些内容有效、哪些内容失效、哪个版本才是最终版本。
## 二、针对Agent协作的研究
"线性聊天不适合复杂工作"，这一点有研究支撑。2023 年，来自加州大学圣地亚哥分校的研究者发布了一个名为 Sensecape 的实验系统，允许用户在 Canvas 和层级视图之间切换，与大语言模型共同完成研究、信息探索和复杂主题梳理。
研究者指出，人们在处理复杂信息时，往往需要反复进行搜索、分类、比较、抽象和重组；但主流 LLM 界面仍然采用线性对话，无法很好地承载这种非线性的思考过程。在用户研究中，Sensecape 帮助参与者探索更多主题，并将信息组织为更加清晰的层级结构。研究同时发现，把所有内容塞进同一张画布也会造成视觉混乱，因此复杂任务需要不同层级的 Canvas，而不是一张无限膨胀的大图。
到了 2026 年，另一项研究直接把这个问题指向了 AI 对话本身。研究者开发了一个叫 CanvasConvo 的系统，把传统聊天转化为可以分支、回溯和重新组织的空间画布。
用户可以从任意一条消息创建新的对话分支，在不打断原有路线的情况下探索不同方案。研究团队让 24 名参与者实际使用这个系统五天，结果显示，传统聊天更多被用于快速提问和即时生成，而 Canvas 则被用于更长时间的整理、回顾和思考：研究中，Canvas 会话的平均持续时间为 34.1 分钟，普通聊天会话为 13 分钟。
参与者认为，画布让他们更容易看清对话是如何发展的，也减少了不断滚动聊天记录和依赖记忆的需要。研究者最终将二者定义成了两种互补的交互方式：
Chat 适合快速交流，Canvas 适合复杂工作的组织与反思。
我自己带着这个困惑去找过资料，找到的东西和我的感受一致。对话框适合回答问题，但当你开始和 Agent 一起完成一个项目，你要的就不只是一连串回答了。你需要一个双方都能看到的工作空间。
## 三、思考并非线性的，而是一张网
一个真实项目通常同时包含很多东西：
目标、用户、场景、功能、页面、流程、依赖、风险、决策、素材、任务和待确认问题。
这些内容之间，并不是简单的先后关系。一个功能可能同时影响三个页面，一个技术限制可能改变整个交互流程，一条用户反馈可能推翻最初的产品假设，一项任务可能依赖另外两个 Agent 的输出。
这些关系更像一张网。
但放进对话框以后，它们只能被压缩成一条时间线。这就像你拿着一张城市地图，却被迫把所有道路、街区和建筑按照经过时间写成一份长长的清单。信息确实都在，但缺乏明确的结构。Canvas 的作用，就是把这个结构重新显现出来。
## 四、AI 产品也正在走出对话框
这个方向已经从学术研究延伸到了产品。一些 AI 产品开始尝试把模型输出从聊天记录中拿出来，放进可以持续编辑的工作空间。
2024 年，Microsoft 推出 Copilot Pages，并把它称为一个面向多人 AI 协作的"动态、持久化 Canvas"。它解决的问题很直接：AI 在聊天中生成的内容通常是短暂的，用户看完、复制、粘贴，然后聊天继续向下滚动。Copilot Pages 则把这些输出变成可以继续编辑、补充和分享的对象，人可以修改，Copilot 也可以根据新的要求继续更新。Microsoft 将这种模式称为一种"human-to-AI-to-human"的协作方式：AI 生成内容，人类修改判断，再让 AI 基于新的状态继续工作。
2026 年，Cursor 也推出了自己的 Canvas。 Cursor 给出的理由非常明确：与纯文本相比，Canvas 可以让 Agent 用非线性的方式组织信息，使复杂内容更容易理解。它的应用场景已经不只是画流程图，还包括：
- 将多个数据源组织成事故响应面板；
- 对大型代码改动进行分类和重点标记；
- 聚类模型评测中的失败案例；
- 展示 Agent 当前正在测试的研究假设；
- 生成可以交互的架构图和审查界面。
在 Cursor 的设计里，Canvas 也不是对话结束后导出的一张图片，而是和终端、浏览器、代码仓库并列存在的持久化工作对象。
这些产品都指向同一个方向：
> AI 的下一代交互界面，大概不会再只有 Chat。
更完整的形态可能是：
> Chat + Canvas + Files + Tasks + Agents。
聊天负责即时沟通，Canvas 负责结构化呈现，文件负责保存完整内容，Agent 负责执行和更新。
## 五、Canvas 不是结果，而是工作台
很多人使用 AI 和 Canvas 的方式，仍然是这样的：和 AI 聊天 → 让 AI 整理内容 → 生成一张思维导图或者流程图 → 导出图表 → 结束。此时的 Canvas 只是对话完成后的展示结果，这和一张普通图片没有本质区别。
真正用起来 Canvas，方法是另一种：
- 人与 Agent 先讨论，Agent 随之把对话内容整理进 Canvas。
- 人直接移动节点、删除错误关系、修改结构、补充遗漏。
- Agent 再读取修改后的 Canvas，根据新的关系继续分析。
- 新的任务、风险和执行结果，再继续写回 Canvas。
整个过程变成：
> 对话
> → 形成结构
> → 人工修改
> → Agent 重新理解
> → 继续执行
> → 更新结构
Canvas 就这样变成了人和 Agent 共同维护的项目界面。
## 六、为什么选择 Obsidian Canvas
无限画布，节点式，低代码这类相似概念早都烂大街了。Miro、FigJam、Heptabase，以及各种白板和思维导图工具，都可以使用节点、连线和空间位置组织信息。但 Obsidian Canvas 有一个非常特别的地方：它不只是一张给人看的图。
Obsidian Canvas 使用开放的 JSON Canvas 格式，文件后缀是 .canvas。按照规范，一张画布主要由两类数据组成：
- Nodes，也就是节点；
- Edges，也就是节点之间的连线。
节点可以是文本、文件、网页链接或者分组，同时包含坐标、大小和颜色等信息。连线则包含起点、终点、方向和标签。Obsidian 官方也明确表示，Canvas 文件保存在本地，脚本、插件和其他应用可以读取并修改其中的卡片与连接。
这意味着，只要 Agent 拥有对应文件的读取权限，它就可以直接解析画布内容，而不一定非得通过截图来"看懂"。它可以读到：
- 画布里有哪些节点；
- 每个节点写了什么；
- 节点引用了哪个 Markdown 文件；
- 节点 A 是否连接节点 B；
- 连线指向哪个方向；
- 连线标签写了什么；
- 哪些节点属于同一个分组；
- 节点位于画布的哪个区域。
对于人来说，这是一张图；对于 Agent 来说，这是一份结构化数据。这正是 Obsidian Canvas 特别适合人机协作的地方。
## 七、Obsidian 生态里已经出现了早期原型
这个想法并没有停留在概念阶段，Obsidian 社区里已经出现了一些相关插件。
例如 Canvas LLM，会把不同提示词和回答组织成分支节点，用户可以围绕同一个问题探索不同方向，而不必把所有内容塞进同一条聊天记录。
Canvas LLM - Obsidian Plugin
开发者将它定义为一种"在 Obsidian 中通过 Canvas 与 LLM 对话的界面"，并特别强调它对复杂研究和分支对话的价值。
另一个更进一步的案例是 Cannoli。
Cannoli - Obsidian Plugin
Cannoli 允许用户直接在 Obsidian Canvas 上，通过卡片和箭头定义变量、逻辑、循环和分支，再运行对应的 LLM 工作流。它可以读取和写入 Obsidian Vault，也可以执行预先定义的 HTTP 请求。换句话说，在 Cannoli 中，节点也可以是任务，连线也可以表示执行顺序和逻辑依赖。
这些插件已经验证了几件事：
- Canvas 可以成为非线性 AI 对话界面；
- Canvas 可以成为提示词和上下文的组织工具；
- Canvas 可以成为可执行的 Agent 工作流；
- Agent 的输出也可以重新写回画布。
但我认为，还有一个更值得探索的方向：
让 Canvas 长期保存人与 Agent 共同维护的项目状态，而不只是执行某一条自动化流程。
## 八、Canvas 表达关系，Markdown 承载细节
Canvas 不应该塞进所有信息。如果每一个节点里都有几千字内容，画布很快就会变得无法阅读。更合理的分工是：
Canvas 负责结构，Markdown 负责细节。
比如你正在规划一个产品功能，Canvas 上只需要放：
- 产品目标；
- 用户角色；
- 核心场景；
- 功能模块；
- 主流程；
- 异常流程；
- 已确认决策；
- 待确认问题。
每一个节点再连接到对应的 Markdown 文件。完整需求、会议记录、用户反馈、技术说明、页面文案和研究资料，继续保存在本地文件中。这样一来，Canvas 更像项目地图——它告诉你什么重要，什么和什么有关，现在推进到了哪里。而完整的内容，依然保留在原始文件里。
这也是 Obsidian 相比普通在线白板更适合长期项目的原因——它连接的是整个本地知识库，而不是一个孤立的视觉空间。
## 九、一个完整的协作过程
假设你现在要和 Agent 一起梳理一个新产品，手上已经有一些零散材料：会议纪要、功能想法、用户反馈、竞品截图，以及几份并不完全一致的需求文档。传统方式是把这些材料都交给 AI，然后让它总结，它可能会输出一份很完整的文字。但你依然很难快速判断：哪些内容是事实，哪些内容是推断，哪些属于用户问题，哪些属于解决方案，哪些只是某次讨论中出现过、后来已经被放弃的想法。
换成 Canvas 后，过程可以变成这样。
## 第一步：让 Agent 读取原始材料
先让 Agent 提取：
- 项目目标；
- 用户角色；
- 核心场景；
- 功能模块；
- 关键流程；
- 已确认事项；
- 风险；
- 待确认问题。
## 第二步：生成第一版 Canvas
第一版不需要完美，它的目的只是把隐藏在文档和对话里的结构显现出来。例如：
```
项目目标
│
├── 用户角色
├── 核心场景
├── 功能模块
├── 主流程
├── 异常流程
├── 外部依赖
└── 待确认问题
```
## 第三步：人直接修改 Canvas
发现某个功能分类错误，就把它移动到另一个区域；发现两个节点其实是同一件事，就合并；发现流程顺序不对，就重新连线；发现某个功能根本不该出现，就直接删除；发现缺少一个关键场景，就手动补充。
这一步很重要，因为你不再需要写一大段提示词去解释 Agent 到底错在哪里——你的空间操作本身就是反馈。
## 第四步：Agent 重新读取 Canvas
此时，Agent 面对的已经经过人类判断和修正，而不再是最初那批模糊材料。接下来，它可以继续：
- 补全遗漏流程；
- 找出逻辑冲突；
- 拆分页面需求；
- 生成产品文档；
- 创建任务列表；
- 标记前置依赖；
- 提出需要人工确认的问题。
## 第五步：把执行结果写回 Canvas
某个需求已经确定，就标记为绿色；某项任务正在进行，就移动到"进行中"；某个技术问题没有解决，就标记为红色；某个方案已经放弃，就移入归档区域。慢慢地，这张 Canvas 就从思维整理工具，变成了项目的当前状态。
这是我受委托开发的一款库存统计类工具的全部流程图，完全通过与Agent协作搭建，在此基础上，可以清晰的产出原型图和代码
这是一个SEO内容产出的流程工作流，同样通过canvas作为演示，与Agent可以直观的协作
## 十、直接"改图"，就是在修改 Agent 的理解
这是 Canvas 最有意思的地方。在传统对话里，Agent 理解错误以后，你只能继续用语言纠正它：
"这个模块不是核心功能。"
"它只是前置条件。"
"不要放在用户流程中。"
"它应该和账户系统建立依赖关系。"
但在 Canvas 里，你可以直接把节点移动到前置条件区域，再重新连接账户系统。Agent 下一次读取文件时，就能看到新的结构。
在对话框里，你是在告诉 Agent：
> 你理解错了。
在 Canvas 里，你是在直接修改它所看到的项目模型，这两种沟通方式的效率差距很大。
## 十一、Canvas 需要一套协作协议
当然，Canvas 也不是随便画就能用好。如果节点越来越多、颜色越来越乱、连线到处交叉，它很快就会变成一张意大利面图，人看不懂，Agent 也无法稳定解析。因此，最好建立一套简单规则。
颜色可以表示状态：
- 紫色：核心目标；
- 蓝色：功能或模块；
- 绿色：已经确认；
- 黄色：等待确认；
- 红色：风险或阻塞；
- 灰色：参考资料。
空间可以拥有固定含义：
- 从左到右：流程推进；
- 从上到下：层级拆解；
- 左侧：输入和背景；
- 中间：核心工作；
- 右侧：输出和结果；
- 下方：风险、问题和待办。
节点类型也可以保持统一：
- 文本节点：简短判断和状态；
- 文件节点：完整内容和事实来源；
- 链接节点：外部资料；
- 分组：阶段、模块或责任范围。
连线也要有清晰语义：
- 有箭头：流程或依赖；
- 无箭头：普通关联；
- "输入"：该节点需要的信息；
- "输出"：该节点产生的结果；
- "负责"：对应人员或 Agent；
- "阻塞"：当前无法继续的原因。
这些规则的目的，是让人和 Agent 对同一张 Canvas 形成稳定理解，而不是让画布更好看。
## 十二、多 Agent 协作，更需要一张共享画布
Canvas 的价值，在多 Agent 场景下会更加明显。比如你要完成五篇 SEO 内容，整个任务可能包含关键词研究、搜索意图分析、文章大纲、正文写作、配图生成、页面代码、SEO 检查和发布。不同环节可能由不同工具或者 Agent 完成：一个负责研究，一个负责写作，一个负责生图，一个负责代码，一个负责检查。
如果这些任务全部分散在不同聊天窗口和终端里，人很快就会失去全局。这时，Canvas 可以成为统一界面。每个任务节点都标记：
- 负责的 Agent；
- 输入文件；
- 输出文件；
- 当前状态；
- 前置依赖；
- 是否需要人工确认。
打开画布，就能立刻知道哪些任务已经完成、哪些正在执行、哪些被阻塞、哪些结果正在等待审核。未来的多 Agent 协作，人大概只需要维护一张共享画布就够了，不需要反复打开十个聊天窗口询问进度。
## 十三、Chat、Canvas 和 Markdown，不是谁替代谁
Canvas 不会替代聊天，对话框依然是最直接、最自然的沟通入口。合理的方式，是让不同工具承担不同职责。
## Chat：负责即时交流
适合提问、发散、解释、调整和下达临时指令。
## Canvas：负责结构与状态
适合表达关系、对齐全貌、维护当前方案和展示任务进度。
## Markdown：负责详细沉淀
适合保存需求、文章、会议记录、研究资料和技术文档。
## Agent：负责读取与执行
负责整理材料、发现问题、完成任务并更新结果。
最后形成一个循环：
> 聊天产生内容
> → Canvas 形成结构
> → Markdown 保存细节
> → Agent 执行任务
> → 结果回到 Canvas
用一句话概括它们之间的关系：
> 知识库解决的是 Agent 知道什么，Canvas 解决的是人和 Agent 此刻正在共同做什么。
## 十四、Canvas 也不是万能的
这个方式同样存在明显限制。
## 第一，画布不是越大越好
Sensecape 的研究已经发现，当 LLM 快速产生大量内容时，单张 Canvas 很容易出现视觉拥挤。更好的方式是分层：项目总览是一张 Canvas，产品流程是一张，页面结构是一张，内容生产流程又是一张。
## 第二，空间位置可能产生歧义
人类可能自然认为两个距离较近的节点关系密切，但 Agent 未必知道这种隐含规则。所以重要的关系，还是得通过连线、标签和明确命名来表达。
## 第三，不要让 Agent 拥有无限修改权
哪些节点可以修改、哪些内容只能读取、删除节点是否需要确认、哪些区域由人维护、哪些区域由 Agent 自动更新——这些都需要明确边界。否则，Agent 很可能在"整理"过程中，把你重要的内容一起优化掉。
## 第四，结构本身也会增加成本
CanvasConvo 的研究同时指出，非线性界面虽然有利于探索和回顾，但也会引入新的问题，比如视图切换、导航成本，以及用户无法确定不同分支究竟继承了哪些上下文。
所以 Canvas 不适用于所有任务。快速问答仍然应该留在 Chat 中。只有当任务开始出现多个方向、多个文件、多个决策和较长执行周期时，Canvas 的价值才体现出来。
## 十五、对话框可能只是 Agent 时代的临时界面
现在大多数 AI 产品仍然采用聊天框，原因不一定是聊天框最适合复杂工作，更可能是因为它最容易理解，也最容易实现——它沿用了我们已经熟悉的即时通信软件形态。但随着 Agent 开始处理越来越复杂的任务，单一对话框会越来越难承载真实工作。
研究系统正在把对话变成可分支的空间，Microsoft 正在把 AI 输出变成持久化的共享页面，Cursor 正在让 Agent 直接生成可交互的工作界面，Obsidian 社区则开始用 Canvas 构建非线性对话和可执行工作流。这些探索还没有形成统一答案，但方向已经比较清楚：未来的人机协作界面，不会再只是一个聊天窗口。
它会同时包含：
```
Chat
+
Canvas
+
Files
+
Tasks
+
Agents
+
Execution Status
```
人在 Canvas 上表达目标、关系、优先级和判断，Agent 在背后负责理解、整理、执行、更新和汇报。人不需要再把所有上下文重新写成一段提示词，而是直接修改双方共同使用的工作空间。
## 十六、最后
对话框当然不会消失，一问一答的场景，它依然是最有效的方式。但当工作开始涉及多个文件、多个角色、多个流程和连续决策时，只靠对话框已经不够了。
Canvas 改变的事情其实就一件：原本藏在聊天记录里的项目结构，被放到了一个双方都能看见、理解和修改的空间中。过去，我们把 Obsidian 当成自己的第二大脑，用它保存知识；接下来，它或许还可以成为人与 Agent 的共同工作台。
聊天负责交流，Markdown 负责记忆，Canvas 负责对齐，Agent 负责执行。
知识库让 Agent 理解你的过去，Canvas 让你们共同面对现在。
🥳感谢看到这里，我是阿哲，前建筑师 → AI 工作流架构师
如果这篇文章对你有帮助，欢迎关注我 @Formulasearch ，我会持续分享跨界思考、AI 工具与方法论。
## 相关链接
- [阿哲Phil](https://x.com/Formulasearch)
- [@Formulasearch](https://x.com/Formulasearch)
- [34K](https://x.com/Formulasearch/status/2076288803786887245/analytics)
- [Canvas LLM - Obsidian Plugin](https://community.obsidian.md/plugins/canvas-llm)
- [Cannoli - Obsidian Plugin](https://community.obsidian.md/plugins/cannoli)
- [@Formulasearch](https://x.com/@Formulasearch)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:53 PM · Jul 12, 2026](https://x.com/Formulasearch/status/2076288803786887245)
- [34.1K Views](https://x.com/Formulasearch/status/2076288803786887245/analytics)
- [View quotes](https://x.com/Formulasearch/status/2076288803786887245/quotes)
---
*导出时间: 2026/7/13 15:56:13*