大多数多智能体系统失败的原因都很无聊。有人启动了三四个智能体，给每个制定了模糊的职责描述，让它们自由地互相交谈，然后奇怪为什么输出结果还不如一个精心设计的单智能体独立完成得好。
更多智能体并不是人们想象的那种升级。一个缺乏协调的智能体群，只不过是一个困惑的过程穿上了几件戏服而已。真正的升级来自于结构：清晰的职责、清晰的交接、真正的验证步骤，以及如何停止的方法。
本课程涵盖了在实际使用中（而非演示条件下）能站得住脚的多智能体系统背后的实际架构。学完后，你将理解为什么大多数团队会失败，使一个团队有效运作的具体角色是什么，如何设计它们之间的交接，以及在将系统托付给任何重要任务之前需要测试的故障模式。
为什么增加智能体通常会让事情更糟
从一个令人不安的事实开始：第二个智能体并不会为系统增加智能。它增加了另一个故障点，另一个上下文可能丢失的地方，以及另一个系统自信地产生错误输出的机会。
朴素的多智能体设计将智能体视为头脑风暴。把几个智能体扔向一个问题，让它们都看到全部信息，让它们都做出贡献，并相信更多视角会产生更好的答案。这种方法失败的原因很具体：没有角色分离，每个智能体最终都会以稍差的方式执行相同的通用任务，而且实际上没有人检查其他人的工作。你只是并行化了猜测过程，而没有提高准确性。
那些真正有效的系统则完全颠覆了这种做法。与其让许多智能体做同样的工作，不如构建少量智能体，每个负责一项不同的工作，并建立一个能在错误累积前捕获它们的结构。多智能体设计不是为了向一个问题增加更多头脑，而是关于分离关注点，就像一支运转良好的团队那样：有人负责构建，有人负责检查，有人负责决定工作何时真正完成。
每个有效系统所需的三个角色
每个能在生产环境中站住脚的多智能体系统，其核心都可以归结为三个角色的某种变体。不同的团队给它们起了不同的名字，但职能是恒定的。
构建者（Builder）。 这个智能体做实际工作。编写代码、起草内容、研究主题、执行任务。它拥有关于具体问题最多的上下文，并且对创造力的限制最少，因为它的工作是产生第一次尝试，而不是完美的结果。
评审者（Judge）。 这个智能体不构建任何东西。它唯一的工作是根据一个特定的、书面的标准来评估构建者的产出。代码是否通过了测试？草稿是否符合简报？研究是否真正回答了提出的问题？理想情况下，评审者应该在不同的提示词下运行，有时甚至使用完全不同的模型，因为让一个智能体用自己编写作业时的同样盲点来给自己的作业评分，其发现问题的能力远不如一个独立的审查者。
管理者（Manager）。 这个智能体不构建也不评审。它负责路由。它根据评审者的报告来决定下一步做什么：将任务连同具体的反馈发送回给构建者，上报给人类，或将任务标记为完成。管理者也是停止条件所在的地方，因为如果没有一个明确负责决定何时停止的角色，系统会快乐地永远循环下去。
这种构建者、评审者、管理者的结构是故意设计得最小化的。你可以添加更专业的角色，比如只收集事实的研究者（Researcher），或者只处理输出结构的格式化者（Formatter），但每一个新增的角色都应该对照这个基线来证明其合理性。如果一个新智能体不能明确地归类为构建、评审或管理，它很可能是在重复一个已经存在的角色，这只会增加成本和故障面，而不会增加能力。
设计交接环节
多智能体系统中真正的工程工作不是每个智能体的提示词，而是它们之间的交接。而这是大多数构建者会跳过的部分。
一个可靠的交接需要满足三个条件：第一，智能体之间传递的内容要有明确的格式，这样接收智能体就不需要解析自由文本并猜测其结构；第二，交接发生的时机要有明确的触发条件，这样构建者就不能自行决定何时完成；第三，要有明确的失败路径（failure path），这样当交接不顺利时，系统有指定的下一步行动，而不是默默地崩溃。
在实践中，这意味着你的构建者智能体应该输出结构化的内容，而不仅仅是散文。一个包含状态字段、内容字段以及完成标志的 JSON 对象效果很好。然后评审者消费这个结构，根据你事先编写的检查清单进行评估，并输出自己的结构化裁决，包括通过、失败或需要修改，以及具体原因。管理者读取裁决（而不是原始内容），并根据你事先定义好的规则（而不是临时即兴发挥）来决定下一步行动。
这听起来比仅仅让智能体用自然语言互相交谈需要更多的前期工作，事实也确实如此。正是这种前期成本，换来的是一个能在第一百次运行时与第一次运行表现完全一致的系统。智能体之间的自然语言交接会发生漂移，而结构化的交接不会。
停止条件不是可选项
多智能体系统变成昂贵灾难的最常见原因就是缺乏明确的停止条件。如果没有它，构建者和评审者可以无限循环下去：每次修订触发一次评估，每次评估又触发下一次修订，而你的 API 账单不断攀升，直到收到发票时才有人注意到。
一个真正的停止条件包含三个组成部分：最大迭代次数，即构建者和评审者可以循环的硬性上限，超过后无论任务是否实际完成，管理者都必须将问题上报给人类；质量阈值，一个具体的、可衡量的、足以满足要求的指标，这样系统就不会追逐一个从未被要求的完美；以及时间或成本上限，一个任务无论如何都不能超过的绝对预算。
将这三个条件明确地写入管理者的逻辑中，要么是代码，要么是一条明确的规则，而不是提示词里一条模糊的指令。像"当结果足够好时就停止"这样的指令，放在提示词里根本不算停止条件，它只是一个建议，模型在特定条件下可以（并且最终会）忽略。而一个硬性的迭代计数器，由管理者在允许下一次循环前进行检查，这才是一个停止条件。
智能体之间的记忆
一个在任务之间会忘记一切的智能体团队实际上不是一个团队，它只是在做同样的事情，每次都是从零开始，只是多了些步骤。
那些能持续产生复合效应的系统，会赋予管理者访问持久化记忆层的能力，这个记忆层能跨越多个任务而存在，而不仅仅是在一个任务内部。当评审者标记出一个反复出现的失败模式时，这个模式会被写入某个永久性的地方（文件、数据库、知识库），这样当下一个类似任务到来时，构建者已经掌握了那个教训，而不是重蹈覆辙。
这里一个有效的结构模仿了"写入→整理→回忆"的模式。每次任务完成后，记录下发生了什么以及评审者发现了什么。定期将这些原始日志整理成少量精炼的教训，而不是让原始日志无限增长。在开始新任务前，让构建者先回忆相关的教训。这正是那种在第九十天和第一天能力相同的系统，与那种每周都在悄悄变得更敏锐、因为它没有重复学习同样错误的系统之间的区别。
你必须测试的四种故障模式
在将任何重要任务托付给多智能体系统之前，请故意让它经历这四个特定的故障条件。大多数在生产环境中失败的系统，如果有人费心去运行测试的话，会在其中一项测试中立即失败。
无限循环测试。 故意给系统一个它按照标准根本无法完成的任务。管理者是会正确地达到迭代上限并上报，还是会永远循环下去，在一个它永远完不成的任务上白白消耗令牌？
恶意或格式错误的输入测试。 故意给构建者一些被破坏的或对抗性的输入。结构化的交接格式是否能经受住考验？还是错误的输入会破坏智能体间的解析，并悄悄地破坏其下游的一切？
评审者串通测试。 如果你的评审者和构建者共享同一个底层模型，请直接检查评审者是否真的在捕捉构建者特定的盲点，还是仅仅在表面上看起来完整的东西上盖章放行。手动将一个已知有问题的输出输入给评审者，并确认它被正确地拒绝了。
成本失控测试。 模拟通过系统的最坏情况路径：最大迭代次数、最昂贵的模型调用、可能的最长内容，然后计算出这在实际成本和时间内会是多少。如果这个数字在一张真实的账单上会让你感到震惊，那么你的停止条件还不够严格。
在部署前运行这四个测试，能捕捉到绝大多数原先会在客户、老板或你自己的银行账单面前才首次出现的故障。
一个实例：内容生产团队
为了具体说明，以下是构建者、评审者、管理者结构在内容生产流水线中的样子。你可以用这类系统将原始素材转化为一份经过事实核查的成品内容，而无需监督每个步骤。
构建者智能体接收原始素材（一篇文章、一份转录稿、一篇新闻稿），并以要求的格式起草内容。它拥有网络搜索权限，以便验证声明，但它唯一的工作是生成一个完整的初稿，而不是决定该草稿是否足够好到可以发布。
评审者智能体会同时接收草稿和原始来源，绝不会只看草稿。它专门检查三件事：草稿中的每一个事实陈述是否都能追溯到来源中实际存在的内容；草稿是否遵循了所需的风格规则（没有 AI 陈词滥调、格式正确、长度合适）；核心论点或钩子是否实际存在，且没有被填充内容稀释。评审者会输出一个结构化的裁决，分别给出三项检查各自的通过或失败，而不是一个总分，因为一个总分掩盖了具体是哪个部分失败了。
管理者读取这个结构化的裁决。三项全部通过，则内容进入最终输出队列。事实项失败，则将草稿连同被标记的未经验证的具体声明一起发回给构建者，而不是一个模糊的"再核实一下事实"的指令。风格项失败，则将草稿连同被违反的具体规则一起发回。如果同一项检查连续三次循环失败，管理者将停止循环，并将完整的失败历史和原因上报给人类，而不是继续重试一个系统已经证明自己无法独立解决的问题。
这是一个小型系统：三个角色，一种清晰的交接格式，一个明确的停止条件。这也是一个你实际上可以无人值守运行过夜，并在第二天早上信任其输出的系统，因为每一种故障模式都有明确的路径，而不是未定义的路径。
第二个实例：代码审查团队
同样的结构应用于代码而非内容时看起来不同，但逻辑完全相同。值得走一遍这个过程，因为具体的检查项变了，而架构不变。
这里的构建者智能体是任何编写或修改代码的东西，一个通过定义好的任务（功能请求、Bug修复）来工作的编码智能体。它的输出不仅仅是代码本身，还包括运行代码的实际命令输出、测试结果、Lint输出、构建状态，所有这些都打包到结构化的交接中。一个生成代码但从不去运行它的构建者，是你无法信任的，因为语法正确但通不过自身测试套件的代码比没有代码更糟糕——它看起来完成了，实际上并没有。
这里的评审者检查三个结构上相同但具体内容不同的正确性类别：更改是否在未经修改的情况下通过了现有的测试套件（因为构建者悄悄修改测试以使其通过是一个特定的常见故障，值得直接检查）；静态分析和 Lint 是否干净；diff 是否真正解决了原始任务，而不是构建者在过程中觉得更有趣的相关但不同的问题。每一项都在结构化裁决中有自己的通过或失败，与内容示例完全一样的形状，只是具体的标准不同。
管理者根据哪个具体检查项失败来路由。失败的测试套件将连同确切的失败测试输出一起返回给构建者，而不是一个通用的"修复测试"指令。作用域不匹配（diff 解决了错误的问题）则立即上报给人类，而不是循环，因为这是关于任务实际是什么的判断失误，而不是构建者可以自己迭代解决的机械性缺陷。
请注意，底层的骨架——构建者生成并提交，评审者根据具体命名的标准进行检查并给出结构化分项裁决，管理者根据哪个具体检查项失败来路由——在两个例子中是相同的。这是将两个领域并排比较后真正值得吸取的教训。一旦你有了正确的骨架，将其应用到新任务上，主要是为评审者编写一个新的、具体的检查清单，而不是从头重新设计架构。
破坏优秀设计的常见错误
现实世界中大多数多智能体系统的失败都不是架构失败（上述构建者、评审者、管理者的骨架是经过许多真实系统验证的）。它们是一些悄悄破坏正确设计的实现细节，而且同样的少数几个错误会反复出现在完全不同的领域。
让评审者只看到构建者的输出，而看不到原始来源或需求。一个没有真实依据可比较的评审者只能检查内部一致性，而不是正确性，这意味着它会愉快地批准自信、格式良好但完全错误的输出。
给每个智能体使用相同的模型和相同的基础提示词，只在上面叠加一层薄薄的角色指令。这往往意味着评审者继承了构建者完全相同的盲点，因为它们本质上是戴了不同帽子的同一个推理过程。在预算允许的情况下，为评审者使用一个真正不同的模型或一个意义不同的提示方法，能产生真正的独立性，而不是戏剧表演般的独立性。
将管理者视为一个简单的 if-else 路由器，而没有赋予其真正的决策逻辑和对已尝试过内容的记忆。一个看不到当前任务上上次尝试历史的管理者，会愉快地将相同的失败反馈第二次、第三次发送给构建者，每次都产生完全相同的失败结果。
因为系统在一次大家密切关注的演示中运行良好，就跳过了四种故障模式的测试。一个在观察下工作的系统和一个能无人值守工作的系统是不同的主张，而只有后者才是构建多智能体团队的根本目标。
何时增加第四个角色
三角色结构覆盖了绝大多数实际用例，但有些任务确实需要第四个角色。值得知道什么时候增加是合理的，什么时候这只是为了复杂而复杂。
当构建者的工作需要在产出任何东西之前从多个来源收集信息，并且这个收集步骤本身有其独特的、与编写或构建步骤分离的故障模式时，研究者（Researcher）角色就值得存在。将研究从构建中分离出来意味着构建者只处理经过验证的、已经收集好的材料，这防止它因在同一轮中既要查找事实又要处理压力而悄悄编造事实。这种分离的代价是增加一次交接，因此它特别适合于事实准确性是最可能出问题的维度的情况，这适用于内容生产、技术文档以及任何提出具体性声明的内容。
当输出结构非常严格且重要，以至于专注内容的构建者在关注实质内容时总是搞错格式时，格式化者（Formatter）角色就值得存在。不必要求构建者在思想和格式上都同样出色，一个专门的格式化者会接收一个结构宽松但内容正确的草稿，然后将其重塑为所需的精确格式，无论是特定的 JSON Schema、特定的文档模板，还是特定于平台的长度和结构规则。
增加任何新角色的测试标准每次都是一样的：你能指出一个特定的、反复出现的故障，这个故障是新的角色能够捕获的，而现有的三个角色由于不在它们各自负责检查的范围内而结构性地无法捕获吗？如果你无法指出那个特定的差距，那么新角色就不是在解决一个真正的问题，而是在增加第四个故障点，只是为了追逐一种"面面俱到"的感觉。
为每个角色选择模型
系统中的每个角色不一定需要相同的模型。将模型选择视为对整个流水线统一适用的单一决策，通常意味着为简单的角色多付钱，而为困难的角色投入不足。
构建者角色通常从你的最强大模型中获益最大，因为这是任务的实际创造性或技术难度所在。一个较弱的模型在这里会产生更差的初稿，需要更多的修订周期来修复，这比第一次就生成好所花费的成本更高。
评审者角色的计算更有趣。它不需要创造性，它需要的是一致性和规则遵循。这意味着一个更小、更快、更便宜的模型，对照一个极其明确的检查清单进行检查，通常能像你的最大模型一样可靠地执行，而成本和延迟却只是零头。例外情况是那些评审本身就很困难的任务（微妙的写作质量、微妙的事实争议），这时你可能希望把最强大的模型放在这个位置上，因为评估任务和生成任务一样困难。
管理者角色几乎从不需要你花钱最多的模型，因为它的工作是针对你已经写好的规则进行路由逻辑，而不是开放式的推理。一个快速、廉价的模型来处理管理职责，可以在每一个循环中保持每个任务的低开销，因为无论构建者和评审者表现如何，管理者至少每次迭代都会运行一次。
这种分层方法——昂贵的模型用于构建，便宜且一致的模型用于评审日常检查，便宜的模型用于路由——通常是多智能体系统中真正节省成本的地方。大多数人认为成本控制意味着使用更少的智能体。但实际上，它来自于将模型成本与每个具体角色的实际难度相匹配。
后续方向
从小处着手。在尝试推广之前，先为一个狭窄、定义明确的任务构建构建者、评审者、管理者的结构。在编写构建者提示词的第一行之前，就明确地写下评审者的检查清单，因为你将依据的标准应该塑造工作，而不是反过来。
在将系统托付给任何真实任务之前，运行四种故障模式的测试，而不是等在线上出事后才做。在基本循环可靠之后再添加记忆层，而不是在此之前。因为一个复合错误的速度快于复合教训的系统，比一个完全没有记忆的系统更糟糕。
那些能够从多智能体系统中获得真实、复合价值的团队，并不是那些同时运行最多智能体的团队。他们是那些花时间明确了每个智能体具体负责什么、工作如何在它们之间流转、以及当事情出错时具体会发生什么的团队。这种纪律性，而不是智能体数量，正是区分一个在你睡觉时也能工作的系统，与一个悄悄积累账单却无法产出任何可用成果的系统之间的全部区别。
