企业 MCP Gateway 3.0：把 CRM、ERP、数据库与内部 API 统一开放给 AI Agent

统一连接 CRM、ERP、数据库和内部 API，为企业 AI Agent 提供安全、可审批、可审计的 MCP 能力网关。

摘要： 本文设计一套“企业 MCP Gateway 3.0”完整参考项目，把 CRM、ERP、数据库和内部 API 转换成可治理的 MCP Tools、Resources 与 Workflows，统一开放给 ChatGPT、Codex、企业助手和自研 AI Agent。核心结论是：MCP 解决工具发现与调用协议，但不会自动解决企业身份、业务授权、数据分级、审批、限流、幂等和审计；生产 Gateway 必须采用零信任逐请求决策，把“用户是谁、Agent 代表谁、能访问哪条记录、能执行什么动作”落实到每一次调用。本文提供分层架构、工具命名规范、OAuth 2.1、策略模型、数据库代理、API 适配、人工审批、FastAPI/Python、YAML、Rego、SQL 与 Docker 部署方案。

核心结论

企业 MCP Gateway 3.0 不是把所有内部接口简单包装成一个 MCP Server，而是建立“统一接入、统一工具目录、统一身份、统一授权、统一数据治理、统一审批与统一审计”的 Agent 能力控制面。CRM、ERP、数据库和内部 API 仍由原系统负责业务真相；Gateway 只向 Agent 暴露经过筛选、参数收敛、权限绑定和风险分级的能力。

值得建设： 当多个 Agent、模型或客户端需要重复接入同一批企业系统时，Gateway 能减少重复连接器和分散凭据。
关键变化： 从“每个 Agent 保存一套 API Key”升级为企业身份、短期 Token、每次调用授权和服务端凭据代理。
开放原则： 优先开放窄而清晰的业务动作，例如 crm.get_customer_summary，不要直接开放任意 SQL 或通用 HTTP 请求。
高风险边界： 写入 ERP、修改客户、批量导出、删除数据、付款与权限变更必须审批或禁止。
实施建议： 先从只读工具和一个业务域试点，以影子审计验证权限，再逐步开放可逆写入和审批型动作。

MCP Gateway 3.0 是什么

结论先说：本文中的“3.0”是面向企业落地的架构代际命名，不是 MCP 官方协议版本。第一代可理解为单个 Agent 直连单个 MCP Server；第二代增加多个 Server 的集中路由与工具白名单；第三代则把身份、工具注册、策略决策、数据控制、审批和审计放到统一控制平面，同时保留各业务系统的独立边界。

MCP 官方把协议描述为连接 AI 应用与外部系统的开放标准，可连接数据源、工具和工作流。工具由名称、描述和输入 Schema 定义，客户端可以发现并调用。但协议级“能发出一个工具请求”不代表业务级“有权读取某客户或修改某采购单”。企业仍需把组织、岗位、租户、资源归属、数据级别、动作风险和审批状态放进授权决策。

企业 Gateway 的目标不是建立一个拥有超级管理员权限的万能代理，而是把原有 CRM、ERP、数据库与 API 的权限边界翻译成 Agent 可用的最小能力。NIST 零信任架构强调以用户、资产和资源为中心，对每次访问做最小权限判断；这比按内网 IP 默认信任更适合 Agent 场景。

相关内容可继续查看 AI Stack Nav 的MCP Gateway 教程和Agent Identity 与企业授权专题。

企业需求与主要痛点

没有 Gateway 时，常见做法是让每个 Agent 团队自行开发 CRM、ERP 和数据库插件。这会产生四类问题：凭据散落在提示词、环境变量或个人电脑；同一业务动作出现多个不一致版本；权限只控制到 API，而不能控制到客户、部门和字段；发生错误后无法知道哪个用户、哪个 Agent、基于什么理由调用了什么工具。

