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 本身的視覺效果同樣重要。
