エージェントフレームワーク
エージェントの制御ループ——計画、ツール呼び出し、状態保持、失敗からの復帰——を提供するライブラリ群。ここでの選択が後続すべてに影響するため、最初のデモが早く動くかどうかだけでなく、デバッグのしやすさとロックインの度合いを併せて評価してください。
12件
プロンプトのオーケストレーション、検索、エージェントツール、管理UIまでを備えた統合プラットフォームで、初期構築さえ済めば非エンジニアでも運用できます。ライセンスはApache 2.0に、マルチテナント提供とブランディングに関する追加条件を加えたもので、OSSではなくソース公開型にあたります。この上に製品を構築する前に必ず確認してください。
本当の価値は網羅性にあります。必要なモデル、ベクトルストア、APIのアダプタはたいてい既に存在し、着想からプロトタイプまでの距離が短くなります。抽象化の階層が深いという評価は根強く、多くのチームは連携部分にこれを使い、制御フローが複雑になった段階でより明示的な実装に移行しています。
`dsh`はDeepSeek AIが自ら開発するエージェントハーネスで、`npx @deepseek-ai/dsh web`を実行すれば既定で`http://127.0.0.1:3080`にWeb UIが立ち上がります。中身はCordisを土台にした「すべてがプラグイン」の構成なので、既製の挙動をそのまま使うより、自分で機能を足していく前提のチームに向いています。一方で本人たちがdeveloper previewと明言し、互換性を壊す変更があるとREADMEで大文字の警告を出しているため、いま書いたプラグインが次のバージョンでそのまま動く保証はありません。READMEが説明する起動方法も`web`コマンドとソースからの実行だけで、それ以外は開発ガイドとアーキテクチャ文書へのリンクが示されるにとどまる点は把握しておきたいところです。
マルチエージェントシステムに対するMicrosoft Researchのアプローチで、専門化したエージェント間の構造化された対話から解が立ち上がります。探索的な課題や研究寄りの問題に強みがあります。採用前に確認すべき点が2つあります。メジャーバージョン間でAPIが大きく作り直されていること、そしてGitHubがリポジトリのライセンスをCC-BY-4.0と報告していることです。後者はコンテンツ向けのライセンスであり、OSI承認のソフトウェアライセンスではありません。商用利用の前にメンテナへ条件を確認してください。
タスクを、役割と目標を持つエージェントのチームとして表現し、互いに作業を引き渡させます。この比喩によりマルチエージェント設計が一目で読めるようになり、デモ映えする理由にもなっています。ただし、役割を演じる複数エージェントが、よく設計された単一エージェントを実際に上回るかは、導入前に計測する価値があります。答えが「否」であることは珍しくありません。
多くのフレームワークがエージェントのループから出発するのに対し、これはデータから出発します。取り込み、インデックス戦略、そして回答が実際に根拠を持つかどうかを決める検索パターンを中心に据えています。問題の難所が推論ではなくコーパス側にある場合に選ぶ価値があります。
エージェントを「中身の見えないループ」ではなく、ノードとエッジの明示的なグラフとして表現します。永続チェックポイントにより実行を人間の承認待ちで中断し、後から再開できるため、本番システムに触れるワークフローで現実的な選択肢になります。反面、単純なツール呼び出しだけのエージェントには記述量が多く、他のフレームワークより初期セットアップが重くなります。
各ステップが何をすべきかを宣言し、評価指標を与えると、オプティマイザがそれを最大化するプロンプトと少数事例を探索します。パイプラインの改善が、経験則ではなく計測可能な作業になるのが利点です。評価用データセットが前提であり、それがなければ最適化の対象自体が存在しません。
エージェント、ハンドオフ、ガードレール、トレーシングという少数のプリミティブのみで構成されています。この表面積の小ささが利点で、学習することも、抗うことも少なくて済みます。OpenAI自身のモデルを第一に想定した設計のため、複数プロバイダ間の可搬性が重要な場合はその点を考慮してください。
コンテキストウィンドウをRAM、それ以外をディスクとみなし、何を読み込み何を退避するかをエージェント自身に判断させます。この枠組みにより、無期限に動き続けるエージェントが扱える対象になります。既存スタックにメモリライブラリを後付けするより、思想への踏み込みが大きい選択です。
Python開発者が既に信頼しているバリデーションモデルをエージェントの出力に適用します。不正な形式のレスポンスは、3層下流ではなく目に見える場所で失敗します。オールインワン型のフレームワークより意図的にスコープを絞っており、それ自体が設計思想です。コードベース全体を型付けしている場合に特によく噛み合います。
音声から音声までのループ——文字起こし、モデル、音声合成、割り込み処理——を、差し替え可能なサービスのパイプラインとして組み立てます。正しく作ろうとすると面倒になるのがまさにこの部分です。音声用途ではレイテンシがすべてであり、ターンテイキングと割り込み(バージイン)を後付けではなく一級の要素として扱っています。実運用ではモデル選定以上に、トランスポートとネットワーク構成への配慮が必要になります。