Skip to content

CLI正在成为新的API

如果你是 AI 的深度使用者, 那你肯定会接触到 CLI 界面, 不管是通用的 AI Agent 工具、AI 编程工具, 还是和业务强相关的 飞书, 钉钉, 企业微信、 Shopee 等也都不约而同的推出了自己的 CLI 工具。

计算机从 CLI 命令行时代发展到 GUI 图形界面时代经历了漫长的过程, 现在 AI 时代,却开始反其道而行之, 开始从 GUI 图形界面时代发展回 CLI 命令行时代。 这背后的底层逻辑是什么? 想想其实也很简单, 就是为了适应 AI 时代的需求。

下面是 2026 年 3 月 27 日, Shawn Yeager(拥有30多年经验的科技商业化专家,主要专注于前沿技术的“Go-to-Market”, GTM,市场进入与商业化,尤其在 AI(人工智能) 和 Bitcoin(比特币) 领域) 发表的一篇文章,原文链接:The CLI is the new API, 为我们详细的讲解了 CLI 成为新的 API 的底层逻辑。


CLI 正在成为新的 API

尼尔·斯蒂芬森(Neal Stephenson)(美国科幻小说家, 在《雪崩》中首次提出元宇宙概念)曾经说过,图形界面(GUI)的出现,就是为了把用户从命令行(CLI)中拯救出来——因为命令行会“残酷地惩罚懒惰和不精确的操作”。当时人们为此投入了数十亿美元,而且确实成功了。如今,智能代理(Agents) 出现了:这些软件从不懒惰,对语法也绝不会出错,它们不需要被保护免受复杂界面的困扰。

残酷地惩罚懒惰和不精确的操作: 也就是说:命令行界面非常严格、无情, 如果你懒惰,比如不想认真看文档、不想精确输入、不想花时间学习正确用法, 或者操作不够精确(打错一个字母、少一个空格、参数顺序不对、路径写错等), 命令直接失败、报错、什么都不做,甚至可能导致严重后果(比如删错文件、系统崩溃等)。

为什么 SaaS 公司开始为智能代理推出 CLI?

SaaS 公司注意到了这个变化。在过去 90 天里,许多公司推出了专门为智能代理设计的 CLI,而不是给开发者用的普通工具。

CLI 已经成为决定产品能否进入智能代理工作流的关键接口层。它就像 2010 年代的 API 一样——是产品能否被连接使用,还是被边缘化的分界线。

我们走到今天,经历了两个阶段。

第一个阶段是 AI 编程代理的兴起。2025 年 5 月,Anthropic 推出了 Claude Code CLI;6 月,Google 跟进推出了 Gemini CLI;4 月,OpenAI 发布了 Codex CLI;12 月,Mistral 推出了 Vibe CLI;2026 年 2 月,GitHub 和微软将 Copilot CLI 正式开放给所有人使用。这些工具不是在原有产品上简单加一个 CLI 外壳,而是 CLI 本身就是核心产品。智能代理在终端中运行,它们读取参数、解析输出,并把多个命令串联起来。对操作软件的软件来说,终端才是它们原生的工作环境

这个阶段确立了模式,第二个阶段则是 SaaS 公司对此的回应。

在 Google Workspace CLI 推出仅 20 天后,37signals 就发布了 Basecamp CLI,包含 55 多个命令,还内置了 Claude Code 的技能。DHH 的说法是:“冰球正往这个方向移动,我们要滑到那里去迎接它。”3 月 27 日,Stripe 推出了 Projects CLI,用于支持代理驱动的基础设施配置。Vercel 发布了针对代理优化的 CLI 命令,并提供适合机器读取的 JSON 输出。Polymarket 也专门构建了一个 CLI,让 AI 代理能够轻松访问。《The Register》在 3 月 11 日发表文章称:“AI 让 CLI 变得更加重要和强大。”

DHH 在公告中最值得注意的一点,并不是功能数量。Basecamp 的 API 其实已经存在很多年了,但他提到使用该 API 的客户比例是“极小的一部分”。同一个 API,现在被包装成 CLI 并内置技能后,他预计智能代理会大规模使用它——不是因为人类会开始手动输入命令,而是因为代理已经在到处运行这些命令了。

为什么浏览器自动化对智能代理来说行不通?

当没有 CLI 时,智能代理的备用方案是浏览器自动化——它们像人类一样,通过截图和模拟操作来浏览图形界面。在 WebVoyager 这个使用友好测试网站的基准测试中,最好的浏览器代理得分约为 89%(2024 年 12 月)。但在更接近真实世界的 WebArena 测试中,最好的模型得分只有 35.8%(2024 年 10 月),而在实际生产环境中得分还会更低。而 CLI 在身份验证等环节可以达到 100% 的成功率——因为它本来就是为此设计的。

CLI 能完美融入程序化的工作流。它的功能非常容易发现:只需输入 --help,就能看到所有可用命令,而不需要人工去浏览界面或阅读文档。这对使用代码的智能代理来说非常重要。CLI 的输出是结构化的文本或 JSON,而不是需要额外解读的视觉界面——直接解析即可,然后通过管道传给下一个工具,简单完成。

对产品开发者来说,CLI 的优势也很明显:只需要维护一个二进制文件,而不用为各种编程语言开发 SDK;--help 本身就是文档;而且它能稳定地包装底层 API,让内部架构变化不会影响到外部调用。

CLI 正在成为新的“连接”与“无关”分界线

过去,API 是决定产品能否融入互联网络的关键接口。Stripe 在 2011 年推出时,把原本需要几周的银行审批、处理器协议和网关配置,简化成了短短七行代码。PayPal 曾经被开发者形容为“恐龙级噩梦”,而 Stripe 用一个简单的 curl 命令就能在几秒内完成支付。Twilio 在通信基础设施领域也做了同样的事。这两家公司并不是靠功能取胜,而是靠接口的质量取胜。

现在,CLI 正在扮演同样的角色。它决定了你的产品是否能进入智能代理的工作流。一旦代理进入工作流,下一个问题就是它们如何付费

没有 CLI 会怎样?

Notion 的情况就是“被排除在外”的典型例子。Notion 没有官方 CLI,于是 GitHub 上至少出现了十几个社区开发的非官方 CLI,其中好几个是专门为 Claude Code 和 AI 代理设计的。其中一个描述自己是“为开发者和需要非浏览器程序化访问的 AI 代理而生”;另一个则提供错误恢复提示和专为代理解析设计的结构化 JSON 输出。

无论如何,包装都会发生。问题只在于谁来控制这个接口——是产品团队自己,还是先到先得的社区。即使有了 CLI,代理也只能访问开发者提前连接好的服务。接口问题和发现问题,其实是同一个差距的两面


最近在写 Agent CLI 的教学课程, 如果你喜欢的话, 可以关注合集: