AI Agent 持续火爆，不仅仅是产品上，在融资市场也同样火爆，各种产品都在往上靠。但对于 AI Agent 该如何架构，有人关注，但少有人刻意去了解和分析。一些常见的问题有：如单个 Agent 搞不定复杂任务，多个 Agent 又容易失控，成本高，在不同的场景应该使用什么样的架构等等。
这篇文章我会尝试分享一下 AI Agent 的 4 个常用设计模式。
1. 什么是 Agent 设计模式
设计模式这个概念最早来自建筑行业，后来被软件工程借鉴过来。Christopher Alexander 在《建筑的永恒之道》里说，每个模式都是一个三元组：在特定的上下文中，解决特定的问题，采用特定的方案。
放到 AI Agent 领域，设计模式就是构建智能体系统的常见架构方法。每种模式都提供了一个组织系统组件、集成模型、编排单个或多个 Agent 来完成工作流的框架。
为什么需要设计模式？因为 Agent 系统的复杂性在于它需要自主决策、动态规划、处理不确定性。我们需要有特定场景下的特定解决方案，不过于复杂，也不过于简单，刚刚好。
选择设计模式前，需要考虑几个关键因素：任务复杂度、响应时间要求、成本预算、是否需要人工参与。想清楚这些，才能选对模式。
2. 单 Agent 模式
2.1 模式定义
单 Agent 模式是最基础的设计模式。整个系统只有一个 Agent，通过一个 AI 模型、一组预定义的工具、一个精心设计的系统提示词来完成任务。
这也是我们实际工作中常用的设计模式。
Agent 依赖模型的推理能力来理解用户请求、规划执行步骤、选择合适的工具。
这个模式的架构很简单：
用户输入 → Agent（模型+工具+提示词） → 输出结果
所有的决策和执行都在一个 Agent 内完成。
2.2 解决的问题
单 Agent 模式主要解决的是需要多步骤处理但逻辑相对清晰的任务。比如：
- 需要调用多个 API 获取信息然后综合
- 需要访问数据库查询后给出答案
- 需要执行一系列操作来完成用户请求
这些任务用传统的非 Agent 系统也能做，但整个逻辑非常固化，都是规则，而使用了 Agent 后，它能动态决策，自行做工具调用。
2.3 核心组件
AI 模型：这是 Agent 的大脑，负责理解、推理和决策。模型的能力直接决定了 Agent 的上限。选择模型时要平衡能力和成本，不是所有任务都需要用最强的模型。
工具集：Agent 能调用的外部功能，比如搜索引擎、数据库、API、计算器等。工具定义要清晰，包括什么时候用、怎么用、预期结果是什么。工具太多会增加选择难度，太少又限制能力。
系统提示词：定义 Agent 的角色、任务、行为规范。好的提示词能较大幅提升 Agent 的表现。要明确告诉 Agent 它是谁、要做什么、有哪些限制、如何处理异常情况。
记忆系统：虽然不是必需的，但记忆系统能让 Agent 保持上下文，避免重复操作。可以是简单的对话历史，也可以是复杂的向量数据库。
2.4 工作流程
- 接收请求：Agent 接收用户的输入，可能是文本、语音或其他格式
- 理解意图：通过模型分析用户想要什么，需要哪些信息
- 制定计划：决定需要执行哪些步骤，调用哪些工具
- 执行操作：按计划调用工具，获取必要信息
- 综合结果：把各种信息整合成最终答案
- 返回响应：将结果返回给用户
整个过程是线性的，但 Agent 可以根据中间结果调整计划。
2.5 应用场景
客服助手：处理常见的客户询问，比如查订单、改地址、退换货。Agent 可以访问订单系统、物流系统、用户数据库，一站式解决客户问题。
研究助手：帮助用户收集和总结信息。比如搜索特定主题的最新进展，整理成报告。Agent 可以调用搜索 API、访问学术数据库、生成摘要。
个人助理：管理日程、发邮件、设置提醒。Agent 可以访问日历、邮箱、任务管理工具，帮用户处理日常事务。
2.6 优势与局限
优势：
- 架构简单，容易实现和维护
- 成本可控，只需要调用一个模型
- 响应速度快，没有多 Agent 协调的开销
- 调试方便，所有逻辑在一个地方
局限：
- 处理复杂任务能力有限
- 工具太多时容易混乱
- 单点故障，Agent 出问题整个系统就挂了
- 难以并行处理多个子任务
2.7 实施建议
从简单开始：先实现核心功能，确保基本流程跑通，再逐步添加工具和能力。
工具要精不要多：与其给 Agent 20 个工具，不如精选 5-8 个最常用的。每个工具的使用场景要明确。
提示词要迭代优化：没有一次就完美的提示词。要根据实际使用情况不断调整，特别是边界情况的处理。
加入失败处理：工具调用可能失败，模型推理可能出错。要有明确的错误处理机制，比如重试、降级、转人工。
监控关键指标：响应时间、成功率、工具调用次数、token 消耗等。这些数据是优化的基础。
3. ReAct 模式
3.1 模式定义
ReAct（Reasoning and Acting）模式是一种让 Agent 交替进行推理和行动的设计模式。不同于简单的输入输出，ReAct 模式让 Agent 在一个循环中不断地思考、行动、观察，直到找到问题的答案。
这个模式的核心思想是把 Agent 的思维过程显式化。每一步都要说明在想什么、要做什么、观察到什么，形成一个完整的推理链条。这不仅提高了结果的可靠性，也让整个过程变得可解释。
3.2 解决的问题
ReAct 模式解决的是那些需要多步探索和动态调整策略的复杂问题：
- 答案不是显而易见的，需要逐步收集信息
- 初始计划可能不完善，需要根据中间结果调整
- 需要试错和迭代才能找到最优解
- 推理过程和结果同样重要，需要可解释性
传统的一次性推理经常不够用，需要 Agent 能够根据新信息不断调整自己的理解和策略。
3.2 核心机制
Thought（思考）：Agent 分析当前状况，推理下一步该做什么。这包括理解已有信息、识别缺失信息、评估可能的行动方案。思考过程要明确表达出来，比如「我需要知道 X 才能回答 Y」。
Action（行动）：基于思考结果，Agent 决定采取什么行动。通常是调用某个工具获取信息，也可能是进行计算或转换。行动要具体，包括使用什么工具、传入什么参数。
Observation（观察）：Agent 接收行动的结果，理解新获得的信息。观察不是简单的记录，而要分析这些信息对解决问题有什么帮助，是否需要调整策略。
这三个步骤形成一个循环，不断重复直到找到满意的答案或达到终止条件。
3.3 工作流程
用户输入问题
↓
初始思考：理解问题，确定需要什么信息
↓
循环开始：
→ 思考：基于当前信息，决定下一步
→ 行动：执行决定的操作
→ 观察：分析操作结果
→ 判断：是否已经可以回答问题？
├─ 否：继续循环
└─ 是：退出循环
↓
综合所有信息，生成最终答案
↓
返回给用户
每个循环都在积累信息，逐步接近答案。关键是 Agent 要能判断什么时候信息足够了。
3.4 典型应用场景
复杂问题求解：比如数学应用题，需要分步骤求解。Agent 先理解问题，识别已知和未知，然后逐步计算中间结果，最后得出答案。每一步都要验证是否合理。
信息检索与验证：用户问一个需要多方印证的问题。Agent 从不同来源收集信息，交叉验证，排除矛盾，最终给出可靠的答案。比如”某个历史事件的真实经过”。
调试和故障排查：系统出问题了，Agent 需要逐步检查各个组件，收集日志，测试假设，最终定位问题原因。这个过程充满了试错和调整。
研究和分析：对某个主题进行深入研究。Agent 先了解背景，然后深入特定方面，发现新的线索后调整研究方向，最终形成完整的分析报告。
3.5 实现要点
推理链的质量：ReAct 模式的效果很大程度上取决于模型的推理能力。要选择推理能力强的模型，并通过提示词引导它进行结构化思考。
终止条件设计：必须有明确的终止条件，否则可能陷入无限循环。常见的终止条件包括：找到满意答案、达到最大迭代次数、遇到无法处理的错误、用户主动终止。可以参考我上一篇文章《AI Agent 核心策略：如何判断 Agent 应该停止》
上下文管理：随着循环次数增加，上下文会越来越长。需要策略性地管理上下文，比如总结之前的发现、删除无关信息、保留关键结论。
错误恢复：某一步出错不应该导致整个流程失败。要有恢复机制，比如重试、换一种方法、跳过这一步等。
3.6 优势与挑战
优势：
- 可解释性强，每一步推理都有记录
- 灵活性高，可以动态调整策略
- 准确性好，通过多步验证减少错误
- 适应性强，能处理预料之外的情况
挑战：
- 延迟较高，多次循环导致响应时间长
- 成本增加，每次循环都要调用模型
- 可能陷入循环，在某些问题上来回打转
- 对模型能力要求高，弱模型效果差
3.7 优化策略
设置合理的最大循环次数：根据任务类型和复杂度，设置合适的上限。简单任务 3-5 次，复杂任务 10-15 次。
缓存中间结果：相同的查询不要重复执行，工具调用的结果要缓存起来。
并行化某些操作：如果多个信息获取操作互不依赖，可以并行执行，减少总体时间。
使用更轻量的模型进行初步筛选：不是每个思考步骤都需要最强的模型，可以用小模型做初筛，大模型做关键决策。
提供思考模板：通过提示词工程，给 Agent 提供思考的框架，提高推理效率。
4. 多 Agent 协作模式
4.1 模式定义
多 Agent 协作模式是让多个专门化的 Agent 共同完成一个复杂任务。每个 Agent 负责自己擅长的领域，通过协调器（Coordinator）或预定义的工作流来协同工作。
这个模式的核心理念是”专业分工”。就像一个团队，每个成员都有自己的专长，通过协作可以完成单个人无法完成的任务。协调可以是中心化的（有一个协调器），也可以是去中心化的（Agent 之间直接通信）。
4.2 解决的问题
多 Agent 协作模式解决的是单个 Agent 难以处理的复杂问题：
- 任务涉及多个专业领域，单个 Agent 难以精通所有领域
- 需要并行处理多个子任务以提高效率
- 任务太复杂，单个提示词难以覆盖所有情况
- 需要不同视角的交叉验证来提高可靠性
当你发现单个 Agent 的提示词越写越长、工具越加越多、错误率开始上升时，就该考虑多 Agent 协作了。
4.3 架构类型
顺序协作：Agent 按照预定顺序依次工作，前一个的输出是后一个的输入。像流水线一样，每个 Agent 完成特定的加工步骤。适合步骤明确、顺序固定的任务。
并行协作：多个 Agent 同时工作，各自处理任务的不同方面，最后汇总结果。像团队分工一样，每个人负责一部分，最后整合。适合可以分解的独立子任务。
层级协作：Agent 组织成树状结构，上层 Agent 负责任务分解和结果汇总，下层 Agent 负责具体执行。像公司组织架构，有管理层和执行层。适合需要多级分解的复杂任务。
网状协作：Agent 之间可以自由通信，没有固定的上下级关系。像专家会诊，大家平等讨论，共同决策。适合需要充分讨论和创意的任务。
4.4 核心组件
专业 Agent：每个 Agent 专注于特定领域或功能。比如数据分析 Agent、文案撰写 Agent、代码生成 Agent 等。专业化让每个 Agent 的提示词更精简、更有效。
协调器 Agent：负责任务分解、Agent 调度、结果汇总。协调器需要理解整体任务，知道每个 Agent 的能力，能做出合理的分配决策。
通信机制：Agent 之间如何传递信息。可以是直接传递（点对点），也可以通过共享内存（如消息队列、数据库）。通信协议要明确，包括数据格式、错误处理等。一般是 json 格式。
上下文管理：如何在 Agent 之间共享和传递上下文。不是所有信息都需要传给所有 Agent，要有选择地传递相关信息，避免信息过载。
4.5 典型场景
内容创作流水线：
- 研究 Agent：收集资料、查证事实
- 写作 Agent：撰写初稿
- 编辑 Agent：优化文笔、检查逻辑
- 审核 Agent：确保符合规范、没有敏感内容
每个 Agent 专注自己的环节，整体产出高质量内容。
客户服务系统：
- 分类 Agent：理解客户问题类型
- 查询 Agent：从数据库获取相关信息
- 解决方案 Agent：生成解决方案
- 回复 Agent：组织友好的回复话术
根据问题类型，协调器可能跳过某些 Agent 或调整流程。
代码开发助手：
- 需求分析 Agent：理解用户需求
- 架构设计 Agent：设计系统架构
- 代码生成 Agent：编写具体代码
- 测试 Agent：生成测试用例并执行
- 文档 Agent：生成代码文档
可以迭代工作，测试发现问题后返回给代码生成 Agent 修改。
数据分析系统：
- 数据收集 Agent：从各个源获取数据
- 清洗 Agent：处理缺失值、异常值
- 分析 Agent：统计分析、模式识别
- 可视化 Agent：生成图表
- 报告 Agent：撰写分析报告
可以并行处理多个数据源，提高效率。
4.6 协调策略
中心化协调：所有决策都由协调器做出。优点是逻辑清晰、易于控制；缺点是协调器可能成为瓶颈。
分布式协调：Agent 之间直接协商。优点是灵活、无单点故障；缺点是可能出现冲突、难以调试。
混合协调：结合两者优点，重要决策由协调器做，细节由 Agent 之间协商。
动态协调：根据任务特点动态选择协调策略。简单任务用顺序协作，复杂任务用层级协作。
4.7 实施要点
明确分工：每个 Agent 的职责要清晰，避免重叠和空白。写清楚每个 Agent 负责什么、不负责什么。
接口标准化：Agent 之间的接口要标准化，包括输入输出格式、错误码、超时处理等。
错误隔离：一个 Agent 出错不应该导致整个系统崩溃。要有错误隔离和恢复机制。
性能优化：识别瓶颈 Agent，考虑并行化、缓存、负载均衡等优化手段。
版本管理：不同 Agent 可能有不同的更新频率，要有版本管理机制，确保兼容性。
4.8 优势与挑战
优势：
- 可扩展性好，可以随时添加新的专业 Agent
- 复用性高，Agent 可以在不同任务中复用
- 维护性好，每个 Agent 独立维护，互不影响
- 可靠性高，通过冗余和交叉验证提高准确性
挑战：
- 协调开销大，Agent 之间的通信和协调需要额外成本
- 调试困难，问题可能出现在任何一个 Agent 或它们的交互中
- 延迟增加，多个 Agent 串行或协调都会增加总体时间
- 成本上升，每个 Agent 都需要模型调用，成本成倍增加
5. 人机协同模式
5.1 模式定义
人机协同模式是在 Agent 工作流程中嵌入人工干预点的设计模式。Agent 在关键决策点暂停执行，等待人类审核、提供额外信息或做出决策，然后继续执行。这不是简单的人工兜底，而是人类智慧和 AI 能力的有机结合。
这个模式承认了一个现实：当前的 AI 还不能完全自主地处理所有情况，特别是涉及主观判断、伦理决策、高风险操作的场景。通过合理的人机协同，可以发挥各自优势。
在 AI 编程中通用有一个手动模式和一个自动模式。
5.2 解决的问题
人机协同模式解决的是纯 AI 方案风险太高或能力不足的问题：
- 高风险决策需要人工确认，比如大额交易、医疗诊断
- 主观判断 AI 难以把握，比如创意评审、品牌调性
- 异常情况超出 AI 训练范围，需要人类经验
- 法律或合规要求必须有人参与决策
- AI 不确定性太高，需要人工验证
这个模式的关键是找到人机协同的最佳平衡点，既不能过度依赖人工（那就失去了自动化的意义），也不能完全放手给 AI（可能造成严重后果）。
5.3 协同机制
审核点（Checkpoint）：在工作流的特定位置设置审核点，Agent 必须等待人工审核才能继续。审核点的位置很关键，太多会影响效率，太少可能错过关键决策。
升级机制（Escalation）：当 Agent 遇到超出能力范围的情况时，自动升级到人工处理。需要定义清楚什么情况下升级，比如置信度低于阈值、遇到预定义的异常情况等。
协作模式（Collaboration）：人类和 Agent 共同完成任务，各自负责擅长的部分。比如 Agent 做数据分析，人类做战略决策；Agent 生成初稿，人类做最终润色。
反馈循环（Feedback Loop）：人类的决策和修正会反馈给 Agent，用于改进后续的行为。这是一个持续学习的过程。
5.4 干预类型
批准型干预：Agent 完成工作后，需要人工批准才能生效。比如 Agent 起草了一份合同，法务人员审核批准后才发送。这种干预主要是把关和确认。
选择型干预：Agent 提供多个选项，由人类选择。比如 Agent 生成了三个营销方案，市场总监选择最合适的。这种干预利用人类的判断力。
修正型干预：人类可以修改 Agent 的输出。比如 Agent 写了一篇文章，编辑可以直接修改其中的内容。这种干预是精细调整。
补充型干预：人类提供 Agent 缺少的信息。比如 Agent 在处理客户投诉时，遇到特殊情况，客服人员提供额外的背景信息。这种干预是信息补充。
接管型干预：在某些情况下，人类完全接管任务。比如 Agent 判断问题太复杂，直接转给人工处理。这种干预是兜底机制。
5.5 设计原则
最小干预原则：只在必要的地方设置人工干预，尽量让 Agent 自主完成任务。过多的干预会降低效率，失去自动化的意义。
透明度原则：人类要能理解 Agent 的决策依据。Agent 应该提供决策的理由、使用的数据、考虑的因素等，让人类能做出明智的判断。
可控性原则：人类要能随时介入、修改或停止 Agent 的行为。要有紧急停止按钮、回滚机制等。
责任明确原则：明确人和 AI 各自的责任边界。特别是出现问题时，要清楚责任在谁。
用户体验原则：人机交互界面要友好，信息呈现要清晰，操作要简便。不能因为加入人工环节就让流程变得复杂。
5.6 实施要点
界面设计：人机交互界面是关键。要展示必要信息，但不能信息过载。要提供便捷的操作方式，减少人工负担。可以用可视化、摘要、高亮等技术。
通知机制：需要人工介入时，要有及时的通知机制。可以是应用内通知、邮件、短信等。要考虑优先级和紧急程度。
超时处理：人工可能不能及时响应，要有超时机制。可以是自动采用保守方案、转给其他人、暂停任务等。
权限管理：不同的人可能有不同的干预权限。要有完善的权限体系，确保只有合适的人才能做关键决策。
审计追踪：所有的人工干预都要有记录。谁在什么时间做了什么决定，依据是什么。这对于问题追溯和合规审计都很重要。
5.7 优势与挑战
优势：
- 安全性高，关键决策有人把关
- 灵活性好，能处理 AI 无法处理的特殊情况
- 可信度高，用户更信任有人参与的系统
- 持续改进，人工反馈帮助系统不断优化
挑战：
- 效率降低，人工环节会增加处理时间
- 成本增加，需要人力投入
- 一致性难保证，不同人可能有不同判断
- 扩展性受限，人工环节可能成为瓶颈
6. 选择建议
选择合适的设计模式需要综合考虑多个因素。这里提供一个决策框架：
6.1 从简单到复杂的演进路径
第一阶段：单 Agent 模式
- 任务相对简单，领域单一
- 团队刚开始尝试 Agent
- 需要快速验证概念
- 成本敏感
第二阶段：ReAct 模式
- 任务需要多步推理
- 结果需要可解释性
- 有一定的复杂度但还能单 Agent 处理
第三阶段：多 Agent 协作
- 任务跨越多个领域
- 需要专业分工
- 单 Agent 已经力不从心
始终考虑：人机协同
6.2 关键决策因素
任务复杂度：
- 低：单 Agent
- 中：ReAct 或简单的多 Agent
- 高：复杂的多 Agent
响应时间要求：
- 实时（秒级）：单 Agent
- 近实时（分钟级）：ReAct 或并行多 Agent
- 非实时（小时级）：任何模式都可以
成本预算：
- 紧张：单 Agent
- 适中：ReAct 或简单多 Agent
- 充足：复杂多 Agent
可靠性要求：
- 一般：单 Agent 或 ReAct
- 高：多 Agent 协作（通过冗余提高可靠性）
- 关键：人机协同
团队能力：
- 初级：从单 Agent 开始
- 中级：可以尝试 ReAct 和简单多 Agent
- 高级：可以驾驭任何模式
7. 总结
AI Agent 的设计模式不是银弹，每种模式都有自己的适用场景和权衡。单 Agent 模式简单直接，适合入门和简单任务。ReAct 模式增加了推理能力，适合需要探索的问题。多 Agent 协作通过分工提高能力，适合复杂的领域任务。层级规划通过递归分解处理高复杂度问题。人机协同则是当前 AI 能力限制下的必要补充。
选择模式时，要从实际需求出发，考虑任务特性、资源限制、团队能力等因素。不要过度设计，也不要畏手畏脚。从简单开始，逐步演进，在实践中找到最适合的方案。
技术最终是为业务服务的。不管用什么模式，最终目的是解决实际问题，创造价值。
以上。