Why Your Multi-Agent System Is Costlier, Slower, and Worse Than a Single Agent

1. What Multi-Agent Actually Brings

Stripping away anthropomorphic packaging, a multi-agent system is simply multiple LLM loops, each with an independent context window, collaborating toward a shared goal. The label "expert agent" does not magically add knowledge; a Security Reviewer agent uses the same base model with a different prompt. Prompt-level specialization helps but has limited impact — often a single agent instructed to adopt a specific perspective captures most of the gain.

The real differentiator is context isolation . A child agent receives a clean context window and can devote it entirely to a sub-task: reading an entire subsystem, digesting a 400-page document, or completing an investigation with 60 tool calls. It returns only a compressed summary. The parent agent retains conclusions without the full work history. Ten child agents can collectively "read" 2 million tokens while the orchestrator's window stays light.

This yields a practical decision rule: multi-agent makes sense only when the task's working set exceeds one context window . If it fits, splitting is usually not worth it. Breadth tasks — research across many sources, multi-dimensional reviews, migrations across many files — rapidly expand the working set. Depth tasks — a tricky bug, a single document, a long reasoning chain — belong in one window.

2. Six Patterns

Production multi-agent systems fall into six topologies, each with specific applicability:

Orchestrator‑workers (the primary pattern): The lead agent decomposes the goal, writes task briefs, spawns workers (often in parallel), gives them narrower tool sets, and synthesizes their summaries. Best for research scans, multi-faceted code reviews, audits. Key challenges: writing good briefs (see §5) and effort scaling — workers must know how much effort a sub-task deserves, else a simple query may spawn 50 searches (an early Anthropic failure).

