Bringing more agent harnesses and frameworks to Cloudflare, starting with Flue

Bringing more agent harnesses and frameworks to Cloudflare, starting with Flue
2026-06-17 Thomas Gauvin — 8 min read

2026年は、エージェントハーネスが本番運用に移行する年です。モデルが外界にアクセスするためのソフトウェア — Codex、Claude Code、OpenCode、Pi、Project Think のようなハーネス — は成熟し、チームはエージェントを単なるプロトタイプではなく、本番で負荷を支えるインフラとしてデプロイしています。しかし、本番で生き残るエージェントを構築するのは難しい課題です。私たちは自社のファーストパーティハーネスとして Project Think を構築する中で、このことを身をもって学びました。お客様と協力してエージェントを本番運用する過程で、クラウド上で動作する際にすべてのエージェントが直面する分散システム上の共通課題があることが分かりました。

• エージェントが中断されたとき、コンテキストを失ったりトークンを無駄にすることなく、自動的かつ優雅に中断箇所から再開するにはどうすればよいか？
• エージェントが信頼できないコードを安全に実行するにはどうすればよいか？
• エージェントが学習時に使ったツールを適切に利用するにはどうすればよいか？

これらの問題はハーネスだけで解けるものではありません。状態、ストレージ、コンピュートに結びついており、エージェントが動作するプラットフォームに依存します。だからこそ、Project Think を本番向けに堅牢化する中で得た知見を、エージェントの基盤層として Cloudflare Agents SDK に取り込んでいます。耐久実行（durable execution）、動的コード実行（dynamic code execution）、耐久ファイルシステム、動的ワークフローが、Agents SDK を基盤に構築する任意のハーネスから利用可能になりました。

同時に、ハーネスの上位に新たなレイヤーとしてフレームワークが現れています。Flue のようなフレームワークは、プロジェクト構造、規約、統合、開発者体験でハーネスを包み込み、エージェントを生産的に開発できるようにします。

スケーリングの課題を解決するために、プロダクショングレードのAIを構築するための三層スタックが現れつつあります。ユーザー向けの開発者体験から下位のプラットフォーム原始に向かって、各要素は次のようにフィットします：

• フレームワーク（Flue） — プロジェクト構造、規約、統合、CLI、エージェント開発のための開発者体験。
• ハーネス（Pi、Project Think） — ツールを呼び出し、結果を読み取り、コンテキストを管理し、タスク完了まで進行するエージェンティックループ。
• ランタイム/プラットフォーム（Cloudflare Agents SDK） — 上のすべてが依存するコンピュート、状態、ストレージのプリミティブ。

Agents SDK はそのボトムレイヤーです：durable execution のようなプリミティブを任意のハーネスやフレームワークに提供します。Flue は Astro チーム出身の新しいオープンソースフレームワークで、それを最初に採用したフレームワークです。以下でその仕組みを説明します。

Flue

今週、Flue は Pi ハーネス上に構築された 1.0 Beta をリリースしました。Pi は OpenClaw が使っているのと同じハーネスです。Flue をエージェントフレームワークとして差別化するのはそのアプローチです：エージェントが何をするかをスクリプトするのではなく、エージェントが何を知っているかを記述します。エージェントに必要なコンテキスト — モデル、スキル、サンドボックス、指示（instructions） — を定義すれば、与えたタスクを自律的に解決します。オーケストレーションループを書く必要はありません。

この宣言的モデルこそがエージェントの記述を容易にします。例えば、バグレポートを傍受し、サンドボックスで再現し、25行未満で診断まで行うトリアージエージェントの例が示されています。

Flue の開発者体験

Flue の強みは、エージェントが孤立して存在しない点にあります。エージェントは既にユーザーが作業している場所に存在するように設計され、好みのツールと統合します：

