AIシステムを間違えています。 根本的に、構造的に、災害的に間違っている。 パターンは常に同じです. あるチームは大きな言語モデルの魔法を発見します. 彼らはそれをPythonスクリプトに巻き込んでいます. 彼らはデータベース、APIゲートウェイ、および顧客サポートログへのアクセスを与えます. 彼らは「100万トークン」が無限のストレージのように聞こえるので、文書の3ギガバイトをコンテキストウィンドウに捨てます。 それを「エージェント」と呼ぶ。 実際には、彼らは神のエージェントを構築しました。モノリス、万能で差別化されない論理のブロブは、CEO、 janitor、およびデータベース管理者であることを同時に試みます。 そして失敗する。 それは幻覚化します。それは混乱します。それはトークンの使用に富を費やします。遅延はユーザの経験が1999年に呼び出しの接続を待つように感じるまで増加します。それが壊れるとき(そして常に壊れるとき)エンジニアは、論理がコードに含まれていないため、それをデバッグすることはできません。 私はこれらのシステムを断ち切るために過去1年を費やしてきました 解決策はより良いプロンプトではありません より大きなモデルではありません 解決策はアーキテクチャです。 コードとベンチマークによる完全な技術分析 コードとベンチマークによる完全な技術分析 なぜ100万トークンを無限のRAMのように扱っているのか? AI開発における現在の正統性は、「コンテキストウィンドウ神話」によって誘惑される。 私たちは嘘を売られました。嘘は、あなたがモデルに十分な文脈を与えれば、それはすべての問題を解決することができますということです。 ベンダーは究極の機能として「無限の文脈」を押す。 128k. 1 百万. 2 百万トークン。 影響は誘惑的です。 アーキテクチャについて心配しないでください。 データコレクションについて心配しないでください。 すべてを投げ込むだけです。 モデルはそれを発見します。 これは、神エージェントのパラダイムの出現につながった。 この世界観において、「エージェント」は単一の存在であり、アプリケーションの全体的な状態を保有するものであり、ライブラリ内のあらゆるツールにアクセスできます。ユーザーが質問をするとき、神エージェントは質問を受け取り、その大規模な文脈(宇宙の歴史全体を含む)を調べ、その答えへの道を推論します。 それは進歩のようで、独特の、意識的なAIのサイエンスフィクションの夢のようだ。 しかし、生産においては、これは悪夢です。 私たちは、ジュニア・デベロッパーにコードベース全体、会社のハンドブック、法的アーカイブを記憶するように依頼し、30秒以内にCSSのバグを修正するように依頼しています。 彼らはバグを修正しません 彼らはパニック発作を起こします。 なぜ私のエージェントが「私は知らない」と言うのに50ドルかかるのか? 神エージェントアーキテクチャのブレークは、コードを生産に押す誰にでも見ることができます。 あなたがより多くの情報を提供するほど、モデルは重要なビットに注意を払うほどです。これは単なる感覚ではありません。それは建築上の欠点です。 研究は、モデルが長い文脈の中から情報を取り戻すために苦労していることを示しています。 編集を失敗することによって、我々は積極的にパフォーマンスを損なう。 我々は、無関係な文書の「騒音」がユーザーの特定の意図の「信号」を圧倒するシステムを作成します。 1. Context Pollution (The Needle in the Haystack) すべてのトークンはお金がかかります. すべてのトークンは処理するのに時間がかかります. 会話の毎回毎回50kのトークン文脈を再読する神のエージェントは、現金を燃やしています. それは計算的に無駄です. 私たちは、入力をフィルタリングするため「はい」または「ノー」と答えるスーパーコンピュータを実行しています。 2. Latency and Cost 神のエージェントが失敗したとき、なぜ失敗したのか?それはプロンプトだったのか? 検索ステップだったのか? ツールの出力だったのか? それともドキュメンタリーの405ページからの無関係なテキストによって単に分散させられたのか? 大規模なコンテキストウィンドウの変数スープに基づいて行動を変えるプロンプトを単位でテストすることはできません。 3. The Debugging Black Hole すべてにアクセスできる単一のエージェントはセキュリティの悪夢です。スムートインジェクションがうまくいけば、攻撃者は城を所有します。バルクヘッドは存在しません。アーキテクチャは確率モデルに最大限の信頼を頼っているため「ゼロ信頼」はありません。 4. The Governance Void ソリューションは単にマイクロサービス(再び)ですか? うん、そうだよ。 進む道は、 そして、The . Aggressive Context Curation Agentic Mesh 私たちは、標準化されたプロトコルを通じてコミュニケーションする小さな、専門化された、非常に制限されたエージェントのネットワークに置き換えなければなりません。 メッシュアーキテクチャでは、単一のエージェントがすべてを知らない。 ルーターエージェントは意図を分類する方法を知っています。 返品会社は返品ポリシーを知っています。 コーディングエージェントはPythonを知っています。 SQL エージェントは、データベースのスケジュールを知っています。 コンテキストウィンドウを共有しない メッセージを共有する これはモノリットからマイクロサービスへの移行です。複雑性を拡大する唯一の方法です。サポートエージェントが動作しているとき、データベースのスケジュールを知る必要はありません。Pythonのライブラリは必要ありません。その文脈は原始的です。 コード構造の違いを見ていきましょう。 『The Old Way: The God Prompt』 今日、ほとんどの人が書いていますが、これは混乱です。 # GOD AGENT - ANTI-PATTERN # We dump everything into one system prompt. system_prompt = """ You are an omniscient AI assistant for Acme Corp. You have access to: 1. The User Database (Schema: users, orders, items...) 2. The Codebase (Python, React, TypeScript...) 3. The Company Handbook (HR policies, returns, holidays...) 4. The Marketing Style Guide Instructions: - If the user asks about SQL, write a query. - If the user asks for a refund, check the handbook policy then query the DB. - If the user asks for code, write Python. Current Context: {entire_rag_retrieval_dump} {last_50_messages} """ # Result: The model gets confused. # It tries to apply HR policies to SQL queries. # It hallucinates tables that don't exist. Python The New Way: The Agentic Mesh(エージェント・メッシュ) ここで、我々は論理を分けます. Router は仕事をしません. It delegates. # MESH ARCHITECTURE - PATTERN # Step 1: The Router Agent # Its only job is to classify and route. It has NO domain knowledge. router_prompt = """ You are a routing system. Analyze the user input and route to the correct agent. Available Agents: 1. billing_agent (Refunds, invoices, payments) 2. tech_support_agent (Python, SQL, Bug fixes) 3. general_chat_agent (Casual conversation) Output JSON only: {"target_agent": "name", "reasoning": "string"} """ # Step 2: The Specialist Agent (Billing) # This agent loads ONLY when called. # It has zero knowledge of Python or SQL. billing_agent_prompt = """ You are a Billing Specialist. You handle refunds and invoices. Tools available: [stripe_api, invoice_db] Context: {user_transaction_history_only} {refund_policy_summary} """ Python 違いは?見るか? SQL シンタクスを幻覚化できないのは、SQL が何であるかを知らないからである. その宇宙は小さい. 小さな宇宙は幻覚に抵抗する。 billing_agent エージェントは hallucinating なしで実際に話す方法は? 私はビッグテクノロジーフレームワークに懐疑的でした. They usually add bloat. I like raw code. しかし、Google の Agent Development Kit (ADK) と Agent-to-Agent (A2A) プロトコルは異なります。 Googleは、エージェントが働くことを望むなら、チャットボットのようにではなく、ソフトウェアのようにお互いに話し合う必要があります。 A2Aプロトコル A2Aプロトコルは、エージェントが発見し、お互いに話し合うためのベンダー中立の標準です。これは「エージェントカード」を使用しています。これらは、エージェントが何ができるかを説明する標準化されたJSONメタデータファイルです。 こんな風に考えてください: { "agent_id": "billing_specialist_v1", "capabilities": ["process_refund", "check_invoice_status"], "input_schema": { "type": "object", "properties": { "transaction_id": {"type": "string"}, "user_intent": {"type": "string"} } }, "output_schema": { "type": "object", "properties": { "status": {"type": "string", "enum": ["success", "failed"]}, "refund_amount": {"type": "number"} } } } JSON ルーターエージェントが返金を処理する必要があるときは、API呼び出しを幻想化しようとしません。 A2Aを通じて手を振り、構造化されたパイロードを渡し、構造化された応答を待つ。 billing_specialist これは標準化であり、我々が構築することを可能にする。 異なるチームのエージェント、あるいは異なる企業のエージェントが協力することができます。 Agentic Mesh これは「孤立した島」の問題を解決します。現在、OpenAIエージェントはVertex AIエージェントと話すことができません。A2Aはプロトコルを共有しています。 これが実際に意味するもの メッシュアーキテクチャを採用すると、私たちがどのように構築するかすべてが変わります。 あなたは確率的な網のログを把握することはできません. 伝統的な観測性(ログ、メトリクス、トレース)は不十分です。 We need to see the なぜルーターは請求代理人に渡したのか?請求代理人は要求を拒否したのか? あなたがこれを持っていなければ、あなたはシステムを構築していない。 1. Observability is Mandatory Agentic Observability 理性チェーン God Agent モデルでは、セキュリティはバイナリ スイッチです. In a mesh, we can apply 請求エージェントは暗示的にルーターエージェントを信頼しません。 使用量を確認します。 ポリシーをチェックします。 爆発半径を制限します。 2. Zero Trust Security Zero Trust 独立した規律としての迅速なエンジニアリングは死んでいます。 The prompt is just a function configuration. The real work is in the routing logic, the schema definition, and the context curation strategy. 実際の仕事は、ルーティングの論理、スケジュールの定義、およびコンテキストの策定戦略にあります。 3. The End of "Prompt Engineering" System Engineering 私たちは無慈悲な編集者にならなければなりません。目標は文脈のウィンドウを埋めることではありません。目標はそれを空にすることです。私たちは圧縮する必要があります。私たちは概要する必要があります。私たちは次の直ちなステップに必要なものを正確に注入する必要があります。エージェントがSQLを書くように任務を負っている場合、それはスケジュールを必要とします。 会社のミッション宣言が必要です。 4. Aggressive Context Curation ノー (明らかに聞こえますが、コードベースの90%で無視されていることがわかります。 Read the complete technical breakdown → 完全な技術的な崩壊を読む → Read the complete technical breakdown → 完全な技術的な崩壊を読む → TL;DR FOR THE SCROLLERS God Agents は失敗します: コンテキスト ウィンドウを混乱させると、混乱、高コスト、およびデバッグが不可能になります。 懸念の分離:一つのことをうまく行う専門エージェント(請求、SQL、チャット)を構築します。 使用プロトコル: エージェントは通信する必要があります。
