提案と検証
提案と検証
ElevenAgents Architectによる変更をテスト、レビューし、本番トラフィックへロールアウトする方法。
概要
ElevenAgents Architectが変更を完了すると、その変更は提案として渡されます。提案には、変更内容を保持するブランチ、変更が機能することを示すテスト、そのブランチをmainにマージするよう求めるマージ提案が含まれます。このページでは、各要素の仕組み、見つける場所、提案が会話からライブトラフィックに至るまでの流れを説明します。
提案とは
提案は既存のバージョン管理モデルに基づいて構築されます。
マージ提案は、チームメイトが手動で作成するものと同じ、標準的なElevenAgentsのマージ提案です。別のオブジェクトタイプではありません。
マージ提案は、1つのソースブランチと1つのターゲットブランチを対象とするため、1つの提案には1つの候補ソリューションが含まれます。代替案を比較するには、それぞれを別々のブランチに置くようArchitectに依頼してください。各ブランチにはそれぞれ独自の提案が作成され、実験としてトラフィックを分割できます。
Architectはあなたとして動作するため、Architectが作成したマージ提案は作成者としてあなたの名前で記録されます。\n Architectが作成したことを記録するフィールドはありません。チームで把握する必要がある場合は、\n 提案の説明に記載してください。
提案の作成方法
問題の修正や改善をArchitectに依頼したとき、失敗したテスト、Spotlightの検出結果、またはトリアージチケットを渡したときに、Architectは提案を作成します。各ステップでArchitectが呼び出すツールを含む完全な手順は、実例を参照してください。概要は次のとおりです。
- Architectが調査し、ブランチを作成して、そのブランチ上のドラフトに変更をステージングします。
- Architectが変更用のテストとシミュレーションを作成し、結果を表示する前に会話内で実行します。
- Architectが公開ダイアログを開きます。差分を確認して公開を選択すると、変更がブランチ上の新しいバージョンとしてコミットされます。
- Architectが
mainへのマージ提案を作成し、ブランチの実際のコミットとテスト実行結果に基づいて説明を記載します。 - 提案のレビュー中に、少量のライブトラフィックをブランチへ送ることをArchitectが提案します。これには承認が必要です。
どの段階でも停止できます。公開済みバージョンがあってもマージ提案がないブランチは、引き続き利用できます。自分でテストすることも、後で提案を作成することもできます。
会話内での検証
Architectは、後から開始する別のステップとしてではなく、変更の作成過程でテストを記述・実行します。修正では、新しいテストが変更なしでは失敗し、変更ありでは成功することを示すのが有用なパターンです。Architectは、元のブランチと変更を含むドラフトの両方に対して同じテストを実行できます。
Architectは、すべての変更に対してこの変更前後のチェックを自動では実行しません。必要な場合に依頼してください。例：「新しいシミュレーションがmainでは失敗し、ブランチでは成功することを示してから、提案を作成してください。」
すべての成功条件を満たすと、テストは成功します。LLMテストでは、エージェントの応答が成功基準を満たします。ツール呼び出しテストでは、想定したツールが想定したパラメータで呼び出されます。シミュレーションでは、シミュレートされた会話が成功条件を満たします。不安定な結果を確認するには、Architectにテストを複数回実行するよう依頼してください。各テストは最大50回繰り返し、成功率を報告できます。
各テストタイプの定義については、テストを参照してください。
提案を見つける場所
エージェントを開き、Version Control > Proposalsに移動します。リストは、ステータス、作成者（Created by）、レビュアー（Awaiting review from、Reviewed by）でフィルタリングできます。会話内でArchitectが作成した提案は、作成者としてあなたの名前で表示されます。
Architectは、提案を作成するとすぐに、会話内でも提案へのリンクを返します。
提案の構成
提案ページには、ソースブランチとターゲットブランチ、ステータス、マージ可能かどうか、ソースブランチがターゲットよりどれだけ遅れているかまたは進んでいるかが表示されます。次のタブがあります。
概要
変更
テスト実行
会話
説明、ソースブランチ上のコミット・レビュー・コメントのアクティビティタイムライン、コメントボックスが表示されます。サイドバーには、レビュアー、推奨レビュアー、リンクされたトリアージチケットが表示されます。
Architectが作成する説明には、常に3つのセクションがあります。概要（重要な変更内容とその理由）、テスト（実行したテストと結果、またはテスト未実行である旨）、レビュー方法（注目すべき点、実行するテストまたは試す会話）。
レビューとマージ
ステータス
マージ提案のステータスは次のいずれかです。
提案がオープン中の場合、各レビュアーの最新レビューはApprovedまたはChanges requestedのいずれかです。「テスト済み」や「レビュー準備完了」といった個別のステータスはありません。テスト結果は代わりにTest runsタブに表示されます。
レビューとコメントは、ソースブランチにコミットされた各新しいバージョンとともに、Overviewタブのアクティビティタイムラインに表示されます。
承認とマージを実行できる人
- エージェントへの編集アクセスを持つ人は、作成者を除いて誰でも提案をレビューできます。Architectはあなたとして動作するため、会話内でArchitectが作成した提案をあなた自身は承認できません。チームメイトによる承認が必要です。
- 作成者以外から少なくとも1件の承認があり、どのレビュアーの最新レビューもChanges requestedではない場合、提案をマージできます。ワークスペース管理者は承認なしでマージできます。
- 保護されたブランチへのマージには、管理者権限、または管理者からの承認が必要です。
Architectは、マージ提案の承認、コメント、マージ、クローズを行えません。これらのステップは常に人が実行します。レビューに関する完全なルールは、マージ提案を参照してください。
Architectは、依頼され、かつロールにマージ権限がある場合、提案なしでブランチを直接マージできます。\n Approval requiredモードでは最初に確認を求めます。Auto-approveモードでは確認しません。\n すべての変更をレビュー済みの提案経由にする必要がある場合は、mainでブランチ保護を使用してください。
マージ時に起こること
マージ後に別途公開する必要はありません。マージによりターゲットブランチに新しいバージョンが書き込まれ、そのバージョンはターゲットが受け取るトラフィックの割合に応じて、すぐにライブトラフィックを処理します。ターゲットがmainで、トラフィック分割が設定されていない場合、すべての通話者が対象です。
マージでは、次のことも行われます。
- ソースブランチに割り当てられていたライブトラフィックの割合をターゲットに移します。
- デフォルトでソースブランチをアーカイブします。
- 同じブランチからの他のオープン中の提案をすべてクローズします。
- リンクされたトリアージチケットがある場合、それを解決します。
段階的なロールアウト
提案がマージされる前に、ライブトラフィックの一部をそのブランチへ送信して、実際の通話者に変更を利用してもらうことができます。
トラフィックの割合の合計は常に100%である必要があり、ルーティングは会話ごとに決定的です。保護されたmainからトラフィックを移す場合を含め、保護されたブランチの割合を変更するには管理者が必要です。トラフィックのデプロイを参照してください。
プロアクティブな提案
Architectは、依頼されたとき、または失敗したテスト、Spotlightの検出結果、アラート、トリアージチケットを\n 渡されたときに提案を作成します。まだスケジュールに従ってエージェントをスキャンしたり、\n 自ら提案を作成したりはしません。
現在のプロアクティブな流れは、Spotlightとその後の引き継ぎです。Spotlightはエージェントの会話を継続的に監視します。調査候補を含む週次サマリーを作成し、リアルタイムアラートを発生させ、設定変更を推奨します。Spotlightの検出結果を提案に変えるには、次の手順に従います。
トリアージチケットも同様に機能します。ライブエージェントは会話中に問題をレビュー用にフラグ付けでき、チケット上のDiscuss with Architectを選択すると、そのチケットの調査が開始されます。
Architectの受信トレイにレポートを配信するスケジュール済み自動化は開発中です。ArchitectページのInboxタブは、そのためのプレースホルダーです。