Multi-agent

coordination

patterns:

Five

approaches

and

when

to

use

them

In an earlier post, we explored when multi-agent systems provide value and when a single agent is the better choice. This post is for teams that have made that call and now need to decide which coordination pattern fits their problem.在之前的一篇文章中，我们探讨了多智能体系统何时能提供价值，以及何时单一智能体是更好的选择。本文面向那些已做出决定、现在需要选择适合其问题的协调模式的团队。

We've seen teams choose patterns based on what sounds sophisticated rather than what fits the problem at hand. We recommend starting with the simplest pattern that could work, watching where it struggles, and evolving from there. This post examines the mechanics and limitations of five patterns:我们见过团队根据听起来是否高级而非是否适合问题来选择模式。我们建议从最简单的可行模式开始，观察其不足之处，然后逐步演进。本文深入探讨五种模式的机制与局限性：

• Generator-verifier, for quality-critical output with explicit evaluation criteria生成器-验证器模式，适用于质量要求高且有明确评估标准的输出
• Orchestrator-subagent, for clear task decomposition with bounded subtasks编排器-子智能体模式，适用于任务分解清晰且子任务边界明确的情况
• Agent teams, for parallel, independent, long-running subtasks智能体团队模式，适用于并行、独立、长时间运行的子任务
• Message bus, for event-driven pipelines with a growing agent ecosystem消息总线模式，适用于事件驱动型流水线及不断增长的智能体生态系统
• Shared-state, for collaborative work where agents build on each other's findings共享状态模式，适用于智能体基于彼此发现进行协作的工作

Pattern 1: Generator-verifier模式1：生成器-验证器

This is the simplest multi-agent pattern and among the most deployed. We introduced it as the verification subagent pattern in our previous post, and here we use the broader generator-verifier framing because the generator need not be an orchestrator. 这是最简单的多智能体模式，也是部署最广泛的模式之一。我们在上一篇文章中将其作为验证子智能体模式引入，此处采用更广泛的生成器-验证器框架，因为生成器不一定是编排器。

How it works工作原理

‍

A generator receives a task and produces an initial output, which it passes to a verifier for evaluation. The verifier checks whether the output meets the required criteria and either accepts it as complete or rejects it with feedback. If rejected, that feedback is routed back to the generator, which uses it to produce a revised attempt. This loop continues until the verifier accepts the output or the maximum number of iterations is reached.生成器接收任务并生成初始输出，然后将其传递给验证器进行评估。验证器检查输出是否符合要求的标准，要么接受为完成，要么拒绝并附上反馈。如果被拒绝，反馈将传回生成器，生成器据此生成修订版本。此循环持续进行，直到验证器接受输出或达到最大迭代次数。

Where it works well适用场景

Consider a support system that generates email responses to customer tickets. The generator produces an initial response using product documentation and ticket context. The verifier checks accuracy against the knowledge base, evaluates tone against brand guidelines, and confirms the response addresses each issue raised. Failed checks return to the generator with feedback that names the exact problem, such as a feature misattributed to the wrong pricing tier or a ticket issue left unanswered.考虑一个生成客户工单邮件回复的支持系统。生成器利用产品文档和工单上下文生成初始回复。验证器根据知识库检查准确性，根据品牌指南评估语气，并确认回复是否解决了提出的每个问题。未通过的检查会连同反馈返回给生成器，反馈明确指出具体问题，例如将功能错误归因于错误的定价层级，或工单问题未得到答复。

Use this pattern when output quality is critical and evaluation criteria can be made explicit. It’s effective for code generation (one agent writes code, another writes and runs tests), fact-checking, rubric-based grading, compliance verification, and any domain where an incorrect output costs more than an additional generation cycle.当输出质量至关重要且评估标准可以明确时，使用此模式。它适用于代码生成（一个智能体编写代码，另一个编写并运行测试）、事实核查、基于评分标准的评分、合规性验证，以及任何错误输出成本高于额外生成周期的领域。

Where it struggles局限性

The verifier is only as good as its criteria. A verifier told only to check whether output is good, with no further criteria, will rubber-stamp the generator's output. Teams most often fail by implementing the loop without defining what verification means, which creates the illusion of quality control without the substance. (We discussed this early victory problem in the previous post.)验证器的有效性取决于其标准。如果验证器仅被告知检查输出是否良好，而无进一步标准，它只会对生成器的输出敷衍了事。团队最常见的失败是实现了循环，却没有定义验证的含义，这造成了质量控制的假象，却无实质内容。（我们在上一篇文章中讨论过这种早期胜利问题。）

