DeerFlow 2.0を読む：長時間タスクを束ねるSuperAgentハーネス

Deep Researchからハーネスへ変わった2.0

DeerFlowは、README上でDeep Exploration and Efficient Research Flowの略称と説明されています。初期のディープリサーチ用途から、調査、データパイプライン、スライド、ダッシュボード、コンテンツ作成までを扱うハーネスへ範囲を広げました。DeerFlow 2.0はゼロから書き直され、1.xとはコードを共有しないと明記されています。元のフレームワークを探す人向けには1.xブランチが維持され、活発な開発は2.0へ移っています。2.0の中心は、単一のエージェントに全作業を詰め込むことではありません。サブエージェント、メモリ、サンドボックス、ツール、拡張可能なスキルを調整し、分数から数時間かかるタスクを扱う枠を作ることです。READMEは公式サイトで実デモを見られると案内していますが、掲載例が自分の業務で同じ精度や安全性を持つ証拠ではありません。導入時は、調査だけ、ファイル操作を含む作業、外部連携を伴う作業を分けて評価する必要があります。

make setupが作る最小構成

クイックスタートでは、リポジトリをcloneしてプロジェクトルートでmake setupを実行します。対話式ウィザードはLLMプロバイダー、任意のウェブ検索、サンドボックス方式、bashアクセス、ファイル書き込みツールなどを選ばせ、最小限のconfig.yamlを作り、キーを.envへ書き込みます。READMEは所要時間を約二分としています。構成を手作業で管理したい場合はmake configで完全なテンプレートをコピーし、make doctorで設定を検査して修正のヒントを得られます。問題報告用のmake support-bundleは、要約、Issue用の下書き、任意の証拠zipを.deer-flow/support-bundlesへ書き込みます。そこには匿名化した診断情報とファイルマニフェストだけが含まれ、.env、会話メッセージ、ユーザーファイルの内容は含まれないと説明されています。Windowsのローカル開発はGit Bashが必要で、cmd.exeとPowerShellはbashスクリプトの実行対象ではありません。設定ウィザードが便利でも、作られたキーと権限の範囲は人がレビューしてから実行へ進めるべきです。

Docker、ローカル開発、サイズの違い

READMEはDockerを推奨経路として案内しています。make docker-initでサンドボックスイメージを取得し、make docker-startでサービスを開始し、make upでイメージをビルドして本番用サービスを起動し、make downで停止する流れです。ローカル開発ではmake checkがNode.js 22以上、pnpm、uv、nginxを確認し、make installとmake devで起動します。アクセス先はhttp://localhost:2026です。目安として、ローカル評価は4 vCPU、8 GB RAM、20 GB SSD、Docker開発は4 vCPU、8 GB RAM、25 GB、長時間稼働するサーバーは8 vCPU、16 GB RAM、40 GBと記載されています。これはREADMEのサイジング案であり、タスク量、モデル、同時実行数を含む性能保証ではありません。config.yamlの変更は次の設定アクセス時にバックエンドが自動取得しますが、チェックポイントの保存設定は再起動が必要と説明されています。起動できることを確認した後、利用するモデル、ファイル領域、同時実行、停止と復旧を自分の負荷で確かめるのがよいでしょう。

サンドボックスとMCPの権限境界

DeerFlowは、エージェントがツールやファイルを使う場面をサンドボックスで分けます。READMEにある方式は、ホスト上で直接動かすローカル実行、隔離コンテナを使うDocker実行、プロビジョナーを介したKubernetes上のDocker実行です。どの方式を選ぶかは、速度だけでなく、エージェントが触れるファイル、ネットワーク、認証情報を決めます。MCPサーバーも設定でき、HTTPとSSEではOAuthトークンの流れ、stdioではツールごとのタイムアウトを扱います。ツール名にサーバー名を付けて衝突を防ぐ仕組みもREADMEにあります。スキルのallowed-toolsは、スキルがスラッシュで有効化されるか、read_fileで読み込まれた後に適用されるという説明です。ただし、READMEはこの仕組みを厳格なセキュリティ境界ではなく、ベストエフォートの動作範囲と位置づけています。ファイル書き込み、bash、外部MCPを有効にするときは、サンドボックス内へ入る秘密情報を洗い出し、不要なツールを無効にし、実行ごとに生成物を確認してください。

