AIエージェントの現状についてのランダムな暴言:

エージェントとは呼ばない人もいますが、決定論的なフローを持つ「ワークフローエージェント」はどこにでもあり、機能します。誰でも簡単なワークフローエージェントを構築でき、Zapierやn8nなどのノーコードツールから始めても構いません。複雑なワークフローエージェントは、確実かつ効率的に構築するために、より多くの思考を必要とします。関連する統合が組み込まれた、共通で価値のあるユースケースのための複雑なワークフローは、ビジネスとして単独で立つことができ、後で他のワークフローやより自律的な作業に拡張するための優れたGTMでもあります。

より動的/自律的なエージェントが機能し始めており、研究(特にWebベースの場合)とコーディングに役立ちます。データソース(APIなど)の追加を開始すると、信頼性が低下します。読み取り専用エージェントは安全でテストが簡単だと感じますが、自律エージェントにアクション(書き込み)を実行させるのは恐ろしいことです。(これに関するランダムなアイデア:CRMのようなツールで開発ミラーを「フォーク」し、ロールバックまたはマージバックできる自動化実験を実行できるとしたら、それは素晴らしいことです。

動的エージェントは、(1) 適切な計画を作成して追跡し、(2) タスクを正しく実行し、(3) 各ステップ (計画と各タスクの両方) に入力する適切なコンテキストを見つけることができる場合にうまく機能します。最後に、(4) 計画を適切に調整し、失敗したタスクやパフォーマンスの低いタスクの実行方法を改善するために、(人間の入力の有無にかかわらず) 途中で反映する必要があります。

タスク計画:LLMの推論能力 プライベートなコンテキストを必要としない単純なタスクリスト(詳細な調査など、要約中の一連のWeb検索など)では問題なく機能します。多くのエンティティを調査したい場合、タスクリスト管理が比較的基本的なため、深い調査はうまくいきません。スプレッドシートベースのAIツールは、プロンプト間で長いタスクリストを渡すとうまく機能しないため、タスク管理をスプレッドシートに効果的にオフロードするため、多くのエンティティの調査に適しています。コーディングエージェントのタスク管理は、単純な問題、単純なコード、またはゼロから始める場合に機能します。より複雑な既存のプロジェクトに入ると、信頼性が低下し、開発者はコードがどのように機能し、整理されているか (.md ファイル) ことを文書化することで信頼性を高め、エージェントがより適切な情報に基づいたタスク リストを作成できるようにします。複雑なコードにはより多くのドキュメントが必要であり、最終的にはそれらのドキュメントから関連するコンテキストのみを動的に取得します。多くの人々/企業は、プロジェクトに取り組むための正しい順序/アプローチ/ツールについて文書化されていない強い意見を持っており、これを事前にその場で文書化するためのより多くのアプローチが必要です。コーディングとWebベースのリサーチエージェントがうまく機能するもう一つの理由は、すべて同じツールセットを使用しているため、それらのツールの使用方法を「学ぶ」必要がないことです(これについては後述します)。

タスクの実行: タスクは通常、API 呼び出し (API の使用方法と基礎となるデータ構造 (カスタム テーブル/列を持つ CRM や DB のように一意である可能性がある) の認証と理解が必要です)、LLM 推論 (要約など)、組み合わせ、さらにはワークフロー エージェント*です。リサーチエージェントは、実際にはループ内のWeb検索と要約にすぎません。コーディングエージェントはコードベースのCRUDであり、学習APIのWeb検索かもしれません。認証と基本的なAPIアクセスは解決されたように感じますが(MCPはここに適合します)、ツール固有のコンテキストについてもっと見たいです(ユーザーに尋ねるだけでなく、最初の接続時に分析し、既存のデータを掘り下げてツールがどのように使用されているか、データがどのように構成されているか、ツールを使用するシナリオ/プロジェクトを理解します)、エラー/リフレクション/フィードバックは、関連するときにコンテキストとしてフィードバックされる組織化された学習に変換する必要があります。同じツールを組織間で異なる目的や方法で使用することができ、タスクをうまく実行するには、これを何らかの方法でキャプチャ/文書化する必要があります。

コンテキスト: 会社の新入社員を想像してみてください。オンボーディング中に多くのことを学び(オンボーディングが優れれば良いほど、最初からより効果的になります)、そして仕事での学習は、組織の経験から学ぶ(「これが私たちのやり方です」)と、自分の経験から学ぶことに分かれます。コンテキスト管理も同様です。メタ(ユーザー/会社)、プロジェクト/部門固有、タスク固有、ツール固有などのコンテキストの層があります。単純なシステムプロンプトからハイブリッドRAG戦略(ベクトル、キーワード、グラフ)へと進化しましたが、データ/コンテキストだけでなく、コンテキストをいつ、どのように取得するかについてのガイダンスが必要です。これは単なる技術的な問題ではなく、ビジネス上の問題でもあり、基本的には、予想されるすべてのシナリオをカバーするオンボーディング ドキュメントを作成する必要があります。プロジェクトが複雑になるにつれて、無関係なコンテキストを最小限に抑えながら、関連する情報のみがプロンプトに含まれるようにコンテキストを正しく剪定するには、より思慮深いものが必要になります。

振り返り: LLM/API のコストや観察をカバーするエージェント監視ツールがありますが、成功/失敗の割り当ては課題です - コーディング エージェントが他のエージェントよりも優位に立つ領域の 1 つは、(コードのテストを通じて) 失敗に気付く決定論的な方法です。他の多くのエージェントタスクについては、将来のアウトプットを改善するために人間の入力を収集する正しい方法をまだ考えているところです。AFAIK、今日のリフレクションはヒューマン・イン・ザ・ループであり、フィードバックは主にエージェントを改善するために人間の開発者に供給されていますが、リフレクションを自己改善に変える方法、つまりエージェントがタスクリストの生成とタスク実行の失敗から洞察を得て、次回はより良い結果を得る方法を見つけたときにロックが解除されます。基本的に、リフレクションは、適切なときにのみプロンプトに取り込むことができる、適切に整理されたコンテキストに変換する必要があります。これはエージェントの微調整部分に進化し、次にエージェントのRL環境に進化します-ここではまだかなり早いように感じます

*先ほど、ワークフローエージェントにタスクを渡すことについて述べましたが、エージェントがツールとしてワークフローエージェントを持たないことで恩恵を受ける場合(毎回既知のタスクリストを理解するのではなく)、システムが十分に複雑で、特殊なコンテキストとツールを備えた専門エージェントのパフォーマンスが向上している場合に、これは意味を持ち始めます。または、他の PPL によって構築されたエージェントを活用している場合 (ここで見始めたパターンの 1 つは、エージェントのコラボレーションを容易にするための自然言語 API エンドポイントです)。

無限のコンテンツ ウィンドウ (品質の低下なし)、無限のコンピューティング、無限のストレージ、ブラウザ アクセス、および支払い方法を備えた今日のモデル品質があれば、1 つの LLM ループで多くのことを成し遂げるのに十分でしょう 上記の無意味な点 (無限のものはありません) のポイントは、エージェント オーケストレーションは主に、構造とコードを通じて LLM から作業をオフロードする方法を設計することにより、制限を管理することです。

本番環境におけるエージェントには、内部ツールとして、さまざまなツールを組み合わせたスタンドアロン製品として、コアツールの機能として組み込まれるなど、さまざまな種類があります。それらは一般的なものでも特殊なものでもかまいません。チャット、音声、バックグラウンド エージェントは、エージェント フローをトリガーするための最も一般的な UI インターフェイスのようです。

他に何が欠けているのでしょうか?