作者：Ayan Gupta
排版：Alan Wang
聊天适合表达意图，但当智能体开始执行任务时，整个工作过程很容易淹没在不断滚动的对话中。本文分享我是如何将 Canvas 与我的 Agentic Workflow 结合使用的，以及为什么你的工作流也值得拥有一个 Canvas。
当我还在大学时，我加入了 VS Code 最早一批 AI 内联代码补全的 Beta 测试。那种体验让我觉得，这将彻底改变编程方式。从那以后，生成式 AI 确实从根本上改变了软件开发：如今的软件团队正逐渐演变为由 Agent 与开发者协同工作的混合团队，而开发者则处于整个流程的核心，既是愿景制定者，也是工作流的编排者。我们正身处这场转变之中。
随着 GenAI 的快速发展，一个自然的结果就是，我们已经拥有了覆盖规划、开发、代码审查到发布整个生命周期的 AI 工具。但在现阶段，许多开发工作流依然是割裂的。上下文会在不同的聊天线程和界面之间丢失，大量时间被消耗在审查 Agent 生成的内容上。Agent 生成代码和修改的速度已经远远超过人类的审查速度，而大多数开发工具最初也并不是为多 Agent 协同编排设计的。于是，你很容易失去对整个流程的掌控：哪些任务已经执行、哪些内容发生了变化、哪些验证已经完成、哪些环节仍然需要人工判断。
GitHub Copilot App 正是朝着解决这些问题迈出的重要一步。而其中一个我越来越喜欢、几乎每天都会使用的功能，就是 Canvas。Canvas 为开发者与 Agent 提供了一个持久共享的协作界面。它不再把聊天窗口当作工作的唯一载体，而是让工作过程在执行过程中变得可见、可引导、可审批。
聊天很适合表达意图，但并不适合承载持久执行过程
我依然认为，聊天是目前最好的意图表达界面之一。它适合思考、推敲和下达指令。面对一个尚不明确的问题时，它快速而灵活。
但一旦 Agent 开始真正执行任务，聊天窗口就会迅速变成一长串滚动的信息流：指令、日志、方向调整、修正......真正重要的信息虽然都在那里，却被埋没了：计划是什么、关键决策点在哪里、哪些验证已经完成、哪些地方等待审批。如果你需要回过头从聊天记录里重新拼凑这些内容，你其实已经开始为协作支付"协调成本"。
Canvas 的作用，就是为工作流提供一个"家"。它让工作状态变得明确且持久。开发者可以随时查看和引导流程，Agent 可以持续更新进度，两者无需不断重复上下文，也能始终保持同步。
第一个 Canvas：Java Modernization Studio
我构建的第一个 Canvas，是 Java Modernization Studio。Java 现代化迁移本身就是一种极度依赖可视化和治理能力的工作流：应用评估、迁移规划、迁移任务执行、验证关卡，以及最终的发布准备。
如果这一切都发生在聊天窗口里，各个阶段很容易混杂在一起。流程依然能够推进，但随着参与者增多，审计难度会上升，团队对流程的信任也会下降。团队总是在反复提出那些代价高昂的问题：
-
我们现在处于哪个阶段？
-
做出了哪些决策？
-
哪些任务被阻塞了？
-
哪些步骤仍然需要人工审批？
Java Modernization Studio 将每一个阶段都显式展示出来，并且可以随时查看。团队不再需要解析聊天记录，而是直接看到工作流当前的运行状态。不再需要猜测发生了什么，而是能够验证发生了什么。人工审核员可以把注意力集中在真正重要的判断上，而 Agent 则持续推动工作在各个检查点之间流转。
体验 Java Modernization Studio Canvas。
第二个 Canvas：Site Studio
之后，我又构建了 Site Studio。它解决的是另一类工作流：个人网站内容的创建与管理。相比 Java Modernization Studio，它更偏向内容创作，而不是代码迁移。但两者面对的是同一种编排问题：章节进度、迭代编辑、审核循环，以及状态流转。
如果完全依赖聊天窗口，内容状态会很快漂移。一个章节改了一次，又改了一次，很快大家就不知道哪一版才是最新版本。反馈散落在聊天记录里，草稿不断重复，每一次修改几乎都要重新建立上下文。
Site Studio 将这些状态持久保存下来。每个章节当前的状态清晰可见；草稿内容会随着工作持续保存；人工审核节点也明确标识出来。Agent 可以持续推进内容创作，而开发者则可以随时介入，引导、审批或调整方向，而不会丢失上下文。
一个可以复用的模式
在这两个 Canvas 中，我发现了一套可以不断复用的设计模式：
-
明确定义工作流状态。
-
将真正重要的决策显式展示出来。
-
第一时间持久保存进度和草稿。
-
保留明确的人工审批节点。
这种方式将人与 Agent 的协作，从一次次 Prompt 驱动的交互，转变为一种可持续存在的协同工作流。你不再把每一轮聊天都当成一个新的开始，而是把整个 Workflow 当成一个拥有记忆、结构和控制能力的系统。
成本与效率：没错，Canvas 是一种投入
我也想坦率谈谈成本。构建 Canvas 确实需要投入。例如，Site Studio 大约消耗了 2,000 AI Credits；Java Modernization Studio 大约消耗了 3,000 AI Credits。设计和打磨一个好的 Canvas，需要投入不少精力。
但对于那些需要重复执行的工作流来说，这种投入会在长期得到回报。持久化的协作界面意味着：减少重复 Prompt，减少上下文丢失，减少无意义的来回沟通，减少重复返工。随着工作不断重复执行，它既节省时间，也节省成本，同时提升团队的信任度和整体吞吐能力。
所以，对我来说，这并不是"花更多 Token 换一个更漂亮的界面"。而是：投资于更好的工作流架构，让重复发生的工作变得更加高效、可预测、可治理。
现已在 awesome-copilot 中可用
我构建的两个 Canvas------Java Modernization Studio 和 Site Studio ------现已发布到 awesome-copilot。任何人都可以使用它们、修改它们，或者将它们作为构建自己 Canvas 的参考。
如果你已经在使用 GitHub Copilot Agent，一个很实际的下一步就是：挑选一个团队里会重复执行的工作流，然后使用 /create-canvas 为它构建一个最小可用的 Canvas。从一个简单版本开始，在真实工作中不断迭代。如果它确实帮助到了你的团队，也欢迎把它贡献回 awesome-copilot，让更多开发者受益。
我们仍然处于 Agent 时代转型的早期，但方向已经越来越清晰。Agent 负责加速执行；开发者负责愿景、判断与责任。而 Canvas，正是让这种协作关系真正变得可见、持久且可规模化的一种方式。
使用/create-canvas构建属于你的 Canvas，并将它贡献回 awesome-copilot。