AI 前端工程：LLM、Agent、MCP 与生成式 UI

AI 前端工程：LLM、Agent、MCP 与生成式 UI

本文聚焦 AI 前端应用的架构、数据流和安全边界。

1. 先划清四个概念

LLM

大语言模型根据上下文预测下一段内容。它擅长自然语言理解、结构化输出和知识组合，但输出具有概率性，不能直接视为事实或可信指令。模型的上下文窗口、延迟、成本和数据处理策略都会影响产品设计。

Agent

Agent 是一个带有目标、状态和工具的执行循环，而不是“给模型套一个聊天界面”。典型流程是：

用户意图 -> 规划/选择工具 -> 校验参数 -> 执行工具 -> 观察结果
       -> 继续规划或生成回答/界面 -> 记录轨迹

需要限制最大步数和超时时间，并为每个工具定义失败、重试和取消语义。模型可以提出动作，但最终是否执行应由应用层决定。

MCP

Model Context Protocol（模型上下文协议）把模型可访问的外部能力抽象为标准化连接：Client 代表调用方，Server 暴露工具、资源或提示模板。它解决的是“如何描述和发现能力”的互操作问题，不会自动解决授权、数据脱敏或工具本身的安全问题。

生成式 UI / A2UI

生成式 UI 让模型返回描述界面的数据，前端根据受控组件目录渲染界面。A2UI 可理解为一种 Agent 到 UI 的声明式消息约定；具体字段和版本应以实际协议规范为准，不要把任意模型生成的 JSON 当成可信 UI。核心原则是“模型描述意图，前端掌握渲染权和交互权限”。

2. 推荐的数据流

浏览器
  |  用户消息/当前页面上下文
  v
应用服务 -> 会话与权限检查 -> Agent 编排器
                              |\
                              | \-- 模型适配层
                              | \-- MCP Client -> 受控工具/资源
                              v
                    结构化回答或 UI 消息
                              v
              Schema 校验 -> 组件白名单 -> 前端渲染

不要让浏览器直接持有模型密钥或任意 MCP 凭据。服务端应把用户身份、租户、工具权限和审计信息注入执行上下文；浏览器只接收最小化的结果或流式增量。

3. 结构化 UI 的最小约束

UI 消息应包含版本、组件类型、受控属性和动作标识，而不是 HTML、JavaScript 或可执行表达式：

{
  "version": "1",
  "type": "form",
  "props": {
    "title": "选择日期",
    "fields": [{ "name": "date", "kind": "date", "required": true }]
  },
  "actions": [{ "id": "submit", "label": "提交" }]
}

前端渲染器应采用注册表，而不是动态执行模型返回的代码：

type UiNode = {
  version: string
  type: string
  props?: Record<string, unknown>
  actions?: Array<{ id: string; label?: string }>
}

const components = {
  form: FormRenderer,
  table: TableRenderer,
} as const

function renderNode(node: UiNode) {
  const Renderer = components[node.type as keyof typeof components]
  if (!Renderer || node.version !== '1') return <UnsupportedNode />
  return <Renderer {...validateProps(node.type, node.props)} />
}

validateProps 应使用运行时 schema（例如 JSON Schema 或项目已有的校验库），拒绝未知字段、过大的数组、非法 URL 和不支持的动作。类型系统只能帮助编译期，不能替代模型输出的运行时校验。

4. 工具调用的安全边界

1. 能力最小化：每个工具只暴露完成业务所需的最小参数和权限；读工具与写工具分开声明。
2. 服务端授权：工具执行前重新检查用户、租户、资源归属和权限，不能信任模型传来的 userId 或 role。
3. 人工确认：发送消息、写入数据、付款、删除等不可逆操作应先生成待确认命令，再由用户明确确认。
4. 提示注入防护：外部网页、文件和工具返回内容都视为不可信数据，不能因为其中出现“忽略之前指令”就改变系统策略。
5. 资源限制：设置超时、最大 token、最大循环步数、响应大小和并发上限；重试只用于幂等操作，并采用退避。
6. 审计与脱敏：记录请求、工具名、耗时、结果状态和 traceId；日志中对 token、Cookie、身份证号等敏感字段脱敏。

5. 流式输出与失败处理

流式协议应区分 message-start、text-delta、ui-patch、tool-status 和 done/error 等事件。客户端要处理乱序、重复、断线重连和半截 JSON：

