MCP协议如何让AI Agent自动遵循设计系统

文章正文

当设计系统、上下文工程和AI Agent三者结合，软件开发的方式正在被重新定义。通过MCP（Model Context Protocol，模型上下文协议），AI不再是"凭记忆干活"，而是能够实时查阅设计规范，构建出完全合规的界面。这篇文章将拆解这一技术链条的每个环节，以及它为何正在改变软件构建的方式。

设计系统：软件开发的"乐高说明书"

设计系统本质上是一套完整的规则和可复用组件库，它规定了一个产品在视觉和交互层面应该长什么样。具体来说，它包括：

• 字体规范：标题、正文、注释等不同层级的排版规则
• 颜色系统：主色、辅助色、状态色等完整的色彩体系
• UI组件：按钮、表单、卡片、导航栏等可复用的界面模块
• 间距与布局规则：元素之间的间距、栅格系统、响应式断点等

用一个直观的比喻来理解：设计系统就像一套乐高积木的说明书。说明书本身就是设计系统的规则，乐高积木块对应各种组件，而按照说明书搭建出来的成品就是最终的应用或网站。

设计系统的概念并非凭空出现，它经历了从早期的品牌风格指南（Style Guide）到组件库（Component Library），再到完整设计系统的演进过程。这一演进本质上折射出整个软件行业从手工作坊到工业化生产的转型：早期的Style Guide仅是一份PDF或网页文档，规定Logo使用规范和品牌色值；组件库阶段引入了可复用的UI代码片段，但设计与开发之间仍存在"翻译损耗"——设计师的视觉稿需要开发者手动解读并转化为代码，过程中不可避免地产生偏差；现代设计系统则通过Design Token、Figma Variables等机制，真正实现了设计意图的机器可读化，为AI协作奠定了基础。

2014年Google发布Material Design、2016年Salesforce推出Lightning Design System，标志着设计系统进入工业化时代。如今，几乎所有大型科技公司都维护着自己的设计系统——Apple的Human Interface Guidelines、IBM的Carbon、Shopify的Polaris等。设计系统的核心工具链也从最初的静态文档演变为Figma中的设计Token、Storybook中的组件文档、以及通过Design Token实现的设计-开发自动同步流程。

设计Token：设计系统的原子化基石

在理解设计系统如何与AI协作之前，有必要深入了解设计Token（Design Token）这一关键概念。设计Token是设计系统中最原子化的设计决策单元，它将颜色、字号、间距等设计属性抽象为与平台无关的键值对。例如，color-primary: #0066FF 就是一个设计Token。Token的价值在于它建立了设计意图与技术实现之间的桥梁——设计师在Figma中修改一个Token的值，通过Style Dictionary等工具链可以自动同步到Web的CSS变量、iOS的Swift常量和Android的XML资源文件中。

Token体系通常分为三个层级：全局Token（Global Token）定义原始值，如 blue-500: #0066FF；语义Token（Semantic Token）赋予业务含义，如 color-action-primary: {blue-500}；组件Token（Component Token）绑定具体组件，如 button-background-default: {color-action-primary}。这种分层架构使得品牌换色只需修改顶层Token，所有组件自动联动更新。这种机制使得设计系统真正实现了"单一事实来源"（Single Source of Truth），也为MCP Server提供了天然的结构化数据源。正是因为设计Token具备机器可读的结构化特性，它才成为连接设计系统与AI Agent的最佳接口。

值得一提的是，W3C的Design Tokens Community Group（DTCG）正在推动设计Token格式的国际标准化。该规范旨在定义一套与工具无关的Token描述格式，使Figma、Sketch、Style Dictionary等不同工具链之间能够无损地交换Token数据。一旦DTCG规范成熟并被主流工具采纳，将为设计系统MCP化提供统一的数据格式基础，大幅降低集成成本——这也是当前设计系统生态中最值得持续关注的标准化进展之一。

设计系统的核心价值在于一致性。无论团队中谁来负责开发，用户都能获得统一、熟悉、易用的体验。然而问题在于——并不是每个开发者都熟悉设计系统的全部规则，这正是AI Agent介入的契机。

上下文工程与MCP：给AI提供"正确的说明书"

什么是上下文工程？

上下文工程（Context Engineering）是一种系统化的方法论，核心目标是：在AI开始执行任务之前，确保它拥有所需的全部背景信息。

