摘要： GitHub 開發者倡導者於 8 月 17 日撰文介紹 Copilot app 的 canvases，把 agentic workflow 從聊天捲動搬進持久、可審視、可導引與可批准的畫布。文中以 Java Modernization Studio 與 Site Studio 為例，分別約花 3,000 與 2,000 AI credits，並提出定義狀態、顯示決策、持久化進度與保留人工批准點的藍圖。
到了 2026 年，agent 產出變更的速度早已超出人類逐項複核的極限，這已經不是預言，而是每天上演的工作現場。一位 GitHub 開發者倡導者在 8 月 17 日的官方部落格文章中點出這個斷點：plan、build、review、ship 的工具我們都已經有了，但多數 workflow 依然零碎；context 在 thread 與介面之間流失，開發者審視 agent 產出的時間不斷膨脹，而當年那些開發工具在設計之初，根本沒把 multi-agent orchestration 當成前提。
文章的主角是 GitHub Copilot app 的 canvases 功能：一個讓人和 agent 在持久、共享的表面上協作的畫布，工作邊展開邊變得可視、可導引、可批准。對 AI-native builder 而言，這不只是新介面，而是一個把 agentic workflow 從聊天記錄升級成有狀態系統的契機。以下依序拆解它的設計邏輯、兩個實戰案例的成本帳本，以及可以直接帶走的落地藍圖。
intent 交給 chat 表達最好，長期執行卻撐不住
作者對 chat 的評價相當公允：在問題還很模糊的時候思考、修正、下指令，chat 是表達 intent 最好的介面之一。但 agent 一旦真的開始做事，chat 就退化成一大串指令、log、轉向與修正的捲動記錄。計畫、決策點、驗證結果、需要人類批准的時刻，這些關鍵資訊技術上都還在，只是全部被埋進歷史裡。一旦你得靠回放 context 才能確認現在做到哪裡，付出的就是文章所稱的 coordination tax。
Canvases 的解法，是替 workflow 找一個家，讓狀態變得顯性而持久。人類負責檢視與導引，agent 負責更新與推進，雙方不必不斷重播 context 也能保持同步。用系統設計的語言來說，這是把對話式互動的臨時狀態，換成可審計的持久狀態——而治理能力正是從這個差異裡長出來的。
實戰雙案例：一邊治理現代化，一邊治理內容
文章完整拆解了兩個案例。第一個是 Java Modernization Studio，也是作者最早打造的 canvas 之一。Java 現代化正是最需要可視性與治理的 workflow：assessment、planning、migration 任務、validation gates，一路到能不能出貨的判斷。放在純 chat 的體驗裡，這些步驟會糊成一團；規模一大、貢獻者一多，團隊就不斷重複問同樣昂貴的問題：現在在哪個階段？哪些決策已經定了？什麼被卡住？哪裡還需要人類批准？
這個 canvas 的 Overview tab 把整段旅程攤在眼前：Assess、Remediate、Validate、Ship 四個階段一目瞭然，旁邊還有 compile-blocker 卡片、Run on autopilot 選項、P0 到 P3 的 severity 計數，以及自動偵測到的技術棧。審查者讀到的是操作狀態本身，不必從敘事歷史裡考古；高訊號的判斷留給人類，例行執行則交給 agent 在檢查點之間推進。
第二個案例 Site Studio 走的是完全不同的領域：管理個人網站內容。它屬於內容密集而非 migration 導向的 workflow，但 orchestration 的挑戰同構，包括 section 進度、迭代編輯、review loop 與狀態轉移。Content tab 以 100% completion 呈現，Design System、Hero、Navigation、About、Conference Talks、Videos、Contact 每個 section 都可編輯、可標記 ready for review。draft 邊做邊持久化，人類的審查點顯性存在，內容不再隨著反覆修訂而漂移。
成本帳本：2,000 與 3,000 AI credits 換到了什麼
談到成本，作者毫不迴避：Site Studio 花了約 2,000 AI credits，Java 現代化 canvas 約 3,000 AI credits，而且設計與調整本身就需要投入。不過在作者的經驗中，對會重複執行的 workflow 而言，這筆投資終究會回本：durable surface 讓重複 prompt 變少、context 流失變少、不必要的往返與 rework 變少，長期同時省下時間與金錢，信任與吞吐也一併提高。必須說明的是，這是作者的單方經驗，尚未經過獨立驗證。
這裡值得留意的框架，是把錢投在 workflow 架構上，而不是多燒 token 換一個漂亮介面。用資本結構比喻：打造 canvas 的成本接近一次性投資，每跑一輪省下的 coordination tax 則是持續回報。實際回本多快，取決於 workflow 的重複頻率與團隊規模，但至少帳本被攤在陽光下，這在多數 AI 功能發文中相當少見。
可複製的四步藍圖與起步策略
把兩個案例放在一起看，作者歸納出一套反覆出現的藍圖：第一，把 workflow 的狀態定義清楚；第二，把真正重要的決策攤到表面上；第三，progress 與 drafts 立即持久化；第四，保留明確的人類批准點。走完這四步，互動模型就從 prompt-by-prompt 的互動轉成 durable collaborative workflow，每一次對話不再從零開始，workflow 本身成為有記憶、有結構、有控制的系統。
兩個 canvas 已經開源在 awesome-copilot extensions，任何人都可以使用、改作或學習。起步建議同樣務實：挑一個你真的會重複執行的 workflow，用 /create-canvas 圍繞它做一個最小規模的 canvas，先用真實工作跑起來，再依實際使用狀況迭代；若對團隊確實有幫助，就貢獻回 awesome-copilot。
Builder 觀點：workflow 是系統設計題，不是對話經營題
抽掉產品名稱，canvases 示範的 pattern 對任何 builder 都適用：當 agent 成為執行主力，人類的價值就轉向願景、判斷與問責，而介面的責任是讓這三件事有地方發生。三個可以直接帶走的判斷：第一，別把審批點藏在聊天訊息裡，要當成產品功能來設計，因為需要批准的時刻就是治理發生的時刻；第二，狀態持久化不是選配，而是 agent 可被審計的前提，沒有持久狀態就沒有可信任的協作；第三，從最痛、最高頻的重複 workflow 開始，讓成本自然攤提。
限制也要講明白：這套實作目前綁定在 GitHub Copilot 生態；以撰文當下的觀察，credits 的計價模型仍在演進，跨平台的 canvas 抽象也尚未出現。但方向已經很清楚：agent 負責加速執行，人類負責願景與責任，canvas 是讓這個分工變得真實、持久、可規模化的其中一種做法。對正在設計自家 agentic workflow 的 builder 來說，這篇文章最有價值的不只是功能介紹，而是一個可以直接沿用的工作架構。