EP124 为什么 Agent 时代，CLI 反而成了最优解？- 主题精读稿

前言：当软件开始为 Agent 而设计

一个反直觉的现象正在发生：像 Obsidian 这样做了六年的笔记软件，突然在 2026 年 2 月发布了 CLI；Podwise 这样的播客 AI 工具，也把 CLI 作为新一代产品形态的主接口。这不是对旧潮流的致敬，而是因为 Agent 生态需要一种全新的软件交付方式。这期节目围绕"为什么是 CLI，而不是 API 或 SDK"展开，从接口哲学、设计原则、LLM 化学反应,一直聊到对低代码平台的颠覆与新架构建议。核心判断是：CLI 加上 Skills，是今天软件接入 Agent 综合成本最低的方式。

一、为何选择 CLI 而非 API 或 SDK (00:08 - 05:14)

Podwise 发布 CLI 和 Skills，并不是一开始就规划好的事——是被用户一步步推着走的。越来越多的用户想把播客内容接进各种 workflow 和自动化流程，Podwise 的用户也就需要从"人"进化到"agent"。当团队决定动手时，第一个问题冒出来了：为什么不是 API，不是 SDK，而是一个看起来反潮流的 CLI？

一啸的回答直截了当：这不是反当下的潮流，而是在反传统 SaaS 的对外提供方式。SDK 和 API 本质上是"给程序员编程用的"，设计往往复杂甚至臃肿。一个 API 上挂着一堆参数，不同组合对应不同效果，还需要配合文档与 Schema 才能搞清楚怎么用。换句话说，它是灵活的编程接口，不是给人直接友好使用的入口。

面向 Agent 时，需求就反过来了：要的是干净、清晰、易用、没有歧义、认知负担低的工具。CLI 正好扮演了这个角色。CLI 本质上是一种可组合的文本接口，而不是一个代码接口。它是 Linux/Unix 时代人和机器交流的唯一通道，天生就有 STDIN 和 STDOUT 这种自然的输入输出流，以及 Pipe 组合能力。在 Linux 上，你可以 cat 一个文本再 grep 想要的内容，通过组合发挥出远超单个工具的力量。

一啸强调的关键词是"认知负担"：一个命令就能跑。API 需要先集成到代码里才能跑，这个步骤的工作量和认知成本都不低。Agent 确实会写代码，甚至能写复杂代码，但它更会写、也更容易写"一条命令"。这正是为什么今天 Agent 生态里大家突然发现 CLI 运行很稳定、很好用。

二、CLI 是软件接入 Agent 综合成本最低的方式 (05:15 - 07:37)

Saito 指出，现在大家都在一股脑做 CLI——Obsidian 做了六年，2020 年发布第一个版本，2026 年 2 月才推出 CLI；如果不是 Agent 生态的出现，它作为一款笔记软件根本没有理由去做 CLI。Podwise 也是一样的情况。

这是因为 CLI 加上 Skills 已经成为软件接入 Agent 综合成本最低的方式。CLI 背后其实也有 API，只是不直接暴露给用户，而是用 CLI 封装起来。这样做的好处是三方都方便：AI 调用方便、用户自己安装调试方便、开发者复用已有能力也方便。

一啸留下了一个让 Saito 觉得"特别有意思"的比喻。以前的软件像堂食餐饮，终端用户要到店吃饭，门店得装修漂亮、服务周到，处处要考虑顾客体验；而 CLI 就像堂食店加了个外卖——门店能力直接复用，只要接上外卖平台、在门口安排个取餐区就行了，这一块不用装修，也不用专门的服务。有了"外卖"这种生态位，才会出现纯外卖专门店，也就是今天那些完全面向 AI Agent 的软件。

就像我们之前的软件，它其实是做堂食餐饮的，终端用户他是到店去吃饭，那门店得装修漂亮，然后服务也得周到。那 CLI 呢就像这个堂食店加了个外卖，它这个门店能力是附用的，然后只要接上外卖平台，在门口安排个外卖取餐区就行了。

