StarHarness、モデルを再学習せず企業向けエージェントを進化

企業向けエージェントの失敗は、モデルの推論能力だけでは説明できない。ツールの引数やスキーマが分かりにくい、現場固有の運用ルールが文脈に含まれていない、タスクを実行する順序が適切でない、といった周辺設計の問題も結果を大きく左右する。StarHarnessは、この周辺部分をharnessとして明示的に最適化しようとする。

何を進化させるのか

StarHarnessはモデルの重みを変更せず、環境に合ったharnessを探索する。対象はシステムプロンプトに限られない。タスクの説明方法、ツールインターフェースとデータスキーマ、再利用可能なスキル、MCPを介したプロバイダー、サブエージェントの構成、状態管理、コンテキスト処理、agent loopの設定などを変更できる。

つまり、同じモデルでも「どのような道具と手順を与えるか」を変えることで、実際のタスク遂行能力が変わり得るという考え方だ。研究では、探索を効率化し、過学習を抑えるために複数の設計を組み合わせている。

• 失敗パターンによる層別化：デフォルトharnessでの失敗の仕方に応じてタスクを分類し、異なる問題を含む小規模な進化プールを作る。
• 提案と選択の分離：変更案を作る側が見られる探索タスクと、変更を評価する非公開の選択タスクを分ける。
• 保留タスクによる検証：進化に使わなかったタスクで、検索対象以外への一般化を測定する。

報告された成果

評価対象は、ITBench SRE、EnterpriseOps-Gym ITSM、AutomationBench Financeの3領域だ。論文の概要によれば、環境ごとに約4〜12件の変更を受け入れた段階で、進化後のharnessはデフォルト構成に比べ、ベンチマーク全体の性能を約20〜35ポイント改善した。進化に含めなかったタスクでも改善が確認され、GPT系とQwen系の間でも再進化なしに効果が移転したとされる。関連説明では、評価環境によって推論コストが17〜53％下がったことも報告されている。

ITBenchでは、進化harnessを使うQwen3.5-27Bが、標準harnessで動かしたGPT-5.5を19.2ポイント上回ったという比較も示されている。これは小型モデルが常に優れるという意味ではなく、モデルと環境の接続方法が、能力の測定結果を大きく変え得ることを示す例といえる。

意義と限界

トレース分析では、インターフェースの修正、環境固有の慣行、運用知識の追加が改善に関係していた。これらが探索を短縮し、誤った診断を減らし、一部の設定では実行軌跡も短くしたという。企業導入では、モデルをすぐ交換する前に、ツール設計やコンテキスト管理、実行制御を見直す余地がある。

一方、提供された素材だけでは、進化そのものに必要な計算量、各コンポーネントの個別効果、異なる環境間での移転限界までは判断できない。StarHarnessは、汎用モデル訓練の代替というより、特定環境に合わせたエージェント運用の最適化手法として捉えるのが妥当だ。

出典：Hugging Face Daily Papers