多智能体何时有意义——何时没有。

对多智能体的默认立场应该是怀疑。你在演示和教程中看到的大多数"多智能体"架构，作为一个具备良好设计工具的单智能体循环（agent loop）来运行，效果会一样好，速度更快，成本也仅是十分之一。在动用多智能体之前，真正该问的问题是：我具体能得到什么，是一个拥有更好工具的单智能体做不到的？

在某些情况下，这个问题确实有真实答案。下面四个属性描述了多智能体分解真正物有所值的场景。如果你的问题没有强烈满足其中至少一项，你大概不需要多智能体。

属性 1：可并行的独立工作

最有力的理由。如果一个任务能分解为 N 个可以独立运行的子任务——每个子任务都不依赖另一个的输出——那么多智能体就允许你并发执行它们。挂钟时间（wall-clock time）从各子任务时长之和降至其最大值。对于一个包含 5 条独立调研线索的研究查询，这意味着从 25 分钟缩短到 5 分钟的差距。

测试方法：你能在任何工作开始之前就描述出各子任务吗？如果可以（编排器能在前期规划），多智能体并行是真实可用的。如果不行（下一个子任务依赖于上一个的发现），你描述的是一个顺序智能体，而非并行智能体——多智能体只给你带来额外开销，没有并行性。

这正是第 4.3 章研究智能体模式背后的属性。这也是为什么并行研究有效，而"智能体辩论以改进答案"通常无效——后者本质上是顺序的，每一"轮"都依赖前一轮。

属性 2：提示词（prompt）层面的角色专业化

某些任务涉及差异足够大的认知操作，以至于一个提示词无法同时针对两者进行优化。规划者需要与综合者不同的推理模式；代码审查者需要与代码编写者不同的评判标准；主持人需要与创意写作者不同的判断力。试图在一个系统提示词（system prompt）中编码所有这些，只会产生一个平庸的提示词，对每件事都做得不好。

解决方案：为不同角色设置独立的提示词，每个角色的提示词专门针对其特定的认知任务进行优化。即便这些提示词运行在同一模型上、处于同一工作流程中，这种形式也已是"多智能体"——"按顺序或协同调用的多个专用提示词"。

测试方法：你的子任务在认知需求上差异是否足够大，以至于一个提示词无法同时胜任？如果单个提示词能做到"寻找来源并综合"，就不是多智能体场景。如果"深入探索某一角度"和"跨角度调和发现"需要根本不同的指令，那才是真正的角色分工。

属性 3：上下文隔离（context isolation）

来自第 4.3 章研究智能体讨论：随着单个智能体的上下文（context window）因累积的工具结果而增长，性能会下降。"迷失在中间"效应开始显现，智能体遗忘早期发现，综合质量下降。

多智能体让每个子智能体维护一个专属于其狭窄任务的上下文窗口。主导/编排智能体只看到来自各子智能体的压缩摘要，而不是产生这些摘要的原始上下文。这是该架构最微妙的优势——也往往是在单靠并行性不足以证明成本合理时，真正能为其买单的那个理由。

测试方法：你的任务涉及的原始输入，是否多到足以让单个智能体遭受上下文退化？涉及大量来源的研究、跨大量文件的代码审查、跨大量页面的文档分析——这些都是上下文受限的场景。输入量小的纯推理任务则不是。

属性 4：故障隔离（fault containment）

一个陷入错误推理链的单智能体——错误假设、幻觉（hallucination）工具结果、无限循环——会污染自己的上下文，进而破坏整个任务。恢复要么需要重启整个任务，要么需要外科手术式地编辑上下文，两者都不理想。

多智能体将故障隔离在单个子智能体内。如果子智能体 #3 陷入无效循环，编排器可以检测到这一点（该子智能体的发现缺失或不连贯），以干净的上下文重新尝试，或替换为不同的方法。其他子智能体的工作不受影响。整个任务在局部失败中幸存下来。

测试方法：在你的任务中，局部失败是否可以恢复？如果即使一个子任务失败（带一个说明缺口）你也能交付答案，多智能体就能为你提供优雅降级。如果每个子任务都不可或缺，故障隔离的价值就没那么大。

