2026年10月28日，GitHub 介绍了 Code Review Max 公开预览：同一份 PR，交给不同供应商的模型独立审查，再由一个聚合 Agent 核对发现、处理分歧，形成最终评审。同日发布的 Octoverse 报告显示：2026年9月，GitHub 上超过40%的 PR 由编码 Agent 提供初稿，3月这一比例还是17%。统计以 GitHub 能检测到的编码 Agent 为范围。越来越多代码改动从 Agent 的初稿开始，评审仍要回答：这些改动能否满足接口约定和业务规则？Max 的设计把这个问题拆成了两个环节：先让多个模型分别找问题，再检查这些发现是否成立。聚合 Agent 需要把分散的发现整理成有依据的结论，开发者才能据此继续处理。

先让模型分别找问题

独立分析为同一份改动保留了不同的检查路径。一个模型可能沿函数内部检查异常分支，另一个则追踪调用方，判断改动是否破坏了跨模块约定。如果后续分析一开始就围绕已有结论展开，注意力可能继续停留在同一组问题上。让模型先各自形成判断，尚未进入第一份答案的线索才有机会被提出。不同模型也可能共享同一个错误前提，因此仍要核查依据。例如，服务端按请求幂等键去重，并为它设置唯一约束。一个模型可能据此认为重复提交已经被覆盖；另一个沿调用链发现，客户端每次重试都会生成新键。若首次下单已写入成功、响应却丢失，重试就可能被当作新请求。在没有其他业务去重约束的情况下，同一笔下单仍可能产生第二张订单。这时，多模型分析带来了两个不同判断。开发者还需要知道，哪一个判断经得起代码检查。

聚合要说明哪些发现成立

在订单例子里，聚合步骤需要核对三个条件：重试是否确实换键，首次写入成功后是否可能丢失响应，以及是否存在其他约束拦截重复创建。如果这条风险路径成立，即使只有一个模型提出，也应保留。若稳定的业务去重机制已经阻止重复创建，则应说明防护在哪里，避免让开发者追查一条无效告警。同一问题的重复描述可以合并，不同的触发条件要分别留下。若只按支持人数筛选意见，那个提出关键线索的模型就可能被忽略；若只保留“通过”或“不通过”，后续又很难看出结论依赖了哪些前提。因此，一份可用的融合评审应保留问题位置、触发条件和代码依据。缺少调用方实现或业务约定时，也应明确指出待补材料，让开发者知道下一步从哪里继续查。

把这套协作接进自己的 Agent

对于自建 Agent 的团队，这套流程涉及多次模型调用、参考结果整理，以及最终的融合作答。应用既要让不同分析充分展开，也要把其中的有效信息交给后续判断。在 PPIO Agentic Cloud 的模型服务中，Fusion 提供多模型融合推理：参考模型独立、并行作答，网关编排并压缩各方分析，提炼共识、识别分歧，再由主模型生成融合回复。应用通过一次标准对话请求调用，由平台承接内部的模型协作。在代码评审中，应用负责准备变更、相关调用关系与业务约束，并要求输出保留每项发现的依据；融合回复再交回原有工作流，由开发者核查、补充测试或修复。团队可以把精力放在评审材料和任务要求上，减少自行维护多模型编排的工作。这种调用方式也适用于架构方案比较、复杂故障分析。团队可以按任务选择模型组合，在平台支持和授权范围内调整配置。更多分析需要时间和推理资源。GitHub 明确说明 Max 比 Lite 和 Balanced 耗时更长、消耗更多额度；Fusion 按内部模型实际 Token 消耗汇总计费。可以优先把多模型协作放在跨模块依赖、复杂权限或状态变化等关键判断上。回到订单例子，最终评审应能说清：重复订单是否可能出现，哪一段重试逻辑导致了它，需要用什么测试来确认。开发者拿到这样的结果，才知道该改哪里，以及为什么要改。