多 Agent 系统炒了一年，生产环境里真正活下来的只有三种模式。剩下的都在坟墓里。

这个结论不是我的。它来自三份今天同时浮出水面的证据——一份是 Cognition（Devin 背后的公司）工程负责人的内部复盘，一份是 Manning 作者 Micheal Lanham 的行业全景报告，还有一份，是 GitHub 上一个叫 metaswarm 的项目。

我把它们放在一起看，发现一件很有意思的事：它们说的竟然是同一句话。

三个信号，同一个判断

信号一：metaswarm——18 个 Agent，127 个 PR，一个周末

今天 HN 上最火的项目。一个人 + 18 个 AI agent + 一个周末 = 127 个 PR 推到生产。MIT 开源。看起来是多 Agent 协作的终极案例。

但如果你仔细看它的架构，你会发现一个被刻意隐藏的细节：它的 18 个 Agent 不是在对等协作。它是 map-reduce-and-manage。

一个管理者拆任务，17 个子 Agent 各干各的，管理者收结果、合并、push。Agent 之间不互相聊天、不互相审查、不互相投票。每一个子 Agent 面对的是自己那一小块独立的上下文。

它看起来像 swarm，但其实是流水线。

信号二：Walden Yan 的内部复盘——「写入保持单线程」

Walden Yan 是 Cognition 的工程负责人。他 10 个月前写了一篇《不要构建多 Agent 系统》，今天又写了一篇《多 Agent：什么真的有效》。

核心结论原话：「多 Agent 系统在今天最有效时，写入保持单线程，额外的 Agent 贡献智能而不是行动。」

他们试了三种模式：

1. 代码审查循环——编码 Agent 写，审查 Agent 读。审查 Agent 拥有完全干净的上下文，不看编码过程，只看 diff。平均每个 PR 能发现 2 个 bug，58% 是严重的。关键发现：两个 Agent 不共享上下文效果反而更好。因为上下文衰减——编码 Agent 工作几小时后积累了巨大的上下文窗口，注意力已经稀释了。干净的审查 Agent 反而更聪明。

2. 智能朋友——主模型遇到棘手问题，调用一个更强（也更贵）的模型作为「朋友」。关键难点不是推理能力，是沟通：弱模型怎么知道自己到极限了？该传给强模型什么上下文？强模型怎么回话才能让弱模型真正理解？

3. 管理者-子 Agent——一个管理 Devin 拆任务，子 Devin 各干各的，管理者综合。遇到的问题全是沟通问题：管理者默认过度规定（因为它缺乏代码库上下文）、子 Agent 不主动报告该让兄弟姐妹知道的信息、Agent 之间默认不传消息。

三种模式，同一条规则：写操作的 Agent 只有一个。

信号三：Micheal Lanham 的行业全景——「多 Agent 失败是结构性的，不是提示词问题」

Lanham 是 Manning《AI Agents in Action》的作者。他今天的文章标题就说明了一切：《Multi-Agent in Production in 2026: What Actually Survived》。

他把多 Agent 系统分成三种拓扑：

• Agent-flow（流水线）：顺序传递。A 做完交给 B，B 做完交给 C。这是生产环境里存活率最高的形态。
• Agent-orchestration（编排）：一个管理者调度多个执行者。map-reduce-and-manage。最实用的复杂任务形态。
• Agent-collaboration（对等协作）：Agent 之间互相通信、协商、投票。几乎全死了。

他的原话：「大多数看起来像『更多 Agent = 更聪明』的东西，其实只是相同信息的冗余重排列。」

三份报告，三个作者，没有互相引用。但结论完全一致。

为什么「对等协作」全死了？

答案藏在两个技术细节里。

第一个，Walden 说的「操作携带隐式决策」。

当一个 Agent 写代码时，它在做选择——用什么设计模式、怎么处理边界情况、变量命名风格、错误处理策略。这些选择不是显式的，是「隐式」的。

两个 Agent 同时写，就会对同一个问题做出互相冲突的隐式决策。最后合并的时候不是 merge conflict，是设计哲学冲突。这种冲突没有 diff 工具能自动解决。

第二个，Lanham 说的「级联表面」。

