Agentic AI 架构入门（七）：十大设计模式全解（从 Tool Use 到 HITL）

课程：《Agentic AI Architectures with Patterns, Frameworks and MCP》笔记整理（第 292–394 页）

---

1. Agentic 设计原则（四大支柱）

1.1 为什么学设计模式？

• 已经掌握「工具」（how）——现在学「蓝图」（what & why）
• 本节 = Agentic AI 的「四人帮（Gang of Four）」
• Prompt Engineering 是战术（为单个任务雕琢完美指令，脆弱、新模型就崩）；Agentic Architecture 是战略（设计可靠解决问题的组件系统）
• 框架是工具（How）：具体的代码库（LangChain、MAF）——锤子锯子电动工具
• 模式是蓝图（What & Why）：可复用的概念方案——「自纠正系统」或「委派系统」的架构蓝图
• 关键洞察：模式与框架无关——「Reflection 模式」用 LangChain、MAF 或纯 Python 都能实现

1.2 模式目录路线图

• Part 1 基础：设计原则
• Part 2 核心单 Agent 模式：Tool Use / Planning / Reflection / ReAct
• Part 3 多智能体模式：Router & Specialist / Handoff / Group Chat / Swarm
• Part 4 控制与安全：HITL / Ejection

1.3 四大设计原则（Agent 的「物理定律」）

原则	概念	架构含义
1. Goal-Directed 目标驱动	由目的定义而非任务：指令式"调 API 查伦敦天气" vs 目标式"给我规划 3 天伦敦行程"（Agent 自己发现步骤：查天气/找航班/订酒店）	目标是启动推理循环的主要输入，所有规划由此派生
2. Reactive 反应性	能感知并响应环境（用户的追问、工具结果/API 错误、新邮件）	循环不能是直线，必须是循环——遇到意外和错误要反应，不能崩溃
3. Stateful 有状态	记住发生了什么：原始目标、聊天历史、工具调用历史、草稿本（当前想法）	状态管理是核心架构问题——设计跨循环持久化的「记忆」组件
4. Autonomous 自主性	能自己行动推进目标——是前三个原则的结果：知道目的地（目标）、看得见路（反应）、知道去过哪（状态）→ 能「开车」（自主）	授予 Agent「代理权」：无需逐步人类确认即可执行动作

四原则作为系统：目标定义「为什么」→ 反应提供「现在怎么办」→ 状态提供「之前发生了什么」→ 自主是「怎么做」（执行决策的能力）——这 4 条构成 Agent 的引擎。

---

2. 模式 1：Tool Use（工具使用）

2.1 核心问题：没有手的脑袋

LLM 是「罐子里的脑子」：文本进文本出，不能上网、查库、甚至不知道今天日期——它的整个世界是上下文窗口里的文本。怎么连接「大脑」（推理）与「真实世界」（代码/API/数据库）？→ Tool Use 模式。

2.2 模式定义：三部分架构

1. Schema（工具说明书）：JSON 描述——①name：函数名（get_weather）②description：最重要，清晰自然语言描述工具做什么（“获取指定城市当前天气”）③parameters：参数描述（city: string, “城市名，如 London”）
2. LLM（选择者）：推理——"目标关于天气，get_weather 的描述匹配；目标指定城市 London，工具需要 city 参数"→ 输出结构化 JSON：{"tool_call": {"name": "get_weather", "arguments": {"city": "London"}}}
3. Orchestrator（执行者，我们的代码）：①收 JSON ②解析（name/arguments）③映射到真实 Python 函数 ④执行 get_weather(city="London") ⑤把结果（“25°C”）返回 LLM 进入下一循环

2.3 架构含义

1. 工具描述就是提示工程：描述质量决定工具会不会被用——坏描述 = 工具永远不会被调用
2. 安全与校验：Orchestrator 必须是安全门——验证 LLM 的所有参数，绝不直接信任 LLM 输出（防 SQL 注入）
3. 错误处理：LLM 调用可能失败，要有处理机制

---

3. 模式 2：Planning（规划）

3.1 从单步到多步

Tool Use 是单步："伦敦天气？"→ 调一次工具。Planning 问题（多步）："把伦敦天气发邮件给我"→ 需要序列：①call_weather ②call_email（结果来自步骤1）——Agent 怎么知道不能先调邮件工具？

3.2 模式定义

