背景与规模：400 亿美元业务上的转型实验
讨论企业 Agentic 编码时，常见样本是绿地项目或小团队副业。Salesforce 提供的是另一种稀缺样本：一个年营收约 400 亿美元、为数十万客户运行生产系统的业务——每一次部署都直接触碰收入与信任——把 Agentic 编码铺开到 1.5 万名工程师。这正是该案例值得逐层复盘的原因：它检验的不是「工具能不能写代码」，而是「组织能不能以生产级标准吸收这种变化」。
2026 年 5 月，Salesforce 工程负责人 Srinivas Tallapragada 发表了系列首篇；9 月，CTO Muralidhar Krishnaprasad 的第二篇把视角从「发生了什么」推进到「如何在 1.5 万人规模上运转」。两篇合起来构成一条从试点到规模的完整路径。
阶段一：30 天试点设计（44 团队/10 产品云/200+ 工程师）
试点于 3 月启动，为期 30 天，设计上有四个刻意的选择：
| 设计维度 | 选择 | 设计意图 |
|---|---|---|
| 规模 | 44 个团队、10 个产品云、200+ 工程师 | 大到有统计意义，小到能快速迭代 |
| 代码库覆盖 | 绿地代码库 + 深度耦合的遗留系统并存 | 验证复杂度光谱的两端，而非只挑好啃的部分 |
| 人员构成 | 高节奏团队 + 维护型团队；AI 早期采纳者 + 怀疑者 | 覆盖真实组织的态度分布 |
| 用例类型 | 创新、迁移、日常维护三类 | 避免「只在适合的场景用」的选择性偏差 |
试点期间用的是 Claude Code（如今公司已有更多工具可选）。但文章反复强调的一点容易被忽略：试点的任务不是证明工具能用，而是证明它在我们实际构建和运维的完整复杂度上——生产级、关键业务系统、企业规模——可以被信任。技术验证回答「这东西行不行」；组织验证回答「我们能不能以足够的速度吸收这种变化」。30 天里发现的摩擦点不在模型，而在工作流、人的习惯和加速内环后暴露的跨职能依赖。
阶段二：全员铺开与自建编排层
从试点到 1.5 万人铺开的过程中，出现了一个典型的「供应商空白」：工程师需要一种管理智能体机群的方式——追踪进度、让自主会话不跑偏、无需持续盯梢就能发现问题。没有供应商提供恰好匹配的产品，于是一组工程师自建了编排层并在全公司分发。
这个细节的含金量在于其生成机制：不是高层立项、不是专项拨款，而是「发现缺口 → 建解决方案 → 广泛分享」的工程文化自然产出。Salesforce 判断这正是「采用 AI 工具的组织」与「围绕 AI 完成转型的组织」的分界线——缺了这种机制，采纳会停在团队级别，无法乘数化。
铺开策略被概括为「let a thousand flowers bloom（让百花齐放）」：允许各团队自由实验不同方法，同时快速识别哪些值得规模化、标准化。结果是没有强制统一到单一工具——AI Expert Suite 与 Dev Bar 等选项并存，工程师可随工作需求在工具与模型之间切换。这种多样性被事后证明是正确的准备：它直接铺垫了后续的模型多元化策略。
成绩单与度量方法
2026 年 7 月的同比数据构成这份成绩单：
| 指标 | 同比变化 | 度量口径 |
|---|---|---|
| 人均完成工作项 | +90.5% | 工作项计数 / 开发者 |
| 人均合并 PR | +88.1% | 合并的 Pull Request 计数 / 开发者 |
| Effective Output | +200.3% | 与斯坦福大学共建的 ML 生产力评分 |
第三个指标值得单独解释：Effective Output 不是行数或提交数，而是一个机器学习模型按照「资深工程师评审团」的方式自动审查每个 commit，对质量、复杂度和投入度给出专家级判断——度量的是代码的价值而非数量。这回应了 Agentic 时代「PR 变多变大导致 vanity metrics 失真」的普遍担忧，也是企业度量的一个值得借鉴的方向：先建「能防住注水的度量」，再放大产能。
Salesforce 把「产量指标 + 质量指标」配对发布而非只报产量。逻辑很直白：Agent 让产出变容易的同时，也让注水变容易——没有质量维度校准的产能数据在 Agentic 时代几乎不可信。
五大可复现打法
从两篇官方复盘提炼，以下五条对所有规模的企业都有迁移价值：
- 试点验证「信任」而非「功能」：30 天试点刻意包含遗留系统与怀疑者，暴露的摩擦点被明确分类为工作流、习惯、跨职能依赖——这些正是规模化阶段真正会绊倒组织的东西。
- 让编排层长在文化里：智能体机群管理（进度追踪、自主会话纠偏）是规模化刚需，供应商没有的产品就自建自用；关键是建立「发现缺口 → 自建 → 分享」的正循环，而不是等一个完美采购。
- 百花齐放 + 快速标准化：自下而上实验、自上而下筛选，两条腿缺一不可。只放不管会碎片化，只管不放会扼杀本地创新。
- 把 token 开支管理做成工程技能：文章把「管理 token 花费」列为一种既提质又提速、同时省成本的工程技能——意味着 token 成本控制应当进入代码评审与工程培训体系，而非只留在财务报表层面。
- 用成熟度曲线统一语言：从「随手用工具」到「全自主智能体编排」的成熟度分级，给 1.5 万名工程师提供了描述自身采纳深度的共同语言——这是规模化沟通的基础设施。
避坑清单：三个反直觉教训
- 不要用小团队成功外推全员成功：绿地项目的 Agentic 成功与 40 亿美元业务、数十万客户的生产系统上的成功是两个问题；后者的约束（合规、遗留耦合、变更风险）在小团队里根本不出现。
- 不要强制统一工具：反直觉但被验证的选择是保持工具与模型的多样性——不同任务的最佳工具不同，强制统一在模型多元化时代会成为战略负债。
- 不要只度量产量：PR 数与完成工作项数在 Agent 介入后都会自然膨胀，若不同步建设质量度量（如专家评审式的 ML 评分），规模化报表将失去决策参考价值。
局限与适用边界
- 自报数据：全部指标来自 Salesforce 官方发布，属于厂商自报口径；Effective Output 的具体评分模型与校准方法未完全公开，第三方尚未独立复测。
- 平台厂商禀赋：Salesforce 拥有自建编排层的工程冗余与斯坦福合作资源，中小团队照搬「自建」路线前应先评估自身平台投入的性价比——采购或开源方案可能更合理。
- 统计口径提示：+90.5%/+88.1% 为人均同比口径，未披露 2025 年 7 月基数与 Agent 介入的任务占比；「贡献归因于 Agentic 转型」的程度依赖读者对口径的审慎解读。
- 文化前提不可复制：「默认响应缺失能力就是自建并分享」的文化是该案例的隐藏变量，缺乏这种文化的组织直接导入工具，大概率停留在团队级采纳。
与本栏目 R-CASE-07（Nubank、Coinbase、Block 的五大打法）对照阅读会更有收获：两个案例在「paved road 平台化」「给 Agent 配环境与边界」上高度一致，但 Salesforce 额外贡献了度量设计（质量评分配对产量指标）与token 成本工程化两个此前案例未展开的维度。目前官方及行业暂未披露更多细节（如按角色拆分的采纳曲线、token 成本节约的绝对值），后续将持续跟进迭代动态。