对等协作的失败不是线性的，是指数级的。Agent A 的误差传给 Agent B，B 放大后传给 C，C 再放大传给 A。三个循环下来，输出和输入的语义距离已经大到不可恢复。

这解释了为什么 2024 年所有那些「Agent 团队自动开发 App」的演示都停在了 demo 阶段。

那活下来的三种模式长什么样？

模式一：流水线（Agent-flow）

最简单的形态。A → B → C，一个接一个。像工厂流水线。

适用场景：需求明确、步骤可分、输出可验证。比如：需求分析 Agent → 代码生成 Agent → 测试生成 Agent → 代码审查 Agent。

活下来的原因：每一步的输入和输出是明确的、可检查的。出问题能定位到具体环节。

模式二：编排（Orchestration = map-reduce-and-manage）

一个强 Agent 做规划 + 拆解 + 综合，多个弱 Agent 并行执行子任务。

适用场景：复杂任务需要并行加速，但决策权必须集中。比如 metaswarm 的 18 个 Agent，比如 Devin 的 manager-worker。

活下来的原因：写入操作只有管理者一个。子 Agent 贡献的是「智能」（分析、生成、搜索），不是「决策」。

模式三：生成-验证（Generator-Validator）

一个 Agent 写，另一个 Agent 读 + 挑刺。写的不看读的过程，读的不看写的过程。干净的上下文。

适用场景：代码审查、安全检查、内容审核。Walden 说他们在生产环境已经跑了很久。

活下来的原因：验证 Agent 的上下文是干净的。没有历史包袱，不会被编码 Agent 的错误假设带偏。

一个反直觉的结论

看了这三份报告，我最大的感受不是「多 Agent 不行」，而是一个更微妙的东西——

多 Agent 系统真正解决的问题不是「更聪明」，是「更便宜 + 更可靠」。

用同样的钱，跑 5 个便宜模型的并行流水线，比跑 1 个贵模型做全流程，出活质量更稳定、容错率更高、速度更快。

这不是 AGI 的突破。这是系统设计的胜利。

Walden 在文章最后说的：「我们正在构建一个世界，智能被注入软件开发生命周期的每一个阶段——不是作为一群自主行动者，而是作为一个协调的系统，扩展人类的品味。」

注意这个词：「协调的系统」，不是「自主的行动者」。

所以，别再造 Agent Swarm 了

如果你现在准备做一个多 Agent 项目，问自己三个问题：

1. 写入操作能不能只有一个人？ 如果能，继续。如果不能，单 Agent 可能更好。
2. Agent 之间传什么上下文？传多少？ 这不是提示词问题，这是架构问题。传多了淹没接收者，传少了接收者无法做正确决策。
3. 失败会怎么级联？ 如果 Agent A 错了，Agent B、C、D 会跟着错到什么程度？有没有断路器？

如果你对这三个问题没有清晰的答案，你就还没有准备好上生产。

多 Agent 的未来是真实的。但不是你想的那种未来。

不是一群 Agent 在聊天室里讨论怎么做。是一个指挥，多个执行者。是一种结构设计，不是魔法。

参考来源：

• Walden Yan (Cognition): Multi-Agents: What’s Actually Working
• Micheal Lanham: Multi-Agent in Production in 2026: What Actually Survived
• metaswarm: 18 AI agents, 127 PRs to prod in a weekend
• Anthropic: anthropics/skills

Multi-Agent in Production in 2026: What Actually Survived

Source: https://medium.com/@Micheal-Lanham/multi-agent-in-production-in-2026-what-actually-survived-f86de8bb1cd1 Press enter or click to view image in full size

An opinionated field guide to agent-flow, orchestration, and collaboration, with the failure data and topology choices that matter when you ship.

The 2026 verdict on multi-agent systems is not the one the 2024 hype cycle promised. Teams of agents did not get automatically smarter than one good agent. What survived contact with production is narrower and, frankly, more useful to know.

Agent-flow and agent orchestration are alive. Agent collaboration, the free-form peer team, survived only in bounded and heavily instrumented niches. Three strands of evidence landed in the same year and all pointed the same way: failure in multi-agent systems is structural, not a prompting bug, and most of what looked like “more agents means more intelligence” was just redundant rearrangement of the same information.

What You’ll Learn in This Article:

• The 2026 Definition of Multi-Agent: Why “reasoning loci” and “control ownership” are better production tests than counting LLM calls
• The Three Patterns and Their Failure Modes: Flow, orchestration, and collaboration, with the exact cascade surface each one exposes
• The Failure Data That Ended the Debate: Numbers from MIT, Google, and the “From Spark to Fire” cascade paper showing when extra agents hurt
• A Concrete Decision Rule: Code for each pattern in CrewAI, OpenAI Agents SDK, LangGraph, and AutoGen, plus when to reach for each

Press enter or click to view image in full size

What Counts as Multi-Agent in 2026

Google’s 2026 scaling paper gave the cleanest operational test. A single-agent system is “one solitary reasoning locus”, a single loop that perceives, plans, and acts, even if it uses tools, chain-of-thought, or self-reflection. A multi-agent system has multiple LLM-backed agents that communicate through message passing, shared memory, or an orchestration protocol.

That’s the line that actually matters in production. If one loop owns the whole decision and just calls helpers, you have a compound single-agent design, not multi-agent coordination.

The classical multi-agent-systems literature is stricter. In the Wooldridge tradition, the load-bearing properties are autonomy, local views, and decentralization. Under that test, a supervisor who retains full control over specialists is only weakly multi-agent. It uses multiple model instances, but the decision structure is still centralized. This distinction matters because most of the 2025–2026 “multi-agent” performance work is really about delegated workflows.

Anthropic’s production writeup takes a looser pragmatic line: a multi-agent system is multiple LLMs autonomously using tools in a loop, working together. That’s less strict but it fits deployed systems well. It’s especially useful for distinguishing subagents (their own prompt, state, and tool loop) from simple reusable tools.

Put these together and you get a production-ready rule: if the specialist is just a bounded capability invoked by a manager who owns the final answer, you have single-agent with subagent-tools. OpenAI is explicit about this. Inagent\.as\_tool\(\)the manager “keeps ownership of the reply.” OpenAI handoffs, by contrast, actually transfer ownership to the specialist. AutoGen group chat maintains a shared thread where different agents publish and react. Those last two are where genuine multi-agent behavior starts.

Press enter or click to view image in full size

The Three Patterns and How They Fail

Three analogies still work because they map to topology and failure surface. Agent-flow is an assembly line: each stage hands an artifact to the next. Orchestration is a franchise or hierarchical command: one hub routes to specialist branches and synthesizes the result. Collaboration is a free-flowing sports possession: peers coordinate dynamically, trade messages, share a workspace, and pay a steep communications tax.

These analogies earn their keep by predicting the dominant failure in each topology. Relay systems accumulate upstream defects. Hub systems bottleneck and “play telephone” with paraphrase loss. Peer teams drift into consensus inertia or message explosion.

Agent-flow

Flow is best when the work has natural stage boundaries, explicit intermediate artifacts, and a strong need for traceability. In 2026, flow systems often have more parallelism inside each stage than the early “chain” metaphors implied, but the control logic is still fundamentally sequential.

Press enter or click to view image in full size

The failure signature: early artifact errors poison downstream stages, and verification arrives after contextual debt has already accrued. That’s why flow systems need aggressive intermediate-artifact schemas and per-stage evaluators, not just a final grader.

Orchestration

Orchestration is now the default public pattern. It’s the clearest fit for domain routing, compliance boundaries, and wide-but-modular tasks like research, financial retrieval, or customer support. OpenAI’s docs explicitly separate handoffs from agents-as-tools, and LangGraph’s supervisor and subagent patterns formalize the same distinction.

Press enter or click to view image in full size

The failure signature: hub fragility (one bad routing decision cascades into every specialist) and translation/paraphrase loss at the center, where the supervisor compresses a specialist’s rich output into a summary for the next step.

Collaboration

Collaboration is the most romantic pattern and the least durable default. AutoGen’s group chat is still the canonical implementation: agents share one topic, take turns, and a manager picks who speaks next. But in production, teams increasingly bound collaboration with a hidden selector, phase gates, shared artifacts, or a final arbiter. Free mesh survived mostly as a controlled subroutine inside a supervisor, not as the outer architecture.

