要旨
自動修復は失敗の圧力によって引き起こされるため、自動実装よりも危険です。実稼働システムの機能が低下すると、エージェントには、ローカル エラーを解消する最速の変更を加えようという強い動機が働きます。ハーネスがなければ、その局所的な修復により、システムを安全にするまさにその制約が取り除かれる可能性があります。その結果、自己修復が進み、ガバナンスがゆっくりと侵食されます。
自律型修復ハーネスは、あらゆる障害を構造化された修復エピソードに変えることでこの問題を解決します。ハーネスは障害をキャプチャし、ドリフトを分類し、修復ルートを選択し、限定された変更を作成し、影響を受けるエピソードを再生し、爆発範囲を推定し、ロールバックを添付し、提案を承認までルーティングします。修復は許可されていますが、憲法の自己編集は許可されていません。
1. 失敗はノイズではなくデータです
従来の運用では、障害は中断として扱われることがよくあります。エージェント システムでは、障害は期待される動作と実際の実行時の動作との境界を明らかにするため、最も価値のあるトレーニング データです。ツール呼び出しの失敗、証拠バンドルの不足、安全でないエスカレーション、または信頼性の低い回答は、単なるインシデントではありません。これは、システム位相空間内の新しい座標です。
したがって、修理ハーネスは障害を第一級のエピソードとして記録します。各エピソードには、入力コンテキスト、メモリ スナップショット、ツール トレース、ゲート トレース、出力、スコア ベクトル、ユーザーへの影響、権限分類が含まれます。障害が捕捉されるまで修復は開始できません。
2. ドリフト分類法
修理の品質は分類の品質によって決まります。入力ドリフト、ツール ドリフト、メモリ ドリフト、ポリシー ドリフト、スコア ドリフト、権限ドリフトの 6 つのトップレベル クラスによるドリフト分類法を使用します。入力ドリフトは、世界が新しい形のリクエストを提示したことを意味します。ツールのドリフトは、外部依存関係が変更されたことを意味します。メモリ ドリフトは、エージェントが古いコンテキストまたは間違ったコンテキストを使用したことを意味します。ポリシーのドリフトは、統治ルールが現実と一致しなくなったことを意味します。スコア ドリフトは、ハーネス メトリックが望ましい動作を捕捉できなくなったことを意味します。権限ドリフトとは、システムの自律性が多すぎる、または少なすぎることを意味します。
権限ドリフトは最も敏感なクラスです。修復には誰が修復するかを決定するルールの変更が必要になる場合があるため、自動的に修復することはほとんどありません。それは憲法上の境界線です。
3. 4つの修理ルート
ハーネスは 4 つの修理ルートから選択します。再実行は、障害が一時的なもので、アーティファクトを変更する必要がない場合に使用されます。構成パッチは、タイムアウト、しきい値、ルーティング、または機能フラグによってコードを変更せずに問題を解決できる場合に使用されます。コード パッチは、ツール ロジック、ワークフロー コード、または UI 動作を変更する必要がある場合に使用されます。人的エスカレーションは、失敗が権限、法的リスク、取り消し不能な措置、データ境界、またはポリシー解釈に関わる場合に使用されます。
type RepairRoute =
| { kind: "rerun"; reason: string }
| { kind: "config_patch"; keys: string[]; rollback: string }
| { kind: "code_patch"; files: string[]; tests: string[]; rollback: string }
| { kind: "human_escalation"; gate: string; rationale: string }ルートは開発者の好みによって選択されていません。証拠によって選ばれます。エピソードに動作の変動がない外部 API タイムアウトが示されている場合は、再実行または構成パッチが適切です。ゲート ロジックの欠落によってエピソードに誤った決定が示されている場合は、コード パッチまたは人間によるエスカレーションが必要です。エージェントが承認を回避したことがエピソードで示されている場合は、自動修復を停止してエスカレーションする必要があります。
4. 修理提案体制
修理提案はレビュー可能でなければなりません。これには、失敗したエピソード、診断、提案された差分、予想されるスコアの変化、実行するテスト、ロールバック エンベロープ、爆発半径の推定、および承認ルートが含まれます。修理業者を信頼していなくても理解できる提案でなければなりません。
自律的な修復は自己正当化されやすいため、これは重要です。エージェントは、制約を弱めたという事実を隠しながら、そのパッチがなぜ役立つかを説明できます。ハーネスは、リプレイ証拠と明示的な境界分類を要求することでこれに対抗します。
5. ロールバックファーストの設計
すべての修復は、適用するよりも元に戻す方が簡単でなければなりません。これは便宜的なものではありません。それは安全性の不変条件です。ロールバックのないパッチは修復ではありません。それは突然変異です。ハーネスは、逆転経路を説明できない修理提案を拒否する必要があります。
ロールバックファーストの設計には、構成スナップショット、以前のアーティファクト ハッシュ、移行反転計画、機能フラグの分離、カナリア ロールアウト、ロールバック前後のエピソード リプレイが含まれます。リスクの高い表面の場合、修復はゲートの後ろで展開され、レビューによって促進されない限り期限切れになる必要があります。
6. 自動修復と社内開発
自動修復は内部の自動実装に直接接続されます。実装ループは目的の機能を構築します。実行時の証拠によって欠陥が明らかになった後、修復ループによって機能が改善されます。どちらも同じハーネス オブジェクト (インテント、座標、シナリオ、スコア、ゲート、差分、承認ルート、ロールバック) を使用します。
違いは感情的なプレッシャーです。実装は製品へのプレッシャーの下で行われます。修理は失敗のプレッシャーの下で行われます。システムは安全性を優先して回復速度を犠牲にする傾向にあるため、修理中はハーネスをより厳密にする必要があります。
7. 修復不可能な体質
修復エージェントは、自身の修復権限を定義するルールを変更できてはなりません。そのような変更を提案することはできますが、適用することはできません。この構成には、承認ポリシー、ゲート定義、テナント境界、スキーマ移行ポリシー、プロンプト コア ポリシー、実稼働展開ポリシー、および監査保持ルールが含まれます。
この境界により、自律修復とガバナンスを両立させることができます。それがなければ、修復は再帰的な自己許可になります。
8. 研究課題
研究課題には 3 つの側面があります。まず、因果関係を修復します。つまり、目に見える症状から根本原因を区別します。次に、修復の最小化です。隣接するシナリオを劣化させることなくエピソードを修正する最小のパッチを見つけます。 3 番目に、信頼性の修復: 証拠が自動パッチ適用に十分である場合と、不確実性が増大する必要がある場合を決定します。
有用なベンチマークは、修復の後悔です。修復では、元のエピソードは修正されるものの、より深刻な下流障害が発生する場合、後悔が伴います。ハーネスは、時間をかけて後悔を追跡し、全体的なリスクを増大させながら局所的に最適化する修復戦略にペナルティを与える必要があります。
結論
自律修復は機能の切り替えではありません。それはガバナンスシステムです。ダイナミック ハーネスは、障害をエピソードに、エピソードを提案に、提案をリプレイ証拠に、リプレイ証拠を承認ルートのパッチに変換することで、修理を安全にします。これにより、エージェントが自己修復を安全に保つ境界を書き換えることを許可せずに、MARIA OS が自己修復に向けて移行できるようになります。