GitHub Copilot 推出画布，但实时人机协作仍有待验证

GitHub Copilot 于 7 月 21 日推出画布这一全新的扩展格式，首次将智能体协作带出文本对话的范畴。GitHub Copilot 的画布公告介绍了开发者与 AI 智能体可以共同更新的共享界面。这一转变看似不大，却对将聊天记录作为智能体工作默认控制面板的模式发起了挑战。

开发者可以在 GitHub Copilot app 中输入 /create-canvas，并描述所需的界面和功能。随后，Copilot 会构建一个显示在智能体会话旁的画布。智能体可以更改其中的内容，而开发者则能在同一界面上点击、编辑、批准、重新组织或调整工作方向。

如今，更大的竞争已不再是 GitHub Copilot 与某一款编程助手之间的较量。GitHub 正在与 OpenAI 的 Codex app 等产品所采用的指挥中心模式竞争。这类产品负责组织并行智能体及其输出，而 GitHub Copilot 画布则试图让每个工作对象都能直接交互。

这种差异引出了一个核心问题：生成式界面能否改善监督，还是只会增加开发者必须检查和调试的另一层内容？

GitHub Copilot 画布将智能体对话转变为共享工作区

重要的变化并不在于 Copilot 能够生成界面，而在于该界面会成为双方共享的操作状态。

GitHub 将画布称为 Copilot app 中共享的交互式界面。智能体可以在工作过程中更新该界面。用户则可以通过界面控件操作同一组信息，而不必将每个决定都转换成新的提示词。

画布公告将这一设计定位为对话难以胜任之任务的解决方案。待办事项分类、系统图表、会话管理和跨来源研究都要求用户先对比信息，再采取行动。

聊天能够完成这些工作，但通常并不顺畅。开发者必须找到相关回复、重建其上下文、请求修改，然后检查另一段生成的文本。重要状态可能会分散在数十轮对话中。

画布则将这些状态放入结构化视图中。它可以显示议题卡片、依赖关系图、发布检查清单或一组活跃的 worktree。无论用户还是智能体采取操作，该界面都会随之变化。

GitHub 的议题分类示例具体展示了这种差异。提示词要求 Copilot 创建一个卡片界面，用户向一个方向滑动即可发布议题，向另一个方向滑动则可拒绝议题。每项操作都会将议题移入相应分组，并立即更新画布。

另一个示例要求 Copilot 呈现代码库的交互式图表。节点代表项目组件，并展示它们之间的关系。开发者可以通过可视化方式探索结构，而智能体则会随着理解的变化刷新图表。

GitHub 还展示了会话 worktree 管理器。worktree 是一种隔离的检出环境，允许智能体修改代码库，而不会干扰其他会话。画布会将这些并行分支转换为可见项目，供开发者检查和管理。

其余示例则超出了代码库检查的范畴。一个画布通过交互式审查流程帮助改进提示词，另一个则搜索已连接的工具，以识别与某个文件或主题相关的人员。

这些并非五个固定的产品模块，而是根据指令生成的示例，这意味着界面可以随工作流程演变。开发者可以要求 Copilot 添加筛选器、更改控件或提供其他操作。

画布文档说明，画布既可供个人使用，也可以与团队共享。个人扩展位于用户级目录中，项目扩展则可存储在 .github/extensions 下并提交至代码库。

这种代码库级作用域非常重要。实用的画布可以成为持续维护的团队资产，而不会随某次对话一起消失。团队可以审查其实现、调整其行为，并通过常规开发流程分发同一操作视图。

文档还区分了人类操作与智能体可调用的功能。看板画布可以允许用户拖动卡片，同时向智能体提供检索、创建或移动卡片的函数。双方通过不同的控件操作同一个状态模型。

这一安排构成了 GitHub 所宣称的实时人机协作基础。用户不再只是看着智能体生成答案，而是与智能体共同操作工作的共享表示。

然而，首个版本提供的是示例、文档和技术模型，而非能够广泛证明其带来更好结果的证据。GitHub 已经展示了发生了哪些变化，但尚未证实生成式画布能在多大程度上超越开发者熟悉的代码库工具。

为什么智能体监督已成为新的开发者界面问题

画布之所以出现，是因为 AI 编程工具在解决最初的代码生成问题后，又带来了协调问题。

早期的编程助手围绕光标工作。它们会建议补全内容、解释函数或生成一小段代码。开发者始终处于实现循环之中，并能在大多数更改发生时看到它们。