• 用 LLM 把高层目标分解成显式的、有序的可执行步骤列表
• 停止问 LLM"给我答案"，开始问"给我找到答案的计划"——计划只是数据结构（文本列表/JSON 数组）
• 使能技术：CoT（思维链）——“先创建计划，再执行第一步”。LLM 内心独白：“用户要天气还要邮件。计划：1. 调 get_weather 查伦敦 2. 用步骤1结果调 send_email。行动：先输出第一个工具调用 call_weather(“London”)”

3.3 Orchestrator 的新角色：状态机

• ①存完整计划（进记忆）②跟踪当前步骤（“第 1/2 步”）③执行当前步 ④把结果喂回 LLM ⑤LLM 感知结果继续下一步
• Plan → Act → Observe → Continue Plan 循环 = 高级 Agent 的基础
• 架构师三要点：①提示词管过程不只结果（“一步步想”“创建计划”“分解问题”）②必须有组件存/读/更新计划 ③处理失败：步骤2失败怎么办？→ 感知失败并重新规划（“send_email 失败，新计划：notify_user_of_failure”）

Tool Use 给 Agent 「手」；Planning 给 Agent 「内心独白」——行动前思考、把大目标分解成小动作。这就是反射式 Agent 与思考型 Agent 的区别。

---

4. 模式 3：Reflection（反思/元认知）

4.1 核心问题：「质量盲」Agent

场景：目标"写 500 字微服务好处博客"。计划：①搜索 ②write_blog_post。「成功的失败」：计划执行完美、500 字写出来了，但重复啰嗦、漏关键点、语气别扭——Agent 报告"成功！"，因为它没有机制评判自己输出的质量。

4.2 模式定义：Writer-Critic 模型

• 元认知 = “思考你的思考”
• Agent 产出后暂停，用第二个批判性过程按标准评估输出——从"我做了任务吗？“到"我做得好吗？”
• 实现几乎总是 Writer-Critic：
  • Writer（行动者）：标准 Agent——跟随计划、用工具、产出初稿（博客/代码）
  • Critic（反思者）：另一次独立 LLM 调用，专用提示词：“你是评论家，根据[原始目标]和[质量标准]评审[作者的草稿]，给出改进反馈”——Critic 只是另一个有专门反思目的的 Agent

4.3 反思工作流（迭代循环）

[目标] → [Writer] → 草稿1 → [Critic] → 评审

• 评审说"输出好" → 最终答案
• 评审说"有缺陷" → 反馈 → 回到 Writer（内部自我改进循环，用户看到前已迭代）

4.4 架构含义

1. 贵：每个反思循环至少多一次 LLM 调用——成本和时间可能翻倍或三倍
2. 需要循环编排：线性 chain 实现不了——这正是 LangGraph 存在的意义
3. 提示词「人格」：要维护两个不同 System Prompt（Writer 提示词管"做"，Critic 提示词管"审"）

Planning 给内心独白，Reflection 给内心评论家——「初稿 Agent」与「定稿 Agent」的区别。

---

5. 模式 4：ReAct（复合模式）

5.1 核心问题：「脆弱」的计划

目标"找 3 本顶级科幻书并邮件发我"→ 计划：①search ②send_email。问题：步骤1（搜索）失败或空结果怎么办？Agent 按死板计划照样执行步骤2——把空列表发出去，违背用户真实目标。怎么让 Agent 根据每次行动的结果适应计划？

5.2 模式定义

• ReAct = Reason + Act：把 Planning 和 Tool Use 交错的紧密迭代循环
• 循环：①Reason（想）：生成想法（下一步计划）②Act（做）：执行那一步（工具调用）③Observe（看）：感知工具结果 ④Repeat：基于观察推理规划下一步
• 不是 Plan-then-Execute，是 Plan-Act-Observe-Plan-Act-Observe…
• 解构：Reason 阶段 = Planning 模式（提示词让 LLM 产出 Thought）；Act 阶段 = Tool Use 模式（产出 Action JSON）；ReAct 提示词就是强制 LLM 按 Thought/Action 格式输出

5.3 为什么是「复合」模式

• 实例（伦敦天气）：循环1：Reason"我要伦敦天气"→ Act call_weather → 观察"25°C 晴"；循环2：Reason"有天气信息了可以回答"→ 最终答案
• ReAct = Planning + Tool Use + Loop；Reflection 也常参与！高级循环：Reason(写博客) → Act(write_blog_post→草稿1) → Observe → Reason(反思"草稿弱") → Act(critique_draft→反馈)
• ReAct 是让所有其他模式协同工作的引擎

