忘掉 MCP?OpenClaw 作者说:CLI 才是 AI 连接世界的终极接口

本文永久链接 – https://tonybai.com/2026/02/04/openclaw-author-cli-ultimate-agent-interface-vs-mcp
大家好,我是Tony Bai。
如果回望 2025 年上半年,AI 圈最火的技术关键词无疑是 MCP (Model Context Protocol)。彼时,行业内满怀希望地为智能体定义 Schema,构建 JSON-RPC 服务,试图为 AI 打造一套标准化的能力连接协议。
然而,时间来到 2026 年初,技术圈的热点正在悄然发生偏移。
最近,一个名为 OpenClaw(其前身是火遍全网的 Moltbot/Clawdbot)的开源项目,用一种极其“复古”的方式给所有人上了一课。其作者 Peter Steinberger 提出了一个极其犀利的观点:与其费力去对齐协议,不如直接回归 CLI(命令行)。
在 OpenClaw 的世界里,要让智能体获得一项新能力——无论是控制智能家居、管理 WhatsApp 消息,还是操作云服务器——秘诀只有一个:写一个 CLI。
作者发现,只要有一个带有 –help 的工具,智能体就能自发掌握它。在经历了一整年的协议崇拜后,这种“低摩擦”的命令行工具,是否才是智能体操作现实世界的最佳方案呢? 在 GUI 为了人类进化了 40 年后,CLI 是否正在因为 AI 而迎来一场“文艺复兴”?它会是 AI 连接世界的终极接口吗? 在这篇文章中,我们就来简单探讨一下。

语义对齐:为什么智能体更倾向于 CLI?
智能体(Agent)和人类不同,它不需要精美的图形界面(GUI),它需要的是能够被理解的逻辑边界。
自描述的帮助文档即“自然语言指令”
人类觉得 CLI 难用,是因为人类记不住参数。但对于以 LLM 为内核的智能体来说,CLI 简直是量身定制的。
智能体拿到一个新工具 my-tool,它会自发运行 my-tool –help。这份吐出的文档,本质上就是一份零噪音、高密度、且包含示例(Few-shot)的 Prompt。智能体不需要任何预配置,在阅读文档后的那一秒,它就学会了如何操作这个工具。 在 AI 时代,写好 –help 文档,比写好 UI 界面更重要。
Unix 哲学的“动作组合性”
Unix 哲学的核心是“只做一件事,并把它做好”,通过管道(Pipe)进行组合。这与智能体的思维链(Chain of Thought)逻辑高度契合。
用户指令:“分析最近一周的错误日志并推送到飞书。”
智能体决策: log-fetch –days 7 | grep “ERROR” | feishu-send –channel #ops
智能体不需要你编写复杂的集成逻辑,它只需要像玩积木一样,通过编排/串联原子化的 CLI 工具就能实现复杂的自动化目标,这就是涌现能力的来源。
深度辨析:有了 CLI,为什么我们依然需要 MCP?
在实际开发中,你可能会产生怀疑:“既然 CLI 也能输出 JSON 结果,也能实现逻辑复用,那 MCP 的护城河到底在哪里?”
这正是架构师最容易产生误区的地方。如果你只是追求“获取数据”或“执行动作”,cli –json 确实已经足够强大。但要构建工业级的自主智能系统(Agentic System),MCP 拥有 CLI 无法替代的三个核心特征:
从“盲摸”到“自报家门”:发现机制的代差
- CLI 模式: 智能体必须预先知道 ls、grep 这些命令名。如果你的系统环境里有 1,000 个工具,你不可能把所有命令名都塞进 Prompt,这会导致严重的 Context 溢出和注意力稀释。
- MCP 模式: 拥有标准的 Discovery(发现)机制。当智能体连接到一个 MCP Server 时,Server 会主动上报一份精简的“能力清单”。这是机器与机器之间(M2M)的元数据对齐,比智能体在 Shell 里“瞎撞”要高效且精准得多。
从“一次性动作”到“长效资源”:抽象能力的升维
- CLI 的本质是“工具(Tools)”: 它是瞬时的、原子化的动作。
- MCP 引入了“资源(Resources)”: 它能将一个持续更新的数据库表、一个实时日志流、甚至一个远程设备状态抽象为一个 URI。MCP Server 还可以为这些资源提供“动态提示词模板”,它不仅给 AI 数据,还告诉 AI “针对这组数据,你当前应该关注哪些风险点”。这种“数据 + 方法论”的打包分发方案,是 CLI 无法实现的。
安全治理:上帝权限 vs. 零信任沙箱
- CLI 的风险: 赋予智能体 Shell 权限意味着你把“核武器”交给了它。它可能在修复 Bug 时,因为一个幻觉顺手运行了 rm -rf /。
- MCP 的护城河: 它是代理(Proxy)架构。
- 精细权限: 你可以定义此 Server 只能 Read 资源,严禁任何写操作。
- 跨宿主复用: 你的 MCP Server 一旦写好,可以无缝挂载到 Claude 网页版、Cursor、甚至自建的机器人中,无需在对应宿主机上安装任何二进制程序。这种“即插即用”的可移植性和安全性,是传统 CLI 无法比拟的。
实战决策:该如何选择你的工具接口?
在构建 AI Agent时,建议遵循以下选型逻辑:
-
选 CLI 模式的场景(个人/Hack 模式):
- 快速打通物理世界:比如你想让 AI 控制一个没有 API 的智能台灯或老旧软件。
- 本地极速自动化:只有你一个人用,追求极致的开发效率,不在乎严格的 Schema。
- 原则:“写个脚本就能搞定的事,别去写 Server。”
-
选 MCP 模式的场景(企业/生产模式):
- 能力标准化:你的工具需要提供给整个团队、在不同的编辑器或平台间共享。
- 高风险环境:必须严格限制 AI 的动作边界,需要通过中间件进行审计和拦截。
- 复杂数据流:涉及跨系统(如 飞书文档 到 PostgreSQL)的结构化数据流转。
OpenCraw 的聪明之处在于:它避开了复杂的协议之争,用 CLI 解决了 AI “手脚”的问题,让 Agent 能够真正触碰到现实世界。
实战启示:如何为 AI 构建 CLI?
既然 CLI 这么重要,作为开发者,我们在编写 CLI 工具时需要注意什么?
答案是:AI-Native Design(AI 原生设计)。
1. Help 文档即 Prompt
以前写 Help 是给人看的,现在是给 AI 看的。
- 多写 Examples: AI 最擅长模仿。多给几个 Example usage,AI 出错率会直线下降。
- 清晰的描述: 明确每个参数的意图,特别是那些有副作用的操作(如 –force)。
2. 结构化输出
除了给人看的文本输出,务必支持 –json 参数。
Agent: aws ec2 describe-instances –output json
让工具直接吐出 JSON,方便 Agent 进行后续的解析和逻辑判断,而不是让 AI 去费劲地解析 ASCII 表格。
3. 避免交互式输入
尽量支持非交互模式(Non-interactive)。不要让 CLI 弹出一个 Are you sure? (y/n) 并在那里傻等。提供 -y 或 –yes 参数,让 Agent 能一气呵成。
小结:工具是肌肉,协议是神经

