物界前沿
MCP 像 GraphQL，治理比接口更关键
这篇文章最有价值的信息是，它把 MCP 放到 GraphQL 的延长线上，而不是当作一个新协议名词。这个实验设计的对照很必要。过去一个月我带学生跑 AI agent，对比的 baseline 是普通 function calling、REST 工具描述、检索增强生成。一开始我以为 MCP 只是给工具调用换个壳。用了一阵子后，看法有点变化：它真正带来的，是把「模型能调什么、怎么调、调完返回什么」从 prompt 里拽出来，变成一层可治理的接口。
这跟 GraphQL 的历史很像。GraphQL 的核心不是查询语法，而是 schema。Hygraph 那篇讲 API of intent 时说得挺直白：schema 本身就是文档。对人类开发者，这是省事；对模型，这几乎等于给了它一张地图。模型不需要从一段含糊的自然语言里猜字段，而是可以围绕类型、字段、关系来生成查询。知识图谱实验里我们也常遇到类似判断，schema 的粒度决定推理上限。太粗，模型没抓手；太细，维护成本爆炸。
但是，GraphQL 的教训也摆在那里。它曾经被寄予一个 endpoint 解决所有问题的期待，后来很多团队发现，真正麻烦的不是查询怎么写，而是谁有权限查、哪些字段能查、一次查询的成本是多少、复杂嵌套会不会把后端拖死。MCP 如果只学 GraphQL 的灵活，不学它的治理，问题会更明显。因为 MCP 背后不是人类前端，而是模型。模型会组合调用，会幻觉，也会把错误解释成合理路径。
我最近看几篇 arXiv 上的 tool learning 论文，数据集的偏差需要考虑：任务集通常选择边界清楚的 API，字段干净，返回值稳定，失败成本低。真实企业环境里，工具往往连着数据库、支付、CRM、内部文档，甚至能写文件、发通知、改配置。这个实验设计的对照组不能只比能不能完成，还得比越权调用率、重复调用成本、中断后的状态一致性。我前阵子写过一句，AI agent 的花钱能力比赚钱能力先行一步，放到 MCP 上也成立。接口越开放，模型越容易做出看起来聪明、账单上很诚实的动作。
schema 是文档，也是攻击面
从方法论看，MCP 和 GraphQL 最该合流的地方是 introspection。Zuplo 那篇说可以把 GraphQL API 自动转成 MCP server，靠 schema 自省生成工具。这个思路有吸引力，尤其适合已有 GraphQL 的企业。Lewis 等人检索增强生成那篇论文里也提醒，外部知识接入不是把资料扔进上下文就完事，索引结构、证据来源、更新频率都会改变结果。工具接口同理：一个 MCP server 如果只是把 REST 接口硬翻成函数列表，模型仍然在猜；如果它暴露类型化 schema、约束、示例，模型至少有了可验证的边界。
不过我不太赞成把所有能力都开放给模型。Apollo 那篇说未来 MCP 是 GraphQL，意思是每个 API 单独做 MCP server 太碎，不如用 GraphQL 聚合。这个判断有道理，但要看场景。开放生态之前，得先把账算明白。我带研究生做实验时，一个很朴素的原则是：先固定变量，再谈泛化。MCP 的泛化能力很强，前提是权限、审计、成本、回滚都先固定下来。否则你看到的不是智能，是一堆不可复现的 side effect。同时开多个 agent 会话，机器容易卡死，这个现象不只是算力问题，也是状态追踪失控。
所以这篇文章说 that's fine，我觉得只对了一半。像 GraphQL 不是问题，问题在于是否继承 GraphQL 的治理框架。REST 和 OpenAPI 时代，接口靠文档约束人类；MCP 时代，接口要靠类型、权限和评测约束模型。对比的 baseline 应该是同一任务下：手写 prompt、OpenAPI tool spec、GraphQL-to-MCP、RAG-only。指标也得分层：任务成功率、token 成本、错误恢复时间、权限违规次数。只比能不能发出去没意义，就像我们做知识图谱，不能只比实体链接 F1，不比下游推理是否被 schema 噪声带偏。
往后看，我的判断是，MCP 不会直接变成 GraphQL，但未来一两年内会出现一种受治理的 MCP：由 OpenAPI 或 GraphQL schema 生成，默认能力白名单，带调用预算、审计日志和评测 harness。企业会先在小范围封闭生态里把成本、权限和复现性算清楚，再逐步开放链路。真正胜出的协议，未必最灵活，而是最像论文里的附录：可检查，可复现，出了问题能定位。
📌 本文编译自 Hacker News，原文：https://aien.me/mcp-is-the-graphql-of-ai-and-thats-fine/
版权归原作者所有，本文为基于公开报道的编译与独立分析。
