Multi-Agent Coordination Patterns: Five Approaches and When to Use Them多智能体协作指南：五种主流模式怎么选、怎么用？

The piece maps five multi-agent coordination patterns — generator-verifier, orchestrator-subagent, agent teams, message bus, shared state — by how they route information and divide context, not by task type.

Its core prescription: default to orchestrator-subagent for low coordination overhead, then upgrade only when a specific bottleneck (memory loss, rigid workflow, need for cross-agent sharing, single point of failure) forces it.

The article's organizing move is to reject task-type taxonomy in favor of an information-flow taxonomy: patterns differ not in what agents do but in how context boundaries are drawn and how information travels between agents. This reframing — inherited from the author's earlier 'context-centric decomposition' principle — is what lets the five patterns be placed on a coherent spectrum rather than treated as five unrelated recipes, and it's why the piece can later offer pairwise decision rules instead of a flat comparison table.

Generator-verifier is presented as the floor case: its entire failure mode reduces to one variable, the specificity of the verifier's rubric. The piece is careful to name the mechanism precisely — a vague rubric doesn't just underperform, it produces 'false confidence,' rubber-stamping bad output while looking like quality control. This is a sharper claim than the usual 'add a review step' advice, because it locates the risk in the evaluation criteria rather than in the loop structure itself.

Orchestrator-subagent and agent teams are distinguished by a single test — does the subtask need persistent memory across invocations — which is a cleaner discriminator than the usual 'hierarchy vs. peer-to-peer' framing. The piece uses Claude Code itself as the worked example, grounding an abstract pattern in a system readers likely already use, and it correctly flags the bottleneck risk: cross-cutting findings (a security bug affecting an architecture review) must route through the orchestrator, so information can degrade through repeated summarization.

Message bus and shared state both decentralize communication but retain an important asymmetry the piece is explicit about: a message bus still has a router making routing decisions centrally, while shared state has none — which is why shared state, not message bus, is recommended when eliminating single points of failure is the hard requirement. This distinction matters practically because an LLM-based router inherits LLM failure modes (misclassification, silent drops), a risk the piece names directly rather than glossing over.

The 'reactive loop' failure mode in shared state is the article's most concrete engineering warning: two agents can echo each other's writes indefinitely, and this is explicitly distinguished from ordinary race-condition problems (which have known fixes like locking and versioning) as a behavioral design problem requiring an upfront termination rule — time budget, no-new-findings threshold, or a dedicated judge agent. Naming this as a distinct failure category, rather than folding it into generic concurrency bugs, is the piece's most actionable engineering insight.

The closing decision framework — four pairwise questions plus a recommendation to default to orchestrator-subagent — is the piece's most practically useful contribution, but it's also where the analysis thins out: the four comparisons cover adjacent pairs in a linear ordering, leaving open how a team should reason when a problem sits ambiguously between non-adjacent patterns (e.g., orchestrator-subagent vs. shared state directly), a gap the closing note on composing patterns only partially addresses.