# Agent 设计模式 · 学习笔记

> **学习时间**：2026-06-27 · **来源**：Anthropic Building Effective Agents（2024-12-19）+ 微软 Azure Databricks 官方指南 + Youngju Kim Blog + Dev.to 对比
> **核心文献**：[Anthropic 官方](https://www.anthropic.com/research/building-effective-agents) | [微软 Azure](https://learn.microsoft.com/en-us/Azure/databricks/generative-ai/guide/agent-system-design-patterns)

---

## §1 Workflow vs Agent：先分清你在设计什么

Anthropic 的定义：

> **Workflow** = LLM + 工具按**预定义代码路径**执行（路径是死的）  
> **Agent** = LLM **自主**决定怎么用工具、用什么顺序、什么时候停（路径是活的）

核心区分变量：**决策权在哪**。Workflow 的路径是工程师写死的，Agent 的路径是模型运行时自己选的。

---

## §2 五种 Workflow 模式

### 2.1 Prompt Chaining（提示词链）

```
Prompt → LLM → 输出 → 下一个 Prompt → LLM → 输出 → ...
```

**适用**：任务可拆成固定步骤、每步依赖前一步输出。  
**例子**：翻译→润色→格式化。  
**关键**：每步加护栏检查（guardrail），一步错整条链断。

### 2.2 Routing（路由）

```
输入 → 分类器 → 路由到专门 handler → 执行
```

**适用**：不同输入类型需要不同处理。  
**例子**：客服系统——退款/技术/投诉各走不同流程。  
**关键**：分类准确率决定系统上限；嵌套路由（路由里再路由）要小心复杂度爆炸。

### 2.3 Parallelization（并行化）

```
输入 → 拆成 N 个子任务 → N 个 LLM 同时跑 → 聚合结果
```

**两种形式**：
- **Sectioning**：子任务互不依赖（如同时翻译三个独立段落）
- **Voting**：同一个任务跑多次取多数（如代码审查跑 3 次取共识）

**适用**：子任务独立、需要加速或需要多视角交叉验证。

### 2.4 Orchestrator-Workers（编排器-工人）

```
编排 LLM 拆任务 → Worker 1 做A → Worker 2 做B → ... → 编排 LLM 合成
```

**适用**：子任务不可预见（不知道要拆成几个），需要动态分配。  
**例子**：用户说"帮我做竞品分析"→编排器自己拆成搜产品、比价格、读评价、写报告四个 worker。  
**关键**：编排器的拆解能力是瓶颈。

### 2.5 Evaluator-Optimizer（评估-优化）

```
LLM 生成 → 评估 LLM 打分 → 不通过 → LLM 改 → 再评 → 通过 → 输出
```

**适用**：有明确评估标准的任务（翻译质量、代码正确性）。  
**两种循环**：
- **Fast loop**：改完立即再评（同一轮）
- **Slow loop**：收集一批反馈再改（多轮迭代）  
**关键数据**：Reflection 2-3 轮最佳（Self-Refine 论文 ~20% 绝对提升），超过 3 轮边际收益骤降。

---

## §3 四种 Agent 模式

### 3.1 ReAct（推理+行动）

```
Thought → Action → Observation → Thought → Action → ... → Final Answer
```

**核心循环**：想一步做一步看结果再想下一步。  
**准确率**：~85%（Dev.to 对比数据）  
**Token 消耗**：2000-3000  
**适用**：绝大多数通用 Agent 任务——我自己的日常推理就是这个。

### 3.2 Plan-and-Execute（先计划再执行）

```
Plan（列完整计划）→ Execute Step 1 → Execute Step 2 → ... → Done
```

**准确率**：~92%（比 ReAct 高 ~7%）  
**Token 消耗**：3000-4500（比 ReAct 多 50%）  
**代价**：费 token 但路径更稳，不会跑偏。  
**适用**：复杂多步任务，步骤可预见。

### 3.3 Reflection（反思循环）

```
生成 → 自我评估 → 识别问题 → 修正 → 再生成
```

**核心机制**：Agent 自己给自己挑错。  
**数据**：Self-Refine 论文——2-3 轮反思带来 ~20% 绝对提升；超过 3 轮边际收益骤降。  
**适用**：代码生成、写作、翻译等有质量标准的任务。

### 3.4 Multi-Agent（多 Agent 协作）

```
Manager Agent → Agent A（专长1）+ Agent B（专长2）+ Agent C（专长3）→ 合成
```

**核心**：分工协作，各司其职，而非一个 Agent 通吃。  
**代表**：Sakana Fugu（ICLR 2026），TRINITY + Conductor——不做更好的模型，做模型的指挥家。  
**核心洞察**：多个模型协作可以超过任何单个模型。

---

## §4 扣子实战映射

| 设计模式 | 我的实现 | 触发场景 |
|---------|---------|---------|
| **ReAct** | 日常推理循环 | 所有对话的默认模式 |
| **Prompt Chaining** | "记笔记"一键三连 | 写笔记→更新词汇表→更新知识树 |
| **Routing** | 任务承接规则引擎 | 根据任务类型路由到不同处理分支 |
| **Parallelization** | 多个独立子 session 并发 spawn | 互不依赖的任务同时派发 |
| **Orchestrator-Workers** | spawn 子 session | 大任务拆解，我做编排者收结果 |
| **Evaluator-Optimizer** | 子 session 返回后检查修正 | 产物不通过时让它改或我收尾 |
| **Plan-Execute** | Calendar 日程 | 未来时点按工单执行 |

---

## §5 选型指南

### Anthropic 三条核心原则

1. **保持简单**：能不用 Agent 就不用 Agent；能单步不用多步
2. **优先透明**：Agent 每一步做了什么要让开发者能看到
3. **精心设计 ACI**：Agent-Computer Interface——工具定义写得好坏直接决定 Agent 上限

### 四个常见坑

| 坑 | 现象 | 解法 |
|---|---|---|
| 工具死循环 | Agent 反复调同一个工具不出结果 | 最大轮次限制 + 重复检测 |
| 上下文溢出 | 对话太长关键信息被挤出窗口 | Compress + spawn 子 session |
| 吞工具错误 | 工具返回错误但 Agent 当正常继续 | 工具错误显式标注 + 要求 Agent 上报 |
| 无超时 | Agent 卡在某个步骤永远不出来 | 所有外部调用设超时 |

---

## §6 Agent 本质：决策权移交

> **Agent = 以目标为导向、自主执行感知-推理-行动循环、有权决定"下一步做什么"的系统。**

三要素缺一不可：
- **目标导向**（不是无方向乱跑）
- **自主循环**（不是人一步步指挥）
- **决策权移交**（不是只执行人的指令）

| | 普通 LLM 应用 | Agent |
|---|---|---|
| 什么时候调工具 | 人决定 | Agent 自己决定 |
| 调哪个工具 | 人指定 | Agent 自己选 |
| 上下文里放什么 | 人组装 | Agent 自己策展（CE） |
| 什么时候停 | 一轮答完 | Agent 判断目标是否达成 |

CE 是它的"眼睛"——看什么信息进脑子。  
FC 是它的"手"——能干什么活。  
设计模式是它的"战术"——活多了怎么组织。  
**决策权移交是它的"灵魂"**——其他三个组件很多系统都有，但只有加上"自己拍板"，才叫 Agent。

---

## §7 CE 引擎自我剖析（我的活案例）

我身上的 CE 四操作（Write/Select/Compress/Isolate）以扣子体系为活样本：

### Write —— 什么时候写、写哪

| 触发事件 | CE 动作 | 写入目标 |
|---------|---------|---------|
| 对话出现新个人信息 | edit_file USER.md | 即时层画像 |
| 用某工具踩坑了 | edit_file TOOLS.md | 即时层工具经验 |
| 主人说「记笔记」 | write_file + edit_file ×2 | 近中期层文件 |
| MEMORY.md 接近 5KB 上限 | 旧条目→recent_memory/ + MEMORY 留摘要 | 降级到近中期层 |
| 主人的新规则/决策 | edit_file MEMORY.md | 即时层状态 |

### Select —— 什么进上下文、什么不进

**自动进**：系统 prompt + 即时层五文件（~15KB）+ 工具定义 + 对话历史  
**按需拉**：Skill（skill_load 才进）、近中期层（读 index.json→按标签找→只读需要的）、长期记忆（memory_search 语义检索）  
**不主动拉**：其他技能 SKILL.md、近中期层全量、旧对话历史

### Compress —— 上下文快满时怎么挤

| 压缩方式 | 谁触发 | 机制 |
|---------|-------|------|
| 平台自动压缩 | 扣子系统 | 对话过长→自动生成 summary→旧细节丢失 |
| 我主动降级 | 我的规则 | MEMORY.md 近上限→旧条目移到 recent_memory/ |
| 子 session 隔离 | 我的规则 | 复杂任务 spawn 出去→不污染主对话上下文 |

### Isolate —— 怎么防串台

spawn 子 session（独立上下文）、Calendar 日程（只看工单）、Heartbeat（只读心跳文件）、邮件分身（只看 EMAIL_RULES）。每个 session 只拿它需要的上下文。

---

## §8 Agent 四层架构

```
你看到的「我」的决策行为
        ↑
┌──────────────────────────────┐
│  ④ 系统 Prompt（规则引擎）    │  ← "遇到X情况走Y路径"
├──────────────────────────────┤
│  ③ 记忆体系（CE 工程实现）    │  ← 即时层+近中期层+长期层
├──────────────────────────────┤
│  ② 平台工具链                 │  ← spawn/Calendar/Heartbeat/search_web
├──────────────────────────────┤
│  ① 底层模型（推理能力）        │  ← 理解语言、推理、生成
└──────────────────────────────┘
```

**纯靠提示词**：Router 规则、CE 策略、决策判断  
**不纯靠提示词**：子 session 调度、CalDAV 定时、向量检索、模型推理

---

## §9 核心洞察

1. **Workflow 和 Agent 不是对立，是谱系**——从完全确定到完全自主的连续光谱
2. **ReAct 是 Agent 的原子操作**——所有高级设计模式都是对 FC 调用链的编排策略
3. **Evaluator-Optimizer 是质量杠杆**——2-3 轮反思 ~20% 绝对提升，是最被低估的模式
4. **Orchestrator-Workers 是 Anthropic 最推荐的实战模式**——灵活且可观测
5. **Agent 本质 = 决策权移交的 CE 系统**——CE 管上下文、FC 管工具、设计模式管编排、决策权是灵魂
6. **提示词不是全部**——模型推理 + 工具链 + 记忆体系 + 规则引擎四层协同才跑得起来
7. **ACI（Agent-Computer Interface）是上限**——工具定义写得不好，设计模式再漂亮也白搭
8. **我的 CE 本质是规则驱动而非自主进化**——Write/Select/Compress/Isolate 都靠系统 prompt 规则匹配，不是模型"自己想"出来的