MCP 协议：让 AI 智能体安全接入现有 API

假设你运营团队里有个人想问 AI 助手："哪些订单会错过今天的发货截点？检查其他仓库的库存，在能补货的地方创建调拨请求。"

这种 Agent 化工作流需要调用 API。Agent 需要当前的订单和可用库存；昨天的报表无法告诉它今天下午还有哪些库存。它还需要把调拨请求写回到履约系统里。

为了让公司的内部订单管理 API 能被 Agent 调用，工程师可能会构建一个 MCP server。这是让类似系统变得可访问的最快方式，但"可访问"现在是容易的部分。更难的问题——早在 MCP 出现之前就存在的问题——是 Agent 到达之后应该看到什么。MCP 只是让这个问题变得紧迫起来。

一个订单管理这样的 API 可能返回广泛的信息，包括个人身份信息、敏感的财务和欺诈细节，以及从未打算离开可信网络边界的运营信息。我们已经知道如何处理传统应用的访问控制：后端检查用户权限，处理上游 API 调用，只返回相应的视图。

所以，启用这些灵活 Agent 的工程师陷入了两难境地。一个向下游传递一切的 MCP 工具会带来安全风险。那是"岩石"。明显的修复方案是过滤工具的响应。但随后财务需要不同的订单视图，支持部门需要部分内部注释，另一个团队连接了库存系统，现在你得维护数十个相似且重叠的工具。那是"硬 place"。

出路是一种确定性的、字段级别的契约，精确指定每个 Agent 可以看到和执行什么，独立于上游 API 和下游 Agent。MCP 定义了 Agent 如何发现和调用工具。字段级契约定义了这些工具被允许访问什么。它们是不同的层，两者都需要。

GraphQL——一种流行、广泛部署的技术——给我们提供了一种实现这一点的方法。

GraphQL 的设计理念是 API 调用应该指定它们需要的确切字段。一个订单状态查询可以小到这样：

query {
  order(id: "order-1842") {
    status
    shipBy
  }
}

无论上游系统提供什么，响应只包含那些字段。最初设计用于在移动网络上缩小大型 API 载荷和避免编写 BFF，现在这个理念给工程师提供了一个强制执行 Agent 权限的地方。

所以，例如，如果一个 Agent 请求像 internalFraudScore 或 customerSSN 这样的字段，GraphQL server 可以阻止请求，甚至让这些字段不可达。规则属于字段本身，并适用于请求它的所有操作。每个工具作者不必记住从另一个响应中删除相同的属性。

写入以相同的方式工作。我们的运营员工需要获得请求库存调拨的权限。只读连接会阻止工作；无限制的访问也可能让 Agent 更改库存数量、取消订单或发出退款。一个 mutation（我们在 GraphQL 中对写入的称呼），比如 requestInventoryTransfer，暴露了特定的业务操作。运行时授权它，底层服务在接受请求前检查当前可用性和任何必需的审批。

所有这些都不需要替换运行业务的 API。GraphQL 层可以位于暴露 REST、gRPC、SOAP 和任何其他协议的现有服务之上。订单 API 可以继续向集成层返回宽泛的记录，而 Agent 只收到它被允许看到的字段。

这种帮助开发者快速构建高效应用的精确性，在调用方是 Agent 在运行时组合操作时更加有用。GraphQL 多年来为应用提供了这种字段级契约，为 Shopify、Netflix、Airbnb、Expedia Group 和 Walmart 的数十亿次日常交易提供支持。这些公司和无数其他公司积累了十年的经验和生产基础设施，运行的正是这个模型。

MCP 使业务系统可以被 Agent 访问。字段级契约使这种访问成为组织可以控制的东西。GraphQL 是一个摆在我们面前的完美答案。