MCP 与 CLI 的取舍

MCP 与 CLI 的取舍

这个思考是俺长期观察 codex 使用 github 的工具调用里发现的，我发现即使给了 github 的mcp 工具，codex 在自主使用工具的过程中，更倾向于使用 exec 来执行本地命令行工具gh。所以我觉得有必要记录下我认为的工程取舍。目前 openclaw 很火，openclaw 背后的Pi-mono 也是放弃了 mcp，因为他觉得 MCP 服务器会占用大量上下文，构建带 README 的 CLI 工具，agent 根据需要读取。（https://mp.weixin.qq.com/s/XRZrOvapXWiZneDtipfHTQ）这里提一嘴，用工具的时候，观察工具背后的原理对于培养工程直觉是非常必要的。

有时候我们常会不自觉地将接入 MCP 视为默认，首选往往是开发一个 MCP Server，似乎不走标准协议就显得不够专业。真实工程世界的取舍从来不在于是否贴合标准，而在于成本与收益的匹配度。将视角拉回真实的长期维护、权限治理、上下文预算以及故障模式中，MCP 与 CLI 的边界十分清晰。MCP 侧重于连接与治理，CLI 则主攻效率与完成度。

很多场景下直接调用 CLI 反而是最便捷的路径。以 GitHub 这类公共基础设施为例，GitHub CLI (gh) 往往比对应的 MCP 协议更贴合工程现实。它天然兼容浏览器或设备码授权等常规工作流，同时将大量高频操作沉淀为稳定的子命令。大模型在预训练阶段已经接触过海量的 gh 用法，具备极强的原生认知。另一个核心点在于，CLI 绝不仅限于输出一堆杂乱的文本流。gh 的许多命令原生支持 json 参数，辅以 jq 或模板输出，我们完全可以将其视作结构化数据接口。

这种优势在处理复杂业务时尤为明显。如果目标是将 Agent 培养成能干活的工程同事，它需要的不仅仅是读取 Issue，还要能审查 PR、排查 CI、执行全局搜索、拉取 diff、批量打标，甚至按照项目习惯生成发版日志。成熟 CLI 的壁垒在于覆盖面与组合性，它的逻辑不是开发者封装了什么能力 Agent 才能用，而是它原生就具备这些能力。反观 MCP，其工具集高度依赖 Server 作者预先设计的抽象程度。一旦覆盖不全，就会陷入协议极其优雅但关键动作无法执行的尴尬境地，最终还是得回退到底层 CLI 或原生 API。

模拟浏览器操作同样印证了 CLI 的价值。类似 agent-browser 这类工具，本质上是专供 Agent 调用的无头浏览器自动化 CLI。它的核心交互逻辑摒弃了将整棵 DOM 树硬塞入上下文的粗暴做法，转而采用快照加引用的机制。先抽取按钮和输入框等交互元素的引用，随后通过引用执行点击或填表等动作，必要时重新抓取快照。这种设计不仅极大地节省了 token 开销，更有效避免了因上下文臃肿引发的模型逻辑漂移。另外提一句与浏览器的交互未来也会重构，现在是看看看，点点点，但是 chrome 最近推出了WebMCP 的早期预览版，让网站可以主动告诉 AI Agent “你能在我这里做什么、怎么做”，而不是让 Agent 自己去猜测和操作 DOM。（https://x.com/dotey/status/2022392133827932255）许多人认为 MCP 的核心价值在于教会模型使用工具，但在真实场景中，模型最迫切需要的是极其精简、稳定且可重复的交互截面。将复杂网页转化为元素引用，将发散的操作收敛为有限集合，本质上是将不可控的环境压缩为可控的接口。实现这一目标未必依赖 MCP， CLI 同样能够胜任，且落地速度往往更快。

我自己感觉 mcp 对外，cli 对内用。MCP 的真正价值在于统一协议、划定权限边界。简单说，to 第三方的场景用 mcp 会比较好，当 Agent 缺乏安全的执行环境，或者需要跨团队分发能力、进行严格的审计与配额隔离时，MCP 更理想。然而在代码托管或浏览器自动化等高度工程化且 CLI 已提供完备能力的领域，盲目追求 MCP 而牺牲执行效率实属本末倒置。

更务实的定位是，对于内部使用，在推进平台化或跨团队复用时，接口一致性和安全审计的优先级显然高于敲几行命令的痛快感。但聚焦于单体项目、内网自动化或小团队快速迭代时，CLI 的即时性与功能完备性已经够了。将 MCP 强推为默认选项，只会让我们在最不需要复杂度的地方背上沉重的技术包袱。CLI 潜藏的最大风险并非缺乏结构化，而是执行力过强。一旦向模型开放不受约束的终端权限，它便会本能地试探系统边界。例如 codex 就直接操作命令行的权限只在当前项目下，直接限制死了。或者是搞一个 sandbox 沙盒环境随便不怕折腾的。（https://github.com/alibaba/OpenSandbox）

然后我们回归严格的架构分层。针对 agent 常用的几个工具：Rules 必须将 CLI 的执行权限收束为最小化白名单，严格界定允许运行的二进制文件及参数模式，并把控哪些动作需要人工介入，从而在底层完成安全收口。Skills 则负责沉淀微观方法论，明确在特定场景下的标准作业流程。以 GitHub Skill 为例，可以明确规定优先使用 json 输出、规避交互式提示，并在执行写操作前校验登录状态。对于 Browser Skill，则规范其执行节奏，遇到多因素认证等复杂阻断时直接交由人类接管。至于 AGENTS.md，仅保留针对项目当前基于 uv 环境或日志规范等宏观约束，并提供对这些 Skills 的索引，严禁将具体的命令细节塞满常驻上下文。

这套分层机制的核心在于实现安全与规范的物理层面解耦。Rules 作为硬约束，Skills 充当软约束，引导 Agent 采用正确的工程方法。AGENTS.md 则是全局导航，重原则而轻细节。不要将权限与规范混为一谈，导致终端权限大开的同时指令冗长，上下文极度臃肿，模型行为却依旧充满不确定性。

从落地构建的视角出发，需要分步。目前大多数场景，特别是 to b 的，只能在 dify 上使用 mcp，然后后续可以自己先试试咋搭建agent 给第三方公司用，然后还能控制模型的边界，如果是本地化部署，就更好。但是失去了最为重要的联网功能了。这都是后话了。我觉得初始阶段优先借助 CLI 跑通核心链路。对于 gh 或 agent-browser 这类成熟工具，完全可以先让 Agent 在受控沙盒内通过 CLI 实现闭环。同时强制输出结构化数据，剔除交互式死锁隐患，并在写操作前加入严密的校验环节。这一阶段重在解决执行效率与业务完成度。随着业务深入遭遇治理瓶颈时，再着手推动产品化改造。产品化并不意味着必须立即上线 MCP Server，更务实的做法是进行一层轻量级封装。将高风险或强依赖结构化数据的动作封装为内部调用 CLI 的工具函数，参数实施严格的白名单过滤，返回结果规范为稳定的结构化数据，并建立完善的错误码恢复机制。直到确有跨端复用或多租户隔离的硬性需求时，再将这层封装平滑外置为 MCP 接口。此时 MCP 的角色是承接分发与治理，而非弥补底层能力的缺失。