企业官网建设流程全解析

一句话结论：这个变化的重点不在「要收费」，而在于它把「你组织里到底跑着多少个智能体」变成一件必须回答准确的事——身份、权限、调用次数三件事被绑在了一起。

一、事件与数据

Salesforce 在 2026 年 9 月 17 日发布的帮助文档《Understand AIforce Impact》里写了目标窗口：

Targeting November, Salesforce will be releasing a new set of security controls, agentic registration, and a new billing model as part of the Headless Toolkit.

三个部分，本期 coming together：

官方用词是targeting，没有给确定日期。价格也还没定：Flex Credits 的公开单价是每 10 万信用点 500 美元（合每信用点 0.005 美元），但 HPI 用量行的倍率在官方费率卡上标注为TBA。官方同时承诺：开始计量前会给 30 天通知；在此之前不计量。

不进入计量的部分也要说清楚：沙盒、scratch org、Developer Edition org 不计量，账单从进入生产环境那一刻开始算；非智能体的传统集成维持原计价方式。

二、技术拆解：身份模型怎么变的

这一步才是真正的技术信息。此前 Salesforce 的 hosted MCP 服务器在 2026 年 4 月 29 日正式可用时，官方描述是：每个事务都以被认证的用户身份运行，不引入匿名服务账号，也不需要学习新的安全模型；按用户走 OAuth 2.0 + PKCE，智能体继承该用户的共享规则与字段级权限。

现在方向反了过来：

Salesforce 自己的比喻是「给智能体发它自己的工牌，而不是借给它一张员工工牌」。对企业安全团队，后者的价值不止于账单——一个只负责排会议的智能体，不该继承导出全部联系人、删 campaign、改收入预测的能力；一旦某个智能体要下线或被换掉，专用凭据也让吊销动作干净得多。

时限规则按客户类型分：

第三行值得单独标出来：MCP 服务器的使用不分新老客户，都算。

三、调用次数会比任务数大一个量级

最容易犯的估算错误，是拿「业务任务数」当账单行数。实际每一次调用都算数：一次查数据、一次重试、一次分页、一次轮询状态、一次写回，都是一次成功调用。

按公开材料里的例子，一个看起来只完成了一件工作的任务，内部可能走了 18 次读取、重试与记录更新，于是产生18 个 HPI 而不是 1 个。据此做一张敏感度表（假设 10 个注册智能体、每个每天跑 200 个任务、平均每任务 18 次交互 → 每天36,000 个 HPI；信用点单价按公开的 0.005 美元计）：

这张表的意思不是「会很贵」，而是在倍率公布之前，任何报价都只是猜测。能确定的是另一件事：调用次数的可控性从此直接等于成本的可控性。

有一个不宜错的参照系：官方目前把标准 Agentforce 动作标为 20 Flex Credits，那是另一个用量类型，HPI 的倍率可能与它完全不同，不能用 20 直接代入上表。

四、对开发者的三个影响

影响一：先把「哪些连接其实是智能体」判定出来。每晚按固定脚本跑一次的记录同步，是传统集成；会自己决定查哪些记录、选哪个工具、重试几十次并回写结果的，是智能体。处在中间的那部分需要逐个审，而不是看产品的营销标签。清点的方法是拉 Setup 里的 Connected Apps 与 API 用户列表，再逐团队确认。

影响二：工具的粒度要重新设计。在按调用计费的口径下，一个「返回所有可能字段」的工具，比一个「返回本次任务需要的字段」的工具贵。分页大小、轮询频率、重试退避策略都会落到账单上，这些参数的成本属性第一次变得和性能属性一样重要。

影响三：身份与权限要按最小可用重新划分。一个只做日程的智能体不要给对象写权限；一个只读取 OAuth 范围的智能体不要给导出权限。注册流程本身会把这个动作逼出来，但更好的做法是提前做完，这样注册那天不用停业。

五、我的判断与前提

• 推测部分：从规则本身的设计意图看，先注册、后计费的顺序说明 Salesforce 需要先把流量打上标签，才能在开启计量时立刻拿到干净的用量数据。这是依据公开规则做出的推断，不是官方说明。

• 前提标注：本文的价格敏感度表基于官方公开的 Flex Credits 单价，倍率 m 在表格里作为参数给出，官方尚未公布，不属于本文可推算的范围。

• 可核查边界：所有事实条目均来自上列四个来源对这些公开材料的转述与引用；Salesforce 官方的帮助文档与费率卡是最终口径，实施前以官方文件为准。

六、结语

智能体接入企业系统这件事，走到今天终于碰到了它迟早要碰的问题：当调用方不再是人，「谁在做这件事」这句话必须重新定义。独立身份 + 调用计量 + 权限收敛，三件事本质上是同一个动作的三个侧面——先把边界画出来，账才算得清。

这在国内环境的落地形态略有不同：智能体通常要以新身份接入既有业务系统，而存量系统往往没有为「非人类调用方」设计权限模型，替换和迁移时还要在给定的国产化软硬件生态里保持调用语义不变。金蝶天燕 Apusic 这条线上，AAS 应用服务器承担业务应用的承载，ADMQ 分布式消息队列承担调用链路与事件留痕；要回答的不是某一个平台的费率表，而是「非人类身份进来了，权限怎么给、调用怎么记、出事怎么查」这套治理能不能在信创环境里同样落地。各自的能力边界以官方文档为准。

问一句：如果今天让你们列出「有多少个智能体正在读写 CRM」，这份名单多久能凑齐、准确率有多少？答案如果是「一周、可能不全」，那么这轮变化的成本不在账单上，在清点本身。