GitHub Copilot Canvases：Agent 从聊天窗口走向可操作的共享工作面

GitHub 在 7 月 21 日发布 Copilot Canvases 官方介绍，把 Agent 的输出从连续对话扩展到可交互界面。用户不再只能用下一条提示词纠正结果，而是可以在同一个 Canvas 中点击、编辑、拖动或执行动作；Agent 也能读取这些变化并继续工作。

这并不是简单的“把回答画成卡片”。按照 GitHub Canvas 扩展文档，Canvas 是一个共享、双向的工作面，可以承载计划、看板、浏览器会话、发布清单、仪表盘、事件或表格等工件。它试图解决聊天交互的一个长期问题：讨论目标适合用对话，但检查进度、比较状态和执行结构化操作通常更适合可见界面。

一个工作面同时服务人和 Agent

Canvas 打开在 GitHub Copilot app 的右侧面板。Agent 可以根据用户描述生成界面、共享状态和可调用能力；用户对界面的操作可以在本地处理，也可以回传给 Agent。之后还可以继续要求 Agent 增删功能，让界面随工作流演进，而不是一次性生成后固定不变。

创建入口是会话中的 /create-canvas。提示词需要说明人能够做什么、Agent 能够做什么。官方文档还给出两种持久化范围：团队共享的扩展放在仓库 .github/extensions，个人扩展放在本机 ~/.copilot/extensions。常见结构包含 package.json、定义行为与能力的 extension.mjs，以及可选的 JSON 状态文件。这说明 Canvas 本质上是可维护的扩展工件，不只是临时渲染结果。

代码架构图把解释变成可探索对象

GitHub 展示的代码架构 Canvas 会读取项目结构，把组件关系绘制为可筛选、拖动和悬停查看的节点图。用户能够直接探索数据流、认证、游戏逻辑或 UI 层，而 Agent 在左侧会话中继续解释和修改扩展。

*图：GitHub 官方产品演示中的代码架构 Canvas；这是厂商演示截图，用来说明节点筛选、关系查看和共享工作面，并非独立效果测评。来源：GitHub 官方博客。*

相比一段静态“代码库概览”，这种界面更适合需要反复定位关系的任务。用户可以在图上发现遗漏，再让 Agent 修改分析逻辑或增加过滤能力。不过，官方页面展示的是示例代码库，没有给出大型仓库的构建耗时、准确率或关系抽取错误率，因此不能把演示直接外推为所有项目都能得到完整架构模型。

Worktree 管理把 Agent 会话状态显性化

另一个示例把多个 Copilot 会话关联的 Git worktree 显示为状态图，区分主工作树、活跃、陈旧和孤立项，并提供刷新或清理入口。对同时运行多个编码 Agent 的团队，这类界面把“哪个会话占用哪个分支、哪些工作树已经失效”从记忆负担变成可检查状态。

*图：GitHub 官方演示中的 Worktree Graph Canvas；右侧展示状态与操作按钮，左侧保留 Agent 的解释和执行记录。截图是厂商示例，不代表系统会自动避免所有误删或分支冲突。来源：GitHub 官方博客。*

这里也存在重要边界：界面更直观，不等于操作更安全。涉及删除陈旧 worktree、关闭 Issue 或修改团队状态时，仍应保留确认、权限、审计和可恢复机制。官方示例展示了操作入口，却没有完整说明每类危险动作的保护策略。

从演示走向团队工作流，还要补治理

官方还展示了 Issue 卡片分流、提示词教练和跨 Slack、Teams、邮件、文档寻找知识负责人的场景。它们共同指向一个变化：Agent 产品开始把“可见状态、直接操作、持续协作”作为核心界面，而不是让用户在聊天记录中寻找所有上下文。

对产品经理、设计师和开发团队，最值得借鉴的不是复制某个深色看板，而是先定义共享工件：哪些状态必须可见，哪些动作可以由人直接操作，哪些能力允许 Agent 调用，数据保存在哪里，以及交接后谁能继续维护。Canvas 文档能证明扩展结构和示例已经存在，但没有提供企业级权限隔离、第三方连接器数据范围、扩展供应链审查和大规模协作指标。正式采用前，这些仍需要结合 Copilot app 的组织策略与安全机制单独验证。

当前证据支持的结论是：GitHub 正在把 Copilot app 从对话式 Agent 客户端扩展为可生成、可持久化、可双向操作的工作面。它能否成为稳定的团队应用平台，还要看扩展审核、权限治理、复杂状态一致性和真实团队使用数据。