Playwright MCP 还是 CLI？从浏览器到 GitHub、Stripe 的智能体工具选型

MCP 和 CLI 怎么选？

开发者在代码仓库里工作，先选 CLI。 命令行接口就是通过命令操作程序的方式。如果智能体已经有获准使用的命令执行器，而且工具能完成任务，再加一层集成可能只会增加维护负担，结果却没有改善。

托管助手需要服务不同用户时，优先选择权限范围受限的 MCP 服务，而不是共用的高权限 shell。 Model Context Protocol 是 AI 应用发现和调用工具的标准。远程服务器可以接受各个用户的授权，只开放助手需要的操作。但这些权限仍然需要你来强制执行。

工程团队共用工具时，可以按职责同时使用两者。 仓库内的工作交给命令执行器；共享的业务操作交给服务层，由服务核验调用者的身份和权限。

真正决定选型的是运行环境的访问能力、凭据归属、操作覆盖范围，以及有多少信息会进入模型。协议叫什么，排在这些之后。

本文依据的厂商文档已于 2026 年 11 月 11 日核验。这里讨论的是有文档依据的工作流和架构判断，不是基准测试，也不声称做过上手实测。

CLI 与 MCP 如何连接模型？

MCP 给智能体一份工具说明，CLI 给它一条可执行的命令。 两者都不能让模型自行完成操作。外围应用接收模型提出的调用，应用自身的控制规则，执行操作，再返回结果。

使用 MCP 时，客户端向服务器查询可用工具。每个工具描述自己的名称、用途和输入模式，也就是接受哪些字段。应用可以把这些定义提供给模型，由模型选择工具并填写结构化参数。MCP 工具规范定义了发现和调用机制，具体怎样与用户交互则由应用决定。

使用 CLI 时，智能体通过命令执行工具启动已安装的程序。它可能已经熟悉常见命令，也可以读 --help，核对当前安装版本的语法。响应可以是文本、结构化 JSON，也可以是文件路径。“CLI 输出”并不等于“非结构化文本”。

例如，“列出我尚未关闭的拉取请求”可以转化为带参数的 GitHub 工具调用，也可以是 gh pr list 命令。底层账号仍然需要有权读取这些拉取请求。换一种接口不会凭空获得访问权限。

关于协议更广泛的作用，参见什么是 MCP。

上下文开销：简单的本地任务，CLI 更占优势

CLI 可以让无关的工具细节不进入模型上下文，但不会让上下文消耗消失。 上下文是模型在决定下一步时接收到的信息。宿主应用一旦把工具说明和参数模式纳入请求，它们就会占用 token，帮助文本和命令输出也是如此。

因此，工具列表庞大的 MCP 服务器可能在开始有效工作之前就占用不少上下文。关键前提是：宿主应用什么时候把工具列表放进来。不能假定每个应用都会在每次模型请求中加载所有可用定义。缩减工具数量或按需发现工具，都会改变比较结果。

CLI 路径可以先只提供命令执行器的定义，需要时再加载具体工具的帮助。数据也可以先过滤，再返回给模型。只请求拉取请求的标题和 URL，比返回完整记录后再让模型忽略大部分内容更合适。

不过，CLI 如果打印巨量日志，或某个技能加载了很长的手册，也会抵消这一优势。同样，一个只返回简短答案的 MCP 工具，可能比反复在 shell 中摸索更高效。应该衡量完整任务：定义、帮助、输出、重试，以及结果是否正确。单看命令字符串短，说明不了多少问题。

本项结论：常规本地任务能按需精简输出时，CLI 更合适。 MCP 如果把工具集和结果保持精简，也有竞争力。这里没有依据给出一个普遍适用的 token 倍数。

身份验证与权限：服务真正执行边界，MCP 才有优势

按用户分别授权，比智能体发送的是 JSON 还是命令字符串更重要。 OAuth 是一种委托授权登录流程：用户授权客户端，不必把密码交给它。远程 MCP 部署可以利用这个身份，判断客户端能访问哪些账号、记录和操作。

设想一个服务于不同客户组织的客服助手。它应当读取当前登录客户的记录，而不是拿到能查看所有账号的工程师凭据。在权限正确限定的远程 MCP 服务与共用管理员 shell 之间，应选前者。在这两种具体实现中，MCP 可能是唯一可接受的方案。

但安全架构并不只有这一种。直接集成 API 也能执行同样的边界。加上 MCP，也不会自动获得这层保障：MCP 授权规范将授权设为可选项，定义了 HTTP 授权流程，并区分了从环境中获取凭据的本地 STDIO 服务器。