痛点	直接连接方式	Gateway 3.0 方式	价值
工具重复建设	每个 Agent 自写连接器	统一 Adapter 与 Tool Catalog	降低维护和版本分裂
凭据管理	长期 API Key 分散	Gateway 代理短期凭据或服务身份	缩小泄露面
权限模型	只看是否能调用 API	用户＋Agent＋资源＋动作逐请求授权	支持行列级和业务级控制
风险动作	模型直接写入	策略分级、参数冻结、人工审批	避免不可逆副作用
审计	各系统日志格式不同	统一 Decision ID 与调用链	可调查、可回放、可合规

Gateway 还解决工具目录膨胀问题。一个企业可能有数千个 API，不应全部进入模型上下文。系统应按部门、任务和权限动态筛选工具，只向当前 Agent 暴露最相关的一小组，并对工具描述做版本化和安全审核。

总体技术架构

核心结论是：Gateway 应分为数据平面和控制平面。数据平面处理实时 MCP 请求、鉴权、路由、适配、审批和结果过滤；控制平面管理 Server Registry、Tool Catalog、连接器、策略、密钥、版本、评测和审计查询。

控制面统一管理身份、工具、策略和审计，数据面负责实时鉴权、路由和结果过滤。

推荐组件如下：

MCP Edge： 支持 Streamable HTTP 等企业部署需要的传输，处理协议版本、能力协商、请求 ID 与流式响应。
Identity Broker： 对接企业 IdP，验证用户 Token、工作负载身份、设备与会话上下文。
Agent Identity： 标记调用来自哪个 Agent、版本、所有者和部署环境，并限制子 Agent 的委托权限。
Tool Catalog： 保存工具名称、Schema、所属系统、风险、数据分类、版本、审批策略和负责人。
Policy Decision Point： 根据主体、Agent、动作、资源、环境和风险做 allow/deny/approval 决策。
Approval Service： 冻结调用参数，等待业务负责人批准；过期或参数变化后重新审批。
Connector Runtime： 分别适配 CRM、ERP、数据库、REST/GraphQL/SOAP 和消息系统。
Secret Broker： 保存后端凭据并换取短期 Token，不把 CRM 或 ERP 密钥返回给 Agent。
Data Guard： 执行字段脱敏、行级过滤、结果大小限制、DLP 和 Prompt Injection 扫描。
Audit / Observability： 关联用户、Agent、策略、工具、后端调用、审批和结果摘要。

多区域部署时，控制面可集中，数据面按区域部署，敏感业务数据不离开指定地域。工具目录元数据可以复制，但 Token、请求内容和工具结果必须符合数据驻留与保留要求。

工具目录与领域建模

最重要的建模原则是“业务能力优先，通用接口最小化”。模型更容易正确使用 erp.create_purchase_requisition，而不是 http.request；安全团队也更容易为前者定义金额、供应商和审批策略。

推荐命名格式：

<domain>.<resource>.<action>
crm.customer.search
crm.customer.get_summary
crm.opportunity.create_note
erp.purchase_requisition.create
erp.purchase_order.approve
data.sales.query_aggregate
internal.ticket.create

工具注册元数据示例：

tool:
  name: crm.customer.get_summary
  version: 1.3.0
  owner: sales-platform
  backend: salesforce-prod
  effect: read
  data_classification: confidential
  input_schema:
    type: object
    additionalProperties: false
    required: [customer_id]
    properties:
      customer_id:
        type: string
        pattern: "^CUS-[0-9]{8}$"
  output_policy:
    allowed_fields: [customer_id, name, segment, owner, last_contact_at]
    redact_fields: [phone, personal_email]
    max_records: 1
  authorization:
    resource_relation: account_team_member
  approval: never

工具描述不得包含密钥、内部网络拓扑或可被外部内容修改的授权规则。Schema 必须禁止未声明字段，避免模型向后端偷偷附加 include_sensitive=true。每个版本都要有兼容策略；破坏性变更发布新主版本，并让旧 Agent 有明确迁移期。

统一身份与 OAuth 2.1 授权

