跳到主内容
TOOL · CODING #09/09编程 Agent
S

Sourcegraph Agentic Batch Changes

把「跨 200 个仓库的依赖升级」交给协调 Agent:该用脚本的用脚本,该动脑的派给 Claude Code / Codex

agententerprisecodemodbatch-changemcpci-retrymulti-repodevops
访问官网 关注此工具更新
能力
4
易用
3
性价比
2
中文
2
稳定
4
编辑结论 评分方法 综合3.0/ 5

不是给个人开发者的工具,是给「有 200 个仓库要升级、而这件事已经拖了两个季度」的平台工程团队准备的。真正的巧思不在 Agent 多聪明,而在它知道哪些活不该用 Agent 干——该走脚本的走脚本,只有需要判断力的仓库才花钱派给 Claude Code / Codex。

发布 2026-09-15更新 2026-09-15核实 2026-09-15
01 / 06深度解读

TL;DR

一句话定位:面向企业级代码库的大规模代码变更 Agent,2026-09-14 正式 GA。协调 Agent 拆解计划后逐段路由——不需要判断力的走脚本,需要判断力的委派给 Claude CodeCodex,通过 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 ChangesClaude Code 直接跑传统 codemod 脚本
适用规模几十到几百仓库单仓库 / 少量仓库大规模但模式统一
理解上下文代码索引 + MCP 注入但需逐仓库重来只认模式
成本结构仅复杂段消耗 LLM全程 LLM几乎为零
CI 失败处理自动调整重试手动手动
人工审核每 changeset 批准
上手成本高(企业级采购部署)中(要写脚本)

避坑清单

  1. 先问清编码 Agent 的计费口径。按仓库还是按 token,直接决定这次改造是省了还是超了。
  2. 索引质量决定一切。Agent 拿到的上下文来自 Sourcegraph 的代码索引;索引不全或不新的仓库,生成的改法就是错的——而它不会告诉你自己不确定
  3. 别把它当自动合并器。设计好审核流程(谁审、审什么、超时怎么办)比关注生成质量更影响落地。
  4. 仓库数少时不要用。50+ PR 的规模才有明显收益;个位数仓库直接跑 Claude Code 更划算。
  5. 国内合规要先确认私有化方案。代码库不能出内网的组织,采购前必须确认是否支持自托管——官方新闻稿未说明这一点。
  6. 先做 audits 再谈 Agent。如果连「哪些仓库用了这个废弃 API」都答不上来,上 Agent 只是把混乱自动化。

适合 / 不适合

适合

  • 平台工程 / DevEx 团队,负责跨仓库一致性改造
  • 有 EOL 截止日期要搬的(语言版本、框架、运行时)
  • 需要跨仓库做安全漏洞修复的团队
  • 正在推新内部 API / 共享库、且各服务老写法各异的组织
  • 用 Gerrit 或 Azure DevOps 的大型传统企业

不适合

  • 仓库数在个位数的小团队
  • 想要开箱即用、按量付费的个人开发者
  • 代码库必须完全不出内网且无法采购商业软件的组织
  • 期待「自动判断业务正确性」的人

相关阅读

Long-tail quick picks

Open-source alternatives

  • 是否开源:(Sourcegraph 商业产品)
  • 开源替代路线:Aider + 自写编排脚本,或 OpenCode 配合仓库遍历;代价是要自己实现路由、上下文注入与 CI 重试。

Free tier

  • 是否有免费档:(官方未公开任何免费额度)
  • 预算敏感团队可参考 通义灵码 / CodeGeex(国内免费额度更友好)。

China availability

  • 是否国内可用:待确认
  • 中文友好度评分:2 / 5
  • 无中文界面与国内技术支持,需走海外采购流程;代码库不出内网的组织须先确认私有化部署方案。
  • 中文场景可考虑 Trae / 通义灵码 / Comate

来源

本卡片由 AI 之家 编辑部根据以上公开资料整理,非厂商付费内容;定价未在公开渠道披露,功能与可用性以官网为准,欢迎在 反馈邮箱 反馈更新。工作流拆解为依据官方描述推演,非一手实测

02 / 06价格速查
计划价格限制国内支付备注
Agentic Batch Changes官方未公开需申请 Demo / 联系销售询价 需海外采购流程 企业级商业授权
03 / 06适合 / 不适合
适合谁
  • · 平台工程 / DevEx 团队(负责跨仓库一致性改造)
  • · 有 EOL 截止日期要搬的(语言版本、框架、运行时)
  • · 需要跨仓库做安全漏洞修复的团队
  • · 正在推新内部 API / 共享库、且各服务老写法各异的组织
  • · 用 Gerrit 或 Azure DevOps 的大型传统企业
不适合谁
  • · 仓库数在个位数的小团队(直接跑 Claude Code 更划算)
  • · 想要开箱即用、按量付费的个人开发者
  • · 代码库必须完全不出内网且无法采购商业软件的组织
  • · 期待「自动判断业务正确性」的人——它只自动化体力活
04 / 06避坑提醒
NOT FOR · 什么情况下不要选它

不适合个人开发者与小团队——这是按企业级流程卖的平台工程工具,定价不公开、部署门槛高,个位数仓库用它属于杀鸡用牛刀

PITFALLS · 避坑提醒
  • 定价完全不公开,必须走销售流程,无法自助试用评估成本
  • 编码 Agent(Claude Code / Codex)的计费方式未公开——是按仓库、按 changeset 还是按 token 算,直接决定这套方案能不能控制住预算
  • 依赖 Sourcegraph 的代码索引质量;索引不全或不新的仓库,Agent 拿到的上下文就是错的
  • 无中文界面与国内技术支持,国内团队落地需自行解决采购与部署
  • 仓库数少时收益不明显——50+ PR 的规模才真正划算,个位数仓库用 Claude Code 直接跑更省事
05 / 06 常见问题
它和 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 即可切换底座):

mcp
Newsletter

关注这个工具的后续更新

订阅 AI 之家 周报,第一时间获取该工具版本更新、定价变动与重新评测结果。