• 以 requestId + sequence 去重，并只接受当前会话的事件。
• 增量 UI 先拼装成完整消息，校验通过后再提交渲染，避免半个节点污染界面。
• 断线后使用幂等的游标或请求 ID 恢复，不能盲目重复执行写工具。
• 模型不可用时退回普通表单、静态问答或人工处理，并向用户说明当前状态。

6. 评估与可观测性

不要只用“看起来能回答”验收 Agent。至少记录以下维度：工具选择准确率、参数校验失败率、任务完成率、首 token 延迟、总耗时、重试次数、人工接管率和敏感操作拦截率。离线评测集应覆盖正常请求、歧义请求、越权请求、提示注入和工具故障；生产日志应能通过 traceId 串起模型、工具和 UI 渲染事件。

7. AI coding 与前端工程工作流

AI coding、vibe coding 和 spec coding 的共同点是让模型参与实现，区别在于是否先把目标、约束和验收标准写成可检查的规格。前端团队可以把一次任务拆成下面的闭环，而不是把生成的代码直接合入主分支：

需求/约束 -> 读取仓库上下文 -> 生成方案与影响面 -> 小步修改
       -> lint/类型检查/测试/构建 -> 人工 review -> 记录结果与回滚点

需要显式提供给模型的上下文包括：目录边界、现有组件和 API 约定、数据权限、浏览器兼容范围、性能预算以及不可修改的文件。让模型先输出计划和待确认问题，再生成小范围 patch，能减少“看似完成但破坏隐含约定”的改动。代码生成后仍要由人负责审查副作用、依赖变更、敏感数据流和错误处理。

AI 在前端工程中的落点不只是一段代码生成：

场景	前端需要建设的能力	关键风险
设计稿转码	组件目录、设计 token、可访问性约束、视觉回归	生成不可维护的重复 DOM
AI IDE	WebView 容器、文件/终端/浏览器状态桥接、权限提示	Agent 获得超出工作区的能力
自动化测试	测试用例生成、运行结果回传、失败重试和人工确认	把偶然通过当成真实覆盖
on-call 排障	日志检索、trace 聚合、只读诊断工具和回滚入口	将诊断建议误执行为变更

浏览器运行时信息（当前路由、网络请求、控制台错误、DOM 快照）应经过脱敏和最小权限的桥接层提供给 Agent，不能把整个用户环境或密钥直接暴露给模型。

7.1 先写可检查的规格，再让模型改代码

资料中的一个反复出现的教训是：一次性要求模型“重构目录、删除冗余、保持逻辑不变”很难验收，因为“冗余”和“更好”没有稳定的机器可检查定义。更稳妥的做法是把任务拆成文件级、行为级的变更，并先写清楚不做什么：

