最近我越来越强烈地感受到一件事：很多 SaaS 产品其实正在悄悄换底座。
过去 SaaS 产品面对的主要是人：人点按钮、人看页面、人手动切换系统完成流程。产品做得好不好，主要看页面顺不顺、功能全不全、协作顺不顺手。
因为现在产品面对的，已经不只是人了，还有 Agent。人是来点按钮的，Agent 是来调能力的。它不关心你的页面漂不漂亮，它关心的是你的能力是不是稳定、清晰、可调用、可审计。
这也是为什么最近飞书、钉钉会不约而同地往 CLI 化、Skill 化走。表面上看这是开发者工具层的动作，实际上是在改产品底座：它们在把自己从“给人点的页面集合”，重构成“给人和 Agent 一起调用的执行系统”。
我对这件事的判断很明确：这不是一阵风，而是 SaaS 产品形态已经开始发生的变化。只是这里面也有一个特别容易走偏的地方：SaaS 最应该做的，是把自己做成最好的能力层，而不是急着把自己做成一个通用代理壳子。
为什么这件事几乎是必然的
CLI 在过去更像开发者接口，现在重新变成了 AI 时代的“自然机器接口”。对人来说，CLI 可能不够友好；但对 Agent 来说，它极其友好：参数清晰、输出结构化、错误可解析、帮助文档自描述、天然可脚本化。
新浪科技在总结飞书和钉钉近期动作时，有一句话说得很准：
“命令行界面（CLI）是软件能力最底层的调用方式——对AI来说，有了CLI，调用平台能力就像执行系统指令一样直接。”
—— 来源：飞书、钉钉开源 CLI，Agent 开放路径走向分岔
这句话真正重要的地方，不在于“CLI”这三个字本身，而在于它点出了一个用户模型的变化：以前 SaaS 面向的是“点击鼠标的人”，现在还要面向“会拆任务、会调工具的 Agent”。
如果一个 SaaS 产品到今天还是只有 GUI、只有零散 API、只有给人看的帮助文档，那它在 Agent 时代就会很尴尬。因为人还能凑合着用，Agent 是很难稳定接进去的。
所以这波趋势的本质并不是“大家都想做 AI”，而是大家都意识到，产品的执行层必须重新开放一次，而且这次不是开放给人，而是开放给 Agent。
飞书、钉钉为什么都在往这个方向走
最近国内最强的信号，就是飞书和钉钉几乎同时走向 CLI 化。
关于钉钉，IT 之家的一段描述很能说明问题：
“钉钉 CLI 开源了！3 月 27 日，钉钉 CLI 开源项目上架 Github 社区，项目以 Apache-2.0 协议开源，首批开放 AI 表格、日历、日志、待办、机器人、通讯录、DING 消息、考勤、开放平台文档、工作台共 10 项核心产品能力，原生支持 Claude Code、Cursor 等主流 AI 编程与 Agent 执行环境。”
—— 来源：钉钉 CLI 开源！首批开放 10 项产品能力
同一篇文章里还有一句也很关键：
“开发者完成一次初始化配置后，即可在任意支持 CLI 调用的 Agent 框架中直接使用钉钉产品能力，无需额外的 SDK 集成或中间件开发。”
翻译成人话就是：未来竞争的关键，不是让 AI 能不能听懂你，而是让 AI 能不能稳定地用你。
飞书这边，虽然这轮公开检索里更容易搜到的是社区实现，但这反而说明一件事：飞书的能力结构已经天然适合被重新封装成面向 Agent 的执行层。
“飞书开放平台命令行工具 — Markdown 与飞书文档双向转换，AI Agent 的飞书操控引擎。”
“除了传统的 CLI 用法，feishu-cli 还为 Claude Code 等 AI 编程助手提供了 11 个开箱即用的技能文件，让 AI Agent 能够直接创建文档、发送消息、管理权限。”
—— 来源：riba2534/feishu-cli - GitHub
这里有个很有意思的信号：就算平台自己不亲自下场定义执行层，生态也会替它定义。因为一旦一个 SaaS 平台沉淀了足够丰富的对象模型、权限系统和工作流能力，市场自然会把它重新打包成 CLI + Skill 供 Agent 使用。
所以从平台视角看，CLI 化、Skill 化不是“顺手多做一个工具”，而是在主动把执行层的定义权拿回来。
真正值钱的，不是 CLI，而是 Skill
CLI 解决的是“怎么调用”；Skill 解决的是“什么时候调用、按什么顺序调用、带着什么上下文调用”。
这两者完全不是一个层级的问题。
只做 CLI，本质上是在暴露原子能力；做 Skill，才是在沉淀领域里的最佳实践。它把原来需要靠资深员工、实施顾问、项目经理口传心授的东西，压缩成一个可以被 Agent 复用的工作单元。
从这个角度看，Skill 的真正价值不是“prompt 模板”，而是领域 SOP 的可执行打包格式。它不是让 AI 更会说，而是让 AI 更会干。
这也是为什么 SaaS 最终一定会往 Skill 走。因为很多 SaaS 真正有价值的部分，从来都不是按钮本身，而是按钮背后那套隐性的业务顺序、对象关系、权限边界和例外处理逻辑。
这对传统数据分析平台和报表平台意味着什么
这部分我觉得其实最值得展开。因为很多数据平台现在理解这波变化，还是停留在“给 BI 加一个聊天框”这个层面。但真正重要的地方，从来不是“会不会对话”，而是“能不能把分析和行动重新接起来”。
传统 BI / 报表平台的问题，不是没有图表，也不是没有问答，而是洞察到行动之间断了一截。
报表告诉你北美收入在掉，仪表盘告诉你某个渠道的转化率在跌，异常监控告诉你某个业务指标突然偏了——但接下来怎么办，往往还得人工再跳到 CRM、营销系统、客服系统、项目管理系统里一层层处理。
所以过去的数据平台，本质上更像“解释世界”的系统；但到了 Agent 时代，大家真正期待的是：你不只是解释清楚，还要能顺手往前推一步。
这也是我为什么觉得，数据分析平台和报表平台接下来真正应该升级的，不是一个会聊天的外壳，而是底下的四层能力。
第一层，是语义层要先 Agent-ready。没有统一语义层，Agent 只会把混乱放大。Dremio 的文章里有一句说得非常直白：“A semantic layer provides the metadata and context that AI systems need to query data accurately.” Databricks 也说得很像：当指标定义被集中到语义模型里，所有下游界面——无论是 BI 看板、Jupyter notebook，还是自然语言问答——读到的都应该是同一套受治理的逻辑。
这意味着，数据平台第一优先级不是“做一个更聪明的对话入口”，而是把指标、口径、维度、权限、血缘、同义词、认证状态这些内容整理成统一的、可被 Agent 稳定调用的语义层。
第二层，是把分析动作本身做成可编排能力。数据平台里有大量高频动作，其实天然适合被命令化：刷新某个数据集、生成某条业务线的周报、对异常指标做根因拆解、生成高管简报、触发某个看板的快照和分发、发起某个指标定义的审批。假如这些动作还是深藏在 UI 里，那 Agent 很难真正接得上来。
第三层，是从“问答式 BI”走向“行动式 BI”。所谓行动式，不是让系统替你做所有决策，而是让它在给出洞察的同时，也能往后推动一步。比如发现某地区续费率异常下降后，不只是解释原因，还能自动圈出受影响的客户分群、生成负责人的跟进清单、在 CRM 或项目管理系统中创建任务，甚至把结论写回复盘文档。这时候数据平台才真正从“看板”变成“指挥台”。
第四层，则是 GUI 的角色要重新定义。GUI 不会消失，反而会更重要，只是它不再是唯一入口。以后更适合它承担的角色，是监督、调试、配置、审批和复核。换句话说，CLI / Tool / Skill 负责执行，GUI 负责让人看清执行过程，并在关键处接管。
如果一个传统数据平台能把这四层打通，它就不是“给报表加 AI”，而是在把自己重构成一套真正 Agent-ready 的分析基础设施。
我为什么反对 SaaS 厂商重度重做一个“类似 Claw 的东西”
这一点我想说得更直接一点：不要把“自己有 CLI + Skill”误解成“自己必须做一个通用 Claw”。
像 Claw 这类产品，本质上是在解决通用任务执行器的问题：多工具协同、文件与浏览器操作、跨系统编排、终端执行、上下文调度。这是一个很大的命题，但它并不是大多数 SaaS 厂商天然擅长的命题。
大多数 SaaS 真正的护城河，从来不在“做一个通用代理壳子”，而在于它对本领域的深度理解：业务对象模型、权限关系、组织关系、流程结构、审计链路、数据语义、例外规则。这些东西，才是别人最难复制的。
如果一个报表平台、一家 CRM 厂商、一个协同办公产品，突然把大量研发资源押到“做一个自己的通用代理操作系统”上，结果大概率是：花了很大力气去补浏览器自动化、通用编排、终端沙箱、跨工具状态同步这些并不属于自己核心竞争力的部分，反而把本来最值钱的领域能力做浅了。
所以我支持的路线一直很明确：深做自己的能力层，浅做自己的代理入口，广泛兼容外部 Agent 生态。
你当然可以有一个自己的 Agent 入口，用来降低上手门槛，也服务那些不愿意折腾工具链的普通用户。但你最重要的资源，不应该砸在“做一个万能代理”上，而应该砸在“让自己的产品成为外部 Agent 最愿意接、最容易接、最放心接的能力层”上。
一句话说，就是：SaaS 厂商应当成为最好的被调用者，而不一定要成为最大的总代理。
如果我是数据分析平台或报表平台的产品负责人，我会怎么做
如果让我来排优先级，我肯定不会先做一个花哨的 AI 外壳，而是会先从最务实、最容易出结果的地方动手。
第一步，我会先把现有高频能力拆成明确的动作层。哪些事情是用户反复在做的？生成周报、快照分发、指标解释、异常诊断、批量导出、权限审批、订阅推送……先把这些变成明确的命令、工具和能力接口。因为这一步一旦打通，外部 Agent、内部工作流和未来的 Skill 才有接入基础。
第二步，我会集中补语义层。不是为了讲概念，而是为了避免后面所有 AI 能力都建立在不统一的口径之上。只要语义层不稳，所有所谓“智能分析”都会在不同场景下说出不一样的话，最后把平台信任度打穿。
第三步，我会挑几条最值钱的业务链路做 Skill，而不是泛泛地做一个“万能问数助手”。比如高管简报、运营周报、异常归因、销售漏斗复盘、投放效果归因、月结分析，这些都比“你可以问我任何数据问题”更容易形成可感知价值。因为真实用户并不缺一个会聊天的工具，他们缺的是一个能把具体工作接过去的工具。
到了这一步，如果要做自然语言入口，它也应该建立在前面这些能力之上，而不是倒过来。对话只是入口，不能成为系统本体。系统本体应该始终是语义层、动作层、Skill 层、治理层。
这也是为什么我一直觉得，对大多数传统数据平台来说，最好的路线不是激进重构一个全新的“AI 操作系统”，而是先把自己一点点改造成一个更适合 Agent 调用的基础设施。这样既不失焦，也更容易真正落到业务结果上。
最后的判断
未来几年，我觉得 SaaS 会形成一个越来越清晰的共识：GUI 不再是唯一主入口，它只是人类入口之一；CLI、Tool、Skill、MCP 会逐渐成为产品能力的标准暴露层；语义层会变成数据产品最核心的资产之一；而报表本身，也会从“结果展示品”慢慢演化成“行动触发器”。
所以，“SaaS 都要变成 CLI + Skill”这句话，如果再说得准确一点，我会改成下面这句：
不是 SaaS 都要变成一个新的 Agent，
而是 SaaS 都要把自己重构成 Agent 可以放心调用的能力层。
对于传统数据分析平台和报表平台来说，真正值得做的，也不是给现有页面再套一个聊天框，而是把指标做得可解释，把语义做得可继承，把分析做得可编排，把动作做得可执行，把过程做得可审计。
这才是这波趋势里最值钱的升级。