三、Podwise CLI 的功能设计：四大类原子能力 (07:38 - 11:26)

一啸在社区里看到一个讨论：很多老牌 SaaS 在做 CLI 时，会把外部版本所有功能一股脑迁移到命令行上，最后得到一个非常臃肿、对 Agent 一点都不友好的 CLI。CLI 到底应该做成已有 SaaS 的哪一部分，可能是最值得思考的问题。这里面必然是取舍的，绝不可能一比一照搬。

Podwise 最终只保留了四大类原子能力，有意不再像 Web 界面那样提供打开就能看到的"已经编排好的工作流结果"。命令行提供的是原子能力，用户可以用脚本、skill 或自动化 workflow 自己去组合出最终想要的结果。

第一类是内容发现。平台上内容非常多，而 Agent 场景下"人已经不在流程里面了"，必须让 AI 自己去发现内容。因此 Podwise 在发现能力上做得非常完善：AI 的 AskAI、Search、列出个人更新、History 等等，确保 Agent 能精准找到想要的那一集。第二类是内容处理，面向音频、视频、本地文件。第三类是结果获取，包括组织稿和各种总结。第四类是内容导出，对接 Readwise、Notion、Logseq 等外部平台。

一啸特别强调发现能力的普适性：所有面向 Agent 的 CLI 都需要思考怎么让 Agent 完成"发现"这一步，这不是 Podwise 独有的问题。

四、兼顾人类与 Agent：TTY 作为分水岭 (11:27 - 13:38)

Agent 现在成了新的用户，那设计 CLI 时需不需要也照顾人类用户？一啸的立场很明确：需要，而且这正是 CLI 比 MCP 好用的关键原因——CLI 能够直接被人使用。他自己在做 Podwise CLI 时从没想过要先写一个 MCP server，因为写完 CLI 再去封装 MCP server 会发现后者调试起来很麻烦，必须接入那套编程生态才能调试。

但 CLI 面向人类的设计有技巧。黑屏白字的视觉表达肯定赶不上 Web 界面，所以 Podwise 加了一个专门给人用的开关选项，打开后结果会被渲染，有颜色、有动画（比如处理进度、syncing 这些）。

这里有一个反直觉的设计小技巧：这个"给人看"的选项必须只能在终端的 TTY 环境下运行。原因是人类环境自带 TTY，而 Agent 作为工具调用时没有 TTY，通过管道重定向时也没有 TTY。如果不做这个判断，渲染输出里那些颜色编码、大量的 color 数字会污染 Agent 的上下文，token 消耗也会非常巨大，严重影响 Agent 的正常运行。因此要靠 TTY 环境识别当前是不是人——是人就走 pretty 输出，否则一律用最原始的纯文本。

五、面向 Agent 的 CLI 六原则 (13:39 - 19:17)

一啸给出了他对 CLI 设计的一套系统性原则，可以视为面向 Agent 的通用设计指南。

第一，管道优先。 这是第一重要的一点。以前给人用的 CLI 很少考虑管道，输入是人提供的参数，输出经常是一个 -o 或 --output-file 选项直接写文件。很多 CLI 在这件事上都是"不合格的"。好的做法是不要自己去写文件，把这件事留给管道去做重定向。Agent 编排时会调用大量系统命令，管道支持得好，组合效果会好非常多。

第二，幂等性。 人有误操作也就算了，Agent 是自动化的，会有极多重复调用，幂等性因此非常关键。

第三，不要交互式。 Agent 没法进行交互式对话，给它一个要输 yes/no 的界面就是不友好的。本质上，今天的 Agent 还是基于文本工作——这里一啸插入了一段对谢赛宁观点的回应：谢赛宁认为未来 AI 世界里视觉非常重要，而今天的 AI 没有视觉能力，它不像人能看屏幕再决定输入什么，而是在分析文本内容。这和人的智能确实有很大不同，人的智能里视觉扮演着相当重要的角色。

