ナビゲーションにスキップ

ElevenAgents Architectの仕組み

会話開始時にElevenAgents Architectが把握している情報、調査の方法、質問を検証済みの変更に変える仕組み。

概要

ElevenAgents Architectとの会話は、構築したエージェントを支えるものと同じエンジン上で動作する、リアルタイムのElevenAgents会話です。Architectのツールは、サインイン中のセッションでブラウザ内で実行されます。各ツールはダッシュボードと同じElevenAgents APIを呼び出すため、すべての読み取りと書き込みは自身の権限に照らして確認されます。権限、承認、下書きを参照してください。

ElevenAgents Architectがデフォルトで把握している情報

各会話の開始時に、Architectは以下を受け取ります。

  • アカウントとワークスペース:プラン、ワークスペース、使用状況。
  • 現在地:開いているページと、エージェント内にいる場合はそのエージェントおよび開いているブランチ。サイドバーでは、Architectはページのスナップショットも受け取り、ページが変更された場合は各メッセージの前に更新を受け取ります。
  • エージェントの概要:エージェント内にいるときにElevenLabsが作成します。エージェント名とオーナー、ブランチとトラフィック分割、過去7日間の通話量、下書きの状態、接続されているエージェント、プロシージャ、テストが設定されているか、編集できるブランチが含まれます。
  • エージェントコンテキスト:エージェントを構築する全員で共有する、エージェントのagents.mdドキュメント。Architectのカスタマイズを参照してください。
  • 設定:構築するすべてのエージェントに適用される、個人用のuser.mdドキュメント。
  • 起点から渡された情報:たとえば、失敗したテスト、Spotlightの検出事項、課題です。会話を開始するを参照してください。
  • このチャット内の以前のメッセージ。

Architectは、エージェントの完全な設定、文字起こし、テスト結果、Spotlightデータ、または他のArchitectチャットを最初から保持しているわけではありません。タスクで必要になった際にツールでこれらを読み取ります。これにより各会話の焦点が保たれ、Architectは古いコピーではなく常に最新のデータに基づいて作業できます。

調査と直接指示

Architectは、2種類のリクエストを異なる方法で処理します。

直接指示では、たとえば「競合他社の価格に関する議論をブロックするガードレールを追加して」や「最初のメッセージを短くして」のように、変更内容を指定します。Architectは関連する設定を読み取り、編集を行い、ステージングした内容を報告します。デフォルトの承認モードでは、エージェント設定への編集は確認なしで下書きにステージングされます。ライブトラフィックや共有リソースに影響する操作は、承認されるまで待機します。

調査では、たとえば「返金の通話がエスカレーションされるのはなぜ?」や「返金解決率を改善するには?」のように、修正方法を指定せずに質問します。Architectは、何かを変更する前に調査します。

  • 調査用のtodoリストを作成し、項目が完了するとコンポーザーの上に表示され続けます。
  • 個々の文字起こしを読む前に、会話数、トピック、評価結果など、コストの低いシグナルから始めます。
  • 会話を並行して分析し、検出内容を根本原因ごとにグループ化します。
  • 推論は表示されます。各推論ステップはThought for Nsとして折りたたまれ、展開できます。
  • 実際に読んだ会話数を含め、検出内容を報告します。サンプルを網羅的な結果として提示することはありません。

プランモード

より大規模な変更では、コンポーザーをPlanに切り替えてください(Shift+Tabでモードを切り替えます)。プランモードでは、Architectは読み取り専用ツールで調査し、作成過程を確認できるプランを書き、Approve planまたはRejectを求めます。承認するまで変更は行いません。メモを添えてプランを却下すると、Architectは修正して再度確認を求めます。

フルスクリーンのArchitectタブでは、プランはコンポーザーの上のパネルに表示されます。サイドバーでは、チャット内のカードとして表示されます。

実例:返金解決率の改善

この例では、幅広い質問からレビュー可能な変更に至るまで、1つの会話を追います。各ステップを会話内に表示される内容と対応付けられるよう、ツール名を示しています。Architectは独自に手順を選択するため、実際の会話では順序や詳細が異なる場合があります。

エージェントのArchitectタブから送信されたリクエスト:

返金解決率を改善するには?

1

調査を計画する

Architectはtodoリスト(write_todos)を作成します。問題の測定、失敗した返金会話の特定、 根本原因の特定、修正の提案とテストを行います。

2

問題を測定する

Architectはエージェントのトピック(get_agent_topics、get_topics_summary)を読み取り、返金 トピックとその成功率を見つけます。次に、評価に失敗した最近の返金会話をカウントして一覧表示します (count_conversations、list_conversations)。

3

会話を読む

Architectは返金リクエストを文字起こしから検索し(search_conversation_messages、 semantic_search_conversations)、失敗した会話のバッチを並行して分析します (analyze_conversation_subagent)。各分析では、ユーザーの目的、エージェントが誤った箇所、 それが発生したターンを報告します。

4

根本原因を見つける

Architectは失敗例を現在の設定(get_agent_config、 list_procedures、get_procedure)と比較します。たとえば次のような検出結果を報告します。「失敗した返金 通話40件のうち31件で、エージェントは注文番号を聞く前にlookup_orderを呼び出し、エラーとなって エスカレーションしました。」

5

ブランチで変更する

Architectはブランチ(create_branch)を作成し、ライブエージェントから変更を分離します。次に、 参照の前に注文番号を聞くよう、返金プロシージャ(update_procedure)を編集します。この編集はその ブランチの下書きにステージングされます。ライブの発信者には何も変更されません。

6

変更のテストを書く