Press enter or click to view image in full size

Here’s the comparison that actually matters in production. Forget the labels and look at control, observability, and cascade surface. Flow gives you the highest observability and lowest engineering ambiguity at moderate cost. Orchestration gives you high observability with medium engineering cost and scales to domain routing. Collaboration gives you the highest token cost, the lowest observability, and the hardest blame assignment, and it’s only worth it when peers contribute genuinely independent evidence or exploration.

Press enter or click to view image in full size

The Evidence That Ended the Debate

The sharpest warning shot came from**Why Do Multi-Agent LLM Systems Fail?**The authors analyzed five popular MAS frameworks across more than 150 tasks and identified 14 distinct failure modes across three categories: specification/system design, inter-agent misalignment, and task verification/termination. Obvious interventions only went so far. On their ChatDev ProgramDev case study, correctness improved from 25.0% to 40.6% with a redesigned topology. That still left performance far below what most production systems would tolerate. Their conclusion: many failures are structural, not fixable with better prompts.

The 2026 “From Spark to Fire” cascade paper made this concrete. Multi-agent collaboration is a dependency graph, and a single atomic falsehood can spread into system-level false consensus. The topological fragility numbers are brutal. In LangGraph, hub injection produced 100% system-wide failure versus 9.7% from a leaf. In CrewAI, 100% versus 15.9%. In extended cascade tests, final infection rates were near-saturating across MetaGPT, LangGraph, CrewAI, AutoGen, and Camel (all at 100%), with LangChain chains at 89.2%. Their governance layer pushed defense success from 0.32 to above 0.89, but with meaningful safety overhead.

Press enter or click to view image in full size

The MIT note from David Simchi-Levi and coauthors is the theoretical spine. The key result: without new exogenous signals, any delegated acyclic network is decision-theoretically dominated by a centralized Bayes decision maker looking at the same information. In the common-evidence regime, optimizing a multi-agent DAG under a finite communication budget is equivalent to designing a lossy communication experiment on the shared signal. If your extra agents don’t add fresh evidence, better interfaces, or selective review, you’re mostly rearranging and compressing what you already have.

The MIT numbers bite. On a controlled four-way task, adding relay stages without new signals drove gpt-4.1-mini accuracy from 90.7% (one stage) to 41.2% (two stages), 43.5% (three), and 22.5% (five), actually below the 25% chance baseline. Interface design mattered: a structured posterior-style relay degraded accuracy by 2.8 points per stage, while prose relay degraded it by 8.5 points per stage. When the added module contributed genuinely new information (a tool-augmented KB lookup), accuracy jumped from 24.3% to 82.7%.

Press enter or click to view image in full size

The 2026 Google scaling study sweeps 180 configurations, five canonical architectures, fixed token budgets. The main result: alignment matters. Centralized coordination improved Finance-Agent performance by 80.9% on parallelizable work, but on sequential planning tasks every multi-agent variant degraded performance by 39–70%. Reliability tracked topology: independent systems amplified errors by 17.2x, centralized systems contained them to 4.4x. The 2026 generalization in one line: architecture matters, but task shape matters more.

Press enter or click to view image in full size

What Actually Survived Production

Flow-dominant systems are alive and healthy where work is genuinely stageable.

Meta’s Ranking Engineer Agent runs Validation, then Combination, then Exploitation, under engineer-approved budgets, and survives multi-day jobs via a hibernate-and-wake loop between planner and executor. First rollout: doubled average model accuracy across six models and turned two engineers per model into three engineers across eight models. Meta’s tribal-knowledge precompute engine uses 50+ specialized agents moving through explorers, analysts, writers, critics, fixers, testers, and gap-fillers to build 59 durable context files, yielding 40% fewer tool calls per task. Google Cloud and App Orchid’s forecasting system sequentially orchestrates a data-semantic preparation phase and then a prediction phase.

