当智能体宿主需要可发现、带类型的工具，并在协议层面为能力和同意留出位置时，使用 MCP。当任务已经适合命令、文件、管道、退出代码和受控 shell 时，使用 CLI。浏览器扩展通常不是第三种对等选项：它可以在智能体通过 MCP 或 CLI 访问的工具下方授予或附加浏览器访问能力。
AI 智能体应该使用 MCP 还是 CLI？
从操作边界开始，而不是胜负。如果主机必须枚举工具、验证 JSON 参数、呈现用户审批并在服务器之间切换，MCP 提供了共享契约。如果编码代理已经拥有受限 shell，并且该操作天然由具有稳定 stdout 和退出码的命令表示，CLI 通常是更简单的路径。
| 需求 | 优先 MCP | 优先 CLI |
|---|---|---|
| 运行时发现 | 类型化工具目录 | 帮助文本或已加载技能足够 |
| 组合 | 主机编排结构化调用 | 管道、文件、脚本和退出码 |
| 远程边界 | 协议传输和服务器生命周期 | SSH、容器、作业或本地进程控制 |
| 输出控制 | Schema 加工具结果契约 | 命令特定的原始输出或 JSON 输出 |
MCP、CLI 和扩展可以相提并论吗？
并非处于同一层级。MCP 和 CLI 是调用表面：它们告诉代理主机如何请求工作。浏览器扩展是浏览器内部的执行或访问组件。它可以附加到用户标签页、请求主机权限、注入内容脚本，或将浏览器状态桥接到另一个进程。
这种区分可防止错误比较。‘MCP 支持 Schema，而扩展可以点击页面’ 将协议属性与实现能力进行比较。一个公正的设计问题是：在什么权限和用户控制边界下，哪条调用路径应暴露哪个浏览器实现？
MCP 与 CLI 有何不同？
MCP 客户端初始化会话、协商能力、列出工具，并向服务器发送结构化调用。当前的 tools 规范允许服务器发布名称、描述、JSON 输入 Schema、可选输出 Schema 和注解。主机仍然负责呈现适当的同意，并且必须将工具注解视为不可信，除非服务器受信任。
CLI 进程从操作系统接收字符串和环境状态。其契约可通过 --help、手册页、示例、退出码以及可选的 JSON 输出来记录。Shell 通过重定向、管道、脚本、进程隔离和标准日志记录增加了成熟的组合能力，但也带来了引用、路径、环境和注入风险，主机必须加以约束。
两者都可以封装相同的实现。在我们的实验中，Playwright 为两条路线提供动力。浏览器任务并没有因为一条命令经过 JSON-RPC 而另一条经过 shell 而变得更强或更弱；发生变化的是发现、输出、会话和策略表面。
发现性和上下文成本有何不同？
MCP 使发现过程机器可读。这有助于主机决定可以调用什么，并为模型提供描述和参数形状。代价是，如果客户端急切加载，庞大的目录或冗长的工具结果可能占用大量上下文。客户端可以通过服务器选择、搜索、工具分组、结果文件、有界快照和简洁输出等方式来缓解此问题。
CLI 并不能消除上下文开销。智能体仍然需要命令名称、标志、示例和返回的输出。设计良好的技能可以只加载相关的命令配方，并要求 CLI 输出紧凑的 JSON 或结果文件。设计糟糕的 CLI 可能倾倒数兆字节的内容或迫使反复调用帮助。请比较实际路线的字节数和模型可见内容，而不是‘零 token CLI’之类的口号。
哪种接口更安全？
两种接口本质上都不安全。MCP 可以将工具描述为只读或具有破坏性，但规范警告客户端不要信任来自不受信任服务器的注解。主机仍然需要服务器信任、用户同意、身份验证、目标限制、超时、日志记录，以及撤销凭据的方法。
通过使用范围狭窄的可执行文件允许列表、固定工作目录、清理后的环境、非管理员用户、文件系统沙箱和参数验证，可以强有力地约束 CLI。如果智能体获得一个包含机密、命令替换、广泛文件访问或生产凭据的通用 shell，也可能变得危险。请避免将机密直接放在提示或命令参数中，因为进程和记录日志可能会保留它们。
浏览器扩展增加了它们自己的边界。请审查请求的权限、主机模式、内容脚本作用域、更新来源、原生消息桥接，以及用户是否可以看到并中断操作。‘在我的浏览器中运行’既不能证明安全，也不能证明风险；决定因素是权限和数据流图。
每种方法的可移植性如何？
MCP 可以在服务器作为本地进程或服务运行的同时，保持稳定的面向客户端的契约，但身份验证、传输、文件系统路径和服务器安装仍因主机而异。在目标操作系统、运行时、二进制文件和 shell 兼容的情况下，CLI 工具具有良好的可移植性。脚本必须考虑引用、路径分隔符、浏览器可用性和版本固定。
扩展与浏览器的扩展 API、权限模型、商店或企业分发以及用户配置文件紧密相关。它们之所以有用，正是因为它们靠近真实浏览器，但这也使它们更难移植到无头服务器或非浏览器任务。
我们的同任务测试中发生了什么？
两条路线都打开了自己的页面，填写了一个字段，等待延迟的产品，发现重复控件，经受住了 DOM 替换，观察到了有意的 HTTP 503 和一次成功的请求，然后关闭了浏览器。每条路线使用了九次任务调用或命令，重复三次。
| 观测中位数 | Playwright MCP 0.0.80 | Playwright CLI 0.1.19 |
|---|---|---|
| 任务成功 | 3/3 | 3/3 |
| 调用/命令 | 9 | 9 |
| 返回的 UTF-8 字节数 | 22,235 | 1,737 |
| 工具目录 | 24 个工具；18,569 字节 | 不会自动返回 |
| 墙钟时间 | 2,165 毫秒 | 14,544 毫秒 |
墙钟时间结果与字节结果方向相反，因为 CLI 测试装置有意启动了九个独立的 npx 进程，并重新连接到一个命名会话。持久化包装器或批处理命令可以改变该结果。可靠的结论范围更窄：在此配置下，MCP 提供了更丰富的发现能力并返回了更多文本；CLI 返回了简洁输出，但将发现过程移到了任务调用之外。
何时应该使用 MCP、CLI 或两者都用？
对于必须可发现、带类型、经同意且可跨客户端替换的宿主面向能力，优先使用 MCP。对于确定性的本地操作、现有工程工具、构建步骤、仓库工作，或文件与退出码契约已经很稳固的命令，优先使用 CLI。
当边界值得时才两者都用。受治理的 MCP 服务器可以暴露一个窄化的业务操作，而编码智能体使用 CLI 命令进行本地验证。CLI 可以管理服务器安装和诊断，而活动任务使用 MCP 工具。除非授权和审计行为真正等价，否则避免通过多个不受控路由暴露同一个高风险操作。
仅当任务需要现有标签页、用户可见状态或浏览器专用 API 时，才添加浏览器扩展。当不需要个人配置时，优先使用干净的自动化配置或直接协议。
ego (lite) 和 ego-browser Skill 是什么？
把产品本身和它的控制接口分开看。ego (lite) 是一款面向人和 AI Agent 的完整本地 Chromium 浏览器；按产品类别来说，它属于 agent browser。它不是 AI Agent，不是浏览器扩展程序，不是 MCP 服务器，也不是云浏览器。兼容的 Agent 通过 ego-browser 直接在页面中操作，不需要安装、配对或保持连接的扩展程序桥接，也没有任何东西会和你当前的标签页或窗口焦点争抢。用户可以随时观看、暂停或接管。虽然 Skill 是从 shell 入口启动并执行 JavaScript，但它并不是那种一次一条命令的 CLI 工作流。
AI Agent 编写一段 JavaScript 程序，通过 ego-browser 的 shell 入口运行。整个工作流可以在一次运行中完成导航、等待、检查、点击和提取，然后只把选中的结果返回给模型，因此模型看到的是最终结果，而不是每一个中间步骤。
ego-browser nodejs <<'EOF'
const task = await taskSpace("review dashboard");
const page = task.page("p1");
await page.goto("https://app.example.com/reports");
const title = await page.title();
console.log({ title });
await task.finish({ keep: [] });
EOF这是一条有效的第三条路线，因为有意义的比较在于执行模型，而不是可执行文件的名称。MCP 暴露可发现的结构化工具，并且通常在每次工具调用后返回。逐条命令的 CLI 暴露单个 shell 操作。而 ego-browser Skill 在模型上下文之外针对专用的可见 Space 执行多步骤 JavaScript 工作流。shell 启动 Skill；这并不会将 Skill 归入 CLI 类别。
如需更深入地了解为何批处理 JavaScript 会改变上下文成本和模型往返次数，请阅读我们关于上下文外路由的技术拆解.
在 2026 年 9 月 11 日的受控运行中，ego-browser 0.5.0.31 恢复了一个 ego (lite) Space，等待延迟到达的 fixture 数据，识别出两个重复的 Beta 控件，并打开了一个单独验证过的 receipt 标签页，整个过程用户自己的标签页始终未受影响。
当智能体需要可见的、经用户授权的浏览器 Space，多步骤 JavaScript 应在模型循环之外运行，并且人工接管很重要时，选择此路线。当宿主需要标准化的工具发现和受治理的调用时，选择 MCP；当工作已经适合稳定的命令、文件、管道和退出码时，选择 CLI。当 API、普通 HTTP 请求、一次性测试浏览器或确定性的 Playwright 套件能以更小的信任面解决任务时，优先选择这些方式。
你应该如何验证这个选择？
- 冻结一个有代表性的任务、版本、宿主、凭据和停止条件。
- 使用声明的分母统计模型可见的 schema 和结果内容；不要根据字符数估算 token。
- 记录调用失败、错误工具选择、权限提示、机密暴露路径以及恢复工作。
- 按交替顺序重复，并保留失败情况，而不是将其平均化掩盖掉。
- 测试实际部署边界：本地、远程、容器、浏览器扩展或现有配置文件。
- 选择满足可发现性、安全性、可移植性、可观测性和可维护性要求的最简路径。
哪些官方来源定义了这些层次？
使用当前的 MCP架构规范和工具规范用于协议声明。经过测试的实现记录在官方Playwright MCP和Playwright CLI仓库中。
将浏览器访问视为独立的权限面；Chrome 在声明权限。ego-browser 示例已对照当前ego (lite) 快速入门于 2026 年 9 月 11 日。
常见问题
MCP 是否比 CLI 消耗更多 token？
当客户端加载大型工具 schema 或冗长结果时，可能会如此，但并不存在通用的百分比。CLI 帮助和输出也会消耗上下文。请使用真实遥测数据来衡量实际的客户端、服务器、技能和任务。
CLI 可以作为 MCP 服务器吗？
可以。MCP 服务器可以验证结构化调用，并在底层调用现有 CLI。包装器应保留错误语义、限制参数，并避免复制不安全的通用 shell。
浏览器扩展比 MCP 更安全吗？
并非按类别一概而论。请比较确切的扩展权限、主机策略、凭据、更新路径、用户可见性和撤销机制。MCP 描述调用；扩展描述浏览器端访问。
