Agent 產出變更的速度已經超過人類逐一審視的能力，這句話在 2026 年不再是預言，而是每天的工作現場。GitHub 開發者倡導者在 8 月 17 日的官方部落格文章中直指這個斷點：我們已經有工具可以 plan、build、review、ship，但多數 workflow 仍然是碎片化的，context 在不同 thread 與介面之間流失，開發者花在審視 agent 產出的時間不斷膨脹，而現有的開發工具當年並不是為 multi-agent orchestration 而設計。
文章的核心主角是 GitHub Copilot app 的 canvases 功能：一個讓人與 agent 在持久、共享表面上協作的畫布，讓工作在展開的過程中變得可視、可導引、可批准。對 AI-native builder 來說，這不只是一個新介面，而是一個把 agentic workflow 從聊天記錄升級為有狀態系統的機會。以下拆解它的設計邏輯、兩個實戰案例的成本帳本，以及可以直接帶走的落地藍圖。
chat 表達 intent 很強，承載執行卻很弱
作者對 chat 的評價相當公允：chat 是表達 intent 最好的介面之一，適合在問題還很模糊的時候思考、修正、下指令。但一旦 agent 開始真正做事，chat 就變成一長串指令、log、轉向與修正的捲動記錄。計畫、決策點、驗證結果、需要人類批准的時刻，這些關鍵資訊技術上都在，但全部被埋在歷史裡。如果你得從頭回放 context 才能知道現在做到哪裡，付出的就是文章所稱的 coordination tax。
Canvases 的解法是給 workflow 一個家：讓狀態顯性且持久。人類可以檢視與導引，agent 可以更新與推進，雙方不需要不斷重播 context 就能保持同步。用系統設計的語言來說，這是把對話式互動的臨時狀態，升級成可審計的持久狀態，而治理就發生在這個差異上。
兩個 canvas：一個治理現代化，一個治理內容
文章給了兩個完整案例。第一個是 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 來說，這篇文章最有價值的不只是功能介紹，而是一個可以直接沿用的工作架構。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。