The pattern also assumes generation and verification are separable skills. If evaluating a creative approach is as hard as generating one, the verifier may not reliably catch problems.该模式还假设生成和验证是可分离的技能。如果评估创造性方法与生成它一样困难，验证器可能无法可靠地发现问题。

Finally, iterative loops can stall. If the generator can't address the verifier's feedback, the system oscillates without converging. A maximum iteration limit with a fallback strategy (escalate to a human, return the best attempt with caveats) prevents this from becoming an infinite loop.最后，迭代循环可能停滞。如果生成器无法解决验证器的反馈，系统会振荡而不收敛。设置最大迭代次数并采用回退策略（升级到人工处理，返回附带说明的最佳尝试结果）可防止其变成无限循环。

Pattern 2: Orchestrator-subagent模式2：编排器-子智能体

Hierarchy defines this pattern. One agent acts as a team lead that plans work, delegates tasks, and synthesizes results. Subagents handle specific responsibilities and report back.层级结构定义了此模式。一个智能体充当团队领导，负责规划工作、分配任务并综合结果。子智能体处理特定职责并汇报结果。

How it works

A lead agent receives a task and determines how to approach it. It may handle some subtasks directly while dispatching others to subagents. Subagents complete their work and return results, which the orchestrator synthesizes into a final output.领导智能体接收任务并决定如何处理。它可能直接处理某些子任务，同时将其他任务分派给子智能体。子智能体完成工作并返回结果，编排器将其综合成最终输出。

Claude Code uses this pattern. The main agent writes code, edits files, and runs commands itself, dispatching subagents in the background when it needs to search a large codebase or investigate independent questions so work continues while results stream back. Each subagent operates in its own context window and returns distilled findings. This keeps the orchestrator's context focused on the primary task while exploration happens in parallel.Claude Code 使用了此模式。主智能体自行编写代码、编辑文件并运行命令，同时在后台分派子智能体，以便在需要搜索大型代码库或调查独立问题时，工作能继续进行，同时结果流回。每个子智能体在其自己的上下文窗口中操作，并返回提炼后的发现。这使编排器的上下文专注于主要任务，而探索并行进行。

Where it works well

Consider an automated code review system. When a pull request arrives, the system needs to check for security vulnerabilities, verify test coverage, assess code style, and evaluate architectural consistency. Each check is distinct, requires different context, and produces a clear output. An orchestrator dispatches each check to a specialized subagent, collects the results, and synthesizes a unified review.考虑一个自动化代码审查系统。当拉取请求到达时，系统需要检查安全漏洞、验证测试覆盖率、评估代码风格以及评估架构一致性。每项检查都不同，需要不同的上下文，并产生清晰的输出。编排器将每项检查分派给专门的子智能体，收集结果，并综合成统一的审查意见。

Use this pattern when task decomposition is clear and subtasks have minimal interdependence. The orchestrator maintains a coherent view of the overall goal while subagents stay focused on specific responsibilities.当任务分解清晰且子任务之间相互依赖最小时，使用此模式。编排器保持对整体目标的连贯视图，而子智能体专注于特定职责。

Where it struggles

The orchestrator becomes an information bottleneck. When a subagent discovers something relevant to another subagent's work, that information has to travel back through the orchestrator. If the security subagent finds an authentication flaw that affects the architecture subagent's analysis, the orchestrator must recognize this dependency and route the information appropriately. After several such handoffs, critical details are often lost or summarized away.编排器成为信息瓶颈。当子智能体发现与另一个子智能体工作相关的信息时，该信息必须通过编排器传回。如果安全子智能体发现影响架构子智能体分析的认证缺陷，编排器必须识别此依赖关系并适当路由信息。经过几次这样的交接后，关键细节常常丢失或被概括掉。

Sequential execution also limits throughput. Unless explicitly parallelized, subagents run one after another, meaning the system incurs multi-agent token costs without the speed benefit.顺序执行也限制了吞吐量。除非明确并行化，否则子智能体一个接一个地运行，这意味着系统承担了多智能体的令牌成本，却没有速度优势。

Pattern 3: Agent teams模式3：智能体团队

When work decomposes into parallel subtasks that can proceed independently for extended periods, orchestrator-subagent can become unnecessarily constraining.当工作分解为可长时间独立进行的并行子任务时，编排器-子智能体模式可能变得不必要的约束。

