维护过开源 fork 的人都知道那种感觉。
上游发了新版本。里面有你等了很久的 bug 修复，但你打开 diff 看到几百个文件变更，心跳已经开始加速——这次同步又要吃掉你下周的大半个工作时间。
上一次花了将近两周。你的主业被切成碎片：上午 debug 一个 API 变更引发的回归，下午回群里解释为什么 feature 进度慢，凌晨可能还要接 on-call。
这不是某一家公司的问题。任何团队只要对开源项目做过深度定制，就背上了这个成本。只不过绝大部分人没算过这笔账——它散落在被推迟的发布计划里、被切成碎片的周报里、凌晨三点被叫起来修的回滚里。
它叫维护债。没有 ticket，没有排期，但利息比技术债更稳定——每次上游更新，就是一次还款日。
这个循环其实有结构
仔细想一下，fork 同步的工作流每次都一样：把上游新代码合进来，跑测试看什么坏了，修坏掉的东西，再跑测试，直到全绿。
sync → measure → fix → repeat。
控制论里叫闭环反馈——有一个期望状态，有一个外部扰动，有一个控制器不断缩小误差直到归零。
<!-- diagram:feedback-loop -->
定速巡航就是这个原理。你设好速度，车上坡自动加油门。没人会为「手动跟着坡度调油门」感到骄傲——它就是该被自动化的。
但 fork 同步一直没被自动化。传感器是测试套件、benchmark、模型评测。执行器是 rebase、patch、CI 重跑。两者之间一直缺一个能自己做决策的胶水——过去全由工程师手动完成：看哪个测试结果、改哪行代码、什么时候再跑一轮。
直到 coding agent 能当这个胶水。
从 weeks 到 days
Cohere 维护着一个 vLLM 的 fork，上面有他们定制的模型支持和 kernel 优化。上游 vLLM 大概每几周发一个版本，单次 diff 可能涉及几百个文件。
他们写了一套 agent skill，把整个闭环串了起来。告诉 agent 去同步到最新上游版本并确保某个测试通过，agent 自己去做 rebase、跑测试、看失败原因、修代码、再跑测试——循环直到全绿。人只需要最后 review 一下结果。
这里面有一个故障值得单独讲。
vLLM 从 v0.19.0 升级到 v0.19.1 时，上游升了一版 transformers 依赖。这个变化静默地破坏了 Cohere 的 ASR 语音识别模型——WER 从正常的 11.92 直接炸到 100。模型输出变成乱码。
agent 自己完成了整条诊断链：对比两个上游版本之间的 diff，定位到 tokenizer 的行为变更，应用了一个临时修复，WER 回到 11.92。随后工程师把这个修复整理成正式的 PR 推回了上游。
整个过程在一次交互对话中完成。效果也很直接——原来吸收一次上游发布需要数周断断续续的人工介入，现在降到几天，期间几乎不需要人盯着。
这还没完。他们后来在自己维护的 HuggingFace transformers fork 上又跑了一遍同样的流程。transformers v5 大版本升级，废弃参数、新签名、tokenizer 行为变更全涌进来——同样的闭环把问题逐一收敛。
重新算 ROI
过去两年关于 AI coding 的 ROI 讨论，几乎全围绕着「一个 AI 能替代几个工程师」展开。这个算法很直观，但只算了一层。
替代一个人的工资，省的是显性成本。那些散落在「等待同步」「修复回归」「推迟发布」里的时间，对工程组织来说更贵——它们直接挤压发布节奏，吃掉团队带宽，从来不会出现在工资单上。
一个团队一年做四次 fork 同步，每次烧掉三个人各两周，这就是二十四个工程师周。如果 agent 能把这个时间压到一半甚至更少，释放出来的是整个团队做新东西的带宽。
ROI 最核心的变量，是省了多少次人工介入。决策和上下文切换的时间，远比敲键盘的时间值钱。每少一次「我来看看这个测试为什么挂了」的打断，就多一整块能连续思考的时间。
从 weeks 压到 days 之后，架构变了：以前三个人断断续续盯两周，现在每期只要一个人 review 最终结果。
该测什么
评估一个 AI 编程工具，除了看它能从零写出多少行新代码，再看看它能不能接手一个已有系统的维护循环——扰动进来之后把系统恢复到健康状态，而且不需要人每一步都盯着。
这套机制不是 vLLM 专有的。sync → measure → fix → repeat 这个闭环，换一个代码库照样成立。Cohere 已经把整套 skill 开源了。
下次评估 AI 工具的 ROI 时，不妨多看一个数字：你们团队在维护已有系统上花了多少人工小时。别只盯新代码。
