你手里有了材料（模型选好了）、工具（框架选好了）、也知道了基本工艺（Loop、Harness 都懂了）。但真正住人的房子和路边的简易棚，差距在哪？在于设计图——承重墙怎么布局、管线怎么走、逃生通道在哪里。Agent 也是一样：同样的模型、同样的框架，用不同的架构模式来设计，出来的效果天差地别。今天我们来聊聊那些经过实战验证的 Agent 设计模式——它们是你从”demo 能跑”到”生产能用”的关键。

这是「小白讲 AI」系列的第 18 篇。上一篇我们对比了五大 Agent 框架，选好了”工具”。这一篇我们往上走一层：不管你用什么框架，这些跨框架通用的设计模式都是你需要掌握的。

一、先搞清楚：你需要几个 Agent？

在选择具体的设计模式之前，第一个问题是：你的场景需要一个 Agent 还是多个 Agent？

这个问题很重要，因为多 Agent 架构的复杂度远高于单 Agent。不要因为”多 Agent 听起来很酷”就上多 Agent——很多场景一个 Agent 就够了。

什么时候一个 Agent 就够？

  • 任务类型单一（比如”回答用户问题”）
  • 工具数量有限（10 个以内）
  • 不需要不同的”专业视角”
  • 延迟敏感（多 Agent 之间的通信会增加延迟）

什么时候需要多 Agent？

  • 任务涉及多个专业领域（比如一个负责写代码、一个负责做测试、一个负责做审查）
  • 需要制衡机制（比如一个 Agent 生成方案、另一个 Agent 审查方案）
  • 工作量大，可以并行处理（比如同时分析 5 个竞品）
  • 需要不同 Agent 有不同的工具权限和安全边界

好了，理解了这个前提后，我们分别来看单 Agent 和多 Agent 的设计模式。

二、单 Agent 模式

模式一：Router（路由器）

核心思路：一个 Agent 接收所有请求，但它自己不干活——它只负责判断请求类型，然后把请求”路由”到对应的处理逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
用户输入
    │
    ▼
┌──────────┐
│  Router  │ ← 判断这是什么类型的请求
│  Agent   │
└────┬─────┘
     │
 ┌───┼───┐
 ▼   ▼   ▼
代码  搜索  闲聊
任务  任务  任务

适合场景：入口统一但处理逻辑差异大的场景。比如一个客服系统——用户可能问产品问题、投诉、咨询退货流程，每种请求的处理方式完全不同。

优点：结构清晰、职责单一、容易维护。
缺点：Router 本身的分类准确度至关重要——如果分错了类，后面的处理就全错了。

模式二：Chain（链式）

核心思路：把任务拆成多个步骤，每步的输出是下一步的输入，像一条流水线。

1
用户输入 → 步骤1（提取关键词） → 步骤2（搜索信息） → 步骤3（整理结论） → 最终输出

适合场景：处理流程固定、步骤明确的任务。比如”翻译一篇文章”——先提取段落 → 逐段翻译 → 校对 → 合并。

优点：简单可靠、容易调试（知道是哪一步出了问题）。
缺点：灵活性差——如果中间某步的结果需要回到前面的步骤重新处理，Chain 就不好表达了。

模式三：Autonomous（自主循环）

核心思路：Agent 自主决定每一步做什么，持续循环直到目标达成。这就是第 15 篇讲的 Loop 工程的直接实现。

1
2
3
4
5
6
7
       ┌─────────────────────────┐
       │                         │
       ▼                         │
Plan → Execute → Observe → Decide ──┘
                              │
                              ▼ (目标达成)
                            输出

适合场景：目标明确但路径不确定的任务。比如”帮我修复这个 bug”——Agent 需要先理解 bug、查代码、试修复方案、跑测试、根据结果调整……每次的步骤可能都不一样。

优点：灵活性最高，能应对复杂、不确定的任务。
缺点：最难控制——需要配合第 14 篇讲的 Bounded Execution 来防止失控。

三、多 Agent 模式

模式一：Supervisor（主管模式）

核心思路：一个”Boss” Agent 负责全局规划和任务分配，多个”Worker” Agent 负责执行具体任务。