IMチャネルと観測データの扱い

IMチャネルとしてTelegram、Slack、FeishuまたはLark、WeChat、WeCom、DingTalkが案内されています。長いポーリングまたはWebSocketを使い、パブリックIPを必須にしない構成と説明されています。チャネルからは、new、status、models、memory、helpなどのコマンドを使い、ログインした利用者ごとにアカウントをひも付ける接続も用意されています。利用者が増えると、誰がどのタスクを送り、どのファイルやツールへ到達できるかが重要になります。観測性ではLangSmith、Langfuse、Monocleを統合できます。LangSmithとLangfuseは環境変数で有効にし、MonocleはOpenTelemetryを基盤にLLM呼び出し、エージェント手順、ツールとMCP呼び出しの入力、出力、時間、トークン数を記録します。トレースにはプロンプトや結果が含まれ得るため、READMEは信頼できる宛先だけでリモートエクスポーターを有効にするよう注意しています。監視を増やすほど、便利さとデータ流出面が同時に増えます。必要な属性、保存期間、閲覧者、送信先を先に決めるべきです。

スキル、サブエージェント、長期メモリ

DeerFlowのスキルは、ワークフロー、ベストプラクティス、参照をMarkdownファイルで定義します。研究、レポート、スライド、ウェブページ、画像や動画の生成などのスキルが同梱され、必要な時だけ段階的に読み込んでコンテキストを抑える考え方です。READMEは、サブエージェント、セッション目標、手動のコンテキスト圧縮、長期メモリ、ファイルシステムもCore Featuresとして挙げています。これらを組み合わせると、長い仕事を小さな役割へ分割し、途中の知識や出力を次の処理へ渡せます。しかし、分割されたタスクが正しいか、メモリへ残る情報が適切か、サブエージェントが同じ権限を持つべきかは設計判断です。組み込みスキルの正確な数はREADMEにありません。導入時は、読み取りだけの調査、ファイル生成、外部送信を別々のスキルへ分け、保存するメモリを明示し、長時間タスクを途中で停止して再開できるかを確認してください。ハーネスは作業の枠を提供しますが、事実確認や最終承認を省く根拠にはなりません。

セキュリティ警告とMITライセンス

READMEは、不適切なデプロイがセキュリティリスクを生む可能性を明示し、セキュリティ上の推奨事項を置いています。完全な脅威モデルや安全性の保証は示していません。とくにLark連携では、ブラウザへLarkアプリの秘密を渡さない一方、サンドボックス内のlark-cliが資格情報ディレクトリを読めるため、サンドボックス自体がLark資格情報の信頼境界になると説明されています。これは、コンテナを使っただけで秘密が見えなくなるとは限らないことを示す具体例です。ライセンスはMITで、著作権表示を残す条件のもと、使用、改変、配布などを許可しますが、保証はありません。リリース履歴にはv2.0.0が記録されています。採用前には、サンドボックス方式、資格情報のマウント、外部トレース、IM利用者、ファイル書き込みを確認し、影響の小さいタスクで停止と復旧を試します。DeerFlow 2.0は長いエージェント作業を整理する基盤として魅力がありますが、強力なツールを束ねるほど、構成と権限を自分で監査する責任が重くなります。

編集部の結論

DeerFlow 2.0は、数分から数時間かかる調査、コード作成、資料生成を一つの実行基盤で管理したいチームに向きます。READMEは設定ウィザード、サンドボックス、MCP、複数の観測系、長期メモリを具体的に示しますが、ベンチマークや本番の安全性を保証していません。採用前にLLMキーの管理、ツール権限、サンドボックスの信頼境界、トレースの送信先、IM経由の利用者認証を小さな構成で確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes