演讲者背景与核心愿景：浏览器即无限画布
Rachel Lee Neighbors 是一位拥有深厚 Web 标准背景的技术专家，曾参与 Firefox DevTools、W3C Web Animations API 以及 Microsoft Edge 的开发，目前担任 Rise 的首席开发者体验工程师。她拥有独特的跨界经历，早年曾为青少年创作网络漫画，拥有 40 万周读者，这让她深刻理解内容创作者与 Web 技术的结合。她指出，浏览器不仅仅是文档阅读器，更是“无限画布”（Infinite Canvas），能够渲染视频、音频等任何内容，且拥有对应的 API 支持。
“I believed that the browser is not just a document reader... It is an infinite canvas that can render anything, not just documents, but video, audio, whatever you need, there's an API for it.”
在 AI 代理（Agent）日益普及的今天，她致力于探索如何利用现有的 Web 原语，将 Agent 转变为无限画布，或者让网站更好地服务于 Agent。她通过个人项目展示了这一理念，例如开发了一个名为 ASA（Anti-Social Agent）的 MCP 应用，允许用户在不访问 Twitter 或 BlueSky 官方界面的情况下，直接在 MCP 环境中使用这些平台，从而避开算法干扰。她的核心论点是：通过利用浏览器已有的规范，我们可以重新定义 Agent 与 Web 的交互方式。
案例研究：为旧漫画网站构建面向 Agent 的未来架构
为了验证这一理念，Rachel 选择修复并重构她 2010 年建立的旧漫画存档网站。该网站目前面临 CDN 故障和 404 错误，但她决定不 merely 进行修补，而是将其打造为“面向未来的-proof”架构。她面临的核心挑战是构建一个统一的服务器端，同时支持三种不同类型的客户端：
- 人类用户：通过传统浏览器访问。
- 人类用户：通过 AI Agent 进行导航和交互。
- Agent 用户：代表人类在浏览器中执行操作。
“I wanted to make my comics available and navigable, one server, but three different kinds of clients, humans in browsers, humans in agents, and agents in browsers using the web on behalf of their humans.”
这种“多角恋”（polycule）式的技术架构要求系统具备极高的灵活性。她特别提到，由于涉及版权图像，她选择使用自己的艺术作品，并计划在后续章节中分享如何保护内容免受训练数据抓取的方法。这一案例旨在展示如何将传统的 Web 内容转化为 Agent 可理解、可导航的结构，从而让 Agent 成为内容消费的新入口。
MCP 协议基础：传输层（Transports）与 STDIO 机制
在深入 Web MCP 之前，演讲者首先梳理了 MCP（Model Context Protocol）的基础设施，重点解释了传输层（Transports）的概念。传输层决定了 MCP 服务器如何与 Agent 进行通信。她指出，虽然 HTTP 是 Web 开发者熟悉的协议，但 MCP 支持多种传输方式，其中STDIO（标准输入输出）是最常见的一种。
“Transports are how MCP servers communicate with agents. And there's a important difference between when you should use either of these.”
STDIO 机制中，服务器作为本地进程运行，由客户端（Agent）生成（spawn）。这种模式类似于传统的命令行工具交互，虽然简单高效，但局限于本地环境。演讲者幽默地将 STDIO 戏称为“Studio”，并指出这种本地进程模式与 Web 的分布式、远程特性存在本质差异。她通过现场互动询问观众是否已在 Web 上托管 MCP 服务器，发现多数人仍停留在本地 STDIO 阶段。这引出了本次演讲的核心技术议题：如何将 MCP 从本地 STDIO 迁移到 Web 环境，即 Web MCP 的实现与优势。她强调，理解传输层的差异是构建跨平台 Agent 应用的关键第一步。
MCP连接架构：Studio本地服务与HTTP云端服务的对比
在构建基于MCP（Model Context Protocol）的应用时，开发者主要面临两种部署架构的选择：Studio本地服务与HTTP云端服务。Studio模式通常通过命令行启动，通信依赖于标准输入输出（stdin/stdout），服务器在整个会话期间保持存活。这种模式要求用户更新配置文件以启动本地服务器，配置过程相对繁琐，且涉及复杂的命令行输入，大多数普通用户并不希望接触这些底层配置。相比之下，HTTP模式将服务器作为Web服务运行，监听特定的HTTP端点，通信通过HTTP POST请求完成。这种架构天然适配Serverless环境（如Vercel或Cloudflare的边缘函数），使得MCP工具可以嵌入到现有的Web基础设施中。
"With studio, you have to update a config file with a command to spin up a local server, but with HTTP, your user's experience is as simple as going over to your own settings."
在用户体验层面，HTTP模式具有显著优势。用户只需在设置界面输入一个名称和URL，即可将MCP工具添加为连接器，无需处理本地环境配置。尽管作者提到Anthropic的Claude客户端在集成HTTP MCP工具时仍存在操作隐蔽的问题，但相比Studio模式，其配置流程已大幅简化。需要注意的是，本文暂不深入探讨这两种模式下的安全性与隐私问题，重点在于连接机制与用户交互流程的差异。
MCP工具的数据返回格式与资源的缺失痛点
MCP工具的核心价值在于其能够返回结构化的数据，从而让Agent能够理解并处理信息。在作者的演示案例中，MCP工具返回的数据格式主要分为两类：JSON结构化数据和Markdown文本。例如，"列出漫画"、"列出故事线"、"列出角色"以及"搜索漫画"等工具均返回JSON格式，这使得Agent能够轻松解析数据并进行后续的逻辑处理。然而，"获取转录文本"（get transcripts）工具则返回Markdown格式，这为后续在Agent界面中直接渲染富媒体内容提供了可能。
尽管工具功能强大，但作者指出当前MCP规范中存在一个关键缺失：Resources（资源）的支持。作者希望利用MCP Resources将大量漫画转录文本一次性加载到Agent的上下文中，以便进行主题和角色弧线的元分析，而不是通过调用533次"获取转录"工具来低效地填充上下文。然而，目前的MCP规范定义松散，实现也不完善，大多数客户端UI无法直接访问服务器端的Resources。
"Agents really don't like using MCP tools to go add markdown to their context... I would rather die in a fire than go call your documentation by MCP tools."
作者强调，如果MCP规范能更好地支持Resources，Agent Harness（代理框架）就可以决定何时预加载文档上下文。例如，当用户切换到React开发模式时，系统可以自动从React的MCP服务器获取所有相关资源，从而大幅提升开发效率。目前，由于缺乏有效的客户端支持，这一理想场景无法实现。
从CLI到富媒体：MCP Apps的革命性体验升级
作者进一步探讨了MCP的另一种高级功能：MCP Apps，即通过捆绑HTML、CSS和JavaScript生成的内联交互式应用。这一功能旨在解决当前"聊天框"（Chatbox）或"海星设计"（Starfish Design）用户体验的局限性。作者认为，当前的聊天界面类似于早期的命令行界面（CLI），要求用户具备大量的上下文知识才能有效操作，缺乏视觉引导和直观性。
"It's been said that chat is the lowest common denominator of the user experience. That it is to the future of agentic experiences what the CLI was to software."
为了证明富媒体体验的优势，作者演示了一个名为"get page"的MCP工具。当用户请求阅读漫画《Crow Princess》时，Claude不再仅仅返回大段的文本描述，而是通过MCP Apps直接在Agent界面中嵌入一个交互式漫画阅读器。这种体验允许用户通过图片和交互界面阅读内容，而不是面对"文字墙"（wall of texting）。作者将这种基于HTML/CSS/JS的打包方式比作过去的DHTML技术，但强调其在现代Agent体验中的巨大潜力。通过这种方式，Agent可以从被动的文本生成者转变为主动的富媒体体验提供者，极大地降低了用户的认知负荷，提升了交互的自然度和效率。
MCP 应用作为微型网站的实现机制
演讲者展示了一个基于 MCP（Model Context Protocol）构建的漫画阅读器应用，该应用能够完整呈现网站功能，包括页面导航、评论展示以及文本模式切换。通过点击“文本模式”，用户可以直接阅读转录文本，这证明了 MCP 应用可以作为一个功能完备的微型网站运行。其核心实现方式是通过定义工具 get page，并传入漫画 ID、故事线 ID 和页码等参数，精准定位资源。最关键的技术细节在于传递一个 meta 属性，指向一个统一资源定位符（URL），从而将外部资源嵌入应用中。
“It looks just as good as the website. You can navigate forward and backward... it's like a little mini website.”
这种架构使得应用能够复用网站的所有资源，同时保持独立的交互逻辑。演讲者指出，虽然目前只需要故事线 ID 和页码，但为了精确性，仍保留了完整的输入参数结构。这种设计允许 AI 代理直接访问和渲染复杂的网页内容，而不仅仅是获取纯文本数据，为后续在浏览器中直接调用 JavaScript 函数奠定了基础。
MCP 应用的沙箱限制与设计系统依赖
MCP 应用并非传统网站，而是运行在 iframe 中的单文件 HTML 孤岛。这意味着所有资源必须通过 Base64 嵌入，无法动态从外部服务器拉取内容，除非在内容安全策略（CSP）中明确配置。由于处于沙箱环境中，应用无法使用本地存储，状态无法在 iframe 间共享，且没有直接的网络访问权限。代理必须通过调用服务器工具来执行网络请求，这被演讲者形容为一种“母亲，我可以吗？”（mother may I）的严格权限控制情境。
“They're an island. They're single HTML files. So, everything that you need there has to be embedded base64.”
鉴于这些限制，使用现有的设计系统（如共享字体、CSS 和组件）变得至关重要。演讲者推荐使用 Vite 的 single file 模式将 HTML 和 JavaScript 组件捆绑，以简化部署。如果开发者没有现成的设计系统，将面临巨大的工程挑战。此外，链接跳转需要主机权限，不能直接使用 window.open，必须通过特定的 API 请求代理执行，进一步强调了 MCP 应用在权限和资源加载上的严格约束。
Web MCP 规范与浏览器代理的演进
尽管 MCP 应用功能强大，但传统浏览器代理在导航网站时仍面临效率低下问题。它们通常依赖截图视觉模型或解析 DOM 树，这两种方式都极其消耗计算资源并浪费 Token。视觉模型需要处理图像，而 DOM 遍历则涉及大量 XML 解析，导致响应缓慢。为了解决这一问题，Web MCP 应运而生，它旨在让每个 HTML 页面成为一个微型 MCP 工具服务器，使代理能够直接调用页面上的 JavaScript 函数和链接。
“Wouldn't it be great if they just had a way to call the same functions and links you already have in your JavaScript directly from the page that they're visiting?”
演讲者强调，Web MCP 与标准 MCP 的关系类似于 JavaScript 与 Java，它灵感来源于 MCP 但并非完全合规。它主要提供浏览器内的代理工具接口，规范仍在演变中。目前存在两种模式：声明式（通过表单属性暴露工具，适合表单密集的网站）和命令式（通过 navigator.modelContext.registerTools 注册工具，适合 API 调用和数据转换）。这种直接调用机制避免了中间层的解析开销，显著提升了代理在浏览器内的操作效率。
工具注册与代理交互的实际演示
在实际操作中，开发者可以通过检查 navigator.modelContext 是否存在来启用 Web MCP 功能。注册工具的过程与标准 MCP 类似，需要定义工具名称、描述和输入 Schema，但核心区别在于需要提供一个执行回调函数。例如，演讲者注册了一个“下一页”工具，其回调函数从页面中提取下一个链接并执行导航，从而允许代理在不进行视觉点击的情况下完成页面跳转。
为了调试和演示，演讲者使用了 MCP Browser 扩展，该扩展模拟了未来浏览器内置代理（如 Gemini）的交互界面。在演示中，代理首先被要求“朗读内容”，成功返回了文本转录；随后，代理接收到“翻到下一页”的指令，并成功执行了导航操作。这一过程展示了异步工具调用的可行性，以及代理如何通过结构化指令直接操控网页状态，而非依赖低效的视觉识别或 DOM 搜索。
“I could do that forward and backward navigation with a tool call... set visibility app there just to make sure that the model's not going to try to use that and return text.”
值得注意的是，演讲者提醒开发者在注册导航类工具时，应设置 visibility 属性为 app，以防止代理误将这些内部工具当作文本输出返回给用户。这种精细的控制确保了代理行为的准确性和用户体验的流畅性，标志着浏览器代理从“被动浏览”向“主动交互”的重要转变。
智能体与浏览器的深度融合：Web MCP 的实践启示
演讲者通过展示一个模型自动调用函数的演示，揭示了智能体（Agent）与浏览器交互的核心机制。当点击“Go”按钮时，模型能够自主触发页面跳转，这种原生功能调用带来了显著的震撼效果。为了深入理解这一技术路径，演讲者推荐了与 Web MCP 创始人的访谈。Web MCP 最初是在亚马逊内部开发的工具，旨在解决复杂的身份验证（Auth）问题，随后逐渐演变为连接智能体与网络服务的关键桥梁。
"The browser's going to die."（浏览器即将消亡。）
这一观点曾在两年前的演讲中引发争议，但演讲者澄清，浏览器并未消亡，而是在进化。CSS 和 JavaScript 不再仅仅是构建网页的语言，它们正在成为智能体交互体验的基础语言。这种转变意味着开发者可以利用现有的 Web 标准，为智能体构建更加丰富和互动的界面。
多模态交互能力的原生支持：从文本到语音
在展示智能体如何生成内容时，演讲者演示了基于 Web Speech API 的文本转语音功能。尽管内置的语音合成效果被形容为“糟糕”，但它提供了一个零依赖、无需推理的解决方案。这意味着开发者无需引入外部模型或复杂的后端服务，即可在浏览器中实现基础的语音反馈。
"It's a browser's built-in text-to-speech capability. Zero-dependency solution. No inference required for that."
这种原生能力的重要性在于其即时可用性。除了语音，Web 平台还内置了动画、音频、Canvas 绘图、WASM（WebAssembly）以及 CSS 等多种 API。这些技术共同构成了一个无限画布（Infinite Canvas），允许开发者在智能体环境中创建高度复杂的交互体验。演讲者强调，这些 API 已经就绪，只待开发者利用它们来塑造未来的智能体界面。
从“浏览器死亡论”到“交互体验进化论”
回顾两年前的观点，演讲者承认当时使用了“浏览器即将消亡”这样的标题党（Clickbait）表述，但核心意图被误解。实际上，Web 技术栈正在经历深刻的范式转移。CSS 和 JavaScript 的角色已经从单纯的页面样式和脚本，扩展为智能体交互的通用语言。
"CSS and JavaScript aren't just the language of the web. They're the language of interactive experiences on agents."
这一论断确立了 Web 技术在智能体时代的地位。通过整合 Web Speech、Animation、Audio、Canvas 和 WASM 等现有技术，开发者可以构建出比传统网页更加动态和智能的界面。演讲者最后表达了对这一无限画布潜力的期待，认为这些原生 API 将为智能体交互带来前所未有的创新空间。