四属性测试，总结

这是一个刻意保守的测试。这个领域默认的失败模式是过度工程化——为一个精心设计的单智能体循环完全可以处理的问题构建多智能体系统，然后在协调逻辑上耗费数月。这些成本会在后期显现：你为每次查询支付 15 倍的费用，却说不出具体获益了什么。

看起来像多智能体但其实不是的模式

有三种模式通常被描述为"多智能体"，但在任何有意义的工程层面上，它们都不是多智能体——将其视为多智能体只会增加复杂性，毫无收益。

调用多个 LLM 的智能体。如果你的智能体循环在某些步骤派发 Sonnet 调用、在其他步骤派发 Haiku 调用（第 2.2 章的模型级联），那不是多智能体。那是一个带模型路由的智能体。该智能体有单一的连贯状态、单一的对话历史、单一的循环，不存在协调问题。

拥有大量工具的智能体。一个同时具备网页搜索、数据库访问、代码执行、文件操作和电子邮件功能的智能体——即便有 20 个工具——仍然是单个智能体。工具不是智能体。每次工具调用都是结构化的，并返回到同一个智能体的循环中。智能体不会与自身协调。

LLM 调用的流水线（pipeline）。一个通过三次顺序 LLM 调用完成"摘要此文档、翻译摘要、发布到 Slack"的工作流是流水线，不是多智能体。其中没有共享任务、没有协调、没有分解。每次调用都是独立的单元，按顺序处理。

真正的多智能体系统具有各自拥有独立循环、通过结构化通信相互交互的智能体。多个模型调用不够；多个工具不够；顺序工作流不够。循环之间的通信才是构成多智能体的要素，也是协调成本所在之处。

三种在生产环境中有效的模式。

工程实践已经收敛到三种能可靠交付的多智能体模式。大多数生产多智能体系统都是其中之一，偶尔结合使用两种。这三种模式是编排器-工作者（orchestrator-worker）、流水线（pipeline）和专业化对等路由（specialized peer routing）。每种模式都有其特定的形态、特定的适用场景和特定的失败模式——研究文献中大多数花哨的模式要么是这些的变体，要么真正无法推广。

模式 1：编排器-工作者

第 4.3 章的模式，推广至研究场景之外。一个协调智能体（编排器）分解任务，生成 N 个并行工作者，每个工作者处理一个子任务，并将其结构化输出综合为最终结果。

结构简单，但它是最核心的模式。Anthropic 的 Research 功能使用它，OpenAI 的 Deep Research 使用它，大多数"AI 并行工作"产品在底层都是这个形态。让它在实践中奏效的关键：

• 编排器提前规划。所有工作者在一次规划步骤后统一派发。编排器在执行过程中不做生成决策。
• 工作者相互无状态。工作者 #2 不知道工作者 #1 的存在，更不了解其发现。这种隔离是关键所在——正是它赋予了系统上下文隔离和故障隔离能力。
• 结构化的工作者输出。每个工作者返回一个类型化对象（按照第 4.3 章的 COMPRESSED_FINDING 模式（schema）），而非自由形式的对话。编排器可以可靠地解析和综合。
• 根据任务规模定制。工作量扩展：简单比较用 2 个工作者，复杂问题用 10 个以上。编排器在规划阶段决定。

此模式在研究之外的适用场景：法律文件审查（每节由一个工作者审查）、代码审计（每个文件由一个工作者处理）、财务分析（每条论点线索由一个工作者处理）、客户反馈综合（每个聚类由一个工作者处理）。通用形态：一批工作自然分割为独立的部分，每部分可以单独分析，价值在于对各部分进行综合。

模式 2：流水线（顺序专业化）

另一种形态：每个智能体处理固定工作流的一个阶段，阶段 N 的输出是阶段 N+1 的输入。没有并行性；价值在于跨顺序阶段的角色专业化。

当工作的各阶段是真正不同的认知操作，且每个阶段都能从专注的提示词中受益时，流水线模式胜出。经典示例：一个内容审核流水线，依次完成（1）提取所陈述的主张 → （2）对主张类型进行分类 → （3）对照政策进行核实 → （4）格式化审核决定。试图在一个提示词中完成所有四步，会产生一个冗长复杂的提示词，在每个单独阶段都表现更差。

需要认清的关键点：流水线与多步单智能体循环不同。区别在于流水线的各阶段是独立的进程——它们不共享对话状态，不共同迭代，不来回循环。每个阶段本质上是一个结构化输入到结构化输出的转换。

Anthropic 的 Claude Code 在内部将这种模式用于部分工作流：一个"规划"阶段生成结构化计划，"执行"阶段消费该计划并据此运行，"验证"阶段检查结果。每个阶段有自己的模型和提示词；它们通过结构化中间输出松散耦合。

权衡：流水线失去了智能体循环的灵活性。如果阶段 B 意识到阶段 A 的提取有误，它无法回退——只能要么继续处理错误的提取结果，要么失败。流水线适用于各阶段已充分理解且稳定的情况；当工作需要迭代时，流水线并不适合。

模式 3：专业化对等路由

一小组拥有不同角色的智能体，加上一个决定由哪个智能体处理哪个请求的路由层。智能体本身之间不直接通信；路由器负责派发。

这是大多数企业部署最终收敛到的客服智能体模式。客户提出问题；路由模型对其分类（账单问题？技术支持？账户管理？）；由合适的专业智能体处理。每个专业智能体有自己的工具、系统提示词和领域知识。

优势在于：每个智能体都可以针对其领域进行深度调优——账单智能体可以访问账单系统 API，并有包含账单特定规则的系统提示词；技术支持智能体有产品的文档和操作手册。试图让一个智能体在所有这些方面都表现良好，只会产生一个在每方面都平庸的通才。

两种重要变体：

纯路由：路由器选择一个智能体，该智能体处理整个对话。简单，有清晰的上报路径。局限：如果对话中途偏向另一领域，你需要显式地重新路由。

带移交的路由：如果问题超出其领域，专业智能体可以将其移交给对等智能体。更灵活，但移交协议本身成为一个协调问题。实现方式：智能体发出一个特殊的"移交"工具结果，路由器据此解读并重定向。

选择正确的模式

决策往往取决于你的任务形态：

组合：模式叠加的时机

生产系统有时会叠加多种模式。最常见的组合：顶层使用专业化对等路由，每个专业化智能体自身则针对其领域内的复杂任务使用编排器-工作者。一个客服部署可能将"复杂账单争议"路由到账单智能体，该智能体随后生成工作者，并行调查争议的不同方面。

总体原则：当每一层的模式都与该层的问题相符时，叠加是合理的。不要为了显得复杂而叠加模式；当额外的结构真正契合实际工作时，才进行叠加。

反模式：为了适配你已采用的框架而叠加模式，而不管叠加是否有帮助。一个常见的失败：有人采用 CrewAI 或 LangGraph，构建了一个本可由单智能体完成的 7 智能体系统，最终交付了一个比简单版本贵 10 倍、更难评估的系统。

协调：最难的部分。

多智能体在生产环境中脆弱的声誉，并非因为那些模式本身不好——它们是扎实的。脆弱性在于协调：智能体之间如何传递工作、如何处理失败、如何调和部分成功。协调问题比智能体质量问题更常导致多智能体系统失败。本步骤涵盖那些能够经受考验的模式。

任务规格说明：最高杠杆的纪律

第 4.3 章在研究智能体的背景下命名了这一点；它可以推广。决定多智能体质量最重要的因素是编排器对每个子任务向工作者描述得有多好。模糊的任务规格产生粗糙的工作；精确的任务规格产生精准的工作。

一个好的任务规格包含五个要素：

包含所有五个要素的任务规格，其编排器获得的工作者输出质量，远优于那些仅发出"调查 X"的编排器。这正是第 4.3 章针对研究场景所覆盖的纪律；它适用于每一种编排器-工作者的设置。

在代码中的具体体现：

# Bad: vague task spec
await run_worker("Investigate Acme's recent product launches")

