要旨
ほとんどの AI 製品チームは依然として、ソフトウェアファーストのワークフローを使用してエージェント システムを構築しています。つまり、プロンプトを作成し、ツールを接続し、プロトタイプを出荷し、障害を観察し、事後にテストを追加します。最も重要な欠陥は構文エラーではないため、このワークフローはエージェント システムには弱すぎます。これらは実行時フェーズのエラーです。エージェントが間違ったモードに入ったり、間違った記憶を信頼したり、自律性を過剰に使用したり、証拠の保存に失敗したり、責任が人間に移るべきにもかかわらず実行を継続したりします。
ハーネス主導の開発では、順序が逆になります。ダイナミック ハーネスはテスト用アクセサリではありません。主な仕様です。エージェントを実装する前に、チームは、エージェントが存続する必要がある実行時のエピソード、ドリフトの分類に使用される障害分類、動作が改善しているかどうかを決定するスコアカード、および承認なしでは越えることができない権限の境界を定義します。その後、実装は、実行中のランタイム契約を満たすための制御された試みになります。
1. プロンプトファースト開発が破綻する理由
最初のデモがすぐに届くため、プロンプトファーストの開発は速く感じられます。しかし、そこには4つの形態の借金が隠されています。まず、動作は散文で指定されるため、エージェントが改善しているのか、単にスタイルを変更しているだけなのかは誰にもわかりません。第二に、失敗は逸話として記述されるため、正確に再現することはできません。第三に、ツールの選択にはリスクが伴う場合が多いにもかかわらず、ツールの動作は実装の詳細として扱われます。第 4 に、エージェントが直接実行のパターンをすでに学習した後、ガバナンスが遅れて現れます。
ダイナミック ハーネスは、これらの隠れた負債を明示的なエンジニアリング オブジェクトに変えます。実行時エピソードは、目標、入力、メモリ状態、ツール呼び出し、証拠、出力、スコア、および最終アクションをキャプチャします。障害分類法では、問題の原因が証拠の欠落、自律性の悪さ、記憶の古さ、間違ったツールの使用、責任の不明瞭、待ち時間の圧力、またはコストの圧力のいずれであるかが示されます。スコアカードはエピソードを測定可能な状態ベクトルに変換します。修復境界は、どの修正を自動的に行うことができ、どの修正が人間によるレビューを必要とするかを定義します。
2. ハーネスの仕様
通常のソフトウェアでは、仕様はシステムが何をすべきかを記述します。エージェント システムでは、それだけでは十分ではありません。また、システムをいつ停止すべきか、いつ質問すべきか、いつ不確実性を保持すべきか、いつシステム自身の出力を信頼できないものとして扱うべきかを指定する必要もあります。したがって、ハーネス仕様には 5 つの層が含まれます。
- シナリオ層: 代表的なランタイム エピソードと敵対的なランタイム エピソード。
- ゲート層: 権限のしきい値、証拠の要件、および人間の承認パス。
- スコア レイヤー: 品質、レイテンシ、コスト、責任、メモリ、安全性の指標。
- 修復レイヤー: 許可された変更、承認が必要な変更、およびロールバック ルール。
- 監査レイヤー: MARIA 座標、根拠、証拠パス、および差分履歴。
これにより、ハーネスは単なる評価スイートではなくなります。それは実装が満たさなければならない契約になります。プロンプト、ツール、ワークフロー、またはポリシーは、ゲートに違反することなくランタイム ベクトルを改善する場合にのみ正しいものとなります。
3. ハーネス主導の開発ループ
開発ループには 5 つの段階があります。最初の段階は行動モデリングです。エージェントが下す必要がある決定、エージェントが使用するコンテキスト、およびエージェントが行使を許可される権限を定義します。第 2 段階はエピソードのエンコードです。サンプルを再生可能なランタイム エピソードに変換します。 3 番目の段階は実装です。エピソードを満たすためにプロンプト、ツール、ワークフロー、およびポリシーが作成されます。第 4 段階はリプレイです。すべての変更がハーネスに対してテストされます。第 5 段階は強化です。失敗は使い捨てのバグノートではなく、新たなエピソードになります。
type HarnessDrivenChange = {
coordinate: string
scenarioIds: string[]
allowedAutonomy: "observe" | "draft" | "execute" | "repair"
gates: string[]
expectedScoreDelta: {
quality: number
responsibility: number
latency: number
cost: number
}
approvalRequired: boolean
}重要な点は、実装は意図によって判断されないということです。リプレイにより判定されます。新しいプロンプトによってデモの見栄えは良くなりますが、エッジケースで安全でない自律性が高まる場合、それは失敗します。ツールの最適化によってレイテンシーは減少しますが、証拠のトレーサビリティが失われる場合、ツールの最適化は失敗します。ワークフローが同等の責任の保持を証明せずに人間のチェックポイントを削除すると、ワークフローは失敗します。
4. エンジニアリングのメタファーとしてのページ分割
優れた LP セクションは、横揺れなくモバイル ビューポート内に収まります。優れたエージェント機能は、責任を揺るがすことなくガバナンス ページ内に収まります。どちらの場合も、規律は同じです。サーフェスを境界のあるページに分割し、隠れたオーバーフローを防ぎ、制御されたコンテナ内で高密度のコンテンツをスクロールさせます。ハーネス駆動開発では、この原則が実行時の動作に適用されます。各エピソードは 1 ページです。各ページが収まる必要があります。それが収まらない場合は、小さなエピソードに分割する必要があり、無制限の自律性にオーバーフローすることは許可されません。
5. 製品チームの変更点
プロダクトマネージャーはユーザーストーリーだけを書くことはなくなりました。これらは、証拠が欠落している場合、ユーザーが安全でないショートカットを要求した場合、データ ソースがメモリと矛盾している場合、またはエージェントが予算内で作業を完了できない場合に何が起こるべきかなどの失敗事例を定義します。エンジニアは、コードが実行されるかどうかだけを尋ねることはなくなりました。彼らは、ハーネス状態ベクトルが改善したかどうかを尋ねます。レビュー担当者は実装スタイルのみをチェックしなくなりました。これらの変更により、権限の境界、証拠のパス、または修復権限が変更されたかどうかが検査されます。
これにより、すべての機能 PR にハーネス デルタを含める必要があるという実際的なルールが作成されます。どのようなシナリオが追加されましたか？どのようなスコアが変化しましたか?どのゲートに触れられましたか?どのような修理が可能になったのでしょうか？人間の承認のみが必要な変更はどれですか?
6. 自動実装との関係
ハーネス主導の開発は、安全な自動実装の前提条件です。ハーネスが弱い場合、実装エージェントには安定したターゲットがなく、表面的な完成を目指して最適化されます。ハーネスが強力であれば、実装エージェントは明示的なランタイム コントラクトに基づいてコードを合成できます。ツールを生成し、エピソードを実行し、障害を検査し、パッチを提案し、スコアの改善が飽和したとき、または次のステップが承認境界を越えたときに停止することができます。
したがって、ハーネスがコード生成と管理された実装の違いとなります。コード生成では、モデルが妥当なコードを生成できるかどうかが問われます。ガバナンスされた実装では、コードが権限契約に基づいて実行時の動作を改善することをシステムが証明できるかどうかが問われます。
7. 研究課題
次の研究課題は、ハーネスの完全性を形式化することです。意図された責任モデルに違反しながらも、動作が現在のすべてのエピソードを通過できる場合、ハーネスは不完全です。これは、プロンプト、ツール、ポリシー、メモリを意図的に混乱させ、ハーネスが劣化を検出するかどうかを尋ねる突然変異テストを通じて測定できます。強力なハーネスとは、悪い突然変異をすぐに失敗させ、その理由を説明するものです。
2 番目のタスクはハーネスの圧縮です。エンタープライズ システムでは、すべての変更ごとにすべてのエピソードを再生することはできません。ハーネスには最小限の基礎が必要です。つまり、スコア勾配がより長い実行時間を予測するエピソードの小さなセットです。ここで位相空間制御が実用的になります。ハーネスは、どのエピソードがリスクの異なる領域を表しているかを特定し、すべての PR で基礎を再生し、スケジュールされた評価でフルセットを再生する必要があります。
結論
ハーネス駆動開発は、プロンプト クラフトからランタイム エンジニアリングへの移行です。ダイナミック ハーネスを仕様にし、ランタイム エピソードを回帰単位にし、スコアカードを測定面にし、権限の境界をゲートします。これは、MARIA OS が内部の自動実装と自動修復を安全にサポートできるようにするために必要な基盤です。