← All Articles

精读 Salesforce《工程如何变得 Agentic》——大型软件公司的 Agent 转型实录

2026-06-14 · Original

受众：Justin（红杉中国 MD） 原文：Salesforce 官网，作者 Srinivas Tallapragada（总裁兼首席工程与客户成功官），2026-05-27，6 分钟读 中文索引：meng shao @shao__meng 推文摘要 抓取说明：Salesforce 官网有 Akamai 反爬，agent-browser 被 Access Denied，正文经 CDP Proxy（真实 Chrome 会话）+ 推文详细摘要交叉确认

为什么这篇值得单独读

市面上”AI 写代码产出涨 N 倍”的材料很多，但绝大多数来自模型公司自己（Anthropic 说 Claude 写了自己 80% 的代码、Cursor 说自己多快）——既是当事人又是利益相关方。

这篇不一样：Salesforce 是一家有几万工程师、几十年历史、背着大量遗留系统的传统企业软件公司。它讲的不是”AI 公司怎么用 AI”，是”一家正常的大公司怎么把工程组织改造成 Agent 驱动”。对判断”Agent 落地到非 AI 原生企业到底能走多深”，这是更有参考价值的样本。而且作者是总裁级（不是某个工程师的个人实验），代表的是公司层面的战略表态。

一、它真正讲的事：两个阶段，重点在第二阶段

Salesforce 把转型分成两段，关键不是第一段而是第二段：

第一阶段：AI 嵌入旧流程。把 Copilot 类工具塞进现有开发流程，工程师还是工程师，只是有了更强的助手。这一阶段他们做到了 >90% 的 adoption——但作者明确说这只是起点，不是目标。

第二阶段：用 AI 拆掉流程本身。不是让 AI 在旧流程里更快，而是用 Agent 拆掉 handoff（交接）和低价值环节，让 Agent 直接驱动写码、审 PR、测试、文档、部署。人退到”定义目标、写规则、做验收”的位置。

这个两阶段划分是全文最重要的判断：大多数公司卡在第一阶段——把 AI 当更快的打字员，流程不变。真正的杠杆在第二阶段——AI 让你有机会重新设计”工作怎么流转”，handoff 和等待这些传统软件工程里最大的隐性成本可以被直接删掉。从”工程师 + 工具”变成”工程师设计 Agent 工作流”。

二、三个撬动变革的杠杆（最可复用的方法论）

杠杆 1：工具收敛 + 零摩擦

全组织统一到 Claude Code，取消 token 上限。

这条看起来是个 IT 决策，实际是个信号决策。取消 token 上限传达的是”深度用 Agent 是被允许、被期待的”——它消除了工程师”用多了会不会超预算”的顾虑。在一个几万人的组织里，统一工具 + 零使用摩擦，是让 Agent 行为能规模化的前提。对照很多公司给 AI 工具设额度、分批试点——那本身就在告诉员工”这是边缘实验，不是主路”。

杠杆 2：规则即代码（rules-as-code）

用 Markdown 写规则 + 参考实现，PR 反馈写回规则。

这是全文的内核。它解决的是 Agent 落地最头疼的问题：每次都要重新 prompt、每个工程师的 Agent 输出质量不一致。Salesforce 的做法是把”怎么做对”沉淀成规则文件，Agent 每次按规则跑；当某个 PR 被 review 指出问题，把修正写回规则——这样下一次所有人的 Agent 都不会再犯同样的错。

meng shao 那句总结很准：“精度复利，而非每次重 prompt”。这是把一次性的 review 反馈，变成了团队级的、只升不降的质量资产。

杠杆 3：自治 + 并行

build/fix/validate 闭环少人介入；隔离环境里并行出 PR。

让 Agent 在隔离环境自己跑”构建-修复-验证”循环，人少介入；多个 Agent 并行各自出 PR。这把工程师从”盯着一个任务”解放成”同时监督多条并行的 Agent 工作流”。

三、那个 18 倍案例的真实含金量

最抓眼球的数字：一个原本估 231 人天的迁移，13 天做完（约 18 倍）；一个 PR 交付 21 个 endpoint、100% 测试覆盖。

但作者自己划了边界，这是这篇诚实的地方：这个案例证明的是”可规则化 + 可自动验证”的任务（API 迁移、补测试、文档同步），不是一切研发。

