Figma详解如何用规范、组件库与访问控制约束智能体

在Config India 2026上，Figma更明确地展示了其自有智能体以及第三方智能体如何在平台内部工作的框架。根据其发布说明以及TechCrunch的一篇报道，Figma介绍了一组旨在为智能体提供更多上下文、同时施加更多约束的工具：一种新的基于Markdown的编辑器Specs、附加在设计组件库上的指南、代码来源、集中化设计系统，以及通过Figma MCP扩展而来的更广泛支持。这些能力背后的共同主线是治理。Figma不仅是在增加AI功能，也在尝试界定团队应如何通过规则、文件和共享参考资料来塑造智能体的行为。

这种对防护栏的强调，似乎与Figma自己承认的一项限制有关。TechCrunch报道称，在过去一周将其画布中的智能体向更广泛用户开放之后，Figma也同步提供了更多工具，用于把智能体引导到更可预测的结果，因为AI本身具有非确定性。这样的表述很关键。Figma并没有把智能体描述成默认就完全可靠的系统，而是把上下文与系统规则定位为减少波动、降低结果差异的一种方式。

为意图与上下文提供原生位置

这次发布中最核心的公告是Figma Specs。在Figma的发布说明里，Specs被描述为一个承载上下文的原生空间，它将书面意图、视觉探索和技术细节汇聚在一起，供团队成员和智能体共同使用。TechCrunch则补充称，这是一款Markdown编辑器，允许用户以一种相对简单的方式定义自己的设计语言。按照该报道的说法，Specs既可以作为Figma中的独立文件存在，也可以与画布并列出现，而且用户还可以引用其他Figma元素，例如画布元素、FigJam图表、代码图层和设计稿。

综合这两个来源来看，Specs的设计目标显然不只是为人类记录项目内容。它同样被定位为Figma内AI系统可以读取的机器可理解上下文。Figma的发布说明并没有像TechCrunch那样深入说明嵌入或引用其他Figma对象的具体技术细节，但两者在更宏观的角色定位上是一致的：智能体应当能够查阅与人类协作者相同的书面和视觉上下文，从而在行动时拥有更统一的参照依据。

在可用性方面，Specs的状态比其他一些公告更清晰。Figma表示，Specs目前正在向付费方案以公开测试版的形式逐步推出。对组织内部讨论治理问题而言，这一区分很重要：该功能并未被描述为全面正式可用，也没有被列为面向所有套餐开放。

用组件库、指南与代码来约束智能体

除了Specs之外，Figma也在把其他控制层正式化。其发布说明称，团队可以向已发布的设计组件库添加指南，以便让智能体遵循既有模式并避开反模式。该功能目前正以公开测试版形式推出。Figma还表示，来自GitHub代码仓库或npm软件包的代码可以作为代码来源导入，帮助智能体构建和编辑能够反映真实设计系统的组件和代码图层。这个功能目前正以封闭测试版形式推出。

TechCrunch给出的描述与此相近，称团队可以引入更多与设计相关的上下文，包括设计组件库、代码库和指南，以管理设计系统的上下文，并且智能体可以参考这一集中化系统来遵守规则。相比之下，Figma自己的发布说明在产品封装方式上更具体。它把集中化设计系统描述为一种组合包，将设计组件库、代码库和指南汇集到单一设计系统中，从而让作者维护起来更容易，也让所有使用者更容易遵守。不过，Figma把集中化设计系统标注为仅预览阶段。

• Specs：付费方案公开测试版。
• 已发布设计组件库中的指南：公开测试版。
• 来自GitHub代码仓库或npm软件包的代码来源：封闭测试版。
• 集中化设计系统：仅预览。
• 新增20家合作伙伴支持的Figma MCP：现已可用。

这样的拆分很重要，因为围绕治理的整体叙事分散在成熟度不同的多项功能之中。有些控制能力付费客户已经可以较广泛使用，有些只向部分用户开放，还有一些仍停留在预览阶段。任何企业如果要评估今天究竟能用Figma智能体在多大程度上落实政策和流程，就必须把“已经宣布的发展方向”和“当下真正可部署的能力”区分开来。

