15种AI Agent设计模式：从单智能体到事件驱动，生产级系统的选择指南

Every team building AI agents hits the same wall.

You start with one prompt and a few tools.

It works.

Then requirements grow. More edge cases. More teams. More risk.

Suddenly your "agent" is a 3,000-word system prompt trying to do five jobs at once.

The fix isn't more prompt engineering.

It's picking the right pattern.

Before you pick a pattern

Not every task needs an agent.

A task justifies an agent when:

→ A single model call can't produce a reliable result

→ The model must choose between tools or data sources at runtime

→ The task needs planning, validation, or iterative refinement

→ The workflow has real uncertainty that can't be hardcoded

A task usually does NOT need an agent when the input-to-output path is predictable.

Summarization. Classification. Simple extraction. Templated generation.

These are faster, cheaper, and more reliable as direct model calls.

Wrapping them in an agent just adds latency and failure points for zero benefit.

PATTERN 1 — Single Agent

The simplest and most common starting point.

One model. One system prompt. A bounded set of tools.

The model decides which tool to call, observes the result, and keeps going until it has enough to answer.

Real example: A customer support agent that looks up order status, checks shipping, and creates a ticket if it can't resolve the issue — all with 2-3 tools and one clear job.

Use it when: the task is well-defined, the tool set is small, and one agent can hold the full context without getting confused.

It breaks when: you keep adding tools and the system prompt grows past a page. That's the signal you need a different pattern — not a longer prompt.

PATTERN 2 — Multi-Agent Sequential

Specialized agents run in a fixed order. Each one's output feeds the next one's input.

Real example: A contract review pipeline — one agent extracts obligations, the next identifies risks, a third drafts the summary for procurement. The sequence never changes.

Use it when: the workflow has clear, repeatable stages and each stage produces exactly what the next one needs.

It breaks when: the order actually needs to vary based on what's found mid-process. Sequential pipelines assume the path is fixed — if it isn't, you need something more dynamic.

PATTERN 3 — Multi-Agent Parallel

Independent subtasks run simultaneously, then get combined into one view.

Real example: A 2am production incident. Three agents investigate logs, metrics, and recent deployments at the same time — not one after another — because every minute matters during an outage.

Use it when: the subtasks are genuinely independent and speed matters.

It breaks when: tasks actually depend on each other's results. Forcing dependent work into parallel execution just creates race conditions and incomplete context.

PATTERN 4 — Loop

Repeat a sequence of steps until an exit condition is met.

Real example: A data cleaning agent that profiles messy CSV data, proposes a cleaning plan, checks if it passes quality standards, and retries if it doesn't — up to a capped number of rounds.

Use it when: the task needs multiple attempts and you can define a clear, checkable stopping condition.

It breaks when: there's no reliable exit condition. Without one, you get runaway costs and a system that might never terminate.

PATTERN 5 — Review and Critique

A judge agent reviews another agent's output, critiques it, and gives specific actionable feedback.

Real example: A generated report gets reviewed by a separate "critic" agent that flags weak claims, missing evidence, or unclear sections before it ever reaches a human.

Use it when: quality matters more than speed and you want a second opinion baked into the system, not bolted on after.

It breaks when: the critic agent uses the same blind spots as the generator. A reviewer trained on similar assumptions won't catch the same mistakes.

PATTERN 6 — Iterative Refinement

A feedback loop with a quality score threshold. The generator keeps refining until it crosses the bar.

Real example: A marketing copy generator that scores its own draft against brand guidelines, and keeps rewriting until it hits a minimum quality score — not just one pass-fail check, but graded improvement.

Use it when: output quality is genuinely variable and "good enough" has a measurable threshold.

It breaks when: the scoring function is vague or gameable. If the model can inflate its own score without real improvement, the loop just burns tokens.

PATTERN 7 — Coordinator

A central routing agent directs requests to specialized agents based on what's actually being asked.

Real example: Support tickets get routed to billing, technical, account, shipping, or fraud specialists — each with narrow context instead of one agent trying to know everything.

Use it when: you have genuinely different request types that need different context, tools, or decision logic.

It breaks when: the routing itself becomes ambiguous. If requests don't cleanly fall into one category, the coordinator becomes a new bottleneck and source of misrouting.

PATTERN 8 — Hierarchical Task Decomposition

A root agent breaks a complex goal into smaller subgoals, delegates them to specialist workers, then synthesizes everything into one answer.

Real example: "Which 3 countries should we expand into next year?" gets broken into competitive analysis, regulatory research, logistics feasibility, and market sizing — each handled by a different specialist, then combined.

Use it when: the problem is too broad for one reasoning pass but breaks cleanly into independent areas of expertise.

It breaks when: the subgoals aren't actually independent. If workstreams need to inform each other in real time, decomposing them upfront loses that interaction.

PATTERN 9 — Swarm

Multiple specialist agents contribute to a shared discussion, challenge each other's assumptions, and a facilitator synthesizes a final recommendation.

Real example: Should the company launch a subscription tier? Research, engineering, finance, and support agents each argue their perspective across multiple rounds before a facilitator weighs the trade-offs.

Use it when: there's no single "correct" answer — you need a well-reasoned decision shaped by genuinely competing viewpoints.

It breaks when: you need a fast, deterministic answer. Swarms are deliberately slow and exploratory — wrong tool if you need speed.

PATTERN 10 — ReAct (Reason and Act)