How it works

A coordinator spawns multiple worker agents as independent processes. Teammates claim tasks from a shared queue, work on them autonomously across multiple steps, and signal completion.协调器生成多个工作智能体作为独立进程。团队成员从共享队列中领取任务，自主地跨多个步骤工作，并发出完成信号。

The difference from orchestrator-subagent is worker persistence. The orchestrator spawns a subagent for one bounded subtask, and the subagent terminates after returning a result. Teammates stay alive across many assignments, accumulating context and domain specialization that improve their performance over time. The coordinator assigns work and collects outcomes but doesn’t reset workers between tasks.与编排器-子智能体的区别在于工作智能体的持久性。编排器为一个有边界的子任务生成子智能体，子智能体在返回结果后终止。而团队成员在多个任务分配中保持活跃，积累上下文和领域专长，从而随时间提高性能。协调器分配工作并收集结果，但不会在任务之间重置工作智能体。

Where it works well

Consider migrating a large codebase from one framework to another. A teammate can migrate each service independently, with its own dependencies, test suite, and deployment configuration. A coordinator assigns each service to a teammate, and each teammate works through the migration autonomously: dependency updates, code changes, test fixes, validation. The coordinator collects completed migrations and runs integration tests across the full system.考虑将大型代码库从一个框架迁移到另一个框架。团队成员可以独立迁移每个服务，包括其自己的依赖项、测试套件和部署配置。协调器将每个服务分配给一个团队成员，每个团队成员自主完成迁移：依赖项更新、代码更改、测试修复、验证。协调器收集完成的迁移，并在整个系统上运行集成测试。

Use this pattern when subtasks are independent and benefit from sustained, multi-step work. Each teammate builds up context about its domain rather than starting fresh with each dispatch.当子任务独立且受益于持续的多步骤工作时，使用此模式。每个团队成员建立关于其领域的上下文，而不是每次分派都从头开始。

Where it struggles

Independence is the critical requirement. Unlike orchestrator-subagent, where the orchestrator can mediate between subagents and route information, teammates operate autonomously and can't easily share intermediate findings. If one teammate's work affects another's, neither is aware, and their outputs may conflict.独立性是关键要求。与编排器-子智能体不同，编排器可以在子智能体之间进行调解并路由信息，而团队成员自主操作，无法轻松共享中间发现。如果一个团队成员的工作影响另一个，双方都不知情，他们的输出可能冲突。

Completion detection is also harder. Since teammates work autonomously for variable durations, the coordinator must handle partial completion where one teammate finishes in two minutes and another takes twenty.完成检测也更困难。由于团队成员自主工作且持续时间可变，协调器必须处理部分完成的情况，例如一个团队成员两分钟完成，而另一个需要二十分钟。

Shared resources compound both problems. When multiple teammates operate on the same codebase, database, or file system, two teammates may edit the same file or make incompatible changes. The pattern requires careful task partitioning and conflict resolution mechanisms.共享资源加剧了这两个问题。当多个团队成员操作同一代码库、数据库或文件系统时，两个团队成员可能编辑同一文件或做出不兼容的更改。该模式需要仔细的任务划分和冲突解决机制。

Pattern 4: Message bus模式4：消息总线

As agent count increases and interaction patterns grow complex, direct coordination becomes difficult to manage. A message bus introduces a shared communication layer where agents publish and subscribe to events.随着智能体数量增加和交互模式变得复杂，直接协调变得难以管理。消息总线引入了一个共享通信层，智能体可以在其中发布和订阅事件。

How it works

Agents interact through two primitives: publish and subscribe. Agents subscribe to the topics they care about, and a router delivers matching messages. New agents with new capabilities can start receiving relevant work without rewiring existing connections.智能体通过两个原语交互：发布和订阅。智能体订阅他们关心的主题，路由器传递匹配的消息。具有新能力的新智能体可以开始接收相关工作，而无需重新配置现有连接。

Where it works well

A security operations automation system demonstrates where this pattern excels. Alerts arrive from multiple sources, and a triage agent classifies each by severity and type, routing high-severity network alerts to a network investigation agent and credential-related alerts to an identity analysis agent. Each investigation agent may publish enrichment requests that a context-gathering agent fulfills. Findings flow to a response coordination agent that determines the appropriate action.安全运营自动化系统展示了此模式的优势。警报从多个来源到达，分类智能体根据严重性和类型对每个警报进行分类，将高严重性网络警报路由到网络调查智能体，将凭证相关警报路由到身份分析智能体。每个调查智能体可能发布丰富请求，由上下文收集智能体满足。发现结果流向响应协调智能体，后者确定适当的行动。

