多 Agent 不是默认选项——「Avoid multi-agent early」的生产共识与实践

开篇：一周之后，我的三个助理对同一件事给出了三个说法

上个月我把系统拆成了三个 Agent：一个管内容、一个管邮件、一个管审计。拆完当晚我很兴奋——各司其职，多体协作，这很「2026」。

一周之后我冷静了。三个 Agent 对同一个事实给出了三个说法：内容 Agent 说「这篇已发布」，邮件 Agent 说「还没发」，审计 Agent 说「草稿箱里没有」。谁都没撒谎，它们只是各自守着各自的上下文。同一个事实，N 个上下文，就有 N 个版本。

这不是我一个人的问题。beam.ai 的调研里，40% 的多 Agent 试点在 6 个月内失败；Shopify 的工程师 Micheal Lanham 在《What Actually Survived》里直接写了「Avoid multi-agent early」；Atlan 复盘多 Agent 失败案例，把 context inconsistency 列为第一主因。顶级团队的反共识是：多 Agent 不是默认选项。

那单 Agent 和群体的边界到底在哪？这篇用我跑过的三个方案回答：先别拆、包抄、最后才上 Supervisor。

一、先看清负债：多 Agent 买的不是能力，是四个坑

先把我这一年多跑出来的四个负债摆出来，每一个都有真实记录：

负债一：context inconsistency——失败的第一主因。 Atlan 复盘了大量多 Agent 落地案例，结论不是「模型不够强」，而是上下文不一致：每个 Agent 各带一份上下文，任务跑完，彼此对「现状」的理解已经分叉。我开头那个场景就是活例子。

负债二：token 成本成倍放大。 Augment Code 做过 build-vs-buy 测算，多 Agent 方案 token 消耗约是单 Agent 的 5 倍。同一个事实要在每个上下文里各写一遍，成本不涨才怪。

负债三：没有 tracing 就是瞎调试。 Agent 之间互相调用，出错时你不知道错误在哪一跳。MLflow、FutureAGI 这些做可观测性的团队都在强调：多 Agent 系统没有 tracing，问题根本定位不了。

负债四：失败率高得吓人。 beam.ai 的数据：40% 的多 Agent 试点在 6 个月内失败。失败原因集中在上面三条。

所以我对「多 Agent 很先进」这个默认假设，做了个相反的判断：多 Agent 是负债，不是资产。 它只有在能换回确定性收益时才值得上。下面是我实际跑通的三招，顺序就是优先级。

二、第一招：先别拆——场景路由让一个 Agent 专精

第一个方案不是拆 Agent，而是把一个 Agent 拆成 6 个「场景专家」。

思路来自微服务：你不需要一个单体服务处理所有请求，而是用 API 网关路由到对应后端。场景路由就是 Agent 的「API 网关」：所有请求先进 task_dispatcher.classify()，判定场景后，只给当前场景注入专属的工具白名单、SOP 和输出 Schema。

SCENE_CONFIG = {
    "email": {
        "tools": ["imap_fetch", "smtp_send", "contact_lookup"],  # 工具白名单
        "sop": "sops/email_sop.md",          # 场景SOP注入路径
        "schema": "schemas/email_schema.json",
    },
    "quoting": {
        "tools": ["rate_query", "quote_template", "history_lookup"],
        "sop": "sops/quoting_sop.md",
        "schema": "schemas/quote_schema.json",
    },
    # 其余场景：report / contact / finance / knowledge
}

实际运行时，所有请求先进分类器，再按场景白名单执行：

# 第一步：分类（正则覆盖90%，语义兜底10%）
scene=$(python3 task_dispatcher.py classify "查一下上海到纽约的运费")
# 第二步：按场景注入 SOP 与工具白名单
bash inject-sop.sh "$scene"

关键在注释里那句话：不在白名单里的工具根本不会被加载。 邮件场景碰不到数据库写入，财务场景发不了邮件。这 6 个专家共用一个上下文，却各自只看得到自己的工具和 SOP——它还是「一个 Agent」，只是被约束成了「六个房间」。

✅ 验证：引入场景隔离后，工具误选率从 15% 降到 2% 以下（运行日志统计）；上下文长度减少 60%，工具调用准确率提升 40%。

踩坑：最初我给了 LLM 全部 20+ 工具自由发挥，误选率 15%，每 5 次就错 1 次。不是模型笨，是「20 个工具里挑 1 个」这件事本身就超出了概率模型的舒适区。

价值：零新增 Agent，零状态同步成本，只改路由层，就把「全能幻觉」换成了「专精可靠」。

▸ 认知跃迁：专业化不是靠多 Agent 实现的，是靠约束实现的。 六个房间还是同一栋楼。

三、第二招：确定性代码包抄——复合任务交给流程容器

单场景任务被场景路由治好了，复合任务又来打脸。一份报告里有邮件判断、有状态查询、有应收应付、有催单建议——我最初把它当「报告场景」处理，给足工具让它自由发挥，结果输出时好时坏，有时漏邮件，有时重复催。

转折点是接受了那句反馈：让大模型自由发挥的定时任务，就是不稳定。 于是我把报告改造成五阶段管道：

① 汇总 → ② 拆解 → ③ 分发 → ④ 执行 → ⑤ 报告

def generate_report(period):
    # ① 汇总：全量读取（脚本，不分类不判断）
    raw_data = fetch_inbox(period) + fetch_events(period)
    # ② 拆解：按票/主题拆成独立工作单元
    work_units = split_into_units(raw_data)
    # ③ 分发：路由到各场景处理器
    dispatched = {}
    for unit in work_units:
        scene = classify_unit(unit)          # 复用场景分类器
        dispatched.setdefault(scene, []).append(unit)
    # ④ 执行：各场景纯脚本处理（no_agent）
    results = {s: process_scene(s, units) for s, units in dispatched.items()}
    # ⑤ 报告：LLM 只做最终组装
    return llm_assemble(results)

