エージェントフレームワーク

deepseek-harnessフレームワーク

`dsh`はDeepSeek AIが自ら開発するエージェントハーネスで、`npx @deepseek-ai/dsh web`を実行すれば既定で`http://127.0.0.1:3080`にWeb UIが立ち上がります。中身はCordisを土台にした「すべてがプラグイン」の構成なので、既製の挙動をそのまま使うより、自分で機能を足していく前提のチームに向いています。一方で本人たちがdeveloper previewと明言し、互換性を壊す変更があるとREADMEで大文字の警告を出しているため、いま書いたプラグインが次のバージョンでそのまま動く保証はありません。READMEが説明する起動方法も`web`コマンドとソースからの実行だけで、それ以外は開発ガイドとアーキテクチャ文書へのリンクが示されるにとどまる点は把握しておきたいところです。

AutoGPTワークフロー

ここでのエージェントは、外部サービスの呼び出し・データ変換・モデルへの問い合わせ・条件分岐といった単位である「ブロック」を繋いだグラフです。コードではなくキャンバス上で組み立て、任意のタイミング、スケジュール、あるいはトリガーで実行します。ただし1つのリポジトリに無償の自己ホスト版と有償ホスティングの実装が同居しており、プラットフォーム側のディレクトリはPolyForm Shieldのため、利用はできても競合サービスとしての提供は禁じられています。

Difyワークフロー

AIへの指示文の管理、社内文書からの検索、AIに使わせる道具、運用画面までを一式で備えており、初期構築さえ済めばエンジニア以外でも回せます。ライセンスはApache 2.0に、マルチテナント提供とブランディングに関する追加条件を加えたもので、OSSではなくソース公開型にあたります。この上に製品を構築する前に必ず確認してください。

LangChainフレームワーク

本当の価値は網羅性にあります。必要なモデル、ベクトルストア、APIのアダプタはたいてい既に存在し、着想からプロトタイプまでの距離が短くなります。抽象化の階層が深いという評価は根強く、多くのチームは連携部分にこれを使い、制御フローが複雑になった段階でより明示的な実装に移行しています。

MetaGPTマルチエージェント制御

`metagpt "Create a 2048 game"`と一行打つだけで、要件定義書・設計書・ソースコードが`workspace/`以下に書き出されます。ただし働く顔ぶれは入手経路で変わります。PyPIで配布されている0.8.2は製品担当・設計担当・進行担当・エンジニアの4役ですが、READMEが案内するgit cloneのmainではチームリーダーとデータアナリストが加わり、進行担当は外れています。デモの下にあるのは汎用のフレームワークで、RoleとActionを継承し、どのActionの結果に反応するかを宣言すれば、共有のEnvironmentがメッセージを配って作業順を決めます。データ分析だけならData Interpreter単体で完結します。限界もはっきりしていて、公式FAQは生成コードが500行を超えると未実装の関数が残ると認めています。

AutoGenマルチエージェント制御

マルチエージェントシステムに対するMicrosoft Researchのアプローチで、専門化したエージェント間の構造化された対話から解が立ち上がります。探索的な課題や研究寄りの問題に強みがあります。採用前に確認すべき点が2つあります。メジャーバージョン間でAPIが大きく作り直されていること、そしてGitHubがリポジトリのライセンスをCC-BY-4.0と報告していることです。後者はコンテンツ向けのライセンスであり、OSI承認のソフトウェアライセンスではありません。商用利用の前にメンテナへ条件を確認してください。

CrewAIマルチエージェント制御

タスクを、役割と目標を持つエージェントのチームとして表現し、互いに作業を引き渡させます。この比喩によりマルチエージェント設計が一目で読めるようになり、デモ映えする理由にもなっています。ただし、役割を演じる複数エージェントが、よく設計された単一エージェントを実際に上回るかは、導入前に計測する価値があります。答えが「否」であることは珍しくありません。

LlamaIndexRAG / 検索拡張