1
2
3
4
5
6
7
8
9
10
      ┌─────────────┐
      │  Supervisor │ ← 接收任务、拆分、分配、汇总
      │  (Boss)     │
      └──────┬──────┘
     ┌───────┼───────┐
     ▼       ▼       ▼
┌────────┐┌────────┐┌────────┐
│Worker A││Worker B││Worker C│
│(搜索)  ││(分析)  ││(写报告)│
└────────┘└────────┘└────────┘

Supervisor 接收到一个大任务后：

  1. 拆分成子任务
  2. 分配给合适的 Worker
  3. 收集 Worker 的结果
  4. 判断是否需要补充任务
  5. 汇总最终输出

适合场景：任务可以明确拆分为子任务的场景。比如”撰写一份市场调研报告”——搜索数据（Worker A）→ 分析趋势（Worker B）→ 撰写报告（Worker C）。

优点：职责清晰、容易扩展（加一个 Worker 就多一种能力）。
缺点：Supervisor 是单点瓶颈——如果它的规划能力不行，整个系统都会出问题。

模式二：Peer-to-Peer（对等模式）

核心思路：没有”Boss”，所有 Agent 地位平等，直接互相通信和协作。

1
2
3
4
5
6
7
8
9
10
┌──────────┐
│ Agent A  │◄──────────►┌──────────┐
│ (研究员) │            │ Agent B  │
└──────┬───┘            │ (编辑)   │
       │                └─────┬────┘
       │                      │
       └───────►┌──────────┐◄─┘
                │ Agent C  │
                │ (审稿人) │
                └──────────┘

Agent A 做完研究后直接发给 Agent B 编辑，Agent B 编辑后发给 Agent C 审稿，Agent C 审完后如果有问题发回给 Agent A 修改……

适合场景：工作流不固定、需要灵活协作的场景。

优点：去中心化、灵活性高。
缺点：协调困难——没有一个中央控制者，Agent 之间可能出现”你等我、我等你”的死锁，或者”两个 Agent 同时在做同一件事”的冲突。

模式三：Hierarchical（层级模式）

核心思路：多层管理结构——顶层 Manager 管中层 Team Lead，Team Lead 管底层 Worker。

1
2
3
4
5
6
7
8
9
10
11
12
         ┌────────────┐
         │  Manager   │
         └─────┬──────┘
       ┌───────┴───────┐
       ▼               ▼
 ┌──────────┐    ┌──────────┐
 │ Team Lead│    │ Team Lead│
 │ (前端组) │    │ (后端组) │
 └────┬─────┘    └────┬─────┘
  ┌───┴───┐       ┌───┴───┐
  ▼       ▼       ▼       ▼
Worker  Worker  Worker  Worker

适合场景：非常复杂的大型任务，需要分层管理。

优点：能处理高复杂度任务、职责层次分明。
缺点：系统复杂度高、层间通信开销大、需要仔细设计每一层的职责和接口。

四、2026 年三种生产就绪的新兴模式

除了上面的经典模式，2026 年有三种新兴的模式已经在生产环境中得到验证。

新兴模式一：Context Engineering Pattern（上下文工程模式）

第 13 篇讲的 Context Engineering 在这里变成了一种架构模式：在每次模型调用前，动态优化上下文窗口的内容。

1
2
3
4
5
6
7
8
9
10
11
12
13
# 伪代码示例
def prepare_context(task, history, tools):
    # 1. 预算分配
    budget = {"system": 2000, "history": 4000, "retrieval": 3000}
    
    # 2. 历史压缩
    compressed_history = summarize_if_over(history, budget["history"])
    
    # 3. 动态检索
    relevant_docs = retrieve_if_needed(task, budget["retrieval"])
    
    # 4. 组装
    return assemble(system_prompt, compressed_history, relevant_docs, task)

这不是一个新概念，但把它提升为一种系统化的架构模式——为上下文管理定义标准化的接口和策略——是 2026 年的新趋势。

新兴模式二：Bounded Execution / Circuit Breaker（有界执行 / 熔断器）

第 14 篇详细讲过。这里补充一个在架构层面的关键点：每一层 Agent 都需要独立的熔断机制。

