在 AI 代理系统中，浏览器代理的分发循环（dispatch loop）是核心组件：代理反复思考（think）、选择工具（tool call）、执行浏览器操作（如打开页面、点击元素、提取数据）、观察结果（observe），直到任务完成。这种循环往往涉及数十次迭代，对延迟、状态管理和资源开销极为敏感。选择 MCP（Model Context Protocol）协议还是 CLI（Command Line Interface）作为浏览器工具接口，直接影响循环效率和可靠性。本文聚焦单一技术点：MCP 在浏览器代理分发循环中的优势 —— 有状态会话、更低延迟、无子进程开销，对比 CLI 的简单性，并给出可落地参数与清单。
MCP 协议的核心优势：为什么适合分发循环
MCP 是一种结构化 JSON-RPC 协议，专为 AI 代理设计，代理客户端连接到 MCP 服务器（如浏览器服务器），通过持久连接调用工具。浏览器代理场景下，MCP 服务器暴露细粒度工具：open_page(url)、click(selector)、evaluate_js(script)、wait_for_selector(timeout) 等。
优势 1: 有状态会话（Stateful Sessions）
分发循环中，浏览器需维护多轮上下文，如登录状态、购物车内容、表单填充进度。MCP 原生支持会话管理：服务器跟踪 session ID，参数中传入 session_id，返回 structured 结果带上下文。相比 CLI，每次调用需通过文件 / 环境变量传状态，易丢失或污染。证据：在终端工具基准测试中，MCP 版本成功率达 100%，CLI 需额外指令管理状态，导致 token 浪费。
优势 2: 更低延迟（Lower Latency）
CLI 每次工具调用 spawn subprocess（如 playwright-cli run ...），启动 Chrome 实例开销 100-500ms，加上解析 stdout/stderr，总延迟 >1s / 调用。MCP 使用持久 WebSocket/HTTP2 连接，无进程启动，单调用 <100ms。基准显示，MCP 整体循环快 23%，因避免安全检查和 bash invocation 开销。在高频分发循环（>20 迭代 / 任务），累积节省显著。
优势 3: 无子进程开销（No Subprocess Overhead）
CLI 循环中，每迭代 spawn 进程，CPU / 内存峰值高，适合低频任务。MCP 单服务器实例复用浏览器上下文，无重复初始化。生产中，CLI 并发 10+ 循环易 OOM，MCP 单实例支持 100+ 会话。
这些优势源于 MCP 的治理设计：typed 参数防错、structured errors 便解析（如 {"error": "timeout", "retry_after": 5}），代理易恢复。
CLI 的反面：简单但不适合高频循环
CLI 如 Playwright CLI、Puppeteer CLI 或自定义 browserctl，优势在于简单：代理生成 shell 命令，利用训练数据知识（如 playwright test --headed），无需服务器。封装复杂流：browserctl checkout --url=site.com --user-id=123 一键完成多步。
但缺点暴露在分发循环：
- 状态管理笨拙：用
--session-file或 temp dir，代理须追踪，易FileNotFound。 - 高开销：subprocess + Chrome launch，p95 延迟 2s+。
- 解析脆弱：stdout 混杂 ANSI/HTML，模型需额外 token 提取 JSON。
基准中，CLI token 高效于熟悉工具，但浏览器自定义 CLI 需文档，整体不如 MCP structured。
引用一例：“MCP adds JSON-RPC framing，但为 structured schemas 换来 predictability。”（来源：MCP vs CLI 基准）
浏览器代理特定场景：何时选何种
浏览器代理分发循环典型：代理解析用户意图 → 调用浏览器工具 → 观察 DOM 变化 → 调整。MCP 胜在多租户：共享服务器，per-session 隔离（如不同用户浏览器 profile）。CLI 胜在单租户实验：快速迭代 Playwright 脚本，无协议定义。
决策矩阵：
| 场景 | 推荐 | 理由 |
|---|---|---|
| 单租户 / 原型 | CLI | 简单，复用现有工具 |
| 多租户 / 生产 | MCP | 治理、安全 |
| 高频循环 (>10 iter) | MCP | 低延迟 |
| 复杂状态 (登录、多 tab) | MCP | 原生支持 |
可落地参数与工程清单
MCP 实现参数（基于 Playwright MCP 服务器）：
- 会话 TTL：5min，无活动自动清理，防内存泄漏。
- Heartbeat：每 10s 发送
ping，超时 30s 断开。 - 并发上限：per IP 20 会话，global 500。
- 工具粒度：10-15 个（如 screenshot, extract_text），避免 overload。
- Retry：幂等工具 3x，重试间隔 100ms*2^n。
- Timeout：单调用 10s，循环总时 5min。
CLI 参数（Playwright CLI 示例）：
- Max concurrent：5，避免资源争用。
- Timeout：命令 30s，kill -9。
- Output：
--reporter json，便解析。 - Sandbox：docker run --privileged=false。
监控与回滚策略：
- 指标：循环 latency p95 <800ms，error rate <3%，token/loop <5k。Prometheus 采集 MCP metrics（如 calls/sec）。
- 告警：latency >1.5s 或 OOM → 降级 CLI。
- A/B 测试：50% 流量 MCP，观察 completion rate +20%。
- 回滚：MCP 失败 → fallback CLI，日志
session_id: mcp_error → cli_fallback。
迁移清单：
- 搭建 MCP 服务器（Node.js + Playwright，暴露 12 工具）。
- 代理提示优化：强调
use session_id consistently。 - Load test：100 并发 checkout 任务，测 throughput。
- 渐进 rollout：10% → 100%。
采用 MCP 可将浏览器代理循环效率提升 25%，尤其生产环境。CLI 仍为快速验证首选。
资料来源：
- MCP vs CLI: Benchmarking Tools
- MCP vs CLI for AI Agents
- Perplexity 搜索结果（2026-03-02）