<p>大多數旨在將大型語言模型與外部系統連接的操作基礎設施根本上是破碎的。這是一種結構性失敗，根源於歷史設計選擇，特別是依賴將機器通信協議（MCP）服務器視為簡單的 API 重複器。這種架構默認優先考慮實施團隊的便利性，而非 AI 代理的性能，現在表現為高昂的運營成本和企業內不可靠的 AI 結果。</p>
<p>Prefect 的首席執行官 Jeremiah Lowin 向行業領導者發表了一場尖鋭的干預性演講，指出現代 AI 代理與現有工具之間的普遍缺陷。他的中心論點很明確：當前一代 MCP 服務器——這一關鍵層次使代理能夠訪問外部能力——顯然效率低下，因為它優先考慮端點暴露而非代理的實用性。傳統方法是將代理生成器指向現有的 OpenAPI 規範，並宣稱工作完成，Lowin 認為這種做法是技術平庸的定義。</p>
<p>這些遺留規範是為使用 SDK 的人類開發者優化的，要求高水平的理解、複雜的序列和對模糊性的容忍。當一個 LLM 代理試圖消耗這個單一的規範時，它會立即被無關的信息淹沒，難以從為完全不同的消費者編寫的文檔中推斷意圖。Lowin 直言不諱地表示，太多的 MCP 服務器只是 “華麗的 REST 包裝器，重複那些為 SDK 而設計的 API，而非為代理設計。” 這種架構懶惰直接導致了 “困惑的 LLM、浪費的令牌和顯著差的性能。”</p>
<p>失敗並不是技術問題，而是產品設計問題。押注於 AI 運營化的創始人和風險投資家必須認識到，代理與能力層之間的接口是新的瓶頸。必要的範式轉變是將 MCP 服務器從簡單的管道視為專為 AI 消費者設計的策劃產品。Lowin 的團隊基於這一原則開發了 FastMCP 框架，強調在複雜性到達代理之前必須無情地管理它。</p>
<p>成功的秘訣在於無情的策劃。我們必須停止考慮端點，開始思考代理所需的產品結果。</p>
<p>該框架建立在代理原生產品設計的三個支柱上：發現、迭代和上下文。發現解決了代理快速理解哪些能力相關的迫切需求，而無需篩選噪音。這意味着呈現高度專業化的小表面區域，而不是整個企業 API 的全景。如果代理的任務僅限於獲取客户元數據，它應該只接觸到為該檢索所需的少數功能，而不是整個 CRM 系統的賬户管理和計費功能。</p>
<p>迭代承認代理交互很少是單次操作。服務器必須設計為促進細緻的多步驟對話，在交互生命週期中有效地保留狀態和記憶。這超越了簡單的請求 - 響應週期，朝着真正的對話實用層邁進。代理需要能夠請求澄清、在飛行中調整參數，並接收簡潔、結構化的反饋，以推動目標，而不是因模糊的錯誤代碼而重新啓動整個過程。</p>
<p>然而，上下文是最關鍵的支柱。Lowin 強調，成功的 AI 結果依賴於提供特定任務所需的最小、最有效的上下文。如果服務器暴露 50 個端點，而代理只需要與數據檢索相關的三個功能，結果的噪音會降低推理質量並增加計算成本。這種噪音迫使 LLM 花費寶貴的推理週期來解釋文檔，從而將能力轉移到解決實際業務問題上。Lowin 觀察到，“像任何產品一樣，優秀的 MCP 服務器是精心設計的結果，” 強調設計任務必須專注於消除模糊性並最大化 LLM 的信號與噪聲比。</p>
<p>對於企業採用者而言，這種低效直接轉化為經濟浪費。每一個浪費的令牌、每一個需要澄清的困惑代理，以及每一個需要複雜提示來導航文檔不佳的 API 的情況，都是邊際成本的累積，使大規模 AI 部署在經濟上變得不可行。當擴展到數千個代理每天執行數百萬個任務時，糟糕的上下文策劃的懲罰變得災難性。</p>
<p>根據 Lowin 的説法，解決方案是接受 FastMCP 的原則，創建優先考慮這三個支柱的代理原生產品。目標不僅是暴露能力，而是將上下文策劃成小而高效的表面區域，從而實現更好的 AI 結果。這要求工程師積極為 AI 消費者設計，理解 LLM 是效用的解釋者，而不是能夠推斷和糾正錯誤的人類開發者。干預是明確的：如果你只是將 MCP 生成器指向 OpenAPI 規範並宣稱完成，那麼最終的性能就是一種負擔。</p>

<p>連接大型語言模型（LLMs）與外部系統的操作基礎設施存在缺陷，導致高成本和糟糕的人工智能表現。Prefect 的首席執行官 Jeremiah Lowin 批評了當前機器通信協議（MCP）服務器的低效，認為它們優先考慮便利性而非代理的實用性。他提出了 FastMCP 框架，強調需要以代理為中心的產品設計，專注於發現、迭代和上下文。該方法旨在通過策劃相關能力、促進多步驟交互和提供有效的上下文，減少複雜性並提升人工智能的結果，最終解決人工智能部署中的經濟浪費問題</p>

