Microsoft Agent Framework は、AI エージェントを構築するためのオープンソースのフレームワークである。Microsoft のコース AI Agents for Beginners で説明されているその際立った特徴は、関数をモデルに公開するのに必要な手続きがきわめて少ないことである。ツールは @tool デコレーターを付けた Python 関数として定義され、フレームワークがその関数とパラメーターをモデルに送るスキーマへとシリアライズし、そのうえでモデルとアプリケーションのコードとの間の往復のやり取りを処理する。これが、関数呼び出し を直接実装する場合に比べてこのフレームワークがもたらすものである。スキーマは手書きするのではなく生成され、モデルとのやり取りはアプリケーションではなくフレームワークの責任となる。
機能
既存の関数はデコレーターを付けることでツールに変換され、その際デコレーター上で承認モードを指定する。エージェントは、プロジェクトのエンドポイント、モデルのデプロイメント、認証情報を設定したチャットクライアントから作成され、名前、指示、使用できるツールが与えられる。そのうえで、エージェントを自然言語のリクエストに対して実行する。
開発者が自ら書く関数に加えて、フレームワークは FoundryChatClient を通じて組み込みのツールへのアクセスを提供する。コースが名前を挙げているのは File Search と Code Interpreter の 2 つである。
個々のエージェントの上位には、フレームワークのワークフローシステムがある。ここでは、エグゼキューターと呼ばれる作業単位がビルダーを通じてエッジで結び付けられる。Microsoft のドキュメントは、このシステムにおける ヒューマン・イン・ザ・ループ を、独立した機能ではなく、より一般的な機能から導かれるものとして説明している。エグゼキューターはワークフローの外部にリクエストを送り、その応答を待つことができ、人間のオペレーターは外部システムのさまざまなケースの 1 つとしてこれに含まれる。そのためのチャネルが型付きのリクエストポートである。リクエストがそこに到達するとワークフローは一時停止し、リクエストの詳細を含むイベントを発行する。外部システムはそれらのイベントを購読してレスポンスを作成し、それを返すと、フレームワークがリクエスト元のエグゼキューターへとルーティングする。同じ仕組みはフレームワークの C#、Python、Go の各インターフェースで提供されており、Python ではエグゼキューターが直接リクエストを発行し、レスポンスハンドラーを登録できる。フレームワークは受信したレスポンスを、そのハンドラーの型アノテーションと照合する。
ツールの承認は、別の仕組みを追加するのではなく、この仕組みを再利用している。組み込みのオーケストレーションのいずれかでエージェントを実行している場合、承認が必要とマークされたツールはワークフローを一時停止させて同じイベントを発行する。違いは、ペイロードが開発者の定義したリクエスト型ではなく承認リクエストである点のみである。ドキュメントはこの限界について明確に述べている。逐次、並行、グループチャットの各オーケストレーションは、それ自体では自由形式のユーザー入力のために停止しないため、ステップ間で対話を必要とするワークフローでは、カスタムワークフローの中でそれらをリクエストポートと組み合わせる必要がある。例外はハンドオフのオーケストレーションであり、これはデフォルトで対話的である。エージェントが別のエージェントにハンドオフせずに応答すると、次の入力のために制御がユーザーに戻る。
待機状態はチェックポイントを経ても失われない。保留中のリクエストはチェックポイントの状態の一部として保存され、復元時に再発行される。また、同じ呼び出しでレスポンスを渡しながらチェックポイントから実行を再開できるため、チェックポイントと再開 と未処理の承認を別々の関心事として扱う必要がない。
採用とエコシステム
このプロジェクトは、リポジトリ内で管理されるアーキテクチャ決定記録（ADR）を通じてオープンに開発を進めてもいる。コースで扱われていないフレームワークの部分を 2 つ目のソースが説明しているのも、そこである。
ここで参照した記録である ADR-0024 は、プロンプトインジェクション に対するラベルベースの情報フロー制御による防御である FIDES（Flow Integrity Deterministic Enforcement System）を提案している。そのステータスは承認済みではなく proposed（提案中）である。この記録はまた、記録同士の関係も示しており、自らの系譜として 2 つの先行する記録を挙げている。1 つは、この記録が基盤とするミドルウェアのパターンを確立したとされるエージェントフィルタリングミドルウェアの記録であり、もう 1 つは、ヒューマン・イン・ザ・ループのパターンについて参照しているとされるユーザー承認の記録である。これらの記録はいずれもここでは読んでいないため、上記は ADR-0024 がそれらをどう説明しているかにとどまる。
この記録がフレームワーク自体について付随的に記述しているのは、その拡張ポイントである。FunctionMiddleware 基底クラスがあり、これを通じてツール呼び出しの前後に振る舞いを挿入できる。そしてこの記録は、選択した案を採用した理由として、既存のそのパイプラインに非侵襲的に統合され、後方互換性を保ちながら、決定論的で形式的に検証可能な保証を与える唯一の選択肢であったことを挙げている。ラベルや類似のメタデータは、スキーマを変更することなく additional_properties フィールドを通じてコンテンツに付与でき、SerializationMixin がそれらを永続化する。
リモートの MCP 接続は、既存の拡張ポイントではなく提案に属するものである。この設計では、readOnlyHint や openWorldHint といった MCP の ToolAnnotations を独自のラベルに対応づけ、サーバーの _meta.ifc 結果メタデータを読み取ることで、ツール単位または URL 単位で行われる接続を保護する（Model Context Protocol を参照）。
このフレームワークはコースにおいて、ツール利用を実装するための Microsoft の 2 つの方法の 1 つとして登場し、もう 1 つは Microsoft Foundry Agent Service である。コースは Python と .NET の両方で実例のサンプルを提供している。
このフレームワークの由来は、4 つ目のソースが記録している。Jimmy Song のオンラインハンドブック『智能体构建指南』のある章は、Microsoft が 2025 年に AutoGen を Semantic Kernel と統合して Microsoft Agent Framework とした と述べており、これにより同社が 2 つのマルチエージェントフレームワークを並行して保守していた期間は終わった。この章はこの統合を、より広範な集約の兆しと読んでいる。すなわち、この分野が機能を競い合う段階から、実験的なプロジェクト間で移行を繰り返すのではなく、チームが依存してもよいと考える少数のプロジェクトへと収束する段階に移りつつあるということである。2026 年のエコシステムのまとめでは、Microsoft Agent Framework を Microsoft の統一されたマルチエージェントフレームワークであり、この統合の産物であるとして、LangGraph、OpenAI Agents SDK、CrewAI、OpenHands と並べて挙げている。ここで保持しているソースには、この統合において AutoGen や Semantic Kernel 自体の API がどうなったかについての記述はない。