1
2
3
4
5
Supervisor（最多 50 步）
    │
    ├─ Worker A（最多 15 步，最多 5 次工具调用）
    ├─ Worker B（最多 15 步，最多 5 次工具调用）
    └─ Worker C（最多 15 步，最多 5 次工具调用）

如果只在最外层设了熔断，一个 Worker 就能”吃掉”大部分步数预算。独立熔断确保每个 Worker 有自己的资源上限。

新兴模式三：Guardrail Layering（分层护栏）

第 14 篇已经详细讲过四层护栏。在架构层面，关键的补充是：护栏配置应该与业务逻辑解耦。

1
2
3
4
5
6
7
8
9
10
11
12
# 好的设计：护栏作为独立的中间件
agent = Agent(
    model="claude-4-sonnet",
    tools=[search, file_ops],
    guardrails=[
        InputFilter(block_injection=True),
        ToolCallGuard(require_confirmation=["delete_file"]),
        OutputFilter(content_safety=True),
    ]
)

# 而不是：把安全检查硬编码在业务逻辑里

把护栏设计成可插拔的中间件，意味着你可以为不同的场景配置不同的护栏组合——低风险场景用轻量护栏（快），高风险场景用重度护栏（安全）。

五、记忆架构设计

记忆是 Agent 架构中一个越来越重要的组件。2026 年的最佳实践是三级记忆架构：

第一级：Working Memory（工作记忆）

就是当前对话的上下文。容量有限（受上下文窗口约束），但访问速度最快。

1
类比：你工作时摊在桌面上的文件——随时能看到，但桌子空间有限。

第二级：Session Memory（会话记忆）

一次完整交互过程中的累积信息。比如一个持续 30 分钟的对话中，Agent 记住了你之前提到的偏好和上下文。

1
类比：你今天会议中记的笔记——这次会议结束后可以归档，但会议进行中随时需要翻看。

第三级：Long-term Memory（长期记忆）

跨会话的持久化信息。存储在向量数据库或其他外部存储中，通过 RAG 检索访问。

1
类比：你的文件柜——存放着过去几个月/几年的项目资料，需要时去翻找。

2026 年，记忆已经有了专门的基准测试套件（LoCoMo、LongMemEval、BEAM），说明行业开始严肃对待记忆的质量。在设计 Agent 架构时，记忆方案不再是”附带考虑一下”的问题，而是需要像选模型、选框架一样认真评估的核心决策。

六、错误处理模式

Agent 在生产环境中最大的挑战之一是错误处理。来看几个常用的模式：

模式一：Retry with Backoff（指数退避重试）

1
2
3
4
第 1 次失败 → 等 1 秒重试
第 2 次失败 → 等 2 秒重试
第 3 次失败 → 等 4 秒重试
第 4 次失败 → 放弃，转入降级方案

为什么是指数退避而不是固定间隔？ 因为连续快速重试可能加剧对方服务的压力，导致所有请求都被拒绝。越重试间隔越长，给服务端喘息的时间。

模式二：Fallback to Simpler Model（降级到更简单的模型）

1
2
尝试用 Claude Opus 处理 → 超时/报错
→ 降级到 Claude Sonnet 处理 → 成功

更大的模型通常更聪明但更慢、更贵、更容易超时。降级到小模型虽然质量可能差一点，但”给一个还可以的答案”远好于”什么都没有”。

模式三：Human Escalation（人类升级）

当 Agent 连续失败或遇到低置信度情况时，自动将任务升级给人类处理。

1
2
3
4
Agent 连续 3 次修改代码但测试仍不通过
→ 自动生成问题摘要
→ 发送通知给人类开发者
→ 暂停等待人类介入

Rate Limit 应对策略

前面多次提到，60% 的 LLM 调用错误来自速率限制。这在多 Agent 架构中尤其严重——一个 Supervisor 同时派出 5 个 Worker，每个 Worker 每步都调用 LLM，API 调用量瞬间暴涨。

应对策略：

  1. 请求队列：所有 LLM 调用统一走一个队列，按照速率限制控制发送频率
  2. 错峰调度：不要同时启动所有 Worker，逐个启动并错开调用时间
  3. Token 预算管理：为每个 Worker 分配 Token 预算，超预算自动降级或暂停

七、可观测性设计

最后一个关键的架构要素：你得知道 Agent 在干什么。

一个在生产环境运行的 Agent 就像一个在后台自主工作的员工——你不可能每秒都盯着它，但你需要随时能了解它的工作状态、追溯它做了什么、分析它为什么在某个地方出了问题。

Traces（追踪）

记录 Agent 的每一步操作，形成一条完整的执行链：

1
2
3
4
5
6
7
8
9
10
11
Trace #12345
├─ [13:00:01] 接收用户请求："帮我分析竞品"
├─ [13:00:02] 规划：拆分为 3 个子任务
├─ [13:00:03] 调用工具：web_search("竞品 A 产品特点")
│   └─ 返回：5 条结果，耗时 1.2s
├─ [13:00:05] 调用工具：web_search("竞品 B 产品特点")
│   └─ 错误：超时，重试中...
│   └─ 重试成功，返回 4 条结果，耗时 3.1s
├─ [13:00:09] 反思：已收集到两家竞品数据，继续
├─ ...
└─ [13:02:30] 输出最终分析报告

Spans（跨度）

每个 Trace 由多个 Span 组成。Span 是一个有起止时间的操作单元——一次工具调用、一次模型推理、一次数据检索。

Span 的价值在于性能分析：你可以快速看出是哪一步最慢、哪个工具最容易出错。

Metrics（指标）

聚合的统计数据，用于监控整体健康状况：

  • 平均完成时间
  • 成功率
  • 平均步数
  • Token 消耗
  • 错误类型分布

这三者（Traces + Spans + Metrics）构成了可观测性的”三大支柱”。缺了任何一个，你的 Agent 在生产环境中就是一个”黑箱”——它在干什么、为什么慢、为什么错，你一概不知。

八、选择设计模式的实用指南

最后给一张实用的选择指南：

你的场景 推荐模式
简单问答/客服入口 Router
固定流程的数据处理 Chain
复杂、不确定的探索性任务 Autonomous
可拆分的多专业任务 Supervisor
需要”生成 + 审查”的制衡 Supervisor（或双 Agent 对等）
超大规模复杂项目 Hierarchical
所有生产场景 + Context Engineering + Bounded Execution + Guardrail Layering

最后一行是重点：无论你选了什么基本模式，三种新兴的生产级模式（Context Engineering、Bounded Execution、Guardrail Layering）都应该叠加上去。

总结

让我们回顾一下今天的内容：

  • 先问自己需要几个 Agent——不要因为”酷”就上多 Agent。
  • 单 Agent 三种模式：Router（分类路由）、Chain（流水线）、Autonomous（自主循环）。
  • 多 Agent 三种模式：Supervisor（主管制）、Peer-to-Peer（对等协作）、Hierarchical（层级管理）。
  • 三种 2026 生产就绪模式：Context Engineering Pattern、Bounded Execution、Guardrail Layering——无论基本模式是什么，都该叠加。
  • 三级记忆架构：Working Memory → Session Memory → Long-term Memory。
  • 错误处理：Retry with Backoff、Fallback to Simpler Model、Human Escalation、Rate Limit 应对。
  • 可观测性三大支柱：Traces + Spans + Metrics，让 Agent 不再是”黑箱”。

设计模式不是教条——它们是前人踩坑后总结的经验。理解它们、灵活组合它们，你就能把 Agent 从 demo 带入生产。

延伸阅读

  1. Building effective agents - Anthropic —— Anthropic 的 Agent 架构设计指南，覆盖了多种模式的权衡分析。
  2. Multi-Agent AI Systems - Augment Code —— 2026 年多 Agent 系统的深度指南，包含具体的代码示例。
  3. State of AI Agent Memory 2026 - Mem0 —— 记忆架构的基准测试和最新趋势。

小白讲 AI 系列第 18 篇完。理论够了，下一篇我们终于要动手了！第 19 篇将从零开始，用 Python + Claude API 手写一个能自主搜索、整理信息的研究助手 Agent。前面 6 篇讲的概念，每一个都会在代码中找到对应——让我们开始造！