多个编程智能体共享代码库时，交付流程必须处理并发

Patrick Debois 介绍多人软件工厂：多人和多个编程智能体同时在同一交付流水线和代码库中工作。

单个开发者可能已经在本地运行多个智能体，但仍需作决定、合并更改并记住各智能体正在做什么。

Debois 区分了共享工具与上下文，以及真正的共享工厂：后者让人们围绕同一任务看板和代码库协作。

更多智能体可以产生更多拉取请求，但也增加冲突、重复变基和测试运行；一个智能体甚至可能撤销另一个的更改。

队列里既有功能工作，也有智能体引发的事故和工厂自身的维护。Debois 建议把并发设计成交付过程的常态。

一种应对方法是在编码前拆分工作：把不同领域、文件或函数分配给不同智能体，并利用依赖信息寻找可独立进行的更改。

智能体可以认领任务并声明预计修改的文件，让其他参与者避免开始重叠工作。

隔离可以超出 Git worktree，扩展到独立机器、数据库快照、测试数据和模拟外部服务，以减少相互干扰及对外部的影响。

工作发生冲突时，智能体可以等待、重试或重新协商计划。Debois 还设想让智能体解决部分合并冲突并预判正在进行的更改。

文本上干净合并仍不够。他举例说，一项更改把发票总额换成分，另一项更改报告逻辑；即使测试通过，组合后的意图仍可能出错。

他建议检查并发更改的意图是否仍然一致，而不只是检查代码行是否冲突。

推测式合并队列会提前测试兼容的更改组合，让其他仍然兼容的更改在某一项失败时继续前进。

在人这一侧，共享任务看板让团队看见正在进行和即将到来的更改。更多并发智能体也会占用人们更多注意力。

智能体可以加入团队对话，收集多人的意见，通过询问需求和测试来完善任务。

Debois 说销售、营销和支持人员也可以参与这个流程。他们的实验可以进入同一工程流水线接受审查，而不是停留在孤立原型中。

智能体遇阻时，他描述一种混合方式：打开带有其上下文的开发环境，让人介入调查，然后把工作交还。

包含具体选项的请求可以让人更容易作决定，同时仍允许人覆盖这些建议。

共享决策日志记录谁在何时决定了什么。人和智能体都可以在后续会话中利用它恢复上下文。

更改的大小还应适合人类审查。若只优化智能体之间不冲突，可能产生人无法有效检查的大型更改。

自动审查、更好的上下文，以及截图或测试等证据，可以减少交给审查者的工作并帮助他们看清发生的变化。

人工审查程度应反映风险。Debois 对比影响较低的文档和认证等敏感更改，并提出渐进发布作为中间方案。

风险还取决于恢复能力：当更改进入生产环境后出错，团队可以通过快速回滚、恢复和韧性设计降低影响。

更改增多也让沟通更难。不同团队需要用适合自己工作的语言理解与其相关的变化。

Debois 建议自动化常规工作，同时将例外和重要决定交给人处理。

他预计会出现类似平台团队的团队，负责维护智能体基础设施、共享 skill、上下文、连接和监控。

展望未来，他设想个人智能体参与共享看板并代表人回答其他智能体。他说这种组织模式仍在发展中。

最后，他邀请观众反馈，并介绍并发交付研究和 Tessl 团队的工作。