Microsoft Agent Framework、オーケストレーションパターンがバージョン1.0に到達
本文の状態
日本語全文を表示中
詳細モードで約5分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Microsoft Agent Framework
Microsoft は Python と .NET の両方の SDK で Agent Framework のオーケストレーション層をバージョン 1.0 に到達させ、主要な協調パターンを安定版として提供した。
AI深層分析を開く2026年8月4日 17:28
AI深層分析
キーポイント
マルチプラットフォームでの 1.0 リリース
Microsoft は Python と .NET の両方の SDK で Agent Framework のオーケストレーション層をバージョン 1.0 に到達させ、主要な協調パターンを安定版として提供した。
安定化された協調パターンの一覧
シークエンシャル、並行実行、グループチャット、ハンドオフ、そして Magentic といったオーケストレーションパターンがすべて安定版となり、開発者は問題に合わせて自由に選択できる。
Magentic パターンの自動化機能
Magentic は管理者エージェントがタスクを計画し、専門家に作業を割り当て、進捗を検証して計画を見直すことで、手動でのグラフ配線なしに複雑な協調を実現する。
ワークフロー層とオーケストレーション層の統合
低レベルのプリミティブ(エグゼキュータやエッジ)の上に位置するオーケストレーションビルダーが同じモデルを使用し、実行・ストリーミング・合成可能な通常のワークフローを返す。
多様なオーケストレーションパターンの提供
Magentic 以外に、Handoff、Group chat、Sequential、Concurrent など複数のパターンが Python と .NET で安定して利用可能になった。
重要な引用
Sequential, concurrent, group chat, handoff, and magentic orchestration are now stable in both SDKs.
Magentic is the least hand-wired pattern: you give it a goal, a manager, and a set of specialists, then the manager decides how the team should work.
That matters because coordination is the part many multi-agent apps otherwise reimplement.
All of those orchestration patterns now have the same stable footing in Python and .NET.
編集コメントを表示
編集コメント
Agent Framework のオーケストレーション層が 1.0 に到達したことは、マルチエージェント開発の標準化に向けた大きな一歩である。特に Magentic パターンの安定版公開は、複雑な協調ロジックを簡素化する実用的なツールとして期待される。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Python 向けの「agent-framework-orchestrations」パッケージがバージョン 1.0.0 に到達しました。これにより、Microsoft Agent Framework のオーケストレーション層は、Python と .NET の両方で正式に 1.0 を達成したことになります。
シークエンシャル(順次)、コンカレント(並行)、グループチャット、ハンドオフ、そしてマグネティックなオーケストレーションが、両 SDK で安定版として利用可能になりました。これにより、SDK の成熟度に合わせて妥協するのではなく、自らの課題に最適な調整パターンを選べるようになりました。
この重要性を最もよく示しているのが「Magentic」です。これは最も手動配線が少ないパターンで、目標とマネージャー、そして専門家のセットを与えるだけで、マネージャーがチームの連携方法を決定します。
ワークフロー層では、Agent Framework を使って自分でグラフを構築できます。エグゼキューターが作業を実行し、エッジがメッセージをルーティングし、実行中にイベントを発行します。これらが低レベルなプリミティブです。詳細はワークフローのドキュメントをご覧ください。
オーケストレーションビルダーは、これらのプリミティブの上に位置するレイヤーです。内部では同じワークフローモデルを使用しつつ、実行・ストリーミング・合成が可能な通常のワークフローを返します。
これが重要なのは、調整機能こそがマルチエージェントアプリで他社が再実装しがちな部分だからです。次のエージェントの選択、ターン間の状態保持、スタック検出、作業完了の判断など、多くの処理が含まれます。
Magentic はこうした調整機能をオーケストレーションに集約します。マネージャーエージェントがタスクを計画に変換し、専門家に作業を割り当て、各ラウンドごとに進捗を確認し、チームが進まなくなった際には計画を見直します。
以下のコードは、MagenticBuilder を使用して手動でグラフを接続することなくワークフローを作成する例です。参加者やガードレールは依然として自分で選択しますが、ラウンドごとの調整はマネージャーが担当します。
import os
from agent_framework import Agent, AgentResponseUpdate
from agent_framework.foundry import FoundryChatClient
from agent_framework.orchestrations import MagenticBuilder
from azure.identity import AzureCliCredential
client = FoundryChatClient(
project_endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
model=os.environ["FOUNDRY_MODEL"],
credential=AzureCliCredential(),
)
researcher = Agent(
name="Researcher",
description="Finds and gathers information",
instructions="You research. You do not do quantitative analysis.",
client=client,
)
coder = Agent(
name="Coder",
description="Writes and runs code to analyze data",
instructions="You answer quantitative questions by writing and running code.",
client=client,
tools=client.get_code_interpreter_tool(),
)
manager = Agent(
name="Manager",
description="Coordinates the team",
instructions="You coordinate the team to finish complex tasks.",
client=client,
)
workflow = MagenticBuilder(
participants=[researcher, coder],
manager_agent=manager,
max_round_count=10,
max_stall_count=3,
max_reset_count=2,
).build()
task = (
"Compare the training and inference energy use of ResNet-50, BERT-base, "
"and GPT-2, estimate the CO2 for each, and recommend the most efficient "
"model per task type."
)
async for event in workflow.run(task, stream=True):
if event.type == "output" and isinstance(event.data, AgentResponseUpdate):
print(event.data.text)
マネージャーはタスクを読み込み、まず研究者に数値の取得を指示し、コード担当者に計算を任せます。各ラウンドごとに進捗台帳を確認し、最終回答を統合します。
チームが進歩を見せなくなった場合、マネージャーはリセットして再計画を行うことができます。max_* 値はあなたが設定したガードレールです。ゴールと回答の間にあるすべての判断は、マネージャーの裁量に委ねられます。
Magentic を超えて
Magentic は最も鋭い例の一つですが、今回のリリースはそれだけではありません。Handoff(ハンドオフ)機能ではルーティングされた専門チームを構築でき、Group chat(グループチャット)機能では調整された共同作業が可能です。Sequential(順次)とConcurrent(並行)は、パイプラインやファンアウト/ファンインのワークフローに対応しています。
これらのオーケストレーションパターンすべてが、Python と .NET で同じ安定した基盤を持つようになりました。これは、サービス間、チーム間、あるいは言語間でエージェントの動作を標準化する際に重要です。
ビルダーがワークフローを生成する一方で、低レベルな API を閉ざすわけではありません。
チームに異なる形状が必要であれば、必要な部品を取り出して、同じプリミティブからカスタムワークフローを構築できます。
手動配線されたパイプラインには任せられないタスクで Magentic を試してみてください。ルーティングルールが重要な場合は Handoff を、ワークフローを決定論的に保つ必要がある場合は Sequential または Concurrent を試してください。
その後、これらのパターンがどこに適合し、どこで破綻するか、何がまだ難しすぎると感じられるかをお知らせください。不足しているものや驚くべき点があれば GitHub で issue を開いてください。そのフィードバックが今後の開発を形作ります。
magentic のオーケストレーションドキュメントで始めましょう。
GitHub に掲載されている完全なサンプルには、その他のオーケストレーションパターンも含まれています。
「Agent Framework のオーケストレーションパターンが 1.0 に到達」という記事は、Microsoft Agent Framework で最初に公開されました。
原文を表示
Python’s agent-framework-orchestrations package is now 1.0.0. That puts Microsoft Agent Framework’s orchestration layer at 1.0 across Python and .NET.
Sequential, concurrent, group chat, handoff, and magentic orchestration are now stable in both SDKs. You can pick the coordination pattern that fits your problem instead of choosing around SDK maturity.
Magentic is the best example of why that matters. It is the least hand-wired pattern: you give it a goal, a manager, and a set of specialists, then the manager decides how the team should work.
At the workflow layer, Agent Framework lets you build the graph yourself. Executors do the work, edges route messages, and the workflow emits events as it runs. Those are the low-level primitives. The workflow docs cover that model in more depth.
The orchestration builders sit one level above those primitives. They use the same workflow model internally and return ordinary workflows you can run, stream, and compose.
That matters because coordination is the part many multi-agent apps otherwise reimplement. You choose the next agent, carry state between turns, detect stalls, and decide when the work is finished.
Magentic moves that coordination into the orchestration. A manager agent turns the task into a plan, assigns work to specialists, checks progress after each round, and revises the plan when the team stops moving.
The code below uses MagenticBuilder to create a workflow without wiring that graph by hand. You still choose the participants and guardrails, but the manager owns the round-by-round coordination.
import os
from agent_framework import Agent, AgentResponseUpdate
from agent_framework.foundry import FoundryChatClient
from agent_framework.orchestrations import MagenticBuilder
from azure.identity import AzureCliCredential
client = FoundryChatClient(
project_endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
model=os.environ["FOUNDRY_MODEL"],
credential=AzureCliCredential(),
)
researcher = Agent(
name="Researcher",
description="Finds and gathers information",
instructions="You research. You do not do quantitative analysis.",
client=client,
)
coder = Agent(
name="Coder",
description="Writes and runs code to analyze data",
instructions="You answer quantitative questions by writing and running code.",
client=client,
tools=client.get_code_interpreter_tool(),
)
manager = Agent(
name="Manager",
description="Coordinates the team",
instructions="You coordinate the team to finish complex tasks.",
client=client,
)
workflow = MagenticBuilder(
participants=[researcher, coder],
manager_agent=manager,
max_round_count=10,
max_stall_count=3,
max_reset_count=2,
).build()
task = (
"Compare the training and inference energy use of ResNet-50, BERT-base, "
"and GPT-2, estimate the CO2 for each, and recommend the most efficient "
"model per task type."
)
async for event in workflow.run(task, stream=True):
if event.type == "output" and isinstance(event.data, AgentResponseUpdate):
print(event.data.text)
The manager reads the task, decides the researcher should pull numbers first, hands the coder the math, checks a progress ledger each round, and synthesizes the final answer.
If the team stops making progress, the manager can reset and replan. The max_* values are the guardrails you set. Everything between the goal and the answer is the manager’s call.
More than magentic
Magentic is the sharpest example, but the release is broader. Handoff gives you routed specialist teams. Group chat gives you moderated collaboration. Sequential and concurrent cover pipelines and fan-out/fan-in work.
All of those orchestration patterns now have the same stable footing in Python and .NET. That matters when you are standardizing how agents work across services, teams, or languages.
Because the builders produce workflows, they do not close off the lower-level APIs.
If your team needs a different shape, take the parts that fit and build a custom workflow from the same primitives.
Try magentic on a task you would not trust to a hand-wired pipeline. Try handoff when the routing rules matter. Try sequential or concurrent when the workflow should stay deterministic.
Then tell us where the patterns fit, where they break, and what still feels too hard. Open an issue on GitHub when something is missing or surprising; that feedback shapes what comes next.
Get started with the magentic orchestration docs.
The full samples on GitHub show the other orchestration patterns too.
The post Agent Framework’s Orchestration Patterns Reach 1.0 appeared first on Microsoft Agent Framework.
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み