别被多智能体架构给骗了，实测证明复杂度并不等于效果

最近我陷入了一个典型的“Agent 执念”：总觉得只要在工作流里加入一个 Planner 做规划，再配个 Judge 做评审，最终的输出质量一定会呈线性增长。逻辑看似无懈可击——思考步骤越多，审核环节越严，答案自然越准。为了验证这个直觉，我搭建了一套量化测试工具，针对 20 个具体的代码任务跑了三组对比实验，结果却非常具有冲击力。

我分别测试了三种方案：第一种是单模型直接生成结果；第二种是“Planner → 执行者”的简单链路；第三种则是最复杂的“Planner → 双执行者 → 评审员”架构。

数据跑完后，我被直接“打脸”了。单模型方案的成功率高达 95%，单次成本仅为 0.031 美元，耗时 2.2 秒。而那个最复杂的“评审团”方案，成功率反而掉到了 80%，单次成本飙升至 0.692 美元，耗时 18.3 秒。最离谱的是，在 20 个任务的样本量中，复杂方案没有一个任务赢过单模型，反而输掉了 3 个。这意味着成本翻了 22 倍，速度慢了 8 倍，结果却在下降。

这里隐藏着一个非常深刻的坑，很多开发者在看评测报告时容易被百分比误导。表面上看，“评审团”方案比单模型低了 15%，但实际分析发现，这 20 个任务中有 17 个是平手，只有 3 个出现了差异。在小样本量下，增加架构复杂度根本没有带来统计学上的显著提升，反而因为链路过长，增加了误差传递的概率。

为了确保这次测试的客观性，我在工具设计上做了三个关键点。首先是配置驱动，通过 JSON 定义角色、模型和拓扑图，直接运行矩阵测试，避免人工干预。其次是绝对禁止“AI 给 AI 打分”，因为模型评审具有极强的随机性和倾向性，我要求工具必须直接运行生成的代码，由程序判定对错。最后，我采用了符号检验（Sign Test）进行配对比较，对比同一任务在不同方案下的胜负，而不是对比一个模糊的平均分。

在具体的开发实现过程中，我还踩到了一个关于浏览器端 API 调用的坑。如果你尝试在前端直接调用 OpenAI API 做这种快速测试，会遇到棘手的 CORS 预检问题。虽然 api.openai.com 会响应 preflight 请求，但在实际响应中经常缺失 access-control-allow-origin 头部，导致浏览器直接拦截请求。这意味着如果你想做一套可视化测试面板，必须通过后端代理转发，而不能寄希望于纯前端调用。

这次实操给我最大的启发是：不要盲目追求复杂的 Agent 架构。在没有建立起大规模量化评测体系之前，所谓的“多步思考”和“自我反思”机制，在很多场景下可能只是在浪费 Token。如果单模型已经能解决 95% 的问题，那么为了追求那 5% 的提升而将成本提高 20 倍，在工程实践中是极其低效的。