由OpenClaw的大火，如何短平快的改造现有Web应用面向Claw友好

执行摘要

本规划旨在为现有 Web 应用引入 AI Agent 自主操作能力，核心目标是通过短平快的改造，让应用对 OpenClaw 等AI Agent 更加友好。我们将摒弃过去需要数月甚至一年的重构计划，聚焦于一条基于 CLI 工具进行代码级解析与自动化 插桩的高效路径，在 2-4 周内快速落地 WebMCP/A2UI 标准，让 AI 能精准、高效地理解和操作我们的前端应用。

当前，AI Agent 与 Web 的交互严重依赖脆弱且高成本的屏幕截图或 DOM 猜测，这在复杂的 Web 应用中尤其低效。本方案将彻底扭转这一局面，我们不追求构建复杂的长期用户画像或记忆系统，而是将重点放在 “让现有系统以最低成本被 AI 快速理解与调用” 上。通过自动化工具将前端应用从“UI孤岛”转变为 AI 可消费的“逻辑中枢”，本轮改造的主目标是：基于 CLI 改造后，Claw 直接成功调用的“整体用户动线用例”覆盖率 ≥ 90% 。在此基础上，我们仍将跟踪 Token 消耗、端到端成功率与时延等作为诊断性指标（非考核 KPI） ，用于持续优化体验，但不作为考核口径。

我们将通过以下核心策略实现这一目标：

• CLI 自动化 插桩：开发一个基于 AST（抽象语法树）的 CLI 工具，自动扫描现有 React/Vue 代码库，识别交互意图，并注入 WebMCP 与 A2UI 所需的代码补丁。
• 声明式与命令式 API 并行：对简单的表单页面，采用声明式 API 进行低成本批量改造；对复杂业务流程，则通过命令式 API 暴露精细的、原子化的、带版本控制的工具。
• 安全与治理前置：在设计之初就融入安全与治理考量，通过 A2UI 的 Catalog 白名单、WebMCP 的用户在场确认机制和全面的可观测性建设，确保 AI 的所有行为都安全、可控、可追溯。

这份方案不仅是一份技术路线图，更是一套可立即执行的行动指南。它将指导我们用最小的代价，抓住 OpenClaw 带来的机遇，使我们的 Web 应用在 AI 时代保持领先。

核心矛盾与原则：在自主、安全与效率中寻求动态平衡

要实现 AI Agent 在浏览器中的高效自主操作，我们必须在三个核心且相互制约的维度之间找到最佳平衡点。这构成了我们整个改造规划的指导思想。

自主度 (Autonomy)

• 目标：最大化 Agent 自主完成端到端任务的能力，减少人工干预。
• 挑战：高度自主性可能引发不可预期的行为，对现有系统造成风险。

安全与合规 ( Security & Compliance)

• 目标：确保 Agent 的所有操作都在严格的权限框架内，符合数据安全与隐私合规要求。
• 挑战：过度的安全限制会扼杀 Agent 的自主性，使其退化为简单的自动化脚本。关键在于用户在场、最小权限和人机协同的平衡。

UI 契约与开发效率 (UI Contract & DX)

• 目标：将不确定的视觉 UI 转化为机器可读的结构化“工具契约”，同时提升开发者体验。
• 挑战：一方面，我们需要将前端组件从“静态视觉资产”重构为包含状态、行为和数据契约的“可执行实体”（Code = Spec）。另一方面，要警惕过度设计，避免为 AI 改造带来沉重的开发负担。

第一性原理复合度量

为了量化我们在这三个维度上的综合进展，我们提出一个“第一性原理复合度量”公式，用于指导我们的架构决策和内部评估。该复合度量仅作为内评的辅助分数，不作为考核 KPI，主 KPI 以“整体用户动线用例覆盖率 ≥ 90%”为准。

系统价值 (System Value) = (自主率 × 可靠性 × 研发速度) / 治理摩擦系数

• 自主率 (Autonomy Rate) ：Agent 能够独立完成任务的步骤数 / 任务总步骤数。
• 可靠性 (Reliability) ：1 - (任务失败次数 / 任务总执行次数)。
• 研发速度 (DX Velocity) ：新功能或工具从开发到上线并被 Agent 调用的平均周期。
• 治理摩擦系数 (Governance Friction) ：实施安全、合规、版本控制等治理措施所引入的额外开发与运维成本。

