一句话结论：CLI没有消失，而是被AI Agent"吃掉"并转化为JSON-RPC，工具以另一种方式回来了。
花出去的钱不是消失了，而是以另一种方式陪在你身边。
有的旧工具也是，你以为它要消失了，但它以另一种方式回来了。
这个月，飞书的GitHub、Google的开源博客，还有钉钉的开发者公告--他们好像商量好似的，各自掏出一个 CLI（命令行工具） 。飞书的 `lark-cli` 、Google的 `gws` ，钉钉紧随其后。它们不约而同地在干同一件事：为自家庞大的SaaS套件，造一个极其复古的命令行入口。
更有意思的，是这些CLI的"目标用户"。
它们并非（或者说，不再仅仅是）为熬夜写脚本的人类工程师准备的。它们开宗明义：这是给 AI Agent 准备的接口。用官方话语说，是"为智能体打造的高效交互范式"。翻译一下：软件的新用户，可能不是人。
听起来像一个技术玩笑：图形界面革了命令行的命几十年后，当AI准备接管一切时，人类给它递上的，居然是一把来自上世纪七十年代的"螺丝刀"。
这把"螺丝刀"，正在被整个行业争相重造。一个更核心的异变正在发生：这个古老的CLI，在被AI"吃掉"的同时，正迅速 变形成一种新的、高度结构化的JSON-RPC 。
一次技术的轮回？还是一次彻底的范式升级？这场静悄悄的工具革命，是人与AI协作底层最深的困惑。
所有人都在重造"螺丝刀"：这不是巧合
让我们把时间线拉得再紧些。
2026年初，Google对外宣布了一个名为"OpenClaw"的开源Agent框架。它最石破天惊的能力，是能被授权接管用户的Gmail、Google Drive等核心服务。想象一下，一个AI可以替你阅读、分类、回复邮件，自动归档整理云端文档。公告一出，技术社区瞬间分裂。
"让一个Agent控制我的整个操作系统？疯了吧！"（Hacker News评论）
几乎是同时，另一派声音涌现。
"从2013年斯诺登事件起，我就一直保留所有数据的本地备份。我从不信任任何云服务的自动归档。但现在，当AI需要为我工作，我却需要把我的数据交出去？不。 现在到了我的验证时刻：我信任我自己的自动化 。"（Reddit评论）
AI想帮你管理邮件，它需要一个接口。如果这个接口是你每天用的Gmail网页版，满屏的按钮、图片、CSS动画，Agent会直接看傻。它需要结构化的、明确的、可编程的指令渠道。网页GUI是给人看的，API才是给机器读的。而API再封装一层，变成命令行指令（ `gws email list --label=Important` ），对于擅长处理自然语言和结构化文本的AI来说，竟然出奇地"顺手"。
所以，飞书、Google、钉钉的动作，逻辑出奇一致：与其让AI笨拙地模拟鼠标点击网页，或者费劲地解析复杂的API文档，不如直接为它量身打造一个最"原生"的界面--命令行。
这不是三家公司的心有灵犀，而是一个必然的行业动作： 当AI成为软件的首要用户，软件的交互层必须为它重建。
"吃"与被吃：两种视角，一个事实
站在AI Agent的视角，它正在"吃掉"CLI。
CLI是什么？是文本输入、文本输出，是清晰明确的动词（ `get`, `list`, `create`, `delete` ）和参数。这完美匹配了大语言模型（LLM）的"舒适区"：处理序列化的文本，理解结构化句法。一个GUI按钮需要经过"识别元素-理解功能-模拟点击"的复杂视觉推理；一句 `git commit -m "fix: typo"` ，对AI来说就像是一句自然的人类工作指令。
CLI因此从开发者工具，跃升为 AI Agent的"机械手" 。AI用这条文本管道，精准地操作数字世界。从这个角度看，AI并非消灭了CLI，而是赋予了它全新的生命力，让它从后台走向了前台，成为人机协作的新枢纽。CLI被"吃"了进去，消化成了AI的行动能力。
但站在人类开发者，尤其是那些经历过Web Service时代的老兵眼里，看到的却是另一番景象： CLI正在被迅速改造成另一种东西 。
为了更高效地被AI"吃"，这些新兴的CLI正在经历一场自我革命。它们不再像传统Unix工具那样输出自由、格式不一的文本，而是普遍地将输出标准化为 JSON 。一个 `lark-cli calendar list` 命令，返回的不再是给人眼看的、带缩进的表格文本，而是一个结构化的JSON数组，里面每个事件都有清晰的 `id` 、 `title` 、 `start_time` 、 `attendees` 等字段。
这还不够方便。为了减少AI调用的认知负担和成本，更激进的方案出现了。
比如 Apideck CLI 和 Mcp2cli 。它们不满足于单个服务的CLI，而是要做一个统一的、面向所有API的CLI层。它们的核心卖点触目惊心：" 比主流方案节省90%以上tokens "、" 可节省96-99%的token消耗 "。
Token是什么？是AI（特别是大模型）处理信息的"计价单位"。当你让AI调用一个复杂的API时，你需要把API的说明文档、参数格式"喂"给它，这部分"背景知识"消耗的tokens，可能比实际指令多得多。
这些项目做的事，就是把复杂的API描述（过去由臃肿的OpenAPI Spec或新贵的 Model Context Protocol (MCP) 定义），压缩成极度精简的CLI语法树。AI只需要知道"动词+名词+参数"的简单模式，无需理解背后庞大的协议细节。
至此，CLI已经彻底变味。它不再是"命令 行 界面"，而更像是一个 用命令行语法包装的、高度结构化的RPC（远程过程调用）接口 。
JSON-RPC的轮回？这一次，有什么不同
于是，那个灵魂拷问在社区里炸开了锅。
"我们是不是又在发明RPC？CLI包装成JSON听起来就是RPC换皮。"一位开发者尖锐地评论道。确实，如果把"命令"看作"函数"，"参数"看作"输入"，"JSON输出"看作"返回结果"，这不就是一个典型的RPC调用吗？
从技术抽象层面看，是的。 这像极了一次技术轮回 ：我们从函数调用，走向了网络RPC（XML-RPC, SOAP, JSON-RPC），然后拥抱了RESTful API，现在，为了AI，我们又回到了一个更精简、更聚焦于"行动"的RPC范式--只是这次，它穿了件CLI的马甲。
但仅仅是换皮吗？驱动这次轮回的内核力量，已经截然不同。
过去的RPC演进，核心驱动力是 机器与机器的通信效率与标准化 。这一次，核心驱动力变成了 AI与机器的交互效率与友好度 。它的"用户心智"变了。它的设计目标，不再仅仅是让一个Java服务调用一个Python服务，而是让一个基于自然语言思考的AI，能高效、准确、低成本地调用成千上万个异构服务。
争议也随之而来。当Apideck CLI们把"节省Token"作为最亮眼的指标挂在首页时，立刻有人泼冷水：" Token节省不应该是北极星指标 。" 言下之意，为了极致压缩而过度简化，会不会损失功能的表达力？会不会把复杂性转移到别处，比如Agent的决策逻辑里？
这直指当前AI Agent工具化浪潮的核心矛盾：我们是在为AI创造一个它用起来舒服的"世界"，还是仅仅在给现有的、为人类设计的复杂世界，打上一个临时的、简陋的补丁？
集体的困惑：为什么大家都在同时发明轮子？
这种矛盾，在另一个社区热点中体现得淋漓尽致。
一个有趣的评论出现在某个AI Agent协作看板项目的讨论区，收获了95个赞同：" 为什么所有人都在做同一个东西？ "
这个"东西"可以代指CLI for AI，也可以代指另一个更宏大的问题：内存管理、工具调用、任务拆解……几乎所有AI Agent的基础设施层，都出现了惊人的重复造轮子现象。
更绝的评论紧随其后："全世界都同时遇到了Agent记忆问题，大家都去做自己的解决方案，而不是先看看有没有现成的。"
这句话点破了当前Agent生态的某种 青春期躁动 。机会看似无限，但底层的基础协议和标准却远未成熟。就像互联网早期的协议混战，当每个人眼里都是万亿级市场时，第一反应往往是"我的场景特殊，我自己来定义标准"。于是，MCP试图成为工具调用的协议标准，但立刻有人吐槽其 `tool definitions` 仅注册就要消耗50000+ tokens，不堪重负。接着，CLI派揭竿而起，宣称自己的方案高效数倍。
这不仅仅是技术路线之争，更是对"AI如何与数字世界接口"这一根本问题，尚无共识的体现。我们是应该让AI去适应已有人类软件的复杂接口（MCP路线），还是让软件为AI重塑一个更简单的接口（CLI路线）？
从这个角度看，飞书、Google的CLI，不仅是工具，更是一种战略投票。它们把赌注投给了后者： 为AI重塑专用接口 ，哪怕这个接口看起来很像几十年前的老古董。
开放性问题：当用户不再是人类
回到最初那个问题：这是一次技术轮回吗？是，也不是。
从形态上，我们看到了技术范式螺旋式上升中似曾相识的回归。但从内核上，这是一次深刻的 设计哲学转向 。
过去，我们设计软件的逻辑是"以人为本"。GUI的演进史，就是不断降低人类认知负荷、提升交互直观性的历史。而现在，一个全新的、以LLM为核心认知模型的"智能体用户"出现了。它的认知模式、交互偏好，成本结构，与人类天差地别。
为一个文本预测模型设计的"最佳界面"，怎么会是一个需要视觉识别的图形按钮呢？
所以，CLI的"复活"与"异变"，不是一个怀旧故事，而是一个信号： 软件设计的坐标轴正在偏移 。北极星不再只是人类用户体验，还有AI Agent的调用效率、准确率，成本（token成本、计算成本）。
这种偏移带来了一连串亟待回答的开放性问题：
当 AI 成为主要用户，软件的功能边界要重新划分吗？ （比如，更多原子化操作？）
当 CLI 变成 JSON-RPC，它的权限模型、审计日志、错误处理，该如何重构以适配AI的"黑盒"决策？
最终，我们是会走向一个" 双层界面 "的世界--为人类优化的GUI，和为AI优化的结构化CLI/API，二者长期共存？还是终有一天，AI能理解我们的GUI，我们也能直接用意念指挥AI，这些过渡性工具再次隐入尘烟？
工具是思想的凝结。今天，我们为AI重新打磨一把名为CLI的旧螺丝刀。明天，这把螺丝刀会变成什么，又会被谁握在手里，去拧动哪一个新世界的螺丝？
这些问题，没有答案。而寻找答案的过程，正在定义下一个十年的软件形态。也许，我们该问自己的不再是"AI能不能用我的软件"，而是" 我的软件，配得上被一个AI使用吗？ "
擘迅