这不是简单地写一段prompt就能解决的问题，而是一种结构化的信息提供方式。你需要告诉AI：当前的业务场景是什么、有哪些约束条件、应该遵循哪些规范——这些都属于"上下文"的范畴。

上下文工程与Prompt Engineering的区别值得特别说明：两者并非同一事物的升级迭代，而是不同维度的工程学科。Prompt Engineering关注单次交互的措辞优化——如何提问、如何给出示例、如何约束输出格式；而Context Engineering关注的是整个信息供给体系的架构设计——包括哪些信息应该预加载进系统提示词、哪些应该通过RAG按需检索、哪些应该通过MCP工具实时获取，以及如何在有限的上下文窗口内合理分配"信息预算"。一个精心设计的Context Engineering体系，可以让一个普通的LLM表现出远超其参数规模的专业能力。

上下文工程的兴起与大语言模型的固有局限密切相关。LLM的上下文窗口（Context Window）虽然在不断扩大——从GPT-3的4K token到Claude的200K token——但仅靠扩大窗口并不能解决信息质量问题。Andrej Karpathy等业界人士已将上下文工程视为AI应用开发中最关键的工程能力之一，认为它是决定AI系统实际表现的核心变量。

RAG：上下文工程的核心技术支柱

在上下文工程的技术栈中，检索增强生成（Retrieval-Augmented Generation，RAG）是最成熟且应用最广泛的技术手段之一。其基本原理是：在LLM生成回答之前，先从外部知识库中检索与用户查询最相关的文档片段，将这些片段注入到模型的上下文窗口中，再让模型基于这些真实信息生成回答。RAG通常依赖向量数据库（如Pinecone、Weaviate、Chroma）来存储文档的语义嵌入，通过余弦相似度等算法实现语义检索。

RAG的核心价值在于解决LLM的两大痛点：知识截止日期（Training Cutoff）和幻觉问题（Hallucination）。由于LLM的参数知识在训练完成后即固化，对于持续更新的设计系统规范，RAG可以确保AI始终引用最新版本的文档，而非依赖可能已过时的训练记忆。MCP可以被视为RAG理念的协议化和标准化——它不仅支持文档检索，还支持工具调用和结构化数据访问，是更通用的上下文注入框架。理解RAG有助于把握MCP的设计哲学：让AI在需要信息时能够主动获取，而非被动依赖预训练知识。

MCP协议：标准化的信息桥梁

MCP（Model Context Protocol，模型上下文协议）是上下文工程的关键基础设施。它是一种行业标准化的协议，专门用于将外部信息以AI能轻松消化的格式传递给大语言模型。

MCP由Anthropic于2024年底开源发布，其架构采用客户端-服务器模式。MCP Server负责将外部数据源（数据库、API、文件系统、设计工具等）封装为标准化接口，MCP Client（通常嵌入在AI应用中）通过JSON-RPC 2.0协议与Server通信。

值得一提的是，MCP选择JSON-RPC 2.0作为底层通信协议有其深层考量。JSON-RPC 2.0是一种轻量级的远程过程调用协议，使用JSON作为数据格式，其核心设计极其简洁：客户端发送一个包含方法名和参数的JSON对象，服务端返回执行结果或错误信息。MCP选择JSON-RPC 2.0而非REST或GraphQL，主要因为其无状态、双向通信友好的特性，特别适合AI Agent与外部工具之间频繁的、结构化的交互场景。每次调用都是独立的请求-响应对，这与Agent"观察-思考-行动"的循环模式天然契合。相比之下，REST API虽然更为普及，但其面向资源的设计范式在描述"调用工具执行操作"这类语义时显得不够自然；GraphQL虽然灵活，但引入了额外的查询语言学习成本。JSON-RPC 2.0的极简设计反而成为了AI工具调用场景的最优解。

MCP发布后迅速获得行业认可，微软、Google、OpenAI等主要AI平台相继宣布支持或推出兼容方案。与此同时，Google推出了类似定位的Agent2Agent（A2A）协议，专注于多Agent之间的通信标准化。两者的并存使得"AI协议标准化"成为2025年的重要行业议题，类似于早年HTTP与其他网络协议的竞争格局。对于开发者而言，选择MCP还是其他协议，很大程度上取决于所使用的AI平台生态——但MCP凭借先发优势和开源社区的活跃度，目前已积累了数千个社区贡献的Server实现，覆盖从数据库到设计工具的广泛场景。