This pipeline suits the message bus because events flow from one stage to the next, teams can add new agent types as threat categories evolve, and teams can develop and deploy agents independently. 此流水线适合消息总线，因为事件从一个阶段流向下一个阶段，团队可以在威胁类别演变时添加新的智能体类型，并且团队可以独立开发和部署智能体。

Use this pattern for event-driven pipelines where the workflow emerges from events rather than a predetermined sequence, and where the agent ecosystem is likely to grow.对于事件驱动的流水线，其中工作流由事件而非预定序列产生，并且智能体生态系统可能增长时，使用此模式。

Where it struggles

The flexibility of event-driven communication makes tracing harder. When an alert triggers a cascade of events across five agents, understanding what happened requires careful logging and correlation. Debugging is harder than following an orchestrator's sequential decisions.事件驱动通信的灵活性使追踪更加困难。当警报触发跨五个智能体的事件级联时，理解发生了什么需要仔细的日志记录和关联。调试比遵循编排器的顺序决策更困难。

Routing accuracy is also critical. If the router misclassifies or drops an event, the system fails silently, handling nothing but never crashing. LLM-based routers provide semantic flexibility but introduce their own failure modes.路由准确性也至关重要。如果路由器错误分类或丢弃事件，系统会静默失败，不处理任何内容但从不崩溃。基于LLM的路由器提供了语义灵活性，但也引入了自身的故障模式。

Pattern 5: Shared state模式5：共享状态

Orchestrators, team leads, and message routers in the previous patterns all centrally manage information flow. Shared state removes the intermediary by letting agents coordinate through a persistent store that all can read and write directly.前面模式中的编排器、团队领导和消息路由器都集中管理信息流。共享状态通过让智能体通过所有智能体都可以直接读写持久存储来协调，从而移除了中介。

How it works

Agents operate autonomously, reading from and writing to a shared database, file system, or document. There's no central coordinator. Agents check the store for relevant information, act on what they find, and write their findings back. Work typically begins when an initialization step seeds the store with a question or dataset, and ends when a termination condition is met: a time limit, a convergence threshold, or a designated agent determining the store contains a sufficient answer.智能体自主操作，读写共享数据库、文件系统或文档。没有中央协调器。智能体检查存储以获取相关信息，根据发现采取行动，并将发现写回。工作通常从初始化步骤开始，该步骤用问题或数据集填充存储，并在满足终止条件时结束：时间限制、收敛阈值或指定智能体确定存储包含足够答案。

Where it works well

Consider a research synthesis system where multiple agents investigate different aspects of a complex question. One explores academic literature, another analyzes industry reports, a third examines patent filings, a fourth monitors news coverage. Each agent's findings may inform the others' investigations. The academic literature agent might discover a key researcher whose company the industry agent should examine more closely.考虑一个研究综合系统，其中多个智能体调查复杂问题的不同方面。一个探索学术文献，另一个分析行业报告，第三个审查专利申请，第四个监控新闻报道。每个智能体的发现可能为其他智能体的调查提供信息。学术文献智能体可能发现一位关键研究人员，其公司行业智能体应更仔细地审查。

With shared state, findings go directly into the store. The industry agent can see the academic agent's discoveries immediately, without waiting for a coordinator to route the information. Agents build on each other’s work, and the shared store becomes an evolving knowledge base.通过共享状态，发现结果直接进入存储。行业智能体可以立即看到学术智能体的发现，而无需等待协调器路由信息。智能体基于彼此的工作构建，共享存储成为不断发展的知识库。

Shared state also removes the coordinator as a single point of failure. If any one agent stops, the others continue reading and writing. In orchestrator and message-bus systems, a coordinator or router failure halts everything.共享状态还消除了协调器作为单点故障。如果任何一个智能体停止，其他智能体继续读写。在编排器和消息总线系统中，协调器或路由器故障会停止一切。

Where it struggles

Without explicit coordination, agents may duplicate work or pursue contradictory approaches. Two agents might independently investigate the same lead. Agent interactions produce system behavior rather than top-down design, which makes outcomes less predictable.没有显式协调，智能体可能重复工作或追求矛盾的方法。两个智能体可能独立调查同一线索。智能体交互产生系统行为，而非自上而下的设计，这使得结果更不可预测。