多くのフレームワークがエージェントのループから出発するのに対し、これはデータから出発します。取り込み、インデックス戦略、そして回答が実際に根拠を持つかどうかを決める検索パターンを中心に据えています。問題の難所が推論ではなくコーパス側にある場合に選ぶ価値があります。

agnoフレームワーク

Agnoは3つの層でできています。エージェント・チーム・ワークフローを書くPython製のSDK、それらをREST APIとして公開し、セッション、JWTによる権限確認、定期実行、実行記録の保存までを自前のデータベースで賄うFastAPI製のランタイムAgentOS、そして実行の様子を眺めるための管理画面です。前の2つはApache-2.0で、コンテナが動く場所ならどこでも動かせます。既定で送られる利用統計を除けば、処理もデータもAgnoのサーバーを通りません。例外は管理画面で、手元のランタイムにつなぐ分は無料ですが、デプロイ済みのランタイムにつなぐには有料プランが要ります。開発の速度が速く、マイナー更新の多くに破壊的変更が入るため、バージョンを固定してから作り込むのが安全です。

LangGraphフレームワーク

LangGraphでは、エージェントの処理の流れを「状態・ノード・エッジ」のグラフとして自分で定義します。ノードはLLM呼び出しやツール実行といった処理単位、エッジは次にどのノードへ進むかのつなぎで、全ノードが共有の状態を読み書きします。状態に応じてエッジを分岐させてループを作れるほか、ノードごとに状態が保存されるため、人の承認待ちで止めて後から再開したり、障害後に保存地点から続けたりできます。その分コードは増え、単純なツール呼び出しだけのエージェントには他のフレームワークより重くなります。

DSPyプロンプト最適化

各ステップが何をすべきかを宣言し、評価指標を与えると、オプティマイザがそれを最大化するプロンプトと少数事例を探索します。パイプラインの改善が、経験則ではなく計測可能な作業になるのが利点です。評価用データセットが前提であり、それがなければ最適化の対象自体が存在しません。

CopilotKitツール連携

文字を返すだけのエージェントは、それが置かれているアプリケーションを活かしきれません。CopilotKitはその両者をつなぎます。あるフックでアプリの状態の一部をエージェントに読ませ、別のフックで画面側の関数を呼べるように登録し、さらに別のフックで、返答を文章ではなくReactのコンポーネントとして描かせます。確認用のフォーム、グラフ、承認を求める差分などです。バックエンドとは、同じ開発元が公開しているAG-UIというプロトコルでやり取りするため、エージェント側がLangGraphでもCrewAIでもClaude Agent SDKでも、画面側の作りは変わりません。逆に、エージェントそのものは提供しません。用意するのは利用者側で、整備されている経路はReactです。

AgentScopeフレームワーク

AgentScopeは、考えてツールを呼び、結果を見てまた考えるという基本のエージェントから始まり、そのうえで通常なら後から自分で作ることになる部分まで用意しています。ツールは自分のプロセス内ではなく隔離された環境で実行され、文脈は増えるにつれて圧縮したり外部に退避したりできます。途中で人に承認を求めることもでき、完成したエージェントは複数の利用者を分離した状態で提供する基盤として動かせます。その広さと引き換えに、2.0は1.0からの意図的な非互換変更であり、旧版向けに書かれた解説はそのままでは通用しません。

OpenAI Agents SDKフレームワーク

エージェント、ハンドオフ、ガードレール、トレーシングという少数のプリミティブのみで構成されています。この表面積の小ささが利点で、学習することも、抗うことも少なくて済みます。OpenAI自身のモデルを第一に想定した設計のため、複数プロバイダ間の可搬性が重要な場合はその点を考慮してください。

smolagentsフレームワーク

