反对「直接把内部 API 暴露成 MCP」的天真做法

Brief

许多组织都希望让 AI 代理能够与现有系统交互，常见做法是尝试将内部 API「无缝、直接」转换为 Model Context Protocol (MCP)。市面上也出现了越来越多支持这种转换的工具，例如 MCP link 和 FastAPI-MCP。

我们不建议采用这种天真的 API→MCP 转换方式。绝大多数 API 是为人类开发者设计的，通常由粒度很细的原子操作构成。如果让 AI 通过 MCP 直接调用这些接口并串联使用，往往会导致 Token 过度消耗、上下文被严重污染，以及整体代理性能不佳。

此外，这类 API——尤其是内部 API——经常会暴露敏感数据，或具备破坏性操作能力。对于人类开发者，这些风险通常通过架构模式和代码评审来缓解；但一旦通过 MCP 将这些接口原样暴露给 AI 代理，就没有可靠且确定性的方式来防止自主代理误用这些端点。

因此，我们建议：在现有 API 之上，专门面向代理工作流构建一个安全的、面向场景设计的 MCP 服务器，而不是做简单的 API 到 MCP 的一一映射。

来源：技术雷达

Details

一、背景与现状：为什么大家想「一键 API→MCP」

1. 组织的直觉诉求

• 业务侧目标：让 AI 代理能「真正干活」，不仅仅是问答，而是能下单、改配置、拉报表、触发自动化流程。
• 技术侧现状：已有大量内部 REST / gRPC / GraphQL API，已经承载了各类业务操作。
• 自然的想法：既然已有 API，就「顺手」通过 MCP 暴露出去，让代理像人类开发者一样调用即可。

这种思路催生出：

• 通用「API to MCP」适配器（如 MCP link、FastAPI-MCP 等），主打「低改造成本、快速暴露能力」；
• 理想状态：几乎不改业务，只加一层转换，代理就能访问所有能力。

2. MCP 的预期角色

在多数架构设想中，MCP 被视为：

• 「代理世界」和「企业系统世界」之间的接口协议；
• 把工具/服务抽象成统一的「能力」，供 LLM Agent 调度；
• 支撑多 Agent / 多工具协作，而不是一个简单的 HTTP 包装层。

直接把内部 API 映射为 MCP，看起来是加速路径，实际却埋下系统性风险。

二、问题与风险：为什么「原样暴露 API」是不负责任的设计

1. 粒度问题：为人类设计的 API，不适合直接给代理用

内部 API 的典型特征：

• 颗粒度细：大量「查一条记录」「更新一个字段」「写一条日志」这类原子操作；
• 接口组合逻辑：真正的业务价值由上层服务/应用通过多次调用组合出来；
• 默认前提：调用者是有上下文、懂业务语义的人类开发者。

对代理而言，这会带来几个问题：

• 需要大量调用链组合才能完成一个业务任务：
  • 例如：先查用户信息 → 再查订单 → 再更新状态 → 再写审计日志 → 再发通知；
• 每次调用都要在 Prompt/工具调用规范里编码参数和上下文，导致：
  • Token 消耗迅速放大；
  • 上下文里充斥大量低层细节（context pollution），挤压对任务本身的建模空间；
• 代理在链式调用中容易迷失：
  • 难以维护一个稳定的一致状态模型；
  • 微小的解析、规划错误就可能放大成错误序列。

总结：为人类设计的「细颗粒度 API」，直接暴露给代理，结构上就不匹配其规划和推理方式。

2. 安全与破坏性操作：人类有「守门人」，代理没有

内部 API 通常包含：

• 读取敏感数据的能力：
  • 用户隐私、业务机密、运营指标等；
• 具备破坏性的写操作：
  • 删除、批量更新、触发外部系统执行等。

在人类开发流程里，这些风险被缓冲在：

• 架构分层与访问控制：只有特定服务 / 角色才能调用；
• 代码评审与上线流程：危险调用往往需要多人评审、灰度、回滚预案；
• 运行时观测与告警：异常模式会被运维体系发现。

一旦通过 MCP 直接暴露给自主代理：

• 代理可能在看似合理的任务规划中误用这些能力：
  • 比如「清理无效账号」被误解为「批量删除活跃用户」；
• 我们很难用传统 ACL/鉴权表达「在这个对话/任务上下文下，哪些具体调用是可接受的」；
• 缺少确定性的防线：
  • 即使加了一些 Rule/Guardrail，也很难穷举所有危险组合，特别是在多步规划场景下。

原文的关键判断是：没有可靠、确定性的方式保证代理不会误用这些端点，安全基线无法接受。

3. 代理性能与工程可维护性

把低层 API 直接暴露为 MCP 工具，还会带来工程性问题：

• 工具爆炸：
  • MCP 层可能出现几十、上百个工具，增加代理工具选择复杂度；
• 规划困难：
  • LLM 很难从一堆「原子接口」中推导出稳健的业务流程；
• 调试困难：
  • 排查「为什么代理做了这串调用」成本极高；
  • 很难做到稳定的回归和演进。

结果是：看似「很能干」的代理，实际在关键场景下非常不稳定且难以调优。

三、建议的模式：在现有 API 之上设计「面向代理的 MCP 服务器」