智能体系统的工作方式不同。它们会检查代码库、修改多个文件、运行命令、测试结果，并持续工作更长时间。开发者越来越多地通过计划、状态消息、差异、终端和拉取请求来监督这一过程。

在发布 7 月的示例之前，GitHub 就已经注意到了这种压力。该公司在 6 月发布的技术预览更新中表示，持续时间更长的智能体会话会使人类的工作重心转向管理输出。开发者必须阅读会话记录、找出有意义的差异，并反复纠正智能体的工作方向。

Copilot app 已经缓解了部分负担。它可以在隔离的 worktree 中运行并行会话、显示计划和差异，并通过集成的终端和浏览器支持验证。它还能连接从代码库、本地文件夹、议题或拉取请求启动的会话。

GitHub Copilot 画布针对的是另一个方面。它们试图呈现工作本身，而不只是围绕工作的对话或执行历史。

发布经理并不会天然地以聊天轮次进行思考，而是关注受阻项目、已批准步骤、负责人、截止日期和依赖关系。画布可以直接呈现这些对象，并允许智能体通过同一结构进行操作。

同样的原则也适用于代码库探索。会话记录可以列出依赖关系，但图表能够让关系更易于快速浏览。其价值在于减少智能体的解释与用户工作模型之间的思维转换。

这种方法也反映出执行与监督之间日益明显的分工。智能体负责更多机械性步骤，而人类则决定应该发生什么、输出是否可以接受，以及何时有必要进行干预。

OpenAI 在 2026 年 2 月发布 Codex app 时，也描述了类似的问题。该应用按项目组织独立的智能体线程、支持隔离的 worktree，并为开发者提供检查更改或对差异发表评论的场所。

因此，参与竞争的产品对问题的判断是一致的：传统编辑器和线性对话并不是为监督多个长期运行的智能体而设计的。

它们的区别在于界面侧重点。Codex 的指挥中心模式将智能体会话作为主要工作单元，而 GitHub 的画布模式则将计划、看板、图表和其他产物作为潜在的协作界面。

这两种模式都不会取代编辑器、终端或拉取请求。相反，它们都试图在这些成熟工具之上构建一个管理层。最终胜出的方案需要在不隐藏重要实现细节的前提下减少协调工作。

GitHub 在这场竞争中拥有一项结构性优势。代码库、议题、拉取请求、审查、检查和团队权限已经存在于其平台上。画布可以紧邻其所代表的工作对象。

但这种接近性并不能保证用户会采用它。开发者已经在使用 GitHub Projects、议题列表、编辑器扩展、仪表盘、脚本和第三方服务来管理这些对象。生成式画布必须比这些替代方案更易于创建、操作也更安全。

团队还需要在任何单一界面之外保留持久的上下文。可搜索的工程知识库可以跨智能体会话保存决策、规范和本地技术文档。画布处理的是活跃交互，而留存的知识解决的是连续性问题。

这正是此次发布的意义超越 Copilot 新功能本身的原因。GitHub 正在押注：下一代开发者界面将组织人、智能体与工作对象之间的关系。聊天窗口只会成为这一环境中的一部分。

GitHub Copilot 推出画布，让智能体工作可供检查

其核心机制是一个双向状态循环，让人类和智能体能够读取、更改并验证同一个工作对象。

传统聊天遵循基于轮次的顺序。用户下达指令，模型作出回应，然后用户再提出请求。即使智能体会调用工具和执行命令，会话记录仍然是主要的协调记录。

画布在这些轮次之间增加了一个结构化对象。该对象可以包含卡片、节点、控件、字段、状态值或其他界面元素。人类操作会改变其状态，而智能体也可以随着工作的推进更新该状态。

GitHub 的文档描述了这一循环中的三个角色。用户检查并引导状态，智能体读取画布并采取结构化操作，Copilot app 则将界面连接到底层产物或运行环境，同时控制允许执行的操作。

第三个角色很容易被忽视。仅凭美观的界面并不能实现可信赖的协作。应用必须明确哪些操作会影响代码库、外部服务或本地进程。

/create-canvas 命令用于启动工作流程。开发者描述用户应该能够执行的操作，以及智能体应该获得的功能。Copilot 随后生成扩展的基础结构，在侧边面板中将其打开，并接受进一步修改设计的请求。

