提案と検証

概要

ElevenAgents Architectが変更を完了すると、提案として渡されます。提案には、変更を保持するブランチ、変更が機能することを示すテスト、そのブランチをmainにマージするよう求めるマージ提案が含まれます。このページでは、各要素の仕組み、確認場所、会話からライブトラフィックへの反映までの流れを説明します。

提案とは

提案は、既存のバージョニングモデルに基づいて作成されます。

マージ提案は、チームメイトが手動で作成するものと同じ、標準のElevenAgentsマージ提案です。別のオブジェクトタイプではありません。

マージ提案の対象は、ソースブランチ1つとターゲットブランチ1つだけです。つまり、1つの提案には候補となるソリューションが1つ含まれます。代替案を比較するには、それぞれを別のブランチに作成するようArchitectに依頼してください。各ブランチに個別の提案が作成され、実験としてトラフィックを分割できます。

提案の作成方法

Architectは、何かの修正や改善を依頼したとき、または失敗したテスト、Spotlightの検出結果、課題を渡したときに提案を作成します。各ステップでArchitectが呼び出すツールを含む完全な流れは、実例を参照してください。概要は次のとおりです。

1. Architectが調査し、ブランチを作成して、そのブランチ上の下書きに変更をステージングします。
2. Architectが変更のテストとシミュレーションを作成し、結果を表示する前に会話内で実行します。
3. Architectが公開ダイアログを開きます。差分を確認して公開を選択すると、変更がブランチ上の新しいバージョンとしてコミットされます。
4. Architectがmainへのマージ提案を作成し、ブランチの実際のコミットとテスト実行に基づいて説明を記述します。
5. Architectが、提案をレビューしている間にライブトラフィックの一部をブランチへ送ることを提案します。これには承認が必要です。

どのステップで止めても構いません。公開済みバージョンはあるがマージ提案がないブランチも役立ちます。自分でテストしたり、後から提案を作成したりできます。

会話内での検証

Architectは、後から開始する別のステップとしてではなく、変更の作成過程でテストを作成・実行します。修正では、新しいテストが変更なしでは失敗し、変更ありでは成功することを示すのが有効なパターンです。Architectは、同じテストを元のブランチと変更を含む下書きの両方に対して実行できます。

Architectは、すべての変更に対してこの変更前後のチェックを自動実行するわけではありません。必要な場合は依頼してください。例：「新しいシミュレーションがmainでは失敗し、ブランチでは成功することを示してから、提案を作成してください。」

すべての成功条件を満たすと、テストは成功します。LLMテストでは、エージェントの応答が成功基準を満たしていることを意味します。ツール呼び出しテストでは、想定したツールが想定したパラメータで呼び出されます。シミュレーションでは、シミュレートされた会話が成功条件を満たします。不安定な結果がないか確認するには、Architectにテストを複数回実行するよう依頼してください。各テストは最大50回繰り返し、成功率を報告できます。

各テストタイプの定義については、テストを参照してください。

提案の確認場所

エージェントを開き、バージョン管理 > 提案に移動します。一覧は、ステータス、作成者（作成者）、レビュー担当者（レビュー待ち, レビュー済み）で絞り込めます。会話内でArchitectが作成した提案では、作成者としてユーザーが表示されます。

Architectは、作成後すぐに会話内で提案へのリンクも返します。

提案の構成

提案ページには、ソースブランチとターゲットブランチ、ステータス、マージ可能かどうか、ソースブランチがターゲットよりどれだけ遅れているか、または進んでいるかが表示されます。次のタブがあります。

レビューとマージ

ステータス

マージ提案には次のいずれかのステータスがあります。

提案がオープン中の場合、各レビュー担当者の最新レビューは承認済みまたは変更をリクエストのいずれかです。「テスト済み」や「レビュー準備完了」といった個別のステータスはありません。テスト結果は代わりにテスト実行タブに表示されます。

レビューとコメントは、ソースブランチにコミットされた各新しいバージョンとともに、概要タブのアクティビティタイムラインに表示されます。

承認とマージができるユーザー

• エージェントへの編集者アクセス権を持つユーザーは、作成者を除き、誰でも提案をレビューできます。Architectはユーザーとして動作するため、会話内でArchitectが作成した提案を承認することはできません。チームメイトによる承認が必要です。
• 作成者以外から少なくとも1件の承認があり、どのレビュー担当者の最新レビューも変更をリクエストではない場合、提案をマージできます。ワークスペース管理者は、承認なしでマージできます。
• 保護されたブランチへのマージには、管理者権限または管理者からの承認が必要です。

Architectは、マージ提案の承認、コメント、マージ、クローズを行えません。これらのステップは常に人が行います。完全なレビュールールは、マージ提案を参照してください。

マージ時の動作

マージ後に別途公開する必要はありません。マージするとターゲットブランチに新しいバージョンが作成され、そのバージョンはターゲットが受け取るトラフィックの割合に応じて、すぐにライブトラフィックを処理します。ターゲットがmainで、トラフィック分割が設定されていない場合は、すべての発信者が対象です。

マージすると、次のことも行われます。

• ソースブランチが受け取っていたライブトラフィックの割合をターゲットへ移動します。
• デフォルトでソースブランチをアーカイブします。
• 同じブランチから作成された他のオープン中の提案をすべてクローズします。
• リンクされた課題がある場合は解決します。

段階的ロールアウト

提案をマージする前に、ライブトラフィックの一部をそのブランチに送信し、実際の発信者に変更を利用してもらえます。

トラフィック割合の合計は常に100%である必要があり、ルーティングは会話ごとに決定的です。保護されたmainからトラフィックを移す場合を含め、保護されたブランチの割合を変更するには管理者が必要です。トラフィックデプロイを参照してください。

プロアクティブな提案

現在のプロアクティブなフローは、Spotlightと、その後の引き継ぎです。Spotlightはエージェントの会話を継続的に監視します。調査候補を含む週次サマリーを作成し、リアルタイムアラートを発生させ、設定変更を推奨します。Spotlightの検出結果を提案に変えるには、次の手順を実行します。

課題も同様に扱えます。ライブエージェントは会話中にレビュー用の課題をフラグ設定でき、課題のArchitectと相談を選択するとその調査が開始されます。

Architectの受信トレイにレポートを配信するスケジュール済み自動化は開発中です。Architectページの受信トレイタブは、そのためのプレースホルダーです。