7 种智能体（Agent）设计模式深度解析
从思维链到多智能体协作，理解这些认知框架，就理解了 Agent 世界的"思维模式库"。
这些模式并非互斥，实际开发中常常混搭使用。理解它们，能让我们在框架选型（LangChain、LangChain4j、LlamaIndex、Dify、Spring AI Alibaba 等）和架构设计时想得更透彻。
全景概览
mindmap
root((Agent 设计模式))
CoT 思维链
一步步写推理过程
Google Research 2022
Self-Ask 自问自答
拆大问题为小问题
Microsoft Research 2022
ReAct 推理+行动
思考与工具调用交替
Princeton & Google 2022
Plan-and-Execute 计划与执行
先规划再逐步执行
LangChain 社区 2023
Tree of Thoughts 树状思维
多分支探索择优
Princeton & DeepMind 2023
Reflexion 反思迭代
犯错后自我纠错
2023
Role-playing 角色扮演
多智能体分工协作
AutoGPT / ChatDev / CAMEL
七种模式的核心差异可以用一张表快速感知：
| 模式 | 一句话总结 | 核心能力 | 典型场景 |
|---|---|---|---|
| CoT | 一步步写过程 | 线性推理 | 数学计算、逻辑推理 |
| Self-Ask | 拆成小问题 | 问题分解 | 多跳事实检索 |
| ReAct | 既思考也动手 | 推理+工具调用 | 实时信息查询、API 调用 |
| Plan-and-Execute | 先计划再执行 | 任务规划 | 多步骤长任务 |
| ToT | 树状多分支探索 | 搜索+评估 | 解谜、复杂规划 |
| Reflexion | 自我反思迭代 | 自我纠错 | 代码生成、流程执行 |
| Role-playing | 多人协作分工 | 多智能体协作 | 软件开发、跨职能协同 |
一、Chain of Thought（思维链，CoT）
提出背景
Google Research 在 2022 年发表论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》，首次系统性地提出：通过引导大语言模型在给出最终答案之前，将推理过程一步步展示出来，可以显著提升模型在复杂推理任务上的表现。
核心思想
传统 prompting 方式下，模型被要求直接给出答案——"一口气报出结果"。这在简单问题上没有问题，但面对需要多步推理的任务（数学计算、逻辑推导、因果分析），直接给答案往往导致"跳步"和错误。
CoT 的核心洞察是：推理过程本身是一种"思维脚手架"。当模型被要求把中间推理步骤显式写出来时，每一步的输出都会作为下一步的上下文输入，相当于让模型在"草稿纸"上演算，而不是心算。这种"显式化"带来三个好处：
- 降低单步推理负担：模型不需要在一个 forward pass 中完成全部推理，而是将复杂推理拆成多个简单步骤，每步只需做一小段推理。
- 提供可追溯的推理链：如果最终答案出错，可以回溯到具体哪一步出了问题，便于调试和改进。
- 激发模型的潜在推理能力：大型模型在预训练阶段已经学到了大量推理知识，CoT 提供了一种"激活"机制，让这些能力得以释放。
CoT 有两种主要变体：Zero-shot CoT（直接在 prompt 末尾加上"Let's think step by step"）和 Few-shot CoT（在 prompt 中给出带推理过程的示例）。前者简单粗暴，后者效果更稳定。
流程图
flowchart LR
A[用户提问] --> B[模型开始推理]
B --> C[步骤1: 理解问题<br/>提取已知条件]
C --> D[步骤2: 设定变量<br/>建立关系]
D --> E[步骤3: 逐步计算<br/>推导中间结果]
E --> F[步骤4: 验证结果<br/>得出最终答案]
F --> G[输出答案 + 推理过程]
style A fill:#e1f5fe,stroke:#0288d1
style G fill:#c8e6c9,stroke:#388e3c
style C fill:#fff9c4,stroke:#f9a825
style D fill:#fff9c4,stroke:#f9a825
style E fill:#fff9c4,stroke:#f9a825
style F fill:#fff9c4,stroke:#f9a825
场景示例
问题：小明网购了一个 3.8 公斤的包裹，快递公司首重 1 公斤内收费 10 元，续重每公斤 3 元，不足 1 公斤按 1 公斤计算。请问小明需要付多少快递费？
CoT 推理过程：
第一步：确认包裹重量 → 3.8 公斤
第二步：计算计费重量 → 不足 1 公斤按 1 公斤算 → 4 公斤
第三步：分离首重和续重 → 首重 1 公斤 = 10 元
第四步：计算续重重量 → 4 - 1 = 3 公斤
第五步：计算续重费用 → 3 × 3 = 9 元
第六步：加总费用 → 10 + 9 = 19 元
答案：小明需要付 19 元快递费。
每一步推理都被显式写出。如果模型直接报答案"19 元"，你无法判断它是真的会算还是猜的；但有了推理链，你能看到它在"不足 1 公斤按 1 公斤算"这一步做了正确的向上取整，思路完全可追溯。
适用业务场景
- 数学计算与数值推理：财务报表分析、投资收益计算、风险评估模型中涉及多步运算的场景。模型需要先提取参数、再建立公式、最后求解，CoT 让每一步都可审计。
- 逻辑推理与决策分析：风控规则引擎、合规审查流程中，需要根据多条规则逐步推导结论的场景。比如"如果用户满足条件 A 且不满足条件 B，则触发规则 C"。
- 逐步分析类问题：医疗辅助诊断中根据症状逐步排除疾病、法律推理中根据法条逐步推导结论、技术故障排查中根据现象逐步定位根因。
- 教育与培训：AI 辅导系统中，不仅给出答案，还展示解题过程，帮助学生理解推理路径。
适用系统与集成方案
适配的系统类型：
- 智能报表与财务分析系统：报表不只是展示数字，而是展示"这些数字怎么来的"。用户点击任何一个指标，都能看到从原始凭证到最终报表的完整推理链。
- 风控决策引擎：每一笔贷款审批、每一次反欺诈判定，系统都绑定一条推理链，审计人员可以逐条回溯"为什么拒绝这笔申请"。
- AI 辅导与在线教育平台：学生做错题不只是看到"正确答案是 C"，而是跟着系统的推理步骤，理解"这道题应该怎么一步步推出答案"。
- 医疗辅助诊断系统：输入症状后，系统不只给出"可能是 XX 病"，还展示"从症状 → 鉴别排除 → 最可能诊断"的完整推导。
系统集成方式：
flowchart LR
A[原始数据] --> B[CoT 推理引擎]
B --> C[推理链存储]
B --> D[结论输出]
C --> E[审计 / 追溯接口]
D --> F[前端展示: 结论 + 推理过程]
style B fill:#fff9c4,stroke:#f9a825
style C fill:#f3e5f5,stroke:#7b1fa2
集成要点：
- 嵌入决策流程，而非独立模块：CoT 不是单独的"推理服务"，而是嵌入在报表查询、风控审批、诊断分析的每一个决策节点上。用户请求一次分析 → 系统返回的不只是结论，还有结构化字段
reasoning_chain。 - 推理链必须结构化存储：将推理步骤存为
[{step: 1, thought: "...", result: "..."}, ...]格式，前端可展开/折叠每一步，审计时可逐条回溯。 - 与现有规则引擎共存：CoT 不替代现有规则引擎，而是互补——规则引擎负责快速硬判定（如"金额超限直接拒绝"），CoT 负责模糊推理（如"这个交易模式看起来可疑，解释一下为什么"）。
二、Self-Ask（自问自答）
提出背景
Microsoft Research 在 2022 年的研究工作《Measuring and Narrowing the Compositionality Gap in Language Models》中提出了 Self-Ask 方法（论文标题为 Self-Ask with Search）。研究者发现，当问题需要组合多个事实才能回答时（即"组合性问题"），模型的表现会急剧下降——即使模型知道每个单独的事实，也无法正确组合它们。
核心思想
Self-Ask 解决的是**组合性鸿沟（Compositionality Gap）**问题。所谓组合性鸿沟，是指模型能够正确回答每个子问题，但当这些子问题组合成一个大问题时，模型的正确率远低于各子问题正确率的乘积。
Self-Ask 的策略是：让模型学会"反问自己"。面对一个复杂问题，模型不是试图一步到位地回答，而是先判断"要回答这个问题，我需要先知道什么？"，然后把这个大问题拆解成一系列后续问题（follow-up questions），逐个回答后再组合成最终答案。
与 CoT 的关键区别在于：CoT 是线性的推理链——每一步都是上一步的自然延伸；Self-Ask 则是问题分解——把一个需要多跳推理的问题拆成多个独立的子问题，每个子问题可以独立查询和回答。更关键的是，Self-Ask 通常会配合外部检索（如搜索引擎）使用：每提出一个 follow-up question，就去检索答案，然后再基于检索结果提出下一个问题。
这种模式特别适合事实链路长的问题——答案需要串联多个事实，而每个事实可能不在模型的训练数据中。
流程图
flowchart TD
A[用户提出复杂问题] --> B{是否需要<br/>分解？}
B -->|是| C[生成后续问题1]
C --> D[检索/回答后续问题1]
D --> E{是否还需要<br/>更多信息？}
E -->|是| F[生成后续问题2]
F --> G[检索/回答后续问题2]
G --> H{是否还需要<br/>更多信息？}
E -->|否| I[组合所有子答案]
H -->|否| I
I --> J[输出最终答案]
style A fill:#e1f5fe,stroke:#0288d1
style J fill:#c8e6c9,stroke:#388e3c
style C fill:#fff3e0,stroke:#ef6c00
style F fill:#fff3e0,stroke:#ef6c00
style D fill:#f3e5f5,stroke:#7b1fa2
style G fill:#f3e5f5,stroke:#7b1fa2
场景示例
问题：埃隆·马斯克创办的第一家公司的市值现在是多少？
Self-Ask 过程：
问：埃隆·马斯克创办的第一家公司是什么？
→ 检索结果：1996 年，马斯克与弟弟金巴尔·马斯克共同创办了 Zip2，
一家为报纸提供在线城市指南和商业目录的公司。
追问：Zip2 公司后来怎么样了？现在还上市吗？
→ 检索结果：1999 年，康柏（Compaq）以约 3.07 亿美元收购了 Zip2，
之后被整合进康柏的 AltaVista 业务中，目前已不是独立公司。
追问（调整方向）：既然已经被收购了，那它被收购时的价值是多少？
→ 检索结果：Zip2 被康柏以 3.07 亿美元收购，其中马斯克获得约 2200 万美元。
组合答案：马斯克的第一家公司 Zip2 目前已不存在独立上市，
1999 年被康柏以约 3.07 亿美元收购。
这个例子展示了 Self-Ask 的灵活性——当第一个追问发现"Zip2 已经不是独立公司"后，模型没有死板地继续追问"市值"，而是动态调整了追问方向，去查"被收购时的价值"。这正是 Self-Ask 相比固定流程的优势：它能根据每一步的检索结果灵活生成下一步追问，而非硬编码的查询流水线。
适用业务场景
- 多跳知识问答：企业知识库中，用户的问题常常需要串联多个文档的信息。比如"我们公司华东区去年Q4营收最高的产品线是什么？它的利润率是多少？"需要先查营收数据，再定位产品线，最后查利润率。
- 事实链路长的信息检索：竞品分析中需要"竞品 A 的母公司是谁 → 母公司的最新财报怎么说 → 财报中提到的战略方向是什么"这样的多跳查询。
- 合规与尽调：背景调查、尽职调查中，需要串联工商信息、司法信息、关联关系等多源数据，Self-Ask 可以自动拆解查询路径。
- 客服与智能问答：用户提问"我的订单什么时候到？"需要先查订单号 → 查物流状态 → 查预计送达时间，Self-Ask 能自动完成这个拆解。
适用系统与集成方案
适配的系统类型：
- 企业智能客服系统：用户问"我的订单什么时候到？"→ Self-Ask 自动拆解为"查订单号 → 查物流 → 算预计送达"。不再只是关键词匹配式的 FAQ 应答，而是真正理解用户的复合查询需求。
- 企业知识库问答平台：知识分散在多个文档库、Wiki、规章制度中，Self-Ask 将复杂问题拆成多个子问题，分别检索不同知识源后合成答案，解决"一个问题的答案藏在三个文档里"的困境。
- 合规与尽调系统：输入一个企业名 → 自动拆解为"工商信息 → 司法风险 → 关联关系 → 舆情"四个子查询，并行调用天眼查、裁判文书、企查查等接口，最终汇总为尽调摘要。
- 竞品情报分析平台：输入"竞品 X 的最新动态"→ 拆解为"产品更新 → 融资动态 → 人事变动 → 市场活动"，按维度检索和汇总。
系统集成方式：
flowchart TD
A[用户提问] --> B[Self-Ask 问题分解器]
B --> C1[子问题 1: 查订单]
B --> C2[子问题 2: 查物流]
B --> C3[子问题 3: 预计时间]
C1 --> D1[订单系统 API]
C2 --> D2[物流查询 API]
C3 --> D3[时效计算引擎]
D1 --> E[答案合成器]
D2 --> E
D3 --> E
E --> F[最终回答]
style B fill:#fff3e0,stroke:#ef6c00
style E fill:#f3e5f5,stroke:#7b1fa2
style F fill:#c8e6c9,stroke:#388e3c
集成要点：
- 子问题与数据源映射：在系统中维护一张"问题类型 → 数据源"的映射表。Self-Ask 分解出的每个子问题带上类型标签，调度器根据类型将子问题路由到对应的业务 API 或搜索引擎。
- 答案合成不是拼积木：合成器不是把子答案简单拼在一起，而是做"去重、冲突消解、信息补全"。比如子问题 A 说"Zip2 市值为 0"，子问题 B 说"Zip2 已被收购"，合成器需要输出"Zip2 已不存在独立市值，被收购时估值 3.07 亿美元"。
- 渐进式渲染提升体验：前端展示时不必等所有子问题都回答完。每个子问题有了答案就实时推送——用户看到的是"正在查你的订单号... ✅ 找到了 → 正在查物流... ✅ 在路上了 → 预计明天下午 3 点送达"，体验比"转圈 5 秒然后出结果"好得多。
三、ReAct（推理 + 行动）
提出背景
Princeton 大学与 Google Research 在 2022 年联合发表论文《ReAct: Synergizing Reasoning and Acting in Language Models》，提出了 ReAct 框架。这是 Agent 领域最具影响力的论文之一，至今仍是大多数 Agent 框架的底层范式。
核心思想
在 ReAct 之前，CoT 和 Self-Ask 主要解决"怎么想"的问题，但它们有一个共同的局限：模型只能基于自身参数中存储的知识进行推理，无法与外部世界交互。如果模型不知道某个事实，或者事实已经发生变化（比如实时天气、最新新闻），纯推理模式就无能为力。
ReAct 的核心创新在于：让模型在推理（Reasoning）和行动（Acting）之间交替进行。具体来说，模型在每一步都会做两件事：
- Thought（思考）：模型推理当前状态，决定下一步应该做什么。比如"用户问杭州昨天的天气，我不知道这个信息，需要调用天气 API 查询"。
- Action（行动）：模型执行一个具体动作，比如调用搜索引擎、查询数据库、调用 API。行动的结果作为新的观察（Observation）反馈给模型。
- Observation（观察）：模型接收行动的返回结果，基于这个新信息进行下一轮思考。
这个 Thought → Action → Observation 的循环可以反复进行，直到模型认为已经收集了足够的信息来回答问题。
ReAct 比 CoT 和 Self-Ask 更全能的根本原因在于：它不仅是一个推理模式，更内建了与外部世界交互的闭环。CoT 只能"想"，Self-Ask 虽然能"查"但流程相对固定，而 ReAct 可以根据每次行动的反馈动态调整后续策略——如果搜索结果不理想，它可以换一个关键词重新搜索；如果 API 返回错误，它可以分析错误并尝试修复。
正是这种"思考-行动-观察"的闭环，使 ReAct 成为当前主流 Agent 框架（LangChain、LangChain4j、LlamaIndex、Dify、Spring AI Alibaba 等）的默认执行范式。
流程图
flowchart TD
A[用户输入问题] --> B[Thought: 分析问题<br/>判断需要什么信息]
B --> C{是否已有<br/>足够信息？}
C -->|是| D[生成最终答案]
C -->|否| E[Action: 选择并调用工具<br/>搜索/查询API/读数据库]
E --> F[Observation: 获取工具返回结果]
F --> B
style A fill:#e1f5fe,stroke:#0288d1
style D fill:#c8e6c9,stroke:#388e3c
style B fill:#fff9c4,stroke:#f9a825
style E fill:#ffcdd2,stroke:#c62828
style F fill:#f3e5f5,stroke:#7b1fa2
场景示例
问题：帮我查一下现在北京的空气质量，如果不适合户外活动的话，帮我推荐几个室内好去处。
ReAct 执行过程：
Thought: 用户想知道北京当前的空气质量。我需要调用天气/空气质量 API
获取实时数据，网上搜不到"现在"的数据。
Action: 调用空气质量查询工具
→ 参数: city=北京
Observation: 北京当前 AQI 172，PM2.5 125μg/m³，属于"中度污染"。
建议减少户外活动，敏感人群避免外出。
Thought: AQI 172 中度污染，确实不适合户外活动。需要给用户推荐室内去处。
但我不知道北京具体有什么好的室内场所，需要搜索一下。
Action: 搜索"北京室内游玩推荐 商圈 博物馆 商场"
→ 调用搜索引擎
Observation: 搜索结果显示——
1. 三里屯太古里（购物+餐饮）
2. 中国国家博物馆（免费预约参观）
3. 798 艺术区室内展馆（当代艺术展览）
4. 合生汇（购物中心+室内卡丁车）
5. 王府井 APM（购物+电影院）
Thought: 现在有了足够信息。结合空气质量数据（AQI 172 中度污染）
和室内去处推荐，可以给用户一个综合回复了。
Final Answer: 北京当前空气质量为中度污染（AQI 172，PM2.5 125μg/m³），
确实不太适合户外活动。这里推荐几个室内好去处：
① 中国国家博物馆——免费但需提前预约，地铁直达
② 798 艺术区室内展馆——正在举办多个当代艺术展
③ 三里屯太古里/王府井 APM——逛吃加看电影一条龙
④ 合生汇——有室内卡丁车，适合想活动一下的朋友
出门记得戴口罩哦！
这个例子展示了 ReAct 的核心价值：模型不止于"思考"——它主动调用工具获取真实的实时数据，根据工具返回结果动态调整后续行动（空气质量不好 → 改推室内），整个过程是一个完整的"感知-决策-行动"闭环。
适用业务场景
- 实时信息查询与决策：任何需要最新数据的场景——股票行情查询、天气查询、新闻摘要、航班状态查询。模型"知道"自己不知道实时信息，主动调用 API 获取。
- 多工具编排与 API 调用：企业内部的智能助手需要调用多个系统 API（CRM、ERP、OA），ReAct 让模型根据任务需要自主选择和组合工具调用顺序。
- 数据分析与报表生成：模型先思考"需要哪些数据"，调用数据库查询工具获取数据，再思考"如何分析"，调用分析工具或编写代码处理，最后生成报表。
- 运维故障排查：Agent 接到告警后，先分析告警信息，调用监控 API 查看指标，再根据异常指标调用日志查询工具，定位根因后给出修复建议。
- 智能客服与技术支持：用户描述问题后，Agent 先理解问题，查询知识库获取解决方案，如果需要还可以调用工单系统、查看用户订单状态等。
适用系统与集成方案
适配的系统类型：
- 企业统一智能助手：打通企业内部的 CRM、ERP、OA、邮件、日历等系统。员工说"帮我查一下陈总的合同审批到哪了，顺便约他明天下午开会"——ReAct 自动判断需要调合同系统 → 查日历 → 发会议邀请，一次对话完成跨系统操作。
- 智能运维平台（AIOps）：系统告警触发 Agent → Thought: "CPU 飙升 85%，需要排查" → Action: 调用 Prometheus 查指标 → Observation: "服务 A 的 QPS 也翻了 3 倍" → Action: 查服务 A 的日志 → 定位到慢 SQL → 给出修复建议并自动创建工单。
- 数据分析与 BI 平台：用户用自然语言问"上个月华东区毛利率为什么降了 3 个点？"→ ReAct 自动写 SQL → 查数据 → 分析趋势 → 关联影响因素 → 输出分析报告。用户不需要打开 SQL 编辑器。
- 智能客服工单系统：用户报修后，Agent 不只给标准回复，而是自动查设备型号、查故障历史、查库存备件，给出"工程师带 XX 型号备件 + 预计 2 小时内到场"的完整方案。
系统集成方式：
flowchart TD
A[用户输入] --> B[ReAct 循环引擎]
B --> C{Thought: 需要什么?}
C --> D[工具注册中心 / API 网关]
D --> E1[CRM 系统]
D --> E2[ERP 系统]
D --> E3[OA 审批]
D --> E4[监控系统]
D --> E5[数据库查询]
E1 & E2 & E3 & E4 & E5 --> F[Observation: 结果汇总]
F --> C
F --> G[最终回复]
style B fill:#ffcdd2,stroke:#c62828
style D fill:#fff9c4,stroke:#f9a825
style G fill:#c8e6c9,stroke:#388e3c
集成要点：
- 工具注册中心是核心枢纽：ReAct 不直接调用各业务系统 API，而是通过统一的工具注册中心。每个工具声明"名称、描述、参数 schema、调用地址"，ReAct 引擎根据 Thought 自动匹配合适的工具。这正是 LangChain4j 的
@Tool和 Spring AI 的@Tool注解背后的设计逻辑。 - 权限边界必须前置：生产环境中，ReAct Agent 调用工具必须经过权限网关。在工具注册中心为每个工具标注所需权限级别，Agent 执行 Action 前由网关拦截校验——不能让 AI 随意调用所有 API。
- 可观测性是底线：每一轮 Thought → Action → Observation 都记录到日志系统（时间戳、耗时、工具名、参数、返回摘要、Token 消耗）。出问题时能快速回溯"Agent 在哪一步做了错误判断"，而不是对着一个最终结果猜原因。
四、Plan-and-Execute（计划与执行）
提出背景
Plan-and-Execute 模式出现在 2023 年前后的 Agent 应用开发框架实践中，主要源自 LangChain 社区的工程实践。它并非某一篇学术论文的产物，而是对 ReAct 模式在复杂长任务场景下局限性的工程改进。
核心思想
ReAct 模式在简单任务上表现出色，但面对复杂的多步骤任务时存在一个显著问题：模型在每一步都重新推理"下一步该做什么"，缺乏全局规划。这导致两个后果——一是容易在中间步骤"跑偏"，偏离原始目标；二是反复推理带来大量 token 消耗和延迟。
Plan-and-Execute 的解法是把任务拆成两个明确阶段：
第一阶段——Planning（计划）：模型先通览整个任务，生成一个完整的步骤计划。这个计划是一系列有序的子任务列表，每个子任务都是具体、可执行的。比如"写一篇新能源车的市场调研报告"会被拆成"收集销量数据 → 分析政策趋势 → 总结消费者反馈 → 撰写结论"这样的步骤序列。
第二阶段——Execution（执行）：按照计划逐条执行每个子任务。每个子任务的执行可以采用任何合适的策略——可以是简单的 LLM 调用，也可以是 ReAct 循环，还可以是调用外部工具。关键在于，执行阶段不需要反复推理"接下来做什么"，因为计划已经确定。
这种分离带来的好处是显而易见的：计划阶段可以专注于"全局最优"的任务分解，执行阶段可以专注于"局部最优"的子任务完成。同时，如果某个子任务执行失败，只需要重新执行该子任务，而不需要推翻整个计划。
进阶版本还支持动态重规划（Re-planning）：在执行过程中如果发现计划不合理（比如某个子任务无法完成，或者执行结果改变了后续前提），可以回到计划阶段进行调整。
流程图
flowchart TD
A[用户下达复杂任务] --> B[Planning 阶段<br/>生成完整计划]
B --> C[计划: 子任务1]
B --> D[计划: 子任务2]
B --> E[计划: 子任务3]
B --> F[计划: 子任务N]
C --> G[执行子任务1]
G --> H{执行成功？}
H -->|是| D
H -->|否| I[重试/调整]
D --> J[执行子任务2]
J --> K{执行成功？}
K -->|是| E
K -->|否| L[重试/调整]
E --> M[执行子任务3]
M --> N[...继续执行]
N --> O[所有子任务完成]
O --> P[整合结果输出]
Q{需要重规划？} -.->|是| B
style A fill:#e1f5fe,stroke:#0288d1
style B fill:#fff9c4,stroke:#f9a825
style P fill:#c8e6c9,stroke:#388e3c
style O fill:#c8e6c9,stroke:#388e3c
场景示例
任务：帮我策划一场 30 人的户外生日派对，预算 3000 元。
Planning 阶段：
计划生成：
1. 根据预算和人数，确定合适的场地类型和候选方案
2. 制定餐饮方案（自助烧烤 or 外卖简餐 or 冷餐摆台）
3. 策划活动流程（游戏环节 + 歌曲 + 切蛋糕）
4. 列出物资采购清单（装饰、餐具、饮料、蛋糕）
5. 制定时间安排表（从下午开始到晚上结束）
6. 生成最终方案文档，附带预算明细
Execution 阶段：
执行步骤 1：搜索"北京 30人户外派对场地"
→ 对比公园草坪（免费）、露营营地（人均30元）、民宿庭院（包场1500元）
→ 选择：露营营地（900元 / 30人）+ 自带帐篷区，性价比最高
执行步骤 2：制定餐饮方案
→ 对比三种方案后选择"自助烧烤"：食材批发约600元 + 饮料200元
执行步骤 3：策划活动流程
→ 14:00-14:30 签到合影 → 14:30-16:00 团队游戏 → 16:00-17:30 烧烤
→ 17:30-18:00 唱歌切蛋糕 → 18:00-19:00 自由活动拍照
执行步骤 4：物资清单
→ 装饰（气球+横幅+照片墙）150元、一次性餐具120元、
蛋糕定制300元、饮料200元、零食150元、小礼品200元
执行步骤 5：预算汇总
→ 场地900 + 食材600 + 饮料200 + 装饰150 + 餐具120 +
蛋糕300 + 零食150 + 小礼品200 + 应急备用预算280 = 总计2900元
✓ 未超出3000元预算
执行步骤 6：生成最终方案文档（包含场地地址、采购链接、时间表、预算明细）
（如果步骤1中露营营地订满 → 切换候选方案，重新算预算，其他步骤不受影响）
Plan-and-Execute 在这里的优势很明显：先用 5 秒生成全局计划，用户一眼就看清"整个派对怎么搞"；然后再逐条执行细节，每步独立验证——如果露营营地满了，换一个方案就行，不会推翻整个策划。
适用业务场景
- 长流程内容生成：市场调研报告、行业分析报告、技术方案文档、产品 PRD 文档。这些任务步骤多、耗时长，需要先规划结构再逐段填充。
- 数据处理流水线：ETL 任务、数据清洗与分析流水线。先规划数据处理步骤（抽取→清洗→转换→加载→分析），再逐步执行，每步可独立验证。
- 自动化运维流程：系统部署、灰度发布、故障恢复等运维场景。先制定操作计划，再逐步执行，每步执行后检查状态，确保安全。
- 项目管理与任务分解：把大型项目自动拆解为可执行的子任务列表，分配给不同的执行者或自动化流程。
- 多步骤研究与调研：学术研究中的文献综述、竞品分析中的多维对比、投资尽调中的多维度核查，都需要先规划调研框架再逐项深入。
适用系统与集成方案
适配的系统类型：
- 自动化部署与发布平台：用户提交"把用户中心服务发布到生产环境"→ Plan Agent 生成"环境检查 → 灰度发布 10% → 监控 5 分钟 → 全量发布 → 回归测试 → 通知"六步计划 → Execute Agent 逐步执行，每步独立验证。失败了只重试失败那一步，不用推翻整个流程。
- AI 文档生成系统：用户说"写一份 Q2 季度技术复盘报告"→ Plan Agent 生成大纲（业务目标回顾 → 技术成果 → 问题与教训 → 下季度规划）→ 用户确认或调整 → Execute Agent 逐段填充内容，每段产出可独立审核。
- ETL 数据处理流水线：数据工程师配置"从 MySQL 抽取订单数据 → 清洗去重 → 转换字段格式 → 加载到 ClickHouse → 跑数据质量检查"→ Plan 生成 DAG（有向无环图），Execute 按依赖关系执行，上一步失败自动阻断下游。
- 多步骤自动化测试平台：测试场景"用户注册 → 登录 → 下单 → 支付 → 查看订单"→ Plan 拆为 5 个测试步骤 → Execute 按顺序跑，每步失败时自动截图保存上下文，方便定位。
系统集成方式：
flowchart TD
A[用户任务输入] --> B[Plan Agent]
B --> C[步骤计划<br/>可人工审核调整]
C --> D[Execute Agent]
D --> E1[步骤 1: ReAct 执行]
E1 --> E2[步骤 2: ReAct 执行]
E2 --> E3[步骤 3: ReAct 执行]
E3 --> F{需要重规划?}
F -->|是| B
F -->|否| G[结果汇总输出]
subgraph 步骤状态追踪
H[(任务状态存储<br/>Redis / DB)]
end
E1 -.-> H
E2 -.-> H
E3 -.-> H
style B fill:#fff9c4,stroke:#f9a825
style D fill:#ffcdd2,stroke:#c62828
style G fill:#c8e6c9,stroke:#388e3c
集成要点：
- 计划必须可审核，不能是黑箱：Plan Agent 生成计划后，必须给用户（或自动化审批规则）一个确认/调整的机会，通过后才进入 Execute。这是企业环境的红线——不能让 AI 自主决定"怎么改生产环境"。
- 步骤状态必须持久化：长任务可能执行几十分钟甚至几小时，必须用 Redis 或数据库记录每步状态（pending → running → success → failed），支持断点续传。运维平台上常见"执行到第 4 步时容器重启了，重启后从第 4 步继续"的场景。
- 动态重规划是灵魂：如果步骤 3 执行失败，不应该从头重来。应该触发 Re-plan："步骤 3 因为 XX 原因失败了，请根据新情况重新规划剩余步骤"。这是 Plan-and-Execute 相比固定脚本的核心优势。
五、Tree of Thoughts（ToT，树状思维）
提出背景
Princeton 大学和 Google DeepMind 在 2023 年联合发表论文《Tree of Thoughts: Deliberate Problem Solving with Large Language Models》。论文灵感来源于认知科学中人类"系统2思维"（System 2 thinking）的理论——人类在解决复杂问题时，会探索多条思路，评估各种可能性，必要时回溯重来，而不是一条路走到底。
核心思想
CoT 是线性推理——一条链走到底。这在简单问题上够用，但面对真正复杂的问题（比如解谜、博弈、创意规划），单线推理的局限性很明显：如果某一步走错了方向，整条链就全错了，而且没有回头路。
ToT 的核心思想是：不是单线思维，而是生成多条思路分支，像树一样展开。具体来说：
- 思维分解（Thought Decomposition）：把问题求解过程分解为一系列中间"思维步骤"（thought），每个 thought 是一个有意义的问题解决中间状态。
- 思维生成（Thought Generation）：在每个节点，生成多个候选的下一步 thought（比如 3-5 个），形成树的分支。
- 状态评估（State Evaluation）：对每个分支的当前状态进行评估——这个方向是否有希望？评估可以由模型自身完成（"这个思路看起来合理/不太行"），也可以通过外部反馈完成。
- 搜索算法（Search Algorithm）：使用树搜索算法（BFS 广度优先、DFS 深度优先、beam search 等）在思维树中探索，根据评估结果剪枝，最终找到最优路径。
ToT 与 CoT 的关系可以类比为：CoT 是"走一条路"，ToT 是"看地图选最优路线"。ToT 的代价是计算成本更高（需要多次 LLM 调用），但在真正需要"深思熟虑"的场景下，这个代价是值得的。
流程图
flowchart TD
A[问题输入] --> B[初始状态]
B --> C1[思路 A]
B --> C2[思路 B]
B --> C3[思路 C]
C1 --> D1[思路 A-1]
C1 --> D2[思路 A-2]
C2 --> D3[思路 B-1]
C2 --> D4[思路 B-2]
C3 --> D5[思路 C-1]
D1 --> E1{评估: 有希望？}
D2 --> E2{评估: 有希望？}
D3 --> E3{评估: 有希望？}
D4 --> E4{评估: 有希望？}
D5 --> E5{评估: 有希望？}
E1 -->|否| X1[剪枝 ✂]
E2 -->|是| F1[继续展开]
E3 -->|是| F2[继续展开]
E4 -->|否| X2[剪枝 ✂]
E5 -->|否| X3[剪枝 ✂]
F1 --> G1[...继续搜索]
F2 --> G2[...继续搜索]
G1 --> H[找到最优解]
G2 --> H
style A fill:#e1f5fe,stroke:#0288d1
style H fill:#c8e6c9,stroke:#388e3c
style X1 fill:#ffcdd2,stroke:#c62828
style X2 fill:#ffcdd2,stroke:#c62828
style X3 fill:#ffcdd2,stroke:#c62828
style B fill:#fff9c4,stroke:#f9a825
场景示例
问题：从北京去成都玩 4 天，预算 2500 元，怎么安排行程又省钱又好玩？
ToT 过程：
初始状态：北京→成都，4天3晚，预算2500元
第1层思维生成（出行方式）：
思路 A：高铁往返（二等座约 780×2=1560 元，单程约 7.5 小时）
思路 B：飞机往返（提前订特价票约 600×2=1200 元，单程约 3 小时）
思路 C：硬卧火车（约 350×2=700 元，单程约 23 小时）
评估（综合考虑预算和时间）：
思路 A → 交通占预算 62%，剩余 940 元用于住宿餐饮 → ❌ 太紧
思路 B → 交通占预算 48%，剩余 1300 元，时间也最省 → ✅ 最佳
思路 C → 交通占预算 28%，但往返近 46 小时在路上 → ❌ 玩的时间太少
保留思路 B，继续展开 ↓
第2层思维生成（住宿 + 行程）：
思路 B-1：住青旅（50 元/晚 = 150 元），景点全走经典线
（宽窄巷子+锦里+大熊猫基地+都江堰）
思路 B-2：住经济型酒店（150 元/晚 = 450 元），
重美食体验（火锅+串串+小吃打卡+川剧变脸）
思路 B-3：住民宿（100 元/晚 = 300 元），
自然+人文混搭（青城山+大熊猫基地+川博+火锅）
评估（综合预算、体验丰富度）：
思路 B-1 → 酒店太差，影响体验 → ❌
思路 B-2 → 总花费 1200+450+650（吃喝+门票）= 2300 元，体验好 → ✅
思路 B-3 → 只有吃火锅单调 → ⚠️ 可优化
保留 B-2，继续展开 ↓
第3层思维生成（美食路线细化）：
B-2-1：Day1 太古里+锦里小吃 → Day2 大熊猫基地+晚餐火锅
→ Day3 宽窄巷子+串串+川剧 → Day4 人民公园+采耳+返程
B-2-2：Day1 落地休整+川博 → Day2 青城山一日游
→ Day3 大熊猫基地+建设路小吃 → Day4 宽窄巷子+返程
评估（行程节奏、体力消耗）：
B-2-1 → 节奏轻松，体验层次丰富，不累 → ✅ 最佳！
最终方案选定 B-2-1：
交通 1200 + 住宿 450 + 吃喝 450 + 门票 200 + 其他 200 = 总计 2500 元
行程充实不赶路，美食打卡全覆盖，预算刚好卡住 ✓
这里的关键是：ToT 不是只规划一条路然后执行，而是同时展开多条分支，通过"评估"这个关卡及时砍掉不靠谱的方向（硬卧太费时间、青旅体验太差），把算力集中在最有希望的分支上。就好像有个军师帮你同时盘算了 9 种方案，最后挑出最优解。
适用业务场景
- 复杂规划与决策：战略规划、项目方案设计、资源分配优化。这些问题往往有多条可能的路径，需要评估各路径的可行性和收益，选出最优方案。ToT 可以系统性地探索多种策略组合。
- 解谜与约束满足问题：排班调度、路径规划、资源分配等约束优化问题。这些问题有明确的约束条件，ToT 可以通过评估约束满足情况来剪枝。
- 创意生成与方案探索：产品设计中的头脑风暴、营销方案的多维探索、技术架构的多方案对比。ToT 可以生成多种创意方向，评估后选择最优的深入展开。
- 博弈与对抗策略：游戏 AI、谈判策略、竞品应对策略。需要在多个可能的对手反应分支中搜索最优应对方案。
- 代码生成与调试：面对复杂编程问题，生成多种实现方案，评估各方案的复杂度、性能、可维护性，选择最优实现。调试时也可以尝试多条推理路径来定位 bug。
适用系统与集成方案
适配的系统类型：
- 智能排班调度系统：输入约束条件（人员可用性、技能匹配、工时法规、业务峰谷），ToT 同时探索多种排班方案，通过评估函数（合规性 × 效率 × 员工满意度）剪枝，最终输出最优排班表，并附上"为什么没选另外两种方案"的说明。
- 物流路径规划系统：输入"100 个配送点、5 辆车、时间窗口约束"，ToT 同时探索多种路径组合，评估总里程、时效性、车辆负载均衡，选出最优调度方案。
- 技术架构选型决策系统：输入业务需求，ToT 同时生成"单体架构方案"、"微服务方案"、"Serverless 方案"三个分支，从成本、可维护性、扩展性、团队能力多维度评估，推荐最优方案并解释取舍逻辑。
- AI 辅助编程工具：面对"实现一个高并发秒杀系统"，ToT 同时生成多种架构思路（Redis 预减库存 + MQ 异步下单、数据库行级锁、纯 Redis Lua 脚本），评估并发容量、数据一致性、实现复杂度后选择最优路径并展开编码。
系统集成方式：
flowchart TD
A[约束 / 需求输入] --> B[ToT 搜索引擎]
B --> C[第 1 层: 生成 N 个候选分支]
C --> D[评估器: 对每个分支打分]
D --> E{剪枝: 保留 Top-K}
E --> F[第 2 层: 对保留分支继续展开]
F --> D
E -->|达到终止条件| G[最优方案输出]
subgraph 评估维度配置
H[成本权重]
I[效率权重]
J[风险权重]
K[合规权重]
end
D -.-> H & I & J & K
style B fill:#fff9c4,stroke:#f9a825
style D fill:#f3e5f5,stroke:#7b1fa2
style G fill:#c8e6c9,stroke:#388e3c
集成要点：
- 评估函数是 ToT 的灵魂：ToT 的好坏 90% 取决于评估函数的准确度。在实际系统中，评估函数应该是"规则引擎 + LLM 自评"的混合体——硬性约束（如工时不超过 40 小时/周）用规则引擎硬剪枝，软性指标（如方案美感、用户体验）用 LLM 评分。
- 控制搜索成本是刚需：每多一层分支，LLM 调用量指数增长。实际系统必须配置"最大探索宽度 K"（每层保留几个分支）和"最大探索深度 D"（最多展开几层）。典型业务配置：K=3、D=5，一共 15 次 LLM 调用，成本可控。
- 结果必须可解释：用户需要看到的不只是最终方案，还有"另外两个方案为什么被淘汰"——ToT 需要输出完整的剪枝原因（"方案 B 虽然成本最低，但物流超时率达 15%，不符合 SLA 要求"）。
六、Reflexion / Iterative Refinement（反思与迭代优化）
提出背景
2023 年论文《Reflexion: Language Agents with Verbal Reinforcement Learning》提出了 Reflexion 框架。这篇论文的核心贡献是提出了一种"语言强化学习"（Verbal Reinforcement Learning）的概念——不通过梯度更新模型参数，而是通过自然语言形式的自我反思来改进模型行为。
核心思想
传统 Agent 的问题是：犯了错不知道为什么错，下次还会犯同样的错。即使是强大的 LLM，在复杂任务中也会犯错——代码有 bug、推理有漏洞、回答有偏差。如果 Agent 只是简单地"重试"，没有总结失败原因，那么重试的结果很可能还是错的。
Reflexion 的核心思想是赋予 Agent 自我纠错的能力，关键在于"反思"这一步：
- 执行（Act）：Agent 尝试完成任务，产生一个输出或行动。
- 评估（Evaluate）：通过外部反馈（如编译器报错、测试用例结果、用户反馈）或自我评估，判断输出是否正确。
- 反思（Reflect）：如果输出有误，Agent 不只是知道"错了"，而是用自然语言总结"为什么错了"——"函数参数类型搞混了"、"边界条件没考虑到"、"搜索关键词太宽泛导致结果不相关"。
- 重试（Retry）：带着反思总结重新尝试，这次有了前次失败的教训，成功率会显著提升。
这个 Act → Evaluate → Reflect → Retry 的循环可以反复进行，直到任务成功或达到最大重试次数。每一次反思都作为"语言记忆"累积下来，指导后续尝试。
与传统的强化学习（通过梯度更新参数来学习）不同，Reflexion 是通过自然语言反馈来改进——模型不变，但上下文中多了"上次失败的经验教训"。这种方式不需要重新训练模型，只需要在 prompt 中加入反思记录即可，工程上非常轻量。
流程图
flowchart TD
A[接收任务] --> B[第1次尝试]
B --> C[生成输出]
C --> D{评估: 是否正确？}
D -->|是| E[任务完成 ✓]
D -->|否| F[反思: 分析失败原因]
F --> G[记录经验教训]
G --> H{重试次数<br/>是否超限？}
H -->|否| I[第2次尝试<br/>带着反思经验]
I --> C
H -->|是| J[任务失败<br/>转人工处理]
subgraph 反思记忆区
K[第1次失败教训:<br/>参数类型搞混了]
L[第2次失败教训:<br/>边界条件遗漏]
M[累积的经验...]
end
G -.-> K
K -.-> I
style A fill:#e1f5fe,stroke:#0288d1
style E fill:#c8e6c9,stroke:#388e3c
style J fill:#ffcdd2,stroke:#c62828
style F fill:#fff9c4,stroke:#f9a825
style G fill:#fff9c4,stroke:#f9a825
场景示例
任务：帮我一封回复，客人说快递到的蛋糕盒子压坏了，要求退款。我们是手工蛋糕店，每个蛋糕都有配送保险。
Reflexion 过程：
=== 第1次尝试 ===
生成的回复：
"您好，非常抱歉给您带来不便。根据我们的配送保险条款，
蛋糕在运输过程中损坏的情况，我们会全额退款。请您提供
订单号和蛋糕的损坏照片，我们核实后立即处理。感谢您的理解。"
评估（客户视角）：❌ 回复太机械、像模板——客人吃到的是情绪（生日的期待落空了），
但回复里没有任何共情，冷冰冰地走流程。
=== 反思 ===
分析失败原因：只陈述了"理赔流程"，完全没有回应客人的情绪。
客人买蛋糕不是为了被"流程处理"，是为了体面地过生日。
教训：先共情 → 再承认失误 → 再给补偿 → 最后给承诺。
=== 第2次尝试（带着反思经验）===
生成的回复：
"看到这个画面真的太心疼了！蛋糕是我们花了好几个小时亲手做的，
寄出去的时候可是完完整整的——快递路上摔了一下，把您的惊喜
都摔没了，这个确实是我们做得不够好。
今年的生日蛋糕我们全额退款，钱会在 24 小时内原路退回。
另外，下次您来订蛋糕，我们直接给您打 5 折，而且这次一定
要求快递当面签收、开箱验货，不能再让这种事情发生了。
希望没有太破坏您今天的心情，生日快乐呀 🎂"
评估：✅ 先共情（"心疼"）→ 归因但不推诿（快递问题但我们来赔）
→ 补偿超出预期（退款+下次五折）→ 流程改进承诺 → 祝福收尾
有温度、有担当、有行动。
任务完成！
Reflexion 的价值在这里体现得非常直观——第 1 次和第 2 次的差距本质不是模型能力的问题，而是有了"上次太像机器客服了"这条反思经验后，模型知道自己问题在哪，下一次能定向改进。这种"语言记忆"的成本极低——不需要重新训练模型，只需要在 prompt 上下文里加上一行反思总结。
适用业务场景
- 代码生成与自动修复：AI 编程助手生成代码后自动运行测试，如果报错则分析错误信息并修正。Cursor、Copilot 等 AI 编程工具的"自动修复"功能本质就是 Reflexion。在企业内部，可用于 CI/CD 流水线中的自动修复。
- 文档写作与内容打磨：AI 写作后通过自评或他评发现不足（逻辑不连贯、论据不充分、语言不流畅），反思后修改优化。适用于技术文档、营销文案、报告的自动生成与迭代。
- 数据分析与结果验证：Agent 完成数据分析后，检查结果是否合理（数据是否异常、结论是否站得住脚），如果发现问题则反思数据质量或分析方法，重新分析。
- 流程执行与异常恢复：自动化流程执行中遇到异常，Agent 分析异常原因，调整策略后重试。比简单的"重试 3 次"智能得多，因为每次重试都带着对上次失败的理解。
- 对话系统与客服：Agent 回答用户问题后，如果用户表示不满意或追问，Agent 反思"是不是我理解错了用户意图"，调整理解后重新回答。
适用系统与集成方案
适配的系统类型：
- CI/CD 自动修复流水线：代码提交 → 自动构建 → 运行测试 → 测试失败？→ Reflexion Agent 分析报错原因 → 生成修复补丁 → 自动提交修复代码 → 重新构建。整个过程开发者只需要在 MR 里看到"自动修复了 3 个测试问题，请确认"。
- AI 写作与内容优化平台：用户说"这篇文案不太满意，太官方了"→ Reflexion 不是简单地"重新写一遍"，而是分析"哪里太官方"（用词？句式？语气？），带着具体改进方向定向优化。每一轮修改都有明确的改进锚点，而不是随机重写。
- 自动化测试生成平台：Agent 为一段代码生成单元测试 → 跑测试 → 发现覆盖率只有 65% → 反思"哪些分支没覆盖到"→ 补充边界条件和异常路径的测试用例 → 再跑 → 覆盖率达到 90%。
- 智能客服质检系统：客服 Agent 回复工单后 → 质检 Agent 评估回复质量 → 不合格 → 反思"具体哪里有问题"（态度不够好？没解决根本问题？给了错误信息？）→ 修正后重新回复，避免"换个说法重说一遍"的敷衍。
系统集成方式：
flowchart TD
A[任务输入] --> B[执行器]
B --> C[输出结果]
C --> D{评估器判断}
D -->|通过| E[任务完成]
D -->|不通过| F[Reflexion 反思引擎]
F --> G[生成反思教训]
G --> H[(教训存储<br/>向量库 / 缓存)]
H --> I[带反思重试]
I --> B
style F fill:#fff9c4,stroke:#f9a825
style H fill:#f3e5f5,stroke:#7b1fa2
style E fill:#c8e6c9,stroke:#388e3c
集成要点：
- 没有好的评估器，Reflexion 就是在瞎反思：Reflexion 的有效性完全取决于评估器质量。不同场景需要不同评估器：代码场景用测试用例结果；写作场景用 LLM 自评 + 人工打分；运维场景用监控指标和 SLA。先打磨评估器，再谈 Reflexion。
- 教训必须可积累、可复用：不要把反思只存在单次对话的上下文里。把历史教训存入向量数据库，后续类似任务可以检索相关教训。"上次写 SQL 没加索引导致慢查询"这条教训，一个月后生成新 SQL 时仍能被检索到并避免。
- 设定硬性停止条件：避免无限反思循环。设置"最大反思次数"（通常 3~5 次就够）和"反思质量下降阈值"——如果连续两次反思内容高度重复，说明到了能力天花板，停止并转人工处理。
七、Role-playing Agents（角色扮演 / 多智能体协作）
提出背景
角色扮演式智能体的概念源自 AutoGPT、ChatDev、CAMEL 等社区项目。这些项目的共同特点是：不再使用单一 Agent 完成所有工作，而是引入多个具有不同角色和职责的 Agent，通过对话协作来完成复杂任务。CAMEL（Communicative Agents Mind Exploration）论文首次系统性地研究了多智能体角色扮演的通信机制；ChatDev 将其应用于软件开发流程；AutoGPT 则展示了自主多步骤执行的雏形。
核心思想
单一 Agent 再强大，也有认知边界——它难以同时扮演产品经理、程序员、测试工程师、设计师等多种角色，因为每种角色有不同的思维模式、关注点和专业语言。
Role-playing Agents 的核心思想是：把任务拆分给不同角色的 Agent，每个 Agent 都有专属职责，通过对话协作完成任务。具体来说：
- 角色定义：为每个 Agent 分配一个明确的角色（Persona），包括它的职责、专业领域、行为准则和输出格式。比如"你是一个资深 Java 后端工程师，专注于系统架构设计，你的输出必须是技术方案文档"。
- 任务分配：将复杂任务分解为各角色负责的子任务。每个 Agent 只负责自己擅长的部分。
- 对话协作：Agent 之间通过结构化对话进行协作。一个 Agent 的输出成为另一个 Agent 的输入，形成协作链条。比如产品经理 Agent 输出需求文档 → 程序员 Agent 根据需求写代码 → 测试 Agent 根据需求和代码写测试用例 → 代码审查 Agent 审查代码质量。
- 反馈循环：下游 Agent 可以对上游 Agent 的输出提出反馈。测试 Agent 发现需求不清晰时，可以"追问"产品经理 Agent；代码审查 Agent 发现设计问题时，可以"建议"程序员 Agent 修改。
这种模式的核心价值在于专业分工和视角多样性。每个 Agent 在自己的角色框架内"思考"，产生更专业、更聚焦的输出；不同角色之间的碰撞和校验，也比单一 Agent 自我检查更容易发现问题。
流程图
flowchart TD
A[用户下达复杂任务] --> B[产品经理 Agent]
B -->|需求文档| C[架构师 Agent]
C -->|技术方案| D[程序员 Agent]
D -->|代码实现| E[测试 Agent]
E -->|测试用例 + 测试结果| F{是否通过？}
F -->|否| G[代码审查 Agent]
G -->|修改建议| D
F -->|是| H[交付完成]
E -.->|需求疑问| B
G -.->|架构建议| C
subgraph 多智能体协作团队
B
C
D
E
G
end
style A fill:#e1f5fe,stroke:#0288d1
style H fill:#c8e6c9,stroke:#388e3c
style B fill:#fff9c4,stroke:#f9a825
style C fill:#fff9c4,stroke:#f9a825
style D fill:#fff9c4,stroke:#f9a825
style E fill:#fff9c4,stroke:#f9a825
style G fill:#fff9c4,stroke:#f9a825
场景示例
任务：为公司的新智能手环产品策划一场线上发布会
多智能体协作过程：
【品牌策划 Agent】
输出发布会定位方案：
- 主题："你的第一块健康管家"——走亲民科技路线，不讲参数，讲生活
- 调性：温暖、可靠、像朋友的关心
- 目标人群：25-35 岁城市白领，关注睡眠和运动但不想太专业
- 核心故事线：一个普通上班族的健康 24 小时
↓ 传递策划方案
【内容文案 Agent】
根据定位输出文案和脚本：
- 开场视频脚本：凌晨 6 点闹钟响 → 手环记录睡眠质量 ⭐⭐⭐⭐
通勤路上久坐提醒 → 午休血氧监测 → 下班跑步心率区间 → 睡觉呼吸检测
- 产品介绍页文案：5 大健康功能，3 句讲清楚，不堆参数
- 结尾 call to action："今天下单，前 1000 名送定制表带"
↓ 传递文案脚本
【视觉设计 Agent】
根据文案输出视觉方案：
- 主色调：暖橙 + 深蓝（温暖 × 科技感）
- 主 KV 设计稿：手环特写 + "看得见的好睡眠"文案
- 产品页排版：每屏只讲一个功能，大留白，大字情感文案
- 倒计时海报 3 张（发布会前 3 天/1 天/当天）
→ 提出疑问："24 小时故事线能不能多给一个周末版本？
工作日和周末的节奏差别很大，两个版本更打动人"
↓ 反馈给内容文案 Agent
【内容文案 Agent】
收到设计师建议后补充：
- 增加"周六版本"故事线：睡到自然醒 → 晨跑推荐路线 → 朋友聚餐卡路里统计
- 继续保留"工作日版本"让目标用户二选一，A/B 测试
↓ 更新后的文案给各个 Agent
【数据分析 Agent】
根据历史发布会数据提供建议：
- 建议发布时间：周四晚 8 点（过去 8 场发布会中转化率最高时段）
- 预告周期：7 天（倒计时太长流失关注，太短蓄水不足）
- 定价策略：首发价 299，对比同类产品 349-399，有价格冲击力
↓ 反馈给品牌策划和内容文案
【品牌策划 Agent】
综合所有意见，输出最终《发布会执行手册》：
包含主题、时间线、文案脚本、视觉素材清单、投放渠道、数据监测指标
【交付完成】
这个场景展示了多智能体协作的精华——不是让一个大模型"想完所有这些"，而是让擅长品牌的人想 slogan、擅长写字的人写文案、擅长做图的人出视觉、擅长数据的人给策略。而且设计师可以对文案提出改进建议（"多加一个周末版本"），数据 Agent 可以纠正发布时间——这种跨角色的碰撞和反馈，单一 Agent 很难做到。
适用业务场景
- 软件开发全流程：从需求分析到设计、开发、测试、代码审查的完整软件生命周期。ChatDev 等项目已经证明多智能体可以完成一个简单软件项目的全流程。企业内部可用于辅助开发流程，提升各环节效率。
- 内容创作团队：模拟编辑部协作——策划 Agent 定选题、调研 Agent 收集素材、写作 Agent 撰写初稿、编辑 Agent 审校润色、SEO Agent 优化关键词。适用于媒体运营、技术博客、营销内容批量生产。
- 投资研究与决策：宏观分析师 Agent 研究经济趋势、行业分析师 Agent 分析赛道、财务分析师 Agent 评估财报、风控 Agent 评估风险，最后由投资决策 Agent 综合各方意见给出建议。
- 跨职能项目协同：大型项目中涉及产品、技术、运营、法务、财务多个职能的协同。每个职能由专门的 Agent 负责，模拟真实的项目协作流程。
- 教育与培训模拟：模拟案例教学——教师 Agent 提出问题、学生 Agent 尝试回答、点评 Agent 给出反馈。也可以模拟商务谈判、面试等场景，由不同角色 Agent 扮演不同立场。
适用系统与集成方案
适配的系统类型：
- 软件开发协作平台（ChatDev 模式）：产品经理 Agent 写 PRD → 架构师 Agent 出技术方案 → 程序员 Agent 写代码 → 测试 Agent 跑测试 → 审查 Agent 审代码。整个软件开发流水线由多 Agent 协作完成，人类开发者只需要在关键节点审核和确认。
- 内容生产流水线（自媒体矩阵）：选题 Agent 抓热点 → 调研 Agent 收集素材 → 写作 Agent 生成初稿 → 编辑 Agent 润色 → SEO Agent 优化标题和关键词 → 发布 Agent 定时推送到各平台。每天自动产出经过多角色打磨的稿件。
- 投资研究决策系统：宏观分析 Agent 研究经济周期 → 行业分析 Agent 评估赛道景气度 → 财务分析 Agent 拆解目标公司财报 → 风控 Agent 评估下行风险 → 决策 Agent 综合各方意见给出投资建议，附带分歧点和置信度。
- 企业跨部门协同平台：大型项目需要产品、技术、运营、法务、财务多方协同。每个部门用专属 Agent 代表，法务 Agent 审查合规风险 → 财务 Agent 算预算 → 产品 Agent 调整方案——模拟真实跨部门协作的链条。
系统集成方式：
flowchart TD
A[任务入口] --> B[任务分配器<br/>Orchestrator]
B --> C1[Agent 1: 产品经理<br/>Prompt + 工具集]
B --> C2[Agent 2: 架构师<br/>Prompt + 工具集]
B --> C3[Agent 3: 开发<br/>Prompt + 工具集]
B --> C4[Agent 4: 测试<br/>Prompt + 工具集]
C1 --> D[消息总线 / 事件驱动]
C2 --> D
C3 --> D
C4 --> D
D --> E[协作编排引擎]
E --> F{流程控制}
F -->|触发下一步| C1 & C2 & C3 & C4
F -->|流程结束| G[交付物组装]
style B fill:#fff9c4,stroke:#f9a825
style D fill:#f3e5f5,stroke:#7b1fa2
style G fill:#c8e6c9,stroke:#388e3c
集成要点：
- 角色定义是门槛，写好 Prompt 才算开始：每个 Agent 的 Prompt 需要包含四个核心要素——"角色定位、职责范围、输出格式、协作规则"。"你是资深产品经理"是定位，"只输出 PRD 文档（Markdown 格式）"是输出格式，"不写代码，但可以验收开发交付物"是协作规则。少了任何一项，Agent 就会越界。
- 协作流程需要状态机兜底：多 Agent 协作不是"大家随便聊"，而是有清晰的状态流转。实现方式：用编排引擎（Orchestrator）管理状态机——"产品经理输出 → 自动触发架构师 → 架构师输出 → 自动触发开发 → 开发输出 → 触发测试 → 测试失败 → 回退到开发"。没有状态机，多 Agent 就是一群没指挥的散兵。
- Agent 间传递的是交付物，不是聊天记录：用文件或数据库记录做中间存储——产品经理输出的 PRD 存为一个文档记录，架构师读取该记录后产出技术方案文档。不要把整个对话历史堆在 prompt 上下文里，否则 Token 消耗很快失控。
- 人机协作是落地红线：不要试图让多 Agent 全自动跑完整条流水线。在关键节点设置人工审核卡点——"产品经理 Agent 的 PRD，需要人类产品经理确认后才进入架构师环节"。这是企业级多 Agent 系统在生产环境中稳定运行的核心原则。
模式对比与混合使用
七种模式并非互斥，实际应用中常常组合使用。以下是常见的组合策略：
flowchart LR
subgraph 简单推理
A1[CoT]
end
subgraph 信息检索
B1[Self-Ask] --> B2[+ 搜索引擎]
end
subgraph 工具调用
C1[ReAct] --> C2[CoT 作为 Thought 引擎]
end
subgraph 复杂任务
D1[Plan-and-Execute] --> D2[每个子任务用 ReAct]
D2 --> D3[失败时用 Reflexion]
end
subgraph 深度探索
E1[ToT] --> E2[每个分支用 CoT]
end
subgraph 团队协作
F1[Role-playing] --> F2[每个角色用 ReAct]
F2 --> F3[角色间用 Reflexion 互审]
end
style A1 fill:#c8e6c9,stroke:#388e3c
style B1 fill:#c8e6c9,stroke:#388e3c
style C1 fill:#c8e6c9,stroke:#388e3c
style D1 fill:#c8e6c9,stroke:#388e3c
style E1 fill:#c8e6c9,stroke:#388e3c
style F1 fill:#c8e6c9,stroke:#388e3c
选型决策参考
| 你的场景 | 推荐模式 | 理由 |
|---|---|---|
| 数学计算、逻辑推理 | CoT | 线性推理足够，简单高效 |
| 多跳事实查询 | Self-Ask | 自动拆解问题，配合检索 |
| 需要调用工具/API | ReAct | 推理+行动闭环，动态决策 |
| 多步骤长任务 | Plan-and-Execute | 先规划全局，再逐步执行 |
| 解谜/复杂规划 | ToT | 多分支探索，评估择优 |
| 需要自我纠错 | Reflexion | 反思失败原因，迭代改进 |
| 跨职能复杂项目 | Role-playing | 专业分工，多视角协作 |
| 都需要？ | 混合使用 | Plan-and-Execute 做骨架，ReAct 做执行，Reflexion 做兜底，Role-playing 做分工 |
框架支持现状
这些设计模式已经被主流 Agent 开发框架广泛内置：
flowchart TD
subgraph Agent 开发框架
L1[LangChain / LangChain4j]
L2[LlamaIndex]
L3[Dify]
L4[Spring AI Alibaba]
L5[Google ADK]
end
subgraph 内置模式支持
M1[ReAct - 基础执行范式]
M2[Plan-and-Execute - 任务规划]
M3[Reflexion - 重试与纠错]
M4[Role-playing - 多智能体]
M5[CoT - 推理增强]
end
L1 --> M1
L1 --> M2
L1 --> M3
L1 --> M4
L2 --> M1
L2 --> M5
L3 --> M1
L3 --> M2
L4 --> M1
L4 --> M4
L5 --> M1
L5 --> M4
style M1 fill:#c8e6c9,stroke:#388e3c
style M2 fill:#fff9c4,stroke:#f9a825
style M3 fill:#fff9c4,stroke:#f9a825
style M4 fill:#fff9c4,stroke:#f9a825
style M5 fill:#e1f5fe,stroke:#0288d1
- ReAct 已成为几乎所有框架的基础执行范式，是 Agent 的"操作系统"。
- Plan-and-Execute 在 LangChain 中有专门实现（Plan-and-Execute Agent）。
- Reflexion 的思想融入了各框架的重试机制和错误处理逻辑中。
- Role-playing / Multi-Agent 在 LangGraph、Spring AI Alibaba 的多智能体模块中有直接支持。
- CoT 通常作为 prompt 工程的一部分，不需要框架层面的特殊支持。
理解这些底层模式，能帮助开发者在框架选型时做出更准确的判断——不是看框架"支持多少功能"，而是看它"如何实现了这些认知模式"，以及哪种实现方式最适合你的业务场景。
总结一句话：CoT 一步步写过程，Self-Ask 拆成小问题，ReAct 既思考也动手，Plan-Execute 先计划再执行，ToT 树状多分支探索，Reflexion 自我反思迭代，Role-playing 多人协作分工。它们构成了 Agent 世界的思维模式库，混搭使用，威力最大。
