没人登录了，SaaS还怎么收钱？Agent时代先丢的其实是归因

“没人登录了，SaaS还怎么收钱？”表面看，这是一个商业模式问题；但如果把场景再往前推一步，你会发现它首先是一个流量与归因问题。

当员工不再反复打开 ERP、CRM、HR、财务系统，而是在钉钉、企微、对话框、工作流或 Agent 平台里直接发出任务，由 AI 在后台自动调用接口、处理数据、返回结果时，SaaS 厂商失去的不只是“账号收费”的基础，还失去了过去那套最熟悉的用户识别方式：谁在用、从哪来、哪一步产生价值、哪一类行为值得收费。

也就是说，Agent 时代先消失的，不只是登录页，而是“人物流量”的表象。真正留下来的，是一条更难看见的任务流量链。

新闻与环境拆解

为什么“按账号收费”开始失灵

材料里对这个问题讲得很直接：过去二十年，中国企服 SaaS 的收费方式很稳定，要么买断，要么按账号、按人头、按年付费。它之所以长期成立，是因为“使用者”与“付费单位”之间的关系很清楚——员工登录系统，企业为这些人买账号。

但现在这个基础正在被 AI 和 Agent 改写。很多操作不再需要员工自己进入系统点击页面，而是通过对话入口、工作流平台、企业助手或上层 Agent 发出指令，由后端自动调 SaaS 的接口完成。系统仍在工作，但“登录的人”越来越少，真正频繁调用系统能力的，变成了一段代码、一组任务、一个自动化流程。

一旦使用行为从“人登录软件”变成“Agent调用能力”，按账号收费就会越来越像旧世界的收费残影。因为用户可能只剩下一个对话入口，但后台调起了十几个 SaaS 能力；你再按 seat 收费，客户自然会问：我买的是界面，还是结果？

从卖前端门票，到卖底层能力

材料里把这种变化概括成“微交易”。意思很简单：扔掉包年门票，回到底层按次、按量、按调用收费。谁调了一次接口、谁跑了一次风控、谁处理了一批数据、谁调用了一次工作流，就为这次能力买单。

这种模式之所以会被越来越多企业接受，不只是因为技术变了，也因为采购逻辑在变。大单、长周期、集中审批、重实施的采购方式，正在被“低门槛试用—跑通场景—自然扩量”取代。初期调用可能只花几十块，业务部门甚至不用走传统采购链路；但一旦真正嵌进业务流，调用频次和总价值反而可能更高。

所以，微交易并不只是收费颗粒度变小，而是 SaaS 被重新嵌进企业业务的方式变了——从“买一个系统”变成“持续调用一个能力”。

SaaS 真正卖的，开始不是软件，而是结果

材料中最有价值的一段，是对“别去拼算力单价”的提醒。因为对垂直 SaaS 来说，真正有溢价的从来不是 GPU 价格、调用单价或者底层 token 成本，而是业务结果。

你不是在卖“一次接口调用”，而是在卖一次税务风险规避、一次合同审查结果、一次库存优化决策、一次供应链锁定能力、一次高准确率的业务判断。也正因为如此，材料里才提出“按结果收费”比“按算力收费”更像垂直 SaaS 的真正出路。

这意味着一个重要变化：SaaS 的产品边界会越来越往下沉。前端界面、交互壳子、模块罗列不再是核心护城河，真正决定收费能力的，是后台那套行业知识、规则引擎、语义层、风控逻辑和结果准确度。

但转型最难的，根本不是定价表

材料里也讲得很残酷：从按账号收费切换到按量或按结果收费，中间有一条死亡之谷，而且至少有两道关。

第一道是组织关。过去很多 SaaS 靠庞大的销售、实施、关系网络推动大单，现在单次调用收费极低、扩张依赖产品渗透和自动调用，原来的销售打法会迅速失效，销售与实施团队必须被重组。

第二道是现金流关。过去先收年费、预付款，账上好看；现在是先使用、后结算，新模式还没完全跑起来，旧模式又开始失效，账面会出现明显断层。很多 SaaS 不是看不懂趋势，而是可能根本熬不过这个过渡期。

这也是为什么材料里不断强调：这不只是技术升级，而是商业模式、组织结构和财务模型的同步重构。

行业为什么会进入“软件公司大逃亡”叙事

补充材料进一步把这种焦虑拉高了一个量级。无论是海外厂商股价承压、传统 ERP 增速下滑、裁员推进 Agent 化，还是国内 SaaS 拉新放缓、客户预算切向 AI、大量投资机构重新审视 SaaS 的替代风险，本质都在说明同一件事：软件本身正在被重新定义。

过去企业买的是“系统”；现在越来越多企业想买的是“一个能直接工作、能直接给结果的能力”。这会让传统产品形态、销售方式、交付模式和估值逻辑一起松动。

但这并不意味着所有 SaaS 都会死。真正有机会活下来的厂商，往往有两种路径：

