大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



当AI Agent成为科技领域的热门风口，越来越多人心中会浮现一个疑问。这些能自主决策、自动完成复杂任务的智能体，明明拥有强大的AI模型作为支撑，处理的是自动化、智能化的高阶任务，和几十年前人类手动操作计算机的场景早已截然不同。人类需要可视化界面来降低操作门槛，但AI模型无需“看见”界面，理论上可以适配任何形式的接口协议。既然如此，Agent为什么没有抛开旧有的技术包袱，重新发明一套全新的接口体系，反而一头扎回了几十年前就已存在的CLI（命令行界面）呢？

其实答案并不复杂，执行者变了，任务场景变了，但接口背后的核心要求从来没有改变。动作要能明确交出去，结果要能立刻拿回来，多个动作要能无缝接起来。而CLI恰恰是最能满足这些要求的成熟方案，更重要的是，它与AI模型的底层特性天生契合，这种契合度，是任何“新发明”的接口都难以在短期内超越的。

如今我们能看到一个有趣的现象，从Anthropic的Claude Code到Google的Gemini CLI，从OpenAI的Codex CLI到国内飞书、钉钉开源的CLI工具，几乎所有主流Agent产品都将bash、zsh等CLI工具作为核心调用方式，甚至将其纳入产品的核心竞争力。Claude Code的官方文档显示，其bash工具的API额外开销仅为245个输入tokens，这是Anthropic经过大量优化后的结果，背后是对LLM上下文成本的极致考量。而Gemini CLI更直接将“原生支持bash命令串联”作为核心卖点，允许Agent通过一条命令完成从代码拉取、编译到部署的全流程。

这些顶尖科技公司明明有能力设计全新的接口协议，却不约而同地选择回归CLI，答案藏在四十年前Unix管道的设计哲学里，藏在每一代接口的迭代困境中，更藏在AI模型本身的特性、成本约束和工程实践的底层逻辑里。接下来，我们就从根源出发，一步步拆解这一现象背后的深层原因。

要理解Agent为何偏爱CLI，首先要回到1973年1月15日那个关键的夜晚。那天，Ken Thompson在Version 3 Unix中实现了pipe()系统调用，而这个看似简单的功能，背后是Doug McIlroy长达九年的奔走呼号。早在1964年，McIlroy就在Bell Labs的内部备忘录中写道：“我们应该能像接花园水管一样把程序串起来”，这句话后来成为了Unix哲学的核心思想之一，更奠定了“可组合接口”的底层逻辑。接口的价值不在于“复杂强大”，而在于“简单通用、可被无缝组合”。

Thompson实现管道后的第二天，整个Bell Labs都陷入了狂欢，McIlroy回忆那是“一场难忘的单行命令盛宴”。这场盛宴不仅重塑了人类操作计算机的方式，更为后来所有接口设计埋下了伏笔。接口的核心是“传递信息、衔接动作”，而非“追求形式上的创新”，这一理念至今依然适用。

管道的设计看似简单，却蕴含着“可组合接口”的全部基因。每个程序都有stdin（标准输入）、stdout（标准输出）、stderr（标准错误）三根“管子”，数据通过stdout传输，诊断信息通过stderr输出不污染数据管道，一个0到255的退出码则用来告知后续步骤是否可以继续。这种设计的精妙之处，在于它构建了一套“最小契约”。不需要复杂的协议约定，不需要额外的类型定义，只要遵循“文本输入、文本输出、退出码反馈”的规则，任何程序都能被串联起来。

就是这简单的设计，直接实现了cmd1 && cmd2（前一个命令成功则执行后一个）、cmd1 || cmd2（前一个命令失败则执行后一个）的组合语义，更实现了cmd1 | cmd2 | cmd3的流式串联，让多个简单工具能够组合成复杂的任务流程。而这，恰恰是AI Agent完成任务的核心逻辑，将复杂任务拆解为多个简单动作，再将动作的输出作为下一个动作的输入，形成闭环。