CLI 也可以使用浏览器登录和限定权限的凭据。风险来自其进程实际能访问什么：凭据、文件、网络目标，以及其他可执行程序。配有窄范围凭据的沙箱命令执行器，与不受限制地访问开发者电脑，完全是两回事。

本项结论：跨用户的委托访问，优先考虑权限受限的远程 MCP。 无论走哪条路径，都应在代码中执行账号和对象层面的授权，避免凭据出现在模型可见的输出里，并记录每次操作由哪个用户授权。

GitHub CLI 与 GitHub MCP：仓库内工作，还是共享服务访问？

编码智能体已经在仓库检出目录里工作时，gh 命令行客户端 GitHub CLI 是直接的选择。 假设你要汇总自己尚未关闭的拉取请求，在仓库内完成身份验证后，可以使用以下文档列明的参数：

gh pr list --author "@me" --json number,title,url

这条命令只请求摘要所需的字段。CLI 还支持用 --jq 在 JSON 到达模型之前进行过滤。这是可以实际采用的上下文节省方法，但本文不据此声称有任何 token 基准成绩。

CLI 的边界取决于外围的执行环境。某条命令能在你的笔记本上运行，不代表它就适合作为所有员工或客户的接口。根据 GitHub CLI 登录手册，浏览器登录通常把 token 存在系统凭据存储中；存储不可用时，会退回明文方式。应检查实际的凭据安排，不要以为“本地”就等于隔离。

GitHub 官方工具服务器 GitHub MCP Server，适合需要通过 MCP 执行仓库操作的助手。 做同样的摘要时，开放相关的拉取请求工具，使用目标用户的授权，再请求该用户尚未关闭的拉取请求。GitHub 提供托管的远程服务器，也提供本地方案。

GitHub 文档介绍了工具集、单个工具选择，以及不包含写入工具的只读模式。远程 OAuth 支持还取决于宿主应用是否配置了相应的 GitHub 应用或 OAuth 应用；传输协议兼容，不代表身份验证就已经解决。

这组怎么选： 开发者自己的摘要和仓库脚本，用 gh。共享助手的客户端如果支持所需的身份验证流程，优先考虑 MCP。两者都不能替代仓库权限；减少 MCP 工具数量，还能同时改善使用清晰度和上下文开销。

Playwright MCP 与 CLI：编码检查，还是探索式浏览器交互？

Microsoft 的浏览器操作命令接口 Playwright CLI，是编码智能体检查网页改动时的默认选择。 开发方建议编码智能体采用 CLI 加技能，因为命令可以避免把大量模式定义和页面数据加载进上下文。这是开发方的设计建议，不是本文测得的速度结论。

开发者检查表单时，工作流是打开页面、查看相关元素、执行交互，再检查结果。智能体不必在每次操作后都读取页面的所有细节。

playwright-cli install 怎么用？先从官方命令开始

文档给出的安装方式及只读页面检查流程如下：

npm install -g @playwright/cli@latest
playwright-cli --help
playwright-cli open https://playwright.dev
playwright-cli snapshot
playwright-cli close

这些命令用于查看公开页面，不是一套测试。先利用生成的快照识别目标，再加入针对自己应用的交互。

Playwright CLI 技能：补上工作流程指令

安装 CLI 后，文档提供的技能安装命令是：

playwright-cli install --skills

关键限制在于外围条件仍需要你来提供：可执行环境、合适的浏览器会话，以及定义成功标准的指令。技能可以帮助规范流程，却无法判断一笔真实客户交易是否获得了授权。

如果 MCP 客户端在探索式交互循环中能受益于结构化页面检查，Microsoft 的浏览器工具服务器 Playwright MCP 更合适。 它通过无障碍快照，即对页面元素的结构化描述，支持浏览器交互。

有两个限制需要留意。首先，持久化浏览器状态并非 MCP 独有：Playwright CLI 会在同一会话的多次调用间保留 cookie 和存储，也提供可跨浏览器重启保留的持久化配置文件。其次，MCP 仓库明确指出，服务器本身不是安全边界。其来源控制说明同样警告，这些控制不提供安全边界，也不影响重定向。

这组怎么选： 编码工作流中的常规检查，用 CLI 加技能；客户端和任务确实能受益于浏览器工具交互时，用 MCP。不要仅为保留会话状态而切换。Playwright MCP 配置与浏览器测试指南更详细地介绍了这条路径。

