技术速递｜Canvas 如何让 Agentic Workflow 更可见、可控、更高效

原创于 2026-08-20 20:49:32 发布 · 293 阅读

本内容遵循CC 4.0 BY-SA版权协议

作者：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 可以持续推进内容创作，而开发者则可以随时介入，引导、审批或调整方向，而不会丢失上下文。

在这里插入图片描述

体验 Site Studio Canvas。

一个可以复用的模式

在这两个 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。

标签