1986年的一个经典案例，完美诠释了这种设计的强大，更揭示了其与Agent任务逻辑的高度契合。Jon Bentley请编程大师Donald Knuth解决一个词频统计问题，统计一篇文章中出现频率最高的N个单词，忽略标点和大小写。Knuth花了数天时间，写了10页Pascal“文学编程”，代码严谨、逻辑完备，却异常复杂，普通人难以理解和修改。而McIlroy的回应只有6行Unix管道：tr -cs A-Za-z ' ' | tr A-Z a-z | sort | uniq -c | sort -rn | sed ${1}q，输出结果与Knuth的代码完全一致，且执行速度更快、可修改性更强。只要调整管道中的任意一个命令，就能实现不同的统计需求。

Knuth解决的是“如何把一个程序写到极致”，而McIlroy解决的是“如何用现成工具组合出最高效的解决方案”。这正是管道哲学的胜利，它把写程序变成了组装程序，让复杂任务可以拆解为多个简单动作的组合，而这正是AI Agent的核心工作模式。Agent不需要从零构建每一个功能，只需要调用现成的工具，通过接口将工具串联起来，就能完成复杂任务。

Eric Raymond在《The Art of Unix Programming》中，将这种思想归纳为十七条规则，其中第一条就是“组合原则”。让程序能被其他程序调用，因此程序要尽量独立，输入输出都走文本流，因为文本流是“通用接口”。它不依赖任何特定的语言、框架或平台，任何程序都能解析文本，任何程序都能输出文本。

而McIlroy在1978年发表于《Bell System Technical Journal》的文章中，更明确地提出了一个原则：“期望每个程序的输出成为另一个尚未写出来的程序的输入，不要用列对齐的格式，不要用二进制格式，不要强求交互式输入”。这句话看似是对Unix程序开发者的建议，实则精准命中了AI Agent的核心需求。Agent需要将复杂任务拆解为多个简单动作，每个动作的输出，都要成为下一个动作的输入；它不需要复杂的格式约束，只需要清晰、通用的文本交互；它不需要交互式输入，只需要明确的命令和即时的反馈。而CLI，正是这种哲学最完美的载体，它本质上就是Unix管道思想的“可视化”（文本化）呈现，每一条CLI命令，都是一个遵循“最小契约”的可组合单元。

更值得注意的是，Unix管道的设计，还暗藏了“容错性”的核心逻辑。退出码的存在，让Agent能够快速判断动作的执行结果，无需解析复杂的响应格式。比如，当Agent执行rm -rf /tmp/test时，如果退出码为0，就说明删除成功，可以执行下一步；如果退出码为1，则说明删除失败，比如文件不存在，Agent可以选择重试、跳过或终止任务。这种简单直接的容错机制，比任何新接口的“错误处理协议”都更高效，也更契合AI模型的“思考逻辑”。模型不需要理解复杂的错误码体系，只需要判断0和非0的区别，就能做出下一步决策。

Unix管道之后，随着分布式系统、跨语言开发、企业级应用的兴起，人们开始不断“重新发明接口”，试图解决更复杂的通信需求。但每一代接口的迭代，都在不断做“加法”，加类型、加版本控制、加流式、加权限、加schema，最终却往往陷入复杂度过高、实用性下降、成本飙升的困境。这些接口的失败，不在于“功能不足”，而在于“脱离了接口的核心约束”。它们追求“完美适配特定场景”，却忽略了“简单、通用、可组合”的底层需求，而这恰恰是Agent最需要的特性。

最早的一轮尝试是SOAP。2003年6月，SOAP成为W3C推荐标准，其全称原本是“Simple Object Access Protocol”（简单对象访问协议），设计初衷是解决不同语言、不同平台之间的对象通信问题。但为了实现“通用性”，SOAP不断增加特性，添加XML命名空间、支持复杂数据类型、增加安全机制、支持事务处理，最终的复杂程度，让联合设计者Don Box自己都调侃，“SOAP中的S（Simple）已经有些名不副实”。

