Claude MCP 入门：企业内部工具如何暴露给 AI agent 调用

Nayxxu

119人浏览 · 2026-06-12 10:34:36

Nayxxu · 2026-06-12 10:34:36 发布

Claude MCP 值得开发团队关注，但它不是“把数据库直接交给 AI”的捷径。更准确的说法是：MCP 把模型和企业内部工具之间的连接方式标准化了，让 Claude Fable 5、Claude Opus 4.8、GPT-5.5 这类模型在需要时可以通过受控工具读取数据、执行查询、调用内部服务。

这件事的价值不在“会聊天”，而在“能接入业务上下文”。比如研发团队希望 AI 读取 GitHub issue、查询 Postgres、查看内部知识库、创建工单、拉取 CRM 客户状态，过去通常要为每个模型、每个系统单独写适配层。MCP 的思路是把适配层沉到 MCP server，模型侧或客户端侧按统一协议调用。

MCP 的基本架构

一个典型 MCP 场景里有三层：

MCP Host：承载模型和对话体验的应用，比如 Claude Desktop、IDE、企业内部 AI 工作台。
MCP Client：负责和 MCP server 建立连接，把模型的工具调用请求转成协议消息。
MCP Server：封装具体数据源或工具，比如 GitHub、Slack、Google Drive、Postgres、内部 CRM、工单系统。

Anthropic 官方介绍 MCP 时，把它定位为连接 AI 工具和数据源的开放标准。官方文档里也明确提到，MCP 可以连接本地文件、数据库、搜索工具、计算器和业务工作流。GitHub 上的 modelcontextprotocol/servers 仓库则提供了参考 server 和相关资源。

开发者真正要做的是两件事：先把企业内部能力封装成工具，再定义好权限边界。前者是工程问题，后者是治理问题。后者更难。

企业内部工具怎么暴露给 AI

以“查询客户订单并创建售后工单”为例，MCP server 可以只暴露三个工具：

get_customer_profile(customer_id)
get_recent_orders(customer_id, limit)
create_support_ticket(customer_id, order_id, reason, priority)

不要让模型直接拿数据库连接串，也不要把完整后端 API 网关裸露给 agent。MCP server 应该像一个受限的业务适配层，只提供当前场景需要的能力。

比较稳的落地流程是：

先选一个低风险场景，比如只读知识库、只读订单状态、只读项目 issue。
为 MCP server 配服务账号，不用个人账号长期跑生产任务。
每个工具都做参数校验，尤其是 ID、分页、时间范围、权限范围。
写入类操作必须加审批或二次确认，比如创建工单、修改客户状态、触发退款。
保存调用日志，记录用户、工具名、参数摘要、返回状态、模型输出和人工确认结果。

如果你已经有 OpenAPI 或内部 RPC 描述，不建议一口气全量暴露。企业里最常见的问题不是 MCP 写不出来，而是工具太多、权限太粗、日志太少，最后没人敢把它接进真实流程。

国内团队使用 MCP 的限制

国内团队做 Claude MCP，限制主要有四类。

第一是访问链路。Claude 官方服务在国内直接访问并不稳定，企业内网到海外 API 的链路也可能受到网络质量、DNS、代理策略和合规要求影响。研发演示能跑，不代表生产环境能跑。

第二是账号和结算。很多团队用海外信用卡、海外主体、个人账号做测试，到了企业采购、发票、人民币结算、权限分级时就卡住。

第三是数据合规。MCP 的价值在于连接内部数据，但这也意味着企业要判断哪些数据能出域、哪些只能在内网处理、哪些需要脱敏后再传给模型。客户资料、合同、代码、财务数据都不能随手丢进上下文。

第四是安全风险。MCP server 本质上是工具入口。近期香港、海外安全社区已经多次讨论 MCP 相关的 prompt injection、工具投毒、权限串联和远程执行风险。企业落地时，应该把 MCP server 当成一个需要鉴权、审计、限流和变更管理的后端服务，而不是一个随便装的插件。

和函数调用有什么区别

函数调用通常更偏模型厂商 API 内部能力：你把工具 schema 发给模型，模型返回要调用哪个函数。MCP 则更像一层开放连接协议，把工具定义、通信、server 生命周期和生态连接标准化。

简单说：

函数调用适合单个应用内快速接工具；MCP 更适合多个 AI 应用共享同一批工具。

如果企业只有一个客服机器人，函数调用可能够用。如果企业希望 Claude、GPT-5.5、内部 agent、IDE 助手都能访问同一套知识库、工单、代码和数据库能力，MCP 的价值会更明显。

生产环境建议

我更建议把 MCP 做成“企业 AI 工具网关”的一部分，而不是把它散落在个人电脑里。

可以按这个结构设计：

AI 应用 / Claude 客户端
        |
MCP Client
        |
企业 MCP Gateway
        |
业务 MCP Servers
        |
CRM / GitHub / 工单 / 数据库 / 知识库

企业 MCP Gateway 负责统一鉴权、审计、限流、脱敏、工具白名单和风险策略。业务 MCP server 只负责连接具体系统。

模型侧也建议做多模型路由。Claude Fable 5 可以用于复杂推理和长任务，Claude Opus 4.8 适合代码与专业知识工作，GPT-5.5 可以作为另一条高能力模型路径。不要把 MCP 能力绑死在单一模型上，否则后续成本、稳定性和供应商策略都会变成风险。

词元无忧 API（ token5u API）价值体现在这里。它的价值不在“替代 MCP”，而在模型调用层提供统一入口：支持 Claude、GPT、Gemini 等主流模型，接入方式对标 OpenAI API，同时支持人民币结算、专线优化和企业级服务。对于国内团队来说，MCP 负责连接内部工具，词元无忧 API（ token5u API）负责模型调用和多模型路由，边界更清楚。

一段伪代码思路

// 伪代码：业务侧只暴露受控工具，不暴露底层数据库
server.tool("get_order_status", {
  customerId: "string",
  orderId: "string"
}, async ({ customerId, orderId }, context) => {
  await authz.check(context.user, "order:read", customerId);
  const order = await orderService.findMaskedOrder(customerId, orderId);
  return {
    status: order.status,
    paidAt: order.paidAt,
    shipment: order.shipmentStatus
  };
});

server.tool("create_ticket", {
  customerId: "string",
  orderId: "string",
  reason: "string"
}, async (args, context) => {
  await authz.check(context.user, "ticket:create", args.customerId);
  await approval.requireIfHighRisk(args, context);
  return ticketService.create(args);
});