两次调用胜过五个Agent：评估多Agent流水线与自精炼在本地语言模型上的表现

研究者将包含五个角色的多Agent系统Parishad部署在Qwen2.5-7B-Instruct本地模型上，对比直接提示、两轮自精炼在GSM8K和HumanEval上的表现。多Agent在JSON格式下GSM8K精度从75%降至45%，plaintext下恢复至82%。两轮自精炼在GSM8K达86.2%，token消耗低7.4倍；在HumanEval上，直接精度96.3%，自精炼反而降至66.5%，但任务感知门控设计保留95.1%。结论：通信格式和实现细节比架构复杂度更重要，简单方法可匹配或超越多Agent流水线。

此前多Agent系统主要在大型商业模型上测试，被认为能提升推理能力。本研究表明在本地7B模型上，多Agent架构因通信格式问题反而降低性能，而更简单的两轮自精炼在数学推理任务上效果更好且资源消耗更低，这挑战了多Agent架构的通用优越性，为本地模型部署提供了更高效的选择。

多Agent系统通过角色分工和消息传递提升推理，但在本地小模型上，角色间通信的格式错误会累积并放大，导致性能下降。自精炼通过两次同一模型的迭代输出，避免了跨角色通信误差，但任务类型影响效果：数学推理受益于第二轮反思，而代码生成中二次输出可能引入错误。任务感知门控通过检测任务类型决定是否启用自精炼，从而保留原有精度。

开发者部署本地小模型时不应盲目采用复杂多Agent架构，而应优先评估简单的自精炼策略，后者可显著降低token消耗（7.4倍）并提升数学推理准确性；但需注意自精炼在代码生成等任务上可能破坏性能，需要任务感知门控设计。通信格式（如JSON vs plaintext）对多Agent系统影响巨大，需谨慎选择。

• 针对本地7B模型，构建任务感知的自精炼门控模块，自动判断是否执行第二轮调用以保留性能。
• 优化多Agent系统的通信格式，优先采用plaintext而非JSON，减少格式错误累积。
• 开发低token消耗的推理服务，将两轮自精炼作为默认方案，并内置任务类型检测开关。
• 在数学推理场景下，用两轮自精炼替代复杂Agent流水线，降低部署成本和延迟。

• 多Agent系统在参数量更大的本地模型（如14B、70B）上是否仍弱于自精炼？
• 任务感知门控的具体实现机制（如启发式规则还是模型分类）如何设计才能通用？
• 自精炼失败的下界原因是什么？在HumanEval上为何第二次调用破坏了高精度输出？
• 其他多Agent架构（如不同角色数量或交互方式）是否也有类似的格式敏感问题？