當五個 AI Agent 同時替你查資料、改程式、做簡報、跑測試，Agent Workspace 的問題就出現了：哪一個還在跑？哪一個卡住？哪份檔案才是最新版？誰正等你核准？真正危險時，又要去哪裡按停止？這些問題不是再開五個聊天分頁就會自動消失。
需求已經浮上檯面。2026 年 8 月 3 日查核時，Hacker News 的〈AI Agent GUI 應該長什麼樣〉討論有 134 points、79 comments；同日 GitHub Trending weekly 在 block/buzz 條目顯示「8,217 stars this week」。這是關注度快照，不是活躍使用、留存或品質證明，卻清楚反映同一個焦慮：聊天 transcript（逐句紀錄）已經很難兼任多任務控制台。
這篇專為第一次接觸 Agent 工作介面的讀者寫。我會先把 Chat、CLI、IDE、Cowork、任務卡與 Workspace 分清楚，再用同一套檢查尺實查開源自架的 Buzz 原始碼與測試契約，並核對桌面 beta MarbleOS 的官方 demo。你也會看到可重現的 Buzz 安裝／連線步驟，以及這次查核做到哪裡、哪些地方仍不能下結論。
先說結論：Agent Workspace 是工作控制面，不是比較漂亮的聊天框
🤖 一句話記住：Agent Workspace ＝對話入口＋共享狀態＋任務佇列＋產物桌面＋控制／觀測面板。
任務卡只是其中一種畫法；真正的價值是讓人看得到狀態、拿得到產物、管得住權限，並能停止、修正與接管。
- 一件模糊任務：通常先用 Chat，因為追問最直接。
- 改程式、跑命令、看 diff：CLI＋IDE 通常最直接。
- 研究、文件、投影片、試算表：成果型 Agent（如 Cowork／ChatGPT Work）或任務畫布，會讓產物比對話更接近工作中心。
- 多件長任務並行：Workspace 才開始有明顯價值，因為你需要跨任務總覽與人工控制。
Agent Workspace 是什麼？先把五種介面當成五個鏡頭
目前業界沒有一份共同規格規定「Agent Workspace」一定包含哪些功能。本文把它定義為：包住一個或多個 Agent 執行工作的持久控制面，讓人建立任務、查看狀態與產物、管理隔離和權限、追蹤用量，並在需要時核准、停止或接管。
這不代表 Workspace 是 Chat 的高級版。現行 Codex desktop、CLI 與 IDE 都能使用 subagent；Claude Code Desktop 可開平行 session，在 Git repository 中每個新 session 會自動使用 worktree 隔離，tasks pane 可查看與停止 subagent。即使這些介面都可能支援平行工作，主要差異之一仍是它以哪種工作單位呈現與控制。
Chat 以一條對話為單位，最適合探索；CLI 以目錄、repo 與 terminal session 為單位，最適合命令和自動化；IDE 把檔案、選取範圍與 diff 放在眼前；成果型 Agent（如 Claude Cowork／ChatGPT Work）偏向「交付一份成果」；Workspace 則把多個 task、session 或 agent 放進同一個操作視野。這些鏡頭會重疊，一個產品可能同時屬於成果型介面與 Workspace。想先理解 Agent 為何能從聊天變成做事，可搭配〈AI Agent Harness 是什麼？〉與〈動手搭一個最小 Harness〉。
一個可用的 Agent Workspace，至少要回答 6 個問題
- 狀態：每件工作是排隊、執行、等待、失敗，還是完成？
- 產物：檔案、diff、報告與測試結果在哪裡？人能不能直接開啟與續做？
- 權限：Agent 可以讀、寫或呼叫哪些工具？哪一個動作必須先核准？
- Trace：它實際呼叫了什麼工具、改了什麼、在哪一步出錯？狀態燈不等於完整 trace，更不等於可重現。
- 成本：看到的是 token、產品估值，還是供應商帳單？三者不能混成同一個數字。
- 停止與接管：能否取消目前 turn、修正方向，再讓人回到同一份檔案或 working tree 接手？
這六項會直接戳破「有任務卡就等於有控制台」的錯覺。卡片可能只顯示漂亮的 Running，卻把重試、錯誤、共用檔案衝突與寬鬆權限藏在下面。若你想專門補 trace、指標與告警的觀念，可讀〈Agent Observability 完整教學〉。
我們怎麼實查 Buzz、核對 MarbleOS？先公開測試邊界
這不是模型跑分，而是介面與控制契約檢查。測試日期為 2026 年 8 月 3 日。Buzz 以 GitHub main 的 commit a5dbdf5 與最新 release desktop-v0.5.3 為準；本機有 Node 24，但沒有 Docker、Rust 與 just，因此沒有假裝完成 relay＋模型的端到端執行。
我們實際 clone 原始碼，執行 onboarding runtime 的 Node 測試，4／4 通過：Claude、Codex、Goose、Buzz Agent 四個 runtime 會出現，顯示順序正確，而且「可用」必須同時滿足已安裝與認證就緒。另以 bash -n 檢查 Compose 啟動腳本並成功讀出 start／stop／upgrade／logs／status 等指令。這能驗證介面契約與部署入口，不能證明本機模型回覆品質或正式環境穩定性。
MarbleOS 方面，官方 macOS updater manifest 與 Windows manifest 在測試日顯示版本 0.0.235、發行日 2026 年 8 月 2 日；公開 changelog 當時只到 0.0.230。我們逐段重播官方 160 秒 demo，核對任務卡、Tools、Files、執行狀態與試算表／投影片產物畫面，但沒有把示範影片當成獨立效能測試，也沒有宣稱未驗證的後端平行度。
Buzz 原始碼實查：它目前更像 Agent 團隊頻道，不是 Marble 式任務看板
Buzz 官方 README把產品稱為「人與 Agent 在自己擁有的 relay 上共同建造的 workspace」。它使用 Nostr 身分與事件，把訊息、反應、git、workflow 與 review 留在同一個簽名事件紀錄裡。畫面第一眼很像團隊聊天室：頻道、thread、DM、canvas、media、搜尋與 agent activity；工作的基本操作是在頻道或 thread 裡 @mention Agent。
Step 1：先自架 Buzz relay 與桌面開發環境
官方開發流程需要 Docker；工具鏈可用 Hermit 管理，或自行準備 Rust 1.88+、Node 24+、pnpm 10+ 與 just：
git clone https://github.com/block/buzz.git
cd buzz
. ./bin/activate-hermit
just setup
just build
just dev
# 預設 relay
# ws://localhost:3000正式單機部署則從 deploy/compose/ 複製 .env.example，再執行 ./run.sh start；開 TLS 可用 BUZZ_COMPOSE_TLS=true ./run.sh start。這不是「下載一個 app 就不必維運」：你要照顧 Postgres 17、Redis 7、MinIO、git volume、TLS、備份、升級與 Nostr 私鑰。自架帶來資料與身分控制，也把維運責任交回你手上。
Step 2：替 Codex／Claude／Goose 建立 Agent 身分
Buzz 的 buzz-acp 透過 Agent Client Protocol（ACP）把 relay 上的 @mention 送給 runtime。每個 Agent 先產生自己的 Nostr keypair，再把公開金鑰加入 relay；秘密金鑰不會自動保存，遺失就無法復原。
先做安全隔離：目前這條 Buzz ACP 路徑沒有可靠的人工作具核准閘。以下指令只適合在不放正式憑證、採最小權限，而且可直接丟棄的容器、VM 或 repo clone 中測試；不要讓它接觸主機上的重要檔案與帳號。
cargo build --release -p buzz-acp
export PATH="$PWD/target/release:$PATH"
cargo run -p buzz-admin -- generate-key
# 把剛產生的 agent 公開金鑰加入 relay
BUZZ_RELAY_PRIVATE_KEY="<relay-signing-key>" \
cargo run -p buzz-admin -- add-member --pubkey "<agent-public-key>"
# Goose 是預設 runtime；先在隔離環境檢查其權限模式
export BUZZ_PRIVATE_KEY="nsec1..."
export BUZZ_RELAY_URL="ws://localhost:3000"
buzz-acp若照 buzz-acp README 的手動啟動範例，Codex 會安裝 @agentclientprotocol/codex-acp 並設定 OPENAI_API_KEY；Claude 會安裝 @agentclientprotocol/claude-agent-acp、設定 ANTHROPIC_API_KEY，再把 BUZZ_ACP_AGENT_COMMAND 指向 claude-agent-acp。Buzz Desktop 的 managed runtime 則會檢查既有 Codex／Claude CLI 登入狀態，所以認證方式依啟動路徑而異。
Step 3：建立第一件工作，平行化要跨頻道
把 Agent 加進一個頻道後，輸入像「@Agent 檢查這個 repo 的失敗測試，先只回報原因與修正計畫」。同一頻道一次只處理一個 prompt；若以 buzz-acp --agents 2 啟動兩個 subprocess，不同頻道才可並行，同一頻道仍保持序列。這比「五張卡一定同時跑」更精確，也能降低同一脈絡中的順序衝突。
Buzz 已能在 activity panel 顯示摘要或 raw ACP JSON-RPC，本機 managed agent 有 Stop current turn，owner 也可用 !cancel 中止當前 turn；新訊息可觸發 steer，不支援原生 steer 時會走 cancel＋merge fallback。產物則是訊息、diff／patch、上傳檔案、canvas 與 workflow output，不應誇成成熟的通用 artifact registry。
Buzz 目前最大的缺口：Approval 看得到，不代表流程真的接得回去
這是原始碼檢查最重要的發現。Buzz 的 review approval 事件與 UI 已存在，但 workflow architecture 顯示 request_approval 目前會產生 suspended token；接著 finalize_run 會把 run 標為 Failed，因為 token 持久化、事件發送與恢復尚未端到端接通。資料庫 CRUD 與 resume handler 已有 scaffolding，官方 README 仍把 approval gates 列在「being wired up」。此外，ACP harness 收到工具 permission request 時會自動選 allow_once，buzz-acp 的 CLI 設定預設則是 bypass-permissions。所以現階段仍要靠 runtime 的權限模式、隔離環境、獨立身分與最小頻道範圍守住安全邊界。
MarbleOS 官方 Demo 核對：任務卡與產物更直覺，但控制深度仍待驗證
MarbleOS 與 Buzz 是兩個不同產品。MarbleOS 是 macOS／Windows 桌面 beta；HN 作者介紹把主要對象定為已使用 ChatGPT／Claude、但尚未採用 Agent 工作流的人，官方 Learn 案例則偏一般知識工作。官方 demo 把每份委派工作變成畫布上的 task card；右側固定放 Tools 與 Files，底部保留文字／語音入口。卡片仍可追加 follow-up，並不是完全消滅聊天。
從示範可直接觀察到三個好處。第一，任務狀態不必埋在長 transcript；第二，執行前能看到預計使用的工具；第三，試算表、投影片與圖片可直接成為畫布上的產物。這降低了一般工作者採用 Agent workflow 的介面門檻，也比純聊天更容易回答「我剛才拿到哪份檔案」。
但要把可見度和控制力分開。官方資料尚不足以確認逐項 tool approval、完整 tool-call trace、token／成本、全域停止、實際平行上限、模型供應商、任務資料保存位置與 artifact 是否能在 workspace 內局部編輯。執行前顯示「會用哪些工具」，不等於每一步都有 permission gate；三張卡同時轉圈，也不等於三個模型工作真的完全重疊。
MarbleOS 隱私政策說匿名 crash report 與基本 feature metrics 不含檔案內容；政策列出的 Supabase、Google Cloud Storage、Vercel 分別用於候補名單／帳號、安裝檔與網站，但未說明模型供應商或 task content 的處理路徑與保存期。因此不能從「可開本機資料夾」推導為 local-only。截至 2026 年 8 月 3 日，官網、demo、公開 changelog 與官方 GitHub 也未提供 app 原始碼或自架指引，所以本文不把 MarbleOS 列為開源或可自架。
Buzz vs MarbleOS：看起來都叫 Workspace，解的其實是不同問題
- Buzz：核心是團隊頻道、Agent 身分、簽名事件、自架 relay 與 ACP runtime。適合願意維運、重視協作紀錄與協定可攜性的技術團隊。
- MarbleOS：核心是一般知識工作的 task card、工具面板與可直接使用的產物。適合已使用聊天 AI、希望把多件工作攤在畫布上的使用者。
- 兩者都還在快速迭代：Buzz 的 approval／job board 尚有未完成區域；MarbleOS 的公開 beta 與文件版本也不同步。現在選擇的是方向與工作單位，不是已證明的企業成熟度。
資料主權也不是二選一。Buzz 以 Apache-2.0、自架 relay 與可攜身分降低單一 SaaS 平台鎖定，代價是基礎設施與私鑰管理；而且身分可攜不代表歷史資料會自動搬家。MarbleOS 降低前端操作成本，卻仍需等待更完整的資料流與商業條款說明。最實際的問題不是「哪家最安全」，而是誰保管資料、誰能執行工具、退出時能帶走什麼、你願意維運什麼。
用同一任務比較 Chat 與 Agent Workspace，才不會被漂亮 Demo 騙
建議固定同一個 repo commit，要求完成一份 release-readiness package：同時做安全掃描、失敗測試診斷、文件漂移檢查與測試缺口檢查；彙整後先等一次人工核准，只修一項，再跑固定測試並交付 diff 與報告。途中刻意補一條更正規格，測量停止與接管。
- 傳統 Chat UI：開四個獨立 thread，使用相同的四個 worker 與 harness；人工負責命名、切換、合併結果與找出阻塞。
- Workspace UI：把同樣四個 worker 放進四個工作單位，再由主 session 彙整；模型、權限、網路、harness 與最大並行數保持相同。
- 記錄：操作次數、user turns、核准次數、context switch、第一份可用產物時間、總時間、阻塞發現時間、takeover latency、衝突／重工、最終正確率與可追溯證據。
至少跑三次、交錯順序，報 median 與 range；安裝、供應商設定與日常維運另外計算。若無法固定 worker、harness、模型或並行數，就老實改稱「單線 Chat 工作流 vs 多 Agent Workspace 整體系統」，不能把結果歸因於 GUI。平行化只對可獨立工作有利；若四個 Agent 同時寫同一個檔案，Workspace 可能比單線工作更慢。
Agent Workspace 怎麼選？從工作單位與接管方式決定
- 先問是否真的有多任務：只有一件短任務時，可先從 Chat 試起。
- 再問人要在哪裡接管：要逐行改碼就選 IDE；要重跑、組合與自動化就保留 CLI。
- 產物是不是工作中心：報告、投影片與試算表比 transcript 重要時，選 artifact-first 的 Cowork／畫布。
- 是否需要團隊與長時間總覽：跨 session 的狀態、阻塞、權限與產物才是 Workspace 的購買理由。
- 最後查資料與退出路徑：本機執行不等於資料不離機；自架也不等於免維運。把模型 provider、log、備份、匯出與金鑰逐項寫清楚。
若你還在 Claude／Claude Code／Cowork 之間猶豫，可看〈Claude、Claude Code、Claude Cowork 怎麼選〉；若主要在比較 coding agent，可接著讀〈Claude Code vs Codex〉。想看更接近成果工作空間的介面，也可參考〈ChatGPT Work 完整教學〉。
Agent Workspace 常見問題 FAQ
1. Agent Workspace 是正式的產業標準嗎？
不是。本文用它統稱多任務 Agent 的持久控制面；各產品實際使用 chat、session、task、subagent、worktree、channel 或 goal 等不同名詞。
2. 有 Agent Workspace 就不需要 Chat 或 CLI 嗎？
不需要二選一。Chat 適合澄清，CLI 適合命令與重現，IDE 適合精準接管，Workspace 適合看全局；它們往往是同一工作流的不同入口。
3. Buzz 已經有完整任務卡與人工 approval 嗎？
還不能這樣說。目前可用核心是頻道／thread、activity、ACP runtime、diff、檔案與 workflow trace；job event 仍未由 ACP 正式發出，workflow approval 的恢復流程也尚未接完。
4. Buzz 可以連 Codex、Claude Code 和 Goose 嗎？
可以，官方目前把三者列為一級 runtime。它們透過 ACP adapter 連線；照 buzz-acp README 的手動啟動範例會設定相應 API key，Buzz Desktop managed runtime 另支援既有 CLI login，認證方式依路徑而異。每個 Agent 仍需要自己的 Nostr 身分。
5. MarbleOS 是 Buzz 的圖形介面嗎？
不是。它們是不同產品。截至 2026 年 8 月 3 日，MarbleOS 官網、demo、公開 changelog 與官方 GitHub 未提供 Buzz、Codex、Claude Code 或 Goose 的整合文件；MarbleOS 目前更偏一般知識工作的任務卡與產物畫布。
6. 自架 Buzz 就代表資料完全不會外流嗎？
不一定。relay、事件與檔案可以由你營運，但 Agent 仍可能把完成推論所需的 prompt、程式碼或 context 送給所選模型 provider。要分別檢查儲存層與推論層。
7. 看得到 Running、Trace 與 Cost，就代表系統可控嗎？
不代表。狀態、trace、可重現性與帳單是四件事；成本也可能只是估值。還要實測停止是否生效、權限是否最小化、產物能否人工接手。
8. 新手現在該不該換到 Agent Workspace？
可以先把「同時管理三件以上、會持續數十分鐘以上」當成試用門檻。這是本文的實務 heuristic，不是通用規格；若主要是一問一答或單一短任務，先把完成條件與權限寫清楚，通常比換介面更有效。
給新手的 7 個重點
- Agent Workspace 是本文的分析框架，不是統一標準。
- Chat、CLI、IDE、Cowork、Workspace 是互補鏡頭。
- 任務卡不等於控制面；要連狀態、產物、權限、trace、成本、停止與接管一起看。
- Buzz 現階段是頻道與簽名事件導向，MarbleOS 是任務卡與產物畫布導向。
- 平行只會加速彼此獨立的工作，共用寫入反而可能造成衝突。
- 自架不等於資料永不離機，本機資料夾也不等於 local-only。
- 最好的選擇不是功能最多，而是人能最快看懂、驗證、停止並接手。
📚 延伸閱讀
- 先補執行層：〈AI Agent Harness 是什麼？〉
- 學會看 trace：〈Agent Observability 完整教學〉
- 釐清 Claude 介面：〈Claude、Claude Code、Claude Cowork 怎麼選〉
- 看成果工作空間：〈ChatGPT Work 完整教學〉
結語：先做一場三任務演習，再決定要不要換控制台
別先搬家。挑一個真實工作，拆成三個可獨立任務，替每個任務寫下完成證據、允許工具與停止條件；先用現在的 Chat／CLI 跑一遍，再用候選 Workspace 跑一遍。記錄你花多少時間找狀態、找產物、核准、停止與接管。當管理工作的成本開始高過 Agent 真正替你完成工作的時間，Agent Workspace 才是解藥。
一句話收尾：Agent Workspace 不是讓 AI 看起來更忙，而是讓人始終知道工作在哪裡、風險在哪裡，以及何時該把方向盤拿回來。想把這套觀念延伸成可落地的工作流，也可從 AlphaLab 的〈Claude 省 token 實戰〉與AI 課程專區繼續練習。