# Good: complete task spec
await run_worker(
    objective="Identify product launches by Acme Corp in the last 6 months "
              "with launch date, product name, and one-sentence positioning",
    scope_in=["products launched publicly",
              "feature releases announced as 'new product'"],
    scope_out=["feature updates to existing products",
               "acquisitions",
               "hiring announcements"],
    tools=["web_search", "web_fetch"],
    budget_tool_calls=10,
    output_schema=PRODUCT_LAUNCH_SCHEMA,   # typed object
)

好的版本在调用点需要编写更多代码，但这是编排器无论如何都要做的事情——与其临时写在提示词字符串里，不如体现在结构化的任务规格代码中。结构化规格也更易于记录、审计和复用。

失败处理：每个工作者都可能失败

朴素的多智能体实现假设工作者会成功。它们不会。工作者可能以几种不同的方式失败，一个健壮的系统会分别处理每一种。

硬失败：工作者报错退出。网络问题、API 速率限制、循环中的异常。编排器的 await 抛出异常。最容易处理：捕获、记录，决定是重试还是跳过。因瞬时错误而硬失败的工作者获得一次重试机会；持续性错误则记录并跳过（在最终输出中注明该子问题未得到回答）。

软失败：工作者返回了，但输出是错的。结构化输出通过了模式验证，但内容有误——发现为空、结果偏题、来源是幻觉。更难处理，因为编排器仅从返回值无法判断。检测模式：模式层面的检查（"至少需要 N 条声明"）、内容层面的检查（LLM 评判者检查工作者的输出是否真正回答了子问题）、来源有效性检查（来源必须解析为真实 URL）。

超时：工作者从未返回。陷入循环，或只是太慢。编排器的等待被阻塞。缓解措施：每个工作者调用设置挂钟超时（通常为预算运行时的 2–5 倍）。超时后，工作者被取消，视为软失败处理。

部分成功：工作者返回了降级但可用的输出。"我只调查了计划中 3 个来源里的 2 个。""我只找到了预期 5 条声明中的 1 条。"编排器在综合时将此纳入考量并注明局限性，而非将其视为完全成功或彻底失败。

# Failure-aware worker invocation

async def run_worker_safe(task_spec, timeout_s=300):
    try:
        result = await asyncio.wait_for(
            run_worker(**task_spec),
            timeout=timeout_s,
        )
        # Soft-failure check: did the worker actually do useful work?
        if not validate_worker_output(result, task_spec):
            return {"status": "soft_fail",
                    "reason": "output did not meet quality bar",
                    "partial": result}
        return {"status": "success", "result": result}
    except asyncio.TimeoutError:
        return {"status": "timeout", "task_spec": task_spec}
    except Exception as e:
        return {"status": "error", "error": str(e),
                "task_spec": task_spec}

# Orchestrator gathers all worker results, including failures
worker_results = await asyncio.gather(*[
    run_worker_safe(spec) for spec in task_specs
])

successes  = [w["result"] for w in worker_results if w["status"] == "success"]
soft_fails = [w for w in worker_results if w["status"] == "soft_fail"]
hard_fails = [w for w in worker_results if w["status"] in {"timeout", "error"}]

综合步骤随后对每种类别进行恰当处理——纳入成功结果、将软失败作为部分信息提及、将硬失败标记为空缺。最终输出如实反映哪些成功了、哪些没有。

"结构化输出用于移交"原则

最常见的多智能体失败模式：在智能体之间传递自由形式的对话文本。智能体 A 写道："我发现客户的最后一次付款是 2024-03-15，金额为 1,200 美元。"智能体 B 必须从自然语言中解析这些信息。有时解析成功，有时不成功；这种不一致性是不可见的，直到真正出问题。

解决方案：每次智能体间的移交都通过类型化的模式传递，而非自由形式的文本。智能体 A 不写一个关于付款的句子——它发出一个结构化对象：{"last_payment_date": "2024-03-15", "last_payment_amount_usd": 1200.00}。智能体 B 直接接收这个对象，无需解析。