我们的目标是在不断提升分子（自主率、可靠性、研发速度）的同时，通过更智能、自动化的工程手段，持续降低分母（治理摩擦），从而实现系统总价值的最大化。

方案总览与架构愿景

我们提出的改造方案遵循一条清晰的自动化管线：从静态代码分析入手，到生成可执行的插桩补丁，最终在运行时为 AI Agent 提供标准的工具和界面描述。这套方案的核心是最大化地复用现有代码和前端资产，通过自动化手段降低接入 AI 的门槛。

核心管线说明：

1. 代码库 → CLI ****AST 解析：一切的起点。我们的 CLI 工具将深入分析现有的 React/Vue 代码库。
2. AST 解析 → 意图图/候选工具：通过对代码的静态分析（AST），CLI 将自动识别出页面中的核心交互意图（如表单提交、路由跳转、数据请求），并生成意图图（Intention Map） 和候选工具清单（Tools Draft） 。
3. 候选工具 → 插桩 补丁 (codemod) ：基于分析结果和开发者的审阅，CLI 将生成符合 codemod 规范的代码补丁。
4. 补丁 → WebMCP/A2UI：将补丁应用于代码库，即可自动为应用注入 WebMCP 的声明式或命令式 API，并生成 A2UI 所需的组件目录（Catalog）。
5. 运行时 → 可观测性：所有被 AI 调用的工具和渲染的 UI，其行为都将被统一的可观测性（ Observability ） 层捕获，用于度量、治理和调试。

与外部生态协同：

• OpenClaw /Agent Gateway：作为 AI Agent 的入口，它将直接消费我们通过 WebMCP 暴露的工具和 A2UI 的组件白名单，实现对前端应用的精准调用。
• DevTools MCP：为开发者提供强大的调试能力。我们可以利用它来录制、回放和分析 AI 的操作序列，排查性能瓶颈和调用失败问题。

技术可行性分析（详细版）

1. 浏览器与协议可行性

• WebMCP 当前状态：Chrome 146 及以上版本在开启相关实验标志后，已经提供 navigator.modelContext API，可支持 WebMCP 声明式与命令式工具注册。Edge 基于 Chromium，可按同一方案演进；其他浏览器暂不具备原生支持。
• 渐进增强策略：所有 WebMCP 插桩均包裹在 if ('modelContext' in navigator) 判断中：支持 WebMCP 时走 WebMCP 声明式/命令式 API，否则回退到 Chrome DevTools MCP / Chrome MCP Server 等 MCP 服务器路径，由 OpenClaw/Agent Gateway 统一调度，保证功能“可用优先”，体验逐步升级。
• 用户在场与权限边界：默认只在用户已打开页面、会话活跃时接受 Agent 调用；对删除、支付、审批等敏感操作强制弹出确认对话框，由用户显式确认。工具仅暴露必要参数，遵循最小权限原则，并通过权限域配置限制可被 WebMCP 调用的后端接口集合。

2. 框架与代码结构可行性（React/Vue）

• AST 解析覆盖：CLI 基于 TypeScript/JavaScript AST，可覆盖 TS/JS、TSX/JSX 以及 Vue SFC 文件，识别表单元素、按钮事件处理器、路由配置、数据请求与常见状态管理模式（useState、useReducer、Vuex/Pinia 等），满足现有技术栈的主流场景。
• codemod 注入点稳定：插桩以 <form> 标签、交互入口组件（Button、Link 等）以及模块初始化函数为主要注入点，对复杂流程通过单独的“工具注册模块”集中注入 navigator.modelContext.registerTool()，避免散落逻辑影响可维护性。
• 构建体系兼容性：改造不依赖特定构建工具，仅注入标准 ES 模块与运行时代码。对于 Vite/Webpack/Rspack 等构建链路，可通过独立 entry 或按需 import() 工具注册模块的方式，控制首屏体积与加载顺序。

3. 插桩策略可行性

• 声明式 API（表单） ：现有表单大多已具备语义化 name、required 属性，CLI 可以可靠地推导 JSON Schema，并在 <form> 上自动补齐 mcp-tool 与 data-tool-input-schema，对业务方来说只需在少数复杂字段上做手工覆盖即可。
• 命令式 API（复杂交互） ：对于多步骤流程、长事务和高价值操作，通过命令式工具暴露“动词_对象”式的业务能力，并在工具对象上增加 version 字段和约束清晰的入参/出参 Schema，配合 A2UI 的 userAction 命名规范，可以在不破坏现有交互的前提下，为 Agent 提供稳定的“能力层”接口。
• A2UI Catalog 与运行时一致性：CLI 生成的 catalog.json 白名单直接来源于组件库与业务代码，运行时只允许 Agent 使用其中列出的组件类型和受控属性，保证 UI 渲染与业务代码的一致性和可控性。

