Cloudflareが2026年6月17日に公開したブログ記事「Bringing more agent harnesses and frameworks to Cloudflare, starting with Flue」を、一次情報をもとに読み解く。
主役は2つある。 1つはCloudflareが整備したCloudflare Agents SDKで、エージェントの土台となるランタイムだ。 もう1つはAstroを作ったチームが公開したオープンソースのエージェントフレームワークFlueで、そのAgents SDKに最初に乗ってきた実装である。
この記事では、Cloudflareが提示した「フレームワーク／ハーネス／ランタイム」の三層スタックという見立てを軸に、Durable ObjectsとFiberによる耐久実行、Code Modeと仮想ファイルシステム、AI Gatewayなどの基盤機能、そして既存のエージェントSDKとの違いまでを、公式ブログとドキュメントの実測情報に沿って整理する。 推測が混じる箇所はその旨を書き、確認できていない料金やリリース時期は断定しない。
AIエージェントの仕組みや代表的フレームワークの全体像から押さえたい方は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 を先に読むと位置づけが掴みやすい。
30秒で理解するCloudflare Agents SDKとFlue
先に要点だけ並べる。
・Cloudflareは「2026年はエージェントのハーネスが本番投入される年」という前提で、ハーネスを支える土台をCloudflare Agents SDKとして整備した
・スタックは三層。フレームワーク（Flue）／ハーネス（Pi、Project Think）／ランタイム（Cloudflare Agents SDK）に分かれる
・FlueはAstroチームのオープンソースフレームワークで、2026年6月16日に1.0 Betaを公開。Piというハーネスの上に構築されている
・Flueの思想は「何をするかを書くのではなく、何を知っているかを書く」。モデル・スキル・サンドボックス・指示を宣言すると、エージェントが自律的にタスクを解く
・Flueはマルチクラウド。Node.jsでは長時間プロセス、Cloudflareでは1エージェントが1つのDurable Objectになる
・Agents SDKはrunFiber()／stash()／onFiberRecovered()による耐久実行、@cloudflare/codemodeによるコード実行、@cloudflare/shellによる仮想ファイルシステムを提供する
- Cloudflareの主張は「ハーネス単体では本番運用の分散システム問題を解けない。状態・保存・計算を持つ基盤が要る」という一点に集約される
- その基盤がAgents SDK。耐久実行・コード実行・仮想ファイルシステム・動的ワークフローを、どのハーネスからも使えるようにした
- Flueはその基盤に対応した最初のフレームワーク。
createAgentでモデル・ツール・スキル・サンドボックスを宣言するだけで動く - 比較の軸は2つに分ける。フレームワーク同士ならFlue対Vercel AI SDK、土台ならAgents SDK対各社ランタイム
Cloudflare Agents PlatformとFlueの関係
Cloudflareの記事は、現在のエージェント開発に新しい三層構造が現れているという見立てから始まる。 公式ブログはこう書く。
「To solve these scaling challenges, there’s a new, three-layer stack that is emerging for building production-grade AI.」 （このスケーリングの課題を解くために、本番品質のAIを作るための新しい三層スタックが現れつつある。） ── Cloudflare Blog, 2026-06-17, https://blog.cloudflare.com/agents-platform-flue-sdk/
三層はそれぞれ次の役割を持つ。
・フレームワーク（Flue）：プロジェクト構造、規約、統合、CLI、エージェントを作るための開発体験
・ハーネス（Pi、Project Think）：ツールを呼び、結果を読み、文脈を管理し、タスクが終わるまで回し続けるエージェントのループ
・ランタイム／プラットフォーム（Cloudflare Agents SDK）：その上のすべてが依存する計算・状態・保存の基盤機能
Cloudflareはこの一番下の層こそが自分たちの担当だと位置づける。
「The Agents SDK is that bottom layer: it makes primitives like durable execution available to any harness and any framework.」 （Agents SDKはその最下層だ。耐久実行のような基盤機能を、どんなハーネスにもどんなフレームワークにも使えるようにする。） ── Cloudflare Blog, 2026-06-17
そしてFlueがそこに最初に乗った、と続ける。
「Flue, our new open-source framework from the team behind Astro, is the first to build on it.」 （Astroチームによる新しいオープンソースフレームワークFlueが、その上に構築する最初の存在だ。） ── Cloudflare Blog, 2026-06-17
ここで用語を整理しておく。
ユーザー指示などで「Flue SDK」と呼ばれることがあるが、Flue自体はフレームワークであり、配布パッケージ名は@flue/runtimeだ。
一方「Agents SDK」はCloudflareが提供するランタイムSDKを指す。
本記事では、フレームワークを指すときは「Flue」、Cloudflareの土台を指すときは「Agents SDK」と書き分ける。
この図がスタックの実体をよく表している。 チャネル（入力経路）とツール（外部能力）に挟まれた中央のAgentクラスが、ハーネスを差し替え可能な部品として持ち、その下にAgents SDKのランタイム機能が並ぶ。
下の図は、三層スタックを簡略化したものだ。
Slack・GitHub・Linear・Discord] subgraph L1[フレームワーク層] F[Flue
規約・統合・CLI・開発体験] end subgraph L2[ハーネス層] H[Pi / Project Think
ツール呼び出しと文脈管理のループ] end subgraph L3[ランタイム層 = Cloudflare Agents SDK] R[Durable Objects・State・Fibers
Code Mode・仮想FS・Workflows] end U --> F --> H --> R R -. 基盤機能を供給 .-> H
Flueの設計思想と何を解決するか
Flueの特徴は、エージェントの作り方そのものにある。 公式ブログはこう説明する。
「you don’t script what your agent does, you describe what it knows.」 （エージェントが何をするかをスクリプトで書くのではなく、何を知っているかを記述する。） ── Cloudflare Blog, 2026-06-17
宣言する内容は、モデル・スキル・サンドボックス・指示の4つだ。
「Define the context an agent needs — its model, skills, sandbox, and instructions — and it solves whatever task you give it, autonomously. There’s no orchestration loop to write.」 （エージェントが必要とする文脈、つまりモデル・スキル・サンドボックス・指示を定義すれば、あとは与えたどんなタスクも自律的に解く。オーケストレーションのループを書く必要はない。） ── Cloudflare Blog, 2026-06-17
この宣言的なモデルが、実コードでどう見えるか。 公式ブログには、バグ報告を受け取ってサンドボックスで再現し、原因を診断するトリアージエージェントを25行未満で書いた例が載っている。
図中のコードを書き起こすと、おおむね次の形になる（出典：上記Cloudflareブログのコード画像）。
import { createAgent } from '@flue/runtime';
import { local } from '@flue/runtime/node';
import triage from '../skills/triage/SKILL.md' with { type: 'skill' };
import verify from '../skills/verify/SKILL.md' with { type: 'skill' };
import { replyToIssue } from '../tools/github.ts';
// Expose (and protect) your agents to the world:
export const route = (c, next) => next();
// Give agents the autonomy to solve complex tasks:
const instructions = `
Triage a bug report end-to-end: reproduce the bug,
diagnose the root cause, verify whether the behavior is
intentional, and attempt a fix.`;
// Compose the context your agent needs to do real work,
// complete with virtual, local, or remote container sandbox.
export default createAgent(() => ({
model: 'anthropic/claude-sonnet-4-6',
tools: [replyToIssue],
skills: [triage, verify],
sandbox: local(),
instructions,
}));
注目したいのは、スキルがSKILL.mdというMarkdownファイルとしてインポートされている点だ。
処理手順をコードで分岐させるのではなく、エージェントに渡す文脈（指示書とスキル）を組み立てる書き方になっている。
sandbox: local()を切り替えれば、同じ定義のまま仮想・ローカル・リモートコンテナのサンドボックスを選べる構造になっている。
Flueはエージェントが孤立しないことも重視している。
公式ブログによれば、Slack・GitHub・Linear・Discordへ、イベント検証やディスパッチの定型処理を肩代わりするChannelsを使って組み込める。
フロントエンド向けには@flue/reactが用意され、エージェントの状態・ツール実行・メッセージをそのまま画面へストリームできる。
統合の追加はflue add channel slackのようなコマンドで行い、自分のコーディングエージェントが読んで取り込めるMarkdownの設計図を生成する、と説明されている。
Flue公式の1.0 Betaアナウンスでは、観測性の拡充、データベースアダプタ（MySQL・Redis・MongoDB・Supabase）、エージェントへの画像入力、npmから取り込めるスキル、オフラインドキュメント用のCLIコマンドなどが追加されたと記されている。
本番運用で壊れない仕組み（Durable Streams）
ローカルの端末から本番環境へエージェントを移すと、分散システム特有の故障が出てくる。 ホストのクラッシュ、LLMプロバイダのAPIタイムアウト、予期しない再起動が、実行中のエージェントターンの短期記憶を消しかねない。
Flueはこれをdurable streamsで解こうとする。
「Flue solves this via Durable Streams. Each event in the execution history is added to an append-only log.」 （Flueはこれをdurable streamsで解く。実行履歴の各イベントが追記専用のログに加えられる。） ── Cloudflare Blog, 2026-06-17
すべてのプロンプト・ツール応答・モデルの選択を、書き換え不能の台帳として処理する。 プロセスが落ちても、別のプロセスがそのログを読み、中断した正確な地点から続けられる、という設計だ。
そのうえで、実行先は1つに縛られない。
「On Node.js, each agent runs as a long-lived process. You can deploy it to any VM or container, run it in GitHub Actions, or embed it on an existing server.」 （Node.jsでは、各エージェントは長時間プロセスとして動く。任意のVMやコンテナにデプロイでき、GitHub Actionsで動かしたり、既存サーバーに組み込んだりできる。） ── Cloudflare Blog, 2026-06-17
そしてCloudflareを実行先にすると、各エージェントがDurable Objectになる。 専用のDurable Objectの中で隔離されたストレージと計算を持ち、サーバーの用意・スティッキーセッションの管理・ノイジーネイバー対策が要らなくなる、と書かれている。
Workers / Durable Objectsとの統合（Fiber）
エージェントのターンは、単一のリクエストでは終わらない。 モデルがトークンをストリームし、ツールを呼び、結果を待ち、ときに人間の承認を求め、サブエージェントへ仕事を委譲する。 この流れは数秒から数分かかり、その途中でプロセスが中断したりクラッシュしたりしうる。 そうなると、メモリ上のエージェント状態（ストリーミング接続、保留中のツール呼び出し、ターンの進行位置）が失われる。 会話履歴はディスクに残っても、ユーザーには終わらないスピナーだけが見える。
CloudflareはこれをFiberという仕組みで解く。
DurableなObjectの中に、チェックポイントの機構を直接持たせる方式だ。
runFiber()がエージェントターンの作業を始める前に進行状況をDurable ObjectのSQLiteストレージへ記録し、ターンが進むたびにstash()でチェックポイントを取る。
中断後に新しいインスタンスが起動すると、onFiberRecovered()が最後のチェックポイントを届け、どこまで進んでいたかをエージェントが知って続行を判断できる。
公式ブログのコード例は次のとおりだ（出典：Cloudflare Blog, 2026-06-17）。
import { Agent } from "agents";
import type { FiberRecoveryContext } from "agents";
class MyAgent extends Agent {
async doWork() {
await this.runFiber("my-task", async (ctx) => {
const step1 = await expensiveOperation();
ctx.stash({ step1 });
const step2 = await anotherExpensiveOperation(step1);
this.setState({ ...this.state, result: step2 });
});
}
async onFiberRecovered(ctx: FiberRecoveryContext) {
if (ctx.name !== "my-task") return;
const { step1 } = (ctx.snapshot ?? {}) as { step1?: unknown };
if (step1) {
const step2 = await anotherExpensiveOperation(step1);
this.setState({ ...this.state, result: step2 });
}
}
}
FlueはこのrunFiber()をCloudflare実行先でそのまま使う。
onFiberRecovered()のフックで、ターンの状態を作り直す方式（Project Thinkが取るやり方）にするか、ターンの一部を再生する方式にするかを、ハーネス側が選べる。
下の図は、Fiberによる中断と復旧の流れを示したものだ。
コード実行と仮想ファイルシステム（Code Modeと@cloudflare/shell）
ハーネスはモデルにツールを与えて外界と接続させる。 しかしツールの面が増えるほど、モデルは正しいツールを選びにくくなり、ツール定義で文脈ウィンドウが埋まっていく。 Cloudflareが挙げる別の手は、コードを実行する1つのツールだけをモデルに渡すやり方だ。 モデルが必要なAPIを呼ぶTypeScript関数を書き、ハーネスがそれを実行する。 この考え方はCloudflareがCode Modeで示してきた。
問題はそのコードをどこで動かすかにある。
LLMが生成したコードを安全に走らせるにはサンドボックスが要るが、ふつうのサンドボックスはツール呼び出しごとに動かすには遅く、コストも高い。
そこでAgents SDKは@cloudflare/codemodeを提供する。
これはDynamic Workersをラップし、与えたバインディングだけを持つWorkerアイソレートの中でLLM生成コードを実行する。
「Isolates start in under 10ms and $0.002 per load, resulting in drastically faster and cheaper cost of execution than booting a container every time your agent needs to execute a short piece of code.」 （アイソレートは10ミリ秒未満で起動し、1ロードあたり0.002ドル。短いコードを実行するたびにコンテナを起動するより、はるかに速く安い実行コストになる。） ── Cloudflare Blog, 2026-06-17
ファイルシステムも同じ発想で軽くする。 コーディングエージェントはファイルの読み書き・grep・diffを多用するが、その大半はテキスト操作だ。 フルのLinuxを起動する必要はない、というのがCloudflareの主張だ。
「@cloudflare/shell gives your agent a durable virtual filesystem inside its Durable Object, backed by SQLite. It provides typed file operations — read, write, edit, search, grep, diff — that agent harnesses can use as tools.」 （@cloudflare/shellは、Durable Objectの中にSQLiteで支えられた耐久仮想ファイルシステムを与える。read・write・edit・search・grep・diffといった型付きファイル操作を、ハーネスがツールとして使える。） ── Cloudflare Blog, 2026-06-17
個別のツールを呼ぶ代わりに、Flueのエージェントはワークスペースの仮想ファイル状態APIに対してJavaScriptを書く。 公式ブログのコード例は次のとおりだ（出典：Cloudflare Blog, 2026-06-17）。
async () => {
const files = await state.glob("src/**/*.ts");
const results = [];
for (const file of files) {
const content = await state.readFile(file);
const todos = content.match(/\/\/ TODO:.*/g);
if (todos) results.push({ file, todos });
}
return results;
}
npm install、git、コンパイラなどフルのOSが要る場合は、Cloudflare Containersがそれを担う。
CloudflareはDurable Objectの仮想ファイルシステムとコンテナを同期させる@cloudflare/workspaceも開発中だとしており、軽量なWorkersから必要なときだけLinux環境へ移れるようにする狙いだと書いている（この機能は開発中の言及であり、提供時期は未確認）。
コンテナとアイソレートのコスト差を、公式ブログは下の図で示している。
エージェントのターン処理がCode Modeと仮想ファイルシステムをどう使うかを、下の図にまとめた。
Dynamic Workerアイソレート] CM --> FS["@cloudflare/shell
仮想FS read/write/grep/diff"] CM --> B[バインディング経由で
外部能力を呼ぶ] FS --> DO[(Durable Object
SQLite)] CM -. 実行後に破棄 .-> X[アイソレート破棄]
動的ワークフローとCloudflareエコシステム連携
エージェントが単発のコード実行を超えて、多段のパイプラインを一貫して繰り返す必要が出てくる場面がある。 バグを確実に直すコードレビューや、良い結果を出すリサーチのワークフローがその例だ。 ハーネス単体ではこの耐久的な多段実行を提供できない、とCloudflareは言う。 各ステップの永続化、失敗時のリトライ、中断後の再開を、プラットフォーム側が担う必要があるからだ。
このパターンの一例として、Cloudflareは他社の動きにも言及する。
「Claude Code recently shipped dynamic workflows, where Claude writes a JavaScript script at runtime to hand off work to dozens of subagents, and the runtime executes it durably.」 （Claude Codeは最近dynamic workflowsを出した。Claudeが実行時にJavaScriptのスクリプトを書いて数十のサブエージェントへ仕事を渡し、ランタイムがそれを耐久的に実行する。） ── Cloudflare Blog, 2026-06-17
Agents SDKでは@cloudflare/dynamic-workflowsがこれをどのハーネスにも提供する。
エージェントが実行時にワークフローを生成すると、Workflowsエンジンが各ステップを永続化し、失敗をリトライし、数時間スリープしたり人間の承認のような外部イベントを待ったりできる。
AgentクラスのrunWorkflow()がエージェントとWorkflowsエンジンをつなぎ、エージェントはワークフローを起動して眠れる。
ワークフローはRPCでエージェントへ進捗報告・状態更新・承認要求をコールバックし、完了するとエージェントが結果とともに目覚める。
計算と保存の外側では、エージェントは外部能力（Web閲覧、メール、メモリ、検索、推論）にアクセスする必要がある。 Agentクラスは、これらをバインディングとしてまとめて提供する。 内訳は、AI Gateway（エージェント単位の支出追跡と上限）、Browser Run（Web自動化）、Email Service（受信箱ワークフロー）、Agent Memory（永続的な想起）、AI Search（検索）、Containers（フルOSが要る処理）、そして14以上のモデルプロバイダにまたがる推論だ。 バインディングの利点は資格情報の扱いにある。
「Bindings grant capabilities without exposing credentials: your agent uses them, but the keys never enter agent-generated code.」 （バインディングは資格情報を露出せずに能力を与える。エージェントはそれを使うが、鍵がエージェント生成コードに入ることはない。） ── Cloudflare Blog, 2026-06-17
LLM生成コードにAPIキーが漏れないという性質は、untrustedなコードを走らせる前提のエージェントでは効いてくる。
既存エージェントSDKとの対比
Flueと既存フレームワーク、そしてAgents SDKと各社ランタイムは、層が違うので素直には並べられない。 それでも選定の見取り図として、力点の違いを表にまとめる。 各製品の細かい仕様は変化が速いため、採用時は必ず各公式ドキュメントで最新を確認してほしい。
| 製品 | レイヤー | 主な力点 | 言語 | 実行先の特徴 |
|---|---|---|---|---|
| Flue | フレームワーク | 宣言的なエージェント定義・チャネル統合・マルチクラウド | TypeScript | Node.js長時間プロセス／CloudflareでDurable Object |
| Cloudflare Agents SDK | ランタイム | 耐久実行・コード実行・仮想FSを基盤として供給 | TypeScript | Workers／Durable Objects |
| Vercel AI SDK | ライブラリ／土台 | モデル抽象・UIストリーミング・ツール承認 | TypeScript | フレームワーク非依存・各種ランタイム |
| OpenAI Agents SDK | フレームワーク | OpenAIモデル中心のエージェント構成 | Python／TypeScript | 任意のホスティング |
| LangGraph | フレームワーク | グラフによる多段制御の厳密記述 | Python／TypeScript | 任意のホスティング |
| Mastra | フレームワーク | TypeScriptのワークフロー・RAG・評価の統合 | TypeScript | 任意のホスティング |
TypeScriptでモデル抽象からチャットUIまでを書く土台としての位置づけは Vercel AI SDK 6入門｜エージェント・MCP・ツール承認をTypeScriptで実装する2026年最新ガイド で詳しく扱っている。Flueと比べる際の参照点になる。
整理すると、Flueと比べるべきはVercel AI SDKやOpenAI Agents SDKのようなフレームワーク層であり、Agents SDKはその下で各社ランタイムが個別に解いてきた分散システム問題を肩代わりする土台だ。 Flueがマルチクラウドである以上、Flue対Agents SDKという対立にはならない。 FlueはNode.jsでも他のVMでも動き、Cloudflareを選んだときだけAgents SDKの基盤機能を引き出す関係にある。
下の図は、レイヤーで各製品を並べたものだ。
Workers / Durable Objects] end FL --> CF FL -.->|Node.js実行先| NODE[任意のVM / コンテナ] OA --> ANY[任意のホスティング] LG --> ANY MA --> ANY VS --> ANY
想定ユースケース
Cloudflareの記事と各機能から、向いている使い方を読み取れる。
・コーディングエージェント：ファイル読み書き・grep・diffが中心の処理を、@cloudflare/shellの仮想ファイルシステムでコンテナなしに回す。重い処理だけContainersへ寄せる
・長時間ターンの自律エージェント：Fiberで中断・復旧に耐えるため、数分かかるツール連鎖や承認待ちを含むタスクでもスピナーが固まらない
・チャット常駐エージェント：Channelsを使ってSlack・GitHub・Linear・Discordへ組み込み、@flue/reactで状態とメッセージをフロントへ流す
・多段パイプライン：@cloudflare/dynamic-workflowsで、コードレビューやリサーチのような繰り返し実行を永続化・リトライ・スリープ付きで回す
・マルチプロバイダ運用：AI Gatewayのバインディングでエージェント単位の支出を追跡・制限し、14以上のプロバイダの推論を切り替える
トリアージエージェントの例が示すとおり、バグ報告の受け取りから再現・診断・修正までを宣言的に書けるため、開発フローに常駐させる用途と相性が良い。
料金体系と無料枠
Flueはオープンソースのため、フレームワーク本体に利用料はかからない。 費用が出るのは、裏側で呼ぶLLMのAPI利用料と、Cloudflareにデプロイした場合のWorkers・Durable Objects・AI Gatewayなどの従量課金だ。
Cloudflareブログが数値として挙げているのは、Code Modeの実行コストである「1ロードあたり0.002ドル、起動10ミリ秒未満」のみだ。 これ以外の総額や無料枠の内訳は同記事に明示がない。 Workers・Durable Objects・AI Gatewayの単価は変動するため、見積もりは各公式料金ページで確認するのが確実だ（本記事では推測の料金は出さない）。
Cloudflareは記事の締めで、自分でハーネスやフレームワークを作る人への提案も書いている。
「if you’re building your own agent harness or you’re building an agent framework, target the Agents SDK and get the platform integration for free.」 （自分のエージェントハーネスやエージェントフレームワークを作っているなら、Agents SDKを実行先にすれば、プラットフォーム統合を無償で得られる。） ── Cloudflare Blog, 2026-06-17
この「for free」はプラットフォーム統合という機能面を指す表現であり、Cloudflareリソースの従量課金が無料という意味ではない点に注意したい。
セキュリティとマルチテナント
マルチテナントの分離は、Durable Objectの単位で効く。 Cloudflareによれば、Flueの各エージェントは専用のDurable Objectの中で隔離されたストレージと計算を持つ。 1エージェント1Durable Objectという構造が、テナント間の状態の混在を避ける土台になる。 ノイジーネイバーを気にしなくてよい、という記述もこの分離に対応している。
コード実行の安全性は、Code Modeのアイソレートが担う。 LLM生成コードを、与えたバインディングだけを持つ使い捨てのWorkerアイソレートで実行し、終われば破棄する。 前述のとおり、バインディングは能力を与えつつ資格情報をコードに露出しないため、生成コード経由で鍵が漏れる経路を断つ設計になっている。
注意したい点もある。 LLM生成コードを実行する以上、与えるバインディングの範囲が実質的な権限境界になる。 不要なバインディングを渡さない、サンドボックスの選択（virtual／local／remote）を用途に合わせる、といった運用側の設計が前提になる。 Cloudflare自身のセキュリティ運用の考え方は、別記事で読める。
Cloudflareがマルチエージェントをどう本番運用しているかは CloudflareのAIコードレビューシステム解剖｜7専門エージェント並列実行の仕組みと実績 が参考になる。
制限事項と未確認の点
一次情報で確認できなかった事項を、推測で埋めずに列挙する。
・Flueのライセンス種別：Cloudflareは「open-source framework」と明記しているが、ブログとFlue公式の取得ページにライセンス名（MIT等）の記載は確認できなかった。採用前にリポジトリのLICENSEを確認すること
・正式GA時期：Flueは2026年6月16日に1.0 Betaを公開。安定版1.0の具体的な提供日は未確認
・総額の料金：Code Modeの「0.002ドル／ロード」以外の従量単価・無料枠は本記事の一次ソースに明示なし。各公式料金ページで要確認
・@cloudflare/workspace：DOの仮想FSとコンテナを同期する機能は「開発中（building）」の言及であり、提供時期・仕様は未確認
・Python対応：FlueとAgents SDKはTypeScript／JavaScript前提。第三者のPyFlueは公式ではない
・Pi／Project Thinkの細部：PiはEarendil（earendil-works）のミニマルなハーネスでMITと公式サイトにあるが、Project Thinkの内部仕様はブログの説明範囲を超える部分は未確認
これらは情報が更新されしだい確認すべき箇所だ。
まとめ
Cloudflareの主張は明快だ。 ハーネス単体では本番運用の分散システム問題を解けないので、状態・保存・計算を持つ基盤を下の層に置く。 それがCloudflare Agents SDKであり、耐久実行（Fiber）・コード実行（Code Mode）・仮想ファイルシステム（@cloudflare/shell）・動的ワークフローを、どのハーネスからも使えるようにした。
エージェントのハーネスという概念そのものを実装例から押さえたい方は Agent ハーネスは魔法ではない。実装例から学ぶ基本構造 を合わせて読むと、三層スタックの真ん中の層が掴みやすい。
Flueはその基盤に最初に乗ったフレームワークで、「何をするかではなく何を知っているかを書く」宣言的なモデルと、Slack・GitHub等へのChannels統合、@flue/reactによるフロント連携を持つ。
Flue自体はマルチクラウドで、Node.jsでもCloudflareでも動き、Cloudflareを選んだときだけAgents SDKの基盤機能を引き出す。
比較するなら、フレームワーク同士はFlue対Vercel AI SDK、土台はAgents SDK対各社ランタイムと分けて見るのが整理しやすい。
実体の判定を一言でまとめる。 Flueは2026年6月16日に1.0 Betaが出たオープンソースのTypeScriptフレームワークで、Piハーネスの上に構築され、Cloudflare Agents SDKを実行先の1つとして選べる。 料金はフレームワーク無償＋裏側のLLMとCloudflare従量で、総額の単価は公式料金ページで確認するのが確実だ。
参照ソース
・Cloudflare Blog: Bringing more agent harnesses and frameworks to Cloudflare, starting with Flue（2026-06-17）
・Cloudflare Agents 公式ドキュメント
・Cloudflare Agents: Durable Execution（公式ドキュメント）
・Flue 1.0 Beta 公式アナウンス
・withastro/flue 公式リポジトリ
・Pi（earendil-works）公式サイト
・Cloudflare Blog: Code Mode
・Cloudflare Durable Objects 公式ドキュメント
・Cloudflare AI Gateway 公式ドキュメント
