AI Agent 的九种设计模式

大模型（LLM）不仅可以做聊天、写文案，也可以被"包装"成更复杂的智能体（AI Agent），用来做任务执行、流程编排、系统集成等。

为了避免一上来就"乱写 Prompt、到处连接口"，先从"设计模式"的角度理解常见架构非常重要。

本文将常见的 AI Agent 设计方式归纳为 九种设计模式，每种模式介绍：

核心思想
典型结构/流程
示例
优缺点
适用场景

这些模式是"积木"，可以灵活组合，不是互斥选项。

1. 单体 Agent 模式（Single-Agent Pattern）

核心思想

一个 LLM（大模型）+ 对话上下文（可选工具），从输入到输出走完整流程。

结构非常简单：

用户输入 → Prompt → LLM → 返回结果

有时会加上简单工具调用，但整体还是"一个 Agent 搞定一切"。

简单结构

text 复制代码

User → Prompt → LLM → Response

可选工具版：

text 复制代码

User → Prompt → LLM → [Tool Call?] → LLM → Response

示例

问答机器人：常见 FAQ、知识问答。
文本类工具：翻译、总结、改写、润色助手。

优点

实现快，开发成本低。
Prompt 即逻辑，修改容易。
很适合做 MVP / 原型验证。

缺点

逻辑都塞在 Prompt 里，复杂任务难以维护和调试。
状态管理弱，长对话可能受上下文长度限制。
对外部系统/流程的控制能力较弱。

适用场景

简单问答、轻量工具、单步任务。
复杂 Agent 系统中的"子助手"。

2. ReAct / 思考-行动循环模式（Reflection-Action Pattern）

核心思想

显式地设计一个循环：
思考（Thought）→ 行动（Action）→ 观察（Observation）→ 再思考，直到完成任务。

模型不一次性输出答案，而是"边思考边调用工具"。

流程

text 复制代码

User 问题
  ↓
LLM: Thought 1（我该怎么解决？）
  ↓
LLM: Action 1（调用某个工具/API）
  ↓
Observation 1（工具返回结果）
  ↓
LLM: Thought 2（基于结果再推理）
  ↓
... 直到输出最终答案

示例

日志分析助手：
- Thought：可能是数据库连接问题；
- Action：调用日志查询工具；
- Observation：发现大量 timeout；
- Thought：进一步检查网络配置......
复杂问答：
- 需要多次检索文档、组合多步计算后再给出统一回答。

优点

可解释：过程透明，便于调试。
可集成多工具，复杂任务可拆解为多步。
能处理多步推理场景。

缺点

每一步都是一次 LLM 调用，成本和延迟会增加。
若未设计好停止条件，有死循环风险。

适用场景

复杂问答、多步推理、多轮工具调用。
需要看中间过程的分析型助手。

3. 自我反思 / 自我改进模式（Self-Refine / Reflection Pattern）

核心思想

让 Agent 对自己的输出进行自查和改写 ：

先生成一个初稿，再由"自己"或另一个模型进行审查点评，然后进行改写。

结构类似：

Generator：生成初稿
Evaluator / Critic：评价、指出问题
Refiner / Reviser：改进输出

示例

方案文档生成：
- 先自动生成版本 v1；
- 再由"审稿 Agent"检查结构、逻辑、是否完整；
- 再出 v2/v3 改进版。
代码生成：
- 先生成代码；
- 自查是否有明显 bug 或不符合规范；
- 输出改进版代码。

优点

整体质量明显高于"一次性输出"。
对长文本、结构化内容、规则约束较强的任务非常有用。

缺点

多轮调用，成本与延迟增加。
需要明确评价标准，否则"瞎审"或过度修改。

适用场景

文档/方案/报告/合同草稿生成。
需要高质量输出而不太在乎多几十秒的场景。

4. 工具 / 函数调用模式（Tool-Calling / Function Calling Pattern）

核心思想

Agent 不是"一切都靠脑补"，而是通过调用外部工具/API 获得真实数据并执行操作。

LLM 负责选择工具、构造入参、解释结果。
工具层负责接业务系统、数据库、外部服务。

典型结构

text 复制代码

LLM Agent
  ↓（选择并调用工具）
Tools / Functions:
  - 搜索引擎接口
  - 订单/审批/CRM 等内部业务 API
  - 数据库查询接口
  - 代码执行环境、计算引擎