例如，开发者可以请求一个具有创建、分配和移动卡片控件的智能体看板。画布还可以提供智能体可调用的操作，例如检索看板或更改卡片的位置。

这种区分可以让权限更加清晰易懂。界面展示用户可以执行的操作，而具名功能则限制智能体的操作方式。不过，其安全性仍取决于生成的实现以及每项操作背后的服务。

该架构也支持本地处理。部分点击或编辑操作可以直接在画布内完成，无需将每次交互都发送回模型。其他操作则可在需要推理或外部访问时触发另一个智能体步骤。

这一选择会影响响应速度、成本、隐私和可预测性。本地筛选不应占用一次模型调用，而分析多个问题为何呈现相同的故障模式则很可能需要。

生成式界面也改变了提示词设计。用户不再需要用文字描述未来的每一种交互。他们可以要求 Copilot 将反复出现的决策编码为可见控件，然后随着需求逐渐明确来修改界面。

一个反复进行问题分类的团队可能会从三个类别开始。之后，它可以添加负责人、严重程度、复现状态，以及相关拉取请求的链接。画布由此成为一个通过对话构建、针对特定工作流的小型应用程序。

这类似于低代码开发，但 GitHub 将画布定位于智能体协作，而非通用应用程序开发。该界面存在于 Copilot 内部，与智能体状态保持连接，并且可以向人类和智能体开放操作。

一篇 Microsoft 开发者文章明确阐述了这一区别。其画布运行时示例将该界面视为观察和控制多智能体系统的动态环境，重点在于协调、执行状态和干预。

这一定位解释了 GitHub 为何强调工作树管理，而非面向消费者的应用程序设计。当智能体已经在执行工作，而人需要一种更清晰的方式来检查工作时，画布就很有价值。

这也解释了提示词质量示例。提示词修改通常通过反复的文本交流完成。结构化画布可以展示标准、替代方案、评分和可编辑组件，同时由 Copilot 更新建议。

构建可复用指令的开发者可以将此过程连接到精选的提示词库。提示词库用于保存经过验证的指令，而画布则能让当前的优化过程更加直观、更具交互性。

这种机制仍然很有吸引力，因为它减少了信息转换。用户可以通过最适合任务的形式表达选择。智能体则以结构化状态接收这些选择，而不必从对话语言中推断一切。

不过，当结构化状态不完整时，它也可能造成误导。绿色卡片、已勾选的复选框或整洁的图表都会带来信心。如果底层智能体跳过了某项测试或误解了某个依赖关系，视觉上的清晰度反而可能掩盖技术上的不确定性。

因此，界面必须呈现证据，而不只是状态。已完成的迁移步骤应连接到日志、差异、测试或其他可验证的产物。否则，画布可能会让智能体输出看起来比实际情况更加确定。

真正的竞争是共享产物与智能体指挥中心之争

GitHub 的主要押注是，开发者将通过交互式产物监督 AI，而不是主要通过智能体对话列表。

指挥中心模式从智能体出发。开发者启动任务、监控多个线程、审查其变更，并选择继续采用哪个结果。工作树和项目分组可以防止并行活动发生冲突。

共享产物模式则从被修改的对象出发。发布看板、架构图、拉取请求或事故检查清单成为中心，智能体以参与者身份对该对象执行操作。

两种模式都支持委派。当工作跨越多个会话，或涉及并未编写原始提示词的人员时，二者之间的差异就会显现。

会话列表保留了谁提出了什么要求，以及智能体如何响应。这些历史记录有助于调试、问责和恢复。不过，它迫使后续参与者根据之前的对话重建当前状态。

共享画布可以立即呈现当前状态。新加入的团队成员无需阅读每次交流，就能看到待处理事项、关联关系、任务分配或审批情况。智能体也可以将该状态作为下一步操作的上下文。

其代价是叙事信息的丢失。简洁的看板可以显示某项变更已被拒绝，却未必保留背后的理由。团队需要建立从可见状态返回讨论、证据和代码库历史记录的链接。

GitHub 非常适合连接这些层级。项目范围的扩展可以与代码库共存，而画布操作可以引用议题、分支、检查或拉取请求。该公司已经掌控了周边工作流的很大一部分。

OpenAI 的 Codex 战略则从更广泛的智能体平台角度处理同一问题。其桌面应用支持技能、自动化、隔离工作和多个项目，其指挥中心并不局限于 GitHub 原生的产物。