中心にあるのはCodeAgentで、モデルは構造化されたツール呼び出しを返す代わりに短いPythonコードを書き、ツールを直接呼びます。呼び出しを繰り返しや条件分岐の中に入れる操作は、フレームワークの機能ではなくPython自体から得られます。エージェントのループ全体がおよそ1000行という小ささは利点であると同時に上限でもあり、永続的な状態、ワークフローの記述、保存機構は自分で組むことになります。従来のJSON形式が合う場面向けにToolCallingAgentも同梱されています。

semantic-kernelフレームワーク

手元のクラスのメソッドにカーネル関数の目印を付け、プラグインとしてまとめてカーネルに登録する——この流れが中心にあり、カーネルにはモデルへの接続も一緒に入るので、OpenAIからAzure OpenAIやOllamaへ移すときに書き換えるのは登録部分だけで済みます。OpenAPIの定義があれば社内の既存APIをそのまま道具にでき、フィルターという仕組みで呼び出しの前後に記録や伏せ字を挟むこともできます。弱点は品質ではなく方向性で、Microsoftは新機能の大半を後継のAgent Frameworkで作ると明言しているため、これから新規に始める案件よりも、すでにこのSDKで書かれた資産を保守し育てていく現場に向いています。

Mastraフレームワーク

エージェントは指示文とモデルを与えて宣言し、ツールは入力と出力の両方をスキーマで検証します。ワークフローはステップを繋いで組み立て、実行状態をストレージに書き出すため、途中で中断して後から再開できます。検索・メモリ・評価・トレースが別々の部品の寄せ集めではなく同じパッケージに入っている点が魅力ですが、その広さは覚える対象の広さでもあります。またApache-2.0の範囲は、別の商用ライセンスで留保されたいくつかのディレクトリの手前で止まります。

FastMCPツール連携

型注釈の付いたPython関数にデコレータを1つ付ければ、それで完成したツールになります。スキーマは型注釈とドキュメント文字列から導出され、受け取る引数と返す値の双方が検証されます。さらに、2週目の作業でぶつかる部分まで揃っています。型付きクライアント、OAuthと外部IDプロバイダ、複数サーバーを1つとして束ねる構成、既存サーバーの前段に立つプロキシ、ミドルウェアです。注意すべきは名前の重複で、このAPIの旧版が公式のMCP Python SDKに取り込まれているため、FastMCPという語はどちらのimportを読んでいるかで別のものを指します。

AI SDKフレームワーク

作業の大半は4つの関数が担います。文章にはgenerateTextとstreamText、スキーマで形を決めたデータにはgenerateObjectとstreamObjectを使い、背後のモデルがOpenAIでもAnthropicでもGoogleでもBedrockでもローカルのものでも、呼び出し方は変わりません。もう半分はUI側のフックで、逐次表示のチャット画面を自前のパーサーなしに数行で書けます。ただしこれはモデル接続とUIの層であり、エージェントの実行基盤ではありません。永続的なメモリ、検索、耐久性のある処理制御は別の道具の担当です。

haystackフレームワーク

Haystackは、文書の取り込みから検索、モデルの呼び出しまでを1つずつコンポーネントとして置き、パイプラインの上で出力と入力を名前で指定してつないでいくフレームワークです。型の合わない組み合わせはつないだ瞬間にエラーになり、条件による分岐も、回数の上限つきで前のコンポーネントへ戻すループも、同じパイプラインの中に書けます。Agentもコンポーネントの一つなので、ツール呼び出しの繰り返しをパイプラインへ組み込んだり、別のAgentのツールとして渡したりできます。裏を返せば配線はすべて自分で書くことになり、PDFを置くだけで対話システムができあがる近道はありません。ライブラリなので自分のプロセスの中で動き、パイプラインをHTTPの窓口やMCPサーバーとして公開するには別プロジェクトのHayhooksを使うか、受け口を自分で用意することになります。

Lettaメモリ / コンテキスト

コンテキストウィンドウをRAM、それ以外をディスクとみなし、何を読み込み何を退避するかをエージェント自身に判断させます。この枠組みにより、無期限に動き続けるエージェントが扱える対象になります。既存スタックにメモリライブラリを後付けするより、思想への踏み込みが大きい選択です。

