从SaaS 到Agent，企业软件会消失还是重生？

公有云、私有化、订阅还是结果付费：企业软件正在走向混合形态

模型和数据，到底放云端还是放本地？ 这个问题没有标准答案，但有清晰的判断框架。当 Agent 比员工还多，SaaS 凭什么继续按人头收钱？ 四位嘉宾完成了一次漂亮的"破—立—定音"。

主持人吴昊：

开场还有两个分歧很大的问题。

第一个是：未来大型企业会不会都部署自己的专属大模型？

第二个是：当Agent数量可能比员工还多，SaaS 还能不能继续按“人头/账号”收费？

我们先聊第一个“部署与数据”的问题。而星兄，我知道您过去是坚定的SaaS 拥护者，但现在似乎越来越理解甚至支持企业去掌握自己的数据和模型能力，为什么会有这种转变？

赵而星：

准确地说，我是从“坚定的SaaS 拥护者”，逐渐转向了“理解中国市场特有的私有化需求”。

很多企业老板都会问一个直击灵魂的问题：“我为什么要把最核心的数据交给你？”这个问题在SaaS 时代就存在，到了AI 时代更是一脉相承，甚至更加敏感。

我的核心体会是：当企业所有的业务数据，都能被“企业自己的AI”安全地访问、并随时用于驱动工作时，效率的提升才是最明显的。所以我越来越相信，可控的数据主权，加上“能被AI 随时调用的数据”，会成为未来企业数字化的重要基础。

至于最终的产品形态到底是纯SaaS 还是私有化，我不认为会有唯一的标准答案。信任SaaS、不愿自己承担运维成本的客户，会继续用公有云；而高度重视数据主权的客户，必然会选择私有化或更可控的专有云方式。

所以我的判断是：中国市场未来很长一段时间内，都会是“混合的软件、混合的AI 与混合的部署模式”并存。

主持人吴昊：

冯斌，ONES 的客户里有很多芯片、金融等对数据极度敏感的企业。在AI 时代，它们是不是更倾向于把大模型直接部署在自己的私有环境里？

冯斌：

要看场景。

芯片行业高度重视保密，核心图纸等数据绝对不能离开企业边界，这种场景毫无疑问需要私有化部署。但一个大型企业里还有很多任务，并不涉及最高敏感度的数据。比如处理一般性方案、检查非敏感条款、翻译公开资料，这些任务完全可以使用云端那些能力更强、更灵活、运维成本更低的公有大模型。

我们可以算一笔账：如果为了绝对安全，把所有事情都放在本地，安全性是上去了，但算力成本和模型运维的压力会很高；反过来，如果全放云端，虽然能力更新快、使用灵活，但要管理数据泄露风险。

所以我认为，大部分企业最终都会走向“混合模式”，并且会在工程上建立一套“按数据敏感度和任务风险分级” 的路由机制。这不是简单地争论“云端好”还是“本地好”，而是让不同任务放在不同地方。

张云龙：

我非常认同而星和冯斌的看法，部署模式不会是绝对的“二选一”。企业最终一定会根据自身的业务场景、数据敏感度和综合成本去算一笔账，做出最适合自己的选择。

主持人吴昊：

好，那我们接着聊开场时抛出的第二个大悬念——收费模式。云龙兄，你刚才提到，未来SaaS 可能没法继续按“人的席位”订阅来收费了，为什么这么笃定？

张云龙：

因为未来企业里的Agent数量，大概率会比真人员工还要多。

想象一下，如果未来一个员工带着十个Agent 协同工作，这十个Agent 该怎么定义和计费？它是一个后台进程、一个领域专家，还是一个长期存在的“数字员工”？这个问题现在全行业都没有统一的答案。

所以我不认为未来还会简单按照人的席位收费。但如果不按席位，按什么收费，我现在也没有标准答案。

按Token 收费也不一定合理。Token 会越来越便宜，客户也很难从Token 数量理解自己到底得到了什么价值。所以，寻找新的“价值度量衡”，是SaaS 行业接下来的必修课。

冯斌：

我补充一个视角，收费模式最终还是要回归到“产品形态”和“价值可衡量度”上。

如果产品的价值很容易量化，比如某些营销工具，能明确计算出带来了多少流量、多少线索和转化，那“按结果收费”就有机会成立。

但对于很多协同办公、研发提效类的产品，它的价值是隐性的，很难单独剥离出来精确计算。在这种情况下，传统的License或订阅模式，大概率还是会占据主流。为什么？因为越简单的收费方式，越能降低买卖双方的“交易成本”，客户在采购时也更容易理解和做决策。

主持人吴昊：

