開發者用的代理框架仍處於早期階段，Vercel 的 eve 和 Fred Schott 的 Flue 都是今年推出的早期範本。

Schott 是網頁框架 Astro 的創辦人，他的公司在今年一月被 Cloudflare 收購。他剛發布了 Flue 的 2.0 版本，這是其首個穩定版，其基礎是 React 風格的「Agent Hooks」。

在 Flue 中，一個代理被表示為一個 JavaScript 函數。這個函數「在每個回合都會重新渲染」，這意味著在每次模型呼叫之前都會重新渲染。

Hooks 的加入是在 Schott 意識到 React 的可組合性非常適合代理開發之後。「我最初發推文說我們正在為代理建構 Astro 或 Next.js」他告訴我們。「但後來我意識到：也許還沒有人為代理建構 React。」

編者按：我們上次與 Sierra 執行長兼 OpenAI 董事長 Bret Taylor 討論「代理的 React」時，他說：「我們仍在努力弄清楚反應式代理是什麼，目前還沒有定論……我們正處於代理的 jQuery 時代，而不是 React 時代。」

Hooks 是用 TypeScript 編寫的。根據 Flue 2 的發布文章，它們「讓您能夠建構動態代理，這些代理可以管理自己的狀態、監聽代理生命週期事件，甚至在執行時動態附加不同的資源和能力來增強自身。」

Flue 2 中有 16 個內建 Hooks，包括 useSkill()、useTool()、useSubagent()。您也可以添加自訂 Hooks。

Hooks 為開發者開啟了新的可能性，它們讓代理變得更加動態，允許其配置隨著對話或工作流程的進展而改變。Schott 表示，這是建構「真正的支援機器人、真正的分流機器人」所必需的，因為它們無法預先完全配置。代理不能只是靜態的，它必須即時適應使用者的需求或情況。

代理 Hooks 為 Flue 帶來了這些能力。例如，一個支援代理在首次驗證使用者後，可能會引入一個帳戶管理工具。

自從 Schott 在五月初公開推出 Flue 1 以來，他對如何建構代理框架的思考迅速演變。最初，他想將現有的網頁框架概念應用到他的新代理框架中。他以基於檔案的路由為例。

「所以我們有點天真地將其移植到 Flue，認為，太好了，我會把你的五個代理放在這五個檔案中，這將是它們公開的五個路由。但對於許多使用 Flue 建構的人，尤其是較大的客戶，他們的整個公司就是一個代理。他們不關心路由。只有一個代理。」

因此，在第一批 Flue 使用者展示了這些早期模式後，可組合性成為 Schott 最關心的問題。這讓他回到了 React。「正如您從 Flue 2 API 中所看到的，我們更多地從 React 中汲取靈感，而不是 Astro 或 Next.js，它更少關於路由和這些網站概念，而更多關於，在其基本層面，如何將代理組合在許多不同的事物上？」

Flue 中的一個關鍵概念是代理必須有一個代理環境（harness），這意味著它處於一個可以存取完成各種任務所需的上下文和能力的環境中。「與其讓您和您的程式碼驅動 LLM 並用腳本告訴它該做什麼，不如將代理放入這個代理環境中，它就能夠自行驅動並解決問題。」Schott 解釋道。

Flue 是建立在 Pi 之上的，Pi 是一個開源的極簡代理環境。本質上，Flue 是 Pi 的一個有主見的版本，增加了 Schott 認為對建構代理的開發者有幫助的功能。例如：Flue 2 中的託管代理現在是使用 Vite（一個開源建構工具）建構的。

事實上，Schott 將 Pi 的角色比作 Vite 現在在 Astro 之下所扮演的基礎角色。「我認為 Pi 可以扮演這個角色，它是一個正確的抽象層，它做得不多，但它提供了正確的 API，然後我們可以說，讓我們對此有一個有主見的看法，做更多的事情。」

建構在 Pi 之上意味著承諾擁有一個內建的代理環境。「我們早期的賭注是，代理環境實際上不是一個功能，而是你認為代理是什麼的基礎」Schott 說。「沒有代理環境就沒有代理。」

