AI杀死SaaS?从飞书CLI看企业软件的新护城河,正在从用户体验转向 Agent 体验

飞书 CLI 值得重视，不是因为它多了一个命令行工具，而是因为它暴露出一个更大的变化：协作平台没有等着被 Agent 绕过去，而是在主动把自己变成 Agent 可以正式工作的执行层和治理层。

这些年，行业里有一种说法越来越响：到了 AI 时代，智能 Agent 会绕过传统协作平台，直接替代像飞书、Slack 这样的 SaaS。

翻译得再直白一点，就是：Agent 能读邮件、管项目、写文档，那谁还需要这些现有的协作工具？

但这套“AI 杀死 SaaS”的叙事，真要细看，其实只说对了一半。

恰恰相反，我们现在看到的是，以飞书为代表的企业级平台，并没有坐等 Agent 把自己绕过去，而是在主动拥抱 Agent，让 Agent 在自己的生态里工作。飞书新推出的命令行工具 CLI，就是一个很典型的反例：它不是被踢出场，而是在主动给 Agent 开门。

飞书 CLI：给 Agent 开门的协作平台

飞书团队最近在 GitHub 上发布了开源项目 larksuite/cli。官方给它的定义很直接：这是一个“面向人类和 AI Agent 的飞书开放平台命令行工具”，覆盖消息、文档、多维表格、日历、邮件、任务、会议等核心业务域，一共提供 200 多个命令和 19 个 AI Agent 技能。

这句话最值得看的地方，不是“200 多个命令”，也不是“19 个技能”，而是前面那半句：面向人类和 AI Agent。

也就是说，飞书 CLI 不是一个单纯给人用的工具，它从一开始就在按“Agent 原生”的方向设计：命令有智能默认值，输出尽量结构化，目的是把 Agent 的调用成功率尽量往上提。

这件事背后传递出来的信号其实很清楚：平台欢迎 Agent 通过自己的命令和接口来工作，而不是让它们绕过平台，自己去野蛮接管。

AWS 官方博客前阵子就举了个很具体的例子：利用 Kiro CLI 这样的通用 AI Agent 运行时，通过 Agent Client Protocol 接入飞书，把飞书能力当成 Agent 可用的工具。Agent 可以通过 CLI 去调用飞书功能、上传文件、发送消息，而平台提供的是一层桥接能力。

这其实已经说明问题了：现有协作平台正在把组织里的上下文和工具能力主动开放出来，让 Agent 在平台生态里工作。与其等 Agent 跳过去，不如先把路修好。正如 Feishu CLI 的 README 里说的，这条通道为 IDE 之外构建 AI Agent 提供了一个强大而且成本不高的基础。

更值得注意的是，飞书并不只押注 CLI 一条路。它还有一个同类场景下的项目：MCP 服务器。这个服务基于 Model Context Protocol，也就是模型上下文协议标准，让 Agent 可以通过统一协议去发现和调用飞书的各种工具能力。

相关社区项目已经提到，现在飞书同时支持 MCP 服务器和独立 CLI 两种方式，Agent 能自动选择更合适的路径来操纵飞书。

整体看下来，飞书的路线其实很明确：不是让 Agent 来取代平台，而是把平台做成 Agent 的工具箱，让 Agent 来调用。

CLI 代表的是“平台定义命令，Agent 来调用”；MCP 更像是给 Agent 提供一层语义化的能力发现协议。两者放在一起，基本已经把平台对 Agent 生态的开放策略画出来了。

AI 杀 SaaS 这套叙事：半对，半错

那“AI 会杀死 SaaS”这个说法，为什么会流行？

原因也不复杂。很多人担心，智能 Agent 最后会成为通用入口，大家不再需要专门的应用界面。这种情绪其实早就反映在资本市场里了：不少 SaaS 公司估值下杀，有分析师干脆直接喊出 “AI kills SaaS” 或者 “Agents replace software”。

但问题是，这种判断太容易一刀切。

业界其实早就有人在往回拉。比如 Leonis 资本就提过一个很关键的观点：市场一看到 Agent 直接操作软件的演示，就立刻断定“SaaS 已死”，可现实是，不同类型的软件站位不一样，AI 对它们的冲击也完全不同。

如果把软件分层来看，这件事就会清楚很多。

对于那些高度依赖 UI、流程相对固定的 SaaS，比如简单的任务管理、表单录入、轻量工作流，这类产品的价值确实可能被 Agent 一点点啃掉。因为 Agent 不需要传统界面，它只要能完成动作就行。

但对于那些深度嵌进企业流程、背后连着大量业务逻辑、权限体系和治理规则的平台，比如 ServiceNow、Salesforce 这一类，情况就完全不同了。

这些平台未必会被替代，反而可能继续往上长，变成 Agent 的控制平面。因为流程、权限、数据和审计，本来就是智能体真正进入执行层时必须遵守的规则和上下文。

如果这些平台反应够快，先一步把授权、审计、治理和调用接口补齐，它们不但不会被这轮重构伤到，反而有可能从中受益。真正危险的，反而是那些还停留在旧架构里、不愿意转型的 SaaS。

所以更准确的说法应该是：

AI 不是直接消灭 SaaS，而是在软件价值链内部重新定价。

模型本身很重要，但只有模型远远不够。真正决定能不能落地的，是组织上下文、规则体系和治理能力。Agent 需要的从来不只是一个功能，而是能不能拿到真正可用的数据、可解释的权限和可审计的执行路径。

平台 vs 新创：真正拼的，是组织上下文的深度

这一点，在“自救”与“重写”的对抗里尤其明显。

AI 原生创业公司的赌注很直接：从零开始，构建一套完全为智能体设计的工作系统，干净、轻、快，不受历史包袱拖累。开源社区、代码工具、各类 agent-first 产品，很多都在往这条路走。

相比之下，飞书、Salesforce 这些老牌平台押注的是另一条路：你可以重写软件，但你很难重写一个平台十年积累下来的组织图谱、业务数据、权限链和流程规则。

真实企业里，账号、权限、审批链、业务规则这些上下文，不是几行文档能复原的。很多都是一代代团队摸索出来的经验，天然就带着护城河。要把这些东西完整迁到一个新系统里，成本极高，也极难。

所以平台阵营现在做的事，不是死守旧界面，而是主动把这些上下文开放给 Agent。

飞书 CLI 和 MCP 的价值，就在这里。Agent 在飞书里拿到授权之后，继承的是飞书内部已有的权限体系和数据访问边界。也就是说，它可以使用飞书里的消息、日历、文档，但同时也必须遵守飞书原本的组织结构和权限管理。

这背后其实只有一个关键变量：

企业上下文到底是可迁移资产，还是不可复制的护城河？

如果它可以被轻松抽象、迁走，那新创当然更灵活；但如果它本质上深埋在组织里、系统里、权限链里，那平台路线就会天然更占优势。

现实里，答案大概率是混合的。

确实已经有不少企业在尝试自研 AI 工具，甚至已经在一些边缘流程上替代了部分 SaaS 功能。像简单报表、审批机器人、局部工作流，这些地方更容易先被改写。

但这类替代大多还是渐进式的。真正核心的 CRM、ERP、主数据和复杂流程系统，重构的难度和代价都太高，不可能一夜之间完成。

所以我更倾向于一个判断：企业上下文依然是很难复制的壁垒。

大型平台现在做的，就是尽量把这层价值留在自己体系里，把 Agent 权限管理、数据治理、调用接口和执行留痕补起来。只要一个平台已经深嵌到真实业务里，又掌握了完整权限体系，它的价值就不只是没掉，反而可能更高。

CLI 与 MCP：从预定义命令，走向语义化能力发现

不过，飞书 CLI 很重要，不代表它就是终点。

CLI 的逻辑，本质上还是“平台先把命令定义好，Agent 再来调用”。这意味着它的能力边界，依赖于开发者事先列出来的命令和参数。对于复杂业务来说，预定义命令再多，也总会碰到天花板。

如果 Agent 真足够聪明，它最终需要的其实不是更长的命令列表，而是更高一层的东西：

平台到底能做什么、这些能力之间怎么组合、限制条件是什么、什么时候该调用哪一个。

这时候，MCP 这种能力发现协议的重要性就开始显出来了。

Model Context Protocol 的核心价值，就是标准化模型如何发现、选择和调用工具。它不是让 Agent 死记硬背 API，而是给它一种统一的方式去理解平台能力。

你可以把 CLI 理解成给 Agent 发了一张技能树；而 MCP 更像是给它一本技能总目录。前者是已经封装好的动作集合，后者则是面向未来的能力语义层。

飞书现在同时布局 CLI 和 MCP，其实正说明它也知道一件事：CLI 更像是 Agent 时代的第一步，而不是最后一步。

也许今天我们看到的还是“平台定义命令，Agent 调命令”；但真正的终局，很可能会往“平台暴露能力语义，Agent 自己判断怎么组合调用”那边走。

“数字员工”时代：真正的难题不是会不会干活，而是谁来管

一谈到 Agent，很多人都会自然地用“数字员工”来形容它。

这个比喻并不夸张。AI Agent 的确越来越像会工作的员工：它能完成任务，能串流程，能处理部分重复劳动。

但真正的问题也从这里开始。

这些数字员工谁来管？它们的绩效怎么评估？它们出错了谁负责？它们能访问什么数据、不能碰什么数据？它们做出的决策怎么留痕、怎么审计、怎么回滚？

到目前为止，各大平台在这些问题上其实都还处在早期阶段。

飞书、Salesforce 这些厂商当然已经在提供 API、权限和基础治理框架，但真要建立一套完整的 Agent 治理体系，现在还远没到成熟的时候。

这也是为什么很多企业今天对 AI 的关注点已经从“能不能接进去”，转向“能不能安全、可信、可控地接进去”。

因为一旦 Agent 开始进入真实流程，权限、审批链、审计日志这些过去偏后台、偏合规的话题，会直接决定企业敢不敢放它上生产。

谁能访问什么数据，谁能触发什么动作，谁来审计，谁来兜底，这些都不再是边角问题，而会变成 Agent 能不能真正落地的前提。

从这个角度看，Incumbent 平台反而可能比新创更有优势。因为它们原来就已经在管理人的组织结构、权限和流程。现在做 AI，至少不是从零开始，而是可以在已有体系上给 Agent 打通一部分路。

像 Workday 最近推出的 Agent System of Record，就很有代表性。它其实是在把“数字员工”正式纳入管理系统：跨平台权限分配、任务调度、决策日志、细粒度角色控制、全程可审计。

这背后说明的，不只是一个新功能，而是一种更深的竞争方向：谁先建立起数字员工的组织操作系统，谁就更可能在下一阶段占住位置。

结论：这场博弈最后会拼什么

回到文章开头的问题：飞书 CLI 到底只是一个产品动态，还是一扇让我们提前看到企业软件未来的窗？

我更倾向于后者。

飞书 CLI 说明的，不只是飞书多了一个命令行，而是平台阵营已经想明白了一件事：Agent 不是要绕过我，而是要通过我工作。

如果把这场博弈压缩成两条路线，大概就是这样：

新创路线（Agent-First）

• • 从零构建 Agent 专用工作系统
• • 架构干净，适合围绕 AI 重做
• • 缺点是组织上下文沉淀不够，重建成本高

平台路线（SaaS 自救）

• • 在现有协作平台上开放接口和执行层
• • 把原有数据、权限和业务流程留给 Agent 使用
• • 优点是上下文深、治理成熟
• • 难点在于要重写架构，也要承担治理责任

最后谁赢，很可能就看下面几个变量：

• • 上下文深度：企业十年积累的数据、审批链和客户信息，到底能不能迁走
• • 开放程度：平台愿不愿意真正把能力开放出来，并为 Agent 设计灵活接口
• • 治理成熟度：谁能先建立面向数字员工的安全、审计、权限和责任体系

我的倾向判断还是那句：

平台路线更有戏。

原因很简单。最后决定胜负的，往往不是谁的模型更通用，而是谁更深地嵌进了行业、岗位、流程和信任关系里。

那些真正掌握了场景深度、数据质量、权限关系和决策痕迹的平台，就算必须重写架构，也依然手里握着新玩家最难补齐的那层东西。

所以飞书 CLI 和 MCP 的推出，真正说明的不是“平台在做一个新功能”，而是平台在告诉市场：我们不会把 Agent 放在平台外部竞争，而是要把它留在平台内部工作。

未来企业软件真正的新护城河，也不会只是 UI、席位和生态，而会越来越多地围绕这些要素重建：

• • 数据质量
• • 上下文深度
• • 权限与治理
• • 信任与审计

谁能在这些层面先跑出来，谁就更有机会在 AI 时代的企业软件市场里占据高点。

参考资料

• • 飞书 CLI 项目文档
• • 企业 AI 分析报告
• • 飞书 Agent 与 MCP 文档
• • Salesforce / Workday 官方研究