ハーネス・エンジニアリングに固定されたアドレスはない
ハーネス・エンジニアリングは、ソフトウェアスタック内のある特定の場所を指すものではありません。それはコードの「特性」なのです。
ハーネスは単にAIモデルをラップするためのものだと考えている人が多いですが、それは間違いです。ハーネスこそが、モデルを実際のビジネスで有用なものにする要素なのです。
私はシンプルな数式を使っています：Agent = Model × Harness
モデルはエンジンです。ハーネスはステアリング、ブレーキ、そしてセーフティレールです。
しかし、ここに問題があります。モデルは絶えず進化しています。新しいモデルのバージョンが登場するたびに、ハーネスの一部がモデルへと吸収されていくのです。
- 推論モデルが、思考の連鎖（chain-of-thought）ロジックを処理できるようになった。
- より優れたモデルが、ツール利用をネイティブに処理できるようになった。
- 長いコンテキストウィンドウが、従来のメモリシステムに取って代わった。
もしモデルがハーネスを飲み込んでしまうとしたら、あなたが構築すべきものは何が残るのでしょうか？
「溶けてなくなる」部分は、メカニズムです。ループ、リトライ、メモリの繋ぎ合わせといった要素は、コモディティ化していくでしょう。配管（plumbing）を作ることに、自分のキャリアを賭けてはいけません。
「残り続ける」部分は、仕様（specification）と検証（verification）です。
- 仕様（Specification）：エージェントに許可される動作を定義しなければなりません。モデルは、あなたの会社の特定の返金ポリシーやリスク許容度を知ることはできません。それらはコードの中に存在するものです。
- 検証（Verification）：エージェントがルールに従っていることを証明しなければなりません。モデルは自分自身を確実に判断することはできません。作業をチェックするための外部レイヤーが必要です。
返金エージェントを例に考えてみましょう。
返金限度額をプロンプトに入れた場合、ユーザーはモデルを欺くことができます。しかし、その制限をコード内のif文に記述すれば、モデルがそれに異議を唱えることはできません。
そのif文こそが、ハーネス・エンジニアリングなのです。
ハーネス・エンジニアリングは、次の2点に集約されます：
- 許可される動作の範囲（envelope）を定義すること。
- エージェントがその範囲内に留まっていることを証明すること。
モデルは、あなたが制御しようとしている対象（プラント）です。 仕様は、あなたの目標です。 ハーネスは、コントローラーです。 評価は、フィードバックです。
ツールやメカニズムは毎月変わっていくでしょう。しかし、仕様と検証という規律が変わることはありません。
配管を作るのはもうやめましょう。制約（constraints）と証明（proofs）の構築を始めるのです。
ソース: https://dev.to/saurav_bhattacharya/harness-engineering-has-no-fixed-address-2m7a
学習コミュニティ（任意）: https://t.me/GyaanSetuAi