要旨
第一世代の AI ハーネスは、出力が合格したかどうかを尋ねます。第 2 世代は、エージェントがポリシー ゲートを尊重したかどうかを尋ねます。 MARIA OS には、第 3 世代である MARIA Self-Healing Runtime が必要です。これは、障害を安全でレビュー可能な、メモリに基づいたシステム改善に変える、自己進化するハーネス ランタイムです。
エージェント システムは最終出力時にのみ失敗するわけではないため、この変化は重要です。ルーティング、取得、ツールの呼び出し、トークンの消費、権限の昇格、アーティファクトの作成、および外部システムとの対話中に失敗します。パッシブ オブザーバはこれらの障害を検出できます。ポリシーゲートがそれらを阻止することができます。しかし、オペレーティング システムには、障害を診断し、期限付きの修復を計画し、パッチを作成し、関連する証拠を再生し、次回の予防ルールを記憶できるループが依然として必要です。
0. 原理
本質的な主張は、システムが自動的に修復できるということではありません。重要な主張は、システムは安全に自動的に修復できるということです。安全性は修復ループの最後には追加されません。それはループの構造です: 障害アナライザー、メタハーネス、エンベロープ、メモリー ストア、人間による承認ゲート、およびループ コントロール。
このセクションは、システムを理解するための最も早い方法であるため、最上部に属します。残りのセクションは、その 1 つのアイデアの実装の詳細です。ランタイムは診断、パッチ適用、再生、学習を行うことができますが、不確実性を隠したり、レビューを回避したり、独自のゲートを弱めたり、速度を責任よりも重要視したりしてはなりません。
外部的には、この機能は MARIA Self-Healing Runtime という名前にする必要があります。この用語は、インフラストラクチャ購入者が理解できるほど具体的であり、MARIA OS に属するのに十分具体的であり、CI/CD 修復、E2E 修復、プロンプト/RAG 修復、エージェント ワークフロー修復、および予防ハーネス カバレッジを含むほど広範です。
1. オープンループゲートからクローズドループ修復へ
ポリシー ハーネスは、オープンループの安全メカニズムです。動作を監視し、ルールに違反した場合は実行をブロックします。これは必要ですが、エージェント インフラストラクチャにとっては十分ではありません。すべての違反を停止して人間が来るのを待っていると、組織は安全を確保できますが、複合的な改善は失われます。すべての違反が自動パッチをトリガーすると、組織はスピードを得ることができますが、再帰的な自己許可が発生する危険があります。
MARIA Self-Healing Runtime は中間パスです。これは、明示的な安定余裕を備えた閉ループであり、観察、診断、計画、修復、再生、承認、展開、監視、学習を行います。ループはシステムを改善するために許可されていますが、ループ自体の改善を管理する権限契約を書き換えることは許可されていません。
type SelfEvolvingHarnessLoop = {
observe: "runtime_episode"
diagnose: "failure_analyzer"
plan: "patch_planner"
repair: "autonomous_fixer_agent"
replay: ["scoped_harness", "cross_cutting_harness"]
approve: "human_approval_gate"
learn: "memory_store"
forbidden: ["self_authority_expansion", "required_gate_weakening"]
}制御理論との類似性は直接的です。静的ゲートはハードしきい値に相当します。 MARIA 自己修復ランタイムはコントローラーに近いものです。状態ベクトルを読み取り、制約付き補正を適用し、再度状態を読み取り、補正が変動し始めた場合は続行を拒否します。
2. 天井としての故障アナライザー
Failure Analyzer はループ全体の上限を設定します。データベース スキーマのドリフトを UI の欠陥として誤って分類した場合、Patch Planner は間違ったファイルをターゲットにします。権限違反をプロンプト品質の問題として扱う場合、Fixer Agent は誤ってガバナンスを弱める可能性があります。したがって、分類の品質は詳細をサポートするものではありません。それは最初の安全面です。
アナライザーは 3 つのレイヤーを使用する必要があります。最初の層は決定的です: ログ署名、HTTP ステータス、スキーマ差分、タイプ エラー、ルート名、変更されたファイル、アクセス許可ポリシー、CI ジョブ名。 2 番目の層は、要件の矛盾、プロンプトのあいまいさ、責任境界の不一致、ビジネス プロセスのドリフトなどの意味論的なケースに対応する LLM 推論パネルです。 3 番目の層は記憶に基づいており、同様の過去の障害エピソード、修復 PR、レビュー決定、ロールバック結果、再発パターンです。
信頼性の低い分類は自動修復に進むべきではありません。エスカレーション パッケージ (証拠、候補の分類、信頼度、可能性のある所有者、および最小の次の診断コマンド) を生成する必要があります。システムの初期バージョンでは、頻繁にエスカレーションする必要があります。最適化する指標はゼロエスカレーションではありません。誤分類が減少するにつれて、エスカレーションも減少しています。
KPI セットは、誤分類率、人的エスカレーション率、同一障害の再発率、自律修復成功率、平均回復時間など、最初から明示的である必要があります。ランタイムはより安全かつ高速になろうとしているため、これらのメトリックは重要です。
3. クロスカットハーネスの前のスコープ付きハーネス
修復は 2 つのレイヤーで実行する必要があります。スコープ付きハーネスは、最初に影響を受けるエリアをチェックします。予約用の予約ハーネス、即時変更用のプロンプト ハーネス、CI 障害用の CI ハーネス、SOW 変更用のコントラクト ハーネスです。このローカルな再生により、パッチが目に見える欠陥に実際に対処していることが証明されます。
スコープ付きハーネスが通過した後にのみ、クロスカッティング ハーネスを実行する必要があります。横断的なハーネスは、API コントラクト、権限、ログ、セキュリティ、コスト、レイテンシ、ユーザー フロー、ドキュメント、および隣接するエージェント ワークフロー全体にわたる回帰の安全性をチェックします。この順序は表面的なものではありません。グローバル ハーネスを実行すると、最初にノイズの多い障害が発生し、因果関係が隠蔽されます。ローカル ハーネスのみを実行すると、ローカルな修復が発生し、周囲のシステムが破損します。
したがって、マージ述語には両方のレベルを含める必要があります。
4. メタハーネス: ハーネスにもカバーが必要です
横断ハーネスはまだ不完全な場合があります。新しい API ルートは、API 契約の対象外で追加される場合があります。新しいプロンプトは、プロンプト ポリシーの評価なしで展開される場合があります。新しい GitHub Actions ジョブが CI Repair Harness の外部に存在する可能性があります。新しい外部副作用により、プリフライト ポリシーがバイパスされる可能性があります。したがって、システムにはメタハーネス、つまりハーネス カバレッジ用のハーネスが必要です。
メタハーネスは、リポジトリ構造、ランタイム サーフェス、ツール、プロンプト、ルート、スキーマ、ワークフロー、ドキュメントを監視します。その疑問は単純です。システムが新しい表面を獲得したとき、どのハーネスがそれを担当するのでしょうか?答えが見つからない場合、メタハーネスはシステムが安全であるかのように振る舞うのではなく、カバレッジギャップを開きます。
これは、ハーネス インフラストラクチャを自己進化するシステムに変える再帰的なステップです。ハーネスが製品を監視します。メタハーネスはハーネスを監視します。メモリ ストアは、繰り返されるカバレッジ ギャップを監視し、新しいハーネス テンプレートを提案します。
5. 予防資産としてのメモリーストア
メモリ ストアはログ ウェアハウスとして設計されるべきではありません。再発防止の資産として設計する必要があります。有用なメモリ レコードには、障害の説明、原因の分類、証拠、パッチの差分、パッチの根拠、再実行結果、副作用、人間によるレビュー コメント、人間によるレビュー者の根拠、防止ルール、次の検出パターン、および関連するハーネスが保存されます。
人間の査読者の論理的根拠を示す独立したフィールドが重要です。レビューコメントは、レビュー担当者の発言をキャプチャします。根拠は、レビュー担当者がパッチを安全、安全ではない、不完全、または承認に値すると判断した理由を把握します。この構造化された理論的根拠により、メモリ アナライザーは機械の故障のパターンだけでなく、人間の判断のパターンを学習することができます。
これにより、メモリ ストアは MARIA OS の理念と一致した状態に保たれます。システムは失敗から改善する可能性がありますが、最も価値のある学習シグナルは、多くの場合、責任をどこに戻すかを決定する人間の推論です。
6. Autonomous Fixer Agent の責任範囲
自動修復には特別な責任封筒が必要です。 Fixer Agent は、範囲指定されたパッチの作成、テストの更新、プロンプト変更のドラフト、非実稼働構成の調整、ドキュメント パッチの作成、および修復 PR のオープンを行うことができます。範囲指定されたハーネスと横断的なハーネスを再実行する場合があります。学習候補者をメモリ ストアに送信する場合があります。
運用データベースを直接変更することはできません。電子メールの送信、請求書の発行、契約の変更、権限の付与、必要なチェックの弱体化、独自の PR のマージ、運用環境へのデプロイ、または独自の権限の拡大はできません。このような変更を提案することもありますが、申請には人間による承認ゲートが必要です。
最も重要な境界は憲法です。自己修復システムにより、コード、プロンプト、ワークフロー、ドキュメントが修復される場合があります。何を修復できるかを決定するルールを黙って書き換えることはできないかもしれません。
7. ループ制御と安定余裕
自己修復は、以前のパッチによって引き起こされた症状にパッチを適用し続けると不安定になる可能性があります。ハーネス ランタイムには、最初からループ制御が必要です。つまり、最大修復試行、反復失敗の上限、ロールバックファースト パッチ、コスト上限、権限ドリフトのエスカレーション、不安定なループまたは高リスク ループの隔離です。
実際的な開始方針は保守的です。インシデントごとに 3 回の修復試行。同じ失敗署名に対して 2 回の試行。リスクの高い変更については自動マージは行われません。実稼働 DB、請求、アウトバウンド通信、許可、契約、憲法ポリシーに対する人間による承認。外部の副作用に対するサンドボックスの確認。コストの急上昇や信頼性の低下時に自動的に停止します。
これらの制限は官僚主義ではありません。それらは安定余裕です。修復ループが制御発振にならないようにします。
8. 段階的な実装
実装パスは、CI 修復からすべての MARIA 自己進化にジャンプするべきではありません。最後のフレーズは 1 つのフェーズには大きすぎます。より良いロードマップでは、システムがマイルストーンに分割されます。
- フェーズ 1: Cloud Build と GitHub Actions の失敗による診断と範囲限定の修復 PR。
- フェーズ 2: UI、API、DB の根本原因マッピングに対する E2E 障害。
- フェーズ 3: LLM、RAG、および限定的改善を伴う即時品質ハーネス。
- フェーズ 4: エージェントのワークフローの失敗、ルーティングの修復、および人間によるエスカレーションの修復。
- フェーズ 5: ハーネス カバレッジ メタハーネス。
- フェーズ 6: スコープ付きハーネス間の依存関係の推論。
- フェーズ 7: 再発防止のための失敗の記憶。
- フェーズ 8: 障害が発生する前に危険な変更を検出する予防ハーネス。
- フェーズ 9: MARIA 自己修復ランタイムの完了ステートメントと外部リリース。
フェーズ 9 は、別の無制限の実装フェーズではなく、完了宣言として意図的に構成されています。予防的ハーネスが機能するまでに、技術的な部分はほとんど完成しています。フェーズ 9 は、MARIA OS が統合機能に名前を付け、オペレーティング モデルを公開し、測定標準を公開するポイントです。
このロードマップにより、自己進化が実行可能になります。各段階では、漠然とした自律性の約束ではなく、測定可能な能力が生み出されます。
9. これによりカテゴリが変更される理由
エージェントのガバナンスとは、自律性に責任を持たせることです。自己修復エージェントのインフラストラクチャは、制約の下で責任ある自律性を向上させることを目的としています。その違いは決定的です。最初のカテゴリはエージェントを管理します。 2 番目のカテゴリーは、撹乱下でもエージェント組織を存続させる神経系を操作します。
MARIA OS は、すでに責任ゲート、証拠証跡、実行時エピソード、承認境界を第一級のアーキテクチャとして扱っているため、この移行を行う立場にあります。 MARIA 自己修復ランタイムは、これらのオブジェクトを修復ループに接続します。 FDE の知識を Memory Store 資産に変えます。これにより、CI の障害が範囲指定された修復提案に変わります。即座に起こる失敗を、再現可能なエピソードに変えます。それは組織の漂流をオーナー主導の介入に変えます。
MARIA OS が MTTR、HITL コンバージェンス、障害再発、誤分類率、カバレッジ ギャップ検出を第一級の製品指標として公開すれば、AI インフラストラクチャの回復力の測定基準を、単にそれに参加するだけでなく定義することができます。
結論
テストだけを行うハーネスは役に立ちます。ゲート付きハーネスの方が安全です。診断、修復、再生、学習、およびそれ自体の責任範囲を保存するハーネスがインフラストラクチャになります。これが、エージェント ガバナンス OS から自己修復エージェント インフラストラクチャへの戦略的な移行です。
難しいのはパッチを生成しないことです。難しいのは、修復を制限し、レビュー可能で、再実行可能にし、それ以上の権限を与えることができないようにすることです。そのため、MARIA 自己修復ランタイムは自動化機能ではありません。これはエージェント システムのランタイム ガバナンス層であり、説明責任を失うことなく改善を続ける必要があります。