这两天，提效党的信息流里同时被推了两类内容。
一类在"劝你招人"：B站9月上旬密集上线的教程里，"零基础用Coze搭建多Agent协作AI团队"拿了266赞82收藏。"ClaudeCode保姆级入门到精通全套教程"直接把"多Claude协作"写进标题。小红书帖子的口径更直接——“最近 OpenAI 的 Agents API 开始支持主 Agent 调度多个子 Agent 并行工作”。哔哩哔哩哔哩哔哩小红书
另一类在"踩刹车"：知乎问题"使用Multi-Agent是不是真的利大于弊？"下的新回答这几天浏览量冲到两万出头，开头就是一盆冷水——“最近用codex蹬各种项目，发现有时候一个简单的任务，单agent比多agent执行得还要快，质量也更高”。知乎
厂商在加主从调度，课程在教你带团队，实操派说越拆越亏。我把这轮争议里被引用最多的三份材料——谷歌的260组受控实验、OpenAI的官方报告、几条生产环境的踩坑复盘——放到一起对完账。结论先放这儿，一句话决定你要不要学这轮"拆分潮"：拆分的收益由任务结构决定，不由演示视频的热度决定。拆错了，一份效果三份成本。
一、实验室的硬数据：260组受控实验，拆开三种结果
争议里被反复转引的那篇论文叫《Towards a Science of Scaling Agent Systems》，作者来自Google Research、Google DeepMind和MIT，arXiv编号2512.08296，2026年4月更新到v3，这个月因为知乎解读帖重新翻红。它的实验设计值得细看：六类任务、三个模型家族、260组受控配置，工具、提示词、总推理Token全部锁死，唯一改变的就是"几个Agent、谁和谁通信"。知乎arXiv论文库
论文把连接方式归纳成四种架构，各自解决不同的问题：
Independent（独立并行）：各干各的，最后交给一个汇总器合并。注意它的汇总器被设定为只合并、不交叉验证——答案来源变多了，质检没有变多。
Centralized（中心化）：加一个Orchestrator，子Agent的结果必须先过中心节点的检查再进入最终答案。相当于设了个统一的验收关。
Decentralized（去中心化）：Agent两两互通、逐轮辩论，像一张网。
Hybrid（混合）：中心编排加部分横向连接。
260组实验跑完，结果分三档：
第一档，拆对了暴赚。可拆分的金融分析任务（Finance Agent）上，多Agent全面碾压单Agent基线：中心化架构提升80.8%，去中心化74.5%，混合73.1%。 论文给的真实轨迹很典型：Agent 1查监管新闻、Agent 2检索SEC文件、Agent 3评估运营影响，最后由Orchestrator综合——每个环节能独立验收，交换的是可验证的信息。知乎
第二档，拆错了血亏。强顺序依赖的规划任务（PlanCraft）上，四种多Agent架构全部输给单Agent，另一篇知乎解读引用的论文数字是相对降幅39%到70%。 逻辑不复杂：下一步完全依赖上一步的状态，拆开只是把一条串行链切成了更多交接点。知乎
第三档，看架构下菜。网页检索类任务（BrowseComp-Plus）只有去中心化赢了，且幅度只有9.2%——不同搜索路径互相对照有用，但也就这点用。知乎
还有三个容易被忽略、但对提效党最实用的数字：
错误放大：Independent架构17.2，Centralized架构4.4。 这是执行轨迹里错误经过交互后被放大的程度——并行且没人检查，错误是成倍带进最终结果的。知乎
Agent数量没有"越多越强"：1、3、5、7、9个的配置都测了，Flash级模型部分架构7个附近见顶，Pro级模型更早见顶。 数量是架构定了之后才轮到的参数。
预测选哪个架构最准的不是模型强弱：论文用任务属性和协调指标拟合的缩放模型，留出配置上87%的准确率选对架构；只看模型能力，准确率54%；随机选，20%。
一句话总结这260组实验：多Agent不是一个升级开关，是一组条件解。任务里有没有能独立验收的部分，决定这件事划不划算。
二、实操派为什么喊亏：拆开的六笔隐性成本
论文数字是受控环境的天花板，而把多Agent放进真实项目的人，晒出来的是下面这本账。知乎两万浏览的高赞回答列了六条，B站和小红书的实操帖逐条能对上：
重复读上下文：同一份20页需求文档，3个Agent各自读一遍，正式开工前Token已经×3。“你招小工一天两百，5个就是1000，而且还可能需要一个人负责安排他们”。知乎
拆分本身是串行的：本来5分钟能干完的活，先花2分钟讨论怎么分、谁负责什么、输入输出是什么。
等最慢的那个：主Agent要等所有子Agent返回，整体速度往往由最慢的一条支线决定——生产复盘帖直接说了：并行任务的p95通常受最慢的关键子任务主导。知乎
交接丢信息：上游没注明"空行要保留"，下游按自己理解处理，最后回头返工。
同模型评审是回音室：让同一个模型、同一份上下文当Reviewer，它可能稳定重复原错误。"把同一个问题问三遍再投票"不是质检，是复读。
人成了新瓶颈：小红书有篇帖子标题概括得狠——“AI并行，人类串行”。N个Agent同时交付，验收队列只有你一双眼睛。小红书
高赞回答给的净收益公式值得抄进备忘录：多Agent净收益 = 并行节省的时间 + 专业化收益 + 隔离收益 − 协调成本 − Token成本 − 集成和返工成本。 后面附的8个动手前自问（有没有至少两个真正独立的子任务？每块够不够重、覆盖启动成本？验收标准定死了没有？单块失败能不能单独重试？能不能测墙钟时间和Token？……）只要多数回答是"否"，先老实用单Agent。知乎
三、厂商为什么还在推：因为有一个场景真划算
争议不是"多Agent有没有用"，是"对谁有用"。目前证据最扎实的受益者是写代码的重度玩家：大型代码任务天然可并行——查不同模块、分析不同bug成因、试不同修复方案，互不依赖；而且代码世界自带免费的验收闸门，编译、测试、复现能直接筛掉不靠谱的方案。所以Codex的ultra模式、Claude Code的ultracode模式（专门设计了6种工作流模式）都在复杂任务上倾向于调动多个subagent。知乎
OpenAI用同一个底座模型对比过单Agent和Ultra配置，三个任务使用多Agent后指标都涨了。 知乎上的解释更抽象一点：多Agent并行本质是一种test-time scaling，把算力摊到不同探索路线同时推进，还顺带躲开了单上下文越跑越污染、被迫压缩的老毛病。知乎
把这套逻辑翻译给不写代码的提效党，判断标准就一条：你的活儿有没有"既能分头干、又有客观验收"的部分。
竞品调研/行业报告：监管动态、财务数据、舆情各拆一个Agent，再加一个只管核验引用来源的汇总位——这就是Finance那组+80%的结构复刻。每份子报告的验收标准你写得出来（只引用指定信源），值得试。
多平台内容分发：不同平台是天然独立的子任务，格式规则就是验收闸门，可以并行；但涉及共用的价格和库存状态，必须串行，否则就是生产复盘帖说的"为了展示多 Agent 而并行查询同一数据库，往往只会制造连接池尖峰"。知乎
周报、单篇翻译、文案润色：强顺序、无并行结构，拆了纯属交税。
企业里的审批流、客服流：生产复盘给了更冷静的定位——多Agent的正经用途是"接起已有的责任边界"，各系统本来就有独立owner、SLA和审计。 如果责任本来就没划清，加Agent只会让账更难算，正确的下一步是加人，不是加Agent。
四、分人群行动建议
已经在跑coding agent的重度玩家：你已经在船上了，只需要补一个动作——起多路时带中心验收（Centralized结构），别用"纯并行+最后汇总"，17.2对4.4的错误放大是现成数据。Orchestrator可以就是你自己定的一条汇总规则。
观望中的中度提效党：先别买课。给你最常见的任务跑一遍单Agent基线，记下墙钟时间、Token消耗、返工率；没有基线，拆不拆你永远在凭感觉吵。有基线之后，按上面8问过一遍，过得了再拆，从2-3个起步，别一上来摆7个。
只聊天写文档的轻度用户：你收藏夹里的"一人公司"大部分是仪式感。你的瓶颈是需求描述不清楚，不是Agent数量不够。
小企业主：把预算先花在"给每类任务写验收标准"上，这件事Agent帮不了你，但没它多Agent全是白拆。
五、接下来盯什么
三个继续观察的信号：
9月20日深圳的超级智能体大会，分论坛直接拆成四条并行主线。"多Agent"从话题变成会务本身，值得看会后放出的落地案例是哪些行业。小红书
各家产品会不会把子Agent从"高级设置"推向"默认开启"。Agents API的主从调度刚开放，免费额度跟不跟、涨价节奏怎么定，会直接决定这波是普及还是劝退。
你自己的两本账：并行开多个Agent之后，Token账单翻倍的同时，如果验收时间没降下来、返工反而多了——那你就是论文里PlanCraft那组-39%到-70%的样本，回去用单Agent不丢人。
谷歌这260组实验说到底只回答了一件事：架构选择的单位是任务，不是信仰。该拆的任务，一个Orchestrator能把收益翻到80%以上；不该拆的，四个架构排队教你做人。
你拆过什么不该拆的活？欢迎在评论区晒晒你的墙钟时间和Token账单，大家互相对个账。