这种更广泛的覆盖范围带来了灵活性，但也需要连接器和权限来重现 GitHub 已经拥有的上下文。当代码库仍是唯一可信来源时，GitHub 更聚焦的集成可能显得更加自然。

Anthropic 的 Claude Code 代表了另一条路径。其以终端为中心的设计让开发者始终贴近命令、文件和明确的工具活动。这种方式更有利于技术透明度，但为非线性协调提供的视觉结构较少。

因此，市场正在检验三种界面中心：

• GitHub Copilot 画布以共享工作对象为中心。

• 智能体指挥中心以并行会话和委派为中心。

• 终端智能体以执行、命令和直接的代码库交互为中心。

这些方式可以共存，产品也会相互借鉴。GitHub 自己的应用已经包含会话管理、终端、浏览器、工作树和自动化功能。画布增加的是一个以产物为中心的层级，而不是取代这些功能。

压力最集中地落在那些只提供聊天、却没有持久化操作视图的产品上。随着会话变长，仅靠对话记录会变得越来越难以浏览。用户需要结构化状态、更强大的审查工具，或同时拥有二者。

GitHub 也给传统项目管理界面带来了压力。固定看板要求用户调整工作方式，以适应预定义的字段和工作流。生成式画布则承诺提供一个能够围绕团队当前问题变化的界面。

这一承诺伴随着维护成本。自定义界面可能偏离团队规范，在底层 API 发生变化后失效，或变得只有创建者才能理解。标准工具仍然很有价值，因为所有人都熟悉其行为。

可复用的项目范围画布或许能降低这种风险。团队可以像审查代码一样审查画布，为其功能编写文档，并提交变更。成熟的画布可以成为内部产品，而非一次性的生成式实验。

衡量采用情况的关键并不在于开发者是否喜欢创建画布，而在于新鲜感消退后，团队是否还会回到同一个画布。重复使用将表明该界面已经成为工作系统的一部分。

如果出现这种情况，GitHub 以产物为中心的模式将获得优势。如果大多数画布仍只是临时演示，指挥中心和成熟的代码库视图将继续承担严肃的协调工作。

生成式界面带来新的信任与治理风险

画布可以让智能体行为更容易被观察，但其生成式控件也扩大了团队必须验证的范围。

第一个不确定性涉及正确性。Copilot 根据自然语言请求生成扩展，用户之后还可以要求它修改功能。每次变更都可能在渲染、状态管理或操作处理方面引入错误。

熟悉的 GitHub 按钮具有经过测试和文档塑造的可预测行为。生成式按钮可能会调用几分钟前才创建的自定义代码。即使其实现几乎未经审查，按钮标签仍可能显得权威可信。

当画布改变外部状态时，这种差距尤为重要。如果操作只保留在本地，移动一张可视化卡片的风险很低；但批准部署、关闭议题、合并变更或更新云资源则需要更强的控制措施。

团队应检查每项可由智能体调用的功能能够访问哪些内容。他们还需要了解某项界面操作究竟是在本地执行、调用智能体，还是访问外部服务。

第二个不确定性涉及状态同步。人类和智能体可能同时对同一界面执行操作。系统必须处理过时信息、并发编辑、部分失败，以及以意外顺序完成的操作。

实时协作会让这些问题变得可见，但不会消除它们。画布需要清晰呈现待处理、已完成、失败和已还原状态。否则，用户可能会把界面的乐观更新误认为已确认执行。

第三个风险是证据压缩。仪表盘擅长汇总状态，但摘要会省略细节。智能体可能在测试通过后将任务标记为完成，却忽略了一个从未被覆盖的集成场景。

画布应保留指向差异、日志、命令、测试结果和审批历史记录的链接。可视化状态必须始终能够追溯到技术证据。团队应避免让界面成为唯一记录的工作流。

安全性同样值得重视。项目范围的扩展会成为代码库内容，因此其代码可以进入审查和版本控制流程。个人扩展则处于这一共享流程之外，在不同机器上的行为也可能不同。

外部工具会带来更多问题。用于搜索组织系统或识别相关专家的画布需要获得适当授权。生成式界面不应暴露超出请求用户访问权限的信息。

GitHub 文档区分了用户范围和项目范围，但每个组织仍需制定有关审查、分发和允许集成的政策。即使创建者从未手动键入代码，生成式扩展依然是代码。

