MCP 协议开放，画布只认 24 家：Figma 白名单撞上 Pi 1.0

MCP 协议作者向 Figma 发出 please fix this，官方回他一张 24 个客户端的目录。Pi 1.0 前脚把 MCP 装进核心，后脚发现写画布的权限在别人手里。协议开放与接入开放分成两层：能力挂在哪一档，接入权就攥在谁手里。

9 月 30 日上午 10 点 20 分，David Soria Parra 在 X 上向 Figma 官方账号发了三个词：please fix this。他身份特殊：维基百科的 MCP 条目写明，这套协议 2024 年 11 月由 Anthropic 发布，作者就是他和 Justin Spahr-Summers。他至今在 Anthropic 做 MCP，9 月下旬刚在 X 上推广 Claude 插件门户，顺带给出「Claude 产品线 MCP 用量今年涨 110x」的口径——他本人的推文，转述，未独立核实。协议作者亲自出面要一个公司「修好」，修的东西在 Figma 开发者文档里白纸黑字：「Only clients listed in the Figma MCP Catalog like VS Code, Cursor, or Claude Code can connect to the Figma MCP Server.」只认名单。

这场较真的起因是个 harness。Pi 是一款极简开源 coding agent，仓库 earendil-works/pi 在 GitHub 上有 11.1 万 star（10 月 2 日 GitHub API 实测），官方口径每周数十万人日用。10 月 1 日，Earendil 发布 Pi 1.0，把 MCP 首次装进核心。第二天撞上的，是它想连的 SaaS 根本不看协议兼容性。

三个半小时后，Figma 员工 Gayani 回帖确认：「our remote MCP server only accepts clients on our supported list, and Pi isn't on it yet.」想加，填表，或者联系客户经理。Figma CEO Dylan Field 随后补了一句「We plan to support Pi」。没有时间表。同一天，HN 上「Figma restricts MCP access to whitelisted clients, excluding Pi」拿下 181 分、102 条评论，MCP 作者的那句「I envisioned an open ecosystem」被顶在最前面。

这件事值得你花十分钟，因为你下个季度大概就要做一次选型：给团队配 agent 时，这份 agent 到底能连上哪些系统，决定权在谁手里？Pi 1.0 与 Figma 的这次相撞，把答案提前写在了目录页上。而且这一天来得不孤立——过去两年，MCP 从一家之言长成跨厂商标准，服务器、教程、专门的会议同步膨胀，「开放生态」被重复了太多次，很多人把「协议开放」自动读成「接入开放」。9 月 30 日到 10 月 1 日这 48 小时，把这两个词重新拆开了。

规范谁都能实现，名单规范管不着

先核协议层。MCP 是开放标准：2024 年 11 月 Anthropic 发布，2025 年 3 月 OpenAI 接入，4 月 Google 跟进；2025 年 12 月，Anthropic 把协议捐给 Linux Foundation 旗下的 Agentic AI Foundation，Anthropic、Block、OpenAI 共同创始（以上时间线出自维基 MCP 条目，该条目引 TechCrunch 与 The Register）。2026 年 7 月 28 日，维护者敲定 MCP 2.0 大版本，把协议层改成无状态。

规范文本任何人都能实现。客户端、服务器、SDK，全部开源，任何人都能写。协议规范里没有任何一条说「server 必须接受所有 client」。这是理解整件事的起点：MCP 的「开放」只覆盖到协议层。

接入是另一层。一个 MCP server 暴露在公网上，就是 Figma 生产环境的一个入口。要不要开这个入口、开给谁、开多大，是 server 运营方的运营决策，任何开放协议都管不到这里。OAuth 要配 client，速率要设限，审计要落日志，这些都在协议之外。协议管「怎么说话」，运营方管「让不让你进门」。两层都合法，两层同时存在。

会混在一起，是因为过去两年里，多数 MCP server 确实谁都能连。社区 server、开源实现、官方 demo，默认全开。开放协议加上默认全开的 server，让人记成了一件事。9 月 30 日，Figma 把两层拆开给你看：协议我支持，名单我说了算。

Figma 给名单外的开发者留的那扇门也值得看清。开发者文档里的入口是一个 Asana 表单链接，页脚的说法更进一步：想注册新客户端，「reach out to your account team」——联系你的客户经理。个人开发者没有客户经理。这扇门的宽度取决于你的合同金额，开放协议的接入条款长成了企业销售的形状。

