原文
これは、プロトコルがオンチェーンで強制できることと、オフチェーンで実際に起こることとの間のギャップ、そして優れたメカニズム設計が、誰もが正直であると信頼するのではなく、不正な行動を不採算にすることでそのギャップをどのように狭めるかについて、私が5月初旬からここに投稿してきた一連の議論の続きです。私たちの通常の主題とは異なる最近の出来事が、同じ原則の明確で大規模な外部事例を提供してくれました。自律エージェントが、私たちがここで設計するシステムにおいて第一級の参加者になろうとしているため、この話題を再び持ち出す価値があると思います。
3月下旬に、あるAIコーディングツールの完全なソースコードが誤って公開され、いくつかのグループがその分析を発表しました。私たちに関連する詳細は構造的なものです。モデルを呼び出し、何をすべきかを決定するシステムの部分はごくわずかです。あるコミュニティの推定では、コードベースの2パーセント未満であり、コードの分類方法に完全に依存するため正確な数値にこだわるつもりはありませんが、質的な分割については異論がありません。エンジニアリングの圧倒的大多数は知能そのものではありません。それは知能を取り巻く装置です。エージェントと状態変更アクションの間にデフォルトで拒否する許可レイヤー、エージェントが目的を見失わないようにするコンテキスト管理パイプライン、並列エージェントが互いに破損しないようにする隔離、そして特権アクションが承認のために保留される明示的なチェックポイントです。
これをメカニズム設計の問題として読むと、見慣れたものになります。エージェントは、周囲の構造がそうすることへの報酬を取り除かない限り、有害な行動を含む、局所的に魅力的な行動を取る参加者です。許可レイヤーは清算ルールです。隔離は、あるアクターの保留中のアクションが別のアクターに漏洩するのを防ぐときに私たちが求めるのと同じ特性です。承認のために保留されるチェックポイントはコミットメントデバイスです。どの装置も参加者をより高潔にしようとはしません。自己利益と誤謬性を所与のものとして想定し、悪い結果が報われなくなるまで行動空間を制約します。
これは、私がオフチェーンのギャップについて主張してきた立場です。参加者に振る舞いを求めるだけではギャップを埋めることはできません。なぜなら、逸脱のインセンティブは構造的であり、意図は負荷に耐えられないからです。逸脱が不採算になるように構造を変更することでギャップを埋めます。私はこの姿勢を、参加者を置き換えるのではなく不変条件を拡張すると表現してきました。そして、流出したハーネスは、私たちのほとんどが検査できない規模で、その異常に具体的なデモンストレーションであると思います。
これが一般的なAIの場ではなくethresearchに属する理由は、それが向かっている方向です。自律エージェントはすでにサーチャー、ソルバー、インテントエグゼキューターとして機能しており、人間以外の参加者によって開始されるオンチェーンアクティビティの割合が増加しています。私たちはこれらのエージェントを合理的で明確に指定されているものとしてモデル化しがちです。ハーネス分析は、本番環境で実際のエージェントを運用している人々が、それらをまったくそのように信頼していないことを思い出させます。彼らはエージェントが時折、完全に自信を持って間違ったことをすると予想しているため、決定論的な制約でそれらを包み込んでいます。
それが正しい運用上の仮定であるならば、エージェントが参加するメカニズムをどのように指定すべきかが変わります。私にはまだ明確な答えがないいくつかの質問があります。
エージェント向けのメカニズムに対するインセンティブ整合性条件 (IC条件)分析は、クリーンな合理的なアクターを仮定するのではなく、参加者が非自明な確率で最適な応答ではない行動を時々取るという誤謬項を含めるべきでしょうか？参加者のかなりの割合が戦略的に敵対的であるというよりも、自信を持って間違っている場合、標準的な均衡論は弱まります。
エージェントを制約するハーネスがオフチェーンに存在し、それが参加するメカニズムがオンチェーンに存在する場合、私たちはレイヤー1上でエアギャップを再現しています。制約とアクションは異なる信頼ドメインによって強制されます。エージェントの許可エンベロープ自体がオンチェーンでコミットされ、制約とアクションが強制ドメインを共有するような設計はありますか？
そしてその逆、私が最も興味深いと感じる部分です。ハーネスパターンは、コアコンポーネントを改善できず、その周りにすべてを構築しなければならなかった人々によって発見されました。メカニズム設計も同じ形をしています。私たちは参加者を正直にすることはできないので、正直さが儲かる行動になるような構造を構築します。もしこの2つの分野が異なる名前で同じ問題を解決しているのなら、オンチェーンメカニズム設計がすでに知っていることで、エージェントハーネスエンジニアリングが現在手作業で再発見していることは何でしょうか？
他の皆さんが、エージェントを信頼できない参加者として捉えるフレームワークを、インセンティブ整合性条件 (IC条件)ツールキットの有用な拡張と見なすか、あるいはカテゴリーエラーと見なすかに興味があります。反論も歓迎します。
1投稿 - 1参加者