示例

企业智能客服：
- 查询订单、物流、库存、工单状态都通过工具完成；
- Agent 对用户来说只是"自然语言界面"。
智能审批助手：
- Agent 调用审批系统 API 获取申请、修改状态、记录意见。

优点

把 LLM 与业务系统解耦。
安全、权限、审计都可以留在工具层处理。
易扩展：增加新工具就能扩展 Agent 能力。

缺点

需要规范化工具设计（入参、出参、鉴权、异常等）。
需要对 LLM 的参数生成做校验，防止错误调用。

适用场景

所有"AI + 业务系统"的企业级应用。
需要查数据、改状态、执行操作的智能助手。

5. 规划-执行模式（Planner-Executor Pattern）

核心思想

将任务分解能力和执行能力拆分成两个角色：

Planner：负责制定计划（步骤、顺序、依赖）。
Executor：负责实际执行计划中的每个步骤。

流程

text 复制代码

User 需求
  ↓
Planner Agent：生成任务计划（Plan）
  e.g. [Step1, Step2, Step3...]
  ↓
Executor Agent/模块：
  - 逐步执行各 Step（工具调用、数据处理）
  - 记录中间结果
  ↓
汇总结果返回给用户

示例

报销流程自动化：
- Planner：校验发票 → 校验金额 → 规则检查 → 提交审批；
- Executor：实际调 OCR、规则引擎、财务系统 API。
数据分析流水线：
- Planner：取数 → 清洗 → 聚合分析 → 可视化 → 撰写报告；
- Executor：使用数据仓库、BI 平台、可视化工具等。

优点

结构清晰，可视化为"工作流图"。
Planner 和 Executor 可以分别优化。
易于调试：是规划不合理，还是执行出错，一目了然。

缺点

架构比单体 Agent 复杂。
需要设计计划的表示方式（Plan 的结构、存储等）。

适用场景

多步骤、强顺序性的业务流程（审批、报销、运维脚本）。
多工具组合的长链路任务。

6. 多 Agent 协作模式（Multi-Agent / Role-based Pattern）

核心思想

仿照现实中的团队，通过多个角色各司其职、协同完成任务。

常见角色：

Coordinator（协调/PM）：理解需求、拆任务、分配子任务。
Researcher：资料调查、信息收集。
Engineer：实现、编码、验证。
Reviewer：审稿/代码审查、质量把关。

典型结构

text 复制代码

User
  ↓
Coordinator Agent（总体规划）
  ↓           ↓          ↓
Researcher   Engineer   Reviewer
  ↘         ↙           ↘
        聚合与整合输出

示例

自动写 PRD / 技术方案：
- Coordinator：梳理需求与结构。
- Researcher：调研竞品、相关资料。
- Engineer：给出技术实现方案。
- Reviewer：检查完整性、合理性。
AI 软件工程团队试验：
- Planner、Coder、Tester、Ops 作为不同 Agent 分工。

优点

将复杂任务拆解成多个可解释角色。
每个角色可以使用专门的 Prompt 和工具集，效果更好。
对"AI 团队协作"有良好的抽象基础。

缺点

多 Agent 之间消息传递和对齐很复杂。
成本和时延上升，需要强编排逻辑以避免虚耗。
工程实现难度增加。

适用场景

高度复杂的创作或工程任务（大型文档、复杂代码库）。
R&D 探索"AI 团队"的实验项目。

7. 记忆驱动模式（Memory-Augmented Agent Pattern）

核心思想

让 Agent 拥有"记忆"，而不是每次交互都从零开始。

记忆主要包括：

用户长期信息：身份、习惯、历史偏好。
历史任务：之前做过什么任务、结果如何。
知识文档：FAQ、内部规章、历史决策记录。

实现方式通常是：

文本嵌入 + 向量数据库（RAG）用于检索相关内容；
结构化数据库保存用户画像、操作日志等。

示例

个人 AI 助理：
- 记住你常用的日报格式、项目背景、常用联系人；
- "帮我写今天日报"时自动结合近期任务记录。
企业内部问答助手：
- 记住部门特有的业务术语、流程规则；
- 不同部门同样的问题会回复不同内容。

优点

