最近我用飞书 CLI飞书的命令行工具一行命令导入了几百条数据到多维表格还能在飞书里直接用它画逻辑图用 OpenCLI可以自动抓取网站数据。不只是这些。每天用的 Agent 工具写代码、跑任务、操作各种软件它们的执行入口几乎都落在了命令行上或者至少借用了 CLI 这套执行范式。命令行一个 1970 年代就有的界面。2026 年了最前沿的 AI 公司在用它最主流的办公软件也在往这个方向走。为什么一个 50 多年前的东西会被 Agent 时代重新选中为了解释这个问题我从头学习了它的整个逻辑怎么来的为什么是这个结构为什么现在又被选中我花了一整周时间把脉络捋清楚。如果把这个问题压成一句话其实就是在问三件事CLI 在软件世界里到底站在哪一层它为什么会在 Agent 时代重新变重要以及它现在正在被重新设计成什么样。CLI 最早要解决的不是界面体验而是让人把命令准确交给机器很多人今天一提到 CLI脑子里先出来的是黑窗口、程序员、专业工具于是很容易把它理解成一种不够友好但更高效的界面。但如果回到它最早出现的现场就会发现它一开始面对的根本不是体验优化问题而是一个更基础的问题人怎么把命令清楚地交给机器。CLI 是Command-Line Interface的缩写中文就是命令行界面。这一段不单单是为了补一段计算机史而是为了回答一个今天的问题为什么 Agent 没有重新发明一套新接口而是又重新撞上了 CLI如果把过去和现在并排看会更容易看清这件事执行者变了题材变了但中间这层要求没有变动作要能明确交出去结果要能立刻拿回来多个动作要能继续接起来。更早的人机交互——打孔卡、纸带、开关面板——能把信息送进机器但反馈不会立刻回来更谈不上持续来回交互。直到终端和电传打字机出现人和机器之间才第一次形成了输入一句立刻看到结果的实时回路。也正是在这个节点上问题才真正升级成既然现在可以实时交互了人到底该怎么把动作清楚地表达给机器CLI 就是在这个问题下成形的。最自然的办法就是把要做的动作压成一行命令也就是命令词 参数 对象。这件事听起来简单但它把一个关键结构固定了下来CLI 是命令文本不是能力本身。它负责把动作交给程序再由程序去调用底层能力。这也让 CLI 很早就具备了三个一直没失效的能力把动作明确交出去把反馈立刻拿回来把多个动作继续接起来。后来 GUI图形用户界面出现了。对普通人来说按钮、窗口、图标和菜单都比记命令轻松得多。人更擅长视觉识别不擅长回忆精确字符串很多状态如果能直接看见也比靠文字想象更容易。所以 GUI 真正解决的是降低操作门槛、把状态直接展示出来、让更多非技术用户也能使用计算机。它替代的是 CLI 的前台位置不是它的结构优势。CLI 更像先想清楚再输入GUI 更像先看见再操作。前者不一定更友好但它在动作表达“结果返回”步骤串联这三件事上一直更强。这也是为什么到了 GUI 时代CLI 并没有消失。git这样的工具直到今天仍然主要运行在命令行上。普通用户把计算机前台交给了 GUI专业世界却一直把连续动作和组合动作交给 CLI。如果要用三个证据把这段历史收住可以记三个名字rm说明 CLI 最基础的结构就是命令 参数 对象从 1970 年代到现在没变过。Unix说明 CLI 为什么能活这么久。不是因为没人想替代它而是因为 Unix 给了它一套生存哲学文本进、文本出每个命令只做一件事命令之间可以接起来。git说明 GUI 时代来了以后CLI 并没有死。它在专业世界里一直承担连续动作和组合动作。这段历史说明的不是CLI 很古老而是它从一开始就是执行层。Agent 时代为什么又轮到 CLI理解了 CLI 最早是怎么被逼出来的再回头看今天的软件世界就会发现两个方向正在往同一个地方收敛。一边是模型侧。Anthropic 把 Agent 的执行入口落在了 CLI做出了Claude Code随后 OpenAI 的Codex CLI、Google 的Gemini CLI也都沿着这个方向推进。另一边是软件侧。平台能力开始被重新包装成命令入口飞书有飞书 CLI网页和平台能力被 OpenCLI 这类项目重新翻译成命令。两边最后都落在 CLI不是巧合而是因为软件世界里多了一个新的行动者Agent。过去的软件结构大致是人通过 GUI 或 CLI 操作软件。现在慢慢变成人提出目标Agent 拆任务、执行、修正。Agent 不是聊天机器人它是一个真正要把动作做出去、把结果拿回来的执行者。一旦执行者从人扩成人 Agent最先被重新摆上桌面的就不是聊天能力而是执行层怎么组织。因为 Agent 一真正开始干活立刻会碰到四个问题命令怎么送进软件执行结果怎么拿回来出错以后怎么继续修正多个动作怎么接成一条链CLI 恰好就是最成熟的答案——不是因为它最新而是因为它在这四件事上积累最深。下面展开说。先理清CLI 和 API 不是一回事很多人会把 CLI 和 API 混在一起说。其实两者站位不同。APIApplication Programming Interface应用程序接口是软件能力的原始接口。比如飞书把读写表格、发消息、管理文档这些能力开放成 API供其他程序调用。CLI 往往是 API 上面的一层包装。它把鉴权、参数拼装、分页、错误处理这些复杂细节封装掉最后对外暴露成一条命令。但 CLI 又不总是 API 的包装。像rm、ls、cp这类命令背后直接连的是本地操作系统不需要远程 API。所以更准确的说法是CLI 站在能力层上面把能力包成一条条可执行的命令。这个能力层可以是远程 API也可以是本地程序。为什么 Agent 的执行层会先收敛到 CLI这里先只看执行层先不把 MCP 放进来。因为这一节要回答的问题很具体当 Agent 真正要把动作做出去时为什么常常先落到 CLI而不是 GUI 或裸 API如果只看执行层可选接口大致有三个GUI、裸 API、CLI。原因有三个。第一CLI 卡在 GUI 和裸 API 中间位置刚好。GUI 对人友好对 Agent 却很别扭。人看按钮一眼就知道该点哪里Agent 要操作 GUI通常得先截图、识别界面、定位元素、再模拟点击。视觉理解成本高链条也容易断。裸 API 则是另一种极端。能力最强但太散。鉴权、参数拼装、分页、重试、错误码解析全都得自己处理。让 Agent 直接和裸 API 打交道等于每次都给它一地零件。CLI 刚好在中间它比 GUI 稳定因为接口是文本不是界面它比裸 API 省事因为脏活已经被命令封装好了。第二大模型天生会用 CLI。大模型的训练语料里充满了命令行指令。项目安装说明、构建脚本、技术问答、错误排查过程到处都是 CLI。模型不需要从零学习怎么用命令行它对这种范式天然熟悉。这也是为什么 Agent 生成 CLI 命令往往比在一堆互不相干的工具里做复杂选择更稳。命令调用是在一个相对统一的文本格式里做组合而函数调用常常是在一堆结构各异的接口之间切换。第三Unix 哲学正好契合 Agent 的工作方式。Unix 很早就把 CLI 的底层逻辑定了下来每个程序只做一件事程序之间能协作用文本流做通用接口。这三件事恰好也是 Agent 最需要的三件事。文本是模型的母语。输入可以是文本命令输出可以是文本结果、错误信息或者 JSON。输入输出通道稳定。正常结果走stdout标准输出错误走stderr标准错误成功或失败由exit code退出码表示。每个命令只做一件事但多个命令可以接起来形成一条工作流。不管是老命令还是新命令结构都是一样的而多个命令可以通过管道接起来这行命令本质上就是把读日志“筛错误”做统计三件事接成了一条链。Agent 擅长的本来就是这种连续动作——拉数据、填数据、出图表一步接一步。Agent 不只能执行还能根据结果继续修正。拉数据发现格式不对就先转格式再继续填数据发现字段缺了就先补字段再接上。这种做一步、看一步、修一步的循环正好和 CLI 的即时反馈机制咬合在一起。所以这一节的结论可以先落在这里执行层一旦重组CLI 仍然是最成熟的会合点。再把 MCP 放进来它和 CLI 到底什么关系前面只讲了 CLI。但 Agent 时代还有另一个高频词MCP。它和 CLI 到底是什么关系先看整体位置CLI 和 MCP 都站在 Agent 和底层能力之间但处理同一件事的方式很不一样。用同一个任务来看最清楚——比如从飞书多维表格里拉出一批记录两者在三件事上有明显区别怎么发现能力、怎么发起调用、结果怎么回来。CLI 路径Agent 必须先知道有什么命令。Agent 需要提前知道lark-cli这个命令存在然后生成一行字符串系统执行这行命令把结果以文本通常是 JSON吐回来。Agent 读文本决定下一步。如果 Agent 不知道有lark-cli这条路就走不通——它连命令都生成不出来。MCP 路径协议主动告诉 Agent 有什么能力。MCPModel Context Protocol模型上下文协议的做法不一样。Agent 不需要提前知道任何命令。MCP Server 会主动把自己的能力清单推给 AgentAgent 看到清单选一个工具填好参数发起调用。它不需要知道底下跑的是lark-cli还是直接调了飞书 API——MCP 把这些细节屏蔽了。两者各有各的强项看同一个任务就清楚了。CLI 的两个强项第一管道组合。比如任务是读日志找出错误行统计一共多少条。CLI 模式下Agent 写一行命令一次调用三步操作通过管道接在一起。MCP 模式下同样的事要分三步先调read_file拿文件再调search_text筛错误行最后调count_lines统计。三次调用每次都要选工具、填参数。第二上下文更省。大模型的训练数据里CLI 是最密集的工具使用范式。GitHub 上几十亿行代码充满了命令行——项目 README 里的使用指南。大模型不需要从零学习怎么用命令行它已经见过无数遍了。而 MCP 的工具 schema 是 2024 年才出现的新东西训练数据里几乎没有。更关键的是MCP 需要把工具描述注入 Agent 的上下文窗口——Agent 还没开始干活窗口就先被占掉一块。虽然延迟加载deferred tools正在缓解这个问题但 CLI 不需要注入、天然就会这个优势是结构性的。MCP 的两个强项第一不限于文本。CLI 的管道是文本流。文本进、文本出这是 Unix 50 年前定下的规矩。对于日志、代码、配置文件这些文本内容这套模式非常高效。但如果 Agent 要处理的是一张图片、一段音频、一个结构化的数据库查询结果呢文本管道就成了瓶颈。你没法把一张 PNG 通过管道传给下一个命令。MCP 的结构化调用没有这个限制。它可以传递 JSON 结构、二进制数据、带类型的返回值。对于需要处理多种内容类型的场景MCP 天然更合适。第二参数验证。CLI 里一切都是字符串。Agent 拼出来的命令参数是对是错只有执行了才知道。拼错了参数格式命令执行失败更糟的情况是如果输入里藏着恶意内容Agent 可能拼出一条危险命令这就是注入风险。MCP 在调用之前就能拦住这些问题。每个工具的参数都有类型定义字符串、数字、必填/可选协议层会在执行前校验。填错了当场报错不会把错误带到执行环节。不过要注意参数验证能减少误调用但不等于MCP 就安全了。真正的安全还是要靠权限控制、沙箱隔离、服务端策略。还有一层容易忽略的区别隐式 vs 显式CLI 看起来省事——不用写 schema、不用注入描述、Agent 直接上手。但它有大量隐式前提当前在哪个目录、环境变量是什么、装了哪个版本的工具、用的是 bash 还是 zsh。这些都会影响命令的执行结果但 Agent 不一定知道。MCP 看起来笨重——要写工具描述、定义参数类型、注入上下文。但正因为这些都写出来了执行前提是显式的输出是可预期的出了问题也更容易定位。一句话CLI 省的是显式说明增加的是隐式不确定性MCP 反过来。两者正在互相靠近CLI 和 MCP 正在各自补对方的短板。CLI 这边开始变得更结构化。OpenCLI 提供了cli-manifest.json机器可读的命令清单和SKILL.md给 Agent 看的能力说明让 CLI 不再只是你得先知道有什么。MCP 这边开始变得更可组合。Code Mode 让 Agent 不再一次只能调一个工具而是直接写一段脚本把多个 MCP 工具串起来——一次搞定原本需要多次调用的链式操作。两边都在往中间走。但这不意味着它们会合并成同一个东西——管道组合和结构化调用是两种不同的架构模型各自在边界上互相学习。在实际产品里已经共存拿 Claude Code 来说它的内置能力运行命令、读写文件、搜索代码全走 CLI 路径。外接服务GitHub、数据库、第三方平台走 MCP。日常使用中大约 70% 的工作由 CLI 完成30% 由 MCP 完成。底层继续调 CLI外层用 MCP 接入——这可能就是 Agent 工具体系最终的样子。CLI 不是原封不动地回来了它正在被重新设计CLI 重新重要以后事情并没有结束。相反它马上碰到了两个新的问题。第一个问题是Agent 不知道当前环境里有哪些 CLI 能用。CLI 原本是给人设计的。程序员知道git、docker、rm能干什么是因为他们学过、记过、用过。但 Agent 一上来并不知道当前机器上装了哪些命令更不知道每个命令具体怎么用。第二个问题是很多平台根本没有 API也没有 CLI。有大量能力仍然锁在网页里。你能点着用却不能调着用。对 Agent 来说这些能力就像隔着玻璃看得见够不着。围绕这两个问题CLI 正在沿着两条线演化。第一条线把已有 CLI 更好地暴露给 Agentyan5xu 推荐一下在《CLI is All Agents Need》里抓住的就是第一个问题。他的方向不是再发明一堆新接口而是围绕已有 CLI 做两件事给 Agent 一个统一入口不让它自己满世界找命令把执行结果整理成 Agent 看得懂、能继续决策的样子这样一来CLI 就不再只是你知道命令才能用的专家工具而开始变成一个能配合 Agent 持续循环工作的工作台。第二条线把网页和平台能力翻译成命令OpenCLI 抓住的主要是第二个问题。它处理的不是已有 CLI 怎么被发现而是原本没有 CLI 的平台怎么变成 CLI。以前你想从某个平台拿数据往往得自己打开网页、找入口、点按钮、导出。OpenCLI 做的是把这些只能点着完成的动作重新打包成命令让原本锁在网页里的能力开始可以被命令式调用。更关键的是它不只提供命令还开始提供机器可读的发现方式比如这意味着它在解决第二个问题的同时也顺带缓解了第一个问题命令不再只是写给人看的也开始写给 Agent 看。当然OpenCLI 当前还不是终局。它先解决的是把平台能力翻译成命令而不是把所有底层动作拆得很细让 Agent 任意拼装。但它已经说明了方向。这件事很重要因为它说明 CLI 的边界正在扩张。它不再只代表本地电脑上的能力也开始代表网页平台和远程服务。把这两条线和之前一直存在的传统 CLI 合在一起看今天的 CLI 至少已经长成三种样子工具型 CLIgit、docker、GitHub CLI平台型 CLI飞书 CLI、OpenCLIAgent 型 CLIClaude Code、Codex CLI、Gemini CLI工具型 CLI 一直都在继续承担专业世界里的连续执行。平台型 CLI 把原本分散在网页或平台里的能力重新包装成命令。这是软件侧收敛的结果。Agent 型 CLI 表面输入可能已经是自然语言但底下实际调度的仍然是 CLI。这是模型侧收敛的结果。三种形态看起来很不一样但它们站的位置其实相同都在执行层。下次看产品多问一句下次看到一个产品可以多问一个问题它的能力暴露到了哪一层只有 GUI——人能用Agent 够不着。有 API——能力开放了但接起来很重。有 CLI——Agent 可以直接调用而且能组合。有 Skill——CLI 场景说明Agent 拿来就能干活。拿飞书举例。如果飞书只有网页Agent 只能截图、找按钮、模拟点击一步错步步错。有了飞书 CLI一行lark-cli sheet records list就能拉数据Agent 直接生成命令、拿回结果、继续下一步。如果再做成 Skill——把命令、场景、参数说明打包在一起——Agent 连怎么组合都不用自己想了。层次越完整Agent 接入的摩擦越小。所以下次看到一个新产品别只问它好不好用也多问一句它的能力Agent 接得住吗学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】