エージェント エンジニアリングは、まずコンテキストとセンサーを強化します。

最近のハーネス エンジニアリングに関する一連の議論を見ていると、最も直観的に感じられるのは、「エージェントに新しい機能層が追加された」ということではなく、エンジニアリングの議論の焦点が変わってきたということです。以前は、モデルが十分に強力であるかどうかについてよく質問されました。ここで、最初に、どれだけのコンテキストを含めるか、ルール ファイルにどれくらいの長さを含めるか、そしてセンサーがどのような信号を与えるかに焦点を当てます。モデルはまだ途中ですが、安定性を決めるのはアウターハーネスです。

コンテキスト ウィンドウが大きいほど、注意がより安定します。

撤退中の誰かが、agents.md を 200 行未満に制御する必要があると述べました。この番号は気取ったものや回線番号を崇拝するものではなく、むしろ予算を思い出させるものです。コンテキストウィンドウが大きいということは、より多くのコンテンツを詰め込めるということを意味するだけで、モデルが把握すべき部分をより安定して把握できるようになるわけではありません。モデルは多くの場合、コンテキストのごく一部にのみ焦点を当てており、コンテンツの残りの部分がウィンドウ内にある場合でも、そのすべてに焦点が合っているとは限りません。

これはエンジニアリングにおいて非常に厄介です。ルールが多ければ多いほど、「制約」を「ノイズ」として書きやすくなります。指示が長ければ長いほど、本当に守らなければならないことが隅に埋もれやすくなります。ファイルを非常に短くすることは、文書をきれいに見せることではなく、制約を強制的に見えるようにすることです。モデルが直面しているのは百科事典ではなく、限定された運営契約です。

センサーはログを再度フィードしません

もう 1 つの明らかな変化は、議論が計算センサーにまで進み始めたことです。ここでのセンサーは単純に埋め込まれているわけではなく、システム ログがそのままモデルに挿入されているわけでもありませんが、実行時のステータスは少数の使用可能な信号に圧縮されています。これが行うのはノイズをフィルタリングすることであり、新たなコンテキスト上の負荷を作成することではありません。

「Python ではなく Rust に切り替えよう」と言われるのはこのためです。焦点は言語の側に立つことではなく、コントロールにあります。センサーが実行時の境界、リソースの制約、例外パス、および決定論的な出力に依存して品質を確保すると、言語と実行環境は単なる実装の詳細ではなく、センサー自体の一部になります。信号が不安定な場合、モデルがどれほど強力であっても、不安定な入力に対してのみ推測が行われます。

生データをモデルに直接送信すると、短期的にはより有益に見えるかもしれませんが、多くの場合、長期的にはシーンのノイズが増えるだけです。本当に役立つセンサーは、まず「何が起こったのか」をいくつかの明確な状態に圧縮し、次にどの詳細を人間に任せ、どの詳細をツールに任せるかを決定する必要があります。

ハーネスの責任は、世界をモデルに供給できる断片に切り分けることです

この種の議論が成熟すると、プロンプト技術よりもシステム設計のように見え始めます。ハーネスは境界を担当します。つまり、何がコンテキストに含まれるか、何がコンテキストの外に留まるか、どの状態がモデルによって信頼できるか、どの状態がツールによって再確認される必要があるかなどです。それはシェルではなく、フィルターの層であり、それに近いものです。

これは、エージェント システムで最も過小評価されているコストでもあります。モデルの置き換えは高速ですが、ハーネスはアクション チェーン、信号チェーン、障害チェーンを直接バインドするため、はるかに遅くなります。コンテキストのバジェット、センサーの設計、権限の境界、フォールバック パスはすべて、最終的にこのレイヤーに分類されます。この層が緊密でない限り、モデルが強力であればあるほど、システムの不安定性がさらに広がりやすくなります。

この種の断片を今見てみると、最も価値のある部分は、単一の結論ではなく、プロジェクトの焦点を明確に述べていることです。つまり、エージェントはもはや単に「何かを実行できるかどうか」ではなく、「外部システムが注意と信号を集めているかどうか」です。このステップは安定していないため、モデルの機能をさらに向上させても、カオスはさらに加速するだけです。