"越用越懂你"，提升黏性和体验。
减少用户重复输入背景信息的成本。

缺点

设计不当可能记错东西或保留过期知识。
隐私、安全、合规必须重点考虑（记什么、不记什么、如何删除）。

适用场景

长期陪伴型助手（个人/团队）。
持续业务流程的助理（客户跟进、项目管理助手）。

8. 环境驱动 / 状态机模式（Environment / State Machine Pattern）

核心思想

把 Agent 放在一个由"环境/状态机"控制的大系统中：

环境负责：状态、规则、合法操作、执行与记录；
Agent 负责：在当前状态下，选择下一步动作（策略决策）。

类似于强化学习中的 Agent--Environment 框架。

典型结构

text 复制代码

Environment（状态机/流程引擎）
  - 当前状态
  - 可用操作列表
  - 规则与约束
   ↑            ↓
Observation   Action（来自 Agent）
   ↑            ↓
Agent（LLM）

示例

流程引擎 + LLM：
- 流程路径由 BPMN/状态机定义；
- 每个节点让 LLM 给出"下一步决策建议"（通过或打回、选哪个分支）；
- 环境记录所有状态与操作，最终有完整的审计轨迹。
游戏/仿真：
- 游戏世界是环境；
- Agent 决定每一步行动（移动、攻击、买卖等）。

优点

流程可控、状态明确、严格可审计。
Agent 出错时，环境可以拒绝非法行为、回滚或告警。
易与现有 BPM/工作流系统集成。

缺点

环境建模和状态机设计成本较高。
开发比简单对话类 Agent 要复杂许多。

适用场景

严格流程管理（审批、风控、生产调度）。
要求可审计、可回放的关键业务系统。

9. 人在环 / 仲裁模式（Human-in-the-Loop Pattern）

核心思想

不追求完全自动化，而是把人类决策者嵌入关键链路中------

Agent 提供建议，人类做最终决策或仲裁。

常见形式

多候选方案 + 人工选择：
- Agent 输出多个选项，人工选一并可以轻微修改。
自动初审 + 人工复审：
- Agent 做风险初筛，标记可疑项；
- 人工只处理高风险或不确定项。
人工反馈驱动改进：
- 人对 Agent 的输出给出评价；
- 系统记录这些数据，作为后续优化 Prompt 或模型微调的依据。

示例

合同/法务审核：
- Agent 自动标红风险条款、提出修改建议；
- 法务人员审核后，决定是否采纳。
营销活动策略：
- Agent 给出多种投放方案；
- 人工选定一个并设定预算上限，最终推送执行。

优点

显著降低风险，适合高风险/高责任场景。
更容易让业务团队放心使用 AI：它是助手，不是替代者。
利于积累高质量的人类反馈数据。

缺点

无法形成完全自动闭环。
需要设计一套合理的人工审核/使用界面与流程。

适用场景

涉及法律、金融、风控、隐私等高风险业务。
AI 引入初期，希望"先半自动、后逐步自动"的场景。

如何组合这九种模式？

实际生产系统里，往往是多种模式的组合，而不是单一模式。

举例，一个"智能审批助手"可能会同时用到：

单体 Agent + 工具调用：作为基础问答、系统操作能力；
规划-执行模式：处理复杂的审批流程、数据收集与校验步骤；
记忆驱动模式：记住用户历史审批记录、偏好、常见规则解释；
环境/状态机模式：由工作流引擎控制整体流程与状态；
人在环模式：关键审批节点由负责人最终确认。

可以理解为：

1--4：从"聊天机器人"到"能调用工具的助手"；
5--7：从"助手"到"可编排、可记忆、可协作的系统"；
8--9：为生产环境补足"可控性、安全性、人机协作"。

选型建议（按复杂度和业务需求）

只做问答或简单工具：
- 单体 Agent + 工具调用
需要多步推理 + 工具：
- ReAct 模式 + 工具调用
需要高质量输出（长文档/代码/方案）：
- 在上面基础上叠加自我反思模式
任务是明确流程/工作流：
- 规划-执行模式 + 环境/状态机模式
面向长期使用、个性化体验：
- 再叠加记忆驱动模式
业务风险高、对结果有强审计需求：
- 必须引入人在环模式
做 AI R&D 或探索"AI 团队协作"：
- 可以尝试多 Agent 协作模式