標準ハーネスは、リクエストを処理するコンポーネント間でコンテキストを分散させます。 各コンポーネントは独自のコンテキストから動作し、ハーネスがトップレベルで自動的にコンテキストを調整するわけではありません。 この分離は柔軟性を提供しますが、独立したコンポーネントから明示的に情報が返されないと重複メッセージや回答漏れが生じる可能性があります。
この記事では、なぜコンテキストが分散されているのか、GitHub Copilotハーネスがどのように異なるのか、エージェントのオーケストレーション層とコンポーネント間でコンテキストがどのように移動するか、そして各コンポーネントが何を認識し何を返せるかを説明します。 この情報を活用して、コンテキストギャップを特定し、意図的にコンテキストを管理するエージェントを設計しましょう。
以下の図は、標準ハーネスにおけるオーケストレーション層、個々のコンポーネント、ユーザー間でコンテキストと通信がどのように流れるかを示しています。
Note
この記事では 、標準的なハーネスの特徴と挙動について説明します。 Access標準エージェントおよびエージェントフローで標準機能にアクセスする方法を学びましょう。
Copilot Studioで構築されたすべてのものはハーネスで動いており、選ばれたモデルが推論と生成を提供します。 ハーネスはこの二つの間に存在するランタイムで、いつモデルを呼び出すか、どのコンポーネントを送信するかを決定し、返ってくるものを解釈し、適切なツールを呼び出します。 Copilot Studioハーネスについて詳しく学びましょう。
なぜ標準ハーネスがコンテキストを分配するのか
標準ハーネスは柔軟性を重視して作られています:
- タスクのオーケストレーションやトランザクションユースケースのサポートを行います。
- 変数やトリガー、特殊な機能を通じて決定論的な制御とAIのバランスを取っています。
- トピック、知識、子エージェント、接続エージェント、ツールなどのコンポーネント間で制御を分散させます。
- 複数の認証、チャネル、統合オプションをサポートしています。
独立した構成要素間での作業分散は柔軟性を提供しますが、文脈に空白が生じる可能性があります。
- エージェントオーケストレーション層は、特定のコンポーネント呼び出し時に制御を渡します。
- コンポーネントが実行されている間、オーケストレーション層はそのコンポーネントがユーザーに送るメッセージを認識できません。
- オーケストレーション層はトップレベルでコンテキストを調整しません。
設計がエージェントのコンテキストを管理しなければ、ギャップが生じ、リクエストが応答されないまま現れることがあります。 これらのギャップは重複や誤答の原因となることがあります。
GitHub Copilot ハーネスがどのように異なるか
GitHub Copilotハーネスのオーケストレーション層は、ユーザーとの唯一のコミュニケーション手段となることで、コンテキストの不一致を回避します。 接続されたエージェントが通信を引き継ぐことは決して許しません:
- 推論とコミュニケーションのループは意図的な文脈管理なしで機能します。
- 接続されたエージェントメッセージは、親のAIレイヤーをあらゆる場面で通過します。
GitHub Copilotハーネスのオーケストレーション層はコンテキストサイズの扱いも異なり、標準ハーネスよりも桁違いにコンテキストサイズが大きいです。
- モデルのコンテキストに直接アクセスできます。
- 圧縮を使えます。
- Bashのサンドボックスコンテナにデータやファイルを書き込むことができます。
コンテキストがコンポーネントに伝達され、オーケストレーションレイヤーに戻る仕組み
標準ハーネスでコンテキストを効果的に管理するには、オーケストレーション層がコンポーネントに渡す内容とコンポーネントが返す内容の両方を考慮してください。
コンテキストはコンポーネントに2つの方法で伝達されます。
明示的な入力とリクエスト:オーケストレーション層は各コンポーネントのアクティブなコンテキストから入力を埋め、設計通りにリクエストを渡します。
暗黙的会話コンテキスト:オーケストレーション層は、明示的な設定なしに知識などのコンポーネントやサブエージェントにより長い会話コンテキストも渡します。 子エージェントは常に親会話のコンテキストを受け取ることに注意してください。 接続されたエージェントには、それを含めるか除外するかの設定があります。 ツールやフローは入力のみを受け取ります。
コンポーネントは情報をオーケストレーション層に2つの方法で返送します:
- 設計通りの明示的な出力と応答。
- 特定の構成要素からの暗黙の文脈。
コンポーネントがユーザーにだけ表示したり、自社の変数にしか残さないものは、その2つのチャネルのいずれかを経由しない限りオーケストレーションレイヤーに届かないことがあります。
暗黙の情報伝達は、重複または不回答のケースの約半数を引き起こします。なぜなら、コンポーネントが明示的に渡されたことのないリクエストに対応できるからです。
構成要素間で文脈の違い
ユーザーで見える会話とオーケストレーション層のコンテキストは重なりますが、同じものではありません。 以下の原則が、コンポーネント呼び出しからオーケストレーション層のコンテキストに到達するものに適用されます。
コンポーネントが自分に隠しているものは隠されたままです。 サブエージェント内のトピック変数や複数ターンの会話はコンポーネント内に存在します。 オーケストレーション層は、それらが出力として返された場合にのみそれらを認識します。
返ってくる情報は2種類だけです。 オーケストレーション層は、設計された明示的な出力とコンポーネントからの暗黙的なコンテキストを受け取ります。 動作はするものの何も返さないコンポーネントは、オーケストレーションレイヤーが何が起こったかを知らないままにしてしまうことがあります。
各コンポーネントには独自の文脈や視点があります。 オーケストレーションレイヤーはアクティブなコンテキストを使ってステップを選択し、入力を生成します。 接続されたエージェントは独自のオーケストレーション層、独自の命令、内部ツールや知識呼び出しを持っています。
以下の表を使って、具体的な質問を投げかけます: どの成分が能動的な文脈で特定の事実を持つのか?
| 視点 | アクティブなコンテキストに含まれる | チャットパネルに書き込みができます | コンテキストとして返すことができる |
|---|---|---|---|
| オーケストレーション レイヤー | ユーザーリクエスト、会話コンテキスト、コンポーネント記述、入力記述、出力記述、プラン状態、暗黙的応答(ただし暗黙的情報がユーザーに示されているかどうか は不明 ) | はい。 それ自体が問いと答えを生み出します。 | それ自体が問い、答え、論理、計画を用意している。 |
| トピック | トピック変数、現在のノード状態 | はい。 メッセージノード、質問ノード、そしてAskをAdaptive Cardで提供します。 | トピック出力や暗黙のメッセージ交換は重複を引き起こす可能性があります。 |
| ツールまたはフロー | オーケストレーション層によって生成される入力 | いいえ。 | ツールやフローの出力。 |
| 知識ステップ | ユーザーリクエストとエージェントのアクティブコンテキスト | いいえ。 チャットパネルではなく、自分のエージェントに書き込みます。 | それが答えです。 |
| 生成回答ノード(トピック内) | 入力として送信される内容と、そのエージェントのコンテキスト | はい。 直接、またはトピック変数に。 | 明示的にはなく、繰り返すことは可能です。 |
| サブエージェント(子エージェントまたは関連エージェント) | 最初の要求に加え、親から提供された入力や含まれる親コンテキストも、独自のオーケストレーションレイヤーコンテキスト内で共有されます | はい、設定や直接応答指示があれば可能です。 | 応答とその出力。 |
Important
トピック:トピックが返す暗黙の文脈にはプレーンテキスト情報のみが含まれ、ユーザーがそれを見たかどうかは含まれません。 プレーンテキスト情報は、メッセージノード、質問ノード、アダプティブカードの内容、ユーザーのタイプされた返信から得られます。 しかし、アダプティブカードのアクションボタンやそれに対するユーザーの操作は、標準的なハーネスの文脈には届きません。 アダプティブカード処理はほとんどのコンテキストミスマッチを引き起こします。 カードの内容だけを文脈として頼らないでください。 代わりに、後のステップでトピック出力として必要とする情報を返し、回答済み状態出力を設定します。 重複メッセージを避けるミニエージェントとしてのデザイントピックについて詳しく学びましょう。
サブエージェント:親コンテキストが接続されたエージェントに渡されると、エージェントが行うすべてのツール、トピック、知識コールに影響を与えます。 もし含まれたコンテキストに応答されていないように見えるリクエストが含まれている場合、接続されたエージェントは補償を試みて再度応答するかもしれません。 子ども代理人も同じリスクを負いますが、コントロールは少ないです。 親内部で動作し、常に親の会話コンテキストを受け取り、除外する設定はありません。 重複メッセージを避けるデザインサブエージェントについて詳しく学びましょう。
次のステップ
このコンテキストモデルを念頭に置き、このシリーズの次の記事では、なぜこのモデルが重複メッセージを引き起こすのかを説明し、それを防ぐための設計パターンを提案します。