编码智能体并行化中的审查与协作控制

并行运行多个编码智能体在造成计算问题之前，首先会造成审查问题。

瓶颈很少在于打开另一个终端。瓶颈在于决定哪个会话值得关注、谁负责每项更改，以及需要何种证据才能接受结果。

一堆聊天窗口无法回答这些问题。团队负责人需要一个包含已归属工件和审查决策的队列。

在并行化之前划分工作

每个任务应有一个负责人、一个请求的工件和一个写入范围。如果两个会话可能编辑同一个文件，请决定由谁集成最终更改，或将工作串行化。

这是首要的控制措施，因为如果没有所有权界定就进行并行执行，只会将冲突解决推迟到审查阶段。所有会话都可能成功完成，但合并后的更改仍然无法被接受。

一张有用的任务卡片应命名以下内容：

会话标识符应随任务卡片、证据和最终审查决策一同流转。

并非每个活跃会话都值得同等关注。一个实用的队列会根据负责人下一步必须执行的操作对状态进行排序：

这种排序可以防止嘈杂的长期运行任务掩盖那些等待单一批准的小型任务。

会话的最终消息是一种主张。审查包则是支持该主张的证据。

对于代码更改，该包应包括差异范围、诊断信息、构建或测试结果，以及当更改涉及用户界面时的实际使用检查。对于研究或运维任务，它应包括来源统一资源定位符（URL）、凭证、回读状态以及任何未解决的不确定性。

团队负责人应能够在不重新打开整个转录记录的情况下回答以下三个问题：

如果审查包无法回答这些问题，则该条目尚未准备好进行审查。

最早完成的任务并不总是下一个要审查的任务。应按影响范围和可逆性进行排序。

身份验证、权限、迁移、部署配置和共享契约比孤立的副本更改更值得关注。即使本地编辑更容易逆转且先完成，也可以排在外部可见的操作之后。

这也是会话状态应与工件状态保持分离的原因。会话可能已完成，但其更改可能仍未审查、被拒绝或被阻止集成。

不要让“智能体完成”等同于“更改已发布”。要为就绪、审查中、已接受、已集成和集成后验证保留明确的状态。

这一流程保护团队免受两种常见错误的影响：在没有证据的情况下合并看似合理的结果，以及因为产生良好结果的会话已关闭而丢失对该结果的跟踪。