Orchestration is the true winner. Anthropic Research is the cleanest reference design: a lead agent spawns 3–5 subagents in parallel, those subagents use 3+ tools in parallel, and the system cut complex-query research time by up to 90%. Anthropic reports a 90.2% gain over single-agent Opus 4 on internal research evaluation, while warning that these systems burn roughly 15x the tokens of chat interactions and are a poor fit for highly interdependent coding work.

Press enter or click to view image in full size

The orchestration case studies now extend well beyond research. Exa’s deep research uses Planner, parallel Tasks, Observer, processing hundreds of research queries daily with latencies from 15 seconds to 3 minutes. S&P Global’s Kensho Grounding uses a central router that breaks a user query into DRA-specific subqueries across equity research, fixed income, and macroeconomics. Bertelsmann’s Content Search uses a centralized router over domain agents in production across the company. Minimal’s e-commerce support system uses a planner plus research specialists, reporting 80%+ efficiency gains and expected autonomous handling of 90% of tickets, while explicitly flagging that monolithic prompts were error-prone.

Collaboration is the chastened pattern. The public shipped systems that look team-like are almost all bounded collaborations, not open mesh republics. Google’s AI co-scientist is a multi-agent scientific collaborator. Spotify’s Ads AI decomposes media planning into specialized agents working in parallel. Meta’s tribal-knowledge engine uses critics, fixers, upgraders, and testers over shared artifacts inside one session. All three are constrained by artifacts, selectors, or phases.

The clearest counterexample is Shopify. Sidekick evolved into a stronger agentic platform, but Shopify’s recommendation to builders is blunt: “Avoid multi-agent architectures early.” The reason is engineering economics, not ideology. Tool complexity already made a single-agent system hard enough to reason about; adding more agents too early multiplies prompts, traces, and failure surfaces before it multiplies value.

Framework Code: Four Patterns, Four Frameworks

Throughout this section, we’ll walk through the minimum production-grade code for each pattern. We start with the simplest (flow), then add the two orchestration flavors that now dominate public case studies, then the collaboration pattern for the narrow case where it pays off.

Flow with CrewAI

CrewAI natively supports sequential and hierarchical processes and exposesusage\_metrics, which is one reason it’s attractive for workflow-heavy production.

from crewai import Agent, Task, Crew, Processresearcher = Agent(    role="Researcher",    goal="Collect facts and citations",    backstory="You gather evidence only.")writer = Agent(    role="Writer",    goal="Turn verified facts into a concise memo",    backstory="You write only from the provided findings.")tasks = [    Task(description="Research the topic and return structured findings.", agent=researcher),    Task(description="Write the final memo from the findings.", agent=writer),]crew = Crew(    agents=[researcher, writer],    tasks=tasks,    process=Process.sequential,)result = crew.kickoff()print(crew.usage_metrics)print(result)

This is the 2026 assembly-line pattern in its clearest form: linear stages, good traceability, and explicit usage metrics. The researcher finishes before the writer starts. Each task produces an artifact that the next task consumes.

Press enter or click to view image in full size

Central orchestration with OpenAI Agents SDK

OpenAI’s guidance is explicit: agents-as-tools fits when the manager should own the final answer and specialists are bounded capabilities. Handoffs, by contrast, move ownership to the specialist.

from agents import Agentsummarizer = Agent(    name="Summarizer",    instructions="Summarize supplied evidence into bullet points.")critic = Agent(    name="Critic",    instructions="Check summaries for omissions or contradictions.")manager = Agent(    name="Research Manager",    instructions="Stay responsible for the final answer. Call specialists as needed.",    tools=[        summarizer.as_tool(            tool_name="summarize_evidence",            tool_description="Summarize raw evidence."        ),        critic.as_tool(            tool_name="critique_summary",            tool_description="Review the summary for gaps."        ),    ],)

The manager stays responsible. This is technically single-agent with subagent-tools under the strict MAS definition, but it’s where most production teams start when they need domain specialization without giving up final-answer ownership.

Central orchestration with LangGraph supervisor

LangGraph supports subagents, handoffs/swarm, and custom workflow graphs. It’s become the default for bespoke production orchestration because it exposes topology directly.

