Agentにはワークフローではなくプリミティブを渡す

Agent用のHarnessは、少数の明確なプリミティブから始め、具体的なツールやワークフローをタスクに応じて生み出せるようにする。

Agentが抽象化のコストを変える

AIがなかった頃、SDKはたいてい合理的なトレードオフだった。認証、ページネーション、リトライ、型変換を開発者の代わりに処理し、複雑なAPIを使いやすい関数に包んでくれる。開発者はコードを書く量を減らし、すべての低レイヤーの詳細を理解せずに済んだ。

しかしAgentは、この損得勘定を変える。

以前は、特定のタスクのために数十行のアダプターを書くにも、エンジニアの時間が必要だった。だから一般的な要求は、あらかじめSDKへ組み込むほうがよかった。今ではAgentがAPIドキュメントを読み、その場のタスクに合わせてリクエストを組み立て、パーサー、アダプター、バッチスクリプトを即座に書ける。一度しか使わないコードの限界コストは、ほぼゼロに近づいている。

そうなると、過度な抽象化はかえって制約になりうる。

SDKは、オブジェクトモデル、パラメーター構造、エラー処理、呼び出し方を利用者に代わって決める。こうした判断は人の認知負荷を下げる一方で、サービスが本来持つ能力を隠してしまうこともある。要件がSDKの想定から少し外れただけで、Agentは抽象化を迂回するか、Harnessに新しい専用ツールが追加されるのを待たなければならない。

必要なツールはAgentに作らせる

それに対して、ドキュメントが明確で、挙動が安定し、状態が見えるAPIは、Agentが直接扱える材料になる。必要に応じてAPIを呼び、レスポンスを観察し、実行ループの中で不足しているツールを作ればよい。APIを呼び、レスポンスを確認し、小さな変換スクリプトを書いて、次へ進む。

そのスクリプトをHarnessの恒久的な一部にする必要はない。将来のあらゆる用途を想定する必要もない。目の前の問題を解ければ十分だ。同じ操作が繰り返され、挙動が安定してから正式なツールに昇格させればよい。

したがって、Harnessの目的は、Agentが必要とするすべての能力を先回りして予測することではない。少数の意味的に完結した基本操作、直接読める明確なドキュメント、生の観察可能な入出力、制御されたコード実行環境、そして権限と不可逆な操作に対する明示的な境界からなる、開かれた操作面を提供することだ。

それでも抽象化すべきもの

リクエスト署名、レート制限、トランザクション整合性のように、複雑だが安定した仕組みは今後も抽象化に向いている。見直すべきなのは、人のプログラミングを楽にするためにあらかじめ決められたオブジェクトモデルや業務フローを、そのままAgentにも渡す必要があるのかという点だ。

優れたHarnessが用意するのは、安定したプリミティブと安全境界だ。現在のタスクに必要なツールは、Agentがそこから作ればよい。

同じ一時的なツールが複数のタスクで繰り返し現れ、インターフェースとエラー処理が安定した時点でHarnessへ取り込む。それまでは、プリミティブを能力へ直接つながる入口として保つ。