多AI智能体并行开发的核心挑战：集成成本远高于编码效率

大家周一好！这是我 AI 编程系列的第九部分。到目前为止，我主要聊的是用 Codex 或 Claude 处理单个任务。但还有一个层面我想探索一下：当多个 AI 智能体同时在同一个项目上工作时，会发生什么？

一个智能体做前端，另一个处理 API，第三个搞数据库，第四个写测试。听起来很棒。四个任务同时推进，而我可以专注于别的事。但四个完成的任务并不会自动拼成一个能跑的产品。

想象一下，前端智能体按某个 API 响应格式建好了页面。后端智能体因为觉得对自己的任务更合理，改了响应结构。两边都顺利完成，都报告一切正常。然后你把它们连起来，发现它们为同一个功能各建了一套版本。

没有人写的代码一定很糟糕。它们只是在不知道其他智能体在改什么的情况下做了决策。这时候，Git worktree、分支和 API 契约这类东西就变得重要了。worktree 给每个智能体一个独立的工作目录，这样它们工作时不会互相覆盖文件。但隔离只解决了一部分问题。

独立的 worktree 能防止智能体踩到彼此的改动。但它们没法阻止两个智能体做出不兼容的决策。这就是为什么当工作变成并行时，任务边界变得重要得多。

如果智能体共享同一个数据库结构、认证逻辑或 API 契约，我不能简单地让每个智能体各干各的，然后指望后面能拼到一起。它们需要约定好的接口、清晰的职责划分，有些改动还必须按特定顺序进行。

我能看出这会对我的不同项目产生不同影响。在电商网站上，独立的视觉组件很适合并行工作。一个智能体做产品页面，另一个做独立的 UI 组件，第三个准备测试。

CRM 就复杂多了。数据表、筛选器、查询和业务逻辑都是连在一起的。两个智能体改同一个数据流，可能带来的集成工作量比它们省下的时间还多。

我的加密项目需要更严格的边界。钱包状态、角色、访问规则和各种集成，不能各自独立演进而不检查改动之间的相互影响。

还有一个成本人们有时会低估：集成。五个智能体能很快产出五套改动。但还是得有人审查代码差异、解决冲突、检查 API 兼容性、跑测试、验证整个用户流程。而且每个智能体分支里测试通过，并不能证明合并后的系统能正常工作。

这就是为什么我觉得“集成负责人”这个概念很有用。必须有一个智能体或一个人对最终结果负责，而不只是对各自的那几块负责。前端和后端是否就同一个契约达成了一致？数据库改动是否保持兼容？安全规则在集成后是否还成立？整个功能在全部合并后是否能正常工作？

没有这个，并行开发可能变成一种非常快地生产大量未完成工作的方式。我仍然认为多个智能体有巨大潜力。但我不会用它们同时完成了多少任务来衡量价值。我会用集成之后能产出多少可用的软件来衡量。

五个智能体能更快地写代码。但还是得有人确保它们在建的是同一个产品。