OpenClaw 的成功,是“奥卡姆剃刀原则(简单优先)”的胜利。它提醒我们不要过度工程化,如果一个简单的 CLI 就能连接世界,就不要去折腾复杂的协议。
但 MCP 的价值,在于它为智能体建立了一套可治理的“契约”。
未来的终极形态可能是:CLI 作为智能体的“肌肉”,负责执行敏捷的本地动作;而 MCP 作为智能体的“神经系统”,负责连接并治理复杂的分布式资源。
下次你想给 AI 增加一项新能力时,先尝试写一个支持 –json 的 CLI。如果它开始变得复杂、需要被多人复用,再考虑将其封装为标准的 MCP Server。
你的“接口”首选
在连接 AI 与现实世界的过程中,你是否也曾被复杂的协议折磨过?面对 CLI 的“极简力量”与 MCP 的“标准化契约”,你更倾向于哪种方案?你所在的团队是否已经开始实践“AI 原生 CLI”的设计?
欢迎在评论区分享你的架构思考或避坑经历!让我们一起定义 AI 时代的交互标准。
如果这篇文章为你拨开了协议之争的迷雾,别忘了点个【赞】和【在看】,并转发给你的架构师朋友,帮他少走弯路!
还在为“复制粘贴喂AI”而烦恼?我的新专栏 《AI原生开发工作流实战》 将带你:
- 告别低效,重塑开发范式
- 驾驭AI Agent(Claude Code),实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码,开启你的AI原生开发之旅。

你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?
- 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
- 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
- 想打造生产级的Go服务,却在工程化实践中屡屡受挫?
继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。
目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

© 2026, bigwhite. 版权所有.
Related posts:
评论