4. 安全与合规可行性

• 最小权限与分级工具：按照“读多写少”的原则，将工具分为只读查询类与写入/变更类，对后者在 Agent Gateway 层增加白名单与审批流程，只对经过评审的工具开放给特定 Agent。
• 频控与配额：在工具执行层和 Agent Gateway 层同时实现限流与配额控制，对高成本工具（批量导出、重计算等）设置更严格的阈值，并结合熔断策略防止雪崩。
• 审计与追责链路：所有 WebMCP 工具调用都记录调用方、参数摘要、结果与耗时，并与现有日志体系打通，满足安全审计与合规检查需要。

5. 性能可行性

• 运行时开销可控：声明式属性只在渲染时多出少量 DOM 属性，不引入额外监听；命令式工具注册集中在初始化阶段，可按需懒加载，避免拉长首屏渲染时间。
• 对比传统方案的优势：相对于多模态截图加 DOM 抓取方案，WebMCP/A2UI 工具调用直接抵达业务逻辑，显著减少多轮对话与 Token 消耗，预期可将复杂任务的总 Token 使用量降低一个数量级，这些提升统一视为诊断性指标（非考核 KPI） ，用于评估性能收益。
• 观测与调优手段：结合 DevTools MCP 的 trace、network 与 console 能力，可以对单次工具调用的耗时、重试与失败进行端到端跟踪，支持后续的性能回归与容量规划。

6. 运维与落地可行性

• CI 集成：CLI 工具支持在 CI 中以 dry-run 模式运行，自动检测未插桩的新交互点，并生成 MR/PR 提示开发者补齐工具与 Schema；同时可对 catalog.json、tools.draft.json 做格式与约束校验。
• 灰度与回退机制：通过特性开关控制 WebMCP 工具注册与 A2UI 渲染范围，支持按路由、按业务线逐步放量；任何异常可以通过关闭开关快速回退到原有纯人机交互路径。
• 与 OpenClaw /Agent Gateway 协同：工具元信息（名称、版本、Schema、权限标签）可以同步给 Agent Gateway，用于路由、调度与安全策略配置，形成端到端的一致视图。

7. 多模态识别增强可行性

• 可访问性增强：在插桩过程中顺带检查 aria-label、role 等属性缺失情况，形成改进建议清单，既提升无障碍能力，又为多模态模型提供更稳定的语义锚点。
• 结构化语义标注：对关键实体（数据集、任务、用户、报告等）补充 schema.org 微数据和 data-intent-* 标签，使多模态模型在无法使用 WebMCP 时仍能依赖 DOM 结构进行较高质量的推理。
• 意图图作为 MCP 资源：将 CLI 生成的页面动线意图图通过独立 MCP 资源暴露给 Agent，使其在决策前可以全局理解“页面任务图”，进一步减少盲目探索与截图需求。

8. 跨浏览器与兼容性

• Chrome 优先策略：短期内以 Chrome 146+ 为主战场，确保在核心人群与内部环境中跑通完整链路（WebMCP + A2UI + DevTools MCP）。
• 其他浏览器的兼容路径：在 Edge 上复用 Chrome 策略；在 Safari/Firefox 等暂不支持 WebMCP 的浏览器中，通过 Chrome MCP Server、Playwright MCP 或 Browser MCP 等方案，继续提供“浏览器自动化 + MCP 工具”能力，保证功能可用与行为一致。
• 标准演进跟踪：持续跟踪 W3C 与主流浏览器对 WebMCP 的标准化进展，每个版本评估是否可以放宽特性开关，逐步将更多用户迁移到 WebMCP 原生路径。

9. 风险提示与边界

• 关键风险聚焦：WebMCP 与 A2UI 的引入会放大权限配置错误、Schema 漂移、模型幻觉与跨浏览器差异等风险，需要在设计阶段即明确边界：哪些操作永远不开放给 Agent，哪些必须用户在场，哪些可以全自动执行。
• 与风险-应对矩阵联动：本节仅给出技术可行性视角下的风险提示，具体缓解措施与监控指标在下文《风险-应对矩阵》中统一收敛，确保技术方案与治理措施一一对应。

