12ファクター・エージェント 5.実施状況と運用状況の調和

さて、この時点でマークダウン・ファイルは1000行を超えた。これはほとんどお遊びだ。

もしあなたがhumanlayerの紹介を待ち望んでいたのなら、これがそれだ。もしあなたが要素6「シンプルなAPIを介した開始／一時停止／再開」と要素7「ツールコールを介した人間とのコンタクト」を実践しているなら、この要素を統合する準備はできています。 ユーザーがAPIから開始/一時停止/再開できるようにする。

何でもこなそうとする一枚岩のインテリジェンスを構築するのではなく、一つのことをうまくこなせる、小さく集中したインテリジェンスを構築する方がいい。インテリジェンスは、より大きな、大部分は決定論的なシステムにおける1つの構成要素にすぎない。 ここでの重要な洞察は、大きな言語モデルの限界である。

これは些細な点だが、言及する価値がある。エージェントの利点の一つは "自己修復 "です。短いタスクの場合、大規模な言語モデル（LLM）は失敗したツールを呼び出すかもしれません。優れたLLMは、エラーメッセージやスタックトレースを読み取ることができる可能性が高い。

自分のコントロール・フローをコントロールできれば、多くの興味深い機能を実装できる。 特定のユースケースに適合するカスタム制御構造を構築する。具体的には、ある種のツール・コールは、ループから飛び出したり、人間が応答するのを待ったり、別の長時間実行タスク（例えばトレーニング・パイプライン）を待ったりする理由になるかもしれない...。

デフォルトでは、ラージ・ランゲージ・モデル（LLM）APIは、基本的にステークスの高いトークンの選択に依存している：プレーン・テキストのコンテンツを返すのか、それとも構造化データを返すのか？ あなたは最初のトークンの選択に重きを置いていますが、それは東京の天気の場合...

インテリジェンスはプログラムであり、何らかの方法で起動、クエリ、再開、停止できることが期待される。 ユーザー、アプリケーション、パイプライン、その他のインテリジェンスは、シンプルなAPIで簡単にインテリジェンスを開始できるはずだ。 長時間実行されるオペレーションが必要な場合、インテリジェンスとそのオーケストレーションの決定論的コード...

ツールは複雑である必要はない。ツールの核心は、ラージ・ランゲージ・モデル（LLM）からの構造化された出力が、決定論的なコードをトリガーするために使用されることだ。 例えば、CreateIssueとSearchIssueの2つのツールがあるとします。ラージ・ランゲージ・モデル（LLM）に「複数のツールのうちの1つを使用する」ように要求することは、実際には...を出力するように要求することです。