到了SOAP 1.2版本，官方干脆把“Simple”从全称中删除，这或许是协议史上最诚实的自我否定。后来，DHH在Ruby on Rails中删除了SOAP支持，理由只有一句话：“我们觉得SOAP过于复杂，它需要太多的配置和解析工作，不符合‘简单高效’的开发理念”。对于Agent而言，SOAP的致命问题的是“解析成本过高”。Agent需要花费大量的tokens解析XML格式的请求和响应，还要处理复杂的命名空间和协议约束，这无疑会占用宝贵的上下文窗口，降低任务执行效率。

紧接着登场的是REST。Roy Fielding在2000年的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中，系统描述了REST架构风格，本意是为HTTP/1.1提供设计指南，核心是“资源导向”，通过HTTP方法（GET、POST、PUT、DELETE）操作资源。但REST很快被整个业界当成了API设计的“教条”，开发者们过度追求“RESTful规范”，添加了大量的额外约束，统一的URL命名规则、严格的状态码使用规范、复杂的资源嵌套关系，最终导致REST API变得臃肿不堪。

Fielding本人在2008年甚至专门写博客吐槽，说大多数人做的“RESTful API”，根本不符合REST的核心思想。REST的本质是“简洁、无状态”，而不是“繁琐的规范”。REST解决了SOAP协议栈的笨重问题，但又留下了新的隐患，过度获取（over-fetching）和获取不足（under-fetching）。比如一次查询一个用户信息，可能需要调用三次接口才能拿到所有需要的数据，用户基本信息、用户订单、用户权限，这对于需要高效完成任务的Agent而言，无疑会增加调用次数和token成本。

为了解决REST的痛点，Facebook在2012年推出了GraphQL。当时，Facebook的iOS应用采用HTML5包装，性能极差，Zuckerberg后来公开承认这是“最大的战略错误”。为了重建原生iOS应用，Lee Byron、Dan Schafer、Nick Schrock三人设计了GraphQL，核心是“客户端按需查询数据”。客户端可以明确指定需要获取的字段，避免过度获取和获取不足。2015年GraphQL正式开源后，迅速获得了业界的关注，成为了前端开发的热门技术。

但GraphQL的代价是服务端复杂度爆炸。服务端需要处理灵活的查询请求，需要维护复杂的schema，缓存机制也难以实现。不同的客户端可能会发送完全不同的查询请求，导致缓存命中率极低。对于Agent而言，GraphQL的问题在于“学习成本过高”。Agent需要理解复杂的schema定义，需要掌握查询语法，这无疑会增加模型的思考负担，也会消耗更多的tokens。

再之后，Google推出了gRPC。2016年8月，gRPC 1.0正式发布，其背后是Google内部每秒处理几百亿请求的Stubby系统。gRPC采用HTTP/2做传输、Protobuf做序列化，性能强劲、类型安全、支持流式传输，非常适合分布式系统之间的高频通信。但gRPC的缺点也同样明显，对浏览器不友好，需要额外的代理层，不是人类可读格式，Protobuf序列化后是二进制数据，学习曲线陡峭，需要掌握Protobuf语法和gRPC的服务定义规范。

一个有趣的冷知识是，gRPC中的“g”，每个版本都有不同的含义，从“genuine”（真正的）到“gemini”（双子座）再到“glimmering”（闪耀的），Google甚至在README中专门维护了一张命名表。这种细节上的“精致”，恰恰反映了gRPC的“复杂”。对于Agent而言，gRPC的致命问题是“无法直接交互”。Agent无法直接解析二进制格式的响应，需要额外的解析步骤，这会增加任务的复杂度和token成本。

从SOAP到REST，从GraphQL到gRPC，每一代接口都在试图解决上一代的问题，但每一次“加法”，都让接口变得更加复杂，也更加脱离“简单、通用、可组合”的核心需求。直到2024年，Anthropic推出了MCP（Model Context Protocol），试图为AI Agent重新设计一套“专属接口”。这是第一个明确针对Agent设计的接口协议，也被业内视为“最有可能替代CLI”的方案。

