拉取请求大约十倍之后，要等的是合并

软件交付的流水线在人工智能之前就有。构建，测试，然后等发布，等合并进主线。Patrick Debois 说这基本上是一条串行的流。它让交付更自动，也更稳。与此同时，人们在自己的笔记本上、在编程智能体里面造工厂。他叫它们单人工厂。智能体越用越多，决定和合并仍常常落在同一个人身上。这个人还得自己记住正在做什么，几乎是整套系统的中心。

他要讲的是下一级。中间还有一档：人们开始共享上下文、技能和循环，这是眼下很多工厂的状态。再往上，是多人同时协作，同一块工单板，同一份代码。左边的张力是每个人都想并进主线。右边的张力是板上的人得一起把事做完。

原始来源：Your Team's Agents Are All Shipping to the Same Code at Once - Patrick Debois, Tessl。中文深度整理，非逐字翻译。本文依据 YouTube 自动生成的英文字幕，专有名词和数字可能有识别误差。字幕里的 Tesla 是 Tessl。ASD graph、SCD、merge cube、Helix ML、PRQ 按字幕保留，不改成另一种术语。约 10 倍是他的口述，不是一份计量研究。

写得越快，队列越堆在合并上

工厂或多人工厂一打开，他看见的第一件事是拉取请求变多，口述几乎是 10 倍，而且还在往上。更多改动被做完，这是产出。张力也从这里长出来。合并变多，还得保证不冲突。运气不好时，智能体会绕圈子：一个改了某样东西，另一个把它改回去。这些冲突在多人工厂打开之后是真的。

更显眼的是开始为发布等待。一次合并之后，其余的拉取请求都要变基，测试通常重跑。持续集成和持续交付因此慢很多，也更贵。贵是副作用。

队列里堆的也不只是功能。还有智能体自己造成的事故要处理。还有工厂自己的维护：技能要改，循环要改。这些都要人批准。他问的是，为什么并发只能当例外。他把目标叫做并发交付，从持续交付走过去，让人和智能体可以在同一份代码上一起做。

拆工作是第一步，像拆工作单元。你做认证，我做支付，另一块交给别人。字幕里的 ASD graph 用来判断哪些块分得开。再往下可以到文件、到函数，甚至到同一文件里的某些击键一起做。这是在写代码之前先把变更计划好。

计划开始执行，像在看板上看板。智能体写明自己认领这张工单，别的智能体就不能同时插手。它还宣布要动哪些文件、做哪些改动。别的智能体在计划和执行期间能看见，避免叠到一起。

很多人用工作树把执行隔开。他想的隔离更宽：给智能体自己的机器，自己的一截上下文，字幕听成 phrase；给它一份被锁住的 API 版本；数据库有自己的快照和测试数据；外面的世界用数字孪生和模拟挡上。这样它做事时不必承受外部影响。

两个智能体在干活时撞上，他列了几条策略。一个等另一个。等完再重试。等着，但是重新排队，直到对方做完。或者当场改计划：你做这块，我做那块。这是边执行边重新谈判，让双方别再互相妨碍。

冲突今天的处理是在 Git 里重跑，看这一次能不能并上。这通常就是拉取请求上的那次变更。他希望智能体来做这件事。不只按代码行看能不能并，按函数看，合并可以更聪明，也许由智能体把合并修好。再往前，是看见变更正在过来：那个智能体大概会改这里，我已经在改自己的代码。这是按并发来想，而不是按串行的变更来想。

代码合得上，意图仍可能不合。他的例子是发票合计。一个变更把函数从美元改成美元的分。同时另一个拉取请求在改报表怎么输出。两次合并都可以过，测试也过。报表不想要欧元的分，也不想要美元的分。代码没有冲突，意图有冲突。智能体可以去看多次合并之间的意图还一不一致，然后警告，或者把拉取请求改到一致。

一条合失败，通常是其余全部变基、返工。他给出的另一条路叫 speculative merge trains。进来的拉取请求先看哪些彼此兼容，成对先检查。这一条上不了，其余仍能上的可以先走，他口中是走 merge cube，于是更快。这些是他举的新策略：合并、冲突、评审、更好的计划。他认为一层新的开发者基础设施正在出现，供应商那边已经看得见：合并会换一种处理，分析、计划、工具都在补。眼下很多工厂在他看来仍是加了光环的循环，字幕听成跟 SCD 一样。并发只会更多。

工单要变成一块共享的计划

人的那一面，是一块共同的任务板。人能看见什么变更要来、什么任务在做。单人工厂里这些都在一个人脑子里，没有一块放在中间的板。

板上的事都要人注意。这在他看来还是容易的那一头。难的是把智能体不停叫人的次数降下来。多个智能体同时干活，这个副作用会出来。

