WebMCP 实战：无需重建后端，快速验证企业 AI POC

当 CEO 突然问你："我们能不能基于现有系统快速搭一个 AI POC，看看它到底有没有价值？"——这是很多企业 AI 架构师真实面对的场景。要么花大量时间和成本去对接复杂的 API，要么用 Mock 数据把 Demo 拼出来，但这两条路都有问题。YouTube 频道「Murali the AI guy」在一期视频中，用一个虚构银行贷款审批的案例，演示了 WebMCP 这种新思路如何在不重建后端的前提下，让 AI Agent 直接驱动既有企业应用。

企业 AI POC 的真正痛点：集成，而非智能

我们天天在谈 AI Agent、自主系统、量子计算，但现实是大型企业里仍然跑着大量 20、30 年历史的老系统。它们稳定、安全、合规，每天承载着关键业务流程。问题在于——技术上虽然可以把 MCP 引入这些环境，但「正确地做」往往意味着构建新 API、搭建集成层、准备基础设施，还要走完安全、架构、合规和审批流程。

这对一个只想验证想法的 POC 来说，代价过高。而业务方要的是"现在就要 AI"。视频作者点出了一个关键矛盾：很多 AI POC 之所以具有误导性，就是因为用 Mock 数据把 Demo 做得很漂亮，却恰恰回避了最难的那部分——它到底能不能在真实的企业环境里跑通？

一个贷款审批的真实工作流

视频用银行信贷专员的日常来说明问题。一笔个人贷款申请通过服务台进入信贷专员手中，在做决策前，专员需要跨多个企业系统收集和校验信息：先在服务台打开工单，看清客户是谁、申请了多少；再打开 CRM 工具，复制客户 ID、搜索客户、查看财务信息；接着进入信贷风险系统，输入客户 ID、申请金额和贷款期限，跑信用与偿付能力检查；然后把这些信息手动录入贷款发起系统，完成评估并保存；最后回到服务台更新结果、补充工作备注、关闭工单。

整个过程就是在不同系统之间来回搬运数据，每笔申请要花 15 到 20 分钟。一旦哪一步出错或信息有歧义，还得回头重做。需求其实很简单：自动化执行环节，但把最终决策权留给信贷专员。

为什么不直接上 MCP？

既然 MCP 就是为连接企业应用而生的，为什么不直接给这些遗留系统做 MCP 服务器？视频作者给出了一个很克制的回答：MCP 确实可能是最终架构的一部分，如果能直截了当地引入，就应该引入。

但在某些遗留系统上，引入 MCP 可能意味着一整套新 API、集成层、基础设施供应，以及安全、架构、合规审批流程——这会严重拖慢 POC 的节奏。他的立场很明确：不要让最终架构阻塞 POC，但也不要让 POC 脱离现实。用现有系统验证真实的端到端工作流，再根据 POC 的收获来定义合适的目标架构——这个建议最终可能包含 API、MCP 服务器、应用现代化，或它们的组合。换句话说，不是在回避 MCP，而是不把 MCP 的实现当成验证想法的前提条件。

WebMCP 与 MCP 的架构差异

要理解 WebMCP 的巧妙之处，先回顾 MCP 的运作方式：MCP 架构里有 MCP 客户端和 MCP 服务器，AI Agent 与 MCP 客户端对话，客户端把请求发给服务器，服务器与企业系统交互、执行动作，再把结果返回。整个链路通常运行在服务端。

WebMCP 的运作逻辑则完全不同——这里没有独立的客户端和服务器架构。它的切入点是：一个遗留 Web 应用，其后端集成可能并不好接，但前端往往已经做了收集、转换、校验后端数据的工作。与其为 AI Agent 重建一套集成，WebMCP 让我们把这些既有的前端能力和数据转换逻辑，以结构化工具的形式暴露出来，对现有应用只需极小的改动。

另一个重要区别在于执行位置：MCP 通常在服务端执行，WebMCP 则工作在客户端——在浏览器里、在那个特定的 Web 应用中。这既是优势也是限制：应用必须在用户浏览器中打开，相关工具才可用。WebMCP 本质上是绑定在 Web 应用之上的。

安全模型如何保证？

安全是企业场景绕不开的问题。WebMCP 不会绕过现有应用的安全机制：用户仍然登录同一个应用、使用同一个会话，原有的权限和授权控制继续生效。默认情况下，它遵循浏览器的同源安全模型（same-origin）。如果另一个 Web 应用需要消费这些工具，必须显式地把它们暴露给一个受信任的来源（trusted origin），这样随便一个网站就无法发现并调用这些 WebMCP 工具。

