あらゆることを実行できるハーネスに向けて

arda tasci content about talk to me Towards a Harness That Can Do Anything 私は数年前から、LLMをチャットペインから解放する方法について考えてきました。人々が試してきたことを見て、何がうまくいき（そして何がうまくいかなかったか）を観察する中で、私はそれに取り組む正しいアプローチについての自分の意見を形成しました。ここに私の考えと、最近私が取り組んできたことを示します。 良いハーネスとは何か I. エージェントにとって自然に直感的であるべきです。 II. すべてが透明であるべきなので、エージェントは自己開発または自己修復（または事後監査）が可能です。 III. できるだけ無駄がなく、柔軟である必要があります。 IV. エラーからの回復、アップデートからの回復、時間の経過によるメモリ破損や劣化がないこと。 LLMの知能が進歩するにつれて、ハーネスは最終的に信頼できるようになるでしょう。本当に重要なのは、ボットにかかる認知負荷（トークンで測定）をどれだけ減らせるかということです。 予備的な真実 長年にわたって学んだ最も重要なこと。 可能な限り決定論的であること。LLMは追求する目標を選択すべきですが、その目標への熟考は明確に定義されているか、少なくとも明確に定義されたステップの集まりであるべきです。コアプロンプトはできるだけ小さくすべきで、LLMは実行時にどのスキルをコンテキストにロードするかを選択すべきです。コンテキスト制限に近づくと、LLMは狂い始めます。 オッズに賭けるな、ボットに賭けろ 良いハーネスは、LLMの事前コーディング知識を利用しなければなりません。コーディングとシステム管理はLLMのトレーニングデータで過剰に表現されているため、LLMがすでに快適な環境を与えてください。新しい環境でそれを無理やり動かすことは、最終的にトークンを無駄にします。同様に、ファイル発見やトラバーサルなどのことには貴重なコンテキストを費やすべきではありません――良いハーネスは委任を容易かつ効率的に行います。同時に、ハーネスはLLMにとって軽量に感じるべきですが、実際にはバックグラウンドで多くのことを行うべきです。これには、ロギング、健全性チェック、フェイルセーフ、サニタイゼーションなどが含まれます。 監査可能性、ロギング、自己修復 すべては脆弱であり、すべてのエージェントはいずれ失敗します。エージェントの失敗には2種類あります。 LLMレベル ハーネスレベル LLMレベルでの失敗は直接パッチを当てることはできませんが、そのような失敗のリスクはハーネスによって軽減できます。ハーネスレベルの失敗は回復可能であり、LLMのターンベースの性質により実行時に修正可能であるべきです。欠陥を修正するために、エージェントは2つのものが必要です：優れたロギングと明確なエラーメッセージ。 すべてを実行できる統一データレイヤー これらの要件のほとんどは長年の質問です。単に言葉遣いがユーザーからエージェントに変わっただけです。したがって、尋ねる価値があります：人々が実際にコードを書いていた「昔々」から何を学べるでしょうか？ 私の仮説：Unix / Linux環境は自然な候補であり、いくつかの変更を加えることでエージェントハーネスに変えることができます。私はUnixとその子孫の専門家ではありませんが、過去10年間、その歴史、設計上の選択、および使用法を学んできました。その多くは私たちの苦境に美しくマッピングされますが、多くはそうではありません。U/Lを直接の比較ではなく、動機付けのアナロジーと考えてください。 古い概念を新しい概念にマッピングし、Unix哲学 忘れてしまった、またはまだ見ていない場合に備えて、リッチーとトンプソンの祖先の信条をここに示します。 1つのことを行い、それをうまく行うプログラムを書け。 新しい仕事をするには、古いプログラムに新しい「機能」を追加して複雑にするのではなく、新たに構築せよ。 プログラムが連携して動作するように書け。 各プログラムの出力を別のプログラムの入力として期待せよ。 テキストストリームを処理するプログラムを書け。なぜなら、それは普遍的なインターフェースだからだ。 これらは今日のハーネスの問題を完璧に要約しています。それらは過度に複雑で、多くのことを行おうとしており、エージェントが取るべき軌跡はしばしば不明確です。これらはすべて同じ問題の症状です。エージェントが自分自身に主体性を持つ方法がありません。多くの場合、ツールは直接コンテキストにロードされ、システムプロンプトは開発者が持つ警告、特定のルール、ガイドラインで事前に満たされます（これらはターンごとにフェードアウトしていきます）。 それから、ハーネスを設計するための独自の原則を導き出すことができます。 1つのことを行い、それをうまく行う、モジュラーで透明なツールを書け。それらが大声で失敗するようにせよ。 連携して動作するツール、スキル、コネクタを書け。スキルはワークフローを決定し、ツールはそれらを実行する手段であり、コネクタはエージェントが操作するデータです。 テキストストリームは普遍的なインターフェースであり、言語モデルはホームコートアドバンテージを持っています。すべてがフラットなテキストファイルであるべきです。 Ambiance：ハーネスに関する私の見解 すべてはファイルである 手動でJSONの操作をしたことがありますか？エンドポイントをクエリするために重いcurlコマンドを構築したことは？複雑な正規表現？私はしたことがありません。なぜなら、それらは面倒だからです。LLMはあなたよりもそれらを扱いやすいかもしれませんが、彼らもプレーンテキストを好むと確信してください。したがって、外部データソースを扱うときはいつでも、ハーネスはLLMに到達する前にそれをクリーンアップするために必要な操作を実行する必要があります。 このすべてのデータを保存する場所が必要です。すべてをディレクトリに分類することで、エージェントのトークン無駄遣いを大幅に減らすことができます。 Filesystem Hierarchy Standard (FHS) を検討する FHSは、新しいLinuxインストールの外観を概説しています。自然に、LLMはLinux FSをナビゲートするエキスパートです。したがって、外部データソースを戦略的に配置し、VFSにルーティングすることで、エージェントは自宅にいるように感じることができます（例：ログは/varに、設定ファイルは/etcに、エージェントワークスペースは/homeに配置されます）。追加の利点は、あなたとエージェントの両方がgrep、find、which、さらには非GNUプログラム（rgやfzfなど）を使用して、簡単に監査、追跡、検索できることです。 重労働は、乱雑で散らかった外部世界を偽のVFSに適合させることです。私は次のマッピングを使用しています。多くのことが直接1対1で翻訳されるわけではないことに注意してください。 Harness | Unix Equivalent | FHS ------- | --------------- | ---- Agents | Users | /home/... External data | Drivers | /sys/ Tools | Binaries | /bin/ Logs | Logs | /var/ Self-healing | System Binaries | /sbin/ & /recovery Skills | Docs | /usr/share/doc 「カーネル」 ファイルシステムがどのようになるべきかを確立したので、エージェントが環境とどのように（あるいはむしろ、いつ）対話するかを考えてみましょう。常に稼働しているエージェントの業界標準であるOpenClawは、イベント駆動型のメッセージ処理とハートビートをペアにします。これは、何か注意が必要かどうかを確認するために固定間隔（デフォルトで30分）で行われる完全なエージェントターンです。問題は、ファイル変更や外部状態のようなプッシュメッセージではないすべてが、ハートビートの粒度でのみ認識されることです。間隔を短くすると、すべての空のチェックで完全なLLMターンを消費し、間隔を長くすると、エージェントは世界から最大1時間遅れます。したがって、私はイベントバスを中心にAmbianceを構築することにしました。私はそれを誤って「カーネル」と呼んでいます。それはテキストファイルのカーソルでFSの変更を監視し、それに応じてLLMを呼び出します（高スループットを処理するためのいくつかの合体戦略付き）。その方法で、エージェントが単一の通知を見逃さないことを保証できます。さらに、異なるイベントに応答するために、異なる「ユーザー」（LLMインスタンス）を配線することもできます。 カーネルが重労働を行う 実際のカーネルは、ソフトウェアとハードウェアの中間層として機能します。Ambianceカーネルは、LLMと外部世界の中間層として機能します。カーネルは、LLMが行うすべてのことが安全で、明らかに有害でないことをチェックし、保証します。 「ユーザー」 これまでに開発した3つのデフォルトユーザーがあります。 root：すべてのシステムレベルのものを処理します。特に新しいドライバー、バイナリのコーディングや古いものの修正を行います。 pai：実際に外部世界と対話する人間向けのLLMです。 librarian：paiが得意なこと、苦手なこと、そしてその日のシステムが行ったことを記録します。 これら3つは、イベントバスとsend-messageバイナリを介して常に互いに通信しています。 試してみてください Ambianceの背後にある考えはシンプルです。モデルの事前知識は最も安価です