结论是：Gateway 必须同时知道最终用户身份、Agent 身份和后端服务身份，但不能把它们混为一个 Token。MCP 官方授权文档以 OAuth 2.1 保护 HTTP MCP Server，并要求 Token 针对目标资源签发；安全最佳实践明确禁止 Token Passthrough。

典型身份链为：员工在企业 IdP 登录；MCP Client 获得发给 Gateway 的访问 Token；Gateway 验证签名、发行者、受众、期限与 Scope；策略引擎判断用户和 Agent 是否可调用工具；Connector 再用 Gateway 自己的服务身份或代表用户换取的短期后端 Token 访问 CRM/ERP。发给 Gateway 的 Token 不能直接转给后端。

{
  "sub": "user:12345",
  "aud": "https://mcp-gateway.example.com",
  "scope": "mcp:tools:invoke",
  "tenant": "enterprise-a",
  "roles": ["sales_rep"],
  "agent_id": "sales-copilot",
  "agent_version": "2.4.1",
  "delegation_depth": 0,
  "exp": 1788268800
}

以上只是说明性 Claim，不代表 MCP 规范强制这些字段。企业应使用 IdP 支持的标准 Claim 或受控扩展，并防止客户端自行伪造 agent_id。Agent 身份标准仍在 MCP 路线图中演进，因此生产方案应把 Agent 注册与证明封装在 Gateway 内部，避免绑定未定稿扩展。

MCP Enterprise-Managed Authorization 提出由企业 IdP 维护获批 Server 与访问策略，实现集中策略和单点登录。这适合 Gateway 控制面，但业务数据授权仍需由 Gateway 和源系统共同执行。

CRM、ERP、数据库与内部 API 适配

CRM 适配

CRM 工具应围绕客户、联系人、机会、活动与工单设计。读取客户摘要时先验证销售人员是否属于客户团队；创建跟进记录可允许自动执行；修改客户负责人、批量导出联系方式或发送营销邮件必须审批。

ERP 适配

ERP 更强调事务、金额、组织和职责分离。查询库存与订单可只读开放；创建采购申请可在金额阈值内进入草稿；审批采购单、修改供应商银行账户、付款和结账不应交给通用 Agent 自动执行。

数据库适配

不要默认提供任意 SQL 工具。优先使用参数化查询模板、只读副本、数据库视图和存储过程：

tool:
  name: data.sales.query_aggregate
  effect: read
  query_template: sales_by_region_v2
  database_role: agent_analytics_ro
  parameters:
    start_date: {type: string, format: date}
    end_date: {type: string, format: date}
    region: {type: string, enum: [north, south, east, west]}
  limits:
    timeout_seconds: 10
    max_rows: 100
    max_bytes: 1048576

数据库自身仍要启用只读账户、Row-Level Security、Statement Timeout、查询预算和审计。Gateway 过滤不能替代数据库权限。

内部 API 适配

内部 API 可能是 REST、GraphQL、SOAP 或消息队列。Adapter 应处理协议转换、错误标准化、超时、重试和幂等，但不能向模型暴露任意 URL。每个工具绑定固定的后端服务、路径模板和允许方法。

async def invoke_internal_tool(tool, args, ctx):
    spec = catalog.get(tool)
    validate_json_schema(args, spec.input_schema)
    decision = await policy.authorize(ctx, spec, args)
    if decision.effect == "deny":
        raise PermissionError(decision.reason)
    if decision.effect == "approval":
        return await approvals.pause_and_freeze(ctx, spec, args, decision)

    credential = await secret_broker.issue_backend_token(
        audience=spec.backend_audience,
        subject=ctx.user_id,
        ttl_seconds=120,
    )
    result = await connectors[spec.backend].call(
        operation=spec.operation,
        arguments=args,
        credential=credential,
        idempotency_key=ctx.idempotency_key,
    )
    return data_guard.filter(result, spec.output_policy, ctx)

逐请求授权与策略引擎