MCP的设计本身非常考究，Anthropic将其称为“AI领域的USB-C”，通用、高效、可扩展。它基于JSON-RPC 2.0，定义了Tools、Resources、Prompts三种原语，支持stdio和Streamable HTTP两种传输方式，能够适配本地和分布式两种场景。2024年11月发布后，MCP迅速获得了业界的关注，一年内SDK月下载量就达到了9700万，注册的MCP服务器超过一万个，2025年12月被捐给Linux Foundation旗下的Agentic AI Foundation，AWS、Google、Microsoft、OpenAI等八大科技公司均为铂金会员。这足以证明MCP的设计价值和行业认可度。

但MCP的致命问题，在于它的“token账”太难算，这也是它无法替代CLI的核心原因。Anthropic的工程博客中坦诚，在内部生产环境中，曾出现过工具定义直接消耗134K tokens的情况。要知道，Claude Sonnet 4的上下文窗口也只有200K tokens，这意味着，工具定义就占用了超过一半的上下文预算。一个Atlassian的标准MCP服务器，初始化时就会注入73个工具定义，占掉约40%的上下文预算。

也就是说，Agent还没开始干活，上下文窗口就已经被工具描述塞满了，后续的任务执行、结果反馈，都只能在剩余的上下文空间中进行，这无疑会限制任务的复杂度，也会增加模型出错的概率。Scalekit做过一项75次运行的对照基准测试，用Claude Sonnet 4跑同一组GitHub任务，结果令人震惊。查询仓库语言和许可证，CLI仅用1365 tokens，MCP却用了44026 tokens，差距达32倍；查询PR详情和审查状态，CLI用1648 tokens，MCP用32279 tokens，差距20倍；按贡献者统计合并PR，CLI用5010 tokens，MCP用33712 tokens，差距7倍。

可靠性方面，CLI实现了100%成功，而MCP的成功率仅为72%，剩下的28%均为TCP超时。这是因为MCP的协议交互更复杂，需要建立持久连接，更容易出现网络异常。换算成月成本，跑1万次操作，CLI大约需要3.2美元，而MCP则需要55.2美元，差距高达17倍。对于需要大规模部署Agent的企业而言，这种成本差距是无法接受的。

曾经是MCP早期鼓吹者的Simon Willison，在2025年10月发表了一篇文章《Claude Skills are awesome, maybe a bigger deal than MCP》，其中一句话道破了真相：“我在使用编码Agent时，已经完全不用MCP了”。他给出的理由很简单，LLM知道如何调用cli-tool --help，不需要预先花费大量tokens描述工具，模型需要的时候，自己会去查询用法。

更重要的是，CLI命令的语义是“自解释”的。gh pr list这个命令，即使没有任何预先描述，模型也能通过预训练语料理解它的含义，而MCP的工具定义，必须通过大量的文本描述，才能让模型理解其功能和参数。MCP的核心悖论就在这里，它被设计成“为Agent重新发明的接口”，但发明它的Anthropic，其自身的Agent产品Claude Code，最常用的工具依然是bash。

这不是MCP的设计不好，而是两种工具发现机制的代价结构完全不同。MCP是“预先声明式”，所有工具schema都要在对话开始前塞进上下文，无论Agent是否需要使用这些工具；CLI是“按需发现式”，需要的时候查一下帮助文档就够了，不需要预先占用上下文空间。对于上下文窗口有硬约束的LLM来说，按需发现的代价，远低于预先声明，这也是CLI能够在Agent场景中胜出的核心原因之一。

MCP的token成本过高，只是Agent回归CLI的表面原因。更深层次的原因在于，LLM和shell在结构上、本质上，是同一种东西。它们都以文本为核心，实现输入与输出的循环，不需要额外的“翻译”步骤，就能实现无缝交互。这种天生的契合度，是任何新接口都无法复制的，因为它源于LLM的底层训练逻辑和CLI的设计本质。

LLM的输入输出是token序列，本质上是一段文本往里喂，一段文本往外吐；而shell的stdin和stdout也是文本流，一串字节往里喂，一串字节往外吐。这种“文本对文本”的交互模式，让Agent无需任何额外的解析、转换步骤，就能直接调用CLI命令。Agent输出一段CLI命令，shell执行后返回文本结果，Agent再解析文本结果，做出下一步决策，形成一个闭环。