目标：给结算表单增加取消请求能力
允许修改：src/checkout/**、对应测试
不变约束：API 响应格式、权限校验、公共组件接口
验收：重复点击只发出一个请求；路由离开会 abort；取消不显示业务失败
验证命令：typecheck、相关单测、结算流程 E2E

交给模型的上下文至少应包含目标、目录边界、已有 API/组件约定、数据权限、兼容范围、性能预算、示例输入输出和验证命令。让模型先返回影响面、方案和待确认问题，再接受一个小 patch；每个 patch 都检查实际 diff、依赖锁文件和生成文件，必要时保留可回滚的提交点。对于不确定的第三方 API 或配置参数，应先查本项目锁定版本的类型定义和文档，再让模型给出候选实现，不能把模型的记忆当作接口事实。

7.2 AI 辅助测试：生成不是验收

AI 可以帮助枚举分支、补齐样例和生成测试骨架，但生成的导入路径、mock 形状、异步时序和断言 API 仍可能不准确。测试用例只有在目标版本的依赖环境中实际运行，并由开发者确认“断言了业务行为而不是偶然实现细节”后，才算进入测试集。建议把验收拆成四项：

1. 可执行：在干净环境中能安装、运行并稳定结束，不依赖开发机残留状态。
2. 断言有效：失败时能指出用户可感知的行为，不是只断言快照或函数被调用次数。
3. 边界完整：覆盖空值、重复操作、超时、取消、权限失败和资源不可用等分支。
4. 回归有价值：用故意引入的小缺陷或 mutation 检查测试是否真的能阻止回归。

团队可以把“接受率”作为内部过程指标（被人工确认并保留的用例数 / 生成用例总数），但它不能代表覆盖率、缺陷发现能力或上线质量。低接受率时，筛选、修正和补遗漏的成本可能高于手写；因此更重要的是记录被拒绝的原因，并改进规格、fixture 和提示上下文，而不是追逐一个脱离场景的百分比。

端到端测试的难点不只是调用浏览器。模型需要同时看到经过脱敏的产品意图、用户流程、测试数据、权限状态、网络 stub、可访问的定位器和每一步的预期断言；否则它只能根据 DOM 猜测“看起来对不对”。可以在隔离环境提供一个有界的浏览器适配器：只允许白名单动作，返回控制台日志、网络摘要、截图或 trace，并限制步骤数、单步超时和外部写操作。失败后把结构化错误和当前状态回传给模型重试，但最终仍由确定性的断言和人工判断决定是否通过。

需求/验收 -> 测试设计与数据夹具 -> AI 生成候选用例
       -> 隔离执行 -> 收集失败证据 -> 人工确认/修正
       -> 纳入 CI 及回归集

不要把“模型生成了很多用例”或“一次运行通过”当成质量证明。生产代码、真实账号和不可逆接口不应作为 AI 测试的执行目标；测试环境要使用最小权限、可重置数据和可观测的网络模拟。

7.3 AI Code Review：辅助发现，不替代合并门禁

AI Review 适合做三类辅助工作：概括 diff 和影响面、提示可能的边界/性能/安全问题、按照团队规则提出可读性和可维护性建议。它不应替代类型检查、lint、依赖扫描、静态安全规则、自动化测试或负责人的最终判断。尤其要警惕“建议听起来合理但没有对应代码证据”的评论。

大型变更可能超出模型上下文，导致遗漏文件关系；同一 diff 多次审查也可能得到不同结论。接入 CI 时可按模块或逻辑变更拆分输入，显式提供架构约束和关注等级，并要求每条评论带文件位置、证据、影响和复现方式。先以非阻断评论运行，只有经过一段时间的误报/漏报统计后，才考虑对有限的高置信规则设置阻断；不能让模型单独批准或自动合并涉及权限、数据迁移和资金的变更。

提交 diff -> 脱敏/拆分 -> 规则检查 + AI Review
      -> 证据化评论 -> 作者修复/解释 -> 人工 reviewer 决策
      -> 测试与发布门禁

代码、提示和工具输出可能包含业务机密。发送前要做仓库、文件、分支和密钥过滤；敏感项目优先使用组织批准的私有部署或受控网关，并设置保留期限、访问审计和退出机制。无论模型是否参与，最终合并人都要对行为变化、依赖供应链、隐私和回滚方案负责。

7.4 分开评估产物质量和流程收益

不要用一个“AI 通过率”混合评价代码、测试和 Review。每项指标都要固定任务集、仓库版本、模型/提示版本、分母和人工判定规则，才能做前后对照：

环节	产物质量	流程成本与风险
代码生成	验证命令通过率、人工确认后保留率、回归缺陷数	人工修改时长、从任务到合并的周期、回滚次数
测试生成	可执行率、mutation 检出率、关键分支覆盖、缺陷复现率	用例修正时长、flaky 率、CI 增量耗时
AI Review	抽样真阳性率、高严重度问题召回、建议采纳率	误报处理时长、审查延迟、漏到后续阶段的缺陷
安全治理	越权/敏感操作拦截率、秘密扫描命中后的阻断率	敏感数据暴露事件、人工接管率、审计缺口

“保留率”只说明候选产物经过人工筛选后有多少进入仓库，不等于正确率或业务质量。发现流程收益下降时，应先按失败类型归因：上下文缺失、规格含糊、模型能力不足、工具/API 版本不匹配、测试环境不稳定或门禁配置错误，再决定改提示、补工具、缩小任务，还是直接改回人工实现。

来源：第一篇 —— 25K高级前端开发的面试全流程.pdf 的“2025 年，前端如何与 AI 结合”（AI coding、测试与辅助 Code Review），以及 第六篇 —— 大厂真实面试原题解析.pdf 的“AI 浪潮下前端后续的发展”（Agent 应用与工具编排方向）。仅保留可在项目中验证的工作流、测试方法和治理边界；课程宣传、品牌链接、仓库数量、接受率/性能倍数等未验证数字未作为结论。

8. Embedding 与知识库检索

Embedding 是把文本、代码或其他内容映射成向量，使语义相近的内容在向量空间中更接近。它适合做召回，不等于事实校验；最终回答仍应带上来源片段并接受权限和业务规则检查。

一个可解释的 RAG（检索增强生成）链路是：

文档清洗 -> 分块(chunk)+元数据 -> embedding -> 向量库
                                      \
查询 -> query embedding -> 过滤/向量召回 -> 重排 -> 上下文组装 -> LLM

type KnowledgeChunk = {
  id: string
  text: string
  source: string
  tenantId: string
  version: string
  acl: string[]
}

async function retrieve(query: string, tenantId: string, userId: string) {
  const vector = await embed(query)
  const candidates = await vectorStore.search({
    vector,
    topK: 20,
    // 伪代码：具体向量库的过滤语法可能不同。
    filter: { tenantId, acl: { $contains: userId } },
  })
  return rerank(query, candidates).slice(0, 5)
}

落地时至少处理以下问题：

1. 分块与元数据：按标题、段落和代码边界分块，保存来源、版本、租户、权限和更新时间；不要把整本长文塞进一个向量。
2. 模型一致性：写入和查询必须使用兼容的 embedding 模型与维度；模型升级要有版本字段和重建策略。
3. 权限与隔离：向量召回前后都做租户和 ACL 过滤，不能因为语义相似就返回用户无权访问的片段。
4. 新鲜度与删除：文档更新、撤回和删除要同步到索引；必要时结合关键词检索、数据库条件过滤和重排。
5. 评估：分别测召回率、来源命中率、答案可追溯性、延迟和成本；对提示注入、恶意文档和隐私内容建立专门用例。

9. Agent 运行时：从循环脚本到可治理状态机

ReAct 适合“思考一步、调用一个工具、观察结果”的短任务；Plan-and-Execute 先生成计划再执行，适合步骤较多且需要展示进度的任务；Multi-Agent 可以按领域拆分角色，但通信和错误传播成本更高。选型应由任务的步骤数、可解释性和失败代价决定，而不是由模型名称决定。

建议把运行时状态显式建模：

received -> planning -> waiting_tool -> tool_running
                    \-> awaiting_approval
tool_running -> observing -> planning | completed | failed | cancelled

每个任务至少携带 runId、tenantId、actorId、截止时间、最大步数和取消信号。工具调用应使用结构化参数 schema，并在执行前后分别记录：

• 前置：权限、资源归属、幂等键、速率限制和人工确认状态。
• 执行：超时、并发上限、重试次数；只对明确幂等的读取操作自动重试，并使用指数退避。
• 结果：把工具输出当作不可信数据，限制大小和 MIME 类型，脱敏后再交给模型。
• 结束：写入成功/失败原因、耗时、token、费用和 traceId；支持取消与部分结果恢复。

模型输出“下一步做什么”，编排器决定“是否允许做、在哪里做、失败后怎么办”。这条边界能避免把 Agent loop 变成不可审计的递归调用。

10. MCP / A2A 服务治理清单

MCP 主要解决 Agent 与工具、资源、提示模板之间的发现和调用互操作；A2A（Agent-to-Agent）更偏向 Agent 之间的任务协作。两者都不应被当成默认的授权系统，具体传输和字段以采用的协议版本为准。

能力发现 -> 版本/能力协商 -> 身份认证 -> 租户与工具授权
       -> 参数校验 -> 调用/流式事件 -> 审计、指标与撤销

上线 MCP Server 或 A2A 服务前，可以按下面的清单逐项确认：

领域	必须明确的规则
身份与权限	mTLS/OAuth 或平台统一身份；每次调用绑定 actor、tenant、scope；服务端重新鉴权，不信任模型传入的角色
能力与版本	工具名、输入输出 schema、错误码、超时、取消、幂等语义；能力协商和版本兼容策略；废弃工具有迁移窗口
数据安全	资源 ACL、字段脱敏、日志分级；禁止把密钥、Cookie 和完整用户数据作为默认上下文
网络边界	SSRF 防护、出站域名白名单、文件系统/命令沙箱、响应大小和 MIME 限制；工具返回内容按不可信输入处理
可靠性	配额、并发上限、队列、熔断、指数退避；写操作使用幂等键，必要时提供补偿或人工审批
可观测性	traceId/runId 贯穿 Agent、MCP Client、Server 和下游；记录延迟、状态、重试、成本和人工接管
变更治理	工具和 Agent 的发布审批、契约测试、灰度、回滚、依赖供应链扫描；异常能力可即时撤销

对于跨 Agent 的任务，除工具级权限外，还要定义任务所有者、消息来源验证、状态转移和结果验收；不要因为“另一个 Agent 推荐了这个动作”就跳过当前租户的授权和人工确认。

来源：25年前端年度复盘.pdf 第 2-5 页、25年下半年面试真题预测.pdf 第 2.12 和 2.18 节。资料中的品牌、专有实现和未验证效果数字未作为项目结论。