零信任意味着每次工具调用都重新评估，不能因为 Agent 已连接 Gateway 就默认可信。决策输入至少包含用户、Agent、设备或工作负载、租户、工具、资源、参数、数据分类、环境、时间、风险和审批状态。

package mcp.tools

default decision := {"effect": "deny", "reason": "no_matching_policy"}

decision := {"effect": "allow"} if {
  input.tool == "crm.customer.get_summary"
  input.user.role == "sales_rep"
  input.resource.owner_team == input.user.team
  input.agent.id in data.approved_agents.sales
  input.environment == "production"
}

decision := {"effect": "approval", "approver_role": "procurement_manager"} if {
  input.tool == "erp.purchase_requisition.create"
  input.args.amount > 10000
  input.user.department == "procurement"
}

示例金额是演示值，不代表通用企业标准。真实阈值应来自财务制度并使用币种、组织、累计额度和供应商风险等条件。审批结果必须冻结参数哈希；金额、收款方、客户或后端环境改变后原批准失效。

工具发现、路由与上下文控制

工具目录很大时，不应把全部 Schema 注入模型。Gateway 可先根据身份、Agent 类型和任务进行确定性过滤，再用工具搜索加载少量相关工具。最终可见工具集合必须是权限过滤后的子集，不能先让模型看到禁止工具再要求它“不调用”。

推荐路由过程：

Client 建立 MCP 连接并提交企业身份。
Gateway 读取 Agent 注册信息与允许业务域。
Policy Engine 计算可见 Server、Resources 与 Tools。
Tool Search 仅在允许集合中按任务相关性检索。
返回经过命名冲突检查和版本固定的工具 Schema。
模型产生调用后，再执行一次参数级授权。

工具缓存需要绑定 tenant + user + agent + policy_version + catalog_version。权限或工具版本变化时立即失效，避免用户离职后仍看到旧工具。

人工审批、执行与审计闭环

关键原则是：审批必须发生在后端调用之前，并且审批人看到的是冻结后的真实参数。OpenAI Agents SDK 官方支持为本地和 Hosted MCP 工具配置 require_approval，暂停后可批准或拒绝，再恢复运行；这能作为客户端侧体验，但企业 Gateway 仍应在服务端强制审批，防止其他客户端绕过。

从工具发现到后端执行，每一步都绑定用户、Agent、策略版本和审计证据。

统一审计事件建议包含：

{
  "decision_id": "dec_01J...",
  "trace_id": "tr_01J...",
  "tenant_id": "enterprise-a",
  "user_id": "user:12345",
  "agent_id": "sales-copilot",
  "tool": "crm.customer.get_summary",
  "tool_version": "1.3.0",
  "resource_hash": "sha256:...",
  "policy_version": "2026-09-01.1",
  "decision": "allow",
  "backend_status": "success",
  "latency_ms": 184,
  "result_classification": "confidential"
}

日志不要保存访问 Token、密码、完整客户资料或未脱敏工具结果。需要调查的原始证据可加密保存到受限存储，并使用单独的访问审计。

完整项目目录与 Docker 部署

enterprise-mcp-gateway/
├── edge/                 # MCP传输与协议处理
├── identity/             # IdP、Token验证与Agent注册
├── catalog/              # Server与Tool目录
├── policy/               # OPA/Rego策略
├── approval/             # 审批状态与Webhook
├── connectors/
│   ├── crm/
│   ├── erp/
│   ├── database/
│   └── internal_api/
├── data_guard/           # 行列过滤、脱敏与DLP
├── audit/                # Trace、指标与SIEM输出
├── migrations/
├── tests/
└── docker-compose.yml

services:
  gateway:
    build: .
    command: uvicorn edge.main:app --host 0.0.0.0 --port 8080
    env_file: .env
    depends_on: [postgres, redis, opa]

  opa:
    image: openpolicyagent/opa:1.8.0
    command: ["run", "--server", "/policies"]
    volumes:
      - ./policy/rego:/policies:ro

  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: mcp_gateway
      POSTGRES_USER: gateway
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7-alpine

volumes:
  pgdata:

镜像版本只是文章核验时的示例，正式项目应确认可用版本并固定镜像摘要。不要把 CRM、ERP、数据库或 WordPress 的真实凭据写入 Compose、文章、日志和 Git。

分阶段实施步骤

盘点 CRM、ERP、数据库与内部 API，列出数据负责人、认证方式、业务动作和敏感等级。
选择一个只读业务域试点，例如 CRM 客户摘要，不从任意 SQL 或写入 ERP 开始。
建立 Tool Catalog，统一名称、Schema、版本、风险、负责人、输出字段和审批策略。
接入企业 IdP，验证 Token 发行者、受众、期限和 Scope，并建立 Agent 注册表。
开发 Connector，后端凭据只保存在 Secret Broker，禁止返回给 Agent。
在 Gateway 与源系统同时实施最小权限；数据库使用只读账户、视图与行级权限。
部署 OPA 等策略引擎，先以影子模式记录“如果执行会允许还是拒绝”。
加入结果脱敏、大小限制、Prompt Injection 检测和敏感目的地控制。
为外部发送、写入、删除、付款和权限变更配置服务端人工审批。
接入结构化日志、指标与告警，建立调用量、拒绝率、审批时长、错误率和后端延迟看板。
使用正常业务集、越权集、跨租户集、重复调用集和审批重放集进行回归测试。
逐步扩大工具范围；每次新系统或新工具上线都经过安全、业务和数据负责人审核。

企业落地示例

销售 Agent

销售人员询问“总结华东区本周高风险机会”。Gateway 只向 Agent 暴露 CRM 汇总与活动查询工具；策略按销售团队过滤客户；Data Guard 隐藏私人电话和邮箱；Agent 可以生成跟进建议，但批量发邮件进入审批。

采购 Agent

采购人员提出创建采购申请。Agent 调用 ERP 草稿工具，Gateway 验证部门、成本中心、供应商和金额。低于制度阈值的草稿可以创建，但审批采购单与付款仍由 ERP 原有工作流负责，不由 MCP Gateway 取代。

数据分析 Agent

Agent 只能调用参数化聚合工具访问只读副本，不能提交任意 SQL。结果限定行数和字段；包含小样本个人信息时自动拒绝或聚合；所有查询带 Decision ID 写入数据库审计。

内部运维 Agent

只读健康检查可自动调用；重启服务需要值班工程师审批；生产数据库修改默认禁止。即使 Agent 受到 Prompt Injection，也无法看到未获准的高危工具。

与其他方案对比

方案	优点	局限	适用场景
Agent 直连内部 API	开发快	凭据分散、审计和权限不一致	低风险原型
每个系统独立 MCP Server	贴近业务域	多客户端治理重复	单域或小规模
API Gateway＋MCP Adapter	复用现有 API 管理	缺少 Agent 工具目录与语义策略	已有成熟 API 平台
企业 MCP Gateway 3.0	身份、目录、策略、审批、审计统一	建设和运营成本更高	多 Agent、多系统、生产环境

若企业已有 API Gateway、Service Mesh、IdP 和 OPA，不必推倒重建。MCP Gateway 应复用现有认证、服务发现和策略基础设施，只增加 MCP 协议、工具目录、Agent 身份上下文和审批体验。

风险、限制与注意事项

协议不等于授权： Tool Schema 只描述参数，业务权限仍需策略与源系统强制执行。
Token Passthrough： 禁止把发给 Gateway 的 Token 原样传给后端；验证受众并使用短期后端凭据。
Prompt Injection： CRM 备注、工单和 API 返回都属于不可信数据，不能改变工具权限和审批规则。
工具爆炸： 动态筛选可见工具，避免把数千 Schema 塞入模型上下文。
重复副作用： 所有写工具使用幂等键；超时后查询后端结果再决定是否重试。
审批疲劳： 优先缩小工具能力，避免所有动作都弹审批；高风险参数变化必须突出显示。
跨租户泄漏： Gateway 与源系统双重实施租户和资源过滤，并做负向测试。
版本漂移： Tool Schema、Connector、后端 API 和策略必须绑定版本并可回退。
单点风险： Gateway 需要高可用、限流、熔断、备份与灾难恢复；故障时高风险写操作 fail-closed。
Agent Identity 演进： MCP 对 Agent 身份和委托的标准仍在发展，本文方案应保留适配层。