当我们把ReAct框架的动作空间和shell命令放在一起对比，就会发现惊人的相似性。ReAct论文中那种search[query]、lookup[term]、finish[answer]的动作格式，和grep query file、man term、exit 0在结构上完全一致。都是“动作+参数”的形式，都是通过文本输入输出完成交互。Agent在语言空间里思考，也只能在语言空间里发出动作，stdout作为观察结果反馈回来，再继续下一轮思考，这本质上就是一个套在LLM外面的shell循环。

Princeton和Stanford的团队做过一个极具震撼力的实验，他们开发了一个叫mini-SWE-agent的工具，只有100行代码，只用bash命令，不使用任何function calling API，不使用任何自定义工具，却在SWE-bench Verified上跑出了74%以上的成绩。这个成绩甚至超过了很多使用复杂工具调用机制的Agent。他们在项目说明中写道：“它没有任何工具，只有bash，甚至不需要使用LLM的工具调用接口”。

这个实验证明了一件事，结构化的工具调用，比如MCP、function calling，对LLM来说是后天习得的技能，需要额外的训练和引导；而文本I/O，才是它的“母语”。LLM在预训练阶段，就已经接触了海量的文本交互场景，能够自然地理解文本输入、生成文本输出，而CLI的文本交互模式，恰好契合了这种“母语能力”。

有研究表明，给一个不支持工具调用的模型添加这项能力，需要额外的有监督微调（SFT），甚至可能导致模型在其他任务上的性能下降。这种“能力迁移损耗”，是很多企业不愿承受的。另一项研究计算过训练代价，在4块A10 GPU上，用LoRA微调Qwen2.5-Coder-7B，大约需要5小时和2300个训练样本，才能获得像样的function calling能力，而微调后的模型，在文本生成、代码编写等任务上的性能，会下降5%-10%。

而shell命令，是所有代码预训练语料中天然存在的内容。GitHub上的README、Stack Overflow的回答、技术博客的教程、开源项目的脚本，到处都是git commit、docker build、kubectl get pods这样的命令，LLM在预训练阶段就已经“学会”了如何使用它们，不需要额外的训练成本，也不会产生“能力迁移损耗”。

Andrej Karpathy在2026年初提出了一个很有意思的观点，CLI之所以适合Agent，恰恰是因为它是“legacy技术”（遗留技术），训练数据里到处都是grep和sed，Agent天生就会用，不需要额外教。这个观点，完美解释了为什么Codex CLI开源后几个月就涨到六万多GitHub star，为什么Google在发布Gemini CLI时，官方博客里那句“对于开发者来说，命令行界面不仅仅是一个工具，更是家”会被反复引用。

对于Agent而言，CLI不是“遗留技术”，而是“原生技能”，它不需要花费精力去学习新的接口协议，就能直接调用CLI完成任务，这无疑会提升任务执行效率，降低开发成本。更有意思的是，MCP本身也离不开CLI，这从侧面印证了CLI的不可替代性。MCP规范中明确写道，本地MCP服务器是作为子进程启动的，通过stdin和stdout通信，说白了，为Agent“重新发明”的接口，在本地场景中，底层依然在用Unix的管道机制做传输。

有数据显示，ClawHub上注册的五千多个MCP工具中，超过70%的底层实现，就是CLI命令的JSON-RPC包装。也就是说，这些MCP工具并没有真正替代CLI，只是给CLI穿了一层协议的“外衣”，本质上依然依赖CLI的命令执行能力。比如，一个MCP工具实现“查询文件列表”的功能，底层其实是调用了ls命令，将ls的输出转换为JSON格式，再通过MCP协议返回给Agent。这种“多此一举”的操作，不仅增加了复杂度，还提高了token成本。