MCP（Model Context Protocol）是由 Anthropic 于 2024 年末提出并开源的协议标准，旨在为 AI 模型与外部工具、数据源之间提供统一的通信接口。其设计思路类似 USB 标准：无论后端是数据库、API 还是文件系统，只要实现了 MCP 服务器，AI Agent 就能通过同一套协议调用。标准 MCP 架构要求在服务端部署一个「MCP 服务器」进程，负责接收来自 AI 客户端的指令并与实际系统交互。这意味着必须有服务端的基础设施支撑，并且需要在企业网络内部开放相应的接口——对于遗留系统而言，这往往牵动数据安全审查、网络策略变更和开发资源投入。WebMCP 则将这套逻辑移入浏览器端，利用 Web 应用本身已有的 DOM 操作、表单提交和 JavaScript 逻辑作为「工具实现」，从而绕开了服务端集成的复杂度。

浏览器同源策略（Same-Origin Policy）是 Web 安全的基础机制：它规定，某个网页只能访问与自身协议、域名、端口完全相同的资源，不同来源之间的脚本默认无法互相读取数据或调用接口。WebMCP 默认遵循这一模型，意味着 WebMCP 工具天然被限定在对应 Web 应用的页面上下文中，第三方页面无法探测或调用这些工具。当需要跨来源消费工具时，必须像配置 CORS（跨域资源共享）策略一样显式声明受信任的来源列表——这为企业提供了可审计的权限边界，而非开放式的工具发现机制。这种设计在安全合规要求严格的金融、医疗等行业尤为重要，因为它不引入新的网络端点，也不改变现有身份验证流程，审计日志与访问控制仍由原有应用统一管理。

Demo：AI Agent 接管执行，人类保留决策

回到银行的例子：AI Agent 坐镇服务台应用，CRM、信贷风险、贷款发起三个遗留系统各自加上 WebMCP，并只暴露 Agent 需要的能力——获取客户详情、跑信用检查、更新贷款申请。

实际操作中，信贷专员打开案例、读完基本信息后，不再手动跳转系统，而是点击 AI Agent 按钮。界面列出该案例需要完成的任务，点「运行所有步骤」，Agent 便开始跨 CRM、信贷风险和贷款发起系统逐步执行，并记录每一步耗时。全部完成后，它把所有发现汇总到面板顶部：收集到的证据、执行的动作、各系统返回的结果，最后由 LLM 给出推荐意见。

但关键是——最终决策仍在信贷专员手里。专员审阅证据和建议后，决定批准或拒绝；如果有失败或需要关注的地方，Agent 会标红提示。确认无误后点击批准，案例自动关闭。原本需要人在三个系统间搬运、检查、录入的流程，现在由 Agent 执行，而人始终掌握最终决定权。这正是 POC 想验证的：减少手工执行的同时，保持 human-in-the-loop。

Human-in-the-loop（人在回路中）是 AI 系统设计中的一个重要原则，指在自动化流程的关键节点保留人工审核或决策的环节，而非让系统完全自主运行。在高风险业务场景（如贷款审批、医疗诊断、法律合规）中，这一原则尤为关键：AI 负责执行信息收集、数据校验、模式识别等高频、重复性工作，人类则专注于需要判断力、责任归属和道德考量的最终裁决。这种分工不仅降低了全自动化带来的合规与责任风险，也使 AI 系统更容易通过内部审批——因为它的定位是「决策辅助工具」而非「决策替代者」。对于 POC 阶段尤其适用：它既能展示 AI 对效率的真实提升，又避免了在价值尚未验证时就承担完全自主化的风险。

理性看待：WebMCP 仍是实验性方案

视频作者在结尾给出了难得的克制态度：他并不认为 WebMCP 是永久方案，也不认为它适合所有场景。这需要根据你的需求和约束逐案评估。作为 AI 架构师，职责是理解需求、验证约束、选对合适的构建模块。

他甚至直接提醒观众：不要一回到客户那里就说"我们上 WebMCP 吧"——它仍然是实验性的，有明确的限制（比如必须依赖浏览器中打开的 Web 应用、绑定前端能力等）。在使用前，先搞清楚它适合用在哪里。对于那些既想快速验证 AI 价值、又不想让集成工作拖垮 POC、还不愿用 Mock 数据自欺欺人的团队来说，WebMCP 提供了一个值得评估的中间路径。