插桩细则：让代码对 AI “说人话”

为确保 AI Agent 能够准确理解并操作页面，我们需要定义清晰的声明式与命令式 API 插桩规范。CLI 工具的核心职责就是自动化实现这些规范。

声明式 API (Declarative API) - 适用于简单表单页

对于结构清晰、功能单一的表单页面，我们优先采用声明式 API 进行低成本、批量化的改造。

• 实现方式：CLI 工具需识别出 HTML 中的 <form> 元素，并为其自动添加 mcp-tool 及 data-tool-* 系列属性。
• 参数映射：表单中的 name 属性将被自动映射为工具的参数。CLI 工具将根据表单元素的类型（input, select）及其属性（type, required）生成对应的 JSON Schema，并注入到 data-tool-input-schema 属性中。

CLI 自动生成的声明式 API 示例如下：

<form
  id="create-report-form"
  mcp-tool="create_data_report"
  mcp-description="创建一个新的数据分析报告"
  data-tool-input-schema='{
    "type": "object",
    "properties": {
      "report_name": { "type": "string", "description": "报告名称" },
      "data_source_id": { "type": "string", "description": "数据源 ID" },
      "start_date": { "type": "string", "format": "date", "description": "报告开始日期" }
    },
    "required": ["report_name", "data_source_id"]
  }'
>
  <input name="report_name" type="text" required />
  <select name="data_source_id" required>
    <!-- options -->
  </select>
  <input name="start_date" type="date" />
  <button type="submit">创建报告</button>
</form>

命令式 API (Imperative API) - 适用于复杂交互场景

对于涉及多步骤、复杂状态管理或动态交互的页面，必须使用命令式 API 暴露更精细、更可靠的原子工具。

• 工具注册规范：通过 navigator.modelContext.registerTool() 进行注册。每个工具都是一个封装了具体业务逻辑的函数。
• 命名规则：工具名称需遵循 动词_宾语 (verb_object) 的格式，例如 create_report, query_user_list, update_dashboard_filter。
• 参数 Schema 模板：CLI 在生成桩代码时，应提供结构化的 inputSchema 模板，强制开发者明确定义每个参数的类型、描述和是否必需。
• Handler 返回结构：工具的 handler 函数必须返回一个结构化的对象，至少包含 success (boolean) 字段和用于传递结果或错误信息的 data / error 字段。
• 版本化与废弃策略：工具注册时需包含 version 字段（如 v1.0）。当发生破坏性变更时，应发布新版本的工具（如 create_report_v2），并为旧版本设置废弃窗口期，同时在可观测性后台记录旧版本的调用情况，以推动调用方迁移。

CLI 自动生成的命令式 API 桩代码示例如下：

// CLI 在识别到数据请求或复杂交互逻辑后，自动在对应组件中生成此代码框架
if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: 'query_user_list_v1',
    description: '根据筛选条件查询用户列表，支持分页。',
    // 版本化管理
    version: '1.0', 
    inputSchema: {
      type: 'object',
      properties: {
        page: { type: 'number', description: '页码', default: 1 },
        pageSize: { type: 'number', description: '每页数量', default: 20 },
        filter: { type: 'string', description: '筛选关键词' },
      },
      required: [],
    },
    // handler 必须返回结构化结果
    handler: async (args) => {
      try {
        // **开发者需在此处填充真实的业务逻辑**
        const data = await fetchUsers(args); 
        return { success: true, data };
      } catch (e) {
        return { success: false, error: e.message };
      }
    },
  });
}

A2UI：从代码到安全的动态界面

A2UI 协议让 Agent 可以安全地“描述”界面，而不是直接生成不安全的 HTML/JS。

• 邻接表 模型：A2UI 的核心是扁平化的组件列表，而非嵌套树。组件之间通过 ID 引用。这便于 Agent 增量生成和局部更新界面。
• Catalog 白名单生成：为保证安全，CLI 工具的核心任务之一是扫描项目中的组件库（如 antd , arco-design ），自动生成一份 catalog.json 白名单。这份白名单定义了 Agent 唯一允许使用的组件及其可用属性。
• userAction 命名：当用户与 A2UI 生成的界面交互时（如点击按钮），客户端会触发 userAction 事件。该事件的 name 必须与组件库中定义的 action 命名保持一致，并携带必要的上下文数据。
• beginRendering 事务化缓冲：为避免界面“一块块”地加载导致闪烁或错误，客户端渲染器在收到 beginRendering 信号前，必须缓冲所有 surfaceUpdate 和 dataModelUpdate 消息，确保所有依赖就绪后再进行首次渲染。