The harder failure mode is reactive loops. For example, Agent A writes a finding, Agent B reads it and writes a follow-up, Agent A sees the follow-up and responds. The system keeps burning tokens on work that isn’t converging. Duplicate work and concurrent writes have known engineering fixes (locking, versioning, partitioning). Reactive loops are a behavioral problem and need first-class termination conditions: a time budget, a convergence threshold (no new findings for N cycles), or a designated agent whose job is to decide when the store contains a sufficient answer. Systems that treat termination as an afterthought tend to cycle indefinitely or stop arbitrarily when one agent's context fills.更困难的故障模式是反应循环。例如，智能体A写入一个发现，智能体B读取并写入后续，智能体A看到后续并响应。系统不断消耗令牌进行不收敛的工作。重复工作和并发写入有已知的工程修复方法（锁定、版本控制、分区）。反应循环是行为问题，需要一流的终止条件：时间预算、收敛阈值（N个周期内无新发现）或指定智能体负责决定存储何时包含足够答案。将终止视为事后考虑的系统往往无限循环，或在一个智能体的上下文填满时任意停止。

Choosing and evolving between patterns选择与模式间的演进

The right pattern depends on a handful of structural questions about the system. In our previous post, we argued for context-centric decomposition, which divides work by what context each agent needs rather than by what type of work it does. That principle applies here too. The patterns differ in how they manage context boundaries and information flow.正确的模式取决于关于系统的一些结构性问题的答案。在上一篇文章中，我们主张以上下文为中心的分解，即根据每个智能体需要什么上下文来划分工作，而不是根据它做什么类型的工作。该原则在此同样适用。这些模式在管理上下文边界和信息流方面有所不同。

Orchestrator-subagent vs. agent teams编排器-子智能体 vs. 智能体团队

Both involve a coordinator dispatching work to other agents. The question is how long workers need to maintain their context.两者都涉及协调器向其他智能体分派工作。问题在于工作智能体需要保持其上下文多长时间。

• Choose orchestrator-subagent when subtasks are short, focused, and produce clear outputs. The code review system works well here because each check runs its analysis, generates a report, and returns within a single bounded invocation. The subagent doesn't need to carry context across multiple cycles.当子任务简短、集中且产生清晰输出时，选择编排器-子智能体。代码审查系统在此表现良好，因为每项检查运行其分析、生成报告并在单个有界调用中返回。子智能体无需跨多个周期携带上下文。
• Choose agent teams when subtasks benefit from sustained, multi-step work. The codebase migration fits here because each teammate develops real familiarity with its assigned service: the dependency graph, test patterns, deployment configuration. That accumulated context improves performance in ways one-shot dispatch can't replicate.当子任务受益于持续的多步骤工作时，选择智能体团队。代码库迁移适合此处，因为每个团队成员对其分配的服务建立了真正的熟悉度：依赖图、测试模式、部署配置。这种积累的上下文以一次性分派无法复制的方式提高了性能。

When subagents need to retain state across invocations, agent teams are the better fit.当子智能体需要在调用之间保留状态时，智能体团队是更好的选择。

Orchestrator-subagent vs. message bus编排器-子智能体 vs. 消息总线

Both can handle multi-step workflows. The question is how predictable the workflow structure is.两者都可以处理多步骤工作流。问题在于工作流结构的可预测性。

• Choose orchestrator-subagent when the sequence of steps is known in advance. The code review system follows a fixed pipeline: receive a PR, run checks, synthesize results.当步骤序列事先已知时，选择编排器-子智能体。代码审查系统遵循固定流水线：接收PR，运行检查，综合结果。
• Choose message bus when the workflow emerges from events and may vary based on what's discovered. The security operations system can't predict what alerts will arrive or what investigation paths they'll require. New alert types may emerge that need new handling. The message bus accommodates that variability by routing events to capable agents rather than following a predetermined sequence.当工作流由事件产生并可能根据发现而变化时，选择消息总线。安全运营系统无法预测哪些警报会到达，或它们需要哪些调查路径。新的警报类型可能出现，需要新的处理方式。消息总线通过将事件路由到有能力的智能体来适应这种可变性，而不是遵循预定序列。

