010. 導言｜Flue 想補上的，不是 another SDK
這支 Better Stack 的影片介紹的是 Flue：一個由 Astro 團隊推出的開源 TypeScript agent framework。影片字幕把名字辨識成「Flu」，但官方網站與 GitHub repo 都寫作 Flue；本文也依官方名稱校正。來源影片在這裡：Finally, a Programmable AI Agent Framework That Works。
Flue 有趣的地方，不在於它又把 LLM call 包成一層漂亮 API。今天 agent framework 太多了，從 LangChain、Mastra、Vercel AI SDK，到各家雲端平台的 agent runtime，每個都能讓模型呼叫工具、串流程、回傳結構化結果。真正值得注意的是 Flue 選的切入點：它把「Claude Code 這類 coding agent 背後那層 harness」抽出來，變成可以用 TypeScript 宣告、執行、部署的框架。
換句話說，Flue 不是先問：「我要怎麼呼叫模型？」它先問：「如果一個 agent 要真的做事，它外面應該有哪些環境？」
這個問題的答案，會包含 session、tools、skills、sandbox、file access、deployment、workflow trigger、observability、以及和人類互動或完全自動化之間的差異。模型本身只是一部分，harness 才是讓模型能夠穩定工作的那一層。
影片用 Claude Code 當對照很直覺。你在 Claude Code 裡看到的是 terminal 或 chat UI，但真正讓它能改檔案、讀規則、呼叫工具、隔離風險的，是底下那組 harness：它會讀 CLAUDE.md 或類似規則檔、載入 skills、接 MCP tools、有 sandbox，也維持對話狀態。Flue 的主張是：這些能力不應該只存在於一個互動式產品裡，而應該可以被程式化、被部署、被接到自動化流程裡。
這就是它和「再做一個 SDK」的差別。
021. 來源故事｜從 Astro repo 裡長出來的工具
Flue 不是一開始就作為通用框架設計。影片提到，Fred Schott 和 Astro 團隊原本只是要在 Astro 自己的 GitHub repo 裡執行 AI workflows。也就是說，它一開始比較像內部工具：讓 agent 能在真實 codebase、真實 CI、真實任務裡工作。
後來，Amplitude 的工程師拿到這套東西使用，Astro 團隊才意識到：這不是只有 Astro 自己需要。任何想讓 agent 做真事的人，都會遇到類似問題。
這個出身很重要，因為它解釋了 Flue 的產品氣質。它不是從 chatbot demo 開始往外長，而是從「agent 要進 repo 做事」開始往下挖。這會自然導向幾個問題：
第一，agent 要如何取得指令和上下文？只丟一段 prompt 不夠，因為真實專案有規則、慣例、工具和可重用技能。
第二，agent 要如何取得工具？如果只有模型 API，它只能說話；要做事，就需要 file read、grep、glob、MCP tools、自訂工具，甚至執行 script。
第三，agent 要如何被隔離？如果它能碰本機檔案與命令，就必須有 sandbox 與權限邊界。
第四，agent 要如何被部署？互動式 terminal 很好用，但許多任務不需要人一直坐在旁邊按 Enter，它們應該可以被 HTTP、CI、排程或 webhook 觸發。
Flue 的回答，是把這些東西一起包進 harness，而不是要求開發者從一堆零件慢慢手接。
032. Harness-first｜真正的差異在環境，不在模型呼叫
影片中講者說，Flue 建立在 Pi 這個最小化 agent harness 上，並在 Pi 的 agent core 外面包出一個真正的 framework。這裡的重點不是底層是哪個 library，而是它採取的抽象層級。
一般 AI SDK 的起點通常是 model call：給 prompt、收 response、串 tool calling、補上 streaming 和 schema。這對很多 app 已經夠用，尤其是客服、內容生成、簡單任務路由。但如果目標是「讓 agent 像 Claude Code 一樣在工作環境裡行動」，model call 只是其中一格。
Flue 的 framing 是 harness-first。也就是說，它預設 agent 需要一整套工作環境：session 管理、skills、tools、sandbox、部署 target、workflow entrypoint。這也是它和 Mastra 或 Vercel AI SDK 這類工具看起來相似、實際重心不同的地方。
講者提到他上次使用 Mastra 時，仍需要手動設定 sessions、memory、sandbox 和 tool loading；那是一個比較 granular、step-by-step 的過程。他也很小心地補了一句：不確定 Mastra 現在是否已經簡化。這個保留很重要，因為 agent framework 變化很快，拿某一次使用經驗當永久定論並不公平。
比較穩的說法是：Flue 想把這些能力前置成預設假設，而不是讓開發者需要時再一個個補。
這種設計會讓它更適合兩種場景。
第一種，是互動式但要可程式化的 agent。你仍然可以做類似 Claude Code 的東西，有人類輸入、有回合、有 session，但整個 agent 是 TypeScript 專案的一部分，可以部署、版本化、測試。
第二種，是不需要人一直介入的 workflow。像影片示範的 YouTube title generator：給一份 script path，workflow 開 session、讀檔、呼叫 skill、產生結果。這不是「和 AI 聊天」，而是「把 AI 放進一個可觸發流程」。
043. Demo 拆解｜從 hello-world agent 到 workflow
影片的 demo 分兩段。第一段是最小 agent，第二段是有 skill 的 workflow。
最小 agent 的流程很短：安裝 @flue/runtime 和 Flue CLI，設定 provider API key，執行 flue init 選 target，然後在 agents 目錄裡寫一個 agent。這個 agent 設定 model，加上一段 instructions，等於把內容 append 到 system prompt。接著用 flue connect 執行，指定 agent 名稱和 instance ID。
instance ID 在本機 demo 裡看起來像小細節，但部署到 Cloudflare 時會變重要。影片提到，Cloudflare target 會把 agent 對應到 Durable Object instance；也就是說，每個 ID 可以有自己的持久化狀態。這讓 agent 不只是一次性函式，而能變成帶狀態的長期單位。
Node target 則走 Hono 上的 HTTP server；Cloudflare target 走 Worker 和 Durable Object。這裡可以看出 Flue 的部署觀：同一套 agent/workflow 宣告，應該能面向不同 runtime package，而不是把 agent 綁死在單一平台。
第二段 demo 比較關鍵。講者建立一個 workflow，用來讀取這支影片的 script，產生 10 個 clickbait YouTube titles，並用一個 title score skill 排分。這裡不再 export agent，而是 export run()。run() 初始化 agent，開啟 harness session，從 JSON payload 拿 path，讀取檔案，把內容傳給 agent，再要求它呼叫 skill 排名。
這段示範凸顯了 agent workflow 的兩個面向。
一個是型別化。payload 的 path 是由 context type 定義，改錯名稱會有 type error。這讓 workflow 比單純 prompt orchestration 更像應用程式碼。
另一個是權限邊界。Flue 預設把 agent 放在 sandbox 裡，只讓它看到已註冊的 skill description。這很安全，但也意味著它看不到 skill 相關檔案本身。影片裡的 skill 需要用 bash 執行 Python script 來算 VidIQ-style score，所以第一次執行時，agent 只能知道「有這個 skill」，卻找不到檔案。
解法有兩種。第一種是匯入 local from @flue/runtime/node，讓 agent 在本機系統上跑，並把 working directory 指到 skill 目錄。這樣它就能讀 SKILL.md、跑 Python script。第二種更保守：把 Python file 包成 custom tool，用 Valibot 驗證參數，再把 tool 註冊給 agent。這樣 agent 不需要直接碰本機檔案，也能取得同樣能力。
這個細節很值得注意。許多 agent demo 會把「能跑工具」講得像魔法，但實務上真正難的是：你要給 agent 多少權限？工具的輸入怎麼驗證？檔案在哪裡？失敗時怎麼 debug？Flue 的 demo 至少把這個邊界攤開來講，而不是把它藏在 happy path 裡。
054. 部署與觸發｜從 terminal 到 HTTP POST
如果 Flue 只是在 terminal 裡跑 agent，它和 Claude Code 的差異不會那麼大。真正讓它變成 framework 的，是它能把 workflows 包進 server。
影片示範加入 root middleware 後，build Flue project，指定 target 和 optional port，再執行產出的 server file。server.js 會 inline 專案裡的 agents 和 workflows，所以部署時只需要這個 server file。任何支援 Node.js 的地方都能跑；如果選 Cloudflare，則走 Worker 和 Durable Object 的路徑。
觸發方式也不只 terminal。講者用 curl 對指定 port 發 HTTP POST，選擇 workflow，給 JSON data，取得 workflow ID。接著再查 workflow endpoint，拿到狀態和結果摘要。若需要 streaming，Flue 也支援 WebSocket。
這裡的設計重點，是 agent 從「一次聊天」變成「可觀測、可查詢、可部署的流程」。這對很多工作流來說更合理。例如：
- PR triage：GitHub webhook 觸發，agent 讀 diff、查規則、產生 review summary。
- 內容管線：上傳 script 或 transcript，workflow 自動產生標題、摘要、社群貼文。
- 客服後台：ticket 進來後，agent 先分類、查知識庫、產生草稿，必要時才交給人。
- 安全掃描：定期讀 issue 或 alerts，先做 rule-based filter，再交給 agent 分析。
這些場景都不需要一個人坐在 chat UI 前面逐句輸入。它們需要的是可觸發、可重試、可追蹤的 agent runtime。
也因此，Flue 的價值不只在「寫 agent 比較快」，而在於它把 agent 放回軟體工程熟悉的形狀：檔案、型別、server、endpoint、deployment target、workflow ID。
065. Sandbox 成本｜just-bash 為什麼有意思
影片最後一段最值得工程師注意：Flue 對 sandbox 成本的處理。
每個 agent 預設都有自己的 sandbox。這聽起來安全，但如果每個 sandbox 都是一個真實 Linux container，成本會很快堆上來。每次啟動 container 都要初始化完整環境；當你要跑的是上千個很輕量的 agents，container boot cost 可能比任務本身還重。
Flue 的做法，是用 Vercel 的 just-bash 作為預設 sandbox。just-bash 用 TypeScript 重新實作 bash，因此可以在記憶體裡執行，而不是啟動完整 container。這讓 agent 能使用像 grep、glob、read 這類工具，同時避免每次都付出 container 啟動成本。
講者的說法是：Flue 因此可以用接近零成本跑上千個 agents，只有在真的需要時才 opt into real container。
這個設計的含義，是把 sandbox 分成兩層。
第一層是輕量預設：適合讀檔、搜尋、簡單 bash-like 操作、受限工具調用。它讓大部分 agent 任務有基本隔離，但不把每個任務都推進昂貴容器。
第二層是按需升級：當你真的需要 Python、原生套件、完整 filesystem、network policy 或更強隔離時，再用 real container。這會比較貴，但也比較有能力。
這種分層很合理，因為 agent 任務的資源需求差異極大。有些任務只是讀幾個檔案、整理摘要；有些任務要跑測試、裝依賴、編譯專案。把兩者都丟進同一種 container 模型，不是浪費，就是不夠安全。Flue 的 just-bash 預設，等於先給一個低成本的安全起點，再讓開發者在需要時升級。
這也回到整篇的主題：harness 不只是「多幾個 helper」。它是模型和真實世界之間的執行環境。環境設計得好，agent 才能便宜、安全、可組合地跑起來。
076. 編輯觀點｜Flue 值得看，但不要把 framework 當答案
Flue 的方向是對的：agent 的下一步，不會只停在「更會聊天」或「更會 tool calling」。真正的問題是，我們如何把 agent 放進工程系統裡，讓它可以被版本化、部署、觀測、觸發、限制權限，並在需要時和人協作。
從這個角度看，Flue 的 harness-first framing 很有說服力。它把 Claude Code 這類產品裡已經被驗證過的工程直覺抽出來：模型需要規則、工具、技能、sandbox 和狀態；如果少了這些，agent 只能是漂亮 demo。
但也要保留一點距離。
首先，Flue 還是快速演進中的開源框架。影片裡的 demo 展現概念清楚，但 production adoption 仍要看 API 穩定度、文件、社群、錯誤處理、observability、以及和既有 infra 的整合。官方 GitHub repo 與文件是讀者應該同步參考的來源：withastro/flue、Flue 官方網站。
其次，harness-first 不代表其他 SDK 就沒有價值。對簡單產品功能來說，Vercel AI SDK 這類工具可能更輕、更直接；對複雜 workflow 來說，Mastra、LangGraph、OpenAI Agents SDK、雲端平台 agent runtime 也各有取捨。Flue 的優勢在於它把「coding-agent-style harness」變成主角，但這不等於每個 agent app 都需要這麼重的結構。
最後，agent framework 的難題往往不在框架本身，而在任務邊界。哪些事能自動做？哪些步驟要人 review？工具權限要開多大？失敗如何回滾？資料如何保密？這些問題不會因為換框架就消失。
所以，這支影片最有價值的 takeaway 不是「立刻改用 Flue」，而是更底層的一句話：如果你正在做的不只是聊天機器人，而是能在真實環境裡執行工作的 agent，那你要設計的是 harness，不只是 prompt。
Flue 只是目前把這個問題講得很清楚、也做得很工程化的一個答案。