根据一项针对 2,900 名工程师的 2026 年调查，开发者现在每周花费 11.4 小时审查 AI 生成的代码，这一数字已超过了他们亲手编写代码的 9.8 小时。瓶颈已从“AI 能否生成代码？”转向了“我们能否信任它生成的代码？”，各团队正转向多智能体（multi-agent）AI 工作流，这种工作流有望提供更清晰的决策轨迹和更高的信心。
引发讨论的调查
这项于今年早些时候进行的问卷调查，询问了开发者如何在编写新代码和检查 AI 生成的代码之间分配时间。受访者表示，审查现在所花费的时间比最初的创建过程还要长。他们还报告称，在单个项目中需要同时应对两到四个不同的 AI 助手，且 70% 的人表示这种做法已成为常态。
这些数字反映了一种日益增长的挫败感：一个通用的单一模型可以在几秒钟内写出一个函数，但它也会在不留下任何记录的情况下，对数据结构、错误处理和性能优化做出隐蔽的选择。开发者最终不得不对这些决策进行逆向工程，这一过程可能会耗费一整天的工作时间。
为什么单一模型已不再足够
多年来，典型的流程是这样的：开发者输入提示词，模型生成一个文件，然后开发者将其复制到代码库中。这种方法适用于快速演示，但生产级软件的需求远不止一次性的输出。例如，当模型决定使用链表而不是数组，或者静默地吞掉异常时，这些选择会嵌入到代码中，并从审查者的视野中消失。
由于模型的内部推理过程没有被记录，团队在事后往往会问：“为什么 AI 会选择这种模式？”寻找答案通常需要翻阅生成的注释、使用不同的 temperature（温度）设置重新运行提示词，甚至需要重现整个生成步骤。这种不确定性在调查中体现为额外的审查时间。
分工协作：多智能体系统如何提供帮助
多智能体设置模拟了一个小型开发团队。不再由一个模型处理所有事情，而是由不同的智能体承担不同的职责：
- 架构智能体 (Architect agent)：生成高层设计文档，概述数据模型、API 契约和错误处理策略。
- 实现智能体 (Implementation agent)：严格按照架构编写代码，将规范作为检查清单。
- 验证智能体 (Verification agent)：生成单元测试、运行静态分析或配置 CI/CD 流水线，专注于质量保证。
每个智能体的输出都是一个独立的产物，因此决策背后的推理逻辑就存在于产物本身之中。在编写任何代码行之前审查架构，其成本远低于修复因错误设计选择而导致的 Bug。这种可追溯性也能满足合规团队的需求，因为他们需要了解是谁（或什么东西）决定了某个特定的实现细节。
让多智能体工作流变得实用的工具
开发者已经在利用各种工具拼凑这些流水线了：
- IDE 集成：让智能体以侧边栏的形式出现，只需点击一下即可将架构文档传递给代码生成助手。
- CLI 工具：实现脚本化序列：运行架构智能体，将其输出通过管道传递给编码智能体，然后将结果交给测试智能体。
- 框架：提供用于构建自定义智能体的库，可以根据项目需求进行更换。
- 规范优先平台 (Specification-first platforms)：在开始任何生成之前都需要正式的需求文件，从而确保设计步骤无法被跳过。
调查中 70% 的数据表明，大多数团队已经构建了这些流水线的临时版本。新平台只是将工程师们一直在手动进行的操作正式化。
谁将获益——以及谁可能被抛在身后
必须满足严格审计要求的企业（如金融或医疗行业）将立即受益。文档化的“从设计到代码”链条降低了隐藏漏洞进入生产环境的风险。对于发展速度足够快、单一模型的速度足以抵消偶尔返工成本的小型初创公司来说，维护多个智能体的开销可能显得并无必要。
有一种反驳观点认为，多智能体系统会增加复杂性。协调三个或更多模型可能会引入集成漏洞、增加延迟，并需要更复杂的监控。缺乏构建或管理自定义智能体专业知识的团队，在编排上花费的时间可能比实际开发还要多。对于这些团队而言，一个经过良好调优的单一模型——尤其是那些提供内置可解释性的模型——可能仍然是务实的选择。
未来几个月值得关注的趋势
- 标准化的日志格式（针对 AI 生成的产物）可能会让比较不同智能体之间的输出变得更加容易。
- 将架构、编码和测试智能体捆绑在单一订阅中的市场化产品，可能会降低缺乏内部 AI 专业知识的团队的使用门槛。
- 关于 AI 辅助代码的监管指南可能会推动更多组织转向可审计的多步骤流水线。
- 衡量总开发时间（而不仅仅是生成速度）的性能基准测试，将帮助团队决定额外的协调开销是否物有所值。
调查的核心数据说明了一个清晰的事实：开发者每周花在复核 AI 输出上的时间比编写新代码的时间还要多。多智能体工作流作为一种直接的回应应运而生，它提供的可追溯性将“黑盒”生成转变为一个有据可查、可供审查的过程。增加的编排复杂性是否对每个团队都物有所值仍有待观察，但将 AI 职责进行拆分的趋势已经在重塑软件构建的方式。