Canvas 作为人机协作的工作台

来源：X @Formulasearch

对话框是目前与 AI 互动最常用的界面：用户说一句，AI 回一句，再追问，再继续 ^[0]。处理小问题足够，但当任务扩展到几十轮——用户需求、功能拆分、流程规划、技术限制混杂在同一条时间线中——用户就会不断说”回到刚才第三个方案""这个功能已经删掉了” ^[0]。问题往往不在模型，而在工具：对话框只能按时间顺序逐条堆积内容，而复杂工作很少是线性的 ^[0]。

对话框擅长保存的是”我们说过什么”，而项目需要的是”现在处于什么状态” ^[0]。在几十轮对话中，方案 A 改为 B，又在某个细节保留 A 的一部分；聊天记录完整记录了过程，却不会显示哪个方案正在生效、哪些决定被推翻、工作卡在何处、下一步由谁负责 ^[0]。因此用户必须承担额外工作：维护 Agent 的上下文，反复提醒它哪些内容有效、哪些已失效、哪个版本是最终版 ^[0]。

非线性界面有研究支撑

学术界有与此对应的研究。2023 年，加州大学圣地亚哥分校的研究者 Sangho Suh、Bryan Min、Srishti Palani、Haijun Xia 在 ACM UIST ‘23 上发表了 Sensecape，一个利用大语言模型和非线性界面支持多层级探索与意义建构的实验系统 ^[7,8]。论文针对的正是上述问题：文本作为符号序列，难以表达概念之间的复杂关系；对话的线性结构会阻碍信息的灵活探索和组织 ^[10]。素材转述的用户研究显示，Sensecape 帮助参与者探索更多主题，并将信息组织成更清晰的层级结构 ^[0]。

2026 年的论文《Conversations in Space: Structuring Non-Linear LLM Interactions on a Canvas》（即素材所说的 CanvasConvo）直接针对 AI 对话界面 ^[1]。24 名参与者使用系统的数据显示：Canvas 会话平均持续 34.1 分钟，普通聊天会话只有 13.0 分钟 ^[1]；交互中，聊天交互占 47.2%、画布交互占 28.3%，分支创建 3.29 次、分支导航 3.88 次 ^[1]。研究者据此判断，参与者将聊天主要用于快速输入和迭代，画布则支撑更长时间的交互 ^[1]。素材补充说，参与者认为画布更容易看清对话发展脉络，减少滚动聊天记录和依赖记忆的需要 ^[0]。两组结论指向同一种互补关系：Chat 适合快速交流，Canvas 适合复杂工作的组织与反思 ^[0,1]。

产品也在走出对话框

研究之外，产品也在向同一方向演进。2024 年 9 月，Microsoft 发布 Copilot Pages，官方将其定义为聊天中”动态、持久化的 Canvas”，面向多人 AI 协作 ^[17,21]。Pages 将原本短暂的 AI 输出变为可编辑、补充和分享的持久对象 ^[17,21]，Microsoft 称之为”human-to-AI-to-human”的协作方式 ^[21]。官方文档补充了一个细节：实时共同编辑虽受支持，但 AI 的响应未必能即时反映多人的同时修改，需要刷新或重新触发 ^[12]。

Cursor 在 2026 年 4 月的 3.1 版本上线 Canvases：Agent 可直接创建交互式画布，包含表格、方框、图表等组件，以及 diff、待办清单这类开发组件 ^[28]。官方设计中，画布不是对话结束后导出的图片 ^[0]，而是与终端、浏览器、源代码管理并列、存放在 Agents Window 侧栏的持久工件 ^[28]。后续版本继续扩展：3.5 引入共享画布 ^[25]，8 月的更新让插件可携带预置画布，例如用于数据可视化的 Hex Canvas、实时聚合 issue 与项目的 Atlassian Canvas ^[22]。素材还称，Cursor 给出的理由是画布能让 Agent 用非线性方式组织信息，场景包括事故响应面板、大型代码改动分类、评测失败案例聚类、研究假设展示与可交互架构图 ^[0]。更宽泛的 AI 产品设计实践中也有同类建议：“链式动作”模式主张将多条生成步骤做成画布上的节点与连线，而不是埋在聊天记录里 ^[53]。

Obsidian Canvas：一张 Agent 可以直接读写的图

为什么选择 Obsidian Canvas？因为对 Agent 来说，它不是一张图，而是一份文件。Obsidian 的白板保存为 .canvas 文件，采用开放的 JSON Canvas 格式 ^[31,38]。2024 年 3 月，Obsidian 将该格式独立为规范，在 jsoncanvas.org 提供规格与开源资源，并以 MIT 许可开放 ^[38]。官方页面明确写道：Canvas 文件存储在本地，应用、脚本和插件可以轻松添加或修改其中的卡片与连接 ^[35]。素材对格式的解析——画布主要由节点（Nodes）和连线（Edges）构成，节点记录文本、文件引用、坐标、大小和颜色，连线记录起终点、方向与标签 ^[0]——意味着只要 Agent 有文件读取权限，它就能解析画布内容，而不必靠截图”看懂” ^[0]。

社区实践印证了这一点：有人直接将画布文件交给 Agent——“Canvas 文件本质是 JSON，Agent 可以直接写它” ^[44]；当知识库由 .md 文件组成时，Agent 无需解析层即可原生读取，因为主流大模型都训练过 Markdown ^[44]。也有资料指出，AI 可以读取、创建和修改 Obsidian 兼容的 .md、.json、.canvas 文件并理解其结构 ^[41]。