Architectは、失敗を再現するテストを作成します。注文番号を伝えずに返金を求める発信者のシミュレーション (create_simulation_test)、lookup_orderが最初に呼び出されないことを確認するツール呼び出しテスト (create_tool_test)、実際に失敗した会話の1つから生成したテスト (generate_test_from_conversation)です。Architectはシミュレーションで副作用のあるツールをモックするため、 実際の返金は実行されません。

7

変更前後でテストを実行する

Architectは変更前のエージェントに対してテストを実行し(元のブランチでrun_tests、または include_draft: falseを指定したrun_agent_tests)、その後、変更を含む下書きに対しても実行して (run_agent_tests)、結果を読み取ります(get_test_suite_summary、 get_test_suite_failures)。期待される結果は、新しいテストが変更前には失敗し、変更後には 成功することです。テストがまだ失敗する場合、Architectは失敗内容を読み取り、変更を調整して、 再度実行します。

8

変更を提示する

Architectは根本原因、変更内容、テスト結果を要約し、公開ダイアログを開きます (request_draft_publish)。差分を確認してPublishを選択すると、変更はブランチ上の新しいバージョンとして コミットされます。Architectが代わりに公開することはできません。

9

提案を作成する

Architectはブランチの履歴とマージプレビュー(get_branch_history、 merge_branch_preview)を読み取り、mainへのマージ提案を作成します(create_merge_proposal)。 説明には、実際のコミットとテスト実行に基づくSummary、Testing、How to reviewの 3つのセクションが含まれます。Architectはレビュー担当者を提案できます (suggest_merge_proposal_reviewers)が、選択するのはあなたです。

10

段階的ロールアウトを提案する

Architectは、提案のレビュー中にライブトラフィックの一部(通常5%)をブランチへ送ることを提案します (set_traffic_split)。これはライブトラフィックを変更するため、承認されるまで待機します。

検証は、公開またはレビューを求められる前に、会話内で行われます。提案がレビュアーに届く時点で、変更の動機となったテストはすでにエージェントに添付され、ブランチで実行済みです。レビュアーに表示される内容については、提案と検証を参照してください。

変更前後のテスト実行は推奨される方法ですが、Architectがすべての変更で自動実行するわけではありません。 確実に実行するには、たとえば「新しいテストがmainでは失敗し、ブランチでは成功することを見せて」のように、 直接依頼してください。

Architectの作業トレース

Architectが実行した各ツール呼び出しを含む、リクエストの作業トレース

スラッシュコマンド

コンポーザーで/を入力すると、現在のページで利用できるコマンドが表示されます。

コマンド内容
/startArchitectが目標を把握できるよう、このエージェントのコンテキスト(agents.md)を設定します。
/generate説明から新しいエージェントを生成します。
/debug最近失敗した会話をデバッグします。
/testテストを実行して結果を要約します。
/explainこのエージェントが何をするかをわかりやすく説明します。
/optimizeプロンプトと設定の改善を提案します。
/reviewエージェントのパフォーマンスをレビューし、改善点を見つけます。
/branchこのエージェント用の新しいブランチを作成します。
/experimentブランチを作成し、A/Bテストとしてデプロイします。
/rollback最近の設定変更をレビューし、必要に応じて元に戻します。
/rememberエージェントの情報をナレッジベースドキュメントとして保存します。
/dashboardチャット内にカスタム分析ダッシュボードを構築します。
/clearこの会話を消去して、新しく開始します。
/feedbackこのセッションに関する非公開フィードバックをElevenLabsに送信します。

ほとんどのコマンドは、エージェント内にいる場合にのみ適用されます。/clearと/feedbackは、Architectタブのホームページでは利用できません。

チャット内のダッシュボード

Architectは会話内にダッシュボードを構築し、たとえば「今週のエスカレーションを理由別に分解して、傾向を表示して」のようなデータに関する質問に答えられます。/dashboardを使うか、直接依頼してください。

Architectはツールでデータを収集し、コードで整形して、Spotlightと同じメトリックタイル、チャート、リスト、テキストカードで構成されるダッシュボードを表示します。ダッシュボードには以下を含められます。

  • 見出しの値、変化、スパークラインを備えたメトリックタイル。
  • チャート:エリア、折れ線、棒、積み上げエリア、ドーナツ、上位N項目の内訳用のランキング棒グラフ。
  • ステータスラベル、日付、個別の会話などElevenAgents内のページへのリンクを含むリスト。
  • 検出事項と推奨事項のためのテキストカード。

フルスクリーンのArchitectタブでは、ダッシュボードは会話内にインラインで表示されます。サイドバーでは、チャットの横にあるパネルで開きます。

ダッシュボードデータは、構築されたブラウザタブのメモリ内にのみ保持され、チャットとともに保存されることはありません。ページを再読み込みした場合、別のタブでチャットを開いた場合、または複数の大きなダッシュボードを構築した場合、古いダッシュボードにはデータの代わりにメッセージが表示されます。Architectに再構築を依頼してください。ダッシュボードは読み取り専用のスナップショットです。フィルターはなく、ライブ更新もされません。

コードの実行

Architectはツールからのデータをカウント、グループ化、比較するために、短いPythonプログラムを実行できます。たとえば数百件の会話にわたる週別の解決率を計算できます。コードはブラウザ内のサンドボックスで、Python標準ライブラリのみを使用して実行されます。ネットワークアクセス、ElevenLabsアカウントへのアクセスはなく、制限時間は20秒です。コード実行は段階的に展開されており、すべてのワークスペースで利用できるとは限りません。

大きなレスポンス

長い会話リストなど、ツールが会話に収まりきらない量のデータを返した場合、Architectはブラウザタブのメモリ内に完全なレスポンスを保持し、要約を使用して作業します。必要に応じて残りを検索し、読み取ることができます。この場合、ツール呼び出し上の通知に表示されます。これらのレスポンスが保存またはアップロードされることはありません。