Agent Development Kitフレームワーク

エージェントはLlmAgent——モデル、指示文、ツールの一覧——として書き、それを階層に組み合わせるか、順次・並列・繰り返しの流れを自分で指定するワークフローとしてつなぎます。各ターンはRunnerが進め、セッションとその状態を保持するため、リクエストをまたいで会話が続きます。他のフレームワークが省きがちな部分——保存したテストケースに対してエージェントを採点する評価の仕組みと、実行を1ステップずつ追えるローカルのWeb画面——まで同梱しているのが特徴です。LiteLLM経由でモデルは選べ、コンテナならどこでも動きますが、ドキュメントもツール群もマネージド実行環境もGoogleのもので、GeminiとGoogle Cloudから離れるほど自分で組み立てる部分が増えます。

Pydantic AIフレームワーク

Python開発者が既に信頼しているバリデーションモデルをエージェントの出力に適用します。不正な形式のレスポンスは、3層下流ではなく目に見える場所で失敗します。オールインワン型のフレームワークより意図的にスコープを絞っており、それ自体が設計思想です。コードベース全体を型付けしている場合に特によく噛み合います。

elizaフレームワーク

elizaOSはTypeScript製のエージェントフレームワークであると同時に、デスクトップとモバイルのアプリ、ホスティングサービス、端末機能への橋渡しまでを1つのリポジトリに収めた製品一式です。開発者が書くのは、名前、指示文、経歴の断片、読み込むプラグインを並べたキャラクターファイルで、あとはランタイムが受け取ったメッセージを保存し、その場面に関係するプロバイダーだけから文脈を集め、モデルにアクションを選ばせて実行し、返答のあとでエバリュエーターが事実を抜き出して記憶に書き戻します。同梱のプラグインには、DiscordやTelegramなどのチャット、MCPサーバーの呼び出し、ブラウザとデスクトップの操作、カレンダーや受信箱といった秘書機能、自分で鍵を持つ暗号資産ウォレット、通信を切っても動く端末内モデルが並びます。ただしnpmの安定版は今も1系で、ここで説明した2系はベータ版とアルファ版でしか配布されていないため、エージェント用のライブラリを1つ選ぶつもりで手を出すと、抱えるものは想定よりかなり大きくなります。

camelマルチエージェント制御

CAMELは、エージェント同士に会話をさせることを出発点にした研究寄りのライブラリです。RolePlayingは指示を出す側と実行する側の2つのエージェントを組ませ、Workforceでは調整役が分割したサブタスクを複数の作業者へ配ります。その周囲には、80を超えるツール群、約50のモデル接続、GAIAやBrowseCompなどのベンチマーク実行環境、対話の記録を微調整用データセットへ変換するパイプラインが揃っています。実験を回す用途ならこの幅広さ自体が強みですが、本番で1つのエージェントを堅実に動かしたいだけなら使わない部分を大量に抱え込むことになりますし、2023年の公開以来バージョンは0.2系のままです。

AG-UIプロトコル

数分間動き続け、途中経過を流し、判断を変え、ときに人の確認を必要とするエージェントを、リクエストとレスポンスのAPIでは表現できません。AG-UIはそのやり取りを、HTTPとWebSocket上のイベント列として定義します。トークン、ツール呼び出しとその結果、共有状態、添付ファイル、そして実行を止めて問い合わせる割り込みが含まれます。有用性は既に実装している側の広さに比例し、本カタログ収録のフレームワークを含む公式対応一覧がその根拠です。逆に自分のバックエンドもフロントエンドも未対応なら、利点は大きく下がります。

Pipecat音声エージェント

音声から音声までのループ——文字起こし、モデル、音声合成、割り込み処理——を、差し替え可能なサービスのパイプラインとして組み立てます。正しく作ろうとすると面倒になるのがまさにこの部分です。音声用途ではレイテンシがすべてであり、ターンテイキングと割り込み（バージイン）を後付けではなく一級の要素として扱っています。実運用ではモデル選定以上に、トランスポートとネットワーク構成への配慮が必要になります。

