MCP 协议与浏览器 Agent：从 N 套适配到一次接入

Agent 要真的动手干活，最后都会落到浏览器上：登录、发帖、抓数据、填表。技术上难的不是能不能点，而是把浏览器交给 Agent 时的接入成本。

N 乘 M 的适配泥潭

假设市面上有 N 个工具、M 个模型。工具提供方要给每个模型写一套对接代码，模型侧也要为每个工具写一套适配层，两边各自维护，总量是 N 乘 M。

麻烦在于这是乘法。多一个工具，不是多一份工作，而是要在这个工具和每个模型之间各接一次；反过来，模型换一版，已经接好的工具也可能要重新验证。一个能力写得再好，只要没有针对某个模型的适配，就用不上——工具就这样卡在流通环节。

早期只能各写各的。同一件事，列出环境、启动浏览器、读取页面，换个调用方就得重写一遍，逻辑还常常不一致：有人把等待写在客户端，有人写在服务端。

协议把两边解开

MCP（Model Context Protocol，模型上下文协议）2024 年底公开，做法是把工具发现和调用定义成标准格式：暴露什么、参数怎么描述、返回什么结构，都写进协议。

结构随之变成 Agent 连一个 MCP Client，Client 按协议去连多个 MCP Server，Server 背后才是具体能力。实现量从 N 乘 M 降到 N 加 M：模型侧实现一次客户端，工具侧实现一次服务端。

角色只有三个。Host 是跑着模型的那个应用，负责把客户端起起来；Client 是协议客户端的实现，一般一个 Server 对应一个；Server 由工具提供方写，把能力包成标准工具暴露出去。

通信目前两种。本地模式走标准输入输出，客户端和服务端在同一台机器上，链路短、配置少，做自动化时用得最多。远程模式走 HTTP 或 WebSocket，适合分布式部署，代价是要额外想清楚鉴权和网络边界。

浏览器场景里，暴露出来的是三层东西

把浏览器环境接进协议，暴露的能力大致落在三层。

最上面是环境：列出账号下有哪些环境、按配置新建一个、启动指定环境、给它绑定网络出口、用完关掉。这些动作过去散在各家 API 里，现在是被模型发现和调用的几个工具。启动之后返回的通常是一个调试端点，端口或者 WebSocket 地址，拿到它就能交给 Selenium、Puppeteer 这类驱动。

中间是页面：打开地址、读取 DOM 或可访问性树、切换标签、截图。

最下面是动作：点击、输入、滚动、等待某个条件成立，以及处理弹窗。

变化的关键不在动作有多少，而在环境从一段必须自己写的代码，变成 Agent 可以自己挑着用的资源。你只需要说清目标，由它决定是先建一个环境还是复用现有的、按什么顺序调用。多环境并行时这一点尤其明显：调度写在提示里，而不是硬编码在脚本里。

现阶段还没解决的部分

协议解决连接，不解决正确性。几处容易被忽视的地方。

工具描述的质量决定调用结果。参数写错、工具选错，协议帮不上忙；工具一多，描述本身还会挤占上下文，数量和颗粒度之间要取舍。粒度太粗，模型不知道一个工具能干几件事；太细，上下文先被塞满。

权限与审计还在早期。相当一部分服务端是本地单机形态，起来就带着不小的权限，缺少细粒度授权和调用记录。远程模式则要先回答谁能连、能看到什么。

页面稳定性没有被消掉。元素定位不到、加载时序不稳、登录态过期、验证码，这些仍然要写等待、重试和兜底，协议只统一了入口。

生态成熟度也不均衡。不同服务端支持的资源类型、返回结构、错误码并不完全一致，跨几个服务端拼一个任务时，编排逻辑往往还得自己写。协议本身还在演进，版本之间的行为差异需要留意。

还有一条边界要分清：协议管的是模型怎么调用工具，不管任务本身是否合规。采集有没有获得授权、账号的使用目的是否正当、是否踩到平台规则，都是独立判断，和链路顺不顺没关系。

多环境场景下，环境之间隔不隔离、网络出口与时区语言是否成套，往往比接入方式更影响结果。PurpleMark 在环境隔离这一层提供了可被 AI 工具调用的环境创建、启动与网络配置接口，同一个客户端就能调度。

仅作技术原理说明，请在合法合规的前提下使用相关协议与工具。