事实依据与来源

MCP 官方文档确认协议用于连接 AI 应用与外部数据源、工具和工作流；工具以名称、描述和输入 Schema 暴露。官方 2026 年授权教程使用 OAuth 2.1 保护敏感资源和操作；安全最佳实践要求实施授权的 Server 验证每个入站请求，且不能把状态句柄当作认证。Enterprise-Managed Authorization 文档提出由企业 IdP 维护获批 MCP Server 和访问策略。OpenAI Agents SDK 官方文档确认 MCP Server 可配置 require_approval，并支持暂停、批准或拒绝后恢复运行。NIST 零信任架构强调面向用户、资产和资源的最小权限逐请求决策。

“企业 MCP Gateway 3.0”、分层架构、工具目录字段、OPA 策略、Connector 设计和 Docker 配置是本文参考实现，不是 MCP 官方产品或标准版本。Agent Identity、委托和未来协议扩展仍可能变化；生产部署必须以实施时的 MCP 正式规范、企业 IdP、源系统授权模型和法律合规要求为准。

内容核验日期：2026 年 09 月 01 日。

FAQ

企业 MCP Gateway 3.0 是 MCP 官方版本吗？

不是。“3.0”是本文用于描述第三代企业治理架构的项目名称。MCP 官方规范有自己的日期与版本，部署时应以官方最新稳定规范为准。

MCP Gateway 能取代 API Gateway 吗？

通常不能，也没有必要。API Gateway 继续负责传统 API 鉴权、限流和路由；MCP Gateway 增加工具目录、Agent 身份上下文、MCP 协议、参数级策略和审批，可在现有 API 平台之上建设。

是否应该把整个数据库开放为一个 SQL 工具？

生产环境通常不应这样做。优先开放参数化查询、只读视图、存储过程和聚合工具，并在数据库侧实施只读账户、行级安全、超时和结果限制。

如何把 CRM 权限传递给 Agent？

Gateway 验证员工身份和 Agent 身份，根据客户归属与角色做授权，再使用服务身份或受控的代表用户 Token 调用 CRM。不能让 Agent 自己声明销售区域或客户权限。

为什么不能直接转发用户 Token？

因为发给 Gateway 的 Token 具有特定受众和权限，直接传给后端会形成 Token Passthrough 风险。Gateway 应验证受众，并为后端获取独立短期凭据。

哪些工具必须人工审批？

外部发送、公开发布、批量导出、修改客户负责人、ERP 审批、删除、付款和权限变更应默认审批或禁止。只读与低风险可逆操作可按策略自动执行。

一个 Gateway 可以连接多个 MCP Client 吗？

可以。Gateway 的价值之一就是让多个企业助手、编码 Agent 和自研客户端复用同一工具目录与治理层，但每个请求仍要按用户、Agent、客户端和资源重新授权。

MCP Registry 可以直接作为企业工具白名单吗？

公开 Registry 可帮助发现和验证发布来源，但企业仍需建立内部获批目录，对 Server 代码、权限、数据处理和版本进行审核。公开可发现不等于企业可使用。

Gateway 故障时应该怎样处理？

只读低风险能力可以按预案降级；写入、删除、付款和权限修改应 fail-closed。必须配置多副本、健康检查、限流、熔断、备份和告警。

参考来源

工具评测文章

工具选型与提示词资料

适合阅读工具评测、工具推荐、对比测评类文章后继续转化。

工具选型表 按场景、价格、上手难度和核心能力筛选合适的 AI 工具。 查看资料包 提示词模板包 提供写作、运营、编程、图片和视频生成常用提示词模板。 查看资料包