CLI 工具规范：自动化改造的引擎

这套“短平快”方案的基石是一个强大的 CLI 工具。

• 技术栈：必须使用 Node.js / TypeScript 实现，以便于处理 AST 和与前端工程生态集成。

• AST 解析规则：

  • React /Vue 框架支持：CLI 必须能够解析 JSX (React) 和 SFC (Vue) 文件。
  • 表单识别：通过 AST 遍历，识别 <form> 标签及其包含的 name 属性的输入元素，用于生成声明式 API。
  • 按钮与事件识别：识别 onClick 等 事件处理器，并向上追溯其调用链路，将其作为生成命令式 API 的候选目标。
  • 路由 识别：解析路由配置文件（如 react-router） ，构建页面“动线”的初步意图图。
  • 数据请求识别：定位 fetch , axios 或其他请求库的调用点，作为生成数据查询类工具的关键输入。
  • 状态机 识别：(进阶) 尝试识别 useState, useReducer 或 Vuex/Pinia 的状态定义，以理解组件的内部状态。

• 输出产物：CLI 执行后，必须生成以下四个核心文件：

  • intent-map.json：页面动线意图图，可视化展示页面间的跳转关系和核心交互点。
  • tools.draft.json：基于分析生成的 WebMCP 候选工具清单（含推荐的名称、参数等）。
  • catalog.json：扫描组件库产出的 A2UI 组件白名单。
  • codemod.patch：可直接应用的插桩代码补丁文件。

• 核心功能：

  • Dry-run 模式：必须提供 dry-run 模式，允许开发者在不实际修改文件的情况下，预览将要生成的补丁内容。
  • 交互式审阅：在 dry-run 后，CLI 应提供交互式界面，让开发者可以逐条确认、修改或拒绝每一处代码变更。
  • 回滚 策略：所有代码修改必须通过版本控制（如 Git ）进行。CLI 在应用补丁前自动创建 commit，便于一键回滚。
  • CI 集成：CLI 工具应能轻松集成到 CI/CD 流程中，定期扫描代码库，发现未被 插桩 的新增交互，并创建 MR / PR 提醒开发者。

多模态识别提升：作为兜底与辅助

虽然我们的核心是 CLI 插桩，但仍可通过优化页面的语义化来辅助多模态模型，作为兜底方案，并减少 Token 消耗。

• 可访问性语义：强制要求为所有可交互元素（按钮、链接、输入框）添加明确的 aria-label 和 role 属性。这不仅是无障碍最佳实践，也为多模态模型提供了比 class name 更稳定的识别锚点。
• 微数据 (Microdata) ：在页面中嵌入 schema.org 等微数据，用结构化的方式描述实体（如商品、文章、事件），让模型能直接“读懂”内容，而非猜测。
• data-intent-* 标签 ：除了 WebMCP 标准，我们可以补充使用自定义的 data-intent-* 标签**，为关键交互元素提供更丰富的业务意图描述，如 data-intent="submit-and-redirect-to-dashboard"。
• 动线意图图暴露：CLI 生成的页面“动线”意图图 (intent-map.json) 本身可以作为一个 MCP 资源被暴露，让 Agent 在开始操作前就能获取整个站点的宏观交互拓扑，从而做出更优的规划，减少无效的截图和 DOM 解析。

可观测性与治理：确保 AI 安全可控

让 AI 操作应用，必须建立配套的监控与治理体系，确保一切行为可追溯、可控制。

术语与口径

• 主KPI： 基于 CLI 改造后，Claw 直接成功调用的“整体用户动线用例”覆盖率 ≥ 90% 。
• “Claw 直接成功调用”定义：指基于 WebMCP/A2UI 工具路径，由 OpenClaw（Claw）触发并在“用户在场”必要确认下完成的端到端成功，无需回退到基于截图/DOM 抓取的视觉模拟路径。若发生回退或需人工手动完成主要步骤，不计入“直接成功”。
• “整体用户动线用例”定义：依据现有 Web 应用的线上埋点/路径分析或产品定义的“用户旅程”清单，去重后构成统计全集。统计周期默认按自然月汇总（如需按自然周可在仪表盘中另设附注）。
• 计算公式： 覆盖率 = 成功由 Claw 直接驱动完成的动线用例数 / 总动线用例数 × 100%。
• 其它指标说明： Token 消耗、端到端时延、失败重试率等统一作为诊断性指标（非考核 KPI） ，用于内部优化与调参，不作为考核口径。