还有一个容易被忽略的细节：Figma 桌面 app 里那个本地 MCP server，名单外客户端照样能连。也就是说，Figma 同时运营着「开放入口」和「名单入口」两套门。读文件走开放的，写画布走名单的。这套组合拳不新鲜——健身房白天免费开放体验区，器械区刷会员卡。区别在于，MCP 目录页把这件事写得像技术兼容性列表，读的人容易把权限差漏掉。

写画布只放在远程一档，远程一档只认名单

把 Figma 的接入结构拆成表格，冲突点就现形了。官方帮助文档给出一张客户端支持矩阵，三列决定 agent 能力：能不能连桌面版 server、能不能连远程 server、能不能写画布。10 月 2 日实测的目录页共列 24 个客户端。三个数字对不上号——24 个名字、2 个入口、1 份名单，能力就挂在这三层错位上。

客户端类型	桌面 server	远程 server	写画布
目录内 24 家（Claude Code、Codex、Cursor、VS Code、Warp 等）	✓	✓	✓
目录外客户端（Pi、OpenCode 等）	✓	✗	✗
目录内只读客户端（OpenHands、Zed 等）	✓	部分	✗

表格读完，人话版是三行。第一行：白名单内的头部客户端，桌面远程全通，画布随便写。第二行：名单外的任何客户端，桌面版能连、能读设计稿，远程那条路被封死，写画布跟着没了。第三行：名单内也有三六九等，OpenHands 和 Zed 只拿到本地只读权限。名单不仅决定「能不能连」，还决定「能连到哪一层」。

为什么写权限只在远程一档？官方帮助文档的答案很直接：写画布是 agent 对 Figma 生产环境做操作的能力。Figma 3 月的官方博客写明，agent 写画布「eventually be a usage-based paid feature, but is currently free during the beta period」——最终按用量计费。把唯一写入口放在远程一档，认证、审计、配额三样东西才收得拢。能力挂档，档位连着计费。

这条结构决定了：Pi 连桌面 server 没人拦，读设计稿照旧。它失去的是 agent 替用户写画布的能力，而这恰是「agent 驱动设计」故事的核心动作。Pi 1.0 发布文把 Codemode 列为头号特性，发布次日，这个特性的上限由别人划好了。

名单内外的差距有多大，可以拿两个客户端对比。Claude Code 在目录里的待遇：远程桌面全通、画布可写、还挂了官方 Figma 插件链接。OpenHands 在目录里的待遇：只有桌面版、只读。同一个协议、同一个 server、两种待遇。协议兼容性三家里一模一样，差别全在名单那一列。这个对比拆穿了目录页的排版魔术——它长得像兼容性矩阵，读起来得像权限价目表。

Figma 为什么把写权限收得这么紧，还有一层行业背景。设计文件的写操作直接改动客户的源文件库，改坏了就是生产事故。权限收紧有质量控制的成分：24 家头部客户端的 agent 行为可以被逐家评估，几千个长尾客户端管不过来。这条理由和计费理由叠在一起，让名单比单纯「想收钱」难反驳——而它带来的产业后果一样重：新 harness 的能力上限，由别人的商务团队决定。

白名单有工程理由，价目表也有

给 Figma 说句公道话。远程 server 是 Figma 托管的公网入口，背后连着 OAuth、审计、配额计费三套系统。开放全部客户端意味着滥用面同步打开：脚本注册、凭证转卖、速率滥用都会从开放入口进来。收紧到 24 家，运营成本可控。这是真实的工程理由。安全边界从产品层挪到商务层，对 Figma 是理性选择。

理性选择也有价格，价格写在两边。名单这边：写画布是 agent 时代设计工具的核心场景，Figma 把这个场景的新入口抓在自己手里，先按名单分配，再按用量计费。生态那边：dsp_ 的原话——「in spirit, when I created MCP, I envisioned an open ecosystem. That to me feels core. Seeing restrictions like this is sad」。协议作者管这叫 sad；目录页脚写着「reach out to your account team」。两种语言，同一个东西：接入权。

