ループエンジニアリングの美学（The Art of Loop Engineering）

• エージェントを安定して有用な作業に活用するには、優れたモデルだけでは不十分であり、作業セットに合わせて設計された**ハーネス（harness）**が必要
• 最も基本となるエージェントループは、LLMにコンテキストを与え、作業が完了するまでツールを繰り返し呼び出す構造
• ここに検証ループ、イベント駆動ループ、ヒルクライミングループを**積み重ねる（stacking）**方式で、より効果的なエージェントを構成
• 各ループ階層はLangChainプリミティブで計測（instrument）でき、社内ドキュメント作成エージェントを例に説明
• 真の潜在力はモデルそのものではなく、エージェントを取り囲んで構築するループにある

---

Loop 1: エージェントループ

• エージェントは本質的に、作業が完了するまでツールを繰り返し呼び出すモデル
• LangChainのcreate_agentがこのループを提供し、モデルを選び、**ツール（tools）**を接続すれば動作するエージェントループが完成
  • ツールは、エージェントが現実世界で行動を起こせるようにする要素
• 社内ドキュメントエージェントの例では、最初のループ段階はドキュメント改善リクエストを受け取り、モデルが変更内容を計画・下書きし、repoのクローン、ファイルの読み取り、文書作成、**プルリクエスト（pull request）**の作成などにツールを使う

Level 2: 検証ループ

• エージェントループは作業を処理するが、最初の試行で常に正確または一貫した結果を出すわけではなく、一貫性が重要なときは出力を点検し、不十分ならフィードバックをモデルに戻す検証ループで包む
• 検証ループは**グレーダー（grader）**を追加してエージェント出力をルーブリック（rubric）に照らして評価し、失敗時はフィードバックとともに結果を差し戻す
  • グレーダーは決定論的にもエージェント型にもでき、LLM as a judgeが典型例
  • RubricMiddlewareがこのパターンを処理するか、create_agentのafter_agentフックで接続可能
• 文書作成の例では、グレーダーは各試行後にテストを実行し、すべてのリンクが正常動作すること、すべてのCIチェックが通ること、diffが要求範囲に限定されていることを確認し、手動レビューなしでエラーの種類を捉える
• 検証を追加すると実行ごとのレイテンシとコストは増えるが、速度より品質が重要な大半の本番用途では価値がある

Level 3: イベント駆動ループ

• エージェント開発で最も重要な部分の1つは**統合レイヤー（integrations layer）**であり、エージェントをエコシステムに接続してバックグラウンドで実行できるようにする
• イベント駆動ループは、新しい文書の到着、スケジュールの発火、Webhookの到着といったイベントが発生するとエージェントを実行する
  • エージェントは手動で呼び出す対象ではなく、より大きなシステムの中で継続的に動作する構成要素
• LangSmith Deploymentがトリガー基盤をサポートし、cronスケジュールとWebhookを支援
  • cron活用の人気例はopenclawのheartbeatsで、エージェントを常時稼働する能動的アシスタントへと変える
• ドキュメントエージェントはノーコードのエージェントビルダーFleetで動作し、Fleetのchannelsとschedulesがイベント駆動・cronトリガーを処理
  • #docs-plz Slackチャンネルにメッセージが来ると、そのチャンネル経由でドキュメントエージェントを実行

Level 4: ヒルクライミングループ

• 前の3つのループが作業を自動化するなら、4つ目のループは改善（improvement）そのものを自動化する
• すべてのエージェント実行は、モデルの振る舞い、呼び出したツール、グレーダーのフィードバックなどを記録した**トレース（trace）**を生成し、このトレースには何が機能し、何が機能していないかについて価値の高いシグナルが含まれる
• ヒルクライミングループはトレースに対して分析エージェントを実行し、その結果としてハーネス構成を改善された設定に書き換える
  • これにはプロンプト／ツールの調整やグレーダー調整が含まれる
  • LangSmithでは、トレース分析エージェントEngineによってこの第4のループを計測する
• ドキュメントエージェントの例では、engineをトレースに対して実行して問題を検出し、複数のトレースが潜在的な問題を示した場合、問題のあるプロンプトやツールの変更を求めるissueが登録される
• 重要なのは、戻り矢印が単に最上部へ戻るのではなく、内側に入り込んでエージェントループ自体を直接更新する点であり、外側ループの各サイクルが内側ループをより効果的にする

• 今後の展望

  • プロンプトとツール構成は最も改善しやすいが唯一の選択肢ではなく、オープンウェイトモデルを運用するチームはヒルクライミングループをRLファインチューニングにつなげ、トレースや評価結果を学習シグナルとしてモデル自体を改善できる
  • メモリ、検索されたスキルのような補助コンテキストも同じ方法で改善でき、ループはパターンであり、何を最適化するかはユーザー次第

人間の監督と専門性

• 自動化は人間をループから排除することを意味せず、すべての階層に人間の監督が価値を加えるポイントが存在する
  • 自動グレーダーはリンクが正常に動作するか確認できるが、対象読者に対するフレーミングが誤っていることに気づくのは人間の役割であり、文脈・経験・見識に基づく判断が人間レビューを必要とする部分
• 一部の専門性はプロンプト／ツール自体にコード化すべきだが、金融取引やDB作業のような機微な行動にはリアルタイムの人間レビューが不可欠
• LangChainはすべてのループでこの接点を計測しやすいよう支援している
  • エージェントループ: 機微な行動／ツール呼び出しの前に人間の入力を要求
  • 検証ループ: 機微なワークフローで人間がグレーダー役を担う
  • アプリケーションループ: 最終ユーザーへ返す前に人間が出力を承認
  • ヒルクライミングループ: デプロイ前にハーネス改善を人間レビューで通す
• すべてのLangChainオープンソースフレームワークはhuman in the loopを第一級プリミティブとして提供

総合まとめ

• 4つのループが積み重なる方式の要約
  • エージェントループ: 作業完了までモデルがツールを繰り返し呼び出す → 作業自動化、プリミティブはcreate_agentおよびLangChain対応モデル
  • 検証ループ: 出力をルーブリックで採点し、失敗時はフィードバックとともに再試行 → 作業品質・正確性を保証、プリミティブはRubricMiddleware
  • イベント駆動ループ: イベントが実システムを更新するエージェント実行をトリガー → 大規模な作業自動化、プリミティブはcronトリガー／WebhookベースのLangSmith DeploymentまたはFleet channels
  • ヒルクライミングループ: 本番実行トレースが分析エージェントを通じてハーネス構成を改善 → ハーネス改善、プリミティブはLangSmith Engine
• これがswyxのいうloopcraft、すなわち実際のループエンジニアリングの姿であり、Steipete・Boris・Andrejのようなリーダーたちも、エージェントの潜在力はそれを取り囲んで構築するループにあるという同じ結論に達している
• ループ1・2は長く扱われてきたが、これからはエージェントをエコシステムに組み込み、基準に従って継続的に改善され、価値が複利的に積み上がるループ3・4へと焦点を移すべき
• Satyaは組織レベルの利害関係に触れ、人間の判断とトークン資本がともに複利的に積み上がる学習ループを早期に構築する企業が、複製しにくい優位性を確保すると述べている