如何构建一个真正协同工作的AI智能体团队（完整课程）

大多数多智能体系统的失败原因都出奇地一致且乏味。有人启动了三个或四个智能体，给每个智能体一个模糊的职责描述，让它们自由地相互交流，然后奇怪为什么输出结果还不如一个精心设计提示词的单一智能体独自完成得好。

更多的智能体并不是人们想象的那种升级。一群未经协调的智能体，不过是穿着多件戏服的同一个混乱流程。真正的升级来源于结构。明确的角色。清晰的交接。一个真实的验证步骤。一个停止机制。

本课程涵盖的是那些能够在真实使用条件下（而非演示条件下）站得住脚的多智能体系统背后的实际架构。到最后，你会明白为什么大多数团队会失败，一个高效团队所需的具体角色是什么，如何在它们之间搭建交接流程，以及在你能放心地将任何重要事务交给这个系统之前，你需要测试的失败模式。

为什么添加智能体通常会让事情更糟

从一个令人不安的事实开始。第二个智能体并不会给系统增加智能。它增加的是另一个故障点，另一个上下文可能丢失的地方，以及另一个系统自信地产生错误结果的机会。

天真的多智能体设计版本将智能体视为一种头脑风暴。向一个问题抛出几个智能体，让它们都能看到所有信息，让它们都能贡献意见，然后相信更多的视角会产生更好的答案。这种做法的失败原因很具体。如果没有角色分离，每个智能体最终都会在做一个稍微拙劣版本的同一种通用任务，而实际上并没有人在检查任何人的工作。你只是并行化了猜测过程，并没有提高准确性。

真正有效的系统完全颠覆了这一点。与其让许多智能体做相同的工作，不如构建少量智能体，每个智能体执行不同的工作，并有一个结构来防止错误在累加前被发现。多智能体设计不是要给一个问题增加更多的思考者。它是要像高效的团队分离关切点那样分离关注点，有负责构建的人，有负责检查的人，还有负责决定工作何时真正完成的人。

每个有效运行的系统所需的三个角色

每个在生产环境中站得住脚的多智能体系统，其核心都可以归纳为三个角色的一些变体。不同团队可能有不同的命名，但功能是恒定的。

构建者。 这个智能体负责做实际工作。写代码，起草内容，研究主题，执行任务。它对特定问题拥有最多的上下文，对创造性的限制也最少，因为它的工作是产生第一次尝试，而不是一个完美的成品。

评审者。 这个智能体不构建任何东西。它唯一的工作是根据一个具体的、书面的标准来评估构建者产生的内容。代码是否通过了测试。草稿是否符合简报要求。研究是否真正回答了所提出的问题。评审者最好使用不同的提示词运行，有时甚至使用完全不同的模型，因为一个智能体用自己写作业时的同样盲点来给自己的作业打分，所能发现的问题远不如一个独立的评审者。

管理者。 这个智能体既不构建也不评审。它负责路由。它根据评审者的报告来决定接下来做什么。将任务连同具体反馈发回给构建者。升级给人类处理。标记任务为完成。管理者也是你的停止条件所在之处，因为如果没有一个明确的角色负责决定何时停止，系统就会愉快地永远循环下去。

这种构建者、评审者、管理者的结构有意做到了最小化。你可以增加更多专门的角色，比如只负责收集事实的研究员，只负责处理输出结构的格式化员，但每一次添加都应该相对于这个基线证明自身的合理性。如果一个新智能体不是明确地在构建、评审或管理，那么它很可能是在重复一个已经存在的角色，这只会增加成本和故障面，而不会增加能力。

设计交接环节

多智能体系统中实际的工程工作并非每个智能体的提示词，而是它们之间的交接。而这正是大多数构建者跳过的地方。

一个可靠的交接需要三个要素。交接内容有定义的格式，这样接收智能体无需解析自由文本并猜测结构。交接触发有定义的触发器，这样构建者就不会自己决定何时完成。以及定义的失败路径，这样当交接不顺畅时，系统有一个指定的下一步，而不是静默地崩溃。

在实践中，这意味着你的构建者智能体应该输出结构化的内容，而不仅仅是散文。一个包含状态字段、内容字段和置信度或完成标记的JSON对象效果很好。然后评审者消费这个结构，根据你预先编写的检查清单进行评估，并输出自己的结构化裁决结果（通过、失败或需要修改），同时附上具体原因。管理者读取裁决结果，而非原始内容，并根据你事先定义的规则（而非临时即兴发挥）来决定下一步行动。

