5層のHermes Agentアーキテクチャは、言語モデルを応答生成器から信頼できる演算子に変換します。
チャット応答から運用ループへの移行
エルメスエージェントのアーキテクチャを理解する最も簡単な方法は、応答の生成とタスクの実行を分離することです。
チャットボットは通常、単一の交換を中心に構築されます。ユーザーが質問し、モデルが答えると、インタラクションは終了します。たとえ答えが役に立ったとしても、モデルはユーザーの環境で実際に動作していません。データベースのチェック、ファイルのオープン、ライブ結果の比較、または出力が実際のタスクを解決したかどうかの検証は行っていません。
ヘルメス型エージェントは動作が異なります。ループ内で実行されます。目標を受け取り、次のステップについて検討し、ツールを呼び出し、結果を観察し、状態を更新して続行します。このループが、エージェントが通常の AI アシスタントとの違いを感じる主な理由です。それらは単に仕事を説明するだけではありません。彼らはその仕事に参加することができる。
ほとんどのビジネス ワークフローは 1 回限りのプロンプトではないため、この区別は重要です。コンテンツマーケターは「ブログの概要を書く」ことを単独で行う必要はありません。キーワードの調査、競合他社のレビュー、内部リンクのマッピング、アウトラインの生成、下書きの作成、フォーマット、品質チェックが必要です。サポートチームは「この顧客に答える」ことだけを必要とするわけではありません。チケットの分類、注文の検索、ポリシーの照合、払い戻し資格の確認、および機密性の高いケースの場合のエスカレーションが必要です。
Hermes Agent アーキテクチャは、人間の意図とソフトウェア実行中の中間層のために構築されています。
プロンプトよりもエージェントのアーキテクチャが重要である理由
多くのチームは迅速な改善から始めます。彼らは指示を書き直し、例を追加し、トーンを調整し、モデルを「よりスマート」にしようとします。それは役に立ちますが、ある程度までです。
通常、より深い問題はアーキテクチャに関するものです。エージェントは、どのようなツールが利用可能であるかを知らない場合があります。間違ったパラメータで正しいツールを呼び出す可能性があります。 3歩前に起こったことを忘れてしまうかもしれません。すでに十分な答えが得られた後もループし続ける場合があります。一部のアクションが承認を必要とする場合でも、すべてのタスクを同様に安全なものとして扱う可能性があります。
有用なエージェントには、賢いシステム プロンプト以上のものが必要です。それには境界、記憶、可観測性、ツール設計、フィードバック、評価が必要です。これらの要素がなければ、エージェントは予測不能になります。デモでは印象的に見えても、運用環境では信頼性に欠ける可能性があります。
これが、Hermes Agent が意思決定のためのシステムとして設計される必要がある理由です。モデルは推論エンジンですが、モデルが何を確認できるか、できるか、進捗をどのように記録するか、間違いにどのように対処するか、そしていつ人間が関与しなければならないか、周囲のシステムによって決定されます。
コアエルメエージェントループ
アーキテクチャの中心には、理解、計画、実行、観察、修正、完成というサイクルが繰り返されます。
エージェントはまずユーザーの目標を解釈します。弱いエージェントは、目標を直接の指示として扱い、急いで行動を開始します。より強力なエージェントは、必要な結果、利用可能なコンテキスト、不足している情報、およびタスクのリスク レベルを識別します。
それから計画を作成します。この計画は、長く目に見えるエッセイである必要はありません。実際、生産エージェントはコンパクトな計画から恩恵を受けることがよくあります。重要な点は、エージェントはどの一連のアクションが意味をなすかを判断する必要があるということです。
計画を立てた後、エージェントはツールを使用して行動します。ツールには、Web 検索、ファイル読み取り、コード実行、データベース レイヤー、ブラウザ自動化、CRM アクセス、スプレッドシート編集、電子メール指定、内部 API などが含まれる場合があります。ツール呼び出しは、エージェントが純粋な言語を離れて作業環境に触れる場所です。
観察ステップでは、多くの悪質なエージェントが破壊されます。ツールの結果は自動的には役に立ちません。エージェントはそれを検査し、タスクの状態が変更されたかどうかを判断し、次に何を行うかを選択する必要があります。検索結果が古い場合、エージェントは再度検索する必要があります。ファイルに予期されるフィールドが含まれていない場合は、ファイルを適応させる必要があります。 API がエラーを返した場合、成功を幻覚するのではなく、回復する必要があります。
ループは完了条件が満たされた場合にのみ終了します。その条件とは、最終的な回答、保存された下書き、完成したレポート、提出されたフォーム、または人間のレビュー担当者への引き継ぎなどです。
自己改善エージェントの 5 つのアーキテクチャ層
エルメス式自己改善エージェントは、インターフェース、推論、ツール、記憶、評価の 5 つの層で理解できます。
インターフェース層
インターフェース層はユーザーの意図を捉えます。これは、チャット ウィンドウ、デスクトップ アプリ、ブラウザ拡張機能、Slack ボット、Telegram ボット、内部ダッシュボード、またはワークフロー トリガーである可能性があります。このレイヤーは、単純に生のユーザー テキストをモデルに渡すべきではありません。タスクの種類を明確にし、利用可能なコンテキストを添付し、権限を特定し、出力形式を定義する必要があります。優れたインターフェイス層は、エージェントがコストのかかる複数ステップの作業を開始する前に曖昧さを軽減します。
推論層
推論層は次に何をするかを決定します。ここで、モデルは現在の状態を解釈し、アクションを選択します。推論は行動を導くのに十分な構造を持っている必要がありますが、脆くなるほど厳格であってはなりません。最適な推論層は、最も長いプロンプトではありません。最も明確な契約です。これはエージェントに、成功とはどのようなものか、何をしてはいけないのか、どの情報源が信頼できるのか、どのアクションに確認が必要なのか、証拠が弱い場合の対応方法をエージェントに伝えます。
ツールレイヤー
ツール層はエージェントが役立つ場所です。ツールは単なる技術的なアドオンではありません。これらはエージェントの言語の一部です。ツール名が曖昧であったり、パラメーターが紛らわしかったり、出力にノイズが多かったりすると、モデルは間違いを犯します。 get_data というツールは、search_customer_orders_by_email というツールよりもはるかに弱いです。優れたツール設計により、適切なアクションが明確になります。また、危険な行為も難しくなります。たとえば、電子メール ツールでは、「下書きの作成」と「電子メールの送信」を分離する必要があります。支払いツールは、払い戻しを行う前に明示的な承認を必要とする必要があります。生産現場では、多くの場合、モデルの選択と同じくらいツールの設計が重要になります。
記憶層
自己改善は記憶力に依存しますが、記憶力は誤解されることがよくあります。エージェントはすべてを記憶する必要はありません。実際、思い出しすぎると症状が悪化する可能性があります。メモリ層には、ユーザー設定、繰り返しのワークフロー、成功したツールのパターン、失敗した試行、承認ルール、プロジェクトのコンテキスト、再利用可能なスキルなど、将来の意思決定を改善する情報を保存する必要があります。通常、記憶にはいくつかの種類があります。短期記憶は現在のランニングを追跡します。長期記憶には、永続的な設定とワークフローの知識が保存されます。エピソード記憶は過去の試みと結果を記録します。スキルの記憶により、繰り返される手順が再利用可能なプレイブックに変わります。危険なのは古い記憶です。強力なアーキテクチャには、メモリのレビュー、有効期限、ユーザーの修正、ソースのタグ付けが含まれます。
評価層
評価レイヤーは、「実行」するエージェントと改善するエージェントの違いです。自己改善する AI エージェントにはフィードバック信号が必要です。一部のフィードバックは自動的に行われます: コードはテストに合格しましたか? API 呼び出しは成功しましたか? 生成された JSON はスキーマと一致しましたか? その他のフィードバックは人間的なものです。 カスタマー サポートの意見は共感的に聞こえましたか? 研究概要には正しい情報ソースが含まれていましたか?こうして改善が体系化されるのです。スキーマ、脆弱な取得、安全でないメモリ、一連の停止ロジックなど、障害ポイントを特定できます。
自己改善が実際にどのように機能するか
自己改善とは、タスクのたびにエージェントが魔法のように自身のニューラル ウェイトを書き換えることを意味するものではありません。ほとんどの実際的なシステムでは、自己改善は、より良いコンテキスト、より良いメモリ、より良いツール、より良い評価ループを通じて行われます。
SEOコンテンツ制作にエージェントを利用するとします。
自己改善型のアーキテクチャは、これらの修正を取り込みます。スタイル メモリを更新したり、コンテンツ チェックリストを改良したり、評価ルーブリックを変更したり、再利用可能な「エディター パス」スキルを作成したりすることができます。モデル自体は同じかもしれませんが、その周りのシステムはチームの基準により沿ったものになります。
これが自己改善型 AI エージェントの実質的な意味です。環境が教えてくれるので上達します。フィードバックは指示になります。繰り返しの行動がスキルになります。間違いはテストケースになります。人間のレビューはチャット履歴に消えるのではなく、構造化された記憶になります。
具体的なワークフロー: リサーチリクエストからブリーフ完成まで
プロダクト マネージャーがエージェントに、新しい生産性向上アプリに関する競合調査の概要を作成するよう依頼する場合を考えてみましょう。
弱いアシスタントは、記憶から一般的な市場概要を生成する可能性があります。エルメス スタイルのエージェントは、タスクに対して異なるアプローチをとります。まず、競合他社、ポジショニング、価格設定、機能のギャップ、ユーザーの不満などの目標を明確にします。次に、現在の公開ソースを検索し、関連するページを開いてデータを抽出し、引用を記録します。結果に一貫性がない場合は、追加のチェックが実行されます。比較表を作成し、レビューのパターンを特定し、検証された事実を解釈から分離することができます。
次に、エージェントは準備書面の草案を作成します。評価ステップでは、概要が元の質問に答えているかどうか、主張がサポートされているかどうか、推奨事項が実行可能かどうかをチェックします。概要が広すぎる場合、エージェントはそれを修正します。重要な競合他社が見つからない場合は、再度検索します。出力が幹部向けの場合は、結論が短くなり、戦術の詳細が付録に移動されます。
最終的な成果物は単なるテキストではありません。それは、研究、検証、総合、批評、改訂という制御されたループの結果です。
このタイプのワークフローは、エージェント アーキテクチャが重要である理由を示しています。この値は、1 つの印象的なモデル応答からではなく、システム全体から得られます。