MCP定义了三种核心原语：Resources（资源，类似于GET请求，提供数据读取）、Tools（工具，类似于POST请求，执行特定操作）、Prompts（提示模板，预定义的交互模式）。这种设计使得任何外部系统只需实现一个MCP Server，就能被所有支持MCP的AI Agent无缝访问，避免了为每个AI平台单独开发集成接口的重复工作。

MCP的作用可以从三个层面来理解：

1. 格式标准化：将设计规范、API文档、组件库信息等转换为AI可解析的结构化数据
2. 实时可访问：AI Agent可以在执行过程中随时通过MCP查询最新的设计规则，而不是依赖训练时的"记忆"
3. 工具集成：MCP不仅提供信息，还可以暴露工具接口，让AI Agent调用特定能力来完成实际操作

AI Agent：能决策、会用工具的智能执行者

代理型AI（AI Agent）区别于普通AI助手的核心特征在于：它能根据掌握的信息自主做决策、选择执行路径，并在过程中调用工具来完成实际任务。

AI Agent的核心架构通常包含感知（Perception）、规划（Planning）、行动（Action）和记忆（Memory）四个模块。与传统的单轮问答不同，Agent通过ReAct（Reasoning + Acting）、Chain-of-Thought等推理框架实现多步骤任务分解。

ReAct：Agent的推理引擎

ReAct是2022年由Google Research和Princeton大学联合提出的Agent推理框架，也是当前最主流的Agent运行模式之一。它的核心创新在于将思维链推理（Chain-of-Thought）与外部工具调用交织在一起，形成"思考→行动→观察"的交替序列。在传统的思维链中，模型只在内部推理；而ReAct允许模型在推理过程中暂停，调用外部工具获取真实信息，再基于返回结果继续推理。

一个典型的ReAct执行轨迹看起来像这样：Thought（我需要知道按钮组件的悬停状态颜色）→ Action（调用MCP工具：query_design_token("button-hover-background")）→ Observation（返回值：#0052CC）→ Thought（现在我可以生成正确的CSS了）→ Action（生成代码）。这种模式极大地减少了LLM的"幻觉"问题，因为每一步决策都可以基于真实数据而非模型的参数记忆。在设计系统场景中，Agent可以在生成每个组件时暂停，通过MCP查询该组件的最新规范，再继续生成代码——这正是ReAct模式与MCP协议结合的典型应用。

值得注意的是，ReAct并非Agent推理的唯一范式。近年来涌现的Plan-and-Execute框架将规划与执行阶段分离，先由规划器生成完整的任务分解方案，再由执行器逐步落实；而Reflexion框架则在ReAct基础上增加了自我反思机制，Agent在完成任务后会评估自身表现并将经验写入长期记忆，用于改进后续任务的执行策略。在设计系统场景中，Reflexion式的自我反思尤为有价值——Agent可以在生成代码后主动对照MCP中的规范进行合规性自检，发现偏差后自动修正，而无需等待人工Review介入。

在实际运行中，Agent会进入一个"观察-思考-行动"的循环：先观察当前状态和可用信息，然后推理下一步应该做什么，最后调用工具执行操作并观察结果。主流的Agent框架包括LangChain/LangGraph、AutoGen、CrewAI等，它们都提供了工具调用、状态管理和多Agent协作的基础能力。

在设计系统的场景中，AI Agent的工作流程大致如下：

1. 用户用自然语言描述需求（例如"我需要一个带搜索功能的产品列表页"）
2. Agent通过MCP连接到设计系统，获取相关的颜色规范、组件定义、布局规则
3. Agent根据这些规则自主选择合适的组件和布局方案
4. 生成符合设计系统规范的原型或代码
5. Agent回头核对MCP中的规则，确认输出完全合规

有无MCP的关键区别

这里有一个重要的区分：

• 不使用MCP：AI Agent只能依靠训练数据中模糊的"记忆"来搭建界面，就像凭印象中的说明书拼乐高，很可能拼错或遗漏细节
• 使用MCP：AI Agent拥有实际的、最新的设计系统规范，可以精确地核对每一个细节，确保输出完全正确

这种差异在企业级应用中尤为关键。大型设计系统往往包含数百个组件和上千条规则，任何AI都不可能通过预训练"记住"所有细节，更何况设计系统还在持续迭代更新。