这个边界判断对投资和实操都关键： - Agent 现在能吃掉的是”规则清晰 + 有自动化验证手段”的工作——迁移、补测、格式统一、文档同步这类又繁琐又有明确对错的活 - 模糊需求、需要产品判断和架构权衡的活，还在人手里 - meng shao 的实操建议很对：别先让 Agent 写模糊需求，先找规则清晰可自动验的活

所以”18 倍”不是普适生产力倍数，是特定任务类型上的倍数。把它当”研发整体提速 18 倍”来理解会严重误判。

四、最容易被忽略但最重要的信号：下游有没有被压垮

这是全文我认为最值得记的一点，也是区分”真转型”和”代码洪水”的判断标准。

数据：PR +79%、有效产出 +151%、事故 -5%。

表面看是吞吐涨了。但真正的信号在于：上游写代码加速后，review / 测试 / 发布这些下游环节没有被冲垮——因为 Agent 也接住了下游（自动 review、自动测试、自动验证）。

为什么这是关键判断：如果只在上游用 Agent 狂写代码，下游还是人工 review 和测试，结果必然是”代码洪水”——一堆没人审得过来的 PR 堆积，质量崩盘。Agent 转型成不成立，看的不是上游能写多快，是整条流水线（尤其最慢的下游）能不能同步提速。Salesforce 的 +151% 有效产出 + 事故还降了，说明它是全链路的，不是单点。

诚实打折：事故 -5% 这些指标是 Salesforce 自研的”Engineering 360”体系，因果关系没公开。所以方向可信（下游没崩），但具体数字别当审计过的硬数据。

五、工程师角色的迁移（对人才判断有用）

作者说核心能力从”写代码”变成三件事：

  1. 把问题拆成 Agent 能执行的结构 + 验收标准——这是新的核心技能，比写代码更难也更值钱
  2. 判断”委派 vs 留在环内”——哪些交给 Agent、哪些人必须在循环里，这个判断力是关键
  3. 沉淀 Skills / CLAUDE.md / 规则库——把个人和团队经验变成可复用资产

一句话：“工程师在变成 Agent 工作流的设计者与所有者。”

这跟最近几篇是同一个判断的不同侧面： - 6/7 深思 Hiten Shah：“把公司最好的人的判断打包成 skill 是真护城河” - 6/13 歸藏：“Agent 放大能力差距，skill 弥合差距” - 6/10 Good AI PM：“bad PM 用 AI 产出更多 artifact，good PM 产出更多 learning”

四篇指向同一个结论：AI 时代的核心能力不是产出，是”把判断和流程结构化、可复用化”的能力。Salesforce 这篇是它在大型工程组织里的实证。

六、对你的几个直接用处

看 AI coding / 企业服务标的时： - 这篇给了一把尺子——判断一个”AI 提效”故事是真是假，看它有没有解决下游（review/测试/发布）的同步提速。只讲上游写代码快的，大概率是代码洪水 - “可规则化 + 可自动验证”是 Agent 当前能吃的任务边界，标的如果声称 Agent 能做模糊需求/架构设计，要打问号 - Salesforce 全组织上 Claude Code 取消 token 上限——这是 Anthropic 企业渗透的一个强信号，对判断 Anthropic vs OpenAI 在企业市场的位置有参考

对你自己团队的 agent 工作流： - “PR 反馈 → 规则”闭环是 18 倍案例里唯一可低成本复制的内核，值得在你们的工程流程里试 - 这也呼应你昨天分享 skill 给 YUE 学员的方向——你在做的正是”团队复利资产”这件事

值得记进 mental model 的一条： > Agent 转型的成败信号不在上游产出速度，在下游（最慢环节）能否同步被 Agent 接住。否则上游越快，下游债越多。

七、一句话总判

这篇值得读不是因为有多新的观点，而是因为它是一家传统大型软件公司（非 AI 原生）从总裁层面给出的 Agent 工程转型实证——比模型公司的自夸数据更有外部参考价值。最值钱的三条：① 真转型在”用 AI 拆流程”而非”用 AI 加速旧流程”；② “PR 反馈 → 规则”的精度复利闭环；③ 判断转型真假看下游有没有被同步接住。

最大的诚实之处是它划了边界（18 倍只在可规则化可验证的任务上），最大的保留是指标自研、因果未公开。

主要来源

配套（你已读过的同主题）