Figma 联创泼冷水：MCP 不是完美协议，它更有利于前沿实验室

过去一年，MCP 几乎成了 AI 工具互联的代名词。只要一个产品宣布“支持 MCP”，就意味着它能被 Claude、Cursor、各类智能体直接调用。标准统一带来的便利显而易见，但并不是所有人都认为这是一套公平的规则。

Figma 联合创始人 Dylan Field 在印度举行的首届 Config 大会上宣布新增 20 个 MCP 合作伙伴，包括 Amp、ClickUp、Dia、JetBrains 的 Junie、Linear、Meta Muse、Mistral、Notion、OpenCode 与 Sarvam Agents。同一场媒体沟通里，他给出了一个相当直白的判断：MCP 不是完美的协议，而且它更有利于前沿实验室。

一分钟速览

• Figma 新增 20 个 MCP 合作伙伴，继续扩大生态接入。
• Dylan Field 明确表示 MCP“有大量改进空间”，且优势偏向头部模型厂商。
• 争议焦点是“非对称上下文共享”：Anthropic 并未通过 MCP 暴露自家 artifacts 与云资源。
• Figma 的立场是开放，但不会一次性暴露全部数据，理由是滥用风险。
• 此前 MCP 联合创建者曾公开抱怨 Figma 不支持开源工具 Pi。

“开放”这件事，账要两边算

MCP 的设计初衷是让模型和外部工具之间有一份通用接口：工具描述自己有什么能力，模型决定什么时候调用。对工具方来说，接入 MCP 意味着能被更多智能体发现；对模型方来说，接入越多工具，回答就越有用。

问题在于，这套交换并不对等。工具方把自己的数据、能力和调用入口交了出去，模型方却未必把自家的云资源、生成物、上下文暴露回来。Field 的抱怨正指向这一点：讨论被简化成“开放 vs 封闭”，但真正被忽略的是“谁在共享上下文，谁只在索取”。

数据护城河与滥用风险

Figma 的谨慎有现实理由。设计文件里不只有图层和组件，还有未发布的产品、客户品牌、营销节奏。一旦通过 MCP 全量开放，任何接入了该服务器的智能体都可能把数据带走。Field 的说法是，暴露得越多，被滥用的概率越高；大多数用户没有恶意，但产品必须为少数恶意场景设计。

这也是所有 SaaS 公司在 MCP 时代面临的共同难题：开放接口能带来生态和流量，但数据一旦离开边界，就很难追踪流向。传统的 OAuth 授权只能回答“能不能访问”，回答不了“访问之后拿去做了什么”。

标准之争，本质是入口之争

MCP 已经具备事实标准的势头，但标准从来不只是一份协议。谁定义工具描述的结构，谁决定权限粒度，谁掌握参考实现，谁就在生态里拥有更大的话语权。对 Figma 这类掌握专业数据的公司，最理想的局面是“支持标准，但保留分级授权”：基础能力开放，深度数据按场景、按客户、按用途放行。

这也解释了它为什么一边扩大合作，一边公开表达保留。扩大合作是生态需要，公开保留是谈判筹码。两者并不矛盾，反而是标准制定期最常见的姿态。

开发者该关心什么

对工具开发者，短期最实际的问题是权限设计：不要做一个“全量读写”的 MCP 服务器，而是把能力拆成可审计的小块。对模型厂商，问题则是互惠：如果只要求别人开放，自己的云资源却留在墙内，标准迟早会分裂成几个互不兼容的版本。

对普通用户，这场争论的结果会体现在很具体的地方：你在设计工具里说一句“帮我把这版做成落地页”，AI 能不能真的读到图层、素材和品牌规范，还是只能拿到一张截图。开放程度决定了 AI 到底能帮到多深。

趋势洞察

AI 工具的互操作性正在经历“先统一、再分层”的过程。统一的是调用方式，分层的是数据权限。未来一两年，MCP 不会消失，但会出现更多围绕它的授权、审计与计费层。真正有价值的公司，不是最早接入标准的那个，而是能在开放与保护之间找到可持续平衡的那个。