LiveKit Agents音声エージェント

LiveKitルームへプログラム可能な参加者として接続するサーバー側エージェントを構築し、WebRTC通信、ジョブ配信、電話連携、ターン検出、各種モデルプロバイダー連携をまとめて扱います。メディア通信と本番セッションの運用を一つの基盤で組みたい用途に向きます。一方、テキスト専用のエージェントや通信層に依存しないパイプラインには、LiveKit前提の構成が過剰になる場合があります。

Agent Frameworkフレームワーク

両者を作ったチーム自身の手によるもので、AutoGenの軽いエージェント抽象を残しつつ、Semantic Kernelのセッション状態・ミドルウェア・テレメトリを取り込み、その上に実行経路を明示するグラフ型のワークフローを載せています。.NETのチームにとっては、これまで存在しなかった純正の答えです。代償は時期の問題で、まだ若く、既存のAutoGenやSemantic Kernelのコードは移行が必要になります。

LangChain4jフレームワーク

看板機能はAI Servicesです。Javaのインターフェースを宣言してアノテーションを付けると、プロンプトの組み立て、モデルの呼び出し、返り値の型へのマッピングまでを実装として提供してくれます。その下には素のChatModel APIがあり、宣言的な層が邪魔になったときはいつでも降りられます。RAG、ツール呼び出し、Spring Boot・Quarkus・Micronaut・Helidonとの統合はいずれも公式提供です。名前は似ていますがPython版の移植ではないため、あちらの資料はそのままは通用しません。

PocketFlowフレームワーク

PocketFlowは、中身を最後まで見通せないフレームワークへの反動として作られています。全体は依存関係のない約100行です。ノードは、必要なものを集める・処理する・次を決める、という3段階で1つの仕事をこなし、ノードが返した文字列がどのエッジをたどるかを決めます。ノード同士はただの辞書を1つ共有します。フレームワークと呼べるのはここまでです。モデルを呼ぶクライアントも、提供元ごとのエラーに対する再試行の方針も、実行記録の仕組みもありません。それらは自分で書くことになり、参考資料の役割は動く例を集めたクックブックが担います。他人の大きな設定を読むより、小さなコードを自分で持つほうがよいと考える人に向いています。

TEN Framework音声エージェント

音声エージェントのうち、モデルの外側にあって通常は手作業で組み上げる部分を覆います。発話の検出、ターン終了の判定、話者の分離、電話網への接続、口の動きを同期させたアバターの駆動、さらには組み込み機器への到達までが対象です。ただし採用の前にライセンスを読んでください。Apache 2.0にAgoraによる追加条件が付いており、モバイル端末を含むエンドユーザー機器上でのホスティングと、Agora自身の提供物と競合する形での配備が禁じられています。

mcp-agentフレームワーク

mcp-agentは、エージェントが使うツールがすべてMCP経由で来るなら、フレームワーク自体は小さくできるという考え方に賭けています。面倒な部分であるMCPサーバーへの接続の開始・維持・終了はこちらが引き受け、そのうえでAnthropicの「Building Effective Agents」で知られる構成を、入れ子にできる部品として提供します。得意分野のエージェントを選ぶルーター、計画を立てて割り振るオーケストレーター、出来を見て差し戻す評価役などです。作ったエージェント自体をMCPサーバーとして公開することもできます。障害をまたいで実行を続けたい場合はTemporal上で動かせますが、その分、運用するサービスが1つ増えます。

Rigフレームワーク