第四，清晰的 help 信息。 而且最好有可以直接复制就能用的示例。Saito 后面补充，Agent 已经内化了"先跑一下 help"的能力，一个 CLI 只要 help 写得清楚，Agent 就能靠 help 里的示例自己做下一步调用；没有清晰示例，就只能靠猜，失误率会很高。

第五，错误信息要能指导下一步行动。 过去我们写 error message 很偏程序员视角，只是 print 一个错误。面向 Agent 的 CLI 应该告诉 Agent 下一步该怎么办——比如"未认证"就要明确告诉它该如何去认证。

第六，结构化输出。 支持 JSON 这类结构化格式，语义表达一定要清晰，每个字段对应什么内容必须明确告诉 Agent。

六、Skills：工作流从手写变成声明 (19:18 - 24:06)

CLI 提供原始的原子操作，Skills 是在 CLI 之上的工作流层。用户可以直接用自然语言调用 CLI 的底层能力——"帮我获取 2026 年 AI 发展趋势那一期的逐字稿"——但 Skills 真正关键的一层在于通过管道或多次调用，把搜索、处理、获取逐字稿、导出等步骤串成完整流程。

Saito 举的例子很直接："请帮我找到最近讲 AI Agent 的播客，然后把重点帮我导出来，同步到 Notion 里面。"这一句自然语言交给 LLM，它会自动拆解成一连串步骤：先 search 找内容，如果没处理过就调用 process 做 AI 处理，然后 get 拿 transcription 或 summary，最后 export 到 Notion。整个 workflow 不是手写的，而是被动态生成的。进一步还可以把固定的 workflow 沉淀成固定 skill，参数化、嵌套都可以。

以前你在调用工具，现在你更像在描述任务。过程式编程变成了声明式编程，LLM 帮你动态拼出工具链。

Podwise 基于此内置了几个 skill：帮你总结本周播客周报、根据你的英文水平抽取地道表达帮你学外语、苏格拉底式问答陪你深度探讨某一期内容。用户还可以直接问"Podwise 你有什么能力"让它自己介绍。Saito 认为最神奇的在于，LLM 的内置智能作用在 CLI 之上时产生的化学反应：不光是固定 workflow 的执行，还有自然语言被 LLM 自动拆解成多个 CLI 命令调用——这是 API 或 SDK 完全给不了的体验。

七、LLM × CLI 的化学反应：从 Workflow 到 Agent 架构 (24:07 - 27:37)

使用 API 和 SDK 为什么获得不了这种神奇体验？因为那仍然是"根据需求开发代码，写一个固定 workflow"。一啸认为，化学反应的核心是排列组合。

传统编程是拿着 API/SDK 根据经验和产品理解实现固定 workflow 的组合，再把"我认为绝大多数用户需要的"业务流程做出来。这就是所有传统 SaaS 的形态：固定编排好的 workflow，上限比较低——你做成什么样，它就是什么样。用户有源源不断的新需求，产品得不断迭代、不断发版本。

LLM 带来的高度自动化让排列组合变得无限可能。开发者不再根据自己对产品的理解把系统做成一个固定形态，而是让 Agent/LLM 去动态生成系统的形态。整个 SaaS 系统变成了一个动态组合系统，驱动力完全来自用户此刻的临时需求。用户想要什么，它就给你什么样的结果，上限因此变得非常高。

这个问题的本质等价于 AI 应用架构设计中"workflow vs agent"的争论。Workflow 是固化好的东西，想象力上限低，好处是稳定，但对产品形态来说太死板。而 Agent 架构让产品的生命力旺盛很多。

你可以从里面变出各种魔法，真的是 magic，就是这样的。

八、颠覆低代码/无代码平台：直接交付结果 (27:38 - 29:31)

