LangChainが4段階ループ構成を提示

具体的な社内事例から議論を組み立てる。ドキュメント改善の依頼を受け、変更を計画・起草し、ツールでリポジトリを複製し、ファイルを読み、ドキュメントを書き、プルリクエストを開くドキュメントエージェントだ。この一例が4段階すべてを通るため、抽象的な枠組みより構成をイメージしやすい。

検証段階は採点者を加える。決定論的またはLLM-as-judgeで、ルーブリックに照らして出力を確認し、基準に満たなければフィードバックを返す。ドキュメントエージェントでは、リンクが解決すること、CIチェックが通ること、差分が依頼範囲に収まることをテストで確認する。LangChainはこれが実行ごとの遅延とコストを増やすと率直に認め、大半の本番ケースでは速度より品質を取るトレードオフだと位置づける。

上位の段階では、エージェントは呼び出すものから、より大きなシステム内で動く部品へと変わる。イベントのトリガーはcronスケジュールやLangSmith Deployment経由のwebhook、あるいはFleetのチャネルやスケジュールから来る。ドキュメントエージェントは#docs-plz Slackチャネルにメッセージが届くたびに起動する。第4ループでLangChainは最も強い主張をする。トレースには何が機能しているかのシグナルが含まれ、分析エージェントがハーネス（プロンプト、ツール、採点者の調整）を書き換えられる。戻り矢印はエージェントループの内部に及び、単に再起動するのではない。今後については、同じループがオープンウェイトモデルを使うチームのRL微調整や、メモリ・取得スキルの改善にも使えると示唆する。ただしループが何を最適化するかはチームによって異なるという留保付きだ。