起名字不是市场部的小花招
七个 agent 都有人名，而且每个对着一个真实岗位：Casey 是客服坐席，Paige 是 IT/HR 的内部支持，Hunter 是销售开发，Piper 是线索筛选。客户还可以改成自己的叫法。 这是个定位声明，不是包装。它要改变的是采购对话的形状——「我们要不要买一个模块」和「我们要不要加一个人头」，走的是完全不同的预算池、不同的审批链、不同的对比基准。一个功能模块跟同类软件比价格，一个「岗位」跟人力成本比。对甲方来说，这个转换里最需要警惕的正是它省掉的那一步：软件按功能验收，人按绩效考核，而一个被包装成岗位的软件，验收标准得自己定。
真正的新东西是 long-horizon runtime
技术上最值得看的一条是 Hunter 用的新运行时：目标跨越数周甚至数月，而不是一次会话。Salesforce 说之后会扩展到其他 agent。这也解释了为什么只有 Hunter 还在 pilot——它是唯一一个必须解决长任务状态问题的。 本站 9 月 11 日写过 OpenAI 的 Agents API 公测，那一套托管的正是会话持久化、上下文压缩和中断恢复。两家在解决同一个工程问题，只是卖给不同的人：OpenAI 把它做成 API 卖给开发者，Salesforce 把它包成岗位卖给业务部门。谁先把「一个任务跑三周还不跑偏」做扎实，谁就拿到了这一轮的实际门槛。 其余的配套也指向同一方向：Multi-Agent Orchestration 已 GA，Agent Optimizer 和 Coworker 里的 AI Skills 十月 GA，还有一个叫 Agent Script 的开源语言，用来把 AI 推理和固定业务规则拼在一起——Marshall 强调的「确定性执行 + 每一步审计记录」就是给受监管流程准备的。
价格一个都没有，这是选型时最大的空白
七个 GA 的 agent 加三项平台能力，定价全部未披露。对做选型的人，这意味着现在做不了任何总拥有成本的比较。 而按「岗位」定位的产品，计价模型本身比单价更重要：按席位算、按解决量算、还是按 Salesforce 自己在用的 Agentic Work Units 算？它公布的 70 亿累计、第二季度 32 亿这组数字，大概率就是未来计费单位的雏形——如果真按这个计费，你的成本会随 agent 的「勤快程度」浮动，而不是随人头固定。这是采购时该问清的第一个问题。 客户侧的效果数字也要按口径读：Engine 称其 help agent 完全解决了一半的入站聊天咨询，Perk 称 Hunter 构建了其 60% 的销售管道——这些是厂商引用的客户说法，不是独立测量，场景差异也很大。真要判断，还是得拿自己的历史工单和线索跑一轮。