The agent alternates between reasoning and action: decide what to investigate, call a tool, observe the result, decide if there's enough evidence yet.

Real example: "The queue processor seems stuck" — the agent searches docs, checks service health, correlates findings, and only then suggests a fix. The investigation path isn't predefined; it depends on what it finds along the way.

Use it when: the path to the answer genuinely can't be planned upfront — it depends on what each step reveals.

It breaks when: investigations run long without converging. Always cap the number of reasoning-action cycles, or you risk infinite exploration.

PATTERN 11 — Human-in-the-Loop

The agent investigates and recommends, but a human makes the final call on anything risky or ambiguous.

Real example: Refund approvals — low-risk, clear-cut cases get automated. High amounts, fraud signals, or policy exceptions pause for human review before anything is finalized.

Use it when: the decision carries real financial, legal, or reputational risk and full automation isn't acceptable yet.

It breaks when: you treat this as just a UI feature instead of an architectural one. You need durable state, reviewer assignment, timeout handling, and escalation paths — not just a "pause" button.

PATTERN 12 — Plan-and-Execute

A planner agent creates a full structured plan upfront — reviewable and modifiable — before any action is taken. An executor then runs through the steps.

Real example: "Resize the worker fleet from 10 to 20 instances, verify the queue drains, update the runbook." The full plan is visible before execution starts, unlike ReAct where the path emerges step by step.

Use it when: you want the plan to be reviewable or approvable before any action happens — important for operations with real consequences.

It breaks when: the environment changes faster than the plan can execute. A stale plan executed blindly is worse than no plan at all.

PATTERN 13 — Reflexion

The agent evaluates its own failures, reflects on what went wrong, and carries that memory into the next attempt.

Real example: A code generation agent writes a script, it fails at runtime, the agent analyzes the actual error, records what to fix, and retries — getting smarter with each attempt instead of repeating the same mistake.

Use it when: failures are informative and self-correction genuinely improves the next attempt.

It breaks when: the failure modes are random or unrelated to each other. Reflexion only helps when there's a real pattern to learn from.

PATTERN 14 — Custom Logic

A hybrid: deterministic code handles the rules that must never be wrong, while the model handles judgment, drafting, and exception handling.

Real example: A refund workflow where purchase verification and fraud checks run as hard deterministic rules — never delegated to the model — while drafting the customer response and routing recommendations stay agentic.

Use it when: the workflow has real branching logic with legal or financial consequences, and you need to be precise about what's deterministic versus what's flexible.

It breaks when: teams blur the line and let the model make decisions that should be hardcoded rules. Eligibility, permissions, and money movement should never be the model's call alone.

PATTERN 15 — Event-Driven Agent

The agent doesn't wait to be asked. It subscribes to an event stream and acts the moment a condition is triggered.

Real example: A fraud detection agent that reacts the instant a suspicious transaction event fires — not when a support ticket eventually surfaces it, by which point the damage is done.

Use it when: timing matters more than anything else, and waiting for a human request means missing the window to act.

It breaks when: the triggering conditions are poorly defined. A noisy event stream with vague triggers turns into a system constantly crying wolf — or worse, missing the real signal.

Pattern selection — match the uncertainty, not the hype

The right pattern matches the shape of the uncertainty in your work:

→ Uncertain which tool to use → Single Agent or ReAct → Uncertain where to route → Coordinator → Uncertain about quality → Review & Critique or Iterative Refinement → Uncertain execution path → Plan-and-Execute or ReAct → Uncertain how to self-correct → Reflexion or Loop → Uncertain about business risk → Human-in-the-Loop or Custom Logic → Uncertain problem structure → Hierarchical Decomposition or Swarm → Can't wait for a request → Event-Driven Agent

A swarm is not more advanced than a single agent if the task only needs one reliable tool call.

Plan-and-Execute is not an upgrade from ReAct if your plan goes stale by step three.

The most reliable production systems are not the most autonomous ones.

They put autonomy exactly where it creates value — and constrain it everywhere else.

10 rules for production agentic systems

1. Start with the smallest pattern that works. A single agent with clean tool contracts beats a multi-agent system with weak ones.
2. Write tool descriptions like contracts. The model only knows what the tool does from the description — not from your intent.
3. Cap iterations, tool calls, and spend per request. An agent without budget limits is a liability waiting to show up in a bill.
4. Log the full action trace. Tool calls, arguments, outputs, final decision. Without this, incident investigation is guesswork.
5. Keep irreversible actions behind deterministic checks or human approval. Never let a model be the only gate before a money movement or production change.
6. Evaluate with real failure cases, not just happy paths. Happy-path correctness is a prototype. Edge-case correctness is a product.
7. Separate prompts by responsibility before the system prompt becomes unreadable. "But don't do X when Y" creeping into your prompt means the agent is doing two jobs.
8. Treat multi-agent systems as distributed systems. Partial failure, timeouts, retries, and observability are not optional.
9. Model review is not a substitute for testing. Use judges to improve quality. Use tests and permission checks to enforce correctness.
10. Prefer the simpler pattern — not because simple is always better, but because the complexity budget you save can be spent on better tools, better prompts, better evaluation.

Most teams don't fail because they picked the wrong pattern.

They fail because they never asked which uncertainty they were actually solving for.

Pick the pattern. Match the shape of the problem. Don't add autonomy where it doesn't earn its place.