5.4 架构含义

1. 高延迟高成本（最大代价）：每步都是完整 LLM 调用，5 步任务 = 5-6 次调用
2. 自适应稳健（最大收益）：搜索失败，下一循环就知道并重新规划（“搜索失败，换一个查询词”）
3. 复杂编排：Orchestrator 要管理循环、解析 Thought/Action、执行、反馈——LangChain 叫它 “Agent Executor”

ReAct 不是新模式，是 Planning（Thought）+ Tool Use（Action）的复合；「魔法」在于把观察喂回 Thought 的编排循环——创造能响应环境的自适应 Agent。

---

6. 多智能体模式导论

6.1 「超级 Agent」谬论（反模式）

一个 50 个工具、10 页系统提示、全能（销售+研究+编码+客服）的单体 Agent？为什么是反模式：

1. 提示词复杂：10 页巨型文档 → 「提示词渗漏」（任务1的指令干扰任务2）
2. 上下文窗口限制：50 个工具的 schema 就吃光窗口，没地方放记忆和任务
3. 单点故障：一部分卡住整个系统崩，调试噩梦

6.2 解决方案：「数字团队」模式 + 三大力量

不要建一个单体 Agent，建一支「微型 Agent 团队」——每个 Agent 提示词小、工具少、可测试可替换；从设计「工人」到设计「组织」。

力量 1：专业化（Specialization）——每个 Agent 被设计成只把一件事做到完美：ResearchAgent（有搜索工具，“彻底客观”）；CopywriterAgent（无工具，“创意风趣”）；LegalAgent（有审合同工具，“严谨规避风险”）。收益：质量可靠性大增——Copywriter 永远不会去调法律工具，Legal 永远不会写俏皮博客。

力量 2：并行化（Parallelization）——并发执行无依赖任务：单体顺序 10s+5s=15s vs 并行 Agent A(10s)‖B(5s)=10s。

力量 3：辩论与批判（Debate & Critique）——Agent 间互相批判提升质量 = Agent 间的 Reflection 模式：WriterAgent 初稿 → CriticAgent 评审 → WriterAgent 修订——「团队式反思」比单 Agent 自审更稳健。

6.3 多智能体模式路线图

三大力量 → 四个蓝图：Router & Specialist（专业化）/ Handoff（顺序流）/ Group Chat（辩论）/ Swarm（大规模并行）。

---

7. 模式 5：Router & Specialist（路由与专才）

7.1 定义：委派模式（不是协作模式）

「经理-工人」或「交警」模型：

• Specialist Agents（工人）：聚焦小提示词 + 只带需要的工具（SupportAgent: [get_order_status, process_refund]；InventoryAgent: [check_stock, get_product_details]）
• Router Agent（经理）：自己不做任何「工作」，唯一工作是分类用户意图并路由给正确的专才。它的提示词禁止直接回答，只能调用 route_task(destination, original_query)：“你必须从 [‘support’, ‘inventory’, ‘billing’] 选一个目的地并调用 route_task”

7.2 架构含义

1. 可维护性与模块化（微服务模式）：加 Billing 部门？只需新建隔离的 BillingAgent + 更新 Router 提示词的列表——其他 Agent 完全不受影响（巨大胜利）
2. 性能与成本：Router 调用又快又便宜（简单分类，不是复杂 ReAct 循环）；只有被选中的那个专才做昂贵的多步工作——不在无关工具/提示词上浪费 token
3. 可测试性：每个专才完全隔离测试

委派的根本模式，直接实现「专业化」原则——复杂多功能 Agent 系统的默认首选模式（Router = 快便宜的「分类器」，Specialists = 聚焦可靠的「工人」）。

---

8. 模式 6：Handoff（顺序交接/流水线）

8.1 定义

用户请求是多步流程（“找 5 篇最新文章 → 总结 → 写社媒帖”）→ 一个 Agent 研究完交接给第二个总结，再交接给第三个写帖。

• 「流水线」模式：固定、预定顺序的专才序列 [Agent A] → [Agent B] → [Agent C] → 最终输出
• 核心机制：一个 Agent 的输出 = 下一个 Agent 的直接输入（State Handoff，由 Orchestrator 用工作流状态/草稿本传递：调 A → 存 Result A 进 State → 调 B 输入 Result A → …）
• 与 Router 的区别：Router 选路径，Handoff 路径固定——关于过程，不是分类