冯斌提到了一个非常核心的词——“交易成本”。确实，复杂的计费逻辑往往会把客户挡在门外。而星兄怎么看？在经历了各种收费模式的探索甚至踩坑后，您认为“订阅制”依然会是企业软件主流的原因是什么？

赵而星：

我认为订阅制之所以难以被颠覆，至少有三个最关键的现实因素。

第一，是“责任归属”问题。AI 在可见的几年里，仍然会犯错。大家讨论“按结果付费”时，往往只盯着好的结果：我帮你增加了多少收入、节省了多少成本。但反过来想，如果AI 做出了错误的决策导致了损失，服务方是否愿意为这个“错误的结果”买单？是否有能力承担相应的连带责任？

第二，是“结果归因”问题。 现实世界里的商业结果，是很多因素共同造成的。比如销售收入增长了，这可能跟产品、市场、品牌、渠道甚至销售团队都有关系。如果你无法证明这个结果主要是由你的工具促成的，凭什么按结果收费？

第三，是一个经常被忽略的“预算可预测性”问题。ToB 采购是要做年度预算的。如果按用量或按结果收费，企业不知道明年到底会花多少钱，这会对现有的企业财务预算机制形成巨大挑战。计费规则越复杂，客户越难理解，交易摩擦也就越大。

所以我的结论是：“按结果付费”肯定会存在，尤其是在那些结果极其清晰、可完美归因的特定场景里。但我不认为它会很快超过订阅，成为所有企业软件的主流。

主持人吴昊：

听完三位嘉宾的拆解，我们可以下一个结论了：未来不会只剩一种收费方式，而是会按“价值形态”分层。

越接近可验证、可归因的业务结果，越可能按量或按结果收费；越接近复杂协同、基础设施和长期运营，订阅或混合计费就越现实。

而收费方式的背后，其实是一个更本质的命题：产品到底交付什么价值、承担什么责任。

这也正好解释了开场快问快答里，我们四个人达成的那个共识：FDE（前线部署工程师）不应该只是把AI 部署到客户环境里，而应该对业务结果负责。

一旦企业软件从“卖工具”转向“交付结果”，责任就是双向的。供应商不能再只负责“模型能否调用、页面能否打开”，还要理解客户真实的工作链，明确数据、权限与人工接管的边界，建立效果评测体系，并在上线后持续处理反馈；与此同时，客户也必须开放足够的业务上下文，与供应商共同定义“什么才算有效结果”。

因此，结果付费不是简单换一张价格表，而是把产品、交付、责任和客户协作方式一起改掉。 没有这套能力做支撑，所谓“按结果收费”很容易变成一个听起来很先进、实际根本没法结算的口号。

当系统开始自演进，人还要不要守最后一道关？

对话的终点，落在了最让人兴奋也最让人不安的地方：当 AI 开始自己改自己，人还要不要守关？ 三位嘉宾给出了三种互补的答案——工程分层、实验清醒、组织视角——却在同一句话上汇合。

主持人吴昊：

最后一个问题，我们聊聊“自演进”。 

如果未来的Agent 可以自己发现问题、修改Skill、补充语料、调整流程，甚至自己修改代码和架构，那人是不是就可以逐渐退出了？谁先接近“无人值守”，谁是不是就会在竞争中对同行形成巨大的“速度差”？ 

冯斌，你们ONES 现在做到哪一步了？

冯斌：

这个问题极其关键，但我认为“自演进”至少要分两个层面来看，不能一概而论。

第一层，是“物料级”的演进，比如语料、Skill 和周边知识库。 举个真实的例子：如果客服Agent 回答得太冷淡，或者某类问题缺少业务信息，系统可以自己分析出是Skill 没写好，还是缺了语料，并自动生成修改建议。 现阶段，这些建议仍然需要人来确认。我们的策略是：信任是攒出来的。如果同类修改经过十次、八次验证，成功率已经很高，我们就可以逐渐把控制权放给AI，但同时必须准备好出问题时的“兜底方案”。

第二层，是“架构级”的自修改，也就是系统修改自身的代码和结构。这个更复杂。 我们现在会跑一些“夜间Loop”：晚上让系统持续跑测试、寻找性能瓶颈并尝试修改代码，第二天早上再给人类汇总“昨晚改了什么、为什么改”。这个过程已经能跑起来了，但我不会把它称为“完全自演进”，它目前更像是一种Loop 工程。

真正要让系统修改自己，前提是评测体系、沙箱隔离、权限管控、一键回滚和故障恢复这套Harness（驾驭工程）全部就绪。

主持人吴昊：

聊到测试，ONES 内部测试用例的设计和最终的代码评审，主要是AI在做，还是人在做？

冯斌：

测试用例可以根据代码、需求文档甚至历史用户反馈自动生成。对于那些简单、边界确定的用例，已经不再需要人去逐条确认了。