1. 核心思路：在 API 与 Agent 之间，再加一层「Agent-Oriented Service」

原文的推荐是：

基于现有 API，架构一个专门为代理工作流设计的、安全的 MCP 服务器。

其内涵包括：

• MCP 工具不是「一一映射 API」，而是抽象为业务级能力：
  • 例如「生成用户月度账单摘要」「创建工单并记录审计 Trail」；
• 内部通过组合/编排调用多个原子 API：
  • API 仍然被人类开发者掌控在内部服务中；
  • MCP 只暴露经过设计与审查的「高层动作」。

2. 设计要点：为 Agent 定制的接口形态

为代理设计的 MCP 工具/服务，通常应具备几个特征：

• 高层任务语义：
  • 输入/输出以业务对象为中心，而不是单表字段；
  • 避免让代理自己去拼细粒度步骤。
• 内嵌安全与约束：
  • 在 MCP 服务器内部实现必要的校验、限流、审计；
  • 对敏感操作引入显式的参数和约束，而不是「任意执行」。
• 为可观测性设计：
  • 每个 MCP 工具调用天然带有审计信息；
  • 便于在事后还原代理行为和排查问题。

相当于：为代理提供的是「受限的、可观测的业务能力接口」，而非整个内部系统的裸露 API 面。

四、旧做法 vs 新模式：如何理解这次转向

1. Naive 模式：API as MCP

• 目标：0 成本接入，让代理立刻可用所有内部 API；
• 假设：代理是「廉价的高级开发者」，可以理解并正确使用这些接口；
• 现实：
  • 高调用成本（Token + 调用次数）；
  • 安全与灾难风险失控；
  • 调试和治理难度远高于预期。

2. 推荐模式：Agent-Oriented MCP Layer

• 目标：构建一层专门面向代理的「业务能力层」，管控代理能做什么；
• 特点：
  • 从原子 API 抽象到业务场景工具；
  • 在 MCP 层实现明确的安全与审计边界；
  • 把「可用性」和「可控性」放在同一设计空间内考虑。

从演进路径看，这是从「接口暴露思维」转向「能力包装与编排思维」。

五、系统性影响：对架构与工程实践的要求

1. 对整体架构的影响

• 需要在系统图中显式加入「MCP 服务器 / Agent 服务层」：
  • 它作为独立组件，介于 LLM Agent 与内部系统之间；
• 引导团队围绕「面向代理的领域服务」重新梳理：
  • 哪些是可对话式触发的业务能力；
  • 哪些仍应限制在传统服务/后台任务里。

2. 对安全治理的影响

• 安全边界重构：
  • 不再是「所有有 Token 的客户端都能调 API」；
  • 而是「代理只能通过经过审计的 MCP 工具访问特定能力」；
• 新的风险管理方式：
  • 重点从「单个请求的权限校验」转为「整条代理行为链的审计和约束」。

3. 对工程效率和协作的影响

• 短期：
  • 放弃「直接暴露 API」会增加前期设计和实现成本；
• 中长期：
  • MCP 工具变成团队内部的「能力目录」：
    • 产品、架构、平台可以围绕这些能力讨论代理能做什么；
  • 便于分层演进：
    • 内部 API 可以演化，而 MCP 能力接口保持相对稳定。

六、落地建议：如何在团队里实践「非天真」的 MCP 设计

1. 适用场景与前提

更适合尝试专门 MCP 服务器的典型场景：

• 计划在关键业务流程引入自主或半自主代理；
• 内部 API 规模大、敏感操作多，安全与审计要求高；
• 有意将「AI 能力」沉淀为长期的架构组成部分，而非临时试验。

前提条件通常包括：

• 有一定的 API 治理和文档基础；
• 有能力抽象出跨系统的业务能力，而不仅是表层 CRUD。

2. 初始路径：从「场景」而不是「API 列表」出发

推荐的推进方式：

1. 选一个小而有价值的闭环场景：
   • 比如：生成运营日报并落库、创建/更新工单并记录完整审计；
2. 自顶向下设计 MCP 工具：
   • 抽象 2～5 个高层任务能力，而不是 20 个底层接口；
3. 在 MCP 服务器内部编排现有 API：
   • 保留所有安全校验、幂等、防错逻辑；
   • 明确什么情况要失败、什么情况要人工介入。

在这个过程中，可以逐步积累：工具命名规范、输入输出约定、审计字段标准等。

3. 防范典型风险的工程手段

在不改变原文立场的前提下，常见可行的缓解思路包括：

• 严格限制 MCP 工具集合：
  • 初期只开放只读或低风险能力；
  • 高风险操作必须具备明确的「安全护栏」和回滚机制。
• 增强观测与审计：
  • 对每次 MCP 调用记录任务上下文、调用参数和结果摘要；
  • 增加面向「代理行为」的监控视图。
• 控制自治度：
  • 在高风险场景中，更偏向「人机协同」，例如： - 代理生成操作计划和命令草案； - 人类确认后才执行对应 MCP 工具调用。

整体而言，原文的姿态是「强烈不建议天真地把现有 API 原样暴露为 MCP」。如果要让代理真正、安全地接入企业系统，应当投入工程资源，围绕具体业务场景设计一层专门的、安全的 MCP 服务，而不是依赖自动适配工具做简单转换。