• Anywhere agents：Slack、GitHub、Linear、Discord にエージェントを配置でき、事前設定された Channels がイベント検証やディスパッチのボイラープレートを自動的に処理します。
• Headless, but UI-ready：エージェントはバックグラウンドタスクとして完全にヘッドレスで動作できますが、@flue/react はエージェントの状態、ツール実行、ライブメッセージをフロントエンドにストリーミングするネイティブフックを提供し、独自にリアルタイム基盤を構築する必要を減らします。
• Ecosystem-ready：flue add channel slack のようなコマンドで統合を追加・アップグレードしやすく、Flue は Markdown のブループリントを生成して、あなたのコーディングエージェントがそれを読み、変更し、コードベースにクリーンに統合できます。

プロトタイプではなくプロダクションを意識して設計

ローカル端末からエージェントを本番エコシステムに移すと、従来の分散システム障害が現れます。ホストのクラッシュ、LLMプロバイダからのAPIタイムアウト、予期せぬ再起動は、実行中のエージェントターンの短期記憶を消去する恐れがあります。Flue は Durable Streams によりこれを解決します。実行履歴の各イベントは追記専用ログに追加されます。各プロンプト、ツール応答、モデルの選択を不変の台帳として処理することで、エージェントの状態は揮発性になりません。プロセスが落ちた場合でも別のプロセスがログを引き継ぎ、正確に中断したステップから継続できます。

どこにでもデプロイ可能、Cloudflare も含む

Flue はマルチクラウド対応フレームワークです。Node.js 上では各エージェントはロングリビングなプロセスとして動作します。任意の VM やコンテナにデプロイしたり、GitHub Actions で動作させたり、既存のサーバに組み込んだりできます。しかし Cloudflare をターゲットにすると、各エージェントは Durable Object になります。各 Flue エージェントを専用の Durable Object 内で実行することで、Cloudflare は必要な数だけ自動的にスケールし、各エージェントに分離されたストレージとコンピュートを提供します。サーバのプロビジョニングやスティッキーセッション管理、ノイジーネイバーを心配する必要はありません。

Flue エージェントが Cloudflare にデプロイされると、Agents SDK の runFiber(), stash(), onFiberRecovered() メソッドを使った durable execution を得ます。Flue はまた、耐久ワークスペースに対するサンドボックス化されたコード実行のために @cloudflare/codemode と @cloudflare/shell を使用します。

ハーネスがエージェンティックプラットフォームに求めるもの

Flue の Cloudflare ターゲットがうまく機能するのは、それが Agents SDK に組み込んだコアプリミティブにうまくマッピングしているからです。Flue のソースコードを掘れば、Pi（基盤ハーネス）がどのように Cloudflare Agents SDK 上で動作するように適応されているかを理解できます。以下では、Flue が内部で Agents SDK をどのように活用しているか、そしてスケールでモダンなエージェントハーネスを確実に動作させるために何が必要かを説明します。

すべてのエージェントハーネスに必要な耐久実行

エージェントのターンは単一のリクエストではありません。モデルはトークンをストリーミングし、ツールを呼び出し、結果を待ち、人間の承認を求めたり、サブエージェントに作業を委任したりします。そのシーケンスは数秒から数分かかることがあり、任意の時点でプロセスが中断またはクラッシュする可能性があります。その場合、メモリにあったエージェント状態はすべて失われます：ストリーミング接続、保留中のツール呼び出し、ターン内の進行位置など。会話履歴はディスクに保存されているかもしれませんが、ユーザーは解決しないスピナーを目にします。それは壊れたユーザー体験です。

Fibers はこの問題を、Agent の基盤となる Durable Object 内部にネイティブなチェックポイント機構を提供することで解決します。runFiber() は Agent ターンの作業が始まる前に Durable Object の SQLite ストレージに進捗を記録し、ターンが進むにつれて stash() でチェックポイントを取ります。中断後に新しいエージェントインスタンスが起動すると、onFiberRecovered() は最後のチェックポイントを渡すので、エージェントはターンが中断されたこと、どこまで進んでいたかを知り、どのように継続するかを決められます。

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 は Cloudflare ターゲット上で正にこの runFiber() を使っています。onFiberRecovered() フックを用いれば、ハーネスはターンの実行をどのように再開するかを決められます。完全修復型のモデル（Project Think のようにターン状態を修復する）を試みるか、ターンの一部をリプレイするか、といった選択が可能です。

