AIエージェントの現状に関するランダムな愚痴:
エージェントと呼ばない人もいますが、決定論的なフローを備えた「ワークフローエージェント」はどこにでもあり、機能しています。Zapierやn8nなどのコード不要のツールを使って始めても、シンプルなワークフローエージェントは誰でも構築できます。複雑なワークフローエージェントを信頼性と効率性を持って構築するには、より多くの考慮が必要です。一般的な価値あるユースケースのための複雑なワークフローは、関連する統合が組み込まれており、ビジネスとして独立して機能するだけでなく、後で他のワークフローやより自律的な作業に拡張できる優れたGTMにもなります。
より動的/自律的なエージェントが動作し始めており、研究（特にWebベースの場合）やコーディングに役立ちます。データソース（APIなど）を追加すると信頼性が低下します。読み取り専用エージェントは安全でテストも簡単ですが、自律エージェントにアクション（書き込み）を実行させるのは不安です。（これに関するランダムなアイデア：CRMなどのツールを使用して開発ミラーを「フォーク」し、ロールバックまたはマージできる自動化実験を実行できれば素晴らしいと思います。）
動的エージェントは、(1) 適切な計画を作成して追跡し、(2) タスクを正しく実行し、(3) 各ステップ (計画と各タスクの両方) に適切なコンテキストを提供できる場合にうまく機能します。最後に、(4) 途中で反映 (人間の入力の有無にかかわらず) して、計画を適切に調整し、失敗したタスクやパフォーマンスの低いタスクの実行方法を改善する必要があります。
タスク計画：LLMの推論機能 プライベートなコンテキストを必要としないシンプルなタスクリスト（詳細な調査、要約しながらの一連のWeb検索など）には適しています。多くのエンティティを調査したい場合、タスクリスト管理が比較的基本的なため、詳細な調査はうまく機能しません。スプレッドシートベースのAIツールは、タスク管理をスプレッドシートに効果的にオフロードするため、多くのエンティティの調査に適しています。プロンプト間で長いタスクリストを渡すことは機能しません。コーディングエージェントにおけるタスク管理は、単純な問題、単純なコード、またはゼロから始める場合に有効です。既存のプロジェクトがより複雑になると、信頼性は低下します。開発者は、コードの動作と構成（.mdファイル）を文書化することで信頼性を高め、エージェントがより多くの情報に基づいたタスクリストを作成できるようにします。複雑なコードにはより多くのドキュメントが必要になり、最終的にはそれらのドキュメントから関連するコンテキストのみを動的に取得する必要があります。多くの人々/企業は、プロジェクトに取り組むための正しい順序、アプローチ、ツールについて、文書化されていない強い意見を持っています。そのため、これを事前に、そして即座に文書化するためのより多くのアプローチが必要です。コーディングと Web ベースのリサーチ エージェントがうまく機能するもう 1 つの理由は、すべてが同じツール セットを使用するため、それらのツールの使い方を「学習」する必要がないことです (これについては次に詳しく説明します)。
タスク実行: タスクは通常、API 呼び出し (認証と API の使用方法の理解、および基礎となるデータ構造 (CRM やカスタム テーブル/列を持つ DB のように一意になる場合があります) が必要です)、LLM 推論 (例: 要約)、それらの組み合わせ、さらにはワークフロー エージェント* です。リサーチ エージェントは、実際にはループ内の Web 検索と要約にすぎません。コーディング エージェントは、コード ベースで CRUD を実行し、学習用 API の場合は Web 検索を実行します。認証と基本的な API アクセスは解決されているように見えますが (MCP はここに当てはまります)、ツール固有のコンテキスト (ユーザーに尋ねるだけでなく、最初の接続時に分析し、ツールの使用方法、データの構造、ツールを使用するシナリオ/プロジェクトを理解するために既存のデータを掘り下げる) についてもっと知りたいと思います。エラー/反省/フィードバックは、関連する場合にコンテキストとしてフィードバックされる体系的な学習に変換する必要があります。同じツールが組織間で異なる目的や方法で使用される可能性があるため、タスクを適切に実行するには、何らかの方法でこれをキャプチャ/文書化する必要があります。
コンテキスト: 会社の新入社員になったと想像してください。オンボーディング中に多くのことを学びます (オンボーディングが優れているほど、すぐに効果的になります)。その後、職場で学習します。これは、組織の経験からの学習 (「これが私たちのやり方です」) と自分の経験からの学習に分かれます。前者は大規模な組織でより一般的です。コンテキスト管理は似ています。メタ (ユーザー/会社)、プロジェクト/部門固有、タスク固有、ツール固有などのコンテキストのレイヤーがあります。シンプルなシステム プロンプトからハイブリッド RAG 戦略 (ベクトル、キーワード、グラフ) に進化しましたが、データ/コンテキストを持つことに加えて、いつどのようにコンテキストを取得するかについてのガイダンスが必要です。現在、初期バージョンが見られますが、改善の余地は大きくあります。これは単なる技術的な問題ではなく、ビジネス上の問題でもあります。基本的に、予想されるすべてのシナリオを網羅するオンボーディング ドキュメントを作成する必要があるためです。プロジェクトが複雑になるにつれて、無関係なコンテキストを最小限に抑えながら、関連する情報のみがプロンプトに含まれるようにコンテキストを適切に整理するには、より慎重な配慮が必要になります。
リフレクション：LLM/APIコストと観察をカバーするエージェント監視ツールはありますが、成功/失敗の割り当ては課題です。コーディングエージェントが他よりも優れている点の1つは、（コードのテストを通じて）失敗を決定論的に検知できる点です。他の多くのエージェントタスクでは、将来の出力を改善するために人間の入力を収集する適切な方法をまだ模索しているところです。私の知る限り、リフレクションは現在、人間参加型であり、フィードバックは主に人間の開発者にフィードバックされてエージェントを改善しています。しかし、リフレクションを自己改善に変える方法を見つけた時に、真の解決策が生まれます。つまり、エージェントはタスクリスト生成とタスク実行の失敗から洞察を得て、次回のパフォーマンス向上につなげるのです。基本的に、リフレクションは、適切な場合にのみプロンプトに取り込める、適切に整理されたコンテキストに変換する必要があります。これは、エージェントの微調整へと発展し、最終的にエージェント強化学習環境へと発展します。これはまだ初期段階のように感じられます。
* 先ほど、タスクをワークフロー エージェントに渡すことについて説明しましたが、これは、エージェントがツールとしてワークフロー エージェントを持たないことでメリットを得られる場合 (既知のタスク リストを毎回調べるのではなく)、またはシステムが複雑すぎて、特殊なコンテキストとツールを備えた特化したエージェントの方がパフォーマンスが向上する場合、意味を持ち始めます。または、他の人が構築したエージェントを活用している場合 (ここで目にし始めたパターンの 1 つは、エージェントのコラボレーションを容易にする自然言語 API エンドポイントです)。
今日のモデル品質に、無限のコンテンツウィンドウ（品質の低下なし）、無限のコンピューティング、無限のストレージ、ブラウザアクセス、支払い方法があれば、1回のLLMループで多くの処理を実行できる可能性があります。 上記の無意味な点 (無限なものは何もない) の要点は、エージェント オーケストレーションは主に、構造とコードを通じて LLM から作業をオフロードする方法を設計することによって制限を管理することであるということです。
実稼働中のエージェントにはさまざまな種類があります。内部ツール、さまざまなツールを組み合わせたスタンドアロン製品、コアツールの機能として組み込まれたものなどです。エージェントは汎用または特化型にすることができます。エージェント フローをトリガーするための最も一般的な UI インターフェイスは、チャット、音声、およびバックグラウンド エージェントのようです。
他に何が足りないでしょうか?