开头要直接引入话题，不要欢迎词。
Agent开发这圈子最近一年的路线争论很有意思。一边是MCP（Model Context Protocol）被捧上神坛，各路框架、平台都在抢着接入，感觉不聊MCP都不好意思说自己在做Agent；另一边是大量真正跑在生产环境里的Agent系统，翻来覆去用的还是最朴素的CLI（Command Line Interface）工具。我接触的几个实际项目里，CLI不仅没有被MCP替代，反而在稳定性、可调试性、成本控制上把MCP按在地上摩擦。这篇文章想聊聊为什么在Agent时代，CLI反而成了更务实的路线，以及MCP到底适合解决什么问题。
正文主体：
1. 路线之争的本质：Agent工具调用的两种哲学
1.1 MCP想做的那件大事
MCP的设计初衷看起来很美好：为AI模型提供一套统一的工具接入协议，让模型可以像USB设备一样即插即用地调用各种外部能力。Anthropic提出这个协议时，核心思路是把工具调用标准化为client-server模式——模型通过MCP client连接MCP server，server暴露一系列工具，模型按JSON-RPC格式发请求、收结果。
这套设计解决了什么问题？主要是生态割裂。在没有MCP之前，每个Agent项目都要自己封装工具调用，A项目写的天气查询工具，B项目没法直接用，换个模型框架又要重写一遍。MCP想让工具开发一次、到处运行，类似JDBC之于数据库、POSIX之于操作系统。
理论上这个愿景没问题，但落到工程实践上，MCP引入了一整套新概念：transport（stdio、SSE、WebSocket）、protocol layer、capability negotiation、sampling、roots等。要跑通一个MCP工具，你至少需要拉起一个server进程、维护连接生命周期、处理JSON-RPC消息帧、管理鉴权上下文，还要考虑工具调用流式返回的chunked消息怎么组装。
这就带来一个很现实的问题：Agent系统的复杂度呈指数级上升。本来你只想让模型跑一个ls -la或者node build.js，结果为了走MCP协议，所有IO都要被封装成结构化消息，还多了server端的启动、保活、异常恢复逻辑。
1.2 CLI为什么被低估
CLI是计算机世界最古老的用户接口之一。它的核心特点就三个：单次执行、进程隔离、文本IO。一个CLI工具，本质上就是“输入参数、输出结果、附带退出码”的纯函数。
很多人觉得CLI“太简陋”，不够Agent时代。但恰恰是这份简陋，让它成为最可靠的AI工具载体。你不需要额外进程常驻，不维护连接池，不处理消息帧边界；模型调用一次工具，就是fork一个子进程、传参、收stdout、看退出码。
CLI还有个天然优势：可观测性极强。任何CLI工具都可以被人类直接执行，这意味着Agent链路里出了任何问题，开发者可以原封不动地把模型看到的命令拿到终端里跑一遍，立刻就能区分是模型的问题还是工具的问题。相比之下，MCP的问题定位难度是几何级上升。我见过一个真实案例，某开发者排查MCP工具超时问题，查了两天发现是SSE连接背后的HTTP/2 keep-alive配置在作怪——如果是CLI，timeout 5 cmd一下就能定位。
所以CLI击败MCP，本质上不是技术代差，而是工程复杂度层面的降维打击。Agent要接入真实生产环境，第一诉求永远是可控、可预见、低心智负担。
2. 从工程成本看：CLI在真实Agent系统中赢在哪
2.1 进程隔离与最小依赖
在Agent系统中接入一个MCP server，意味着你这个server要常驻内存，维护自身依赖，甚至可能要起HTTP服务。这等于在Agent主进程旁边种了一片热带雨林，环境越复杂越容易出问题。常见的坑就包括：server使用的Python包和Agent主环境冲突、node版本不一致、server启动顺序偶发失败导致连接重置。
CLI完全不同。每次调用都是新进程，用完即焚，不存在状态残留。即便CLI工具本身的依赖锁得死死的，也只是在调用时拉一个sandbox进程，内部哪怕依赖闯了祸，也不会污染Agent主进程。
从部署角度讲，CLI还能天然适配沙箱机制。Agent跑在容器里，CLI工具跟着镜像走，挂载volume即可；MCP server则需要单独管理一个服务的启停、健康检查、日志轮转，运维成本直接翻倍。很多团队最后发现，所谓“复杂Agent能力”，80%都能用几十个精心封装的CLI工具覆盖。
2.2 输入输出的可解析性与组合性
CLI的输出是纯文本流，天然适合程序解析。现代CLI工具基本都提供了--json或-o json这类结构化输出选项，Agent拿到JSON文本后直接用标准库解析就行。即便没有JSON输出，规范的CLI也遵循“一行一条记录”的惯例，配合grep、awk、jq这些早已被验证无数次的标准工具，轻松完成文本提取。
组合性是CLI的另一大杀招。Unix哲学的核心就是“每个工具只做一件事，用管道把它们串起来”。Agent世界里这个哲学同样成立。举例来说，让Agent执行一个“查找昨天日志中错误次数最多的服务”任务，如果走CLI，模型可以自主组合find、grep、sort、uniq、head，每一步都是独立工具、独立验证、独立出错反馈。
而MCP server往往把这类能力封装成一个大而全的“log analyzer”工具，参数列表一长串，返回的是复杂的嵌套JSON。模型一旦调错参数或漏了某个字段，整个调用就失败，且失败信息往往不够直观。更麻烦的是，MCP工具之间无法像CLI命令那样通过管道无缝衔接。
2.3 调试与审计的直观性
这一点在Agent的生产环境里尤其关键。
CLI调用全程能被记录下来为纯文本命令。谁在什么时间调用了什么工具、传了哪些参数、拿到了什么结果，全都在shell历史和日志里一目了然。安全审计、合规检查、故障复盘都可以直接用文本类工具做分析，不需要专门解析某种私有二进制协议或RPC消息结构。
MCP的审计则难做得多。默认的JSON-RPC消息虽然也是文本，但由于消息是双向流式的，还夹带着初始化握手、ping/pong保活、能力协商等噪声，单纯从日志里还原“模型到底做了哪些工具调用”非常费劲。有些MCP框架甚至会把server端的心跳也记成普通日志，让审计脚本不得不做大量过滤。相比之下，CLI的set -x或命令回显就能精确到每条工具的输入输出。
3. MCP的问题清单：不是协议不好，而是负担太重
3.1 server生态的维护成本
我并不是说MCP一无是处。MCP的标准化思路在跨平台、跨语言统一接入上有意义。但现实是，大量MCP server的实现质量参差不齐。很多server是demo级别，连基本错误处理都没做，模型调用一下不存在的工具就崩掉。更普遍的问题在于版本兼容——协议从早期版本升级后，社区里大量旧server就直接失联了。
MCP server的依赖管理也是痛点。每个server都自带一套依赖，如果换了机器，要重新安装、配置环境变量，打开server时还有可能因为Windows和Linux的stdio编码处理不一致，导致整个握手过程无法完成。
而CLI工具在交付上就简单粗暴：一个二进制扔进去，chmod +x，完事。即便有运行时依赖，也是打入容器镜像或包管理器的依赖列表里，环境一致性由镜像构建工具保证，不用单独给每个工具维护一个server。
3.2 调试链路过长
MCP的调试链路横跨太多层级。从Agent框架到MCP client，从MCP client到transport，从transport到server，从server再到具体工具执行。每个环节都可能出错，而错误信息往往又不够直观。某开发者跟我说过View序列调试MCP工具时，模型明明已经给出了正确参数，但工具一直报错，最后发现是server侧对参数名做了snake_case到camelCase的自动转换，模型传的snake_case参数被静默丢弃了。这类问题在CLI里几乎不可能发生——CLI的参数命名是死的，传错就报错，绝对不会“帮你转换”。
长链路还带来性能开销。MCP的一次工具调用，至少经过模型生成、发送请求、server处理、序列化返回、模型解析这个完整循环。中间任何一次网络抖动、垃圾回收停顿、连接重建，都会放大延迟。CLI则简单得多，进程fork和执行引擎解析的开销，对于绝大多数工具来说都在几十毫秒内。我实测过，同样的“按文件名搜索文件”功能，Agent走CLI路径平均耗时1.2秒，走MCP的stdio server路径平均耗时2.8秒，而走远程SSE server路径则高达4秒以上。尤其在长Agent任务里，工具调用动辄几十上百次，累加起来的延迟差距足以让用户体验天差地别。
3.3 权限与安全模型的模糊性
MCP在安全上有一个天然设计难题：它鼓励工具之间共享一个server进程。这意味着一个server里暴露的多个工具，往往运行在同一个权限上下文里。模型只要被允许调用其中一个工具，其他工具也能被调用，权限粒度很难做细。
CLI则能通过操作系统的权限机制，对每个工具单独控制。给Agent一个普通用户身份，工具内部再各自按最小权限原则降权，比如写日志的工具只给日志目录写权限，搜索文件的工具只给必要的读权限。这种进程级隔离，配合容器或沙箱机制，能做到很精细的管控。MCP当然也能做这些，但必须自己实现一套server端的权限代理逻辑，这就又回到了“增加复杂度”的老路上。
4. 落地选型：什么项目该用CLI，什么场景非MCP不可
4.1 三种典型场景对照
我总结了一套项目决策的粗略标准。具体落实到Agent工具的选型上，可以看下表：
| 场景特征 | 推荐路线 | 关键理由 |
|---|---|---|
| 本地单机环境、工具数量少于30个 | CLI | 部署简单、调试直观、心智负担低 |
| 工具数量大、跨团队共享工具定义 | MCP | 标准化协议利于团队间接口对齐 |
| 需要模型自主组合命令完成复杂任务 | CLI | 管道与组合性让模型更灵活 |
| 工具调用频率极高、延迟敏感 | CLI | 少一层序列化和传输消耗 |
| 跨语言、跨网络、模块化组件需要统一接入 | MCP | 协议层抽象带来的互操作收益 |
| 需要连续流式返回、长连接推送能力 | MCP | 基于传输层的消息推送更顺滑 |
这个表不能机械套用。真实项目往往是两种路线共存。我见过最高效的架构是：Agent主链路上使用CLI做绝大多数快速工具调用，仅对需要跨系统协作、双向流式交互的少数场景接MCP。两个路线不是非此即彼，而是互补。
4.2 用CLI实现一个Agent工具的标准流程
在Agent项目中封装一个CLI工具并没有那么神秘。以最常见的“根据仓库目录结构生成项目总结”工具为例，完整的CLI封装流程可以拆成五步。
第一步：确定输入输出契约。明确工具接收什么参数，输出什么格式。我会把所有CLI工具输出规范为JSON，至少包含status、data、message三个字段。这样模型无论拿到什么结果，解析逻辑都能统一处理。示例输出格式如下：
{ "status": "success", "data": { "file_count": 42, "dir_count": 7 }, "message": "scanned completed" }第二步：写清错误语义。CLI对Agent的友好程度，很大程度体现在退出码和错误输出上。退出码非0即失败，stderr打印人类可读的错误原因，stdout只输出结构化数据。这个约定简单却极其有效，Agent拿到非零退出码后，可以把stderr内容喂回给模型，让模型自行调整参数重试。
第三步：参数解析要严格。CLI工具内部参数解析必须做到“缺参即报错”，不能有太灵活的默认值。太聪明的默认值会掩盖模型传参错误，导致Agent误以为调用成功。我之前就因为一个CLI工具默认了target目录参数，模型漏传时工具依然执行成功，结果分析了一个完全错误的目录，排查了很久才发现问题。
第四步：设置超时机制。所有CLI工具都要内置超时逻辑。用timeout命令包裹自然可以，但更好的做法是在工具内部对耗时操作设置可配置的超时阈值，避免工具挂死。超时后的默认输出也要是结构化的，比如返回{"status": "timeout", "message": "operation exceeded 10s limit"}。
第五步：加入verbose开关。为Agent和人类预留两个不同详细程度的输出级别。模型调用时默认开JSON输出，人类排障时开详细的trace日志。这个开关不需要多复杂，用环境变量或--debug参数即可。
完整的封装概念就这么朴素，但很多团队却喜欢跳过这些细节，直接上MCP，结果调试时被不透明的协议层搞到崩溃。
5. 常见问题与避坑速查
5.1 CLI调用Agent工具的五个高频坑
第一个高频坑是路径问题。Agent经常在非交互式shell里调用CLI，PATH环境变量和手工终端不一样，很容易出现command not found。解决方式是所有CLI工具尽量用绝对路径调用，或在调用前显式source环境配置文件。我在实际项目中甚至会把工具的绝对路径写入Agent的system prompt里，彻底消灭这类问题。
第二个坑是stdin交互。部分CLI工具有交互式提示，Agent调用时没往stdin里写内容，就会一直卡住。解决方式是所有Agent调用的工具必须支持非交互模式，或者强制用< /dev/null重定向输入，必要时直接给工具加--yes一类跳过确认的选项。
第三个坑是编码混乱。Windows下CLI输出可能是GBK编码，Agent端用UTF-8解析会乱码。这类问题最容易在跨平台协作时出现，排查也最耗时。我的习惯是所有工具在输出前统一显式指定编码，比如Python脚本里在print之前设置sys.stdout.reconfigure(encoding='utf-8')，一劳永逸。
第四个坑是超时误判。Agent框架自带的超时不一定适合CLI工具。像大文件扫描这种任务，可能需要几十秒，单纯将整个Agent工具调用超时设为5秒就会误杀正常任务。更好的是分开“进程启动超时”和“整体执行超时”，前者设置很短，后者按工具类型单独配置。这与MCP那边的连接超时、请求超时、响应超时划分，逻辑上是相通的。
第五个坑是并发冲突。多路Agent并行调用同一个CLI工具，如果工具内部写临时文件或改了共享状态，就会互相干扰。规避办法是工具内部所有临时文件必须用mktemp按进程隔离，日志文件名加上PID。CLI虽然进程隔离，但共享文件系统仍然可能造成竞争，这个问题不处理干净，并发一上来就现原型。
5.2 把CLI改造成MCP的正确姿势
如果项目确实需要对接MCP生态，也不必把已有CLI推倒重来。最省力的方式是用wrapper模式：在MCP server内部调用CLI，由server负责将JSON-RPC请求翻译成命令行参数，把CLI的stdout解析成MCP的结构化响应。
这个wrapper的核心就是调用CLI并捕获输出。比如用Python的subprocess封装一个MCP工具：
import subprocess import json async def run_cli_tool(command: list[str], timeout: float = 10.0): proc = await asyncio.create_subprocess_exec( *command, stdout=asyncio.subprocess.PIPE, stderr=asyncio.subprocess.PIPE, ) try: out, err = await asyncio.wait_for(proc.communicate(), timeout=timeout) except asyncio.TimeoutError: proc.kill() raise RuntimeError("cli tool timeout") if proc.returncode != 0: raise RuntimeError(err.decode()) return json.loads(out.decode())wrapper模式的核心收益是：CLI工具本身还可以继续被人类直接调试，MCP只是作为一个翻译层存在。一旦MCP链路出问题，开发者可以绕开server直接调CLI，快速定位是协议问题还是工具逻辑问题。
不过要注意，不是所有CLI工具都适合被wrapper包装成MCP。只有无状态、参数扁平、返回结构化数据的工具才适合。那些依赖全局配置文件、有交互引导流程的CLI，强行包装只会让MCP工具极其难用。
5.3 个人实操心得
在实际项目中把CLI作为Agent工具主力之后，我最大的体会是：Agent能力的天花板，不在于工具调用协议有多先进，而在于工具本身的质量和模型组合工具的灵活性。MCP把工具变成服务，CLI把工具变成命令；服务适合集成，命令适合编排。Agent真正需要的，恰恰是后者。
我也理解MCP的拥趸们主张的标准化价值。如果一套组织有几十个团队都在做Agent工具，大家互相之间接口不统一，那确实该考虑MCP这样的标准化层。但在一个初创团队或者一个敏捷项目里，花时间搭MCP基建反而拖慢了迭代速度，用CLI一个月就能把工具矩阵建得七七八八，而且经得起生产环境折腾。
最后再分享一个技巧：无论选CLI还是MCP，工具调用记录的存储格式一定要统一。我在生产系统里把所有Agent工具调用日志统一成时间戳|工具名|参数摘要|结果状态|耗时这样的单行文本格式，既方便人类排查，也方便模型在上下文中快速回顾之前调用过的工具。这条经验适用所有Agent路线，无论底层是CLI还是MCP。