Stripe CLI 与 Stripe MCP：开发 webhook，还是操作账号？

开发和调试支付集成时，Stripe 的终端工具 Stripe CLI 更合适。 典型任务是在本地运行的应用中接收 webhook 事件，也就是 Stripe 在发生某件事时发出的通知。CLI 文档介绍了用 stripe listen 接收和转发这些事件，以及用 stripe trigger 生成示例事件。

这套工作流应放在沙箱中。触发事件会创建 API 对象，还可能产生额外事件，并不只是打印一份示例载荷。CLI 也支持 API 操作和请求日志检查，因此不只适用于转发 webhook。

身份验证上的区别，比“CLI 就是复制 API 密钥”复杂得多。Stripe 文档介绍了按用户进行浏览器登录、在可用时安全地存储本地凭据、会话刷新和撤销。对开发者来说，这可以是合适的安排。但托管助手如果走 CLI 路径，仍然需要隔离各个用户的运行环境和凭据。

兼容的助手没有本地命令执行器，却需要操作账号时，面向智能体的服务接口 Stripe MCP 更合适。 例如，获得授权的操作人员可以让助手查找和读取相关 Stripe API 数据。服务器提供 API 搜索、参数发现、读取和写入工具，而不是为每一种操作单独定义工具。

Stripe 支持通过 OAuth 代表用户访问，也支持使用智能体 API 密钥独立访问。通用工具 stripe_api_write 可以覆盖很多操作。Stripe 对人工确认的要求取决于具体操作，且独立于客户端自己的工具审批设置。因此，批准某一类工具，不等于批准它能执行的每一项业务操作。

这组怎么选： 本地开发 webhook 用 CLI；在助手中委托处理账号事务用 MCP。应比较所需的操作，而不是命令或工具的数量。能读取账号数据的 MCP 连接，不能替代开发工作流中的本地 webhook 监听器。

MCP 与 Skills 有什么区别？指令属于另一层

技能告诉智能体怎么工作；MCP 和 CLI 提供执行操作的途径。 在 Agent Skills 格式中，SKILL.md 文件包含名称、说明和任务指令，也可以配套脚本和参考文件。智能体先发现元数据，需要时再加载更完整的指令。

讨论“MCP、CLI 和 Skills 怎么选”时，实用的组合往往是 CLI 加技能。CLI 执行操作；技能规定该用哪些命令、选择什么环境、检查哪些证据，以及何时停止。技能也完全可以指导智能体使用 MCP 工具。

例如，汇总拉取请求的技能可以要求只处理尚未关闭的请求，选择简洁字段，并禁止在汇报任务期间发表评论。真正的访问边界仍要由凭据和运行环境执行。书面指令帮助智能体正确行动，但不会收回权限。

本项结论：可重复执行的流程适合用技能。 技能可以配合任一种接口，加载时也会带来自己的上下文开销。

MCP、API 与 CLI：把业务逻辑留在服务层

业务规则集中在服务层，再按用户需要开放接口。 API 是应用供程序调用的接口。CLI 可以调用它，MCP 服务器也可以，Stripe 的接口就是例子。

如果两者都要维护，应复用授权和校验逻辑，不要为“谁可以修改这条记录”分别实现互相竞争的规则。MCP 与 API 对比解释了什么时候值得增加协议层。

仅仅封装一个能接受任意 shell 文本的入口，并不是迁移的充分理由。这可能让现有命令执行器能通过 MCP 访问，却保留了执行器原有的权限。有效的适配器应该开放有明确边界的操作，校验输入，只返回智能体所需的证据。

选型表：按部署场景决定

选择能完成任务、又不扩大权限的最小接口。 以下是起步配置，不是永久绑定。

从 MCP 换到 CLI，或反向迁移

一次迁移一个工作流，不要把整个工具库一起搬。 成本高的部分往往是保留权限、输出和故障处理，而不是把工具名称改成命令。

迁移到 CLI，需要安排安装、凭据、命令执行器、输出过滤和可复现的指令。迁移到 MCP，需要选择或运营服务器，配置客户端身份验证，定义开放的工具范围，并通过该接口处理错误。浏览器工作流还必须明确会话和配置文件归谁所有。

不要仅为增加协议支持，就切换运转良好的 CLI 工作流。也不要因为一条命令看起来更短，就移除正在服务无 shell 用户的远程 MCP 集成。

订阅邮件通讯，获取更多有关智能体工作流选型和权限范围设计的实用指南。

常见问题