但当上下文很长、业务逻辑很复杂时，AI 确实容易“漏测”。所以我们现在的流水线是：先让多层AI 进行交叉检查，最后由人来确认“测试策略是否被正确应用”。

核心的人机分工原则是：不会让人去复核机器已经能执行的“硬规则”。 机器和自动化脚本先跑，如果连硬规则都过不了，就直接打回，绝不浪费人的时间。人的精力，只留给那些真正需要业务判断、架构考量和品味把关的部分。

至于什么时候能完全“无人值守”、完全不让人介入？我们的底线是：只有在AI 的成功率已经足够高，或者即使出错、其影响范围也被严格隔离和控制得很小的场景，我们才会放心地把最后一道关卡交给机器。

主持人吴昊：

而星兄，你对自演进更谨慎一些。

赵而星：

我做过让Skill 自我优化的尝试，至少目前的实验结果只能说差强人意。

原因主要有三个。

第一，模型本身在快速变化——在这一代模型上验证有效的Skill，到了下一代模型未必仍然适用，自演进的地基本身就在移动。第二，自演进需要一套足够准确的评测标准，但现在的AI 判断本身也可能出错——让一个会犯错的裁判去给选手打分，这个闭环本身就不可靠。第三，链路越长，错误越可能累积——每一步的小偏差，经过多层传递后会被放大成系统性错误。

所以我的态度是谨慎乐观。

冯斌和云龙分享了很多非常好的案例，我完全认同他们的方向。但真实实践里，一定也会有跑错方向、甚至改坏系统的时候。我的体会是：加了越多AI，测试的重要性反而变得越强。 总要有一个最后的把关者——在现阶段，人必须守住最后一道关。

张云龙：

我想补一个不一样的视角。SES 的自演进，跟一个研发系统自己去修改代码和架构，其实不完全是一回事——它更多是在解决一个组织问题。

它的演进逻辑是这样的：每天有更多的人在用，就会暴露出更多的问题。比如财务数据对不上了，大家就会去追问原因，然后把缺失的上下文和规则补回去。系统就是在这种使用 、反馈和修正的循环里持续演进。

我对工程上的理解是，一个好的架构，从一开始就不应该把目标设成“永远不出问题”。问题一定会存在，这是前提。

好架构真正要做的，是两件事：第一，把问题造成的危害降到最低；第二，用最快的速度发现问题。

如果影响范围可控、监控足够及时，就可以让AI 做更多事情。不是等它达到百分之百正确才开始，而是在0 和1 之间找到一个能够安全推进的位置。这个位置找到了，自演进才能真正跑起来。

主持人吴昊：

这可能是今天非常重要的一个结论。

第一个反转：AI Coding 并没有让软件工程消失。 恰恰相反——当代码、测试、流程都能被自动生成的时候，架构、验证、监控、权限和回滚，反而变得更重要。 

第二个反转：真正的自演进，也不是让AI 在没有边界的情况下随意修改一切。 而是让系统在一个可验证、可回滚、影响可控的范围里，不断地学习、修正、进化。

换句话说，AI 让“生成”变得廉价，却让“判断与约束”变得昂贵。 这或许就是今天这场对话，最想留给每一位ToB 从业者的判断。

企业软件没有消失，旧的运行规则正在消失

这场对话没有给出“SaaS 必然消失”或“Agent可以包办一切”的简单答案。

它真正提供的，是一组更接近现实的判断：

关于价值——只卖账号、界面与固定流程的软件，会越来越难证明自己的价值。

关于组织——AI 不会自动完成组织转型，却正在迫使企业重新设计任务、岗位、责任与协作方式。

关于部署——公有云与私有化不会只剩一种答案，数据敏感度、效果、成本与运维能力，会推动混合模式长期存在。

关于收费——结果付费不会立刻取代订阅，归因、责任、预算与交易成本，仍是任何新商业模式都必须穿过的现实关口。

关于演进——系统越接近自演进，测试、监控、权限、回滚与人的最后把关，就越不能缺席。

被重写的不是“SaaS”这个名字，而是企业软件的运行规则。

未来的软件，将不再只是供人操作的工具。它会逐渐成为组织中人与Agent 共同工作的基础设施：理解业务上下文，调用知识与工具，执行任务，接受验证，再把每一次结果沉淀为下一轮的能力。

真正稀缺的，也将不再是某个功能，而是企业能否把数据、规则、权限、流程、验证和经验组织成一套可被AI调用、又能对结果负责的工作系统。

谁能更早完成这套重构，谁就更有机会，把模型能力转化为组织能力，再转化为持续的经营能力。

（本文整理自 K+Talk No.119 直播实录。）