<p>The majority of operational infrastructure designed to bridge Large Language Models with external systems is fundamentally broken. It is a structural failure rooted in historical design choices, specifically the reliance on treating Machine Communication Protocol (MCP) servers as mere API regurgitators. This architectural default, which prioritizes convenience for the implementation team over performance for the AI agent, is now manifesting as high operational costs and unreliable AI outcomes across the enterprise.</p>
<div class="lb-trans"><p>大多數旨在將大型語言模型與外部系統連接的操作基礎設施根本上是破碎的。這是一種結構性失敗，根源於歷史設計選擇，特別是依賴將機器通信協議（MCP）服務器視為簡單的 API 重複器。這種架構默認優先考慮實施團隊的便利性，而非 AI 代理的性能，現在表現為高昂的運營成本和企業內不可靠的 AI 結果。</p>
</div><p>Jeremiah Lowin, CEO of Prefect, delivered a sharp, interventionist presentation to industry leaders about the pervasive flaws in how modern AI agents interact with existing tooling. His central thesis was clear: the current generation of MCP servers—the critical layer facilitating agent access to external capabilities—is demonstrably inefficient because it prioritizes endpoint exposure over agent utility. The conventional approach involves pointing an agent generator at an existing OpenAPI specification and declaring the job complete, a practice Lowin asserted is the definition of technological mediocrity.</p>
<div class="lb-trans"><p>Prefect 的首席執行官 Jeremiah Lowin 向行業領導者發表了一場尖鋭的干預性演講，指出現代 AI 代理與現有工具之間的普遍缺陷。他的中心論點很明確：當前一代 MCP 服務器——這一關鍵層次使代理能夠訪問外部能力——顯然效率低下，因為它優先考慮端點暴露而非代理的實用性。傳統方法是將代理生成器指向現有的 OpenAPI 規範，並宣稱工作完成，Lowin 認為這種做法是技術平庸的定義。</p>
</div><p>These legacy specifications were optimized for human developers using SDKs, requiring high-level comprehension, complex sequencing, and tolerance for ambiguity. When an LLM agent attempts to consume this monolithic specification, it is instantly overwhelmed by irrelevant information, struggling to infer intent from documentation written for a completely different consumer. Lowin stated plainly that too many MCP servers are simply “glorified REST wrappers, regurgitating APIs that were designed for SDKs, not agents.” This architectural laziness leads directly to “confused LLMs, wasted tokens, and demonstrably poor performance.”</p>
<div class="lb-trans"><p>這些遺留規範是為使用 SDK 的人類開發者優化的，要求高水平的理解、複雜的序列和對模糊性的容忍。當一個 LLM 代理試圖消耗這個單一的規範時，它會立即被無關的信息淹沒，難以從為完全不同的消費者編寫的文檔中推斷意圖。Lowin 直言不諱地表示，太多的 MCP 服務器只是 “華麗的 REST 包裝器，重複那些為 SDK 而設計的 API，而非為代理設計。” 這種架構懶惰直接導致了 “困惑的 LLM、浪費的令牌和顯著差的性能。”</p>
</div><p>The failure is not one of technology, but one of product design. Founders and VCs betting on the operationalization of AI must recognize that the interface between the agent and the capability layer is the new bottleneck. The necessary paradigm shift is moving from viewing the MCP server as mere plumbing to treating it as a curated product designed specifically for the AI consumer. Lowin’s team developed the FastMCP framework based on this principle, emphasizing that complexity must be ruthlessly managed before it reaches the agent.</p>
<div class="lb-trans"><p>失敗並不是技術問題，而是產品設計問題。押注於 AI 運營化的創始人和風險投資家必須認識到，代理與能力層之間的接口是新的瓶頸。必要的範式轉變是將 MCP 服務器從簡單的管道視為專為 AI 消費者設計的策劃產品。Lowin 的團隊基於這一原則開發了 FastMCP 框架，強調在複雜性到達代理之前必須無情地管理它。</p>
</div><p>The secret to success lies in ruthless curation. We must stop thinking about endpoints and start thinking about the desired product outcome for the agent.</p>
<div class="lb-trans"><p>成功的秘訣在於無情的策劃。我們必須停止考慮端點，開始思考代理所需的產品結果。</p>
</div><p>This framework is built upon three pillars of agent-native product design: Discovery, Iteration, and Context. Discovery addresses the immediate need for an agent to quickly understand what capabilities are relevant without sifting through noise. This means presenting highly specialized, small surface areas rather than the entire corporate API landscape. If an agent’s task is limited to fetching customer metadata, it should only be exposed to the handful of functions necessary for that retrieval, not the entire CRM system’s account management and billing functions.</p>
<div class="lb-trans"><p>該框架建立在代理原生產品設計的三個支柱上：發現、迭代和上下文。發現解決了代理快速理解哪些能力相關的迫切需求，而無需篩選噪音。這意味着呈現高度專業化的小表面區域，而不是整個企業 API 的全景。如果代理的任務僅限於獲取客户元數據，它應該只接觸到為該檢索所需的少數功能，而不是整個 CRM 系統的賬户管理和計費功能。</p>
</div><p>Iteration acknowledges that agent interactions are rarely single-shot operations. The server must be designed to facilitate nuanced, multi-step dialogue, retaining state and memory efficiently across the interaction lifecycle. This moves beyond simple request-response cycles toward a true conversational utility layer. An agent needs to be able to ask for clarification, adjust parameters mid-flight, and receive concise, structured feedback that advances the goal, rather than restarting the entire process due to an ambiguous error code.</p>
<div class="lb-trans"><p>迭代承認代理交互很少是單次操作。服務器必須設計為促進細緻的多步驟對話，在交互生命週期中有效地保留狀態和記憶。這超越了簡單的請求 - 響應週期，朝着真正的對話實用層邁進。代理需要能夠請求澄清、在飛行中調整參數，並接收簡潔、結構化的反饋，以推動目標，而不是因模糊的錯誤代碼而重新啓動整個過程。</p>
</div><p>Context, however, is the most critical pillar. Lowin emphasized that successful AI outcomes hinge on providing the minimal, most effective context required for a specific task. If a server exposes 50 endpoints when the agent only needs three functions related to data retrieval, the resulting noise degrades reasoning quality and increases computational expense. This noise forces the LLM to spend valuable reasoning cycles simply interpreting the documentation, diverting capacity away from solving the actual business problem. Lowin observed that “Like any product, great MCP servers are the result of careful design,” stressing that the design mandate must be focused on eliminating ambiguity and maximizing signal-to-noise ratio for the LLM.</p>
<div class="lb-trans"><p>然而，上下文是最關鍵的支柱。Lowin 強調，成功的 AI 結果依賴於提供特定任務所需的最小、最有效的上下文。如果服務器暴露 50 個端點，而代理只需要與數據檢索相關的三個功能，結果的噪音會降低推理質量並增加計算成本。這種噪音迫使 LLM 花費寶貴的推理週期來解釋文檔，從而將能力轉移到解決實際業務問題上。Lowin 觀察到，“像任何產品一樣，優秀的 MCP 服務器是精心設計的結果，” 強調設計任務必須專注於消除模糊性並最大化 LLM 的信號與噪聲比。</p>
</div><p>For enterprise adopters, this inefficiency translates directly into economic waste. Every wasted token, every confused agent requiring clarification, and every complex prompt required to navigate a poorly documented API represents marginal cost accumulation that renders large-scale AI deployment economically untenable. When scaling to thousands of agents performing millions of tasks daily, the penalty for poor context curation becomes catastrophic.</p>
<div class="lb-trans"><p>對於企業採用者而言，這種低效直接轉化為經濟浪費。每一個浪費的令牌、每一個需要澄清的困惑代理，以及每一個需要複雜提示來導航文檔不佳的 API 的情況，都是邊際成本的累積，使大規模 AI 部署在經濟上變得不可行。當擴展到數千個代理每天執行數百萬個任務時，糟糕的上下文策劃的懲罰變得災難性。</p>
</div><p>The solution, according to Lowin, is to embrace the principles of FastMCP, creating agent-native products that prioritize the three pillars. The goal is not just to expose capabilities, but to curate context into small, highly effective surface areas that lead to better AI outcomes. This requires engineers to actively design for the AI consumer, understanding that the LLM is an interpreter of utility, not a human developer capable of inference and error correction. The intervention is clear: if you have simply pointed an MCP generator at an OpenAPI spec and called it a day, the resulting performance is a liability.</p>
<div class="lb-trans"><p>根據 Lowin 的説法，解決方案是接受 FastMCP 的原則，創建優先考慮這三個支柱的代理原生產品。目標不僅是暴露能力，而是將上下文策劃成小而高效的表面區域，從而實現更好的 AI 結果。這要求工程師積極為 AI 消費者設計，理解 LLM 是效用的解釋者，而不是能夠推斷和糾正錯誤的人類開發者。干預是明確的：如果你只是將 MCP 生成器指向 OpenAPI 規範並宣稱完成，那麼最終的性能就是一種負擔。</p>
</div>

The API Mismatch Killing Agent Performance

- 當前的機器通信協議（MCP）服務器設計存在結構性缺陷。  
- Jeremiah Lowin 指出，現代 AI 代理與工具的互動效率低下，導致高運行成本。  
- FastMCP 框架提出通過優化上下文提供，以提高 AI 成果的有效性。

API 的不匹配正在影響代理的性能表現