Rigは、本体がすでにRustで書かれていて、モデルを呼ぶためだけにPythonのプロセスを別に立てたくない場合の選択肢です。ツールはRustの関数そのもので、引数の定義は型から生成されるため、食い違いは本番で見つかる不正な呼び出しではなくコンパイルエラーになります。出力も同じで、エクストラクタにモデルへ値を求めさせると、普通のRustの構造体として返ってきます。モデルの提供元もベクトルストアもトレイトの背後にあるため、差し替えは設定の変更で済みます。引き換えになるのは周辺の充実度です。評価や記録、エージェント向けの道具はPythonなら何種類もありますが、Rustでは相当するものがないことが多く、周辺の仕組みは自分で書くことになります。

swarmsフレームワーク

Swarmsは、1つのAgentクラスと、複数のエージェントを協働させる既製の型を数多く抱えたフレームワークです。直列につなぐ、同じ課題を全員に配る、監督役が専門家へ割り振る、多数決や討論で決める——こうした15種類をSwarmRouterが名前ひとつで呼び分けますが、型によっては、流れを表す文字列や、賛成役・反対役・審判役という3体の並び順など、名前以外の指定も要ります。依存関係をグラフで書くGraphWorkflowはこの呼び分けには含まれず、直接組み立てます。守備範囲の広さはそのまま設定量でもあり、14.0.0のAgentクラスは名前つきの引数だけで89個あります。しかも公式ドキュメントは、履歴をディスクに残すかどうかの既定値を、実際のコードとは違う形で説明しています。本番に載せる前に、既定値は書かれた説明ではなく実際の挙動で確かめておくことをおすすめします。

NeMo Guardrailsガードレール

多くのガードレール製品は1か所で1つのことを検査します。こちらは介入点を5つ定義します。モデルが要求を見る前、検索が取り込んだ内容、会話の流れ、ツール呼び出しの周囲、そして応答が利用者に届く前です。アプリケーションとモデルの間に位置するため、既に稼働中のシステムに、どちら側も変えずに後付けできます。代償はレイテンシと語彙です。強力な制御のいくつかはそれ自体がモデル呼び出しであり、対話の規則はColangという専用言語で記述します。

Strands Agentsフレームワーク

Strands Agentsは、処理の流れをグラフとして組み立てる方式とは逆の設計です。システムプロンプトと、ツールとして印を付けた普通の関数を渡せば、どれをどの順で呼び、いつ終えるかはモデルが判断します。最初のエージェントは配線図ではなく数行で書ける一方、想定外の動きをしたときに見比べるグラフがないため、実行の記録をたどって原因を探すことになります。そのループの周りには、長く動かすために必要な部品が揃っています。各ステップで呼ばれるフックでツール実行を記録したり拒否したりでき、会話マネージャは履歴がモデルの上限に達する前に切り詰めや要約を行います。あるエージェントを別のエージェントのツールとして渡すこともできます。

GEPAプロンプト最適化

強化学習は実行全体を1つの数値へ圧縮するため、何が悪かったかを示す部分を捨ててしまいます。GEPAはそれを保持します。エラーメッセージ、実行の記録、推論のログをモデルへ戻し、失敗の原因を診断させて具体的な修正案を出させます。さらに、1つの勝者へ収束させず、それぞれ異なる事例で強い候補プロンプトの集合を保ちます。プロジェクトは、強化学習が1万回超を要する場面で100〜500回の評価で結果に達すると述べています。実行も反省もモデル呼び出しであるため、この効率は強化学習との比較であって、費用ゼロという意味ではありません。

AG2フレームワーク

AutoGenがメンテナンスモードに入ったとき、進む先は2つに分かれました。これはそのうちコミュニティ側の道です。同じ有志たちが、複数のエージェントが会話しながら課題を解くという元の考え方を、Microsoftの外で引き継いでいます。ただしAutoGenから移ってくる人は、1.0で何が起きたかを知っておく必要があります。実際にコードを書く対象だったConversableAgentやGroupChat、そして`autogen`という読み込み名は、並行して保守される別リポジトリへ移りました。現在の`pip install ag2`で入るのは、プロトコルを軸に作り直された新しいフレームワークです。既存のコードは動き続けますが、その置き場所はもうここではありません。