入口开放给智能体之后：SaaS 按席位收费的前提先站不住
一、席位从来不是一个计量单位，它只是一个替身
据公开报道，有头部 SaaS 厂商把自己系统里积累的数据与流程开放给外部 AI 调用，同时开始探索新的收费方式；报道把这条演进描述为从预测、到生成内容、再到执行任务。
对做云服务和 SaaS 交付的人来说，值得拆的是收费那一半。按席位收费看起来在数人，其实在数工作量：一个销售坐在那里，一年打开系统几百次，改几十条线索，发若干邮件，于是”一个席位”就顺手代表了这一团工作。这个代表关系成立的前提有三个——同一个人在用、使用强度有上限、产生的价值跟人的工时同向。三个前提里任何一个断了，席位就开始说谎。
智能体进来之后，三个一起断了。它不坐在任何位置上；它的调用强度取决于任务复杂度而不是工时，一次任务可以把一件事做几十遍；它产生的价值跟工时无关，跟”事情有没有做完”有关。更要紧的是，同一个席位下的工作量可以横向复制：给一个人开的权限，一旦交给他的助手，就等于交给了一批可以并发跑的执行体。
所以问题不是”要不要按智能体收费”，而是计量单位要换一个能被审计的东西。可审计的意思是：账单上的每一个单位，都能指着服务端的一条记录说清它对应哪一次调用、谁发起、动了什么。
二、三类计量单位与各自的可审计字段
| 计量方式 | 计费单位 | 必须能落到的字段 | 断掉的地方 | 适用场景 |
|---|---|---|---|---|
| 按席位 | 一个被占用的人 | 席位绑定到哪个目录身份；谁在用同一凭据；活跃怎么判定（登录、读、还是写） | 一个凭据背后可能有多个执行体；活跃判定对机器完全失真 | 人类使用者的基础访问权 |
| 按动作 | 一次被服务端接受的调用 | 调用方身份（哪个主体的哪次会话）；动作类型与目标对象；读还是写；影响的数据行数；是否触发对外发送 | 同一业务目标可被拆成很多次小动作；动作粒度不由客户控制 | 读写混合、流程可枚举的系统 |
| 按结果 | 一次被确认完成的交付 | 什么算成功交付的判定条件；由谁判定（系统状态还是人工确认）；返工怎么计；失败是否计费 | 判定条件容易被人为放宽；跨系统结果难以归属 | 有明确交付物、且交付物能被机器校验的任务 |
三类的核心差别在”谁说了算”。席位由采购方说了算，动作由供方说了算，结果要双方一起把定义写死。写不死的场景不要按结果收费——那等于把争议留给未来。
按动作计价还有一个必须一起交出的东西：动作目录。哪些动作是读、哪些是写、哪些会外发，一张列清楚。没有目录的动作计价会变成”什么都可能算一次”，客户不敢用；有了目录，客户可以自己在发起端做预算控制。这是我们认为开放入口时最该优先补的一份文档，比价格表还急。
三、开放入口必须同时收口的三件事
调用方从”我们产品里的人”变成”任何人带来的助手”，权限模型要跟着改三处。
读写分域。读的能力与写的能力不能共用一把凭据。智能体最常见的事故不是把数据偷走，而是把一个不该写的字段写进去——它读到的上下文越全，越有信心去”补完”。分域之后还要给写操作单独一套配额，因为写会产生别人要承担的后果。
字段级可见性。行级权限在无人的调用里几乎不起作用，因为一次任务会把整表拉走再看。要收到字段层：哪些列对这个调用方存在，哪些列在响应里根本不出现。敏感列（成本价、客户联系方式、内部备注）默认不可见，可见需要按调用方授权，而不只是按角色授权。
导出与缓存策略。智能体天然会把结果落到它自己的存储里，这一步挡不住，只能约定。要写清三件事：允许缓存什么、缓存多久、缓存在谁的域里；不允许长期保存的字段是什么；调用方注销或任务结束后，那些副本由谁负责清。这条与数据出口直接连着——一旦允许外部主体成批读取并留存，”数据在谁家机器上”这个问题就不再只由乙方负责。
这三处的共同点是要在开放之前做完。开放之后再补，等于要求客户改他们已经写好的调用，任何做过接口演进的人都清楚那有多贵。
四、责任链要落在服务端字段，不是会话文本
“谁发起、谁批准、谁承担误操作”这三问，现在普遍只存在于聊天记录里。这不够，因为会话文本不可查询、不可统计、不可对账。
落法是把三问变成服务端必填字段。发起方：真人身份（目录 ID）与所代表的智能体主体是一对绑定关系，写操作必须两者都带。批准方：当动作落在预设的高风险清单上（对外发送、删除、涉及金额的变更、批量改写），要在请求被接受之前拿到一次明确批准，批准本身是一条可回查的记录，含批准人、批准时间、批准时看到的参数摘要。承担方：误操作发生后，追责路径按前两个字段走；没有这两个字段，一切解释都会退化成”它自己理解的”。
这里有一个实务判断值得说：批准不该由调用方自己实现。供方在服务端设一道确认门槛，好处是所有调用方共用同一套语义，坏处是把 UX 复杂度推给了接入方。我们的做法是按风险分档——低风险直接执行，中风险执行前给出可预览的变更集，高风险必须外部批准并留记录。分档标准要写进文档，因为采购方要用它来核自己的内控流程能不能对上。
五、既有合同覆盖不了什么
现有席位合同在智能体调用上有四处空白，每处都要在续约之前谈。
席位定义。合同里的”用户”通常写为”访问系统的个人”。当一个助手代多人访问时，它到底占不占席位、占几个，取决于定义写法。多数老合同的措辞在这里没有答案，于是争议会被留给账单而不是留给条款。
超额怎么算。智能体的用量不像人那样可预测：一次批量任务可以在很短时间把调用量顶到日常水平之上。合同要提前写明配额是按天、按月还是按任务，超额是硬限、软限还是事后结算，以及客户能不能自己设上限。没有可自设上限的合同，采购方无法把预算交给使用者。
责任与配额之外的第三块是数据用途：调用产生的提示与返回内容，供方是否留存、留多久、是否用于模型改进；这一项要在合同里而不是在隐私政策的链接里。
最后一块是吊销。当出现异常调用或安全事件时，谁能多快把某个调用方切断，切断后正在跑的任务怎么处理，责任如何划分。这三问在纯人类使用场景里从不重要，在机器调用场景里是首要条款。
六、采购方要问的六个问题
我们把这些年做交付时客户问得最多的六条整理成一份清单，它同样适合供方自检——答不利落的，说明入口还没准备好开放。
- 调用方是否可以枚举：能不能列出当前有哪些主体在调用，各自代表谁，权限是哪一档。
- 账单能否按调用方拆开：每一笔费用要能追到具体调用方与动作类型，而不是只有一个总量。
- 审计日志保留多久、能看到多细：是否包含参数摘要、影响行数、批准记录；保留期是否与我们的合规要求对得上。
- 数据会不会被拿去训练：送出去的内容与返回的内容各自怎么处理，能否逐调用方关闭。
- 故障责任怎么分：因供方变更导致调用失败，或因智能体误用造成数据损坏，判定与赔偿按什么走。
- 如何吊销：出现异常时按调用方切断的时限，以及切断后数据与副本的处理。
六个问题里有四个是同一件事的不同面：能不能审计。这也是整件事的实质——收费单位从”人头”换成”可审计的行为”，权限粒度从”角色”换成”调用方”，责任链从”会话”换成”字段”。三处都换完，入口开放才是可交付的东西；只换第一处，就是给老账单加一个新名字。洹拓内部把这三处列成了开放类项目的上线门禁，动作目录、字段级可见性和风险分档线三份文件没齐，就不建议客户签接入协议。