这听起来比仅仅让智能体用自然语言相互交谈要做更多的预先工作，事实也确实如此。正是这种预先成本能让你得到一个在第一百次运行时和第一次运行时行为一致的系统。智能体之间的自然语言交接会漂移。结构化交接则不会。

停止条件并非可选

多智能体系统变成昂贵灾难的最常见原因就是缺乏明确的停止条件。没有停止条件，构建者和评审者可以无限循环下去，每次修改触发另一次评估，每次评估触发另一次修改，而你的API账单不断攀升，直到收到发票才有人注意到。

一个真正的停止条件包含三个组成部分。最大迭代次数，即构建者和评审者可以循环次数的硬性上限，当达到上限时，无论任务是否实际完成，管理者都必须强制升级给人类处理。质量阈值，一个特定的、可衡量的、被视为“足够好”的标准，这样系统就不会追求从未被要求提供的完美。时间或成本上限，一个任务无论处于何种状态都不能超出的绝对预算。

将所有这三者明确地写入管理者的逻辑中，作为代码或一条毫不含糊的规则，而不是作为提示词中的模糊指令。提示词中像“当结果足够好时停止”这样的指令并非停止条件。它只是一个模型在适当条件下可以而且最终会忽略的建议。管理者在允许另一次循环之前检查的硬性迭代计数器才是一个停止条件。

跨智能体的记忆

一个在每次任务之间忘记一切的智能体团队实际上并不是一个团队，而是带着额外步骤，每次从头开始的相同对话。

能够随时间累积效果的系统，会给予管理者访问一个跨任务（而非仅单个任务内）存活的持久记忆层的权限。当评审者标记出一个重复出现的失败模式时，这个模式会被写入某个永久位置——一个文件、一个数据库、一个保险库——这样当下一个类似任务到来时，构建者从一开始就能获得这个教训可用，而不是重复犯同样的错误。

这里效果良好的结构遵循写入、整合、回忆的模式。每次任务之后，写下发生了什么以及评审者发现了什么。定期将这些原始日志整合成少量的精华教训，而不是让原始日志无限增长。在开始新任务之前，让构建者首先回忆相关教训。这正是以下两者之间的区别：一个在第九十天和第一天能力一样的系统，与一个每周都悄然变得更敏锐、因为它没有再重蹈覆辙的系统。

你必须测试的四种失败模式

在将多智能体系统用于任何重要事务之前，请有意识地让它经历这四个特定的失败条件。大多数在生产中失败的系统，如果当初有人费心运行一下这些测试，本应立即暴露问题。

无限循环测试。 故意给系统一个它实际上无法达到评审者标准的任务。管理者是正确命中迭代上限并升级处理，还是永远旋转下去，在一个它永远无法完成的任务上消耗token。

恶意或畸形输入测试。 故意给构建者一些有缺陷或有对抗性的输入。结构化的交接格式是否经得住考验，还是错误输入会破坏智能体之间的解析并静默地破坏其下游的一切。

评审者共谋测试。 如果你的评审者和构建者使用相同的底层模型，直接检查评审者是否实际上在捕捉构建者的特定盲点，还是仅仅在表面检查看起来完整的内容上盖章通过。手动将一个已知的错误输出通过评审者运行，并确认它被正确地拒绝了。

成本失控测试。 模拟通过系统的最坏情况路径——最大迭代次数、最昂贵的模型调用、最长的可能内容——并计算这在金钱和时间上实际花费多少。如果这个数字在一张真实发票上会让你感到震惊，那么你的停止条件还不够严格。

在部署前运行这四个测试可以捕获绝大多数原本会在客户、老板或你自己的银行账单面前首次出现的故障。

实例：内容生产团队

为了使这一点具体化，以下是构建者、评审者、管理者结构在内容生产管线中的应用方式——即用于将原始资料转化为经过事实核查的成品内容的系统类型，无需监督每一步。

构建者智能体接收一个来源（一篇文章、一份转录稿、一份新闻稿），并按要求的格式起草内容。如果声明需要验证，它有网络搜索权限，但它唯一的工作是制作一份完整的第一稿，而不是决定该草稿是否足够好到可以发布。