• 把自己变成 Agent 背后的核心能力层
• 把自己变成结果导向的行业基础设施层

而这两条路，都要求你先能识别：到底是谁在调用你，你提供了什么结果，你在整条任务链路里贡献了多少价值。

从新闻到用户路径的归因问题

如果说“没人登录了”首先是商业模式问题，那它落到增长、产品、数据和技术团队头上时，最先爆炸的其实是归因体系。

因为传统 SaaS 的很多关键指标，默认都建立在“人”这个主语上：

• 有多少账号
• 有多少登录
• 哪些人在活跃
• 哪些用户触发了功能
• 哪些企业使用深度高
• 哪条线索最终签约

但在 Agent 时代，这些指标会变得越来越不稳定。因为真正发生价值的，不再总是“人点击页面”，而是“任务调用能力”。人物流量开始隐身，任务流量开始抬头。

问题会集中出现在四个层面。

第一，谁是用户变模糊了。
是最终下达需求的员工？是发起工作流的管理者？是调用你接口的上层 Agent？还是把你嵌进流程的集成平台？如果还用老办法统计“有多少人登录了系统”，你看到的可能只是冰山尖。

第二，价值发生点往后台迁移。
以前价值容易和前台操作绑定，比如注册、登录、创建工单、审批流程、导出报表。现在很多真正值钱的动作，发生在后台 API 被调用、规则引擎被执行、模型判断被返回、风险被拦截、任务被自动完成时。页面没有热闹，业务却在持续发生。

第三，来源链路开始断裂。
一个任务可能来自企微对话、钉钉机器人、某个 Agent 平台、某个 ERP 工作流、某个行业应用，再层层调用多个 SaaS 能力。最终到了你这里，只剩一次 API request。如果没有链路参数和任务上下文，你根本不知道这次调用属于哪个客户、哪个场景、哪个入口、哪个合作渠道。

第四，收费解释权开始依赖归因能力。
按账号收费时，账单很好解释；按结果收费时，客户会问得更细：这次结果是谁触发的、完成了什么、为什么该收费、为什么比别家贵。没有清晰归因，你不仅难优化产品，连开账单都会缺乏说服力。

所以，Agent 时代最先失灵的并不是报表本身，而是报表背后的世界观——原来一切都默认人是流量主体，现在你必须接受任务才是新主体。

工程实践：把人物归因升级为任务归因

先把“调用来源”做成统一入口层

很多企服团队在接 Agent 化流量时，最容易犯的错误，就是把所有 API 调用都看成同一类调用。实际上，同样是一条 request，它可能来自：

• 钉钉或企微里的企业助手
• 某个 Agent 平台的自动任务
• 某个行业 SaaS 的嵌入式调用
• 某个合作方工作流系统
• 某个私有化部署环境
• 某个销售定制项目的专属入口

如果这些都在后台被混成一类“系统调用”，那后续无论是增长分析、定价评估、续费谈判还是合作渠道管理，都会陷入失真。

更好的方法，是通过 全渠道统计 的思路，为不同入口建立统一的 ChannelCode 体系。这样你统计的就不再是笼统的“企业流量”或“API流量”，而是能明确区分：

• 来源平台
• 合作伙伴
• 行业线
• 地区
• 产品版本
• 场景入口
• 销售/实施归属

这一步本质上是在做一件事：把“不可见的接口调用”重新拉回可解释的入口体系里。只有入口先干净，后面你才有可能谈按量计费、按结果收费、分合作方结算、按行业看留存。

如果你的团队已经开始出现多平台、多 Agent、多接口入口并存的情况，可以直接参考 xinstall 在《亚马逊 AI 战略升级？多云多 Agent 时代 App 该怎么认清流量真身》里强调的那套思路：先认清流量真身，再谈增长和收费。

用参数还原“任务是谁发起的”

光知道来源平台还不够。因为对企服 SaaS 而言，最关键的问题不是“从哪来”，而是“这次任务是谁发起的、为什么发起、属于哪条业务流”。

一个员工在企微里问一句“帮我审这份合同”，上层 Agent 可能会拆成多个子任务，再调用法律审查、条款比对、风险提示、模板生成等多个底层 SaaS 能力。到了某一个垂直 SaaS 这里，也许只看到一次接口调用，但这次调用背后的业务上下文其实很丰富。

这时就需要借助 智能传参安装 和参数还原思路，把 task_id、workflow_id、agent_id、org_id、scene、risk_level、partner_id 这类上下文在链路里持续带着走。哪怕最终是接口完成任务，你也能在系统内部知道：这是哪个企业、哪个 Agent、哪条工作流、哪个场景下触发的调用。

这种能力最大的价值在于，它把“后台黑盒调用”变成了“有上下文的任务行为”。没有它，你看到的是一次 request；有了它，你看到的是一笔真实业务。