コードを実行することは、多数のツールを抱え込むより良い

エージェントハーネスはモデルにツールを通じて外界へのアクセスを与えます。しかしツールの表面は急速に増え、ツール定義が増えるとコンテキストウィンドウが埋まり、モデルは適切なツールを選択しづらくなります。より良いパターンは、モデルに1つのツールだけ与え、そのツールがコードを実行することです。モデルは必要な API を呼ぶ TypeScript 関数を書き、ハーネスがそれを実行します。これは私たちが Code Mode を紹介したときに説明したパターンです。

問題は、そのコードをどこで実行するかです。LLM生成コードを安全に実行するにはサンドボックスが必要ですが、典型的なサンドボックスは遅く、コストが高く、ツール呼び出しごとにコンテナを起動するのは非効率です。そこで Agents SDK は @cloudflare/codemode を提供します。@cloudflare/codemode は Dynamic Workers をラップし、LLM生成コードを独立した Worker isolate で、あなたが提供するバインディングだけで実行します。Code Mode は各スニペットごとに新しい Dynamic Worker を作成し、それを実行して捨てます。Isolate の起動は 10ms 未満で、$0.002/ロード 程度のコストで、短いコード実行ごとにコンテナを起動するより遥かに高速かつ安価です。

Flue は Cloudflare ターゲット上で @cloudflare/codemode をコードツールに用いています。エージェントはワークスペース向けに JavaScript を書き、Code Mode でそれを実行します。

ほとんどのワークスペース作業にフルコンテナは不要

エージェントハーネスはファイルシステムを必要とすることが多いです。ファイルを読み、出力を書き、コードを検索し、差分を理解するためです。特にコーディングエージェントはファイルシステム上で生きます。しかし、ハーネスがサーバーレス環境で動作している場合、実行を跨いで持続する耐久ファイルシステムをどう得るか？

一般的な答えはコンテナです。それでも動きますが、エージェントが主に行う作業に対してはコストが高い。エージェントターンの大半のファイル操作はテキスト処理です。例えば、レビューエージェントがファイルを読み、ソースをgrepし、パッチを書く場合、フルLinuxブートは不要です。

@cloudflare/shell は Durable Object 内に耐久仮想ファイルシステムを提供し、SQLite によってバックされます。読み書き、編集、検索、grep、diff といった型付きファイル操作をツールとして提供します。Flue エージェントが Cloudflare ターゲット上で動く場合、個別ツールを呼ぶ代わりにワークスペースの仮想ファイル状態 API に対して JavaScript を書きます。Durable Object 内でより多くの操作を実行することで、エージェントはワーカーのアイソレートモデルによる効率的な実行の恩恵を受け、コンテナオーバーヘッドを完全に回避できます。例えば：

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/workspace を開発中で、ある Durable Object の仮想ファイルシステムとコンテナの間で状態を同期し、軽量な Workers から必要なときだけ Linux 環境にシームレスに移行できるようにします。

Dynamic Workflows：エージェント自らワークフローを書き、繰り返し一貫した作業を行う

しかし、エージェントがファイルの読み取りや単一コードスニペットの実行以上のことをする必要があるときはどうでしょうか？大規模で複数ステップにわたるパイプラインをオーケストレーションし、時間をまたいで一貫して繰り返す必要がある場合（例えばバグを確実に解決するコードレビューや、良い結果を出す研究ワークフロー）にはどうすればよいでしょうか？ハーネス単体では各ステップを永続化し、失敗をリトライし、中断後に再開する耐久的なマルチステップ実行を提供できません。これはプラットフォームが各ステップを永続化し、再試行し、中断後に再開できることを必要とします。

このパターンは注目を集めています。Claude Code は最近 dynamic workflows をリリースしました。そこでは Claude がランタイムで JavaScript スクリプトを書き、十数の...