Pipeline : Agents chained sequentially (draft → critique → revise; extract → normalize → validate). Valuable when stages need different contexts, tools, or a "clean-room" second opinion (e.g., a critic that never saw the author's reasoning). If stages share the same information, a single agent doing three phases is better — each handoff loses information and adds latency.

Router / handoff : Triage at entry, then delegate to a specialized agent (billing, refunds, tech support). OpenAI Agents SDK supports this natively. The gain is often policy isolation , not context isolation: a refund agent lacks tools for other domains, enforcing security boundaries at the tool layer.

Debate / panel + judge : N agents independently solve the same problem; a judge compares and synthesizes. Costs N× reasoning tokens; the judge inherits evaluation biases needing separate calibration. Suited for high-stakes, hard-to-verify questions where inter-answer consistency is evidence (safety reviews, architecture decisions) and the cost of a confident error exceeds 4× token spend.

Blackboard / shared workspace : Coordination via artifacts (shared filesystem, task lists, plan documents) instead of messages. Mirrors "files as memory" in context engineering and real coding-agent clusters. Works when collaboration is long-lived and the artifact is the collaboration hub. Requires managing write conflicts (isolated git worktrees, explicit file ownership).

Hierarchy : Orchestrators spawning orchestrators. Occasionally needed at scale, but often recurses coordination problems. If used, depth limits and budget guards must be built in; runaway child-agent generation is the classic failure mode.

3. Cost Issues

Multi-agent multiplies token consumption far beyond intuition. Anthropic reports: a single agent ~4× chat tokens; a multi-agent system ~15×. Costs accumulate from: each worker carrying its own system prompt and tool definitions; parent-known context rediscovered by workers; summaries written, read, and re-summarized; orchestrator continuously managing the process.

This 15× overhead raises the value bar — the result must justify 15× investment, so high-value breadth tasks (research, audit, migration) qualify; daily small tasks rarely do. Parallelism doesn't eliminate latency: fan-out only reduces wall-clock before synthesis; pipelines add latency if stages weren't bottlenecks. Errors accumulate across agents — a subtle wrong summary from a worker is ingested as fact by the orchestrator. Observability (trace trees, per-branch cost aggregation) is essential to detect such issues.

An economic lever: route workers to different models. Mechanical work (formatting, extraction) to smaller models; keep the orchestrator on a frontier model. This can compress 15× toward ~6×.

4. When Not to Use Multi-Agent

Working set fits in one window — context isolation yields no benefit; team tax remains for show. Most tasks fall here, including many that look large.

Sequential dependencies — deep debugging, single-document writing, chain-of-thought analysis require step N to see steps 1..N‑1. Splitting breaks the chain; depth tasks need one window.

Shared mutable state — if two workers must touch the same files/records, they're not independent parallel units but merge conflicts with a token bill. Re-split or revert to single agent.

Unified judgment standard needed — four agents producing four writing styles stitched together often requires a synthesis pass that costs another full draft's tokens to fix the fragmentation.

On most tasks, a single frontier agent with precise tools and a compression loop is very hard to beat. Before committing to multi-agent, run a direct evaluation against the best single-agent baseline. Because multi-agent carries 15× cost, the burden of proof lies with it. Real evaluations show it loses to single-agent more often than industry hype suggests.

5. Engineering Practices When Multi-Agent Is Justified

Task brief = API . The brief the orchestrator sends to a worker is the highest-leverage interface. It must include: goal in the worker's task language; context and prior decisions the worker cannot discover; structured output format (schema-constrained); effort budget (e.g., "search 3–5 times then report"); boundaries (e.g., "do not modify files outside /billing"). Vague briefs are the top cause of rework and drift. Anthropic's post-mortems rank "teach the orchestrator to write detailed briefs" very high.

Summary = return value . Worker reports are engineering interfaces, not prose. Conclusions must be explicit; precise identifiers (paths, IDs, citations) preserved verbatim; paraphrase decay worsens across agent boundaries. Confidence and open issues explicitly marked. Full work history not returned to parent. Structured summaries contain meaning loss.

Blast-radius isolation . Parallel workers get independent workspaces (coding agents → separate git worktrees); tool sets narrowed; per-worker budgets set. Most runaway-agent post-mortems end with "later added per-worker caps." Such guards belong in initial design: max steps, max tokens, max depth.

Orchestration checkpoints . If 5 workers run and the 4th fails, resume from checkpoint, not re-run all. Durable execution patterns are high-value here because runs are longer and costlier. Partial failure must be handled: a null result from one worker triggers graceful degradation in synthesis, not error ingestion or total crash.

Trace and evaluate the whole system . The nastiest failures live between agents: briefs written poorly, summaries dropping information, synthesis ignoring a branch. Evaluation must cover seams: is decomposition sound? Do workers duplicate effort? Did synthesis actually use worker 3's output? Trace trees with per-branch cost aggregation are the most reliable diagnostic; reading traces is itself an engineering cost.

6. Decision Framework

Before building multi-agent, ask:

Does the working set exceed one context window? No → single agent, stop.

If yes, is the overflow breadth (parallelizable units) or depth (long chain)? Depth → single agent with compression and external memory.

If breadth, can units run independently without shared mutable state? No → re-split until they can, or stop.

If yes, adopt orchestrator‑workers with briefs, budgets, isolation, tracing, and evaluation. Baseline must be the current best single-agent solution. If the team system's lift doesn't exceed its cost multiplier, shut it down — no nostalgia.

Conclusion

Intelligence comes from the harness, context, tools, and evals wrapped around the model — either delivering the model's capability to the task or burning it in transit. Multi-agent makes this principle visible because architecture easily becomes theater. A row of titled agents looks like an organization and demos futuristically; but if the task lacks the one critical feature, the architecture adds no value. That feature is singular: relevant work exceeds one context window's capacity.

When the task has that feature, orchestration changes outcomes. The 90% figures are real, cluster migrations are real, context-isolation gains are real. When it doesn't, the better system remains one strong model inside a well-built harness, seeing only what the task truly demands.

When the workload exceeds one "brain's" working memory, then build a team. Otherwise, make that brain better.

Code example

来源：DeepHub IMBA
本文
约5000字
，建议阅读
8
分钟
这一篇要把多智能体讲清楚：有哪些模式，真正起作用的机制是什么，成本为什么会迅速上升，以及工程上应该怎样做选择。