オリジナルソース: Agent Harness: Working with your data, safely
これは今年のエンジニアリング記事の中でも特に有用なもののひとつである。なぜなら、デモファーストの自律性という一般的な罠を拒否し、代わりにエージェントが実際のユーザーデータと現実の結果の周りでどのように動作すべきかに焦点を当てているからだ。
ここで強調されている3つの構成要素は完全に正しい。
- ファイルアクセスにより、エージェントはユーザー所有のデータに基づいた有用な判断ができるようになる。
- 承認ゲーティングにより、結果を伴うアクションの無言実行を防止する。
- 永続メモリにより、制御を犠牲にすることなく反復的なやり取りを回避する。
ほとんどのチームはツールの幅に過剰投資し、アクセス許可のセマンティクスに過小投資している。それは逆である。10のツールと弱い承認境界を持つエージェントよりも、3のツールと予測可能な制御ポイントを持つエージェントの方が価値が高い。
この記事で最も優れた実践的パターンは階層型承認戦略である:
- 常に承認を要求: 取引や破壊的操作など、影響の大きいツールに対して。
- 自動承認: リスクの低い読み取りはフローを維持するために自動承認する。
- スコープ付きスタンディング承認: セッション内で反復される信頼済みアクションに対して使用する。
これにより健全なリスク勾配が生まれる。ユーザーは無害な読み取りのために中断されることはないが、結果が高コストまたは不可逆的になる場合にはループに留まる。
また、ファイルメモリとFoundry メモリの明確な分割も気に入っている。チームはひとつのメモリモデルですべての問題を解決しようとするのをやめるべきだ。レポートやウォッチリストのようなユーザー可視状態には、粗く明示的なファイルアーティファクトが最適である。事実レベルのメモリ抽出は、好みや会話のコンテキストに適している。両方を混在させることで、どちらか一方だけでは不十分だと見せかけるよりも良い結果が得られる。
私の意見を明確に述べると、エージェントの品質は今後、巧妙なプロンプトよりも安全エルゴノミクスによって測定されるようになる。承認プロンプトがノイジーであれば、ユーザーは盲目的にクリックスルーする。メモリ境界が不明確であれば、ユーザーはアシスタントを信頼しなくなる。データアクセスのデフォルトが寛容であれば、セキュリティチームがプロジェクトを停止させる。
このパターンを採用する .NET および Python チームにとって重要なのは、ポリシーコールバックと承認ルールを中核的なビジネスロジックとして扱い、他の重要なコードと同様にバージョン管理およびテストすることである。サンプルに埋もれたアドホックなラムダ式のままにしてはいけない。
結論
信頼を勝ち取るエージェントシステムとは、最も多くをこなすものではない。ユーザーが意図したことを、過不足なく、リスクが高まったときには明確な中断ポイントを備えて実行するものである。
それが、印象的なデモと、人々が実際の作業を委任したいと思うソフトウェアとの違いである。
