Your Agent Harness Should Repair Itself (8 minute read)｜エージェントハッチは自己修復するべきである（8 分読了） | AIニュース最前線

AI エージェントが本番環境で失敗した際、観測ツールはそれが何をしたかを正確に示しますが、どのように修正すればよいかについてはほとんど何も教えてくれません。 実行のクリーンなトレース、発火したすべてのモデル呼び出しとツール、各ステップにかかった時間、そしてトークンコストが得られます。 しかし、なぜ壊れたのか、それを直す変更は何か、あるいは来週同じことが起きないという保証については何も得られません。 そのため、トレースをスパンごとにスクロールして何が間違っていたかの仮説を立て、手動でパッチを書き、以前動作していたものを壊さないことを祈るしかありません。 すると新しいモデルがリリースされ、新たな失敗モードのバッチと共に、あなたは最初からその手動ループを再び実行することになります。 真のボトルネックは観測ツール自体ではありません。トレースが画面に到着した後に起こらなければならないすべてのことです。 点線の左側にあるものは自動的に実行されます。点線の右側にあるものはあなたの時間で行われるもので、これが本番環境でのデバッグの実態です。 Cursor は最近、彼らのエージェントを取り巻くハッチ（harness）にどれほどのエンジニアリングが費やされているかを共有しました。これは生モデルを囲むプロンプト、ツール、チェックの層のことです。同じモデルでもより良いハッチを使えばはるかに良い結果が得られ、この作業は決して終わることがありません。 これがすべての観測プラットフォームがあなたに残す場所です。それは何が起きたかを答え、次に何故起きたのか、何を修正すべきか、そしてどうすれば再び壊れないようにできるかを返します。 そのギャップこそが、現在の多くのチームが閉じ込められているループです。なぜそれが繰り返し開いてしまうのか、そしてそれを最終的に閉じるために何が必要なのかを以下に説明します。 ほとんどのエージェント観測プラットフォームは、トレースを提供してそこで終わってしまいます。 スパンツリー、レイテンシの数値、トークンコスト、そしてダッシュボードが得られます。しかし、なぜ失敗したのか、何を修正すべきか、あるいは二度と壊れないという保証については何も得られません。 - 「何が起きたか」→ プラットフォームが対応 - 「なぜ起きたか」→ 手動 - 「ここが修正点です」→ 手動 - 「もう二度と壊れません」→ 手動 これは 2023 年であれば妥当な製品でした。しかし、今日プロダクションでエージェントを運用しているチームにとっては、不適切な抽象化です。 この問題は複合的に悪化します。モデルのアップグレードごとに新たな失敗モードが導入され、新しいツールごとに新たなエッジケースが発生します。ハッチ（基盤）は、どのチームも手動で追跡・修復できる速度よりも急速に複雑化していきます。 これを実現するスタックがこちらです。 ほとんどのプラットフォームはダッシュボードで終わってしまい、残りの作業をユーザーに任せてしまいます。右側にあるのは、Opik が独自に実行するループです。 Opik は、AI エージェントおよび LLM アプリケーション向けのログ記録（logging）、デバッグ、最適化プラットフォームです。Opik の構築の前提は、このループを人員配置ではなく自動化すべきものであるという点にあります。 Opik のアーキテクチャは、一つのつながったワークフローです。 トレース → Ollie が診断 → Ollie が修正案を提案 → 修正が適用され検証される → テストスイートでその失敗を回帰テストとして固定 → 再びトレースへ この 4 つの層は別々の機能ではありません。それぞれが単一のループ内で互いに連携し、自動的に完結します。 各層について説明します。 すべての LLM コール、ツール呼び出し、検索ステップは、単一のデコレータ（decorator）によって自動的に計測されます。 ```python import opik ``` @opik.track def my_agent(query: str): # your agent logic here ... LangGraph、CrewAI、および 50 以上のフレームワークと、そのままの状態で連携します。すべてのトレースは、後で失敗した入力を再実行する必要がある際に完全な再現性を確保するために、アクティブだったエージェント構成を記録します。 これら 4 つの層は別々の機能ではありません。それらは互いに補完し合い、自身で閉じる単一のループの中で動作します。 他のすべての観測プラットフォームは「これがあなたのトレースです」で終わりますが、Opik は Ollie によって駆動され、トレースから修正済みのコードへと至ります。 Ollie は Opik に組み込まれたコーディングエージェントです。1 つのエージェントが、完全な文脈を扱います。 サイドパネルで修正を進める Ollie は、各ステップの承認後にのみファイルを読み取り編集します。 コードへのアクセスなしに、Ollie はスパンツリー（span tree）を読み込み、失敗モードを特定し、すべての LLM 呼び出し間の因果連鎖を説明します。「なぜ最終回答が取得された文脈を無視したのか」と尋ねると、Ollie は完全なスパンツリーをたどり、根本原因を浮き彫りにします。 プロジェクトのルートディレクトリから `opik connect` を実行すると、Ollie がフルコード修正モードにアップグレードされます： - ソースファイルを読み取る - 責任のある正確な行を特定する - ダフ（diff）を提案しますが、明示的な承認がない限り何も変更されません 承認後、Ollie は元の失敗トレースからの正確な入力に対してエージェントを再実行し、新しいトレースをストリーミングして並列比較を行い、元の失敗をテストスイート内の回帰ケースとしてロックします。 不良トレース → 根本原因 → ダフ → 承認 → 再実行 → 回帰ロック 悪いトレースから承認という手動ステップを唯一の例外として、ロックされた回帰テストに至るまでの完全なパス。 ほとんどの評価ワークフローは、ラベル付きデータセットの構築、数値指標の定義、浮動小数点値の比較です。このモデルは研究者には機能しますが、エンジニアが品質について考える方法とは一致しません。 Opik はこれを平易な英語によるアサーションに置き換えます。 python suite = opik.TestSuite("crm-agent-v2") suite.add_assertion("The response must include specific deal details, not just a count") suite.add_assertion("The response must never reveal unauthorized information") suite.run_tests() Opik はこれらを内部で LLM-as-a-judge（LLM を判事として用いるチェック）に変換します。各テストケースごとに明確な合格/不合格が得られます。 実際の失敗から構築された回帰スイートであり、各アサーションは平易な英語によるチェックとして記述されています。 ワークフローを変える部分：デバッグしたすべての失敗トレースが自動的に新しいテストケースになります。このスイートは、事前に誰かが作成した合成シナリオではなく、実際の生産環境での失敗から成長していきます。 毎回のサイクルで、ハッチ（harness）を壊すことがより困難になります。 しかし、テストスイートが増え続ける中でも、変更をリリースする前に安全にテストできる場所が必要です。それが Layer 4 の役割です。 ほとんどのプレイグラウンドはプロンプトプレイグラウンドです。システムプロンプトを変更して LLM の呼び出しを再実行するだけです。これは間違った問いに答えることになります。 本番環境での真の問いは、この部分を変更したときに、エージェントグラフ全体に何が起こるかということです。 Opik の Agent Sandbox は、UI 内で完全なインストゥルメント化されたエージェントをエンドツーエンドで実行します。プロンプトを変更し、モデルを交換し、ツールを追加するだけで、全体のスパンツリーにわたるシステムの反応を観察できます。サンドボックスの実行ごとに、完全な Opik のトレースが生成されます。 開発者以外のステークホルダー、PM（プロジェクトマネージャー）、ドメインエキスパート、QA は、git を操作することなく安全に設定をテストできます。 これらのレイヤーは独立した機能ではありません。それらは一つのループです。 .track でインストゥルメント化し、opik.Config を宣言します。本番環境で何かが失敗すると、Ollie がトレースを読み、ソースコードを確認し、修正案を提案します。あなたが承認すれば、Ollie はサンドボックス内で元の失敗した入力に対してエージェントを再実行します。修正が成功したら、それを新しい Blueprint として保存します。環境ポインタはステージングへプロモートされ、元の失敗は回帰テストとしてロックされます。 これは、エージェントのインストゥルメント化から次の失敗がトップに流入するまでをエンドツーエンドで描いた同じループです。 次の失敗も同じループに入ります。 すべてのサイクルを通じて、ハッチ（枠組み）は壊れにくくなっていきます。 エージェントが単純な段階では、トレースで終わる観測可能性（Observability）は理にかなっていました。しかし、本番環境に到達した今、真の作業はトレース後のすべてであり、それがまさに Opik があなたのために実行し、あなたの負担に残さない部分です。 このスタック全体がオープンソースで提供されています。トレーシング、Ollie、テストスイート、Agent Sandbox、6 つのアルゴリズムからなる Agent Optimizer（エージェント最適化器）、そして 50 以上のフレームワーク統合が含まれており、GitHub でのスター数はすでに 19.3K を超えています。 セルフホストは以下の 3 コマンドで可能です： ```bash git clone https://github.com/comet-ml/opik cd opik ./opik.sh ``` Cursor が説明する手動ループとは、Opik が不具合のあるトレースからロックされた回帰テストに至るまで、自らクローズするものです。 プロダクションでエージェントを実行している場合は、ぜひご覧ください。 (スター🌟を忘れないでください) あなたのエージェントスタックにおける観測性の現状はどうでしょうか？また、現在ごチームのデバッグループがどこで破綻していますか？ AI エンジニアに愛されるオープンソースツールを開発されている場合は、ぜひご連絡ください。私たちは自社テストをクリアしたツールのみを取り上げていますので、まずはあなたのツールを試して、その価値が認められれば記事にさせていただきます。 本号のスポンサーである Comet ML 様に感謝いたします。

エージェントハッチは自己修復するべきである（8 分読了）

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

関連記事