AI智能体协作框架实测：三种模式对比，推荐混合方案
研究者通过让不同框架团队开发同一个真实工具，测试了三种核心差异较大的AI智能体协作框架，记录了测试过程、故障问题和适用选择。
有关AI智能体协作的宣传称，多智能体共同工作能完成比单智能体更多任务，演示效果很好，但实际交付产品时，会出现很多实际问题：如何拆分工作？智能体如何协调？并行开发真的有帮助，还是只会带来整合难题？研究者决定开展真实测试而非思维实验来解答这些问题。
测试设计了对照实验，三种不同的AI团队协作框架，完成同一个真实任务，用相同指标评估。任务是开发一款名为csv2json的Python命令行工具，实现带类型推断和数据验证的CSV转JSON功能。这个任务具备真实开发的复杂度，涉及边界情况处理、架构决策、测试和文档，同时范围可控，能在合理时间内完成。
所有框架都在相同基础设施上运行：基于Hermes Agent，使用GLM-5.2模型，并行任务使用子智能体委托，工作目录结构完全一致。要求所有智能体产出可运行代码、执行测试并验证输出，不允许使用占位桩、不接受“理论可行”的说法，不允许虚构结果。
第一种框架是专业化分工并行模式：三名智能体同时工作，各负责一个领域，分别是研究专员、实现专员和文档专员，相互看不到对方的工作。该框架的假设是：并行能最大化速度，专业化能最大化质量。
第二种框架是顺序流水线模式：三名智能体按顺序工作，流程为研究→实现→文档，前一名智能体的输出直接传递给下一名。该框架的假设是：交接能保证对齐，下游智能体始终基于上游真实工作开发。
第三种框架是并行群集+共识模式：三名智能体并行独立开发完整工具，包含代码、测试和文档，之后由第四名共识智能体审核全部三份成果，选择最佳方案合并为一个最终版本。该框架的假设是：冗余开发能通过竞争选择产出更高质量的成果。
评估指标包括：实际耗时，从启动到完成的总时间；测试结果，通过和失败的测试数量；代码体量，产出的代码、测试和文档行数；整合质量，产出物是否匹配，文档和代码是否对应，研究成果是否指导实现；命令行功能，工具端到端能否正常运行；边界情况覆盖，包含BOM处理、Unicode、嵌入换行符、空文件、类型推断。所有测量都来自真实工具输出，包含实际pytest运行结果、实际命令行调用结果、实际文件统计，没有估算和猜测。
对于第一种专业化分工并行框架，三名智能体同时启动，研究专员产出了1314行技术规范，实现专员产出了443行csv2json.py代码和321行测试，文档专员在四个文档文件中写出了共1959行内容。
三名智能体完成时间相差不到几秒，都大约用了170秒，是所有框架中实际耗时最短的。最终结果：总耗时约171秒，58项测试全部通过，代码共764行，文档共1959行分4个文件，研究规范1314行，工具可以正常运行。代码整洁，测试全部通过，工具各项功能正常，文档写得完善专业。
该框架出现的问题是文档和代码不匹配。因为三名智能体完全隔离工作，文档专员编写的文档对应一个不存在的工具，API.md中记录的多个类都没有出现在实际实现中，README描述的多个命令行选项也不存在于实际工具中。实际工具只有5个选项，文档记录了12个以上，差异非常明显。
研究专员写出的1314行规范也没有被实现专员读取，实现专员从头设计了自己的方案，类名、函数签名、命令行结构都和规范不同，研究工作完全被浪费了。
该框架的总结：速度优秀，单个产出物质量优秀，整合质量差。专业化分工框架能产出出色的独立组件，但组件无法组合成整体，就像三位专家在三个房间各自创作杰作，无法拼出一个完整连贯的产品。如果你需要速度，后续可以由人类完成整合工作，这个框架可用；如果你需要一个连贯的交付成果，它不适用。
对于第二种顺序流水线框架，三名智能体按顺序工作，研究专员产出1649行规范，实现专员读取规范后基于它开发工具，文档专员读取实际代码后基于它编写文档。交接是该框架的核心特点，每个智能体的输出都是下一个的输入，不需要猜测，不会出现并行开发的对齐问题。
最终结果：总耗时约850秒，其中第一步177秒，第二步550秒，第三步约120秒；177项测试通过175项，有2项失败，因为智能体在调试中用完了迭代配额；代码共2992行，文档共1200行分4个文件，所有文档和实际代码完全匹配；27个CSV测试用例覆盖所有边界情况，工具可以正常运行，共支持22个命令行选项。
实现成果体量很大，1679行Python代码包含30多个类和函数，搭建了完整架构，包含异常层级、类型推断、验证引擎和polars快速路径选项。规范直接塑造了实现，实现严格遵循规范的类型推断优先级、选择的依赖库、项目结构和边界处理策略，规范中93个代码模式都直接落地使用。
该框架出现了两个问题：第一，实现智能体用完了迭代配额，它花费550秒开发调试，在修复最后两个失败测试前就达到了迭代上限，两个失败分别是日期推断边界问题和严格模式退出码bug，工具可以正常处理真实CSV输入，但两个测试仍然不通过。第二，存在顺序瓶颈，该框架总耗时是第一种框架的四倍以上，研究完成后实现才能开始，实现完成后文档才能开始，总实际耗时约727秒，且还存在继续延长的可能。
该框架的总结：速度差，比第一种慢四倍；实现质量优秀，代码体量是前者两倍，支持22个命令行选项，27个测试用例；整合质量优秀，文档匹配代码，规范指导实现。顺序流水线能产出最全面、整合最好的成果，但速度慢，顺序依赖链会让一个智能体的延迟传导到所有下游环节，实现阶段用完迭代配额是真实存在的风险，它是最复杂的步骤，却没有多少调整恢复的空间。
对于第三种并行群集+共识框架，三名智能体并行独立开发完整工具，包含代码、测试和文档，每个智能体自己做架构决策，之后由第四名共识智能体审核三份成果，对比不同方案，选择最佳基础，再合并其他方案的优势得到最终版本。
最终结果：总耗时约468秒，其中并行开发183秒，共识处理285秒；共识合并后的成果72项测试全部通过，29项随机检查全部通过；最终代码共1088行，三份独立实现共产生1925行冗余代码，工具可以正常运行。
三份独立实现的差异非常明显，不同智能体选择了不同的CSV读取方式、测试数量、输出格式、特殊值处理方式，对各类功能的支持也不相同。共识智能体选择Agent C作为基础，它的架构最简洁，支持特殊值排除、0/1保留整数类型、中断信号处理，又合并了Agent A和Agent B的优势功能，最终合并成果测试全部通过，还附带一份合并报告说明每一项决策。
该框架没有出现功能故障，但成本非常真实，三名独立智能体产出了1925行冗余代码，三份实现中有两份被部分丢弃，为了最终保留的功能，浪费了大量算力和token。共识智能体本身也花费了约285秒，时长接近并行开发阶段，审核对比合并三个完整代码库的工作量并不小。
该框架的总结：速度良好，比第二种快2.7倍，比第一种慢2.7倍；质量良好，测试全部通过，所有检查都通过；整合质量良好，共识合并记录了所有决策；成本高，冗余工作量达到三倍。并行群集+共识框架通过竞争选择产出高质量成果，冗余本身是特点不是缺陷，你能得到三个独立方案再选最优，但需要承担对应的算力成本。
没有任何一种框架在所有指标上都获胜，测试数据显示最优方案是混合框架，结合每一种原有框架的优势，分为四个阶段。
第一阶段：顺序研究，1名智能体产出技术规范，作为所有下游环节的基础，规范需要包含：带理由的依赖库选择、代码模式和函数签名、项目结构、边界情况清单、测试策略。这个阶段用顺序开发的原因是，规范是整个项目的契约，所有后续工作都基于它，这个阶段并行开发会增加基础对齐出错的风险。
第二阶段：并行实现与测试，启动2到3名实现智能体并行开发，所有人都基于同一份规范，但可以采用不同架构方案，每个智能体只需要开发代码和测试，暂不生成文档，此时接口仍可能调整。这个阶段用并行开发的原因是，实现风险最高、创造性最强，多个独立方案能给你选择空间，降低单智能体错误设计影响后续所有环节的风险。
第三阶段：共识合并，1名共识智能体审核所有实现成果，选择最佳基础，合并各方优势，产出一个统一的标准版本，保证测试全部通过。这个阶段用共识合并的原因是，你能得到群集模式的最优质量，不需要承担完整三倍冗余成本，因为所有智能体都基于同一份规范开发，差异更小，也不需要生成冗余文档。
第四阶段：顺序写文档，1名文档智能体读取最终合并后的代码，基于实际代码编写文档，不是基于规范也不是基于设计文档。这个阶段顺序开发写文档的原因是，文档必须和实际产物匹配，第一种框架的失败就是这种整合问题，在共识合并完成后再写文档，能保证对齐。
测试得到了五条核心结论：第一，没有协调的并行专业化会产出不匹配的产物，各智能体能产出合格的独立工作，但没有协调就会互不兼容，全自动团队中没有人检查衔接问题；第二，顺序交接能得到最好的整合效果，但会带来连锁风险，一个环节卡壳就会导致所有下游等待，复杂环节最容易超时；第三，冗余开发成本高，但能通过选择得到更好的质量，三倍算力成本换更高质量，对重要工具值得，对原型不值得；第四，规范是项目契约，真正落实规范的框架能产出更全面的代码，浪费规范的框架整合质量最差，产出规范后必须要求下游智能体读取使用；第五，智能体迭代配额是实际存在的约束，复杂任务需要更多迭代，如果配额在测试通过前耗尽，就只能带着失败测试交付，解决方法是给复杂环节增加配额，或者用并行模式获得多次尝试机会。
基于本次测试，对于开发真实软件的AI智能体团队，推荐“规范→群集→共识→文档”的混合框架：先由1名智能体顺序完成研究，产出技术规范；再由2到3名智能体并行开发，每个都读取规范，产出2到3份独立的代码+测试实现；再由1名智能体顺序完成共识合并，产出一份统一的、测试通过的合并实现；最后由1名智能体顺序完成文档，读取最终代码，产出和实际代码匹配的文档。
不同场景可以调整方案：小型、需求清晰的任务，可以跳过规范和群集，直接交给一名智能体，不值得付出额外成本；大型复杂、高不确定性任务，可以在实现前增加一名并行研究智能体，先合并得到规范再开发；对速度要求高的原型，可以使用第一种专业化分工框架，接受整合债，后续由人类对齐；对任务关键的生产代码，使用完整混合框架，2到3倍实现冗余是应对坏设计的保障。
本次测试在Hermes Agent上运行，使用GLM-5.2模型，所有智能体使用相同的并行委托系统，选择CSV转JSON命令行工具作为任务，平衡了真实复杂度和可控范围。所有测量都来自真实工具输出，完整的实验产物，包含所有代码、测试、文档、规范和合并报告都公开可查，没有挑选结果，所有问题都是真实存在的，混合框架推荐来自测试数据，不是预设结论。
AI智能体团队不是魔法，它们是存在协调成本、整合风险和 tradeoff 的软件系统。你选择的框架决定了你会遇到哪种失败：快但不对齐的专业化分工，慢但全面的顺序流水线，贵但最优的群集+共识。
不必思考“哪个框架最好”，要思考“哪个框架适合当前任务”。混合模式适合大多数生产工作，但它只是起点不是规则。本次测试最核心的结论是：如果想要智能体产出连贯的产品，必须有某一步负责整合。整合环节明确的框架，产出都是连贯的；没有明确整合环节的框架，产出看起来出色实际无法使用。协调不是额外开销，它本身就是产品。