关于这类“链路携参 → 拉起/调用 → 任务还原”的底层方法，可以参考 xinstall 在《智能体分发时代 App 安装传参逻辑的底层重构》里提到的思路，把任务上下文而不是页面点击作为核心传递对象。

把核心指标从登录量改为任务事件图

很多 SaaS 团队现在最危险的地方在于，技术架构已经开始 API 化、Agent 化，报表却还停留在 seat、DAU、功能点击、页面停留时长这套老框架里。结果就是业务已经变了，数据还在描述旧世界。

如果你真的要服务 Agent 时代，建议把指标体系切到任务事件图：

• 谁发起了任务：actor_type / org_id / user_role
• 任务来自哪里：channelCode / partner_id / platform
• 任务属于什么场景：scene / workflow_type
• 调用了哪些能力：capability_id / api_name / agent_id
• 结果是否完成：success_flag / result_type / confidence
• 结果带来什么价值：risk_avoided / time_saved / revenue_impact
• 是否产生结算：billing_type / billable_event / settlement_status

当你能从“登录行为”切换到“任务事件”，产品团队才能看懂真正的使用深度，商业团队才能设计合理收费模型，客服和实施团队才能解释客户为什么该付这笔钱。

注：本文讨论的“人物流量向任务流量迁移、Agent调用链归因、任务级参数还原与结果型计费”属于对未来企服分发与增长趋势的前瞻性技术延展与思考，例如跨平台任务归因、多Agent链路观测、私有化环境下的参数识别、按任务/按结果计费的数据支撑等方向。目前此类高复杂度链路通常需要结合企业现有架构与业务模型进行定制化设计，尚未全部以统一标准能力完整覆盖。如团队已经出现多 Agent 场景、复杂任务流归因、结果型收费支撑等需求，欢迎联系 Xinstall 客服团队进一步探讨或联合定向研发。

这件事和开发 / 增长团队的关系

面向 SaaS 产品与架构团队

现在最值得补的，不是一个更炫的对话框，也不是更花哨的前端，而是把后台能力真正产品化、可计量、可归因、可结算。

建议优先补这几类字段和能力：

• task_id、workflow_id、agent_id、org_id
• channelCode、partner_id、scene
• result_type、billable_event、settlement_status
• API 调用级日志和结果追踪
• 多角色、多入口、多任务源头的统一映射

这是未来收费体系的底账，也是未来增长分析的底账。

面向商业化与增长团队

商业化团队也要换思路。以前你卖的是 seat、模块、版本、实施包；以后很多时候你卖的是：

• 一次准确的结果
• 一个被频繁调用的能力
• 一个嵌进工作流后难以替代的节点
• 一个能持续降低风险和时间成本的业务引擎

这意味着增长不再只是“签多少新客户”，还包括：

• 谁的任务调用在增长
• 哪个场景最能扩量
• 哪个合作方带来的调用价值更高
• 哪类任务最容易变成可持续付费

如果还盯着登录数和账号数，很容易在真正的增长开始时却误判产品已经衰退。

现在就能做的三件事

• 把 seat、登录、页面点击之外的任务事件补进数据模型。
• 给所有 Agent / API / 工作流入口建立统一 ChannelCode 体系。
• 在产品内部建立“结果可解释、价值可归因、结算可对应”的事件闭环。

常见问题（FAQ）

Agent 时代是不是意味着 SaaS 一定会死？

不一定。更准确地说，会消失的是上一代以界面、模块和账号为核心的 SaaS 形态，而不是所有 SaaS 能力。很多垂直 SaaS 反而有机会成为 Agent 背后的核心能力层。

为什么“没人登录”会影响收费模式？

因为按账号收费默认前提是“人登录软件并持续使用”。一旦实际使用主体变成 Agent 和 API，账号数量就不能再准确代表系统价值，收费自然需要转向按量、按任务或按结果。

微交易一定比包年收费好吗？

不一定。它更适合被频繁调用、能快速验证价值、容易嵌入业务流的能力型产品。但微交易会带来现金流压力、组织重构和定价挑战，并不意味着所有公司都能平滑切换。

为什么说 Agent 时代先丢的是归因？

因为一旦价值发生在后台调用和任务执行中，原来依赖登录、点击、页面路径的归因方式会立刻失真。收费、续费、优化、合作分账，都会先卡在“这次价值到底是谁创造的、怎么解释”的问题上。

行业动态观察

“没人登录了”不是一句夸张的行业标题，而是企服世界正在发生的结构变化：软件正在从“人用的界面”变成“任务调用的能力”。当人物流量退场，任务流量上位，收费模式、增长模型和组织结构都会被迫重写。

所以对企服团队来说，真正的关键不只是把产品接进 Agent，而是要先搞清楚：当任务在流动、接口在被调用、结果在被消费时，你还能不能认出自己的价值发生在哪里。谁先把这个问题解决清楚，谁才更有资格谈下一代 SaaS 的收费权。