8.2 实例：博客工作流

“写一篇关于 AI 未来的博客”：ResearchAgent（输入"AI 未来"，输出 500 字原始文本+事实+链接）→ DraftingAgent（输出 5 段结构化博客）→ EditorAgent（校对语法和语气，输出终稿）。

8.3 架构含义

1. 高可靠高确定（最大收益）：LLM 调用序列完全已知、无意外——完美适合自动化已知业务流程
2. 简单可测：失败时精确知道哪段交接断了（如 B→C 链）
3. 僵硬脆弱（最大代价）：链条固定，不能适应意外——Agent A 失败整个链停；不能跳过 B 或加新步骤

固定顺序路径 = Agent 架构的「流水线」；适用已知稳定流程（如"处理发票"）；收益=可靠性，代价=僵硬。

---

9. 模式 7：Group Chat / Debate（群聊/辩论）

9.1 定义：「数字会议室」

Router 是经理派活、Handoff 是流水线——Agent 们都沉默，从不互相说话。复杂问题、最佳方案未知、需要讨论批判发现 → 「数字会议室」。

三大组件：

1. Specialist Agents（参会者）：熟悉的工人（Researcher/Writer/Critic）
2. 共享聊天历史（State）：会议室的「白板」——每个 Agent 都能看到所有人的所有消息（共享上下文）
3. GroupChatManager（主持人）：最重要的新组件——管理轮流发言、决定下一个谁说话

9.2 好处与代价

• ✅ 高质量与「涌现」方案（最大优势）：辩论修订过程产出远超任何单 Agent 的结果——方案是发现的不是执行的
• ✅ 灵活适应：对话可以是 3 步或 15 步，适应问题复杂度
• ❌ 成本与延迟（最大劣势）：聊天里每一条消息都是昂贵的 LLM 调用——10 轮辩论 = 至少 10 次 API 调用
• ❌ 非确定性与混乱：Agent 可能陷入「死循环」争论不休、跑题

用受主持的对话循环取代固定路径；组件 = 专才 + GroupChatManager + 共享聊天历史。适用：复杂、创意、定义不清的问题，质量是 #1 优先级（胜过速度/成本/可预测性）——例：“设计新产品”“辩论法律策略”。

---

10. 模式 8：Swarm（蜂群/并行）

10.1 定义：「蜂巢/工人大军」

问题不是创意复杂，而是规模巨大：“总结昨天发布的 10,000 篇文章”——需要「一支同时干活的 Agent 大军」。

• 定义：中央「蜂后（Queen）」Agent 把大任务分解成许多小的相同子任务，派出大量「工人（Worker）」Agent 并行执行
• 核心概念：MapReduce 设计模式应用到 Agent
  • Map 阶段（分解分发）：Queen 拿大任务（1000 份报告清单）→ 为每个条目派一个 Worker
  • Reduce 阶段（聚合综合）：Queen 等所有 Worker 完成 → 收集 1000 个结果 → "总结这些总结"成一个最终答案

10.2 好处与代价

• ✅ 巨大速度与规模：真正大规模列表任务的唯一模式——比顺序循环快 1000 倍
• ❌ 局限 1：只能「尴尬并行」——子任务必须 100% 独立；Worker 之间不能通信（需要通信就用 Group Chat）
• ❌ 代价 1：极端成本——1000 个并行 Agent = 1000 次同时 LLM API 调用（这是成本取舍，不是延迟取舍）
• ❌ 代价 2：编排复杂——不是简单 for 循环，是复杂异步并行处理系统

1-to-N 并行模型 = Agent 的 MapReduce；Queen（分解/聚合）+ Workers（执行）；适用海量列表独立任务；用成本与复杂度换速度与规模。

---

11. 模式 9：Human-in-the-Loop（HITL，「你确定吗？」按钮）

11.1 核心问题：非确定性的危险

• 传统软件：确定性（IF X THEN Y，相同输入相同输出，可预测）
• Agentic AI：非确定性（IF X THEN 也许 Y？也许 Z？）——LLM 输出是概率性的，只能引导不能 100% 保证
• 架构师噩梦：你在构建一个核心逻辑组件天生不可预测的系统
• 企业风险四类：财务（误读请求退了 $100,000 而非 $1,000）、数据完整性（误解"清理旧用户"删了活跃客户数据）、安全隐私（把"John 的客户数据"给了另一个 John）、声誉（Agent 暴走向客户发冒犯信息）
• 永远不能给非确定性 Agent 完全控制权