Flue 專案於今年早些時候在 Astro 儲存庫中開始，作為一個問題分類系統。起初，它是一個由 LLM 驅動的腳本或工作流程來審查問題。但後來，Schott 解釋說，它獲得了在儲存庫中採取行動的能力。

「它開始從儲存庫中的自動化轉變為希望獲得 Claude Code 的體驗，使其無頭化、可託管並在雲端運行。」這就是代理環境作為錨點的想法出現的時候。事實上，在他五月初的 v1 發布文章中，Schott 將 Flue 描述為「就像 Claude Code，但 100% 無頭和可程式化。」

我自己使用 Claude Code 測試了 Flue，它引導我設定了我的第一個 Flue 代理。Schott 證實許多開發者都是這樣使用 Flue 的。「我們非常為他們建構」他談到 AI 編碼代理時說。「我們的整個入門流程就是，你知道，將這個提示詞傳遞給你的代理，它會引導你完成。我們所有的文件都支援 Markdown。」

與 Flue 最接近的比較是 Vercel 的 eve，它也將代理環境視為基礎。Vercel 和 Cloudflare 以公開競爭而聞名，但 Schott 對 eve 的評價卻很慷慨。「Eve，我認為，是最直接的競爭對手」Schott 說。「它大約在同一時間出現，所以它也有內建代理環境的相同觀點。」

Schott 還提到了他所謂的「OG 代理框架」，這些框架在 Flue 之前出現，因此沒有將代理環境作為核心概念。他列舉了 Vercel 的 AI SDK、Cloudflare 的 Agents SDK 和 Mastra（由建構 Gatsby 的同一團隊開發，Gatsby 是一個早於 Astro 的網頁框架）。

雖然這些「OG 代理框架」現在都在添加代理環境，但 Schott 認為這是一個附加功能，而 Flue 和 eve 都擁有內建代理環境。我問 Flue 與新興的「元代理環境」（meta-harnesses），如 Databricks 的 Omnigent，甚至可能是自我改進的 Exo 代理環境相比，處於什麼位置。

注意：我們本週末也將發布對 Exo 共同作者 Alex Krentsel 的採訪；值得一看，並有關於 OpenClaw 架構的額外討論！

Schott 正確地指出，在這個早期階段，對於「元代理環境」這個術語的含義存在混淆。無論如何，他認為擁有一套 API 來跨所有代理環境工作會讓 Flue 的故事變得混亂。他的框架明確定義了技能在 Flue 中如何運作，子代理如何運作等等。正如他所說，「框架 [Flue] 和代理環境是高度交織的。」

他個人覺得元代理環境的討論很有趣，也玩過 Exo，但他說這是一個「與託管代理無關的不同興趣場景」。在整個採訪中，Schott 提到了能夠利用他的雇主 Cloudflare 的工具和基礎設施。但他也非常清楚，Flue 是一個「適用於每個主機的開源框架」，正如他所說，他希望它保持這種狀態。

「最好的工具是那些漂浮在主機之上的工具」他說。「這為最多的開發者採用和最多的創新打開了大門。」主機可移植性是 Flue 的一個決定性原則，這也許是與 Vercel 的 eve 的根本區別。雖然 eve 也可以自我託管，但它經過優化以利用 Vercel 的許多功能。當然，這是 Vercel 的已知策略，它對 Next.js 也採取同樣的做法。

儘管如此，Vercel 自己已經表明 Flue 代理可以部署在 Vercel 上。所以這兩家公司可以好好合作。我還提到了 LangChain 新推出的 Managed Deep Agents 服務，作為市場上出現的託管代理平台的一個例子。然而，Schott 表示，託管代理產品目前不在 Flue 的發展藍圖上。

「對我們來說還很早，我們只是專注於建構最好的代理環境」他說。線上尋找 Flue 和 Fred 的連結；Richard 在 @ricmac。這是我們為訂閱者嘗試的新書面採訪系列，請告訴我們您的回饋！