这等同于第 4.3 章中引用纪律的论据：结构性约束能防止一类仅靠文档说明无法阻止的错误。模式能强制执行提示词指令只能请求的事情。智能体仍然可以生成解释性文本——但承载实质信息的通信是结构化的。

协调的令牌成本，诚实地呈现

第 4.3 章给出的数字（单次对话成本的 15 倍）是基线。三个运营现实会在管理不善时使其更糟：

每个工作者的上下文包含冗余材料。每个工作者都需要了解原始任务、相关子问题、工具文档、输出模式。这些基线上下文在 N 个工作者中重复。缓解措施：对每个工作者的样板内容使用提示词缓存（第 2.2 章），可以大幅削减这部分开销。

编排器的综合上下文包含所有人的摘要。如果 10 个工作者各返回一个 500 个令牌的发现，编排器的综合调用在其自身上下文之上还有 5,000 个令牌的输入。缓解措施：结构化发现（而非对话文本）比散文摘要更紧凑。

失败/重试的工作者会双倍付费。如果一个工作者超时并被重试，你为两次尝试都付了费。缓解措施：识别软失败模式，在重试不太可能有帮助时放弃（不重试）；将每种工作者类型的重试率作为指标进行追踪。

一个工程良好的多智能体系统的运行成本是单智能体的 10–15 倍。工程粗糙的则是 30–50 倍。差异恰恰在于这三种协调经济性。听起来乏味；省钱之道就在这里。

在论文中看起来不错但在生产中失败的模式

为了诚实，以下是文献热衷于，而生产团队基本已放弃的多智能体模式：

自由形式的智能体辩论。多个智能体通过对话相互批评对方的输出。听起来强大；实践中产生约 5% 的质量提升，成本却是 3–5 倍。同一模型之间的辩论尤其薄弱。跨模型辩论（Claude + GPT）有时对可验证的任务有效，但大多数团队不将其发布上线。

层级式智能体树。管理者生成子管理者，子管理者生成工作者。成本随深度呈指数级增长；协调变得难以控制。生产系统最多只有一层委派。

开放式智能体社群。一个拥有角色（CEO、工程师、市场营销人员）的智能体"团队"，在任务上"协作"。演示效果好，上线效果差。协作结构过于松散；智能体相互说不到一起，重复工作，无法收敛。

自我修改的智能体系统。根据性能自动更新自身提示词的智能体。有过演示；循环并不收敛。智能体对自身提示词的判断力不足以驱动自主的提示词改进。

这些都不是不可能的——随着更好的模型或新颖技术的出现，它们将来可能有效。目前在 2026 年，它们无法可靠地交付。如果你现在正在构建多智能体系统，请坚持使用第 2 步中的三种模式。

评估多智能体系统。

单智能体系统有一组指标——任务级成功率、成本、延迟。多智能体系统拥有所有这些加上一层多智能体结构特有的指标：编排器分解得有多好？工作者完成各自任务的效果如何？综合如何将它们组合起来？评估该系统需要审视每一层。

两层评估（eval）结构

对于任何编排器-工作者系统，存在两个截然不同的评估问题：

第一层：端到端质量。最终输出是否满足用户需求？这是第 3.1 章的评估框架，不加改变地应用在此。从用户的角度来看，唯一重要的是输出——他们不关心涉及了多少个智能体。

第二层：每个智能体的质量。每个智能体执行其任务的效果如何？这是多智能体特有的问题。三个子问题：编排器是否合理地分解了任务？每个工作者是否完成了分配的子任务？综合是否忠实地保留并组合了工作者的发现？

两层都需要的原因：如果你的端到端质量很差，你需要每个智能体的诊断数据来知道失败起源于哪里。较差的输出可能源于编排器的规划失败、工作者的调查失败，或者综合过程中丢失了工作者的发现。没有第二层指标，你无法区分这些情况——也就不知道该修哪个提示词。

编排器质量：分解是否有意义？

首先需要评分的事项。给定一个用户查询，编排器的计划是否将其拆分为合理的子问题？三项具体检查：

覆盖度（Coverage）。各子问题合在一起，是否涵盖了用户查询的全部内容？LLM 评判者可以对此评分：给定用户查询和编排器的计划，查询中是否有明显方面未被任何子问题覆盖？

