MCP——Model Context Protocol——让 AI Agent 可以在运行时向外部服务发起工具调用。Figma 推出了官方 MCP 服务器，社区也构建了几个更多的。其卖点是：你的 Agent 可以按需、在对话中途直接向 Figma 请求设计数据。无需导出步骤。始终保持最新。
figmascope 采取了相反的架构赌注：一次导出，交付一个包，之后不再连接。这是真正不同的选择，有着不同的含义。以下是每种方式的实际成本和收益。
Figma MCP 服务器是什么
Model Context Protocol 是 Anthropic 的开放标准，用于通过服务器接口将 AI Agent 连接到外部工具。MCP 服务器暴露 Agent 可以调用的类型化工具：get_file、get_node、get_styles 等。当 Agent 需要设计上下文时，它调用工具，MCP 服务器调用 Figma API，结果作为当前提示的上下文返回。
Figma 的官方 MCP 服务器涵盖文件读取、节点检查、组件检索和评论访问。社区 MCP 服务器（GitHub 上有几个）通过自定义模式、额外转换或针对特定 Agent 工作流优化的更窄范围来扩展这些功能。
要使用任何 Figma MCP 服务器，你需要在 Agent 客户端（Claude Desktop、Cursor、Continue 等）中配置它，提供 Figma PAT，服务器作为本地进程运行。当你的 Agent 需要 Figma 上下文时，它调用工具。你不需要明确导出任何东西——Agent 在需要时获取所需内容。
MCP 模型在实践中
典型的 MCP 驱动的 Figma 工作流如下：你打开 Cursor，开始对话，说"从这个 Figma 文件实现结账屏幕"，Agent 调用 get_file，拉取节点树，在上下文中获得设计数据。如果你然后说"设计师更新了按钮令牌"，Agent 可以再次调用并获取新鲜数据。
这种实时连接模型对某些工作流是真实且引人注目的。Agent 正在使用当前数据工作。你不管理导出工件。"设计师推送了更改"和"Agent 拥有它"之间没有手动步骤。
MCP 的优势
实时数据，无导出步骤。Agent 按需获取当前状态。如果设计在十分钟前改变了，Agent 可以看到它。figmascope 需要手动重新导出来捕获更改。
对话式设计探索。"CTA 按钮的颜色是什么？""有多少屏幕引用了这个组件？"使用 MCP，Agent 可以通过调用 Figma 来回答这些问题。使用包，答案只有最后一次导出时那么新鲜。
直接编辑 Figma。一些 MCP 服务器暴露写操作——创建节点、更新属性、发布评论。这只有通过实时连接才可能。静态包没有写路径。
无手动工作流。对于已经使用 MCP 连接 Agent 设置的开发人员，没有导出步骤意味着少一件事需要记住。上下文管理委托给 Agent。
MCP 的劣势
实时连接模型有容易被低估的架构成本。
会话绑定状态。MCP 调用发生在对话会话的上下文中。Agent 在会话 A 中检索的数据在会话 B 中不可用，除非重新获取。如果你开始新的聊天，Agent 从头开始。figmascope 包在会话之间、开发人员之间和工具之间持久存在——它只是文件。
对 git 不透明。没有工件。没有可提交的东西。通知代码的设计上下文不存在于仓库中。六个月后，如果你想了解构建组件时的设计是什么样子，没有记录。有了仓库中的包，你有了设计意图的提交历史。
需要连接。MCP 需要运行的服务器、实时的 Figma API 连接和具有访问权限的 PAT。网络中断、Figma API 宕机、PAT 过期——Agent 没有上下文。包在飞机上也能工作。
依赖模型的检索。Agent 通过 MCP 请求什么取决于它决定请求什么。它可能不获取令牌值。它可能不拉取组件库存。它可能只请求它认为需要的节点子树，错过来自相邻节点的空间上下文。检索是概率性的，而非确定性的。figmascope 每次都以固定模式获取所有内容。
更难测试和复现。"我的 Agent 从这个 Figma 数据在这个时间点构建了这个组件"——使用 MCP 无法验证。获取是短暂的。有了包，你可以精确重放：相同的包、相同的 Agent、相同的提示——确定性输出。这对调试、代码审查和发布责任很重要。
上下文窗口压力。对复杂 Figma 文件的简单 get_file 调用返回巨大的 JSON 树。Agent 必须进行选择性工具调用以保持在上下文预算内。这引入了可能出错的启发式和判断调用。figmascope 将树预处理为结构化 IR，只包含所需内容，大小已知且有界。
figmascope 的包模型：一次捕获，永远交付
figmascope 从 Figma REST API 导出一个纯文件的 .zip——无插件、无服务器，在你的浏览器中运行。包包含：
CONTEXT.md——人类可读的规范，Agent 可读的规范tokens.json——类型化设计令牌，级联来源：Figma 变量 → 从频率推断 → 无screens/*.json——带布局语义的每屏 IR：stack、overlay、absolute、leaf；INSTANCE 节点上的componentId；文本上的stringRef.keyscreens/*.png——2× 参考截图components/inventory.json——完整组件索引strings.json——所有文本内容，带键值_meta.json——导出元数据
一旦导出，包就是自包含且不可变的。它与它描述的代码一起进入你的仓库。任何 Agent、任何会话、任何开发人员、任何 CI 任务都可以读取它。不需要连接任何东西。
可版本化的差异：像代码一样比较包
这是包模型最强的论据。因为输出是结构化 JSON 和 Markdown，你可以对它进行差异比较。
在设计冲刺前导出一个包。之后再导出一个。对 tokens.json 运行 diff：
- "spacing.4": "16px"
+ "spacing.4": "14px"
这是你间距比例中的一个破坏性变更。它是可见的、可审查的，并可追溯到提交。使用 MCP，同样的变更会悄悄发生——Agent 下次获取时得到新值，没有任何变更的记录。
你可以将此作为 PR 门控：将包导出作为设计交付的一部分，提交它，在实施开始前要求设计师和开发人员对差异签字确认。这是设计规范即代码。MCP 没有等效物。
确定性论据
相同的 Figma 文件版本 + 相同的 figmascope 导出 = 相同的包。每次都是。IR 模式是固定的。令牌溯源逻辑是确定性的。字符串键提取是基于规则的。
MCP 检索不是确定性的。Agent 决定获取什么。不同的 Agent、不同的提示措辞、不同的上下文预算——不同的获取行为。输出依赖于模型。
对于生产 UI 代码生成，确定性很重要。你希望生成组件的规范是可复现的。你希望能够从相同输入重新生成组件并获得一致结果。包支持这一点。MCP 会话不支持。
对比
| 维度 | Figma MCP | figmascope 包 |
|---|---|---|
| 数据新鲜度 | 始终实时——获取当前 Figma 状态 | 快照——与最后一次导出一样新鲜 |
| 需要导出步骤 | 否 | 是——每个设计版本一次 |
| 可版本控制 | 否——无工件 | 是——包是可差异化的 JSON + Markdown |
| 跨会话持久 | 否——每次会话必须重新获取 | 是——文件无限期持久 |
| 离线工作 | 否 | 是 |
| 确定性输出 | 否——依赖模型的检索 | 是——相同输入 → 始终相同的包 |
| 上下文窗口压力 | 高——原始 Figma JSON 庞大且无结构 | 低——IR 经过预处理，大小有界 |
| 对 Figma 的写操作 | 是（部分 MCP 服务器） | 否——只读导出 |
| git 历史中的设计规范 | 否 | 是——提交包，追踪设计历史 |
| 需要 Agent 设置 | 是——每个 Agent 客户端配置 MCP 服务器 | 否——任何读取文件的 Agent 都可以使用 |
| i18n 字符串键 | 基础 Figma MCP 模式中没有 | 是——IR 中的 stringRef.key + strings.json |
| 空间/布局 IR | 原始 Figma 节点树（无语义布局类型） | 类型化 IR：stack / overlay / absolute / leaf |
| 令牌溯源 | 变量（如已设置）；否则原始值 | 变量 → 从频率推断 → 无 |
MCP 擅长"实时编辑 Figma"——包擅长"构建生产 UI"
这是诚实的总结。如果你的工作流是对话式设计探索——"更改这个组件"、"注释这个屏幕"、"这个框架上的颜色令牌是什么"——MCP 的实时连接是正确的模型。Agent 是设计过程中的合作者，它需要当前数据才能做到这一点。
如果你的工作流是从最终（或接近最终）设计构建生产 UI——实现组件、连接状态、编写测试——包模型更好。你希望规范锚定在你的仓库中，在设计迭代中可差异化，任何 Agent 无需配置即可读取，且足够确定性可以依赖。
这两种模型是互补的。当设计处于变动状态且你在协作迭代时使用 MCP。当设计稳定且你将其交给工程师实施时导出 figmascope 包。包成为实施所依据的真实来源——可追溯、可审查、可复现。