ハーネスエンジニアリングによる深層エージェントの改善

TLDR: 当社のコーディングエージェントがTerminal Bench 2.0でトップ30からトップ5に躍進しました。変更したのはハーネスだけです。これが当社のハーネスエンジニアリングへのアプローチです（予告: 自己検証とトレースが大いに役立ちます）。 ハーネスエンジニアリングの目標 ハーネスの目標は、モデルが本質的に持つ「突出した知性」を、私たちが重視するタスクのために形成することです。ハーネスエンジニアリングはシステムに関するものであり、タスクのパフォーマンス、トークン効率、レイテンシなどの目標を最適化するために、モデルの周囲にツーリングを構築します。設計上の決定事項には、システムプロンプト、ツールの選択、実行フローなどが含まれます。 しかし、エージェントを改善するために、ハーネスをどのように変更すべきでしょうか？ LangChainでは、大規模なエージェントの失敗モードを理解するために「トレース」を使用しています。現在のモデルは大部分がブラックボックスであり、その内部メカニズムを解釈するのは困難です。しかし、私たちはテキスト空間におけるそれらの入出力を確認することができ、それを改善のフィードバックループに利用しています。 私たちは、deepagents-cli（当社のコーディングエージェント）を13.7ポイント向上させるために、単純なレシピを用いて反復的に改善を行いました。 実験のセットアップとハーネスの調整項目 私たちはTerminal Bench 2.0を使用しました。これは現在、エージェント型コーディングを評価する標準的なベンチマークとなっています。機械学習、デバッグ、生物学などの分野にわたる89のタスクがあります。実行を調整するためにHarborを使用しています。Harborはサンドボックス（Daytona）を起動し、エージェントループと対話し、検証とスコアリングを実行します。 すべてのエージェントのアクションはLangSmithに保存されます。また、レイテンシ、トークン数、コストなどのメトリクスも含まれます。 調整可能な項目 エージェントハーネスには多くの調整項目があります：システムプロンプト、ツール、フック/ミドルウェア、スキル、サブエージェントへの委譲、メモリシステムなどです。私たちは意図的に最適化空間を圧縮し、三つに焦点を当てました：システムプロンプト、ツール、およびミドルウェア（モデルとツール呼び出しの周囲のフックを指す当社の用語）です。 デフォルトのプロンプトと標準的なツール+ミドルウェアから始めます。これはGPT-5.2-Codexで52.8%のスコアでした。堅実なスコアで、現在のリーダーボードのトップ30のすぐ外ですが、成長の余地があります。 トレースアナライザースキル トレース分析を繰り返し可能にしたいと考え、それをエージェントスキルにしました。これは、複数の実行にわたるエラーを分析し、ハーネスを改善するための私たちのレシピとして機能します。フローは以下の通りです： LangSmithから実験トレースを取得する 並列エラー分析エージェントを生成 → メインエージェントが調査結果と提案を統合する フィードバックを集約し、ハーネスに対して的を絞った変更を加える。 これは、以前の実行からのミスに焦点を当てるブースティングと同様に機能します。ステップ3では、提案された変更を検証し議論するために、人間が非常に役立つ場合があります（必須ではありません）。特定のタスクに過剰適合する変更は一般化に悪影響を及ぼし、他のタスクでの後退を引き起こす可能性があります。 自動化されたトレース分析は何時間もの時間を節約し、実験を素早く試すことを容易にしました。私たちはこのスキルを近日中に公開する予定で、現在、一般的なプロンプト最適化のためにテスト中です。 実際にエージェントのパフォーマンスを改善したもの 自動化されたトレース分析により、エージェントがどこで間違っていたのかをデバッグすることができました。問題には、推論エラー、タスク指示の不遵守、テストと検証の欠如、時間切れなどが含まれていました。これらの改善点については、以下のセクションで詳細に説明します。 構築と自己検証 今日のモデルは、卓越した自己改善マシンです。 自己検証により、エージェントは1回の実行内でフィードバックを通じて自己改善することができます。しかし、彼らには自然にこの「構築-検証」ループに入る傾向はありません。 最も一般的な失敗パターンは、エージェントが解決策を書き、自身のコードを再読し、問題なさそうだと確認し、停止するというものでした。テストは自律的なエージェント型コーディングの重要な部分です。それは全体的な正確性をテストするのに役立ち、同時に、エージェントが「丘登り」を行うためのシグナルを与えます。 私たちは、問題解決へのアプローチ方法について、システムプロンプトにガイダンスを追加しました。 計画と調査: タスクを読み、コードベースをスキャンし、タスク仕様と解決策の検証方法に基づいて初期計画を立てる。 構築: 検証を念頭に置いて計画を実装する。テストが存在しない場合はテストを構築し、正常系とエッジケースの両方をテストする。 検証: テストを実行し、出力全体を読み、求められたものと比較する（自身のコードと比較しない）。 修正: エラーを分析し、元の仕様を再確認し、問題を修正する。 私たちは、テストが各イテレーションの変化を促進するため、テストに特に焦点を当てています。プロンプティングと並行して、決定論的なコンテキスト注入がエージェントの作業検証に役立つことを発見しました。私たちはPreCompletionChecklistMiddlewareを使用しています。 エージェントに環境に関するコンテキストを与える ハーネスエンジニアリングの一部は、コンテキストエンジニアリングのための優れた配信メカニズムを構築することです。Terminal Benchのタスクには、ディレクトリ構造、組み込みツーリング、厳格なタイムアウトが付属しています。 ディレクトリコンテキストとツーリング: LocalContextMiddleware テスト可能なコードを書くことをエージェントに教える: エージェントは、自身のコードがどのようにテスト可能である必要があるかを知りません。私たちは、彼らの作業がプログラムによるテストに対して測定されることを示すプロンプトを追加します。これは、コードをコミットするときと似ています。例えば、ファイルパスに言及するタスク仕様は、自動採点ステップで解決策が機能するように、正確に従うべきです。エッジケースを強調するプロンプティングは、エージェントが「正常系」ケースのみをチェックすることを避けるのに役立ちます。モデルにテスト標準に準拠させることは、時間の経過とともに「ずさんさが蓄積する」ことを避けるための強力な戦略です。 時間予算: 私たちは時間予算の警告を注入し、エージェントに作業を終了して検証に移行するよう促します。エージェントは時間見積もりが非常に苦手で有名なので、このヒューリスティックはこの環境で役立ちます。現実世界のコーディングには通常厳格な時間制限はありませんが、制約に関する知識を何も追加しないと、エージェントは時間制限内で作業しません。 エージェントが自身の環境、制約、評価基準についてより多く知るほど、彼らは自律的に自身の作業を方向付けることができます。 ハーネスエンジニアの目的: エージェントが自律的に作業を完了できるように、コンテキストを準備し提供することです。 エージェントに一歩引いて計画を再考するよう促す エージェントは、一度計画を決めると近視眼的になることがあり、同じ破綻したアプローチに小さなバリエーションを加える「破滅ループ」に陥ります（一部のトレースでは10回以上）。 私たちはLoopDetectionMiddlewareを使用しています。 重要な注意点。これは、現在認識されているモデルの問題をエンジニアリングする設計ヒューリスティックです。モデルが改善されるにつれて、これらのガードレールはおそらく不要になるでしょうが、今日ではエージェントが正確かつ自律的に実行するのに役立ちます。 推論にどれだけの計算リソースを費やすかを選択する 推論モデルは何時間も自律的に実行できるため、各サブタスクにどれだけの計算リソースを費やすかを決定しなければなりません。すべてのタスクで最大の推論予算を使用することもできますが、ほとんどの作業は推論計算コストの最適化から恩恵を受けることができます。 Terminal Benchのタイムアウト制限はトレードオフを生み出します。より多くの推論はエージェントが各ステップを評価するのに役立ちますが、2倍以上を消費する可能性があります。 私たちは、推論が問題を完全に理解するための計画に役立つことを発見しました。Terminal Benchのタスクには非常に難しいものもあります。良い計画は、機能する解決策により迅速に到達するのに役立ちます。 後期段階の検証も、ミスを見つけて解決策を提出するために、より多くの推論から恩恵を受けます。ヒューリスティックとして、私たちは「xhigh-high-xhigh」の「推論サンドイッチ」をベースラインとして選択します。 xhighのみで実行するのは、計画には良いですが、検証には不十分です。 モデルにとって自然なアプローチは適応推論です。ClaudeやGeminiモデルに見られるように、モデルが推論にどれだけの計算リソースを費やすかを決定します。 マルチモデルハーネスでは、推論予算のバランスを取ることは、計画には大規模モデルを使用し、実装にはより小さなモデルに引き渡すという形で展開される可能性があります。 エージェントハーネス構築のための実用的な要点 エージェントの設計空間は広大です。以下は、私たちの実験とdeepagents全体の構築から得られた一般的な原則です。 エージェントに代わって行うコンテキストエンジニアリング。コンテキストの組み立ては、今日のエージェントにとって依然として困難です。特に未知の環境ではそうです。ディレクトリ構造、利用可能なツール、コーディングのベストプラクティス、問題解決戦略などのコンテキストでモデルをオンボーディングすることは、不適切な探索によるエラー面を減らし、計画における回避可能なエラーを防ぐのに役立ちます。 エージェントが自身の作業を自己検証するのを助ける。モデルは、最初に思いついたもっともらしい解決策に偏る傾向があります。彼らに積極的に検証するよう促し、

ハーネスエンジニアリングによる深層エージェントの改善

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト