SaaS 的隐含前提#

传统 SaaS 的产品边界，基本对应旧组织边界。

销售用 CRM，财务用 ERP，HR 用 HRM，客服用工单系统，项目经理用项目管理工具。每个部门有自己的软件，每个岗位有自己的账号，每个员工对应一个 seat。

这套模式背后有几个隐含假设：

• 公司由部门组成；
• 部门由岗位组成；
• 岗位通过软件界面完成工作；
• 流程靠人推动：人填表、人审批、人复制粘贴、人跨系统沟通；
• 软件的价值可以按“人头”收费。

所以 SaaS 不是中性的技术形态。它其实是把工业时代和互联网时代的科层组织数字化了。

这也是为什么美国 SaaS 能做得很大。美国企业更愿意接受标准化流程、订阅付费、云端托管和生态集成。一个企业买几十上百个 SaaS，员工每天在 dashboard、表单、审批流之间工作，是可以成立的。

但这不意味着 SaaS 的价值只在“写软件”。企业级 SaaS 真正难的部分，恰恰不是开发，而是长期维护、支持和信任：稳定性、SLA、灾备、培训、迁移、权限、审计、数据隔离、合规，以及和客户已有系统的集成。

AI 可以显著降低开发成本，但不会自动消灭这些运营和治理成本。

为什么美国 SaaS 股票跌#

美国 SaaS 股票大跌，不是因为市场认为企业软件明天没人用了，而是几个估值假设同时被打破。

第一，利率变了。SaaS 是典型长久期资产：今天利润不高没关系，市场买的是未来多年增长。利率上升后，未来现金流折现价值下降，估值倍数自然压缩。

第二，增长放慢了。美国 SaaS 渗透率已经很高，很多品类从新增客户爆发进入存量替换、续费涨价和交叉销售阶段。ARR 增速从 30% 到 40% 掉到十几二十，市场就不愿继续给高倍数。

第三，也是最关键的，AI Agent 挑战了 per-seat 模型。

传统 SaaS 早期很大程度上按人头收费：一个销售一个 seat，一个客服一个 seat，一个 HR 一个 seat。当然，后来很多企业 SaaS 已经不再只靠 seat 定价，而是转向 usage-based pricing、transaction-based pricing，按调用量、处理量、交易量、自动化次数或业务结果收费。

但这个变化主要改变的是收费单位，并没有真正改变 SaaS 背后的组织形式。软件仍然围绕部门、岗位、权限、表单、审批流和 dashboard 来设计；人仍然在系统之间切换，推动流程前进。也就是说，pricing model 进化了，但 operating model 还停留在旧组织架构里。

所以 AI Agent 的冲击不只是“seat 数减少”。更深的问题是：如果一个 Agent 可以跨系统完成多个操作员的任务，企业为什么还要把工作拆成那么多岗位界面和软件入口？

市场真正担心的是：

• seat 数减少；
• 单价涨不上去；
• AI 推理成本反而上升；
• 价值被 OpenAI、Anthropic、云厂商或新的 Agent 公司截走。

过去 SaaS 的护城河是 workflow + UI + 数据 + 集成。现在 Agent 可以绕过 UI，直接读数据、调 API、执行流程。那些只是“表单 + dashboard + approval flow”的 SaaS，当然会被重新定价。

所以，市场杀的不是企业软件本身，而是旧 SaaS 的估值叙事。

中国 SaaS 的问题不一样#

中国 SaaS 渗透率本来就不高，这说明中国和美国面对的并不是同一个问题。

美国的问题是：成熟 SaaS 会不会被 AI-native app 替代？

中国的问题是：SaaS 模式还没完全跑通，就进入了 Agent 时代。

中国企业软件市场更偏项目制、定制化和一次性采购。很多老板和部门并不愿意为了标准 SaaS 改自己的流程，而是希望软件适配自己的流程。政企、制造、医疗、金融又对数据上云有天然顾虑。再加上客户成功和售后成本高，ARPU 未必撑得起美国式 SaaS 模型。

因此，AI 在中国更可能强化的不是纯 SaaS，而是“AI + 私有化部署 + 行业服务 + Agent 工作流”。

这很可能是一条绕过美国 SaaS 路径的企业软件演化线。

中台为什么曾经必要#

过去为什么需要中台？

因为写流程很贵。

一个业务流程要程序员调研、开发、测试、上线、维护。如果每条业务线都重复写会员、订单、客户、权限、库存、支付、营销，那组织成本会爆炸。所以大型企业需要把共性能力沉淀下来：用户中心、订单中心、商品中心、支付中心、营销中心、数据中台、风控中台。

中台的理想，是让前台快速创新，后台保持稳定。

但中台后来常常变味。原来前台等后台，现在前台还要等中台。中台不直接对业务结果负责，却掌握接口和资源。抽象越来越厚，离真实场景越来越远，最后变成新的官僚层。

所以，中台本质上是旧组织面对互联网速度时的一种补丁。

Agent 如何 turn the table#

过去中台的经济学是：

写流程很贵，所以要写一次，多处复用。

Agent 改变的是边际成本。

临时理解需求、临时组合 API、临时生成流程脚本，成本从“程序员时间”变成了“tokens + 算力 + 权限治理”。

这会让很多过去必须产品化、中台化的流程，变成即时流程。

例如销售说：

“把上季度华东区所有续约风险客户找出来，结合工单、回款、拜访记录，生成一个优先级列表，并给每个销售创建跟进任务。”

过去这可能要 BI、CRM、财务、工单系统一起排期开发。现在 Agent 可以临时调用这些 API，生成一次性工作流。

这就是 turn the table。

但这里有一个关键边界：Agent 可以临时写流程，不等于企业不需要中台能力。

企业仍然需要统一身份、权限体系、数据口径、业务对象定义、API 目录、审计日志、安全策略、异常处理和人工确认机制。

被颠覆的不是中台能力，而是中台组织、固化流程和大量预开发。

API 编排：从系统到任务#

API 编排，就是把分散系统组合成一个可执行的业务流程。

比如销售说：

“帮我给华美做下周拜访准备。”

Agent 背后可能会：

1. 调 CRM API，查客户档案、联系人和历史拜访记录；
2. 调合同系统 API，查合同、到期时间和未完成条款；
3. 调财务 API，查回款、欠款和开票状态；
4. 调工单 API，查最近投诉和未解决问题；
5. 调邮件或微信记录 API，提取最近沟通重点；
6. 调知识库/RAG API，查历史方案和交付文档；
7. 调日历 API，寻找可约时间；
8. 调 LLM API，生成拜访简报、风险点和建议话术；
9. 调任务系统 API，创建 follow-up checklist。

销售看到的不是九个系统，而是一份结果：

“华美下周拜访简报：合同 6 月到期，最近有 2 个未关闭工单，财务还有一笔 18 万回款未到账，建议本次重点谈续约和售后响应。已建议三个可约时间。”

这才是 Agent 时代的软件形态：不是人在多个 SaaS 之间切换，而是 Agent 围绕业务目标动态调用工具。

新底座不是 SaaS，而是 Agent 治理层#

未来企业软件不会因为 AI 而消失，但价值会迁移。低壁垒、薄 UI、标准 CRUD、按 seat 收费的 SaaS，会继续被压缩。

但更重要的是：即使身份、权限、数据语义、业务对象、流程引擎、工具注册、审计、异常处理、人工确认这些能力仍然重要，它们也未必会继续以传统 SaaS 或中台模块的形态存在。

它们会被 Agent 的治理、管理和观测系统重新吸收：

• Guardrails：定义什么能做、什么不能做、哪些动作必须人工确认；
• Agent management system：管理 agent 注册、授权、任务分配、生命周期和能力边界；
• Audit：记录每一步为什么做、调用了什么工具、用了什么数据、谁批准的；
• Observability：观测运行轨迹、失败率、成本、延迟、幻觉风险和越权风险；
• Policy engine：表达组织规则、合规边界、审批策略和风险阈值；
• Human-in-the-loop：在高风险动作上建立人工确认与追责链。

所以，新底座不是传统意义上的 CRM、ERP 或中台，而是 Agent governance & observability layer。

旧 SaaS = 把部门和岗位数字化。

旧中台 = 把流程预先固化成平台能力。

Agent 时代 = 业务能力下沉为工具和 API，流程生成权交给 Agent 临时组合，而真正的控制点上移到治理、观测、审计和人工确认。

所以，SaaS 不会简单死亡。但 SaaS 作为旧组织结构的皮袋，会被重新拆解。能退到底层成为可靠工具和数据源的会留下；只停留在界面和固定流程上的，会被新的 Agent 治理与执行层吃掉。

这不是 SaaS 的终结。

这是企业软件从“人用系统”走向“Agent 执行组织意图，并由治理系统约束 Agent”的开始。