可靠AI Agent的秘诀：API与MCP如何打通模型与业务系统

AI能解释Kubernetes的架构，能写出一封措辞得体的邮件，也能给出一个语气极其自信但完全错误的答案。但当你要求它查询一张真实的支持工单、找到公司的退款政策并起草回复时，光会说话就不够了。它需要接入你的业务系统——这正是API发挥作用的地方。而如今，另一个概念被反复提及：MCP。

很多人说MCP将取代API。这种说法恰恰忽略了最有意思的部分：真正的挑战不在于API或MCP谁替代谁，而在于我们如何将API应用连接到Agent可以使用的工具上。

问题本质：模型看不见你的业务

假设你正在构建一个客服助手。用户提出需求：找到Serra最新的支持工单，查看我们的退款政策，然后起草一份回复。

如果没有连接任何工具，模型手里没有这些记录。它可能会泛泛地解释如何处理这类请求，可能要求你手动粘贴信息，或者——如果你的应用设计不当——它可能直接编造一个答案。

知道退款政策通常长什么样，和读取你公司实际的政策文档，是完全不同的两件事。这就是AI Agent落地时最核心的鸿沟：模型的语言能力再强，也无法凭空获取私有业务数据。

因此，一个能真正干活的客服助手需要三样东西：访问工单的能力、访问政策文档的能力，以及准备回复的能力。

API：连接的基础层

API是这一切的起点。用最直白的话说，API就是应用程序之间约定好的通信接口——它定义了“你可以问我什么”以及“我会以什么格式回答你”。

在你的客服助手场景中，工单系统会提供一个API来查询特定用户的工单，知识库会提供一个API来检索政策文档，邮件或回复系统会提供一个API来创建草稿。模型本身并不直接调用这些API，而是你的应用程序负责处理认证、请求构造、错误处理和数据解析，然后把整理好的结果提供给模型。

这一层看似传统，但它是可靠性的根基。没有API，Agent就只是一个会聊天的空壳。

在Agent架构中，API通常不会由模型直接调用，而是由一层编排代码（Orchestration Layer）负责。这层代码承担了认证（如OAuth令牌管理）、请求构造（拼接参数与URL）、重试与限流、错误码映射、以及将API返回的原始JSON转换为模型易于理解的文本或结构化数据。这一层有时被称为“工具执行层”或“动作层”。将这部分逻辑与模型推理分离，是保证Agent可靠性的关键工程实践，因为模型本身不应持有密钥，也不应处理底层的网络异常。

MCP补上了什么

MCP（Model Context Protocol）引起广泛关注，是因为它试图标准化一件事：模型如何发现和调用外部工具。

传统做法下，每个应用都要自己定义工具描述、参数格式和调用约定，模型侧也需要针对性地适配。MCP的价值在于提供一个统一的协议层，让工具的定义、发现和调用有章可循。这样，模型不需要为每个API单独学习一套交互方式，工具提供方也不需要为每个模型单独适配。

但把MCP理解为“API的替代品”是误解。API负责的是系统间的数据交换和能力暴露，MCP负责的是让模型能够以标准化的方式理解和使用这些能力。两者是不同层次的东西，更像是互补而非替代。

MCP由Anthropic于2024年底开源提出，采用客户端-服务器架构：模型所在的应用充当MCP客户端，外部能力提供方实现MCP服务器。协议规定了三类核心原语——Tools（可被模型调用的函数）、Resources（可被读取的数据源）和Prompts（预设的提示模板），并通过JSON-RPC进行通信。这意味着一个已经实现MCP服务器的工单系统，理论上可以被任何支持MCP的模型或客户端直接使用，无需针对每个模型单独开发适配层。这与传统的函数调用（Function Calling）有区别：函数调用的格式由各家模型厂商各自定义，而MCP试图在协议层面统一这一层，让工具生态可以跨模型复用。

工具越多，Agent反而可能越差

一个反直觉但非常重要的结论：给Agent更多工具，有时会让它的表现更差。

原因在于，工具数量的增加会带来选择复杂度的上升。模型需要在更多选项中找到正确的工具，参数空间变大，歧义增多，调用错误的概率也随之上升。一个拥有五十个工具但缺乏清晰描述的Agent，往往不如一个只有五个精心定义工具的Agent可靠。

这也意味着，构建可靠Agent的关键不是堆砌能力，而是精心设计工具边界：每个工具职责清晰、参数明确、错误可预期。MCP提供了标准化的框架，但工具本身的设计质量仍然取决于开发者。

这一现象在业界被称为“工具过载”（Tool Overload），其背后的机制与模型的上下文窗口和注意力分配有关。当工具描述全部塞入系统提示时，每个工具的定义都会占用token，工具数量越多，单个工具描述能获得的“注意力”就越少。同时，语义相近的工具（如“查询工单”和“搜索工单”）容易让模型产生混淆，导致选择错误。实践中常见的缓解手段包括：按任务场景对工具分组、使用路由层先筛选相关工具再交给模型、以及为每个工具编写精确而简洁的描述。这些做法的共同目标都是缩小模型每次需要做出的选择空间。

可靠性的真正来源

回到最初的问题：AI Agent可靠运行的秘诀是什么？

答案不是更强的模型，也不是更多的工具。而是在模型和业务系统之间搭建一条清晰、可控、职责分明的通路——API提供访问能力，MCP提供标准化的调用方式，而你作为开发者，决定了这条通路上每一个环节的设计质量。

模型负责理解和生成语言，但它不应该负责猜测你的业务逻辑。把该由系统做的事交给系统，把该由模型做的事交给模型，这才是可靠Agent的基本前提。