数据来源与仪表盘

• 埋点与路径分析：前端和 Agent Gateway 需要对“整体用户动线用例”的起止、关键步骤和完成情况埋点，按自然月汇总输出每个用例的完成次数。
• 工具调用遥测：结合 WebMCP 工具调用日志与 A2UI userAction 事件，判定一次用例是否为“Claw 直接成功调用”，并与用户在场确认记录关联。
• 示例统计表结构：

直接成功次数	总用例数	覆盖率%
85	90	94.4

• 统一事件命名：无论是用户点击还是 AI 调用，所有触发工具执行的事件必须遵循统一的命名规范，并记录事件来源（user 或 agent）。
• 工具调用遥测：对所有 WebMCP 工具的调用进行全量遥测，上报包括：工具名称、版本、输入参数、执行耗时、返回结果（成功/失败）及调用方信息。
• 频控 与配额：在 Agent Gateway 或前端应用层面，必须实现针对工具调用的频率控制和配额管理，防止恶意或失控的 Agent 行为拖垮后端服务。
• 敏感操作“用户在场”确认：对于所有涉及资金、权限修改、数据删除等敏感操作，必须在前端强制弹出确认框，要求用户手动确认。这是不可逾越的安全红线。
• 日志与审计：所有 AI 的操作日志都应集中存储，形成可审计的记录，用于问题排查和安全分析。
• Schema 版本演进：当工具的 Schema 发生破坏性变更时，必须提供至少一个大版本的废弃窗口期。期间，旧版本工具应继续可用，但返回的 header 中需包含废弃警告，并在可观测性后台对旧版本调用设置告警。

风险与治理

风险-应对矩阵

在推进过程中，我们预见以下潜在风险，并制定了相应的缓解措施与监控指标。

风险类别	具体风险描述	缓解措施	监控指标
安全风险	权限泄露：Agent 被赋予过高权限，或被利用执行越权操作。	- 最小权限原则：默认不暴露任何写操作工具。工具 handler 内的逻辑必须复用前端自身已有的、经过鉴权的请求方法。

• 用户在场确认：对所有敏感操作强制要求用户物理确认。
• 定期安全审计。 | - 高危 API 调用次数。
• 用户确认弹窗的拒绝率。 | | | 工具滥用：恶意或失控的 Agent 高频调用工具，导致服务瘫痪或成本激增。 | - 在 Agent Gateway 或前端实现频率控制和资源配额。
• 对工具调用的成本进行实时监控和告警。
• 建立 熔断机制，当某个工具的失败率或耗时异常时，暂时禁用该工具。 | - 单个 Agent 的 API 调用 QPS。
• Token 消耗速率。 | | 技术风险 | 版本漂移：WebMCP 工具的 Schema 变更导致线上 Agent 大量失败。 | - 建立严格的 Schema 版本管理机制，破坏性变更必须升级主版本号。
• 提供废弃窗口期和自动化的迁移通知。 | - 因 Schema 不匹配导致的调用失败率。
• 旧版本 API 的调用量。 | | | 模型幻觉：Agent 尝试调用不存在的工具或传入不合规的参数。 | - 前端进行严格的输入 Schema 校验。
• Catalog 白名单机制确保只使用已定义的组件。
• 提供清晰的工具描述，减少模型的猜测空间。 | - Schema 校验失败次数。
• 调用未注册工具的错误日志。 | | 兼容性风险 | 跨浏览器兼容性：WebMCP 标准尚未被所有浏览器完全支持。 | - 渐进增强：将 WebMCP 插桩代码包裹在 if ('modelContext' in navigator) 的判断中，确保在不支持的浏览器中，应用原有功能不受影响。
• 试点阶段聚焦于 Chrome。 | - 各浏览器用户占比。
• 在非 Chrome 浏览器上的 Agent 任务失败率。 | | 合规风险 | 隐私合规：Agent 操作过程中可能接触和传输用户敏感数据。 | - 在前端对所有传给 Agent 的数据进行自动化脱敏。
• 遵循 GDPR、CCPA 等法规要求，确保数据处理流程合规。 | - 数据传输日志中敏感字段的屏蔽率。
• 定期合规审计报告。