更前沿的架构方向是多Agent协作：单一Agent处理完整的设计-开发流程存在上下文长度和专业深度的双重瓶颈，而多Agent体系可以将任务分解给专业化的子Agent——一个专注设计规范解析、一个负责代码生成、一个专门做可访问性审查，通过Orchestrator Agent统一协调。这种架构与现代软件团队的分工模式高度对应，也是CrewAI、AutoGen等框架重点支持的场景。设计系统MCP化后，每个专业Agent都能通过统一接口获取所需的规范子集，避免信息过载，同时保持各自的专业深度。

这一组合为何正在改变软件开发

设计系统 + 上下文工程 + AI Agent的组合，带来的不仅是效率提升，更是开发范式的根本转变：

降低专业门槛：即使开发者不熟悉设计系统的每一条规则，AI Agent也能通过MCP确保合规性。这意味着更多人可以参与到高质量的产品构建中。

加速原型迭代：从需求描述到可用原型的周期可能从数天缩短到数分钟，因为AI Agent能够同时理解业务需求和设计约束。

保持设计一致性：在大型团队中，设计一致性历来是最大的挑战之一。当AI Agent成为"设计系统的执行者"，人为偏差将被大幅消除。

设计系统的活文档化：通过MCP，设计系统不再是一份静态的文档或Figma文件，而是成为AI Agent可以实时查询和调用的"活知识库"。

落地挑战与当前生态

尽管前景广阔，但将设计系统MCP化在实践中仍面临若干挑战。首先是设计Token的语义化程度——许多团队的设计系统仍以视觉稿或PDF文档形式存在，缺乏机器可读的结构化描述。其次是版本管理问题，设计系统的迭代需要与MCP Server同步更新，否则AI Agent可能引用过时的规范。

此外，AI生成代码的质量审查机制也需要建立——即使有MCP提供规范，Agent的输出仍需人工Review，特别是在可访问性（Accessibility）和国际化（i18n）等维度。可访问性（简称a11y）要求软件产品能被所有用户使用，包括视觉、听觉、运动或认知障碍人群，这涉及WCAG（Web Content Accessibility Guidelines）标准的遵循，例如颜色对比度至少达到4.5:1、所有交互元素可通过键盘操作、图片需提供替代文本等。国际化（简称i18n）则要求产品能适配不同语言和文化，包括文本方向（如阿拉伯语的从右到左）、日期格式、货币符号等。这两个维度之所以对AI生成代码构成特殊挑战，是因为它们涉及大量隐性规则和边界情况，很难仅通过设计Token来完整表达，需要额外的语义化规范描述和专门的验证工具。

目前，Figma的Dev Mode API、Style Dictionary等工具正在为设计系统的结构化输出铺路，但完整的MCP生态仍在早期建设阶段。值得关注的是，W3C的Design Tokens Community Group正在推动设计Token格式的国际标准化（DTCG规范），一旦该标准成熟，将为设计系统MCP化提供统一的数据格式基础，大幅降低不同工具链之间的集成成本。

写在最后

这三者的结合——设计系统提供规则和组件、MCP提供标准化的信息桥梁、AI Agent提供自主决策和执行能力——正在定义下一代软件开发的基本形态。

对于技术团队而言，现在值得思考的问题是：如何将现有的设计系统MCP化？如何构建适配自身业务场景的上下文工程体系？这些问题的答案，很可能决定了团队在AI时代的开发效率和产品质量。

核心要点

• 设计系统是软件开发的规则基础，通过全局Token→语义Token→组件Token的三层架构实现跨平台一致性；W3C DTCG规范的推进将进一步标准化Token的跨工具交换格式
• 上下文工程不同于Prompt Engineering，是系统化管理AI信息供给体系的工程学科，RAG和MCP是其核心技术手段
• MCP协议基于JSON-RPC 2.0实现标准化的AI-外部系统通信，定义了Resources、Tools、Prompts三种核心原语，已形成数千个社区Server的活跃生态；其极简的无状态设计与Agent工具调用场景天然契合
• AI Agent通过ReAct"思考→行动→观察"循环实现多步骤任务分解，Reflexion等进阶框架进一步引入自我反思机制；结合MCP可实时查询设计规范；多Agent协作架构进一步突破单Agent的能力瓶颈
• 三者结合正在降低开发门槛、加速迭代、保障一致性，但在设计Token语义化（DTCG标准化进行中）、版本管理、可访问性审查等方面仍有挑战待解