当代理主机需要具有协议级功能和同意位置的可发现、类型化工具时，请使用 MCP。 当任务已经适合命令、文件、管道、退出代码和受控 shell 时，请使用 CLI。 浏览器扩展通常不是第三个对等选项：它可以在代理通过 MCP 或 CLI 访问的工具下授予或附加浏览器访问权限。
AI代理应该使用MCP还是CLI？
从经营边界开始，没有赢家。 如果主机必须枚举工具、验证 JSON 参数、提供用户批准以及在服务器之间切换，MCP 提供共享合约。 如果编码代理已经具有受限制的 shell，并且操作自然地由具有稳定 stdout 和退出代码的命令表示，则 CLI 通常是更简单的路径。
| 需要 | 更喜欢MCP | 更喜欢CLI |
|---|---|---|
| 运行时发现 | 打字工具目录 | 帮助文本或加载的技能就足够了 |
| 组成 | 主机协调结构化调用 | 管道、文件、脚本和退出代码 |
| 远程边界 | 协议传输和服务器生命周期 | SSH、容器、作业或本地进程控制 |
| 输出控制 | 架构加工具结果契约 | 命令特定的原始或 JSON 输出 |
MCP、CLI 和扩展是否具有可比性？
不在一个级别。 MCP 和 CLI 是调用表面：它们告诉代理主机如何请求工作。 浏览器扩展是浏览器内部的执行或访问组件。 它可以附加到用户的选项卡、请求主机权限、注入内容脚本或将浏览器状态桥接到另一个进程。
这种区别可以防止错误比较。 “MCP 支持模式，而扩展可以单击页面”将协议属性与实现功能进行比较。 一个公平的设计问题是：哪个调用路径应该在什么权限和用户控制边界下公开哪个浏览器实现？
MCP 和 CLI 有何不同？
MCP 客户端初始化会话、协商功能、列出工具并向服务器发送结构化调用。 当前的工具规范允许服务器发布名称、描述、JSON 输入模式、可选输出模式和注释。 主机仍然负责提供适当的同意，并且必须将工具注释视为不可信，除非服务器可信。
CLI 进程从操作系统接收字符串和环境状态。 它的合同可以通过 --help、手册页、示例、退出代码和可选的 JSON 输出来记录。 shell 通过重定向、管道、脚本、进程隔离和标准日志记录添加了成熟的组合，但也创建了主机必须限制的引用、路径、环境和注入风险。
两者都可以包装相同的实现。 在我们的实验中，Playwright 为两条路线提供动力。 浏览器任务的能力并没有因为一个命令跨过 JSON-RPC 而另一个命令跨过 shell 而变得更强或更弱； 发现、输出、会话和政策面发生了变化。
发现和上下文成本有何不同？
MCP 使发现变得机器可读。 这有助于主持人决定可以调用什么，并给出模型描述和参数形状。 代价是，如果客户端急切地加载大型目录或冗长的工具结果，则它们可能会占据有意义的上下文。 客户端可以通过服务器选择、搜索、工具组、结果文件、有界快照和简洁输出来缓解这一问题。
CLI 不会消除上下文。 代理仍然需要命令名称、标志、示例和返回的输出。 精心设计的技能可以仅加载相关的命令配方，并向 CLI 请求紧凑的 JSON 或结果文件。 设计不良的 CLI 可能会转储兆字节或强制重复呼叫帮助。 比较实际路由的字节和模型可见内容，而不是诸如“零令牌 CLI”之类的口号。
哪个接口更安全？
这两个接口本质上都不是安全的。 MCP 可以将工具描述为只读或破坏性，但规范警告客户端不要信任来自不受信任服务器的注释。 主机仍然需要服务器信任、用户同意、身份验证、目标限制、超时、日志记录以及撤销凭证的方法。
CLI 可以被严格包含在狭窄的可执行白名单、固定工作目录、清理环境、非管理员用户、文件系统沙箱和参数验证中。 如果代理收到包含机密、命令替换、广泛文件访问或生产凭据的通用 shell，也可能变得危险。 避免将机密直接放置在提示或命令参数中，因为进程和转录日志可能会保留它们。
浏览器扩展添加自己的边界。 检查请求的权限、主机模式、内容脚本范围、更新来源、本机消息传递桥以及用户是否可以查看和中断操作。 “在我的浏览器中运行”既不是安全证明，也不是风险证明； 权限和数据流图决定。
每种方法的可移植性如何？
MCP 可以在服务器作为本地进程或服务运行时保持稳定的面向客户端的合同，但身份验证、传输、文件系统路径和服务器安装仍然因主机而异。 CLI 工具可以在目标操作系统、运行时、二进制文件和 shell 兼容的情况下顺利运行。 脚本必须考虑引用、路径分隔符、浏览器可用性和版本固定。
扩展与浏览器的扩展 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 毫秒 |
wall-time 结果指向与字节结果相反的方向，因为 CLI 线束故意启动了 9 个单独的 npx 进程并重新附加到命名会话。 持久包装器或批处理命令可以更改该结果。 可辩护的结论范围更窄：在此配置中，MCP 暴露了更丰富的发现并返回了更多文本； CLI 返回简洁的输出，但将发现移至任务调用之外。
什么时候应该使用 MCP、CLI 或两者都使用？
首选 MCP 来实现面向主机的功能，该功能必须可在客户端之间发现、输入、同意和交换。 对于确定性本地操作、现有工程工具、构建步骤、存储库工作或文件和退出代码契约已经很强大的命令，首选 CLI。
当边界获得边界时使用两者。 受治理的 MCP 服务器可以公开狭窄的业务操作，而编码代理使用 CLI 命令进行本地验证。 CLI 可以管理服务器安装和诊断，而活动任务则使用 MCP 工具。 避免通过多个不受控制的途径暴露相同的高风险行为，除非授权和审计行为确实相同。
仅当任务需要现有选项卡、用户可见状态或仅限浏览器的 API 时才添加浏览器扩展。 当不需要个人配置文件时，首选干净的自动化配置文件或直接协议。
什么是 ego (lite) 和 ego-browser Skill？
先把产品和控制接口分开来看。ego (lite) 是一款供人和 AI Agent 共同使用的完整本地 Chromium 浏览器，品类上属于 AI Agent 浏览器。它不是 AI Agent 本身，也不是浏览器扩展程序、MCP 服务器或云浏览器。兼容 Agent 通过 ego-browser——也就是 Skill 和控制接口——在专用、用户可见且拥有独立标签页的 Space 中工作。你可以查看过程、暂停任务或随时接管。虽然 Skill 从 shell 入口启动并执行 JavaScript，但它不是逐条执行命令的 CLI 工作流。
Agent 会先编写一段 JavaScript 程序，再通过 shell 入口启动 Skill 运行时。程序在 Node.js 中运行，浏览器操作则经由 ego (lite) 的本地控制器和内置 CDP 连接执行。一次运行即可完成导航、等待、检查、点击和提取，最后只把选定结果返回给模型。
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，等待延迟的测试数据，识别出两个重复的 Beta 控件，并打开了一个经过单独验证的结果标签页。
当 Agent 需要用户授权且可见的浏览器 Space、多步骤 JavaScript 应在模型循环之外运行，并且人工接管很重要时，选择这条路线。当宿主需要标准化工具发现和受治理调用时选择 MCP；当工作天然适合稳定命令、文件、管道和退出码时选择 CLI。如果 API、普通 HTTP 请求、一次性测试浏览器或确定性的 Playwright 测试套件能以更小的信任面完成任务，则优先使用它们。
您应该如何验证选择？
- 冻结一项代表性任务、版本、主机、凭据和停止条件。
- 使用声明的分母对模型可见模式和结果内容进行计数； 不要根据字符数来估计标记。
- 记录调用失败、错误的工具选择、权限提示、秘密暴露路径和恢复工作。
- 以交替顺序重复并保留失败而不是平均它们。
- 测试实际部署边界：本地、远程、容器、浏览器扩展或现有配置文件。
- 选择满足发现、安全性、可移植性、可观察性和维护要求的最简单的路由。
哪些官方来源定义了这些层？
使用当前的MCP架构规范和工具规范用于协议声明。 测试的实现记录在官方文档中Playwright MCP和Playwright CLI存储库。
将浏览器访问视为单独的权限表面； Chrome 将其模型记录在声明权限。 ego-browser 示例已根据当前版本进行检查ego (lite) 快速入门于 2026 年 9 月 11 日。
常见问题解答
MCP 使用的代币是否比 CLI 更多？
当客户端加载大型工具架构或详细结果时可能会出现这种情况，但没有通用的百分比。 CLI 帮助和输出也会消耗上下文。 通过真实的遥测测量实际的客户端、服务器、技能和任务。
CLI 可以是 MCP 服务器吗？
是的。 MCP 服务器可以验证结构化调用并调用底层的现有 CLI。 包装器应保留错误语义、限制参数并避免重复不安全的通用 shell。
浏览器扩展比 MCP 更安全吗？
不按类别。 比较准确的扩展权限、主机策略、凭据、更新路径、用户可见性和撤销。 MCP描述调用； 扩展描述了浏览器端访问。