「护栏」不是「笼子」：❌ 笼子（错）：移除所有工具，只能回答简单问题——安全但毁掉一切价值；✅ 护栏（对）：让 Agent 开车，但在周围建安全系统——把确定性检查点和覆盖机制架构进非确定性工作流 → 目标：安全自主（Safe Autonomy）。

11.2 定义

工作流在预定义的高风险检查点故意暂停，等待人类明确批准才继续——在非确定性 Agent 执行不可逆/高价值动作前重新引入确定性人类判断。这不是失败状态，是设计特性。

检查点架构（Checkpoint）——关键：不让 Agent 决定何时求助，由我们定义检查点：

1. Agent 规划：Reason 阶段生成计划（如 call_tool(‘refund_customer’, amount=10000)）
2. Orchestrator 拦截：执行前拦截该计划
3. 确定性规则：检查硬编码规则 IF tool_name == 'refund_customer' AND amount > 1000:
4. 暂停等待：命中 → 转入 human_approval 状态；未命中 → 立即执行

11.3 架构含义

• ✅ 两全其美：Agent 的自主魔法问题解决 + 人类的确定性可问责判断——高价值任务安全部署的唯一方式
• ❌ 延迟与扩展性：把人类尺度延迟（秒/分钟/小时）引入毫秒级软件循环；贵；不扩展（要人类 standby）
• 🎯 关键设计决策：阈值——$100？（太低，警报太多，贵）$100,000？（太高，风险太大）——阈值是核心业务逻辑决策

Agent 建议，人类决定（The agent suggests, the human decides）——适用金融交易、数据删除、发送关键外部消息。

---

12. 模式 10：Ejection / Custom Logic（弹出/自定义逻辑，「红色停止按钮」）

12.1 为什么需要「逃生舱」

HITL 用于危险动作（Agent 工作正常，如"我要扣 $10,000，可以吗？"）；Ejection 用于损坏或不良对话（Agent 失败或用户想退出）。

定义：确定性、基于规则的模式——特定条件满足时立即绕过或终止非确定性 Agent 循环——瞬间把控制权从不可预测的 LLM 转移到可预测的确定性系统（非确定性系统的确定性覆盖）。

关键场景：①用户沮丧（Agent 死循环，用户说"你没用，让我找真人！"）②用户终止（“停”“取消”“算了”“再见”）③政策/安全违规（用户辱骂、粗俗、要求政策禁止的事）。

12.2 架构：「预检过滤器」

• ⚠️ 关键：这个逻辑绝不能放进 Agent 的提示词里（Agent 可能无视它）
• 实现：在 Agent 的感知/推理阶段之前运行的简单确定性 if 语句

---

13. 小结

本段精华：

1. 模式 vs 框架：框架是工具（How），模式是蓝图（What & Why）——模式与框架无关，任何框架都能实现
2. 四大设计原则：目标驱动（为什么）+ 反应性（现在怎么办）+ 有状态（之前发生了什么）→ 自主性（怎么做）——Agent 与普通程序的分界线
3. 四大核心模式递进：Tool Use（给手）→ Planning（给内心独白）→ Reflection（给内心评论家）→ ReAct（手+独白+循环复合，观察喂回思考 = 自适应）
4. 超级 Agent 是反模式（提示词渗漏/上下文窗口吃光/单点故障）→ 建「数字团队」：专业化 + 并行化 + 辩论批判 三大力量
5. 四大协作模式：Router & Specialist（交警分类派活，默认首选）/ Handoff（固定流水线，可靠但僵硬）/ Group Chat（会议室，质量最高最贵）/ Swarm（蜂群 MapReduce，海量并行，Worker 间不能通信）
6. 非确定性是架构师噩梦 → 护栏不是笼子：要「安全自主」
7. HITL：「你确定吗？」——检查点拦截 + 确定性规则 + 人类审批；阈值是核心业务决策；Agent 建议，人类决定
8. Ejection：「红色停止按钮」——预检过滤器（在感知之前、绝不能放提示词里）检测停止词/违规（含 “human” 就转实时聊天）→ 确定性覆盖
9. 下一段预告：Agentic RAG——传统 RAG 的局限 → 「主动研究员」循环