エージェント システムはまずコンテキスト バジェットとセンサーを強化します。

Martin Fowler の記事 Fragments: July 13 を見ると、最初に浮かぶ単語はモデル スコアではなく、ハーネス エンジニアリングです。リトリートでは、すでに議論を文脈やセンサーに落とし込んでいる人もいます。この問題は、新興のエンジニアリング分野に非常によく似ています。エージェントは、まず入力を強化し、次にアクションの拡張について話し合う必要があります。

コンテキスト ウィンドウが大きくなるほど、制約は短くなります。

この記事には非常に簡単な詳細が記載されています。誰かが agents.md を 200 行以内に制御したということです。この数字は潔癖症のように見えますが、実際にはプロジェクトの予算です。確かにコンテキストウィンドウはどんどん大きくなっていますが、ウィンドウが大きくなったということは、より多くのコンテンツを詰め込めるというだけで、モデルが把握すべき部分をよりしっかりと把握できるようになるわけではありません。モデルは通常、コンテキストのごく一部にのみ焦点を当てており、残りのコンテンツが存在する場合でも、単に実行されているだけである可能性があります。

これは、長いドキュメントで最も一般的な問題です。ルールが多ければ多いほど、本当に重要な制約がノイズによって覆い隠されやすくなります。説明が長ければ長いほど、境界を背景として、背景を境界として書きやすくなります。ファイルを短くすることは、書き込み時間を節約することではなく、制約を強制的に表示、読み取り、実行可能にすることです。エージェントが直面しているのは資料の山ではなく、限定された運営契約です。

センサーは少量の使用可能な信号に圧縮する必要があります

もう 1 つの変化は、議論が計算センサーにまで進み始めたことです。ここでのセンサーは、単にポイントを埋めたり、ログをモデルに再度フィードしたりするのではなく、実行時のステータスを少数の安定した信号に圧縮します。センサーが元の出力再生になると、入力は再び拡張されます。本当に価値のあるアプローチは、まずシーンをいくつかの明確な状態に切り分けてから、どの詳細を人物に与え、どの詳細をツールに与えるかを決定することです。

この記事では、Python から Rust などのより制御しやすい言語に切り替えることは、この状況でのみ意味があると述べています。焦点は言語の好みではなく、コントロールにあります。センサーに必要なのは、「実行中」ではなく、明確な境界、明確な例外セマンティクス、および明確なリソース消費です。信号が不安定である限り、どんなに強力なモデルでもジッター入力でしか判断できません。

ハーネスは最初にアクション チェーンを閉じます

この議論がここまで進むと、ハーネスはシェルではなく、マウスピースのようなものになります。何がコンテキストに組み込まれ、何がコンテキストから除外されるかを決定する責任があります。どの状態がモデルによって信頼できるか、どの状態がツールによって再確認される必要があるか。コンテキスト バジェット、センサー設計、権限境界、フォールバック パスはすべて、最終的にこのレイヤーに到達します。

エージェント システムで最も過小評価されやすいコストもこのレベルに当てはまります。モデルの置き換えは高速ですが、ハーネスはアクション チェーン、信号チェーン、障害チェーンにバインドされているため、はるかに遅くなります。この層が強化されず、モデルの機能が前進しない限り、システムはカオスをより速く増幅させるだけです。

純粋な読み取りリクエスト、ワンタイム分析スクリプト、外部アクションのない軽量エージェント、およびモデル機能が依然として主役です。プライベート データ、長期状態、実際のアクションを接続し始めるとすぐに、最初に強化するのはモデル パラメーターではなく、入力境界と信号境界になります。エージェントが本当にシステムに似ている瞬間は、多くの場合、これら 2 つの層が最初に定着するときです。