最初の高額なエージェント実行は、ガバナンスの問題というよりも、請求の問題のように見えます。チームがメーターをオンにした後に最初のエージェント請求書を受け取り、実行をコスト順に並べ替えると、中央値の40倍のコストがかかる実行が見つかります。プロバイダーのメーターはトークンと合計を示し、アプリケーションログはリクエストが成功したことを示し、トレースビューアは整然としたリクエストとレスポンスを示します。どれも、この実行がなぜ長時間かかり、他の実行がクリーンに終了したのかを説明できません。
以前の記事「補助金の終焉：ツールを使用するエージェントの実際のコスト」で、私は使用量ベースの課金がエージェントを高価にしたのではなく、既存のコストを可視化しただけだと主張しました。請求書は大きくなったわけではなく、単に正直になっただけであり、正直な請求書はエンジニアリングの対象にできるものです。
しかし、可視化と帰属は同じではありません。ツールを使用するエージェントのコストを帰属させるには、そのコストを生み出した実行の内部を見る必要があります。その可視性を構築すると、コストは問題が最初に可視化される場所に過ぎないことに気づきます。コストの急上昇、安全でない委任、暴走アクションは異なる障害ですが、同じ欠落した層を露呈します。すなわち、コントロールプレーンは独立して観測できないループを統治できないということです。
請求書は正直ですが、説明されていません。請求書の数字は間違っていませんが、不完全です。プロバイダーの課金は何が消費されたかを教えてくれますが、通常はプラットフォーム内のどの設計選択が消費を引き起こしたかを教えてくれません。アプリケーションログは外部リクエストが成功したかどうかを教えてくれますが、エージェントがどのようにそこに到達したかを教えてくれないことがよくあります。そのため、チームは請求書について議論することになり、実際に必要なのは監査証跡です。
コントロールプレーンとは、個々のエージェントの上のプラットフォーム層であり、組織が可観測性を集中管理し、ポリシー、アクセス、予算、ルーティング、実行制約を適用する場所です。ほとんどの組織はすでにその層の一部を持っていますが、その下にある証拠層、つまりエージェントがターンごとに実際に行ったことのループ認識記録が欠けていることがよくあります。
コントロールプレーンはポリシー決定が存在する場所です。可観測性基盤はコントロールプレーンが読み取る証拠です。計装ポイントはエージェントが迂回できないランタイムの関門です。モデルゲートウェイ、ツールプロキシ、APIゲートウェイ、実行サンドボックス、ランタイムハーネス、ポリシーエンジンなどです。
多くの組織はアプリケーション境界を計装し、その後、実際の作業がループ内で行われるシステムをデプロイしました。結果は、意見はあるが証拠が不十分なコントロールプレーンです。
ループは観測の単位です。空のトレースの背後にある誤りは次の通りです。エージェントの可観測性は、しばしばアプリケーション可観測性の重いバージョンとして扱われますが、形状がまったく異なります。作業単位が変わり、計装が追従していません。従来のサービスはリクエストを処理してレスポンスを返します。リクエストは自然なトレース単位です。エージェントはリクエストを処理するというよりも、結果に向かって作業します。推論し、ツールを呼び出し、結果を読み、再び推論し、完了したと判断するか、境界に達するか、エスカレーションするまで続けます。単一のユーザー意図は、多くのモデル呼び出し、多くのツール呼び出し、ターンごとに変化するコンテキストウィンドウに広がる可能性があります。重要なシグナルは、これらのターン間の関係であり、個々のターンのタイミングだけではありません。
これから3つのことが導かれ、それぞれがアプリケーションモニタリングが静かに依存している仮定を破ります。第一に、コンテキストは蓄積する状態であり、固定されたペイロードではありません。各ターンは、以前のメッセージ、ツールの説明、取得されたファイル、中間結果、以前の決定を引き継ぐ可能性があります。その状態がターンごとに成長するのを観察できなければなりません。なぜなら、成長こそがコストとリスクの多くが存在する場所だからです。第二に、ツール呼び出しは第一級の決定であり、実装の詳細ではありません。モデルがどのツールを選択したか、どのパラメータを渡したか、結果の大きさ、ポリシーが呼び出しを制約したかどうかはすべてガバナンス記録の一部です。ルーティングの正確性とルーティングコストは、2つの方向から見た同じ監査です。第三に、すべての実行が独自のトレースツリーになる可能性があります。同じプロンプトが月曜日とは異なるパスを火曜日に取る可能性があるため、固定されたコールグラフとクリーンなサービスマップは、エージェントが持っていないかもしれない規則性を前提としています。観測単位が依然としてリクエストであれば、10,000回の成功した呼び出しを見て、本来3ターンで済むはずが15ターンも実行されたループに気づかないでしょう。
ループが単位であることを受け入れると、要件は具体的になります。エージェントの下でキャプチャされた少数の特定のシグナルが必要であり、実行ごとのビューア内だけでなく、フリート全体でクエリできる場所に保存する必要があります。私が大規模な医療機関で実施しているパイロットでは、この層を最初に構築しました。OpenTelemetry、Cloud Trace、データウェアハウス内の使用量ログテーブルを使用しています。特定のスタックは形状ほど重要ではなく、その形状はそのシナリオをはるかに超えて一般化できます。
各ユーザー意図は少なくとも1つの実行トレースを生成する必要があります。各ループターンは、スパンまたは安定したグループ化属性として表現されるべきです。モデル呼び出し、ツール実行、ポリシーチェック、リトライ、後処理は、そのターンの下の子スパンまたは構造化イベントであるべきです。正確な命名規則は、ループの因果構造を保持することほど重要ではありません。
シグナル コントロールプレーンがそれを必要とする理由 例フィールド 実行とターン構造 実行をフラットな呼び出しリストではなく因果ツリーとして読み取り可能にする run_id, turn_id, parent_span_id, timestamp トークンとモデル会計 コストをターン、モデル、ツールパスごとに説明可能にし、単に集計で可視化するだけではない model, input_tokens, output_tokens, cached_tokens ツール呼び出しイベント 委任決定を記録し、過大または繰り返しのツール結果を特定する tool_name, parameter_shape, result_bytes, row_count ガードレール決定イベント どの制御が発動し、アクションを許可、拒否、書き換え、制約、またはエスカレーションしたかを示す policy_id, policy_decision, reason_code, enforcement_point IDと権限コンテキスト 作業が誰の権限で実行されたか、その時点でどのデータスコープが適用されたかを再構築する principal_id, delegated_scope, service_account, data_scope 結果と境界メタデータ クリーンな完了とリトライ、境界ヒット、エスカレーション、ユーザー可視障害を区別する turn_count, stop_reason, loop_bound_hit, payload_cap_hit, outcome_status これらはどれもエキゾチックではなく、実際の設計作業は新しいテレメトリプリミティブを発明することではなく、カーディナリティ、保持、ペイロードキャプチャ、サンプリングポリシー、スキーマ進化、およびトレースデータ、使用量データ、IDデータ、ポリシーデータ間の結合を制御することです。
ストレージポイントはチームが過小評価する部分です。これらのシグナルがトレースビューアにのみ送られる場合、1つの実行を美しく検査できても、1000について推論することはできません。ガバナンスはフリートの問題であり、単一トレースの問題ではないため、基盤はクエリ可能でなければなりません。
また、データ最小化を念頭に置いて設計する必要があります。デフォルトでメタデータをキャプチャし、例外でコンテンツをキャプチャします。ツール呼び出しをキャプチャすることは、すべての生のプロンプト、完全な結果セット、資格情報、機密文書、または機密パラメータをトレースに保存することを意味しません。規制環境では、メタデータをペイロードから分離するパターンが有用です。ツール名、モデル、トークン数、ペイロードサイズ、行数、ポリシー決定、権限コンテキスト、リクエストID、および必要に応じて編集またはハッシュ化されたパラメータ値。目標は、実行がなぜそのように動作したかを再構築するのに十分な証拠を提供することであり、エージェントが見たすべての無制御アーカイブではありません。
最初の有用なバージョンには、完全なプロンプトキャプチャやセマンティック評価は必要ありません。run_id、turn_id、parent_span_id、timestamp、principal_id、delegated_scope、model、input_tokens、output_tokens、cached_tokens、tool_name、result_bytes、row_count、policy_id、policy_decision、stop_reason、loop_bound_hit、outcome_statusなどの列があれば、高価なループは謎ではなくなり、クエリになります。
正確な構文はウェアハウスによって異なりますが、ガバナンスの質問は人間が個々のトレースビューアをクリックすることなく表現できるべきです。
with runs as ( select run_id, count(distinct turn_id) as turns, sum(input_tokens + output_tokens) as total_tokens, max(result_bytes) as largest_tool_result, bool_or(loop_bound_hit) as hit_loop_bound, count_if(policy_decision = 'rewrite') as rewritten_actions from agent_turn_events where occurred_at >= current_date - interval '7 days' group by run_id ) select * from runs where turns > 10 or largest_tool_result > 10000000 or hit_loop_bound or rewritten_actions > 0;
これが、トレースを賞賛することとフリートを統治することの違いです。
古いトレースでは、冒頭の高価な実行は単に高価でした。ループ認識トレースでは、それは読み取り可能になります。ターン3で80,000行を取得し、ターン4でその結果を引き継ぎ、ターン5で高価なモデルを選択し、ターン6から11で同じツール呼び出しをわずかに異なるパラメータで再試行し、実行は最終的にクリーンに完了したのではなくループ境界に達したために停止しました。実行は謎から記録になります。
1つの基盤、3つのガバナンス問題。これを一度正しく構築する価値がある理由は、同じ基盤が業界でしばしば別々に扱われる3つのエージェントガバナンス問題、すなわちコスト管理、委任とアクセス制御、暴走アクション防止に答えるからです。これらは同じ障害ではありませんが、同じ種類の証拠を必要とします。
ガバナンス問題 コントロールプレーンが必要とする証拠 コスト ターン数、トークン数、モデル選択、コンテキスト成長、ツール結果サイズ、リトライ、停止理由 委任 プリンシパル、委任された権限、データスコープ、選択されたツール、アクションパラメータ、ポリシー決定 暴走アクション 繰り返しアクション、ループ境界、ペイロード上限、ガードレール決定、拒否または書き換えられたアクション、結果ステータス コストが最初の問題であり、各ターンのトークン会計により、実行がなぜ高価だったかをようやく答えられます。コストが、ターンが多すぎる、保持されたコンテキストが多すぎる、ツール結果が大きすぎる、間違ったステップに高価なモデルを使用した、または制限されるべきだったリトライループから来ているかどうかを確認できます。
委任とアクセスは2番目でより難しい問題です。マルチエージェントシステムでは、委任はセキュリティ境界です。エンタープライズは最終的に、特定のエージェントアクションを誰が承認したか、そのアクションが誰の権限で実行されたか、その時点でどのデータスコープが適用されたかを尋ねられます。その質問のための監査証跡は、各ターンにIDと権限を追加した同じトレースです。
暴走アクションは3番目です。破壊的な削除が戦争の話になる、エージェントがプロダクションテーブルを削除しようとした、同じ高価なスキャンを繰り返し発行したループは、事後分析にのみ存在すべきではありません。このモデルでは、ブロックされた破壊的ステートメントは拒否が付いたガードレール決定イベントであり、暴走スキャンはループ境界またはペイロード上限に達したトレースです。興味深いガバナンスシグナルは、決定論的制御が拒否した危険なアクションです。
3つの会話、1つの立ち位置。ループはガバナンスの単位です。なぜなら、ループはコストが蓄積され、権限が行使され、ツールが選択され、制御が発動し、結果が現れる場所だからです。
エージェントは自分自身の記録を保持できません。エージェント自体を計装し、エージェントに自身のトークン、権限、ブロックされたアクションをログさせるという誘惑的な近道があります。しかし、それは安全ではありません。なぜなら、エージェントが侵害された場合、記録を改ざんする可能性があるからです。より根本的には、ガバナンスがエージェント自身のログに依存する場合、独立して検証できないコンポーネントで監査していることになります。コントロールプレーンは、エージェントが介入できない層から証拠を読み取る必要があります。そのため、計装ポイントはランタイムの関門でなければなりません。
エージェントはその内部状態に関する有用なシグナルを提供できますが、ガバナンス層はエージェントをその記録の最終的な仲裁者として決して信頼すべきではありません。記録を統治されるエンティティに委ねることは、コントロールプレーンと監視対象を混同することです。