还在用原始对话框？教你用 Obsidian Canvas 与 Agent 协作Still Using a Plain Chat Box? Collaborate with Agents in Obsidian Canvas
本页目录On this page
知识库让 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，会把不同提示词和回答组织成分支节点，用户可以围绕同一个问题探索不同方向，而不必把所有内容塞进同一条聊天记录。
开发者将它定义为一种”在 Obsidian 中通过 Canvas 与 LLM 对话的界面”，并特别强调它对复杂研究和分支对话的价值。
另一个更进一步的案例是 Cannoli。
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 工具与方法论。