Claudeforce 是双向的，而只有一个方向把记录留在 Salesforce 里

究竟宣布了什么

Salesforce 与 Anthropic 把它命名为 Claudeforce，新闻稿的说法是把 Claude 的推理能力与 Salesforce「可信的企业级外壳」——它的数据、工作流、业务逻辑、动作与治理——结合起来。而在这套说辞底下，是两件方向相反的交付物。

媒体报道大体把这读成一则「选模型」的故事——企业软件还能不能保持模型中立的风向标，而 Salesforce 点名了一个默认项而不是给出一份菜单。这是个真问题，但也是两个问题里比较无趣的那个。企业套件里的默认项一向黏性十足，Agent Builder 仍然允许管理员另选，而一个 CRM 推理引擎背后的模型，是你日后有可能换掉的东西。日后换不掉的，是一个决定的记录最终落在了哪里。

同一项合作，两条边界

Claude 进 Agentforce：模型走向数据

在这个方向上，智能体的动作就是 Salesforce 动作。它们在某个运行用户的上下文里执行，这意味着平台的共享模型、字段级安全与对象权限会逐一作用其上，不需要任何人再实现一遍。工具目录就是该组织自己的动作与流程。推理经由 Bedrock 在 Salesforce 所称的 Trust Boundary 内运行——正是这一条具体主张，让受监管客户可以说数据没有离开。而合规团队想要的那些产物——什么变了、谁改的、在谁的权限下——是由一套比智能体早了十年的机器产出的。

代价是另一种自主性：你在别人的平台里、用他们的动作模型、配他们的默认推理引擎。这是一笔寻常的交易，而多数企业早就做过了。

Salesforce 进 Claude：数据走向会话

插件这个方向更值得琢磨，恰恰因为它是以「便利」的名义卖的。用户在 Claude 里干活。transcript 在 Claude 里。上传的表格、写了一半的方案、同一位用户启用的其他连接器——全都在 Claude 里。插件拉取实时 CRM 上下文，模型在其上推理，然后一个受治理的动作写回去。

注意什么变了、什么没变。那次写入依然是一次 Salesforce 写入，依然受权限约束、依然被记录：这一半是真的解决了。挪走的是推敲过程——被检索到的上下文、被权衡过的备选、用户实际给出的那句指令——而它挪进了一个由另一家厂商决定留存、导出与法律保全策略的工作区。

可审计的那一半，和缺失的那道连接

字段历史会告诉你某个商机的折扣从 5% 变成了 22%，以及是集成用户干的。它不会告诉你：智能体读过一份被粘进聊天窗口的竞品报价、掂量过销售顺口提到的续约风险，然后提出了这个数字。在 Agentforce 那个方向上，这些上下文至少还能从同一个租户里找回来。在插件那个方向上，它们在一段对话里——那段对话可能被编辑、可能被删除，并且适用于用户自己工作区的策略。

这在三个具体场景里要紧，而对任何有规模的公司来说，没有一个是假想的：

• 取证与法律保全。一旦某个决定被争议，推理过程就是可取证材料。一份覆盖 CRM 的保全令，并不覆盖另一个产品里的会话，除非有人特意把范围划过去。
• 受监管的理由留存。凡是需要把理由归档的决定——必须不带歧视的定价、带阈值的审批、任何触及受监督流程的事情——「记录显示了变更却没有依据」就是一条等着被写下来的检查发现。
• 事故重建。当一次错误写入在三周后才被发现，有用的问题是「智能体当时相信了什么」。那就是推理过程；没有它，修复工作要难得多。

解法并不体面，但值得给它排预算：让智能体把自己的理由回写成它所触及对象上的一条记录。一段话的说明，附上它读过的东西的 id，在写入的当下存进 CRM——这在两个方向上都补上了那道缺口，代价是一个字段。

插件的权限范围是什么，以及它为什么比看上去更粗

一个 connected app 的 OAuth 范围是一次性授予的，而且要按「这个应用可能做的一切」来定尺寸。把 37 项技能打包在一个插件后面，那个范围就必须是其中任何一项所需权限的并集——管线读取、记录更新，很可能还有联系人与活动。而一段只想总结某个客户的对话，正带着这全套权限在跑。这不是这个插件独有的缺陷；这是每一种连接器式集成的形状，也正是「按动作生效的权限模型」值钱的现实理由。

会真的酿成事故的是它的二阶版本。一个 CRM 里塞满了别人写的文字——收到的邮件、工单描述、来自你网站表单的备注。把这些文字拉进一个同时握着该用户邮箱、文件与另外三个连接器的通用助手，你就凑齐了经典的「混淆代理」局面：一边是攻击者撰写的内容，一边是用户的完整权限，中间是一个正在决定该做什么的模型。在 Agentforce 里，一次成功的注入替攻击者买到的是一个受共享模型约束的 Salesforce 动作。在一个通用工作区里，它买到的是用户其他连接器所能触及的一切。这正是环境权限整篇的论点，只不过它这次是以一个产品决策而非一次安全评审的形式登场。

在测试版落地之前该做什么

想要那个九月的测试版，是件合理的事。有四件事能让它扛得住：

• 逐个工作流决定它属于哪个方向。凡是记录必须完整的工作——定价、审批、任何监管者或法庭可能会读的东西——放在推敲过程留在租户内的那个方向。探索性的工作、起草与分析，放在另一个方向没问题。
• 把理由回写。无论哪个方向，在写入的当下把一段机器写的说明存到记录上，是这里最便宜的一项控制，也是唯一一项能在换厂商之后依然留存的。
• 按服务账号而不是按用户来划定 connected app 的范围。去问清楚这个插件的 OAuth 范围实际授予了什么、能不能拆开。如果答案是「37 项技能共用一个范围」，那就是你的爆炸半径；把敏感对象直接排除在范围之外，而不要指望它在每段对话里自我克制。
• 在启用之前就把留存与法律保全扩展到这个新面上，而不是等第一次请求到来之后。如果做不到，那这个事实本身就是受监管工作流的答案。

另外，把「模型中立」这个问题放回它该有的比例里。一个默认推理引擎是一件值得去谈判的商业事实，但它是可逆的；而一份积攒两年、没有记录任何依据的决定档案，不可逆。

延伸阅读

本站内容：

• 环境权限——为何是连接器那份未被列举的触及范围、而非模型本身，把一次注入变成一次提权。
• 智能体身份与权限——运行用户上下文与服务账号范围之别。
• 审计轨迹与来源——一条决定记录要装些什么，日后才用得上。
• 委托访问与同意记录——智能体代人行事背后的那套文书。
• 智能体连接器平台——这个插件所属的品类。

信息来源：

• Salesforce and Anthropic Announce Claudeforce——公告本身。
• Salesforce 投资者关系新闻稿
• CNBC 报道——商业层面的解读。