无重叠（Non-overlap）。各子问题之间是否有重复？（第 4.3 章命名的失败模式——两个子智能体并行调查同一件事。）评判者：这些子问题描述的是不同的调查吗？

规模适当性（Right-sizing）。子智能体的数量是否与问题复杂度相匹配？Anthropic 的规范化规则（事实核查 1 个 / 比较 2–4 个 / 复杂研究 10 个以上）使其可以量化：对带有预期复杂度层级标签的查询数据集，运行编排器，检查实际子智能体数量是否与预期匹配。

这三项指标让你能够在不评估下游工作者输出的情况下衡量编排器质量，这至关重要——你需要能够独立于修复工作者来修复编排器。

工作者质量：每个工作者是否完成了其任务？

对于每次工作者调用，两个问题：

模式有效性。工作者是否发出了符合预期模式的结构化输出？这是二元的——输出要么验证通过，要么不通过。将有效率作为每个工作者类型的指标进行追踪。下降表明该工作者类型的提示词存在问题。

任务完成度（Task-completion）。给定任务规格和工作者的输出，工作者是否真正回答了其子问题？LLM 评判者对此评分：阅读任务规格，阅读输出，该输出是否是对规格目标的实质性回答？

任务完成度检查能捕捉到"工作者返回了一个充满空内容的、模式有效的对象"的情况。一个在达到工具预算时没有找到答案的工作者，可能会发出一个空的发现数组——模式有效，任务未完成。

综合质量：编排器是否忠实地进行了组合？

最后一步，也是最可能悄无声息退化的一步。第 4.3 章的引用忠实度检查在此直接适用：综合输出中的每个实质性声明，都应能追溯到某个工作者的发现。工作者的发现本身已经有了来源归属；综合只需保留这种归属。

需要测试的两种具体失败模式：

综合中的无中生有（Confabulation in synthesis）。综合者添加了不在任何工作者发现中的声明，从训练数据中提取，没有来源。检测方法：对于输出中的每个声明，追溯到一个工作者的发现；如果找不到匹配，则标记。

丢失发现（Dropped findings）。综合者遗漏了来自工作者的相关发现（也许是因为综合者的上下文正忙于其他发现）。检测方法：统计发现出现在综合中的工作者数量，与发现缺席的工作者数量。如果一个工作者的实质性发现在没有正当理由的情况下从综合中缺席，则标记。

综合评估仪表盘

对于生产中的多智能体系统，按优先级顺序值得追踪的指标：

这比单智能体系统需要的检测工作量更大，这是在生产中运行多智能体的代价。这些指标不是可选的——没有它们，当端到端质量下降时，你无法定位回归（regression）。有了它们，"编排器的 plan_coverage 在周二部署后下降了 8 个百分点"就能精确地告诉你该看哪里。

一个客户支持分诊系统，追溯其获得的各种模式。

为了将本章内容具体落地：一个真实形态的系统，从简单开始，最终演变为多智能体——但只有在团队有明确证据证明更简单的版本不奏效之后才这样做。这是"我们成为多智能体是因为不得不如此"的诚实版本，而非"我们从第一天起就是多智能体"。

背景设置

一家 SaaS 公司的客户支持不堪重负。工单以每天 800 张的速度涌入；团队大约能回答 600 张。那 200 张未得到回答的工单带来了客户流失风险。他们希望用 AI 智能体处理简单的工单，让人工得以专注于复杂的工单。

产品需求：处理答案明确无误的工单，对任何模糊情况上报给人工，绝不让情况更糟（账单问题不能给出错误答案，技术指导不能有误）。

第 1 周：单智能体尝试

团队的第一个版本：一个基于 Sonnet 的智能体，具备网页访问、知识库搜索、账户查询工具，以及"回复"和"上报给人工"两个动作。系统提示词："你是一个客服智能体。如果能自信地回答，就处理这张工单；如果不能，就上报。"

在影子流量（shadow traffic）上运行一周后的结果（智能体的回复被生成但不发送；人工事后评估）：