还有一个容易被忽略的点，CLI的“调试成本极低”。Agent在执行任务时，难免会出现错误，而CLI命令的错误信息清晰、直观，Agent可以通过stderr获取详细的错误提示，快速定位问题并修正。比如，Agent执行git push时，如果出现“permission denied”错误，stderr会直接提示“权限不足”，Agent可以立刻调用ssh-add命令添加密钥，再重新执行git push；而如果使用MCP工具，错误信息会被包装在JSON格式中，Agent需要花费额外的tokens解析错误信息，才能定位问题。这种调试成本的差异，在复杂任务中会被无限放大。

回到最初的问题，Agent为什么没有重新发明新接口？答案其实很简单，接口的形状，从来不是由执行者决定的，而是由中间层的最小契约决定的。不管执行者是1973年的shell用户、1995年写CGI脚本的后端、2015年写React Native的前端，还是2025年拿Claude Code干活的Agent，只要涉及“把任务拆给别人做”，中间层就必须满足三个核心要求，这四十多年来从未改变。这三个要求，是接口设计的“底层逻辑”，也是CLI能够胜出的根本原因。

第一个要求是动作要能明确交出去。你得有办法说清楚“我想让你干什么”，这个契约不能含糊，不能有歧义。Unix里是“命令+参数”，REST里是HTTP方法+URL，gRPC里是Protobuf的method，MCP里是JSON-RPC的tools/call，而到了Agent这里，又回到了最简洁的“命令+参数”。

CLI的命令格式清晰、语义明确，比如gh pr list就是查询PR列表，kubectl get pods就是查询Pod状态，Agent不需要复杂的解析，就能明确发出动作指令。这种“无歧义”的特性，对于AI模型来说至关重要，因为模型的“理解能力”是有限的，复杂的接口协议很容易导致模型误解指令，而CLI的简洁性，能够最大限度地减少误解。更重要的是，CLI的命令是“标准化”的，同一个命令，在不同的环境、不同的平台上，执行结果是一致的，Agent不需要考虑环境差异，就能放心调用。

第二个要求是结果要能立刻拿回来。你得知道对方干完了没、成功了没、拿到了什么，反馈必须即时、清晰。Unix里是stdout加exit code，0表示成功，非0表示失败，HTTP里是response body加status code，MCP里是tool_result，而Agent依然沿用了stdout加exit code的模式。

这种反馈机制简单直接，Agent可以根据exit code判断是否继续下一步，根据stdout获取任务结果，不需要额外的解析逻辑。比如，Agent执行docker build -t my-image .后，只要看到exit code为0，就知道镜像构建成功，直接执行docker push即可；如果exit code为非0，就可以通过stderr获取错误信息，修正后重试。这种即时反馈，能够让Agent快速调整决策，提高任务执行效率，而MCP的反馈机制，需要等待完整的JSON响应，解析后才能判断结果，耗时更长，也更消耗tokens。

第三个要求是多个动作要能继续接起来。你得能把一堆小动作组装成复杂工作流，衔接要无缝、高效。Unix里是|、&&、||原生支持，REST里需要客户端自己编排，GraphQL靠嵌套查询，MCP靠上下文窗口承载状态，而Agent再次回归了Unix的管道机制。

比如gh pr list --json number,title,author | jq '.[] | select(.author.login == "alice")'，一条命令就能完成“查询PR列表+筛选特定作者”的复杂任务，Agent只需要一次LLM调用就能完成，而如果用MCP，可能需要多次工具调用。第一次调用gh pr list工具，获取PR列表；第二次调用jq工具，筛选特定作者；还要在上下文窗口中维护中间结果，不仅耗时，还会消耗更多tokens。

更重要的是，CLI的管道机制支持“流式处理”，前一个命令的输出可以实时传递给后一个命令，不需要等待前一个命令完全执行完毕，这对于处理大规模数据的任务来说，优势尤为明显。Matt Rickard在《Unix Philosophy for AI》一文中，将McIlroy的准则改写成了LLM版本：“期望一个语言模型的输出成为另一个未知语言模型的输入”。

这句话，恰恰道出了CLI与Agent的契合点，CLI的文本流输出，完美适配了LLM的文本流输入，让多个Agent、多个工具能够无缝协作，组装成更复杂的任务流程。比如，一个Agent负责用CLI命令拉取代码，另一个Agent负责用CLI命令编译代码，第三个Agent负责用CLI命令部署代码，三个Agent之间不需要复杂的协议交互，只需要通过文本流传递结果，就能完成从代码拉取到部署的全流程。这种协作模式，简单、高效、可扩展，是任何新接口都难以实现的。