Saito 做过几年低代码平台。他把低代码/无代码平台称作"旧时代的魔法"，Agent 则是"新时代的魔法"。旧魔法的逻辑是：平台提供封装好的原子能力，加上编排机制（所见即所得，或者 workflow DSL），让用户自己实现需求。原子能力提供确定性，编排机制提供可能性，用户有时能做出超出开发者想象的东西。

但这里有个根本问题：用户必须先自己动手做工具，才能用工具得到结果。做工具这一步，即使在无代码平台辅助下也并不简单，稍微复杂就需要不少专业知识。

CLI 提供确定性的原子能力，大模型提供无需编排的可能性，把低代码平台最麻烦的那一步直接干掉了。 用户不需要经过"搭建工具"这个中间过程，就能魔法般地直接拿到结果。

Saito 的结论很决绝：如果今天还有在持续迭代维护的低代码、无代码平台产品，已经到了应该舍弃的时候，不管投入了多久，都应该壮士断腕。一啸回应："认可这个。"

Saito 补充了一个观察：低代码/无代码平台本身对性能要求不高，本质上是"数据库集合+业务流程编排"，也就是数据模型加上业务流。而 LLM 的组合能力刚好也不是性能最优的那一种，但它能无限组合——两者恰好匹配。用数据模型加上 LLM，就已经可以替代低代码/无代码平台本身的流程编排能力。

九、Token 与内容消耗的成倍增长 (29:32 - 36:48)

Saito 用自己的真实案例说明 Skills 带来的消费跃迁。他想研究 Stripe 前 CTO David Singleton（设计模式里"单例"那个名字）的过往言论，让 Podwise 帮他检索——结果找到了 Singleton 参与过的 9 期播客，5 期已处理、4 期没处理，Podwise 直接把那 4 期也处理了，然后统一汇总出 Singleton 在 Stripe 时期和新创业公司 Dreamer 当 CEO 后各自的观点。整个结论非常完美，因为全部从播客里提取。不光 token 消耗增长，Podwise 内容的消耗量也成倍增长。

一啸解释说这其实挺直觉：token 的流转本身就是内容的流转。大模型通过 token 的流转来"阅读"和"理解"内容（加引号，原理上只是模式匹配和推测）。表象上，它消费输入的内容，把内容转成 token，再把 token 转出新的内容——所以它就是在消费内容。

放到编程场景也是一样。写代码本身就需要消费内容——看已有代码、看文档、看第三方库。现在这些都被大模型在消费，效率是巨大提升。结果上看大模型是直接在写代码，但它动手写代码之前，其实是以几百倍于人类的速度在阅读内容、梳理方案。Saito 回忆说，AI Coding 能力还没那么强时，他习惯先自己看代码看文档，脑子里形成方案再描述给大模型来提高确定性。程序员花时间最多的从来不是写代码，而是想方案——AI Coding 能力变强后，"想"这部分的时间节约非常明显。

一啸的体感类似：今天内容消费几乎完全不自己人肉消费了。接一个新 SaaS 产品，他会直接把整个文档网站扔给 Agent，让它几分钟读完所有文档，把架构原理到收费策略的关键点列出来。换成人自己看，只会挑 pricing 和架构，其他细节大概率不会去看了。消费内容因此成倍增长。

但一啸在 token 消耗这件事上很清醒：效率提升很明显，成本也明摆着，要看性价比。工作、编程场景，性价比非常高；纯娱乐场景，token 消耗成本可能就摆在那里，需要权衡。他还点破了一个现实：今天很多人在鼓吹"消耗多大量 token 才算真正掌握 AI"，但要想想——黄仁勋是做什么生意的？阿里、Google、腾讯卖 token，老黄卖卡，每个人都是从自己的生意角度出发。每人每天消耗一万美金，钱都进了他们的口袋，这是合情合理的。

十、Podwise CLI 的商业模式：免费开源与滚动窗口限制 (36:49 - 38:35)