• 自信处理的工单：68%（目标：70%，接近）
• 错误答案率：14%（目标：<2%，严重不达标）
• 上报率：32%（目标：30%，可以接受）

错误答案率是致命问题。智能体用技术支持的逻辑自信地回答账单问题，给出了错误的退款指导，并错误地分类了账户类型。团队的调查结论：单智能体的系统提示词试图同时处理"账单规则" + "技术故障排查" + "账户管理" + "上报判断"，在每一项上都表现平庸。

第 2 周：模式 3——专业化对等路由

团队采用模式 3（专业化对等路由）架构。三个专业化智能体（账单、技术支持、账户管理），各自有独立的系统提示词和工具，加上一个对传入工单分类并派发给合适专家的路由智能体。

每个专家只拥有与其领域相关的工具——账单智能体可以访问账单 API，但不能访问技术知识库；技术智能体有知识库访问权限，但没有账单系统权限。这本身就是一个重大改进：错误的工具使用变得不可能。

一周后的结果：

• 自信处理的工单：71%
• 错误答案率：3.2%（大幅改善，但仍未达到 <2% 的目标）
• 上报率：28%

错误答案率大幅下降，但仍不可接受。调查：大多数剩余的错误答案出现在路由步骤——路由器将一张工单分类为"账单"，而实际上它是关于某个付费功能的技术问题，账单智能体随后自信地给出了错误的技术指导。

第 3 周：为复杂案例添加编排器-工作者

团队增加了一层：复杂工单（多主题、类别模糊或 VIP 客户）不再直接路由到专家，而是路由到"编排器"路径。编排器采用模式 1——将子问题并行派发给相关专家，并综合他们的答案。

这更贵（每张工单 10 倍成本），但只对约 15% 需要此路径的工单触发。其余 85% 的工单仍走廉价的路由路径。

一周后的结果：

• 自信处理的工单：73%
• 错误答案率：1.4%（低于目标！）
• 上报率：26%
• 成本：平均每张工单 0.04 美元（简单工单 0.02 美元，复杂工单 0.40 美元）

错误答案率现在可以接受。架构形态：对常见情况使用模式 3（路由），对边缘情况使用模式 1（编排器-工作者）。这种组合从抽象层面看并不优雅——它是对团队实际遇到的失败模式的诚实回应。

第 4 周暴露的失败模式

第 3 周末已达到生产质量。第 4 周带来了一个不同的问题：复杂案例路径的端到端延迟为 12 秒（5 个子智能体并行运行，加上编排器开销）。客户注意到了这段延迟并选择放弃。那 12% 走复杂路径的客户，在智能体的回复到达之前就已在回复"你还在吗？"。

团队的解决方案：在子智能体完成时向客户流式传输部分回复，并附带状态提示（"正在检查您的账户……正在查找您的发票……正在准备您的回复……"）。端到端延迟不变，感知延迟降至约 3 秒（第 2.4 章的流式传输模式）。复杂路径上的客户放弃率降至基线水平。

这是一个第 2.4 章的问题，而非多智能体问题——但它在多智能体场景中出现得更频繁，因为其中的操作运行时间更长。

此追踪的教训

三个可推广到这个特定系统之外的教训：

不要从多智能体开始。团队本能地可以是"这是一个多领域问题，让我们从第一天起就构建多智能体"。他们没有——他们先尝试了单智能体，发现了具体的失败模式，然后才采用多智能体模式来解决特定的失败。最终架构之所以成立，是因为团队能够说出多智能体解决了哪些具体问题。

基于真实需求组合模式。最终的形态（路由 + 针对边缘情况的编排器-工作者）不是教科书式的模式。这是两种模式的叠加，因为团队面临两个截然不同的问题（大多数工单是简单且领域专属的；一些工单是复杂且跨领域的）。两者都需要解决；架构是解决方案的并集。

运维问题随多智能体成倍放大。延迟、可观测性、成本——一切都变得更难。系统中每增加一个智能体，就是又一个活动部件。要为运维现实做好规划，而不仅仅是为智能体质量的故事做规划。