评审者智能体同时收到草稿和原始来源进行比对（绝不是只看草稿）。它具体检查三件事：草稿中的每一个事实性声明是否都能追溯到来源中确实存在的内容；草稿是否遵循要求的风格规则（没有AI陈词滥调、正确的格式、正确的长度）；核心论点或钩子是否确实存在且未被填充物稀释。评审者输出一个结构化的裁决结果，对三项检查分别给出通过或失败，而不仅仅是一个总体分数，因为单一的总体分数会隐藏具体哪一部分失败了。

管理者读取这个结构化的裁决结果。如果所有三项都干净通过，则内容进入最终输出队列。如果是事实失败，则带着被标记的特定未验证声明（而非模糊的“仔细检查你的事实”指令）发回给构建者。如果是风格失败，则带着被违反的具体规则发回。如果在同一项检查上连续失败三次，管理者将停止循环，并将完整的失败历史记录和原因升级给人类处理，而不是继续重试一个系统已经证明无法自行解决的问题。

这是一个小型系统：三个角色，一个清晰的交接格式，一个明确的停止条件。这也是一个你可以真正在无人值守的情况下运行一夜，并在早上相信其输出的系统，因为每一个失败模式都有定义的路径，而不是未定义的路径。

第二个例子：代码审查团队

相同的结构应用于代码而非内容时看起来不同，但遵循相同的逻辑，这值得走一遍，因为即使架构不变，具体的检查项也会改变。

这里的构建者智能体是任何编写或修改代码的东西——一个处理定义任务（功能请求、错误修复）的编码智能体。它的输出不仅仅是代码本身，还包括运行代码的实际命令输出——测试结果、lint输出、构建状态——所有这些都打包进结构化的交接内容中。一个产生代码但从不运行它的构建者不是一个你可以信任的构建者，因为语法正确但未能通过自身测试套件的代码比没有代码更糟，因为它看起来完成了但实际没有。

这里的评审者检查三个不同但结构上相同的正确性类别：更改是否无需修改就通过了现有的测试套件（因为构建者悄悄修改测试以使其通过是一个具体且常见的失败点，值得直接检查）；静态分析和linting是否返回干净结果；diff是否真正解决了原始任务，而不是构建者过程中决定更感兴趣的相关但不同的问题。每一项在结构化裁决结果中都有自己独立的通过或失败，与内容示例的形状完全相同，只是具体的标准不同。

管理者根据具体哪项检查失败进行路由。测试套件失败则带着确切的失败测试输出发回给构建者，而不是泛泛的“修复测试”指令。范围不匹配（即diff解决了错误的问题）则立即升级给人类处理，而不是循环，因为这是关于任务实际是什么的判断失败，而不是构建者可以自行迭代解决的机械性缺陷。

请注意，底层骨架——构建者产生并提交，评审者依据具体命名标准进行检查并给出按项的结构化裁决，管理者根据具体哪项失败进行路由——在两个示例中是相同的。这是从并排观察两个领域中学到的实际教训。一旦你掌握了正确的骨架，将其应用于新任务主要是为评审者编写一份新的、具体的检查清单，而不是从头重新设计架构。

破坏原本良好设计的常见错误

现实世界中的大多数多智能体故障并非架构故障——上面的构建者、评审者、管理者骨架是经过许多真实系统验证的可靠框架。它们通常是悄悄侵蚀一个原本正确设计的实现细节，而且同样的一小撮错误会跨完全不同的领域反复出现。

让评审者只看到构建者的输出，而看不到原始来源或需求。没有真实依据可比较的评审者只能检查内部一致性，而不是正确性，这意味着它会愉快地批准看起来自信、格式完美但完全错误的内容。

给每个智能体相同的模型和相同的基础提示词，只是在上面叠加一层薄薄的角色指令。这通常意味着评审者继承了构建者完全相同的盲点，因为它们本质上是戴着不同帽子的同一个推理过程。在预算允许的情况下，为评审者使用一个真正不同的模型或意义不同的提示方法，可以产生真正的独立性，而不是表演性的独立性。

将管理者视为一个简单的if-else路由器，而不是赋予它真正的决策逻辑和对已尝试过内容的记忆。一个无法看到本次任务先前尝试历史的管理者，会愉快地将相同的失败反馈第二次、第三次发送给构建者，每次产生完全相同的失败结果。

跳过四种失败模式的测试，因为系统在大家密切关注的单次演示运行中工作良好。在观察下工作的系统和无人值守时工作的系统是两种不同的主张，而只有后者才是构建多智能体团队的真正目标。

何时添加第四个角色

三个角色的结构涵盖了绝大多数实际用例，但有些任务确实需要第四个角色，并且知道何时添加是有价值