这就是「三明治模式」：确定性代码包抄概率 LLM。 扫邮件、拆单元、做统计这些脏活，脚本干又快又准；LLM 只在最后一步做结构化数据到自然语言的组装。全流程仍然只有一个 Agent 上下文，但 LLM 的参与被压缩到了最小。

✅ 验证：改造后报告稳定性从约 60% 提升到约 95%，数据来源可追溯，输出格式统一。

踩坑：五阶段比单场景多约 30% 延迟。值不值？对于「每天定时出、错了要担责」的生产任务，稳定性比速度值钱得多。

价值：LLM 的角色从「报告撰写者」变成「SOP 执行者」，概率被关进笼子里。

▸ 认知跃迁：减少 LLM 调用次数，本身就是最便宜的多 Agent 替代方案。 你不需要第二个 Agent，你需要让第一个 Agent 少干活。

四、第三招：真要协作时——Supervisor，一个经理加 N 个工人

前两招覆盖了 90% 的场景。剩下 10% 的任务，真的需要多个角色并行——这时候才轮到多 Agent。但即使上多 Agent，也不是「平级协作」。

平级协作有三个坑，我都踩过：谁先谁后（三个 Agent 同时开工互相等）、谁来裁决（两个 Agent 对同一数据给出不同解读）、谁来兜底（工人失败后没人管，任务卡死）。

解法是 Supervisor 架构：一个「经理 Agent」只做拆解、调度、协调、兜底，不干活；N 个「工人 Agent」只做自己的专业活，不决策。

class SupervisorAgent:
    def handle(self, user_request: str):
        plan = self.plan(user_request)      # LLM 拆解：需要哪些 Worker、什么顺序
        results = {}
        for step in plan:                    # 按序调度，上一步结果喂给下一步
            step["params"].update(results)
            result = self.workers[step["worker"]].handle(step["action"], step["params"])
            results[step["action"]] = result
            if not result["ok"]:             # 失败兜底：重试或降级
                return self.fallback(step, result)
        return results

我自己的多助理系统（内容、邮件、审计三个 Agent）最终也收敛成这个形态：调度是唯一的决策点，工人之间不直接对话。 工人之间唯一的通信渠道是 Supervisor 转交的结构化结果，而不是共享上下文——这正好绕开了 context inconsistency。

✅ 验证：Supervisor 上线后，跨 Agent 任务的失败从「没人管」变成「有兜底」，任务卡死率归零。

踩坑：Supervisor 的 prompt 是系统里最贵的一段文字，它一乱，下面全乱。先把它写成固定 SOP 再放开。

价值：多 Agent 的风险被收敛到「一个调度点」，其余部分仍然可预测、可审计。

▸ 认知跃迁：多 Agent 的正确打开方式，是把它当成最后一道工序，而不是第一反应。

五、决策边界：什么时候才该上多 Agent

把三招按成本从低到高排，就是我的决策阶梯：

第 1 级：单 Agent + 场景路由。 任务能按场景分类，就用它。成本最低，收益最快。
第 2 级：流程容器（三明治）。 任务是复合的，但可以编排。加确定性代码，不加班底。
第 3 级：Supervisor + Workers。 任务必须并行、且各角色需要独立上下文时才上。每上一级，上下文数量 +1，状态同步成本和调试难度翻倍。

判断是否上第 3 级，我只问一个问题：「两个上下文各自干活、再合并结果」，会不会比「一个上下文按顺序干完」明显更好？ 答不上来，就停在当前级。

进阶思考：反共识的共识，是工程纪律

为什么 Shopify 敢公开说 Avoid multi-agent early？因为复杂度应该跟随 workload，不跟随潮流。 多 Agent 不是「更先进」，是「更贵、更难调试、更容易上下文分叉」的选项。它的价值只有在「并行独立上下文」这个条件真实成立时才兑现。

这也解释了为什么 context inconsistency 是失败第一主因：多 Agent 的本质是把一个问题分给多个上下文，而上下文之间的一致性需要持续同步——同步是熵增，不维护就分叉。 单 Agent + 约束（工具白名单、场景 SOP、确定性包抄）本质是用约束消灭同步需求：只有一个上下文，就没有同步这回事。

所以「Avoid multi-agent early」不是保守，是工程纪律：先让一个 Agent 把确定性吃满，再用编排补足复合场景，最后才用多 Agent 解决真正的并行需求。 每一步都在回答同一个问题：这笔状态同步的账，值不值得付？

结尾

今天你学到的是三招先单后多：场景路由让一个 Agent 专精（误选率 15%→2%）、三明治模式用确定性代码包抄（报告稳定 60%→95%）、Supervisor 把多 Agent 收敛到单一调度点。 加上一句决策口诀：复杂度跟随 workload，不跟随潮流。

行动号召，今晚就能做：

# ① 列出你 Agent 的所有工具，按场景分组，只留当前场景白名单
# ② 找出最不稳定的复合任务，把它的执行步骤拆成五阶段管道
# ③ 只有出现"必须并行"的需求，才画 Supervisor 架构图

做完这三步，你会发现大多数「多 Agent 需求」在第 ① 步就消失了。

下一篇，我们把镜头拉远：当底座（模型、框架、协议）越来越趋同，Agent 竞争的真正战场到底在哪——《底座趋同，生产系统才是答案——2026 年 Agent 竞争的真正战场》。

关于作者：魏无记，AI 和数智化实践者。专注 Agent 工程化与 Loop Engineering 研究以及数智化转型。公众号持续更新 Agent 工程化实战系列和数智化转型相关知识实践——每篇都是保姆级教程照做就行。

魏无记