2026 年 1 月，Obsidian CEO Steph Ango 发布了官方 Agent Skills，教 Claude Code 正确处理 wikilinks、frontmatter、Bases 数据库和 JSON Canvas 等文件格式 ^[47]。同一篇文章提醒：所谓”记忆”的机制，拆开看就是”读文件、把信息装进上下文、再写回文件” ^[47]——画布要发挥作用，依赖的是文件本身可读可写，而不是玄学。

社区原型：画布上的 Agent 工作流

Obsidian 生态中已出现早期原型。Cannoli 是其中最有代表性的一款：它允许用户在 Canvas 上用卡片和箭头构建无代码 LLM 脚本，通过颜色或前缀区分节点和箭头类型，定义变量、字段、循环和分支选择等基本逻辑，还能做出带自定义逻辑的聊天机器人 ^[30]。素材补充说，它还可以读写 Obsidian Vault、执行预定义的 HTTP 请求 ^[0]。另一款插件 Canvas ACP 让用户就画布笔记向 ACP 代理提问，并把生成的笔记再添加回画布 ^[30]。此外还有把画布元素连同元数据转成线性文档的 Canvas2Document ^[30,33]、从 Vault 和画布运行本地 Agent 工作流的 OpenAgent Canvas ^[45]、把任务和笔记片段发送到画布的 Send to Canvas ^[34]。素材还提到一款名为 Canvas LLM 的插件，把不同提示词和回答组织成分支节点 ^[0]。

这些原型各自验证了画布的不同用法：非线性 AI 对话界面、提示词和上下文的组织工具、可执行的 Agent 工作流、将 Agent 输出写回画布 ^[0]。素材认为更值得探索的方向是让画布长期保存人与 Agent 共同维护的项目状态，而不只是运行一条自动化流程 ^[0]。

从展示结果到共同工作台

许多人使用 AI 和画布的方式是”聊天→让 AI 整理→生成思维导图→导出图片→结束”，这时画布与普通图片没有本质区别 ^[0]。真正的用法是一个循环：Agent 先读取原始材料，提取项目目标、用户角色、核心场景、功能模块、关键流程、风险、待确认问题 ^[0]；生成第一版画布——不需要完美，只为把藏在文档和对话中的结构显现出来 ^[0]；人直接移动节点、合并重复、重连流程、删除不应存在的功能、补充遗漏场景——空间操作本身就是反馈，不必再写一大段提示词解释 Agent 错在哪里 ^[0]；Agent 重读修改后的画布，补全流程、查找逻辑冲突、拆分页面需求、生成文档和任务列表 ^[0]；执行结果再写回画布——需求确认标绿、进行中的任务移入”进行中”、未解决的技术问题标红、放弃的方案移入归档 ^[0]。画布逐渐从思维整理工具变为项目的当前状态 ^[0]。

这个循环成立依赖两层约定。第一层是分工：Canvas 负责结构，Markdown 负责细节 ^[0]。画布上只放目标、用户角色、核心场景、功能模块、主流程、已确认决策、待确认问题，每个节点连到对应的 Markdown 文件，完整需求、会议记录、用户反馈和研究资料留在本地文件里 ^[0]。第二层是协议：颜色表示状态（紫色核心目标、蓝色功能、绿色已确认、黄色等待确认、红色风险、灰色参考），空间有固定含义（从左到右流程推进、从上到下层级拆解、下方风险与待办），连线语义明确（箭头=流程或依赖、无箭头=普通关联、“阻塞”=无法继续的原因）^[0]。这些规则的目的不是让画布好看，而是让人和 Agent 对同一张画布形成稳定理解 ^[0]。设计指南也指向同一方向：除了”把链条做成节点与连线” ^[53]，还有共享视图模式——在共享画布或工作区中实时可见 AI 正在看什么、做什么 ^[53]。

多 Agent 场景下，共享画布的价值更明显：负责研究、写作、生图的多个 Agent 如果分散在各自的聊天窗口，人很快失去全局 ^[0]。画布统一了每个任务的负责 Agent、输入输出文件、当前状态、前置依赖和是否需要人工确认 ^[0]。视觉协作工具领域的总结也指出，画布让决策、负责人、时间线和依赖关系一目了然，团队更容易达成一致 ^[55]。最终的分工是：Chat 负责即时交流，Canvas 负责结构与状态，Markdown 负责细节沉淀，Agent 负责读取与执行 ^[0]。

边界：Canvas 不是万能的

素材也列出了四类边界。第一，画布不是越大越好 ^[0]。素材引用 Sensecape 研究指出，当 LLM 快速产生大量内容时，单张画布容易出现视觉拥挤，更好的做法是分层：项目总览一张、产品流程一张、页面结构一张 ^[0]。类似判断也出现在其他产品中：Seede AI 的团队认为大多数用户没用过无限画布，早期默认只提供简单的垂直布局，熟练用户才切换到无限画布模式 ^[51]。

第二，空间位置可能产生歧义 ^[0]。人会觉得距离近的节点关系密切，但 Agent 未必知道这种隐含规则，重要的关系要用连线、标签和明确命名来表达 ^[0]。第三，不要让 Agent 拥有无限修改权 ^[0]：哪些节点可改、哪些只读、删除是否需要确认、哪些区域由人维护，都要有边界，否则 Agent 可能在”整理”过程中把重要内容一并优化掉 ^[0]。第四，结构本身有成本 ^[0]：非线性界面引入了视图切换和导航成本，用户也可能无法确定不同分支到底继承了哪些上下文——素材称这一点来自 CanvasConvo 研究 ^[0]。

因此快速问答仍然应留在 Chat 里 ^[0,1]。只有当任务涉及多个方向、多个文件、多个决策和较长执行周期时，Canvas 的价值才真正体现出来 ^[0]。