更深刻的洞察是，这三个核心要求，本质上是“效率”与“简洁”的体现。Agent的核心价值是“自动化、高效完成复杂任务”，而任何复杂的接口协议，都会增加任务的复杂度和成本，违背Agent的核心价值。CLI之所以能够满足这三个要求，就是因为它足够简洁。没有复杂的协议约束，没有多余的功能添加，只专注于“传递动作、反馈结果、衔接流程”，这种“极简主义”的设计，恰恰契合了Agent的核心需求。

看到这里，很多人可能会得出一个结论，CLI完胜MCP，MCP没有存在的价值。但事实并非如此，CLI和MCP，从来不是非此即彼的对手，而是各自有其最优适用场景。真正的分歧，不在于接口本身，而在于任务的已知性、编排的粒度和安全需求。不同的场景，需要不同的接口方案，而“CLI+MCP”的混合模式，正在成为当前Agent接口设计的最优解。

Smithery团队做过一项更细致的基准测试，756次运行的结果显示，对于Agent已经很熟悉的API，比如GitHub、Docker、Kubernetes这种在训练数据中出现过无数次的工具，CLI的优势碾压MCP。不仅token成本低、成功率高，而且调试方便；但对于Agent没见过的API，比如新加坡公交API、小众开源工具的API这种训练语料覆盖极少的工具，不带schema的盲调用成功率只有16.7%，Linear GraphQL的成功率只有41.7%，而用MCP提供类型化schema，成功率能达到100%。

这说明，CLI的优势本质上是训练语料的覆盖。模型之所以能熟练使用CLI，是因为它在预训练阶段见过大量的CLI命令；而MCP的优势，在于对未知工具的可发现性。通过schema定义，模型可以快速理解未知工具的功能和参数，无需依赖训练语料。

Port of Context的测试则揭示了第三条路，让Agent不直接调用MCP工具，而是写一段TypeScript去编排多个MCP调用，这种“Code Mode MCP”在12个Stripe API任务上，比CLI便宜56%，比原生MCP便宜78%。在复杂多步任务上，差距更为惊人，CLI需要19轮、497K tokens，原生MCP需要12轮、168K tokens，而Code Mode MCP只需要4轮、39K tokens。

这种模式的优势在于，它结合了CLI的“高效编排”和MCP的“类型安全”。Agent通过代码编排MCP调用，既避免了原生MCP的高token成本，又解决了CLI对未知工具的不足，同时还能利用MCP的类型化schema，减少调用错误。

从安全层面来看，CLI和MCP也各有优劣，这也是混合模式得以流行的重要原因。CLI给了Agent完整的shell权限，存在一定的安全隐患。Agent如果被恶意引导，可能会执行rm -rf /这样的危险命令，导致系统崩溃、数据泄露。Simon Willison提出过一个“致命三部曲”框架，当Agent同时拥有私有数据访问、不可信内容暴露、外部操作能力时，就可能成为数据窃取的载体。

CVE-2025-59536就是Claude Code的Hooks功能中，一个配置注入导致的远程代码执行漏洞，CVSS评分高达8.7。这个漏洞的根源，就是Agent拥有过高的shell权限，被攻击者利用注入恶意命令。在企业场景中，直接开放bash权限，权限管理、审计和租户隔离都很难实现。企业无法精准控制Agent能执行哪些命令、不能执行哪些命令，也无法追溯Agent的操作记录。

而MCP的OAuth 2.1和工具注解，恰恰在这方面提供了更成熟的解决方案。MCP可以通过权限控制，限制Agent只能调用特定的工具、执行特定的操作，同时还能记录每一次调用的详细日志，方便审计和追溯。

