この記事は、1 つの問いに答えることを目指している。本番環境の顧客の手に渡せるほど優れた LLM 搭載ソフトウェアを構築するには、どのような原則を用いればよいのか、という問いである。記事は GitHub 上の元祖 12 Factor Agents の文書に基づいており、12 Factor Apps の形式にならっている。著者は、多くのエージェントフレームワークを試した結果、「AI エージェント」と銘打たれた製品のほとんどはそれほどエージェント的ではなく、大部分は決定論的なコードで、適切な箇所に LLM のステップが置かれているだけだとわかったと報告している。また、顧客向けのエージェントを構築している創業者たちと話したところ、そのほとんどはフレームワークを使わずに独自のスタックを自作していたという。
「プロンプト、ツールの詰め合わせ、目標に達するまでループ」という素朴なパターンに対する記事の反論は、コンテキストウィンドウが長くなるとエージェントは迷走し、同じ破綻したアプローチを繰り返してしまうというものである。記事は、モデルがより長いコンテキストウィンドウをサポートするようになっても、小さく焦点の絞られたプロンプトとコンテキストのほうが常に良い結果をもたらすと主張し、実際にうまくいくのは「マイクロエージェント」、つまり、大部分が決定論的なより大きなワークフローの中で、範囲がよく絞られたタスクにエージェントパターンを用いることだとしている。その具体例は HumanLayer が運用しているデプロイボットで、決定論的なコードがステージングとテストを処理し、本番デプロイを小さなエージェントに引き渡し、各デプロイ呼び出しを人間が承認する。
要点
- エージェントは 4 つの部分から成ると説明される。LLM に次のステップの JSON 記述を出力させるプロンプト、その JSON をどう扱うかを決める switch 文、それまでに起きたことを蓄積したコンテキスト、そして LLM が終了ステップを出力するまで繰り返すループである。
- Factor 1、自然言語からツール呼び出しへ：リクエストを構造化オブジェクトに変換し、それを決定論的なコードが実行する。
- Factor 2、プロンプトを自分で所有する：フレームワークのブラックボックスなプロンプト構築に頼るのではなく、制御、テストと評価、反復、透明性のために、プロンプトを第一級のコードとして扱う。
- Factor 3、コンテキストウィンドウを自分で所有する：任意の時点での LLM への入力は「これまでに起きたことはこれで、次のステップは何か」であり、記事は標準的なメッセージ形式の代わりに、トークン効率と注意効率の高い独自のコンテキスト形式（例えば、履歴全体を XML 風のイベントとして 1 つのユーザーメッセージに詰め込む）を用いるべきだと論じる。記事は「すべてはコンテキストエンジニアリングである」と述べ、コンテキストエンジニアリングという用語は 12-factor agents の公開からおよそ 2 か月後に広まったと記している。
- Factor 4、ツールは単なる構造化出力である：ツール呼び出しは決定論的なコードを起動する JSON であり、そのコードが毎回決まった対応する関数を実行する必要はない。
- Factor 5、実行状態とビジネス状態を統合する：可能であれば、実行状態（現在のステップ、待機状態、リトライ）を別途追跡するのではなく、コンテキストウィンドウから推論する。
- Factor 6、シンプルな API で起動・一時停止・再開する：エージェントは簡単に起動でき、長時間かかる処理のために一時停止でき、Webhook のような外部トリガーから再開できるべきである。
- Factor 7、ツール呼び出しで人間に連絡する：LLM には常に JSON を出力させ、人間に入力を求めるといった意図を構造化された呼び出しとして表現させる。記事はこれを、人ではなくイベントや cron によって起動される「アウターループ」エージェントに結び付けている（アウターループ を参照）。
- Factor 8、制御フローを自分で所有する：人間や長時間かかるタスクを待つためにループから抜け出せる制御構造を構築する。著者があらゆるフレームワークに対して最も求めているのは、ツールの選択とツールの呼び出しの間に割り込み、呼び出しが実行される前にレビューできるようにする機能である。
- Factor 9、エラーをコンテキストウィンドウに圧縮する：モデルが自己修正できるようにエラーをフィードバックするが、上限（例では連続およそ 3 回の試行）を設け、それを超えたらエスカレーションする。
- Factor 10、小さく焦点の絞られたエージェント：各エージェントをおおよそ 3〜10、多くても 20 ステップ程度に抑えてコンテキストを扱える範囲に保ち、モデルがより長いコンテキストでも信頼できるようになるにつれて初めて範囲を広げる。
- Factor 11、どこからでもトリガーする：ユーザーが Slack、メール、SMS などのチャネルからエージェントを起動でき、エージェントが同じチャネルを通じて返答できるようにする。記事はこれを HumanLayer の売り込みだと公然と認めている。
- Factor 12、エージェントをステートレスなリデューサーにする：著者はこれを「ほとんどただのお遊び」として提示している。
背景
この記事は、測定に基づく比較ではなく、エージェントを構築し創業者たちと話してきた著者自身の経験から書かれており、繰り返し述べられる但し書きは、著者は最良のプロンプトやコンテキスト形式を知っているわけではなく、構築者があらゆることを試せる柔軟性を必要としていることだけを知っている、というものである。この記事は部分的に HumanLayer の製品の売り込みでもあることを公然と認めている。このウィキの関連ページには、コンテキストエンジニアリング、関数呼び出し、ヒューマン・イン・ザ・ループ、そして同じ発行元による コーディングエージェントのための高度なコンテキストエンジニアリング がある。