运营团队的人想对AI助手说一句话：查一下今天哪些订单赶不上发货截止时间，看看其他仓库的库存，能补上的就创建调拨申请。这种智能体工作流需要调用API——它要拿到当前订单和可用库存，昨天的报表说明不了今天下午还剩多少货，它还得把调拨申请写回履约系统。
为了让公司内部的订单管理API能被智能体调用，工程师可能会搭一个MCP服务器。这是让系统被触达的最快方式，但触达如今已经是最简单的部分。更难的问题在MCP出现之前就存在：智能体进去之后，应该看到什么。MCP只是让这个问题变得紧迫。
一个订单API，能吐出多少不该给的东西
订单管理这类服务的API可能返回一大片信息，包括个人身份信息、敏感的财务与欺诈细节，以及本就不该离开可信网络边界的运营信息。
传统应用的访问控制我们早就知道怎么做：后端检查用户权限，处理上游API调用，只返回合适的视图。但要让智能体灵活工作，工程师就卡在了两难之间。
一个把上游数据全部透传的MCP工具，是安全风险——这是第一难。显而易见的修法是过滤工具响应。但接下来，财务需要订单的另一种视图，客服需要一部分内部备注，另一个团队又接入了库存系统，于是你得维护几十个相似且互相重叠的工具——这是第二难。
出路是字段级契约，不是又一个工具
出路是一份确定性的、字段级的契约，明确规定每个智能体能看什么、能做什么，且独立于上游API和下游智能体。
MCP定义的是智能体如何发现和调用工具；字段级契约定义的是这些工具被允许访问什么。它们是不同的层，两层都需要。
GraphQL提供了一条务实的实现路径。它围绕一个理念设计：API调用应当指明自己需要的具体字段。一次订单状态查询可以小到只问状态和发货截止时间，响应里就只有这两个字段，不管上游系统还能提供多少东西。
这套思路最初是为了在移动网络上收窄庞大的API响应体、省去写BFF的麻烦，如今它给了工程师一个执行智能体权限的位置。比如智能体请求internalFraudScore或customerSSN这类字段，GraphQL服务器可以拦截请求，甚至让这些字段根本不可达。规则属于字段本身，对所有请求该字段的操作统一生效，工具作者不必逐个记得从另一个响应里删掉同一个属性。
写操作同样如此
前面那位运营同事需要申请库存调拨的权限。只读连接会让工作做不成；不加限制的访问又可能让智能体改动库存数量、取消订单或发起退款。一个mutation（GraphQL里对写操作的叫法），比如requestInventoryTransfer，暴露的是特定的业务动作。运行时对它做授权，底层服务在接受请求前检查当前可用量和所需的审批。
这一切不需要替换支撑业务的API。GraphQL层可以架在暴露REST、gRPC、SOAP及其他协议的现有服务之上。订单API可以继续向集成层返回宽记录，而智能体只收到它被允许看到的字段。
这种精确性曾帮助开发者快速构建高效应用，当调用方是在运行时组合操作的智能体时，它更有用。GraphQL已经为应用提供这种字段级契约超过十年，在Shopify、Netflix、Airbnb、Expedia Group和沃尔玛支撑着每天数十亿笔交易。这些公司以及其他无数公司，积累了十年运行这一模型的经验和生产基础设施。
MCP让业务系统能被智能体触达。字段级契约让这种访问成为组织可以控制的东西。GraphQL就是一个摆在眼前的答案。
热门跟贴