代码图层扩大了智能体的操作范围

Figma不仅在收紧指令边界，也在扩大智能体可以执行的任务范围。根据TechCrunch的说法，代码图层最早于6月以私人测试版形式公布，而现在根据两个来源的信息，这项功能都已开始以公开测试版形式推出。Figma将其描述为一种在画布上创建交互式、由代码驱动原型的方法，用户可以通过转换设计框架、导入GitHub代码仓库、借助Figma Chrome扩展捕获网站，或者从零开始输入提示词来完成。

TechCrunch还补充了一个与治理相关的细节：用户可以要求智能体把设计转换为代码，或者修改部分代码，以迭代一个原型。换言之，智能体正在更靠近真正的构建界面，而不再只是一个头脑风暴助手。Figma的发布说明也强化了这一方向，称现在可以从外部AI工具中使用Figma MCP来创建代码图层、编辑Specs，或者在画布上生成图像。

这种组合带来两层含义。第一，当智能体影响的不再只是静态设计产物，而是由代码支撑的交互原型时，上下文控制的重要性会进一步提高。第二，互操作性本身也会成为一个治理问题。Figma表示，MCP现在具备更快的性能、对更多Figma产品的支持，以及对20家新合作伙伴的支持。TechCrunch点名提到了Open Code、Dia、Grok Bot和Sarvam等新增工具。而在当前提供的Figma发布说明摘录中，并未列出这些名称，因此这些合作伙伴细节来自TechCrunch。

Payload集成，以及从原型走向应用

此次公告的另一部分则超出了设计治理本身，延伸到应用交付。Figma表示，Make现在可以原生搭建Payload后端框架，提供CMS、数据库、媒体、API、身份验证和管理面板，并由Figma负责托管，使内容和数据与塑造它们的设计处于同一位置。根据发布说明，这项能力将面向所有套餐逐步推出。

TechCrunch也给出了类似表述，称Figma正在把Payload与Figma Make集成，以生成动态网站并直接管理内容。报道还提到，Figma在去年收购了开源无头CMS Payload。虽然这一集成并不是主要作为智能体治理功能来表述的，但它强化了这些公告背后更广泛的产品逻辑：设计上下文、代码上下文和内容上下文正在被拉入同一个环境，而智能体可以在这个环境中采取行动。

哪些已经确认，哪些仍是方向性信息

综合多个来源，核心信息是一致的：Figma希望团队通过给予智能体明确的上下文和规则，来定义它们应当如何行动。不过，仍有两点需要谨慎看待。第一，若干能力尚未完全开放。公开测试版、封闭测试版和仅预览，在实际操作层面并不是同一回事。第二，一些实现细节只出现在单一来源中。例如，TechCrunch称Specs基于Markdown，并表示它可以引用嵌入式Figma元素，而Figma自己的发布说明更强调产品层面的总体用途，而不是这些完全相同的具体机制。

两个来源在强调重点上也有所不同。TechCrunch着重指出AI具有非确定性，因此Figma正在努力把结果引导向更可预测的方向。Figma的发布说明则更强调工作流和产品覆盖范围，描述了如何用代码构建和协作、如何捕获并分享上下文，以及如何利用真实数据和内容进行构建。这两种说法彼此兼容，但并不完全相同。

对企业而言，更实际的变化在于，Figma正在提供更具体的操作杠杆，让团队决定智能体应当看到什么、应当遵循哪些规则，以及被允许在何处采取行动。就目前来看，这可能意味着用Specs记录设计意图，把指导原则附加到已发布的组件库上，并在公开测试版中测试由代码支撑的工作流，同时也要认识到，一部分控制能力仍处于封闭测试版或预览阶段。简而言之，组织已经可以开始不再把智能体行为仅仅视为临时性的提示词操作，而是把它视为设计系统治理的一部分；不过在推进这一目标时，仍需要逐项对照各功能当前的实际发布状态。