from langchain_openai import ChatOpenAIfrom langgraph_supervisor import create_supervisorfrom langgraph.prebuilt import create_react_agentmodel = ChatOpenAI(model="gpt-4o")researcher = create_react_agent(model, tools=[web_search], name="researcher")writer = create_react_agent(model, tools=[save_report], name="writer")app = create_supervisor(    [researcher, writer],    model=model,).compile()result = app.invoke({"messages": [{"role": "user", "content": "Research and draft a report"}]})

The shift from the OpenAI SDK pattern is that LangGraph makes the routing graph explicit and traceable. You can see exactly which node received which message. For teams that want to audit routing mistakes (the hub-fragility failure mode from earlier), this explicitness is the point.

Collaboration with AutoGen group chat

AutoGen is the canonical home of group chat. Worth noting up front: the main Microsoft autogen repo is now in maintenance mode, which matters for greenfield choices.

from autogen_agentchat.agents import AssistantAgentfrom autogen_agentchat.teams import SelectorGroupChatwriter = AssistantAgent("writer", model_client=client)critic = AssistantAgent("critic", model_client=client)editor = AssistantAgent("editor", model_client=client)team = SelectorGroupChat(    [writer, critic, editor],    model_client=client,)await team.run(task="Draft, critique, and refine a short report.")

This is the reference implementation for collaboration: a shared thread, turn-taking, and a manager that picks the next speaker. Use it only when you have genuine independent evidence streams or parallel exploration; otherwise you’re paying the full communications tax for no gain.

Press enter or click to view image in full size

Practical Considerations Before You Ship

A few production rules that sound obvious and still trip people up.

**Start with a single strong agent.**Shopify’s guidance is the right default. Tool complexity alone can make one agent hard to reason about. Adding more agents before you’ve exhausted that path multiplies failure surface without proving added value.

**Test whether your specialists add new information.**Apply the MIT rule: if the specialist doesn’t bring a new exogenous signal, a better interface, or non-redundant review, it’s probably compressing data you already had. That’s where the 90.7% -> 22.5% collapse lives.

**Match topology to task shape, not to org chart.**The 2026 Google result is the sharper guide than any architecture diagram. Parallelizable work rewards centralization. Sequential planning punishes every multi-agent variant. Look at the task, not the team.

**Budget for 15x tokens if you go multi-agent.**Anthropic is direct about this. Research-style orchestration burns roughly 15x the tokens of chat interactions. If your margin doesn’t absorb that, you’re shipping a pattern that won’t survive billing review.

**Keep an arbiter if you let peers collaborate.**Every surviving 2026 collaboration system has phase gates, shared artifacts, or a final supervisor. Open mesh is what the failure taxonomy papers were studying.

**Watch for maintenance signals on frameworks.**AutoGen’s main repo is maintenance-only. CrewAI and LangGraph are active. OpenAI’s Agents SDK is native to the platform. This matters when you’re picking a greenfield stack today.

Wrapping Up

Three positions compress the 2026 evidence into architecture guidance. Anthropic: “find the simplest solution possible” and note that for many applications “single LLM calls” plus retrieval and examples are enough. Shopify, blunter: “Avoid multi-agent architectures early.” MIT, hardest-edged: added stages help only when they add new exogenous signals, preserve decision-relevant information better, or provide non-redundant review.

The production rule for 2026 is straightforward. Start with a strong single agent. Move to agent-flow when the work has reliable stages and audit-worthy intermediate artifacts. Move to orchestration when the task is breadth-first, decomposable, or spans distinct tool or policy domains. Reach for collaboration only when peers truly contribute independent evidence or exploration trajectories a supervisor can’t cheaply emulate. Even then, bound the collaboration with protocols, artifact contracts, and observability.

The inter-agent protocol work coming out of 2026, especially A2A, matters here because once teams do need cross-agent identity and contract boundaries, they want standardized handoff semantics, not ad-hoc message passing. The “agent” story in 2026 is no longer that teams of agents are automatically smarter. It’s that the right topology, for the right task, with the right evidence boundaries, can be worth the cost.

What pattern are you running in production right now? And more importantly, did you pick it because of task shape, or because the framework docs made it look easy? I’d genuinely like to hear which of the three you’ve shipped and what you’d do differently.