如果你的 agent 還停在本機 terminal，Flue 的重點可能只是「更好開發」。一旦你想把 agent 放進 Slack、GitHub、Linear 或背景任務裡，問題會立刻變成：模型呼叫中斷怎麼辦？工具執行要跑在哪裡？檔案狀態如何保存？人類批准與重試要怎麼接回同一個任務？
Cloudflare 2026 年 6 月 17 日的更新，把這些問題拆成更清楚的三層：代理框架（agent framework）、代理控制層（agent harness）與執行平台（runtime/platform）。Flue 1.0 Beta 是框架層，Pi 或 Project Think 這類 harness 管代理迴圈，Cloudflare Agents SDK 則提供持久執行、狀態、儲存、沙盒與工作流。
這篇原本追蹤 Cloudflare Agents SDK v0.12.4 的聊天恢復（chat recovery）與 Durable Think。現在更適合把它當成「Cloudflare agent runtime 上線檢查」來看：Flue 讓開發者更快包裝 agent，但真正影響 production 成敗的是恢復能力、沙盒邊界、工具權限與成本治理。
如果你還在整理 Cloudflare AI Platform 的整體定位，可以先看站內的 Cloudflare AI Platform 推論效率與成本治理。這篇聚焦 Flue 與 Agents SDK 對 agent 開發者的直接影響。
先回答：Flue 和 Agents SDK 這次改了什麼？
Cloudflare 這次把 agent starter 的討論往下推到平台層。官方公告的核心是：Agents SDK 要成為任何 agent harness 或 agent framework 可共用的底層平台，Flue 是第一個明確站上這層平台的開源框架。
| 層級 | 代表 | 負責解決的問題 |
|---|---|---|
| 代理框架（agent framework） | Flue | 專案結構、CLI、整合通路、React hooks、開發者體驗。 |
| 代理控制層（agent harness） | Pi、Project Think | 代理迴圈、工具呼叫、上下文管理、任務持續執行。 |
| 執行平台（runtime/platform） | Cloudflare Agents SDK | Durable Object、持久執行、沙盒程式執行、檔案狀態、Workflow、綁定外部能力。 |
對開發團隊來說，這個分層比「Cloudflare 又推了一個 agent 工具」更重要。你可以用 Flue 取得框架與整合體驗，也可以自己做 harness，但只要 agent 要跑在雲端，就要回答同一批平台問題：狀態、恢復、隔離、觀測、成本與權限。
Flue 適合解決什麼？
Flue 1.0 Beta 採用宣告式模型。你描述 agent 需要的模型、技能、沙盒與指令，讓 harness 去處理任務，而不是自己手寫一整套 orchestration loop。官方範例把 bug triage agent 壓到很短的設定與程式碼：攔截 bug report、在 sandbox 重現、診斷問題，再回到使用者所在的通路。
它的實用價值主要在三個地方：
- 通路整合：官方提到 Slack、GitHub、Linear、Discord 等 Channels，可處理事件驗證與 dispatch 樣板。
- 前端可見性：
@flue/react提供 hooks，把 agent 狀態、工具執行與即時訊息串進前端，不必從零做 realtime plumbing。 - 生態整合：例如
flue add channel slack這類命令會產生 Markdown blueprint，讓團隊或 coding agent 能接著修改與整合。
如果你的需求只是一次性批次腳本，Flue 可能太重。若你的 agent 要常駐在使用者工作流裡，或要同時支援背景任務與 UI 顯示，Flue 的框架層價值會更明顯。
真正要測的是 durable runtime
Agent 上線後最常見的失敗，不一定來自模型答錯，而是流程在半路消失。使用者關掉頁面、LLM provider timeout、部署重啟、工具呼叫卡住、等待人類批准，任何一件事都可能讓 agent 忘記自己做到哪裡。
Cloudflare 在 Agents SDK 裡主打的持久執行（durable execution）正是為了這種場景。官方公告說，Flue 在 Cloudflare target 上會把每個 agent 放進自己的 Durable Object，並使用 runFiber()、stash()、onFiberRecovered() 來 checkpoint 與恢復任務。這讓 harness 可以在新的 agent instance 啟動後知道：哪個任務中斷、上一個 checkpoint 在哪裡、接下來該重跑、接續或要求人工介入。
這也呼應 Cloudflare 5 月的 Agents SDK v0.12.4 更新紀錄。當時官方已經把聊天恢復（chat recovery）、durable Think submissions、語音連線控制（Voice connection control）與路由重試（routing retry）放進 SDK。6 月的 Flue 更新，等於把同一組能力推到更高層的框架與 harness 生態。
沙盒與檔案狀態：不要讓工具清單越長越難控
很多 agent demo 會把外部能力做成大量 tools。工具越多，模型越容易選錯，也越難控權限。Cloudflare 這次的說法是：在許多情境下，讓模型寫一段 TypeScript function，由受控 sandbox 執行，會比塞一長串 tool definitions 更容易管理。
Cloudflare 公告提到 @cloudflare/codemode 會透過 Dynamic Workers 執行 LLM 產生的程式碼，只提供你允許的 bindings。官方同時宣稱 isolate 啟動低於 10ms，並在公告中給出每次 load 的成本描述；這類成本數字需要以 Cloudflare 最新方案與帳務頁為準，本文只把它當成架構選項的訊號。
檔案狀態則由 @cloudflare/shell 補上。對 code review、文件整理、搜尋、diff、patch 這類任務，agent 多半需要讀寫文字檔，不一定每次都要啟動完整 Linux container。Cloudflare 的方向是先用 Durable Object 裡的虛擬檔案系統處理輕量 workspace；真的需要 npm install、git、compiler 或完整 OS 時，再接 Cloudflare Containers。
這個取捨對台灣或中小型團隊很實際：先確認你的 agent 工作是不是大量文字與 API 操作，再決定是否真的要為每一步工具呼叫付出 container 成本與啟動延遲。
Dynamic Workflows 適合哪種任務？
單次工具執行解決不了所有問題。當 agent 要把 code review、資料清理、研究流程或客戶工單處理變成可重複的長流程，就需要工作流引擎保存每一步、重試失敗、等待外部事件或人類批准。
Cloudflare 在公告中提到 @cloudflare/dynamic-workflows 與 runWorkflow()：agent 可以在 runtime 產生 workflow，交給 Workflows engine 持久執行；workflow 再用 RPC 回報進度、更新 state 或請求批准。這對「每天跑、會睡眠、會等待、要可追蹤」的 agent 比較有價值。
不過，dynamic workflow 也會提高治理難度。團隊至少要限制三件事：
- agent 可以產生哪些 workflow；
- workflow 能使用哪些資料與 bindings；
- 失敗、重試、人工批准與取消是否都有 audit trail。
如果沒有這些邊界，長任務 agent 會從「省人力」變成「看不懂它為什麼一直跑」。
實務判斷：先測恢復，再談大規模導入
Flue 讓 agent framework 看起來更接近一般 app framework，但導入順序不該從通路數量開始。更安全的做法，是先挑一個低風險流程，把 runtime 可靠性測完。
建議用這張檢查表做第一輪評估：
- 恢復：使用者關頁、部署重啟、provider timeout 後，任務能否接續或清楚失敗？
- 狀態：對話、工具結果、檔案變更、人工批准記錄存在同一個可追蹤邊界內嗎？
- 沙盒：LLM 產生的程式碼只能碰到被允許的 bindings 嗎？有沒有 secrets 外洩風險？
- 檔案系統：文字 workspace 用 Durable Object 內的虛擬檔案系統即可，還是需要完整 container？
- 成本：AI Gateway、模型供應商（model provider）、Dynamic Workers、Containers 的支出能不能按 agent 或任務設上限？
- 觀測：你看得到每一步 tool call、workflow step、latency、retry 與人類批准嗎？
- 退出機制：任務跑錯時，使用者或管理員能否取消、回滾或交給人處理？
如果這些問題還答不出來，先別把 Flue 接到高權限 GitHub repo、客戶資料或付款流程。可以從 Slack triage、內部文件整理、低敏感 issue 分流開始；若要盤點更完整的組織條件，再對照 Cloudflare Agent Readiness 五層檢查。
和其他 agent 平台怎麼比較？
Cloudflare 這次更新的差異化不在模型能力，而在平台原語。OpenAI Agents SDK、Vercel 的 durable AI workflow、各家雲端 agent platform 都在處理相似問題：工具怎麼執行、狀態怎麼保存、長任務怎麼恢復、沙盒與成本怎麼控。
Cloudflare 的優勢是 Workers、Durable Objects、Workflows、AI Gateway、Browser Rendering、Email Service、Containers 等能力原本就在同一個開發平台（developer platform）裡。若你的團隊已經在 Cloudflare 上跑 Workers 或 AI Gateway，Flue/Agents SDK 的導入成本會低一些。若你的 agent 需要重度本機建置（build）、複雜作業系統相依或大型資料處理，仍要評估 Containers、其他雲端執行環境，或專門的 coding agent sandbox。
延伸閱讀可以看 OpenAI Agents SDK sandbox 的安全邊界 與 Vercel durable AI code agent workflow，用同一組問題比較不同平台的狀態、沙盒與工作流設計。
來源與仍需追蹤的限制
本文主要採信 Cloudflare 2026-06-17 官方公告、Cloudflare Agents 文件、Cloudflare 2026-05-13 Agents SDK v0.12.4 更新紀錄、Flue 官網、npm 套件後設資料與 withastro/flue GitHub repo 後設資料。
截至 2026-06-18 查閱時，@flue/runtime 與 @flue/react 的 npm latest 版本為 1.0.0-beta.1，授權為 Apache-2.0，repository 指向 withastro/flue。Beta 版本代表 API、整合方式與文件仍可能調整；導入前要看最新 release notes，不要只照本文日期的狀態實作。
重點整理
Cloudflare Agents SDK 與 Flue 的組合，適合用來判斷 agent 能不能離開 demo：框架層負責讓開發變快，harness 層負責代理迴圈，runtime 層負責中斷恢復、沙盒、檔案狀態、工作流與平台 bindings。
短期最值得做的事，是選一個低風險流程跑完整測試：讓任務中斷、重啟、重試、等待批准、執行程式碼、讀寫檔案，再確認成本與觀測資料能不能被管理。這比急著把 agent 放進所有通路更能降低上線風險。