GitHub 于 2026 年 7 月 21 日介绍 Copilot canvases，将 Copilot 的对话式 agent 放进一个可交互的工作面。这个方向针对的不是「如何再问一条 prompt」，而是有些任务本身需要可视化、筛选、点击和逐步修改，单靠一串消息来回并不容易完成。
GitHub 把 canvas 描述成 Copilot app 的延伸界面。Agent 可以一边工作，一边更新同一个 canvas；用户则可以直接点击、编辑或操作画面，这些互动再传回 agent，或者由 canvas 在本地处理。对需要整理信息和采取行动的工作来说，这种双向互动比只等待文字回答更接近实际工作台。
文章列出的例子包括以卡片方式逐一整理 GitHub Issues、把代码库画成可探索的互动关系图，以及查看不同 Copilot session 和 worktree 的状态。另一些 canvas 则用来改善 prompt、跨 Slack、Teams、电子邮件和文档寻找知识，显示同一种界面可以承载资料查看、决策和后续操作。
其中一个重要细节，是 canvas 可以随着 agent 的工作持续演化。用户可以要求 agent 增加功能、调整布局或修改互动方式，而不是每次都重新开始。这使 agent 由一次性的生成器，转向一个可共同维护的工作空间；但生成的界面仍然需要人员检查资料是否完整、操作是否符合预期。
GitHub 建议在 Copilot app 的 agent session 使用 /create-canvas 建立 canvas。这篇文章主要是功能介绍和使用示例，没有提供跨团队效率、准确率或成本的独立基准。因此，不能单凭示例推论所有代码管理或工作流都会获得同样改善。
对 agent 产品而言，canvas 的意义在于把「理解」和「操作」放在同一个表面。当任务涉及 backlog triage、资料关联、流程查看或多个候选方案时，用户需要看到中间状态，也需要能够在关键位置介入。可交互工作面未必代表更高程度的自主化，但可以让代理的推理、输出和人工决定更容易对接。
采用这类界面时，团队仍应先定义哪些互动可以由 agent 执行、哪些只可本地预览，以及哪些动作需要确认。权限、数据来源、生成 UI 的测试和操作记录，会和 canvas 本身的视觉效果同样重要。