Podwise 的 CLI 和 Skills 免费开源，可以在 GitHub 搜 podwise-cli 找到。商业设计上，Podwise 对价值较高的能力（比如获取 AI 处理后的结果）做了滚动窗口限制：5 小时的滚动窗口加上一周的滚动窗口，到点重置。原则是让正常使用够用，但如果有人想把数据一次性爬完，就要防御一下。成本大头的转录和 AI 处理沿用与 APP 共享的 credits，CLI 转录的结果在 APP 里也能看到——本质上 CLI 就是对 APP 能力的再包装。

为了推广体验，Podwise 还给 Free 用户送了专属于 CLI 的 AI 处理配额，这份配额只能在 CLI 上使用，Web 上用不了。目的是鼓励大家不花钱就能体验 CLI 加 Agent 的那种"神奇体验"。

十一、新产品的架构建议：API 优先，CLI 当作标准配套 (38:36 - 44:55)

如果从零开始做一个同时给人和给 Agent 用的新产品，架构上应该怎么设计？一啸的回答是：从工程基础架构上跨度没有特别大，更重要的是生态意识的转变——要不要转向 Agent 生态。这才是产品人需要思考的核心问题。

具体到技术层面，他给出三点。

第一，前后端分离要做成绝对的 API 优先。 前后端分离是提了很多年的老话，但过去几乎所有"前后端分离"都有一个神奇的问题——你去找后端要一份清晰的 REST API，往往要不出来。后端给不出一个可以作为 Open API 对外开放、带完善 token 认证和限流、和前端完全解耦、有清晰 API 日志的 API。所以今天做前后端分离，要的是 API 优先，API 先行，再在此之上考虑 GUI 和 CLI。

第二，把更多逻辑放到 CLI 上，让服务端更简单。 Podwise CLI 可以导出 SRT、VTT 字幕格式，可以生成 PDF、XMind——这些格式转换利用本地桌面电脑的算力就非常自然，完全不需要增加服务端压力。服务端专心去提供稀缺的高价值核心能力：用户认证、计费、最核心的业务流程。

第三，不要把 CLI 当成对 API 的 wrapper，要把它当成服务端的标准配套，像 iOS App 一样。 iOS App 远远不只是调用远程 API 再展示结果，它利用了大量本地计算能力做本地逻辑。CLI 也一样，跑在本地桌面或服务器上，拥有对算力、存储的完整控制能力，可以做浏览器做不到的所有事情。CLI 可以去实现所有扩展功能，提供更多原子能力供 Agent 直接调用。

一啸举了"转 PDF"的例子：今天的 Cloud Code 这类 Agent 确实能把文字内容写成 HTML 再转成 PDF，但这个过程要消耗大量 token，且不稳定——生成的 PDF 每次漂亮程度都不一定。把"文字转 PDF"沉淀到 CLI 里，就变成固定的 tool、固定的原子能力，Agent 可以反复稳定调用。从这个角度看，CLI 不是 wrapper，而是与 server 端配套的客户端程序。

这也回答了 Podwise 为什么选择开源 CLI：因为大多数核心业务逻辑（计费、认证）在服务端，客户端不重要，可以给大家随便改。但当 CLI 成为核心服务的一部分、和 server 形成配套的时候，开源与否就需要重新决策，很可能会选择不开源的方式提供给用户——要根据产品自己的属性来判断，和 iOS App 是一个道理。

Saito 最后收束到体验与成本的关系：本地能力和服务端配合，可以让 CLI 能力更强、降低 token 消耗、给用户更好的体验，同时降低用户成本。这是产品设计时可以从体验角度着重思考的方向。

十二、安装通道 (44:56 - 结尾)

如果使用小宇宙（OpenCloud），可以在 Cloud Hub 搜索 Podwise 直接安装，或者命令行 cloud hub install podwise。如果使用 Cloud Code、OpenCode、Codex 等其他产品，可以通过 npx skills add hard-hacker-labs podwise-cli 直接安装。问题反馈可走 GitHub issue 或评论区。