HN 评论区把这两边摆得很开。高赞评论说白名单「against the spirit of MCP」。另一条高赞反问：「Spam is against the spirit of email.」垃圾邮件从来合法地存在于协议之上，邮件协议照样运行了几十年。开放协议上的商业管控，历史先例一长串。安卓应用商店、iOS 审核、Chrome 扩展审核，全都是「开放平台+名单」的成熟形态——先例不缺，缺的是先例的教训：名单一旦建立，名单就是权力。

社区还有一条更冷的反驳：开放 MCP 本身就会杀死 SaaS 产品——LLM 自己能做的功能收不到钱。这条评论在 Figma 身上格外成立：HN 评论区不少用户承认，他们已经跳过设计工具直接让 agent 生成界面。Figma 把 agent 写画布定义成计费入口，是求生动作。

Figma 的处境有一组可看的反差。它在 3 月的官方博客里把 agent 写画布讲成未来计费方向，措辞热情；同一家公司 9 月末在 X 上回协议作者「填表、联系客户经理」，措辞冷淡。热情留给愿景，冷淡留给接入。这个反差不矛盾：愿景需要生态热闹，计费需要入口可控，名单是这两件事的交点。读懂这个交点，再看其他 SaaS 的 agent 接入政策，套路是一样的：宣传页讲开放，文档页讲名单。

把 dsp_ 那句「spirit」再读一遍，它有实际的分量。MCP 已经捐给了 Linux Foundation 旗下的基金会，Anthropic、OpenAI、Block 是共同创始方。一个进了中立基金会的开放标准，最流行的商业 server 实现之一在接入层划了 24 人名单——协议的中立性和实现的开放性从此要分开打分。以后评估任何「开放标准」，问两句话：规范在谁手里，名单在谁手里。答案经常不同。

Pi 花一年投降进 MCP，第二天撞上名单

回头读 Pi 这条线，时间差是事件的核心。Pi 团队一年前还公开反 MCP。pi.dev 首页曾写着骄傲的声明：不支持 MCP。创始人 Mario Zechner 2025 年 11 月写过《What if you don't need MCP?》，把 MCP 的组合性问题逐条拆过。10 月 1 日发布的《You Said No MCP!》把投降过程写得坦白：MCP 这一年变化很大，7 月底 MCP 2.0 落地，模型在自己 harness 上训练，「we look at what the models are doing」，不跟训练分布对着干。

投降换来的东西很具体：Pi 1.0 的 Codemode 原生支持 MCP，还顺带支持 Jev 这类非 LLM 模型。发布当天 HN 1382 分，社区把这一步读成极简派的成年礼：最挑剔的 harness 都进了生态，协议赢了。

协议赢了，接入没赢。Pi 1.0 发布次日，写画布的权限还在名单外面。Earendil 官方博客里那条「hundreds of thousands of people」的口径，在 Figma 的目录页面前没有兑换成名单席位。用户量、star 数、协议兼容，三样都换不来一个写权限。兑换需要的是另一张桌子：客户经理。

HN 评论区有人替 Pi 算过一笔账。Pi 的用户里，把 Figma 设计稿转成代码是高频场景；写回画布是低频场景。损失集中在前者吗？恰恰相反，读这条路 Figma 没有封。损失落在后者：agent 驱动设计的完整闭环里，写不回去，agent 就只是个高级截图工具。

评论区有人说得更直白：Figma 在自己的核心场景外挂了一个「agent 只读区」，把 agent 时代最重要的写入动作留在了人工手里。这笔账的算法各家不同，账单只有一个：写权限。

这轮碰撞里藏着一个值得记下的时序。Pi 用一年时间完成从反 MCP 到进 MCP 的转身，赌的是协议生态的开放性。转身完成的第二天，生态里流量最大的 server 之一用一张 24 人名单回答了这场赌局。投降加速了被拒：进了 MCP 名录的客户端成百上千，名单只有 24 行。

同一周，harness 这一层也在重新洗牌。DeepSeek 把开源 harness 打包成桌面 app，8 月 13 日建仓，10 月 2 日 GitHub 页面显示 24.2 万 star（增速异常，存疑口径，仅供参考），HN 上「中国二进制还是开源可审计」吵成一团；Cloudflare 同日开源决策模型 Clef，Apache 2.0。模型厂在把 harness 铺向每个桌面，SaaS 厂在把 agent 挡在名单外。agent 栈的两端在同一周拔河，绳子的中点就是接入权。

把三家的动作排进同一张时间表，这一周的结构就出来了。9 月 30 日：Figma 员工确认名单，dsp_ 发难。10 月 1 日：Pi 1.0 进 MCP，同日 Cloudflare 开源 Clef 决策模型。10 月 2 日凌晨：DeepSeek Harness 桌面版上 HN。

三天里，SaaS 关门、极简派进门、模型厂铺门。同一个协议，三种用法，三种对「开放」的定义。你用的 harness 站在哪一边，两周后回头看会很重要。

白名单拦的是合规用户，拦不住改 UA 的人

最后核这条白名单的实际效力。HN 里有用户当场晒出绕法：「I use a figma CLI patched to look like Claude code」——把客户端 UA 改成名单内的名字就绕过去了。另一条评论补刀：UA 白名单技术上拦不住伪造，只烦合法用户。OAuth 时代伪造 UA 未必拿到写权限，但社区实测绕过是事实。名单的边界强度，等于客户端身份声明的可信度。

安全工程里有现成的分类法。防人：OAuth 审计、设备指纹、行为风控。防机器：速率限制、异常检测。防 agent：两者都失效——agent 用合法账号、发合法请求、按正确顺序调用工具。Figma 名单管的是「客户端身份」，agent 身份挂在客户端背后。名单拦得住 Pi，拦不住 Pi 背后的用户改一个 header。

一句话收拢：名单精确到客户端，agent 的自由度在名单之下。

这条边界画在错误的层上。写画布的风险点是「agent 拿着用户凭证做超出预期的事」，管这个需要动作层控制（审批、限速、审计日志），Figma 全都有，也全都对名单内客户端生效。名单外的客户端被整档切掉，风险模型里被切掉的还有同一批用户。用户没变，风险没变，变的是客户端名字。名单的颗粒度配不上风险的真实结构。

名单的执行成本也在往用户头上转。名单内客户端出事，Figma 可以按合同条款追责；名单外客户端出事，Figma 的服务条款里没有对应位置。于是合规路径只剩一条：换客户端。你原本用 Pi 管理 Figma 设计稿，现在要么换 Cursor，要么接受只读。切换成本看着不高，叠上团队里每个人的配置、插件、习惯，就是一次小型迁移。名单的权力就在这里：它让「不换」变成持续的不便。

对读者的操作口径很具体。选型时把「支持 MCP」四个字当未验证声明：你的 agent 能连桌面还是远程、有没有写权限、名单入口是什么，三问都问完再签约。采购 agent 平台时，把目标 SaaS 的 MCP 目录页和 OAuth 页一起读，接入条款往往写在客户经理的报价单里。验收时问一句：名单下一次扩容走什么流程、多久、有什么标准。这三问在 Figma 这里全都有现成答案：填表、等计划、问客户经理。

还有一个更远的读法。OpenAI 的 Dots 上周刚把 always-on agent 推向消费者，凭证保险箱、动作审批、后台监控写得密不透风；亚马逊用一纸弹窗切断 Muse 站内代购；FTC 正在起草对 agent 事故的传票。agent 的能力每前进一格，接入的闸门就多建一道：平台关闸、监管拟传票、SaaS 立名单。三条线在同一个十月收紧，MCP 白名单只是其中最有戏剧性的一条——协议作者本人被目录页顶了回来。

Dylan Field 那句「We plan to support Pi」还值得单独掂量。CEO 亲自回帖是姿态，姿态没有日程。名单从 24 家扩到 25 家需要什么？技术对接、行为评估、商务条款，最后才是拉名单。Figma 没说这个流程要多久，也没说标准是什么。

社区里已经有人在传 Figma MCP 未来按用量计费、需要 dev seat——这些说法出自评论区，转述，仅供参考，但方向与官方博客的「usage-based paid feature」一致。等你等到计费上线那天再回头申请接入，谈判条件已经变了。姿态和条款之间，永远选条款。

下一次有人向你推销「支持 MCP」的 agent 平台，你会知道该问什么。问完三问，再加一句：这份名单下一次开门，是什么时候？