他看到的一种做法是把智能体拉进聊天。编码不再是你一个人写提示。智能体同时从你和队友那里拾线索，用这些输入把工单收细。智能体的对抗式评审还在。同一张工单上，对话进行时还有多个人的输入。它擅长反过来提问，而不是等人把所有东西重复说完。测试是什么、行为该是什么、需求有哪些，在这里被问清。工单于是接近编程智能体里的计划模式，但是变成板上的共享功能，摊开全部需求。

进这块板的不必先是工程师。以前销售、市场和支持把工单丢给工程，落在某处，然后等，他口中可以等上几周。他说在他们工厂里，人们在组织内部的聊天里就把智能体拉上。不一定每次都把代码做完。以前的 vibe coding 对不上工程实践。多人工厂用的是同一条流水线、同一套知识、同一批技能和循环，一进来就落在工程的流程里。他们可以试验，可以把功能收细，也可以把功能做起来，以前则要等。字幕把工程侧的下一句听成 engineering refused that。字面是工程拒绝了。上下文是在说这条流程很有力。本文不把「拒绝」写成一种已经写明的交接规则。

工厂里的工单模式有时慢，人想要快的来回，智能体执行到一半也会不确定。他提了一个来自 Helix ML 的做法：智能体卡住时，打开一个带着当前上下文的编程环境，文件都在。人跳进去做选择、做试验，再交回给智能体和工厂。这是个人编程智能体的快，和工厂之间的一块中间地。智能体也可以用它来把问题问清、来求助。

选择本身要变少。呈现给人的是几个可选项，人选一个，它就走。人可以改口。不必每次都从头告诉它该做什么。每一次人做的决定记上一本账。单人的编程智能体里，这也许只是本地上下文。多人工厂里，它放在一份共享的决策日志上。人和智能体都能查谁在什么时候做了哪个决定。下一次会话用到这段上下文时，也可以查询。

审的是能承担的风险，回滚得先变便宜

变更要小，因为大的变更读不完。智能体之间不互相改回去，只解决了一半。另一半是人能审多少。他的做法是拆成多份拉取请求，放进多条合并列车，让人能审得快。

很多人想减少评审次数，于是做自动评审。第一段是把失败降下来：更好的上下文、更好的工具、对抗的智能体在代码到人之前先看一遍。质量上去，风险下来。同时要让人看见它做了什么。他点了屏幕流程、截图、视频、证明和测试，都是帮评审的人看的东西。

再往下是一个人还能不看代码到什么程度。有几个人告诉他，自己已经不看代码了。他反问：这东西进生产的影响是什么。文档，影响有限。有的还没有真客户，影响也不大。挑选的标准是你能承担什么风险。文档那一类可以说往前走。认证这种影响大的失败，人要多看。中间一档是先铺开，再看输出、看有没有错误，也就是渐进发布。只优化质量、只把发生的可能性做低，还不够。还得从风险看。

出了生产之后，风险要能被压住。字幕说的是 when it moves out of production。影响若是丢掉数据，有没有快的恢复。一个节点挂了，能不能快回滚。这些是架构决定。出事时，恢复或修好得便宜。拉取请求上的风险因此有不止一条路，不只是把代码审得更干净。

变更还得被辐射出去。他自己远程工作，团队多数在伦敦。别人聚在一起聊，他远程时很难跟上发生了什么。多人工厂一开，每个人都得跟上。产出的代码多到市场、支持和其他岗位可能跟不上。他们需要一份用自己的语言写成的变更说明。在自己的领域里、按自己的工作，怎么保持跟得上。沟通和把变更辐射出去，在他看来是多人工厂里很重要的一项功能。

能自动的就自动，技能、上下文这些部分持续改好，人留给例外。基础设施和协作方式都在的时候，仍要能把决定送到人那里。

照看着这些的，是他称为工厂团队的一群人，像以前对付 Kubernetes、集群和云的平台团队。现在对付的是编程智能体，以及大家一起工作的那层织物。谁拥有技能，上下文有没有更新，东西有没有接到该接的地方，工厂本身有没有被维护、有没有被监视。

他收成两头压力。一头是智能体在同一份代码里越来越多地一起干活。一头是人越来越多地和智能体一起、以并发的方式交出更多产出。两头都要改很多东西。

他们正在试的下一截，是个人智能体。不只是写代码的智能体，也不只是在板上做事的人。个人智能体会上板，替人做决定，也回答别的智能体。这是把你还在工厂里做的一部分任务再委托出去。他的建议是做好准备。还没到那一步。编程智能体是单人工厂上很好的一步。多人工厂会给智能体写代码、也给人一起工作，带来新的动力学。

幻灯片他愿意用领英私信换反馈。研究放在 concurrent.cd，收集在解这件并发的人、工具和做法。Tessl 的工厂，字幕听成 Tesla，他邀请人去试他们正在做的循环、工厂和技能，以及多人模式。10 倍、互相改回、变基造成的等待，是他描述的压力。恢复做便宜、变更辐射给非工程角色、工单变成共享计划，是他给出的对策方向。哪些已经在工厂里跑通，字幕没有逐项给出计量。