现在，越来越多的开发者和企业，都采用了“CLI+MCP”的混合模式，并且形成了清晰的分工。写代码、改配置、跑测试、查日志，全走CLI，速度快、成本低、调试方便；对接企业SaaS、查询多租户数据、需要权限审计，走MCP；如果涉及大量结构化API调用的编排，就让Agent写一段TypeScript去调MCP，也就是Code Mode MCP的路径。这种模式，既发挥了CLI的高效、低成本优势，又利用了MCP在未知工具和企业安全方面的价值，实现了“优势互补”。

Anthropic自己的实践，也印证了这种混合模式的合理性。Claude Code采用的是“Skills+Bash+MCP”的混合栈，Skills负责提供特定任务的指导和脚本，帮助Agent更好地完成复杂任务；Bash负责本地命令执行，处理日常的代码开发、系统操作等任务；MCP负责外部工具集成，对接企业SaaS、小众API等Agent不熟悉的工具。

这种组合，既解决了CLI对未知工具的不足，又解决了MCP的高token成本问题，成为了当前Agent接口设计的最优解。更重要的是，这种混合模式不是“固定不变”的，随着Agent技术的发展，开发者可以根据任务需求，灵活调整CLI和MCP的使用比例，实现“成本、效率、安全”的平衡。

还有一个值得关注的趋势，CLI本身也在进化，正在吸收MCP的优势，变得更加“智能”。比如，一些开源项目推出了“智能CLI工具”，能够自动生成CLI命令、解析命令输出、提供错误修复建议。这些工具本质上是将LLM与CLI结合，让CLI不仅具备“可组合”的优势，还具备“可发现”的能力。比如，当Agent不知道某个CLI命令的用法时，智能CLI工具可以根据Agent的需求，自动生成对应的命令，甚至提供参数说明，这在一定程度上弥补了CLI对未知命令的不足。这种“CLI+LLM”的进化方向，进一步巩固了CLI在Agent场景中的核心地位。

Agent没有重新发明新接口，不是因为缺乏创新能力，而是因为接口背后的核心约束，四十多年来从未改变。动作明确、结果即时、步骤可组合，这三个要求，是所有接口设计的“底层逻辑”，无论执行者是人类还是AI，无论任务是简单的文件查询还是复杂的企业自动化，这个约束都不会改变。Unix管道在四十年前，就已经完美满足了这些约束；而CLI，作为Unix管道思想的载体，自然成为了Agent的最优选择。

MCP、REST、GraphQL、gRPC这些接口，虽然各有创新，但它们都是在“变量”上做文章。在特定场景下优化性能、完善功能、提升安全性，却没有触及那个最稳定的约束本身。而Agent的回归，本质上是对这种底层逻辑的回归，不是复古，而是找到最适合自身特性的解决方案。这种“回归”，不是放弃创新，而是一种更理性、更务实的创新。它不追求形式上的“新”，而是追求本质上的“适配”，让接口服务于任务，而不是让任务迁就接口。

在科技快速迭代的今天，我们总是热衷于追逐“新事物”，总以为“新的就是好的”，却常常忽略了那些经过时间检验的“旧智慧”。CLI的生命力，不在于它的“旧”，而在于它抓住了接口设计的本质，简洁、通用、可组合。它没有复杂的协议，没有多余的功能，却能完美满足Agent的核心需求；它没有被时代淘汰，反而在AI Agent时代焕发了新的生机，这背后，是对底层逻辑的深刻洞察。

对于AI Agent来说，回归CLI，不是放弃创新，而是站在巨人的肩膀上，更高效地实现智能化任务。它让Agent能够利用预训练的“原生技能”，无需额外学习新的接口协议，就能快速调用工具、完成任务；它让Agent能够通过管道机制，无缝组合多个工具，实现复杂任务的自动化；它让Agent能够以最低的成本、最高的效率，完成从代码开发到系统部署的全流程。

未来，随着Agent技术的不断发展，或许会出现新的接口形态，或许MCP会通过schema过滤、Code Mode等优化，缩小与CLI的差距，或许CLI会进一步吸收MCP的优势，变得更加智能、更加安全。但无论如何，“动作明确、结果即时、步骤可组合”这个核心约束，永远不会改变。