As conditional logic accumulates in the orchestrator to handle an expanding variety of cases, the message bus makes that routing explicit and extensible.随着编排器中处理不断扩展的各种情况的条件逻辑积累，消息总线使该路由显式且可扩展。

Agent teams vs. shared state智能体团队 vs. 共享状态

Both involve agents working autonomously. The question is whether agents need each other's findings.两者都涉及智能体自主工作。问题在于智能体是否需要彼此的发现。

• Choose agent teams when agents work on separate partitions that don't interact. The codebase migration fits here because each teammate handles its service and the coordinator combines results at the end.当智能体在不交互的独立分区上工作时，选择智能体团队。代码库迁移适合此处，因为每个团队成员处理其服务，协调器在最后组合结果。
• Choose shared state when agents' work is collaborative and findings should flow between them in real time. The research synthesis system is a better match because the academic agent's discovery of a key researcher immediately becomes relevant to the industry agent's investigation.当智能体的工作是协作性的且发现应在它们之间实时流动时，选择共享状态。研究综合系统是更好的匹配，因为学术智能体发现关键研究人员立即与行业智能体的调查相关。

Once teammates need to communicate with each other rather than only share final results, shared state makes that more natural.一旦团队成员需要相互通信而不仅仅是共享最终结果，共享状态使其更自然。

Message bus vs. shared state消息总线 vs. 共享状态

Both support complex multi-agent coordination. The question is whether work flows as discrete events or accumulates into a shared knowledge base.两者都支持复杂的多智能体协调。问题在于工作流是作为离散事件流动，还是积累成共享知识库。

• Choose message bus when agents react to events in a pipeline. The security operations system processes alerts stage by stage, with each event triggering the next before completing. The pattern is efficient at routing events to capable agents.当智能体在流水线中对事件做出反应时，选择消息总线。安全运营系统逐阶段处理警报，每个事件在完成前触发下一个。该模式在将事件路由到有能力的智能体方面高效。
• Choose shared state when agents build on accumulated findings over time. The research synthesis system gathers knowledge continuously. Agents return to the store repeatedly, seeing what others have discovered and adjusting their investigations.当智能体随时间基于积累的发现构建时，选择共享状态。研究综合系统持续收集知识。智能体反复返回存储，查看他人发现的内容并调整其调查。

The message bus still has a router, which means a central component decides where events go. Shared state is decentralized. If eliminating single points of failure is a priority, shared state provides that more completely.消息总线仍然有一个路由器，这意味着一个中央组件决定事件去向。共享状态是去中心化的。如果消除单点故障是优先事项，共享状态更彻底地提供了这一点。

If agents in a message bus system are publishing events to share findings rather than trigger actions, shared state is a better fit.如果消息总线系统中的智能体发布事件是为了共享发现而非触发动作，则共享状态是更好的选择。

Getting started入门指南

Production systems often combine patterns. A common hybrid uses orchestrator-subagent for the overall workflow with shared state for a collaboration-heavy subtask. Another uses message bus for event routing with agent team-style workers handling each event type. These patterns are building blocks, not mutually exclusive choices.生产系统通常结合多种模式。一种常见的混合模式是使用编排器-子智能体处理整体工作流，同时使用共享状态处理协作密集的子任务。另一种是使用消息总线进行事件路由，并使用智能体团队风格的工作智能体处理每种事件类型。这些模式是构建块，而非互斥的选择。

The following table summarizes when each pattern is appropriate.下表总结了每种模式的适用场景。

For most use cases, we recommend starting with orchestrator-subagent. It handles the widest range of problems with the least coordination overhead. Observe where it struggles, then evolve toward other patterns as specific needs become clear.对于大多数用例，我们建议从编排器-子智能体开始。它处理最广泛的问题，且协调开销最小。观察其不足之处，然后随着具体需求变得清晰，向其他模式演进。

‍In upcoming posts, we will examine each pattern in depth with production implementations and case studies. For background on when multi-agent systems are worth the investment, see Building multi-agent systems: when and how to use them.在接下来的文章中，我们将通过生产实现和案例研究深入探讨每种模式。有关多智能体系统何时值得投资的背景信息，请参阅《构建多智能体系统：何时以及如何使用它们》。

Acknowledgements致谢

Written by Cara Phillips, with contributions from Eugene Yan, Jiri De Jonghe, Samuel Weller, and Erik S.作者：Cara Phillips，贡献者：Eugene Yan、Jiri De Jonghe、Samuel Weller 和 Erik S。