当我们讨论智能体时，最容易被看见的是“脑”：模型有多强、上下文有多长、推理有多稳。但真正决定一个智能体能不能进入现实工作流的，往往是另一件更朴素的事：它到底用什么“手”去碰外部世界。
只会聊天的 AI，本质上还停留在建议层。它可以解释代码、总结会议、写一段方案，但它不能真的打开仓库、查询数据库、改配置、发消息、跑构建。智能体之所以成为智能体，是因为它开始具备行动能力。
这也是 MCP 和 CLI 之争真正有意思的地方。
表面上，它们都是让 AI 调用工具的方式。MCP 提供标准化协议，让外部工具用统一方式向模型“自报家门”；CLI 则把操作系统里早已存在的命令行能力交给 AI，让它用文本命令直接工作。但如果只把它们理解成两种集成方案，就会错过更重要的变化：它们代表了两种完全不同的“手”。
MCP 是一只戴着手套、带着工牌、每一步都可审计的手。CLI 是一只直接伸进现场、能临时拼装工具、也更容易碰坏东西的手。
真正的架构问题不是二选一，而是：在哪些地方需要秩序，哪些地方需要现场感。
MCP 解决的是协作秩序
MCP 的直觉很容易理解。AI 应用越来越多，工具和数据源也越来越多。如果每个模型都要为每个系统写一套适配，复杂度会很快失控。五个模型、二十个数据源，就是一百套连接逻辑。模型换了，适配重写；工具换了，适配也重写。
MCP 想解决的就是这个碎片化问题。它让工具以标准方式暴露资源、工具和提示词，让模型所在的 Host 通过 Client 与 Server 交互。工具不再要求模型读懂自己全部 API 文档，而是用一套标准格式告诉模型：我是谁，我能读什么，我能改什么，调用时需要哪些参数。
这件事的价值不只是“方便接入”。它更像是在为智能体建立一个可治理的工作场。
当 AI 代表一个用户访问 Slack、Gmail、Notion、数据库或企业系统时，问题已经不只是能不能调用成功，而是谁授权、能访问哪部分数据、能不能改写、出错后是否可追踪。对一个面向大量用户的产品来说，这些问题比单次调用效率更重要。
所以 MCP 的核心价值是秩序：身份隔离、权限边界、结构化调用、审计记录和可复用的工具描述。它适合出现在产品边界、企业边界和多人协作边界上。
代价也很清楚。MCP 的工具描述、Schema、权限模型和调用包装都会消耗上下文。工具越多，说明书越厚，模型在真正思考任务之前要先读一大段“可用工具手册”。这就是协议税。它不是小问题，因为上下文窗口在 AI 应用里不是免费的仓库，而是推理发生的工作台。工具说明塞得越满，留给任务、证据和判断的空间就越少。
但这笔税并不一定是浪费。它买到的是可控性。
如果你的智能体要服务不同用户、进入公司数据、触碰高风险操作，MCP 的啰嗦反而是一种必要成本。它牺牲了一部分现场效率，换来组织可以接受的安全边界。
CLI 解决的是现场执行
CLI 的重新变重要，看起来有点反直觉。
过去几十年，软件一直在把命令行藏起来。普通用户进入图形界面，开发者使用云控制台，企业系统有各种可视化后台。CLI 像是上一代计算机世界留下的老工具。
但对大语言模型来说，CLI 反而天然友好。
模型本来就是处理文本的系统。命令行输入是文本，输出也是文本，错误信息还是文本。相比图形界面里大量像素、按钮、状态和布局，CLI 给 AI 的信号更直接、更便宜，也更容易被组合。
这正是 UNIX 式工具在智能体时代重新获得生命力的原因。git、rg、jq、curl、kubectl、aws、psql 这些工具本来就有稳定的文本接口。AI 不需要等厂商给它开发专用 Agent API，只要有命令、权限和反馈，就能开始工作。
更关键的是，CLI 不只是一个调用入口，它是一种现场编排能力。
AI 可以先用 rg 找文件，再用 sed 看片段，再用测试命令验证，再根据报错安装依赖、修改配置、重跑构建。每一步都会产生标准输出和标准错误。错误不是对话结束，而是下一轮行动的输入。
这使 CLI 很适合研发、运维、本地自动化和一次性问题处理。它的强项不是把所有能力包装成漂亮接口，而是允许智能体在现场把小工具拼成一条临时工作流。
这也是 CLI 最危险的地方。
它太接近真实系统了。一个拥有 shell 权限的智能体，可以读很多东西，也能改很多东西。对个人开发者来说，这种效率很诱人；对企业产品来说，这种权限模型往往过于粗放。CLI 给了 AI 很大的行动自由，但很多时候也等于把风险交给了模型自己的判断力。
所以 CLI 更像一只裸手。它灵活、敏捷、触感清晰，适合在工程现场摸索、修补和创造。但当它伸向多用户数据、监管系统或不可逆操作时，就必须有额外护栏。
选择的关键不是协议，而是行动边界
如果把 MCP 和 CLI 放进同一个问题里，答案会变得清楚很多：你不是在选择一种更先进的协议，而是在选择智能体的行动边界。
可以用一个简单的判断表：
| 场景问题 | 更适合的手 | 原因 |
|---|---|---|
| 面向大量用户的 SaaS 智能体 | MCP | 需要身份隔离、授权、审计和稳定工具契约 |
| 企业内部知识库、办公系统、跨应用协作 | MCP | 组织更关心权限边界和可追踪性 |
| 本地代码重构、测试、构建、批量文件处理 | CLI | 文本反馈直接，工具组合能力强，成本低 |
| CI/CD、运维排障、数据清洗脚本 | CLI | 现场问题变化快，临时编排比预定义接口更有效 |
| 高风险写操作、合规数据、金融医疗场景 | MCP 优先 | 行动必须可授权、可限制、可审计 |
| 研发团队自己的 Agent 工具链 | CLI + 薄护栏 | 需要速度，也需要最基本的确认和回滚机制 |
| 把老系统接入 AI 工作流 | CLI 起步，必要时 MCP 化 | 先利用已有命令行接口，再把稳定能力封装成协议 |
这个表背后的原则是：越靠近产品边界，越需要 MCP；越靠近工程现场，越需要 CLI。越多人共用，越需要标准化；越像一次性问题，越需要可组合性。越不可逆，越需要审计；越探索性，越需要低摩擦。
真正成熟的智能体系统，大概率不会只选一种手。
它会在内部保留 CLI 的速度，让智能体可以探索代码、运行测试、处理文件、调用本地工具；同时在对外产品边界使用 MCP，把稳定能力封装成可授权、可审计、可复用的工具。CLI 负责发现和现场修复，MCP 负责沉淀和组织协作。
这也是一种渐进式抽象：先让 AI 用 CLI 在真实环境里跑通工作，再把反复出现、风险较高、需要共享的能力上升为 MCP 工具。不要一开始就把所有东西协议化，也不要把所有风险都交给 shell。
Agent-first 的接口应该帮助 AI 自我修复
MCP 和 CLI 共同指向一个更大的变化：接口设计正在从 API-first 转向 Agent-first。
过去 API 主要是写给人类开发者看的。文档要清楚，参数要稳定，错误码要可查。开发者读文档、写代码、处理异常。
但智能体使用接口时，重点会变成另一件事：当它失败时，能不能自己修正。
这要求工具返回的信息不只是“失败”，而是足够具体的失败原因、可选路径、权限边界、当前状态和下一步建议。CLI 在这一点上天然有优势，因为好的命令行工具通常会输出明确错误。MCP 则可以把这种反馈结构化，让智能体更稳定地理解失败。
未来好的工具接口，可能不只是给人看的文档，也不是单纯给程序调用的函数，而是一种能让智能体行动、观察、纠错、再行动的闭环。
这才是“智能体的手”真正改变软件的地方。手不是按钮数量，也不是协议名称，而是智能体能否在真实世界里形成可靠的行动循环。
如果这个循环只有自由，没有护栏，就会变成危险的自动化。如果这个循环只有秩序，没有现场感，就会变成昂贵而迟钝的集成工程。
MCP 和 CLI 的关系，正好对应这组张力。
MCP 让智能体进入组织。CLI 让智能体进入现场。
一个负责让行动变得可托付，一个负责让行动真的发生。未来更好的智能体产品，不会迷信某一种协议，而是会认真设计这两只手分别该伸向哪里、能拿什么、什么时候必须停下来等人确认。
资料来源
- 科技慢半拍：#133 MCP vs CLI｜智能体的“手”到底是什么样的？