エージェントがタスクを引き継いだ後、最初に強化するのは作業単位です。

最近、エージェントに関する多くの議論を読んでいますが、最終的にはいつも同じ質問に戻ります。作品は誰に渡すべきか、渡す前にどのように梱包すべきか、返却後はどのように受け入れられるかということです。プロジェクトでこの問題が発生すると、多くの場合、最初に増加するのはモデルのコストではなく、作業単位の複雑さです。タスクが大きすぎると、モデルは「あたかもそれが実行できるかのように」見えます。本当の問題は通常、ロールバック、再現、受け入れにあります。

ワークユニットは最初に受け入れられる必要があります

ここ数日、Martin Fowler の断片的なメモと、Thoughtworks Future of Software Development Retreat でのいくつかのディスカッションをつなぎ合わせた後、最も明白に感じたのは、会議での会話は表面的には散漫だったが、その根底では、実際にはたった 1 つのこと、つまり大きな仕事をエージェントに引き渡すことだけを中心に展開していたということです。

キーフ・モリスのフィニッシュは最も単純だ。さまざまなセッションで、コードレビュー、本番環境での事故、チームの分業、モデルのルーティングについて議論しました。彼らは別々のことを話しているように見えましたが、結論は同じであることがわかりました。つまり、人々は「単位作業」のサイズを調整しているということです。ユニットが大きいほど、引き渡しが容易になります。ユニットが大きくなればなるほど、戻ってきた後にそれを受け入れるのは難しくなります。モデルがそれを実行できないのではなく、後続の確認リンクが最初に保持できないのです。

ハーネスについて何度も言及されるのはこのためです。コンテキスト管理、計算センサー、プロパティベースのテスト、形式的手法、これらは追加ツールのように聞こえますが、実際には作業単位を収集します。形のきれいさを追求するためではなく、本当に有用で実際に確認できる情報の部分のみをシステムが受信するように強制するために、agents.md を 200 行未満に制御する人もいます。コンテキストが緩すぎますが、もちろんエージェントは実行できます。しかし、実行後は、どの層の制約を飲み込んだのかは誰にも分かりません。

セルフホスティングによりコントロール サーフェスが起動します

自己ホスト型モデルに関する議論でも同じことが指摘されています。トークンが高価になり、コンプライアンス要件が厳しくなり、データが外部に漏洩できなくなると、オープンソースモデルやローカルモデルの魅力が自然と高まってくる。しかし、自分でモデルを持ち運ぶと、GPU、推論室、ルーティング、ロールバック、微調整、モデルの選択などの問題も発生します。これらはモデルの機能そのものではありませんが、システムが最終的に安定しているかどうかを決定します。

このようなコストは過小評価されることがよくあります。多くのチームは当初、「モデルがより強力であるかどうか」に焦点を当てていましたが、実際に時間を消費するのは複数のモデル間でのワークユニットの安定した転送であることが後にわかりました。いつ大規模モデルを使用するか、いつ軽量モデルを使用するか、いつ単にローカル モデルを使用するかは、口頭での好みではなく、気晴らしや隠蔽に使用できるコントロール サーフェイスの層によって決まります。このレイヤーがなければ、セルフホスティングは「主導権を握る」ことから「運用と保守の複雑さを自分で引き受ける」ことになってしまいます。

Simon Willison 氏は、より強力なモデルに作業を実行させるためにより小さなモデルを選択させると述べました。この考え方は、コントロール プレーンが行っていることと非常によく似ています。モデル自体は必ずしもチームのコスト境界を知っているわけではありませんが、システムは知っています。モデルをブローカーとして扱い、それを使用してタスクを割り当てることは、包括的な配信のために単一のモデルを盲目的に追求するよりも実際の配信に近くなります。

承認と目標を外部委託することはできません

サム・ルビーの「ブリング・ミー・ア・ロック」は別の問題を浮き彫りにした。モデルに作業を与えることは、エグゼキューターを追加することと同じです。責任は消えません。マネージャーは LLM を探索に使用でき、最初に大量の候補ソリューションを吐き出させることができますが、最終的な受け入れ基準は依然として人間の手に委ねられる必要があります。隠された目標が最も厄介です。権限、プライバシー、破壊的なアクション、コンテキスト漏洩は、多くの場合、元の要件に含まれていません。

したがって、適合性テストは仕様書よりも役立つことがよくあります。仕様は「何が必要なのか」を記述するのが得意で、テストは「何が起こり得ないのか」を明らかにするのが得意です。これは、エージェント システムに特に当てはまります。モデルは明示的な目標を十分に補うことができますが、暗黙の境界はより厳しい検証を通じて検証する必要があります。受け入れ条件があいまいな説明のままである限り、エージェントがやればやるほど、システムは確率に賭けているように見えてしまいます。

したがって、以前は非常に人間らしいタスクであったコード レビュー、インシデント処理、およびタスクの割り当ては、現在では別の形で行われ始めています。マネージャーはモデルを直接使用します。表面的には効率化が進んでいるように見えますが、実は根底では「管理方法」から「目標管理」へと管理方法を変えているのです。目標が明確に記述されていれば、モデルは機能する可能性があります。目標が明確でない場合、モデルは他のモデルにとって曖昧さを増幅するだけです。

経験と読解力はまだ向上中

Dan Davies 氏が言及した対話型の専門知識と貢献的な専門知識も、この変化に非常に関連しています。モデルは多くの資料を読み込んで適切な判断を下すことができますが、システムを安定させるためには、仕様を読み、結果を確認し、何が問題なのかを知ることができる人が必要です。ここで重要なのは、人々は誰がより賢いかを知るためにモデルと競争すべきではなく、人々は境界を定義する立場に立ち続けるべきであるということです。

ソフトウェアの配信に関しては、この問題はより簡単になります。エージェントが引き継いだ後は、人間の作業は手動での実行ではなく、タスクの分割、境界定義、受け入れ設計、例外処理に重点が置かれるようになります。タスクを引き継ぐことができるかどうかは、その後のコンテキスト管理、モデルのルーティング、およびツールのオーケストレーションが行う価値があるかどうかを明確に決定します。単元が明確でなければ、いくら階層があっても問題を後回しにするだけです。

過去数日間にこれらの断片を読んだ後、私の心に残っているのは、特定のモデル名や新しいフレームワークではなく、より単純な判断です。エージェント システムが最初に強化する必要があるのは、モデルの機能ではなく、作業単位であるということです。ユニットが小さく、受け入れがより厳しく、権限がより厳しい場合、システムは複雑さを制御可能な範囲内に保つことができます。