一、一场"复古"的技术革命
在AI智能体风起云涌的今天，关于工具接口的选择引发了一场热烈的讨论。一个有趣的观点正在获得越来越多的认同：与其费力去对齐复杂的协议，不如直接回归最朴素也最强大的CLI——命令行界面。
要让智能体获得一项新能力，无论是控制智能家居、管理即时消息，还是操作云服务器，秘诀可能简单得出人意料：写一个CLI。
二、为什么智能体更倾向于CLI？
CLI对于AI智能体来说，有着天然的亲和力，主要体现在两个核心理由：
2.1 自描述的帮助文档就是最好的指令
人类觉得CLI难用，是因为人类记不住那么多参数。但对于以大语言模型为内核的智能体来说，CLI简直是量身定制的。
智能体拿到一个新工具，它会自发地运行帮助命令，而这份文档本质上就是一份零噪音、高密度、且包含示例的Prompt。在AI时代，写好帮助文档，可能比写好UI界面更重要。
2.2 Unix哲学的动作组合性
Unix哲学的核心是"只做一件事，并把它做好"，通过管道进行组合。这与智能体的思维链逻辑高度契合。
举个例子：用户指令"分析最近一周的错误日志并推送到团队群"，智能体可以通过编排几个原子化的CLI工具就能实现，不需要复杂的集成逻辑。
三、有了CLI，为什么还需要MCP？
如果你只是追求"获取数据"或"执行动作"，CLI加上JSON输出确实已经足够强大。但要构建工业级的自主智能系统，MCP拥有CLI无法替代的三个核心特征：
3.1 从"盲摸"到"自报家门"：发现机制的代差
在CLI模式下，智能体必须预先知道命令名才能使用工具。如果有1000个工具，不可能把所有命令名都塞进Prompt。
而MCP拥有标准的发现机制，Server会主动上报一份精简的"能力清单"。这是机器与机器之间的元数据对齐，效率完全不同。
3.2 从"一次性动作"到"长效资源"：抽象能力的升维
CLI的本质是"工具"——瞬时的、原子化的动作。而MCP的本质是"资源"——持续更新的数据库表、实时日志流、远程设备状态。
MCP可以为资源提供"动态提示词模板"，不仅给AI数据，还告诉AI"针对这组数据，你当前应该关注哪些风险点"。这是"数据+方法论"的打包分发方案。
3.3 安全治理：上帝权限vs零信任沙箱
CLI模式直接赋予Shell权限，相当于把"核武器"交给了智能体，可能因为幻觉顺手运行了危险命令。
而MCP采用代理架构，可以定义精细权限（只读、只写等）。而且一旦写好，可以无缝挂载到不同的编辑器和平台中。
四、该如何选择你的工具接口？
选择的逻辑其实很清晰：
选CLI模式的场景
- 快速打通物理世界——比如想让AI控制一个没有API的智能台灯或老旧软件
- 本地极速自动化——只有你一个人用，追求极致的开发效率，不在乎严格的Schema
- 记住一个原则：写个脚本就能搞定的事，别去写Server
选MCP模式的场景
- 能力标准化——你的工具需要提供给整个团队、在不同的编辑器或平台间共享
- 高风险环境——必须严格限制AI的动作边界，需要通过中间件进行审计和拦截
- 复杂数据流——涉及跨系统的结构化数据流转
五、如何为AI构建CLI？
如果你决定为AI构建CLI，这里有三个AI原生设计原则：
5.1 帮助文档就是Prompt
- 多写Examples——AI最擅长模仿，多给几个示例用法，AI出错率会直线下降
- 清晰的描述——明确每个参数的意图，特别是那些有副作用的操作
5.2 结构化输出
- 除了给人看的文本输出，务必支持JSON参数
- 让工具直接吐出JSON，方便Agent进行后续的解析和逻辑判断
- 不要让AI去费劲地解析ASCII表格
5.3 避免交互式输入
- 尽量支持非交互模式
- 不要让CLI弹出确认对话框并在那里傻等
- 提供强制确认参数，让Agent能一气呵成
六、这不是非此即彼的选择
最后要强调的是：这不是非此即彼的选择，而是各有所长的互补。
未来的终极形态可能是：
- CLI作为智能体的"肌肉"——负责执行敏捷的本地动作
- MCP作为智能体的"神经系统"——负责连接并治理复杂的分布式资源
我的实践建议是：
- 先从CLI开始——下次想给AI增加一项新能力时，先尝试写一个支持JSON的CLI
- 再考虑MCP——如果它开始变得复杂、需要被多人复用，再考虑将其封装为标准的MCP Server
- 不要过度工程化——很多时候，简单的方案就是最好的方案
七、总结
工具是肌肉，协议是神经。CLI是肌肉，让AI能够快速、灵活地执行动作；MCP是神经，让AI能够连接、治理复杂的分布式资源。
两者不是对立的，而是互补的。选择哪一个，取决于你的场景和需求。
在连接AI与现实世界的过程中，你是否也曾被复杂的协议折磨过？面对CLI的"极简力量"与MCP的"标准化契约"，你更倾向于哪种方案？
评论