无障碍性是另一个尚未解决的衡量维度。可视化工作流可以帮助许多用户，但生成式界面可能会产生薄弱的键盘导航、含义不清的标签、较差的对比度，或屏幕阅读器无法解读的控件。

标准化组件库和验证机制可以改善这方面的问题。当前公告重点介绍了可能实现的各种体验，并未公布生成式示例的无障碍测试结果。

用户采用情况也仍未得到验证。GitHub 的示例展示了合理可行的工作流，但该公司尚未发布对比研究来证明分类速度更快或智能体错误更少。这些结果需要独立测量。

一项有效的评估应比较同一任务的三个版本。一组可以使用聊天，另一组使用传统固定工具，第三组使用生成式画布。研究人员可以测量完成时间、纠正频率和遗漏错误。

团队还应追踪创建成本。一个只需五分钟创建、每周都能节省时间的画布具有明确价值。一个需要不断通过提示词进行修复的界面，则可能成为又一个需要维护的内部工具。

因此，GitHub 的核心主张应保持克制。画布让智能体工作更具交互性，并可能更易于检查；但它不会自动让智能体变得正确、安全或更易于治理。

最可靠的实现会将该界面视为附带可审计证据的控制面板。最薄弱的实现则会把它当成智能体成功的视觉确认。

GitHub Copilot Canvases 发布后开发者应关注什么

接下来的三个信号将表明，画布会成为持久的基础设施，还是仍然只是一项颇具吸引力的预览功能。

第一个信号是团队实际重复使用的项目级扩展的质量。与提交到活跃代码仓库、由多位开发者审查并随工作流变化持续维护的画布相比，公开示例并没有那么重要。

应关注那些不止用于一次演示，而是长期存在的共享看板、事件处理工具、迁移跟踪器和代码库地图。重复使用将支持 GitHub 的主张，即工作对象可以成为稳定的人机协作界面。

大量一次性实验则会削弱这一论点。这意味着生成式界面适合快速可视化，但不适合作为可靠的团队基础设施。

第二个信号是 Copilot 应用内部更强的治理能力。团队需要权限边界、可见的操作历史、验证工具，以及对本地界面变更和外部操作的明确区分。

GitHub 的文档已经介绍了作用域位置和明确能力。下一步是让管理员和普通用户都能理解审查机制与运行时行为。

应关注标准化安全检查、扩展审批策略、无障碍验证和更完善的审计跟踪。这些新增能力将表明 GitHub 预计画布会用于控制具有重大影响的工作。

如果治理能力没有改进，其在大型组织中的采用将受到限制。如果没有明确的强制机制和证据，企业团队不太可能信任围绕代码仓库、事件或部署生成的控制界面。

第三个信号是竞争对手如何回应。OpenAI、Anthropic、编辑器厂商和项目管理平台都面临同样的监督问题。它们的应对方式将揭示共享工件是否会成为行业模式。

OpenAI 已经在 Codex 工作流中支持注释、智能体线程、应用和可共享的工作成果。它可以在不采用 GitHub 特定扩展架构的情况下，转向功能更丰富的双向界面。

Anthropic 可以在增强终端可见性的同时，加入结构化审查界面。编辑器可以让计划、差异、测试和智能体操作更具交互性，而无须使用单独的桌面应用。

如果竞争智能体加入持久、共享的工作对象，GitHub 的界面理念将得到支持。如果它们转而专注于改进会话导航和执行透明度，市场可能会更青睐指挥中心。

开发者目前无须选择一种长期固定的模式。他们可以从一个聊天会产生明显阻力的重复性工作流入手。问题分类或并行会话审查都能提供切实可行的测试场景。

实验应保留由人类审批重大操作的机制。每一种可视化状态都应链接到代码仓库中的证据，团队还应记录画布需要修复的频率。

经过多个周期后，将节省的时间与扩展维护及审查工作量进行比较。此外，还应统计遗漏的问题、错误操作，以及用户为弄清情况而返回对话记录的次数。

GitHub Copilot 画布值得关注，因为它们将界面设计变成了智能体编排的一部分。此次发布承认，仅靠更好的模型无法解决监督问题。

悬而未决的问题是，生成式界面究竟能改善人类判断，还是仅仅让智能体输出看起来更美观。开发者应通过真实工作、证据和重复使用来检验这一区别。

如果 GitHub Copilot 画布能成为值得信赖的工作检查、引导和验证场所，聊天将不再是主要的智能体界面。如果不能，对话记录即使杂乱无章，也仍将不可或缺。