Figma 說明代理治理護欄：以 Specs、元件庫與存取範圍引導行為

在 Config India 2026 上，Figma 更明確地提出一套框架，說明其自家代理與第三方代理可如何在平台內運作。根據該公司的發佈說明以及 TechCrunch 的報導，Figma 描述了一組旨在為代理提供更多脈絡、同時也施加更多限制的工具：一個名為 Specs、以 Markdown 為基礎的新編輯器，附加在設計元件庫上的指引，程式碼來源，集中式設計系統，以及透過 Figma MCP 擴大的支援。這些項目背後的共同主軸是治理。Figma 不只是增加 AI 功能，也正試圖界定團隊能如何透過規則、檔案與共享參照，來塑造代理的行為。

對護欄的強調，似乎也與 Figma 自身承認的一項限制有關。TechCrunch 指出，在過去一週將其畫布上的代理開放給更廣泛的使用者之後，Figma 也同步提供工具，讓使用者能把結果引導至更可預期的方向，因為 AI 具有非決定性。這樣的表述很重要。公司並不是把代理描繪成預設就完全可靠的系統，而是把脈絡與系統規則定位成降低變異、縮小輸出落差的方法。

意圖與脈絡的原生承載位置

這次的核心公告是 Figma Specs。依照 Figma 的發佈說明，Specs 被描述為一個承載脈絡的原生空間，能把書面的意圖、視覺探索與技術細節集中到同一處，供團隊與代理共同使用。TechCrunch 進一步補充，這是一個 Markdown 編輯器，讓使用者能以簡單方式定義自己的設計語言。根據該報導，Specs 可以作為 Figma 內的獨立檔案存在，也可以與畫布並列；使用者還能引用其他 Figma 元素，例如畫布元素、FigJam 圖表、code layers 與設計內容。

綜合這兩個來源來看，Specs 的設計目的不僅是替人類把專案文件化。它也意在成為 Figma 內 AI 系統可機器讀取的脈絡。Figma 的發佈說明並未像 TechCrunch 那樣，針對嵌入或引用其他 Figma 物件提供同等程度的技術細節，但兩者在更宏觀的角色定位上是一致的：代理應當能查閱與人類協作者相同的書面與視覺脈絡。

在可用性方面，這一項比其他部分公告更清楚。Figma 表示，Specs 現正以 open beta 形式，在付費方案中逐步推出。這個區分對組織內部討論治理時相當重要：這項功能並未被描述為全面正式可用，也不是所有方案都包含。

以元件庫、指引與程式碼作為代理約束

除了 Specs 之外，Figma 也正在把其他控制層正式化。其發佈說明指出，團隊可以把指引加入已發佈的設計元件庫，讓代理遵循既有模式，並避免反模式。這項功能目前也正以 open beta 推出。Figma 同時表示，來自 GitHub 儲存庫或 npm 套件的程式碼，能作為 code sources 匯入，以協助代理建構與編輯可反映真實設計系統的元件與 code layers。這項功能目前正以 closed beta 推出。

TechCrunch 描述的圖像相近，指出團隊可以帶入更多與設計相關的脈絡，包括設計元件庫、程式碼元件庫與指引，用來管理設計系統的上下文，而代理可參照這套集中化系統以遵守規則。至於 Figma 自身的發佈說明，則在產品打包方式上更具體。它將 centralized design systems 描述為把設計元件庫、程式碼元件庫與指引打包到單一設計系統中，讓作者更容易維護，也讓所有人更容易遵循。不過，Figma 對 centralized design systems 的標示僅為 preview。

• Specs：付費方案 open beta。
• 已發佈設計元件庫中的指引：open beta。
• 來自 GitHub 儲存庫或 npm 套件的 code sources：closed beta。
• Centralized design systems：僅限 preview。
• Figma MCP 與 20 個新夥伴的支援：現已可用。

這樣的拆分之所以重要，是因為整個治理敘事分散在成熟度不同的多項功能上。有些控制已可供付費客戶較廣泛地使用，有些仍僅限特定使用者，還有些仍停留在 preview。任何企業若要評估今天到底能用 Figma 代理實際落實多少政策與流程，就必須把已公布的方向，與當前真正可用的能力區分開來。

Code layers 擴大代理的操作範圍

Figma 並不只是收緊指令，同時也在擴張代理能做的事。根據 TechCrunch，code layers 最初於 6 月以 private beta 形式公布；而依照兩個來源的說法，現在都正以 open beta 推出。Figma 將其描述為一種能在畫布上建立具互動性、由程式碼驅動之原型的方法，做法包括：把設計 frame 轉換過來、匯入 GitHub 儲存庫、利用 Figma Chrome 擴充功能擷取網站，或直接從零開始以提示生成。

TechCrunch 還補充了另一個與治理相關的細節：使用者可以要求代理把設計轉成程式碼，或修改部分程式碼以迭代原型。換句話說，代理正逐漸靠近真正的建置表面，而不再只是腦力激盪助手。Figma 的發佈說明也強化了這個方向，指出如今可以從外部 AI 工具使用 Figma MCP，來建立 code layers、編輯 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 去年收購了開源 headless CMS Payload。雖然這項整合的主要框架並不是代理治理功能，但它強化了上述公告背後更大的產品邏輯：設計脈絡、程式碼脈絡與內容脈絡，正被拉進同一個環境中，而代理可以在其中採取行動。

哪些已獲確認，哪些仍屬方向性訊號

綜觀各來源，核心訊息是一致的：Figma 希望團隊透過提供明確的脈絡與規則，來定義代理應如何行動。不過，有兩點仍需要審慎看待。第一，若干能力尚未完全可用。open beta、closed beta 與僅限 preview，在實務運作上並不相同。第二，有些實作細節只出現在單一來源中。舉例來說，TechCrunch 把 Specs 描述為以 Markdown 為基礎，並表示它能引用嵌入的 Figma 元素；而 Figma 的發佈說明則更著重產品目的本身，而非這些精確機制。

各來源在強調重點上也有所不同。TechCrunch 突出的一點是：AI 具有非決定性，而 Figma 正試圖把結果引導向可預測。Figma 的發佈說明則更強調工作流程與產品覆蓋範圍，描述如何以程式碼建構與協作、如何擷取與分享脈絡，以及如何以真實資料與內容進行建置。這兩種說法彼此相容，但並不完全相同。

對英語系企業而言，實際上的變化在於，Figma 正提供團隊更具體的控制槓桿，來決定代理應該看到什麼、應遵守哪些規則，以及被允許在哪些位置採取行動。以目前來說，這可能意味著：在 Specs 中記錄意圖、把指引附加到已發佈的元件庫，並在 open beta 中測試由程式碼支撐的工作流程，同時也必須認知到部分控制仍停留在 closed beta 或 preview。簡言之，組織現在可以開始把代理行為視為設計系統中一個可治理的組成部分，而不再只是臨時性的提示工程；但若要落地，仍需把這項企圖與各功能當前的推出狀態逐一對照。