<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 的不匹配正在影响代理的性能表现