Sourcegraph Agentic Batch Changes
把「跨 200 个仓库的依赖升级」交给协调 Agent:该用脚本的用脚本,该动脑的派给 Claude Code / Codex
不是给个人开发者的工具,是给「有 200 个仓库要升级、而这件事已经拖了两个季度」的平台工程团队准备的。真正的巧思不在 Agent 多聪明,而在它知道哪些活不该用 Agent 干——该走脚本的走脚本,只有需要判断力的仓库才花钱派给 Claude Code / Codex。
发布 2026-09-15更新 2026-09-15核实 2026-09-15TL;DR
一句话定位:面向企业级代码库的大规模代码变更 Agent,2026-09-14 正式 GA。协调 Agent 拆解计划后逐段路由——不需要判断力的走脚本,需要判断力的委派给 Claude Code 或 Codex,通过 Sourcegraph MCP 注入仓库专属上下文,CI 失败自动重试,最后由人审核合并。适合仓库数在几十到几百、且手上压着「一直拖着没做的改造」的平台工程团队。
它到底是个什么
Agentic Batch Changes 是 Sourcegraph 在既有 Batch Changes(批量变更)产品线之上叠加的 Agent 编排层。要理解它,先看它要解决的老问题:
一个依赖的大版本升级,在 200 个仓库里可能有 200 种写法。传统两条路都不好使:
| 路径 | 优点 | 致命问题 |
|---|---|---|
| codemod 脚本 | 快、可复现 | 只认得模式,不认得这个 API 在这个仓库里到底怎么被用 |
| 人工逐个改 | 准 | 慢到做不动,200 个仓库就是两个季度 |
Sourcegraph 引述 Canva 高级软件工程师 William L. 的评价点出了要害:普通的脚本化改动「多半只是一次文本查找替换,完全不知道它实际是怎么被使用的」。
Agentic Batch Changes 走第三条路:由 Agent 理解每个仓库的上下文,再生成针对该仓库的改法——但只在该花钱的地方花。
核心能力
协调 Agent 与「脚本 / 编码 Agent」双路由
用户先用协调 Agent 规划一次变更。对计划的每一段,协调 Agent 判断:
- 这段是机械替换? → 走脚本,不消耗 LLM。
- 这段需要判断力? → 委派给 Claude Code 或 Codex。
Sourcegraph 明确说明这个路由是刻意设计的:避免为同一个改动付一百次编码 Agent 的钱。对企业级场景,这不是优化项,是能不能落地的分水岭。
代码库上下文经 MCP 注入
需要判断力的部分,Agent 会拿到仓库专属指令与代码库上下文,通过 Sourcegraph MCP 提供。这复用了 Sourcegraph 的老本行——代码索引与语义检索。
CI 失败自动重试
生成改动后跑 CI,失败时 Agent 会调整策略再试。这一步把「生成 → 验证 → 修正」的循环闭合了,是它区别于一次性 codemod 的关键。
人在环上(Human-in-the-loop)
工程师实时看到 diff 生成,每个 changeset 都需人工审核批准后才合并。官方并未声称能自动判断改动的业务正确性。
代码托管平台覆盖
支持 GitHub、GitLab、Bitbucket Server、Bitbucket Cloud、Azure DevOps、Gerrit。
价格
官方未公开定价。以下为 2026-09-15 查询官方新闻稿与产品页的结果,需申请 Demo / 联系销售询价。
| 档位 | 价格 | 限额 | 国内支付 | 定位 |
|---|---|---|---|---|
| Agentic Batch Changes | 未公开 | 需申请 Demo / 询价 | 需海外采购流程 | 企业级商业授权 |
询价时必须问清的一件事:编码 Agent(Claude Code / Codex)的调用如何计费——按仓库、按 changeset 还是按 token。路由设计省下的钱如果没体现在定价里,等于白设计。
工作流拆解(基于官方公开描述推演)
以下流程依据 Sourcegraph 官方新闻稿与产品页描述整理,AI 之家 未做一手实测;具体交互以产品实际为准。
1. 描述变更意图(自然语言)
↓ 例:「把内部 HTTP client 从 v2 升到 v3,处理 breaking change」
2. 协调 Agent 在索引过的代码库里定位受影响仓库
↓
3. 逐段路由:机械替换 → 脚本 / 需要判断 → 派编码 Agent
↓
4. 注入该仓库专属指令 + 代码库上下文(Sourcegraph MCP)
↓
5. 生成 diff → 跑 CI
↓
6. CI 失败 → Agent 调整策略重试
↓
7. 汇总所有 changeset,人工逐个 review + 批准 → 合并
客户实证(厂商公开引述):Canva 用它完成一次库迁移,跨仓库发起并合并 50+ 个 PR,并在同一处跟踪每个 PR 的状态。William L. 的原话是:没有它的话,「我们要么管理几个巨型 PR,要么管理一堆电子表格」。
同类对比
| 维度 | Agentic Batch Changes | Claude Code 直接跑 | 传统 codemod 脚本 |
|---|---|---|---|
| 适用规模 | 几十到几百仓库 | 单仓库 / 少量仓库 | 大规模但模式统一 |
| 理解上下文 | 代码索引 + MCP 注入 | 但需逐仓库重来 | 只认模式 |
| 成本结构 | 仅复杂段消耗 LLM | 全程 LLM | 几乎为零 |
| CI 失败处理 | 自动调整重试 | 手动 | 手动 |
| 人工审核 | 每 changeset 批准 | ||
| 上手成本 | 高(企业级采购部署) | 低 | 中(要写脚本) |
避坑清单
- 先问清编码 Agent 的计费口径。按仓库还是按 token,直接决定这次改造是省了还是超了。
- 索引质量决定一切。Agent 拿到的上下文来自 Sourcegraph 的代码索引;索引不全或不新的仓库,生成的改法就是错的——而它不会告诉你自己不确定。
- 别把它当自动合并器。设计好审核流程(谁审、审什么、超时怎么办)比关注生成质量更影响落地。
- 仓库数少时不要用。50+ PR 的规模才有明显收益;个位数仓库直接跑 Claude Code 更划算。
- 国内合规要先确认私有化方案。代码库不能出内网的组织,采购前必须确认是否支持自托管——官方新闻稿未说明这一点。
- 先做 audits 再谈 Agent。如果连「哪些仓库用了这个废弃 API」都答不上来,上 Agent 只是把混乱自动化。
适合 / 不适合
适合
- 平台工程 / DevEx 团队,负责跨仓库一致性改造
- 有 EOL 截止日期要搬的(语言版本、框架、运行时)
- 需要跨仓库做安全漏洞修复的团队
- 正在推新内部 API / 共享库、且各服务老写法各异的组织
- 用 Gerrit 或 Azure DevOps 的大型传统企业
不适合
- 仓库数在个位数的小团队
- 想要开箱即用、按量付费的个人开发者
- 代码库必须完全不出内网且无法采购商业软件的组织
- 期待「自动判断业务正确性」的人
相关阅读
- 同类工具:Claude Code · Codex CLI · Devin · Cursor · Muse Code
- 概念:MCP · Agentic Coding · 上下文工程 · AI Agent
- 相关资讯:Agentic Batch Changes 正式 GA · AI 编程日报 2026-09-15
Long-tail quick picks
Open-source alternatives
Free tier
China availability
来源
- Sourcegraph Announces General Availability of Agentic Batch Changes — BusinessWire(官方新闻稿)
- Sourcegraph Agentic Batch Changes 产品页
- Sourcegraph 官网
本卡片由 AI 之家 编辑部根据以上公开资料整理,非厂商付费内容;定价未在公开渠道披露,功能与可用性以官网为准,欢迎在 反馈邮箱 反馈更新。工作流拆解为依据官方描述推演,非一手实测。
| 计划 | 价格 | 限制 | 国内支付 | 备注 |
|---|---|---|---|---|
| Agentic Batch Changes | 官方未公开 | 需申请 Demo / 联系销售询价 | 需海外采购流程 | 企业级商业授权 |
- · 平台工程 / DevEx 团队(负责跨仓库一致性改造)
- · 有 EOL 截止日期要搬的(语言版本、框架、运行时)
- · 需要跨仓库做安全漏洞修复的团队
- · 正在推新内部 API / 共享库、且各服务老写法各异的组织
- · 用 Gerrit 或 Azure DevOps 的大型传统企业
- · 仓库数在个位数的小团队(直接跑 Claude Code 更划算)
- · 想要开箱即用、按量付费的个人开发者
- · 代码库必须完全不出内网且无法采购商业软件的组织
- · 期待「自动判断业务正确性」的人——它只自动化体力活
不适合个人开发者与小团队——这是按企业级流程卖的平台工程工具,定价不公开、部署门槛高,个位数仓库用它属于杀鸡用牛刀
- 定价完全不公开,必须走销售流程,无法自助试用评估成本
- 编码 Agent(Claude Code / Codex)的计费方式未公开——是按仓库、按 changeset 还是按 token 算,直接决定这套方案能不能控制住预算
- 依赖 Sourcegraph 的代码索引质量;索引不全或不新的仓库,Agent 拿到的上下文就是错的
- 无中文界面与国内技术支持,国内团队落地需自行解决采购与部署
- 仓库数少时收益不明显——50+ PR 的规模才真正划算,个位数仓库用 Claude Code 直接跑更省事
它和 Claude Code / Codex 直接跑有什么区别?
区别在于编排层。Claude Code / Codex 是「一个 Agent 在一个仓库里干活」;Agentic Batch Changes 是「一个协调 Agent 管几百个仓库」——它先找到所有受影响的仓库,再决定每个仓库该用脚本还是派编码 Agent,注入该仓库专属的上下文与指令,跑 CI,失败重试,最后把所有 changeset 汇总给你审。编码 Agent 只是它的一层执行器。
会自动合并代码吗?
不会。官方口径是工程师实时看到 diff 生成,每个 changeset 都需要人工审核批准后才合并。这一点很重要——它解决的是「找齐并生成改动」的体力活,不是替你做技术决策。
支持哪些代码托管平台?
GitHub、GitLab、Bitbucket Server、Bitbucket Cloud、Azure DevOps、Gerrit。覆盖 Gerrit 说明它瞄准的是大型传统企业(电信、汽车、金融)而非互联网初创。
「该用脚本还是编码 Agent」是谁决定的?
协调 Agent 在计划阶段逐段判断。Sourcegraph 明确说这个路由是刻意设计——避免为同一个改动重复付一百次编码 Agent 的费用。对跨仓库改造,这是能不能控制住预算的关键。
国内能用吗?
产品本身无中文界面,需走海外采购流程。若代码库因合规要求不能出内网,需要确认是否有自托管 / 私有化部署方案——官方新闻稿未说明,需直接询价确认。
可接入 / 兼容以下大模型 API(在设置中配置 key 即可切换底座):