企业如何把现有系统 API 转成 MCP？

把现有系统 API 转成 MCP，第一步不是写代码，而是盘点企业已有能力。企业需要知道哪些系统有 API、哪些 API 可以读取数据、哪些 API 会修改业务状态、哪些 API 涉及敏感信息、哪些 API 只适合内部系统调用。这个过程决定了哪些能力适合开放给 Agent。

API 盘点还需要结合业务场景。不是所有 API 都应该变成工具。适合优先转换的是查询明确、权限边界清楚、操作风险可控、业务价值高的接口，例如订单查询、库存查询、审批状态查询、知识库检索、报表生成和工单创建。

API 文档不完整怎么办

很多企业系统没有完整 OpenAPI 或 Swagger 文档，这是常见情况。可以先从网关路由、接口调用日志、系统集成配置、数据库访问记录和业务流程文档中还原 API 目录。对高价值接口，再补齐请求参数、返回字段、错误码、权限要求和业务说明。

文档不完整时，不建议直接让 Agent 调用接口。应该先建立最小可用工具描述，限制参数范围，使用测试环境验证，再逐步扩大可用范围。对会写入数据或触发流程的接口，还需要人工确认、审批策略或灰度发布机制。

OpenAPI / Swagger 与工具描述

OpenAPI / Swagger 可以为 API 转 MCP 提供结构化基础。它描述路径、方法、参数、请求体、响应体和错误码。MCP 工具描述则需要在此基础上补充业务语义，让 Agent 知道这个工具适合解决什么问题、参数如何填写、返回结果如何解释。

例如一个库存查询 API 可能只描述 skuCode 和 warehouseId，但工具描述需要说明它用于查询指定仓库的可用库存，不应用于承诺交付日期，也不应返回未授权仓库数据。Schema 解决格式问题，业务描述解决语义问题。

鉴权、权限边界和风险控制

API 转 MCP 的核心难点是权限。Agent 调用工具时必须继承真实用户或应用身份，而不是使用一个全局超级密钥。企业需要根据部门、角色、系统、数据范围和操作类型设计权限边界，确保用户只能调用自己有权使用的工具。

风险控制包括参数校验、敏感字段过滤、写操作确认、频率限制、异常拦截和结果脱敏。对高风险工具，可以要求二次确认或只允许返回建议，不直接执行业务动作。这样既保留 Agent 自动化价值，也避免误操作和越权风险。

参数 Schema 和工具描述

参数 Schema 不只是技术字段定义，也是一种业务约束。每个参数应该说明类型、是否必填、允许范围、默认值、示例和业务含义。对枚举字段、日期范围、金额、组织范围、客户范围等敏感参数，要尽量通过受控选择而不是自由文本输入。

工具描述要告诉 Agent 这个工具适合做什么、不适合做什么，以及调用前需要满足什么条件。好的工具描述可以降低误调用概率，也能让审计人员在复盘时理解工具设计意图。

调用审计与实施步骤

调用审计需要记录用户、Agent、工具、API、参数、响应摘要、时间、结果状态和错误信息。审计不是为了事后追责才存在，它也帮助平台团队优化工具描述、发现异常调用、识别高成本链路和改进业务流程。

实施可以分为六步：盘点 API，选择低风险高价值场景，补齐 OpenAPI 或接口描述，设计 MCP 工具 Schema，配置权限和安全策略，接入审计与可观测，最后通过灰度方式交给业务团队使用。每一步都应保留回滚和人工验证机制。

AirBit 的 API 转 MCP 价值

AirBit 可以把 API Gateway、MCP Gateway、Enterprise Integration、AI Observability 和 Guardrails 组合起来，形成从 API 到 Agent 工具的治理链路。它帮助企业把存量 API、系统连接器和流程编排转成 AI 可调用能力，同时保留权限、审计和安全控制。

对企业来说，API 转 MCP 的目标不是展示技术概念，而是让 AI Agent 在真实业务中安全使用系统能力。AirBit 的定位是提供这层控制和连接能力，让企业不需要推翻 ERP、CRM、OA、MES、WMS 等既有系统，也能逐步实现业务能力 AI 化。