【AIOPS】AI Agent 专题【左扬精讲】Agent 设计模式精讲：CoT+ReAct+Reflexion+ReWOO
【AIOPS】AI Agent 专题【左扬精讲】Agent 设计模式精讲：CoT+ReAct+Reflexion+ReWOO
引言
-
-
- CoT 聚焦逻辑推理链的构建，层层拆解复杂问题；
- ReAct 打通“思考-行动”的闭环链路，实现决策与执行的高效联动；
- Reflexion 赋能自主反思与迭代优化，持续提升任务处理精度；
- ReWOO 专攻工具调用的效率优化，大幅降低资源消耗与响应时延。
-
本文将从原理、流程、实现、场景四大维度，对这四种核心模式展开系统性拆解，为AI Agent的开发实践提供清晰的选型依据与落地指引。
一、四大核心设计模式全解析
1.1、CoT 模式（Chain of Thought，思维链）
1.1.1、定义
CoT 模式 是让 LLM 像人类一样“逐步思考”的基础模式，通过引导模型生成中间推理步骤，而非直接输出最终答案，从而提升复杂问题的解决能力。其核心本质是“分解推理过程，降低认知负荷”。
从通俗角度理解：当面对“数学计算”、“逻辑推理”等复杂任务时，CoT 让 Agent 不再“跳跃式作答”，而是像学生解题一样，一步步写出推导过程，最终得出结论。
1.1.2、技术原理与工作流程
CoT 模式的核心流程可概括为 “问题拆解→分步推理→结论整合” 三步：
-
-
-
- 问题分析：Agent 接收用户需求后，识别任务类型（逻辑推理 / 数学计算 / 因果分析等）；
- 推理链生成：通过 Prompt 引导 LLM 输出逐步推理过程（如“第一步：先计算 A，第二步：根据 A 推导 B，第三步：结合 B 得出结论”）；
- 结论验证：Agent 检查推理步骤的连贯性与正确性，整合生成最终答案。
-
-
Prompt 设计示例（数学计算场景）
你是一个逻辑推理助手，解决问题时请按照以下步骤思考： 1. 明确问题要求的计算目标； 2. 列出所需的已知条件和未知变量； 3. 分步推导计算过程； 4. 验证结果是否合理，最终给出答案。 问题：某公司3月份营收200万元，4月份环比增长20%，5月份环比下降10%，请问5月份营收是多少？
1.1.3、核心价值与适用场景
-
-
- 核心价值：
- 提升复杂问题解决准确率（尤其数学计算、逻辑推理类任务）；
- 推理过程可解释（便于排查错误、增强可信度）；
- 降低 LLM 直接作答的 “跳跃性错误”。
- 适用场景：
- 数学运算、公式推导（如财务计算、数据分析）；
- 逻辑推理、因果分析（如故障根因定位、问题诊断）；
- 多步骤决策（如简单的方案规划）。
- 核心价值：
-
1.1.4、实现要点
-
-
- Prompt 设计需明确引导“分步思考”，避免模型直接输出答案；
- 对于超长推理链，可拆分 Prompt 进行多轮交互，避免上下文溢出；
- 可结合领域知识优化推理步骤模板（如 AIOPS 场景的故障排查推理模板）。
-
1.2、ReAct 模式（Reason-Act，思考 - 行动）
1.2.1、定义
ReAct 模式 是打通“思考 - 行动 - 反馈”闭环的核心模式，通过“推理决策→工具调用→结果反馈→迭代优化”的循环，让 Agent 具备与外部环境交互的能力。其核心本质是 “将思考转化为可执行行动，通过反馈修正决策”。
从通俗角度理解：ReAct 模式让智能体的工作方式与工程师高度相似。面对任务时，先拆解分析问题的核心诉求与执行路径（思考），再精准匹配并调用所需工具（如数据库查询、API 接口调用、专业模型推理等），随后执行具体操作（行动），最后根据执行结果调整优化方案（反馈），直至任务圆满完成。
ReAct 模式主要解决了大语言模型（LLM）在实际应用中的以下核心痛点：
1.2.2、技术原理与工作流程
ReAct 模式的完整闭环包含 4 个关键步骤，循环执行直至任务完成：
-
-
-
- 思考（Reason）：Agent 接收用户需求，结合上下文分析任务目标，判断是否需要调用工具、调用哪种工具；
- 行动（Act）：根据思考结果，生成工具调用指令（如 API 调用参数、数据库查询语句），执行外部工具；
- 观察（Observe）：获取工具返回结果（成功 / 失败、数据 / 错误信息）；
- 反馈（Feedback）：根据工具结果修正之前的思考，决定是否继续调用工具、更换工具或直接生成答案。
-
-
工作流程示意图：
用户需求 → 思考（是否需要工具？用什么工具？）→ 行动.（调用工具）→ 观察（工具结果）→ 反馈（修正思考）→ 循环... → 生成最终答案
1.2.3、核心价值与适用场景
-
-
- 核心价值：
- 实现 Agent 与外部工具的联动（突破 LLM 自身能力边界）；
- 支持动态调整行动策略（应对工具调用失败、结果不符合预期等情况）；
- 任务执行过程可追溯（便于问题排查）。
- 适用场景：
- 需调用外部工具的任务（如数据查询、系统操作、API 交互）；
- 动态环境下的任务（如实时数据查询、状态变化的系统管理）；
- 多步骤工具协同（如 AIOPS 场景的日志查询→故障分析→告警处理）。
- 核心价值：
-
1.2.4、实现要点
1.2.5、Go 语言简化实现示例（工具调用部分）
// 思考阶段：判断是否需要调用工具
func reason(userInput string, tools []Tool) (string, *FunctionCall) {
prompt := fmt.Sprintf(`用户需求：%s
可用工具：%v
请分析是否需要调用工具。若需要，输出工具调用指令（JSON格式）；若不需要，直接返回回答。`, userInput, tools)
llmOutput, _ := callLLM(prompt)
// 解析LLM输出，判断是直接回答还是工具调用指令
parsedResult, _ := parseLLMResponse(llmOutput, tools)
if call, ok := parsedResult.(FunctionCall); ok {
return "", &call // 需要工具调用
}
return llmOutput, nil // 直接回答
}
// ReAct闭环执行
func reactLoop(userInput string, tools []Tool) string {
var context string // 上下文存储（思考记录+工具结果）
for i := 0; i < 5; i++ { // 限制最大循环次数，避免死循环
// 1. 思考阶段
answer, funcCall := reason(userInput+context, tools)
if answer != "" {
return answer
}
// 2. 行动阶段：调用工具
toolResult, err := callTool(funcCall)
if err != nil {
context += fmt.Sprintf("工具调用失败：%v", err)
continue
}
// 3. 观察+反馈阶段：更新上下文
context += fmt.Sprintf("工具调用结果：%s", toolResult)
}
return "任务执行超时，请检查参数或工具状态"
}
1.3、Reflexion 英[rɪˈflekʃn] 美[rɪˈflekʃn] 模式（反思优化）
1.3.1、定义
Reflexion 模式 是赋予智能体（Agent）“自主反思、迭代进化” 核心能力的进阶范式，其核心运行逻辑遵循 “执行任务→轨迹评估→反思归因→经验沉淀→优化策略” 的完整链路，通过对历史任务执行过程的深度复盘，持续迭代执行策略，实现任务完成质量与效率的阶梯式提升。该模式的本质在于 “让智能体具备从历史经验中学习的能力，通过主动规避重复错误、继承有效策略，实现自我能力的持续强化”。
从通俗角度理解：Reflexion 模式让智能体的工作方式与专业复盘专家高度契合：在完成单次任务后，不仅停留在 “任务结束” 的结果层面，而是主动回溯整个执行轨迹 —— 精准定位问题节点（如工具调用时机偏差、推理逻辑断点、参数设置错误等），深入分析问题根源，提炼可复用的经验规律，将这些反思成果存入长期记忆；当再次面临相似任务时，智能体可直接调用沉淀的经验优化执行方案，避免重蹈覆辙。
-
-
- 核心目标不同：从 “完成任务” 到 “优化能力”
- ReAct 模式的核心目标是通过 “思考 - 行动 - 观察” 的闭环实现任务的有效完成，聚焦于单次任务的执行过程可控性，不涉及对历史经验的沉淀与复用；
- 而 Reflexion 模式的核心目标是通过反思机制实现智能体自身能力的迭代，不仅要完成当前任务，更要通过当前任务的执行经验，提升未来相似任务的处理能力，实现 “做一次、会一类” 的效果。
- 核心机制差异：新增 “评估 - 反思 - 记忆” 关键模块
- ReAct 模式的核心机制是 “思考→行动→观察” 的循环交互，依赖实时环境反馈调整当前任务的执行策略，无专门的反思与记忆组件；
- Reflexion 模式在 ReAct 基础上新增了三大核心模块：
- 一是评估器，对任务执行轨迹（如思考过程、行动步骤、输出结果）进行量化或质性评价，判断是否存在错误或优化空间；
- 二是反思器，基于评估结果生成针对性的反思结论，明确问题根源与改进方向；
- 三是长期记忆组件，存储反思形成的经验规律，为后续任务提供决策支撑。这种机制升级让智能体从 “被动响应反馈” 升级为 “主动沉淀经验”。
- 错误处理逻辑：从 “即时修正” 到 “根源规避”
- ReAct 模式对错误的处理聚焦于单次任务流程内的即时修正 —— 当观察到行动结果不符合预期时，仅回到 “思考” 环节重新规划当前任务的后续步骤，不涉及对错误原因的深度分析与长期规避；
- Reflexion 模式则构建了 “错误 - 反思 - 规避” 的长效机制：通过反思明确错误的本质原因（如是工具调用逻辑错误，还是任务拆解思路偏差），并将 “错误类型 + 规避方案” 存入记忆，后续遇到同类任务时直接调用规避策略，从根源上减少重复错误的发生。
- 例如在编程任务中，ReAct 可能仅修正当前代码的语法错误，而 Reflexion 会反思语法错误的产生原因，总结同类语法规则并记忆，后续生成相似代码时主动规避该类错误。
- 能力进化路径：从 “任务依赖” 到 “泛化迁移”
- ReAct 模式的能力边界受限于单次任务的环境与工具，不同任务之间缺乏能力迁移，处理新类型任务时仍需重新启动 “思考 - 行动” 循环；
- Reflexion 模式通过反思沉淀的经验具有泛化性，能够实现跨任务的能力迁移。
- 例如在文本问答任务中总结的 “多源信息交叉验证” 经验，可迁移到事实验证、代码调试等其他需要严谨推理的任务中，显著提升智能体处理复杂、陌生任务的能力。
- 核心目标不同：从 “完成任务” 到 “优化能力”
-
1.3.2、技术原理与工作流程
Reflexion 模式的核心是“执行 + 反思”双循环，包含 5 个步骤：
-
-
-
- 任务执行：采用 CoT 或 ReAct 模式完成用户需求，记录完整过程（思考步骤、工具调用记录、结果）；
- 结果评估：判断任务是否成功（如答案是否正确、工具调用是否高效、是否存在冗余步骤）；
- 反思分析：若任务失败或存在优化空间，分析问题根源（如推理错误、工具选择不当、参数错误）；
- 经验总结：将反思结果转化为结构化的经验规则（如“当查询服务器错误时，优先调用 Elasticsearch 工具，参数需包含时间范围”）；
- 策略优化：将经验规则融入 Agent 的决策逻辑，指导后续类似任务的执行。
-
-
反思 Prompt 设计示例：
请回顾以下任务执行过程，完成反思： 1. 任务目标：%s 2. 执行过程：%s 3. 执行结果：%s（成功/失败） 请分析： - 若失败，问题根源是什么？（如推理错误、工具调用错误、参数缺失） - 若成功，是否存在优化空间？（如减少工具调用次数、简化推理步骤） - 总结1条可复用的经验规则，用于后续类似任务。
1.3.3、核心价值与适用场景
1.3.4、实现要点
1.4、ReWOO 模式（Retrieve 英[rɪˈtriːv] 美[rɪˈtriːv], World, Output，检索 - 世界 - 输出）
1.4.1、定义
ReWOO 模式 是优化工具调用效率的专项模式，通过“检索规划→工具并行→结果整合”的流程，将任务拆解为独立的工具调用单元，并行执行后汇总结果。其核心本质是“拆分任务、并行计算，提升工具调用效率”。
从通俗角度理解：ReWOO 模式让智能体的工作方式与资深项目经理高度契合：接到复杂任务后，不会急于分步执行，而是先完成全局规划——明确任务目标、拆解出可并行的子任务模块（如同时检索A数据库的行业数据、调用B工具的数据分析能力、获取C平台的实时信息等），随后将这些独立子任务同步分配给对应“执行单元”并行处理，最终汇总所有子任务的结果进行整合分析，输出完整方案。这种方式彻底规避了串行执行中“等待前一步完成再启动下一步”的效率损耗，大幅缩短复杂任务的整体耗时。
1.4.2、技术原理与工作流程
ReWOO 模式的核心是“任务拆分 + 并行执行”，包含 4 个步骤：
-
-
-
- 检索规划（Retrieve）：Agent 分析用户需求，拆分出多个独立的子任务，每个子任务对应一个工具调用（或无需工具）；
- 世界交互（World）：并行执行所有工具调用子任务，获取每个子任务的结果（支持不同工具同时调用）；
- 结果整合（Output）：将所有子任务结果（工具返回数据 + 直接推理结论）汇总，生成最终答案；
- 优化调整：根据执行效率和结果质量，调整任务拆分策略（如合并冗余子任务、优化并行执行优先级）。
-
-
任务拆分示例（AIOPS 故障排查场景）：
用户需求：分析今天上午服务器响应延迟的原因
子任务拆分：
调用监控工具查询服务器 CPU / 内存使用率（9:00-12:00）；
调用日志工具查询应用错误日志（9:00-12:00）；
调用网络工具查询网络带宽占用率（9:00-12:00）；
并行执行上述 3 个工具调用，汇总结果后分析延迟原因。
1.4.3、核心价值与适用场景
1.4.4、实现要点
1.4.4、Go 语言简化实现示例（并行工具调用）
// 任务拆分：将复杂需求拆分为独立子任务
func splitTask(userInput string) []SubTask {
prompt := fmt.Sprintf(`用户需求：%s
请拆分为独立的子任务，每个子任务对应一个工具调用（格式：工具名称+参数），无需依赖其他子任务结果。`, userInput)
llmOutput, _ := callLLM(prompt)
return parseSubTasks(llmOutput) // 解析为子任务列表
}
// 并行执行工具调用
func parallelCallTools(subTasks []SubTask) []ToolResult {
var results []ToolResult
var wg sync.WaitGroup
resultChan := make(chan ToolResult, len(subTasks))
for _, task := range subTasks {
wg.Add(1)
go func(t SubTask) {
defer wg.Done()
res, err := callTool(t.FunctionCall)
resultChan <- ToolResult{Task: t, Result: res, Err: err}
}(task)
}
// 等待所有子任务完成，关闭通道
go func() {
wg.Wait()
close(resultChan)
}()
// 收集结果
for res := range resultChan {
results = append(results, res)
}
return results
}
// ReWOO 模式执行入口
func rewooExecute(userInput string, tools []Tool) string {
// 1. 任务拆分
subTasks := splitTask(userInput)
// 2. 并行工具调用
toolResults := parallelCallTools(subTasks)
// 3. 结果整合
整合Prompt := buildCombinePrompt(userInput, toolResults)
finalAnswer, _ := callLLM(整合Prompt)
return finalAnswer
}
二、四大模式对比与选型指南
2.1、核心特性对比
|
设计模式
|
核心聚焦
|
关键优势
|
主要劣势
|
依赖能力
|
典型适配模型（国内外）
|
|---|---|---|---|---|---|
|
CoT（思维链）
|
逻辑推理链
|
可解释性强、准确率高
|
不支持工具交互、仅适用于推理类任务
|
LLM 推理能力
|
国外：OpenAI GPT-4o、Anthropic Claude 3.7 Sonnet、Google Gemini 2.5 Pro、OpenAI O1/O3-mini国内：DeepSeek-R1、阿里云通义千问 2.0、智谱清言 ChatGLM4、红星（Red Star）
|
|
ReAct（思考-行动）
|
思考-行动闭环
|
支持工具调用、动态调整
|
串行执行效率低、复杂任务易循环
|
工具生态 + 推理能力
|
国外：OpenAI GPT-4 Turbo、Anthropic Claude 3 Opus、Meta Llama 3 70B（适配工具框架）国内：字节跳动火山方舟、百度文心一言 4.0、阿里云通义千问（Dify 平台适配）、华为盘古大模型 4.0
|
|
Reflexion（反思优化）
|
自主反思优化
|
持续进化、减少重复错误
|
需存储历史数据、反思耗时
|
记忆能力 + 推理能力
|
国外：OpenAI GPT-4o Advanced、Anthropic Claude 3.7 Opus、Google Gemini 2.5 Ultra国内：DeepSeek-R1（进阶版）、智谱清言 ChatGLM4 增强版、字节跳动云雀大模型（企业版）
|
|
ReWOO（并行工具调用）
|
并行工具调用
|
执行效率高、可扩展性强
|
任务拆分要求高、结果整合复杂
|
并行框架 + 工具生态
|
国外：OpenAI GPT-4o、IBM Granite Instruct、Meta Llama 3 405B（适配 LangGraph 框架）国内：阿里云通义千问（企业级并行框架适配）、百度文心一言 4.0 企业版、华为盘古大模型（云原生并行架构）
|
2.2 模型适配说明
2.2、场景选型建议
三、模式落地关键注意事项
3.1、LLM 选型适配 —— 按需匹配能力边界，平衡效果与成本
LLM 作为 Agent 的“大脑核心”，其推理能力、结构化输出能力、响应速度直接决定了设计模式的落地效果。需结合模式特性与业务场景，实现“能力适配 + 成本优化”的双重目标：
3.1.1、按模式特性精准选型
-
-
- CoT 模式：核心依赖 LLM 的“逻辑链拆解能力”与“步骤连贯性”，需选择强推理模型。
- 推荐选型：GPT-4/Turbo、通义千问 Plus、智谱清言 X、Llama 3 70B+（本地化部署）；
- 避坑点：避免使用轻量模型（如 GPT-3.5 Base、通义千问 Slim），此类模型易出现推理跳跃、步骤遗漏（如数学计算中跳过关键推导环节）。
- Reflexion 模式：需同时具备“推理能力 + 自我批判能力”，模型需能分析历史执行缺陷并总结通用规则。
- 推荐选型：GPT-4、通义千问 Ultra、Claude 3 Opus；
- 关键要求：模型需支持长上下文（至少 8k+），以便加载完整的任务执行日志与反思历史，避免因上下文截断导致反思不全面。
- ReAct 模式：核心需求是“意图识别 + 结构化工具调用指令生成”，推理难度低于 CoT/Reflexion，但对输出格式一致性要求高。
- 推荐选型：GPT-3.5 Turbo、通义千问 Plus、智谱清言、Gemini Pro；
- 关键要求：模型需能稳定输出 JSON 格式的工具调用指令（如 {"function":"query_error","params":{"date":"2024-10-01"}}），可通过 Prompt 强制格式约束（如 “若需调用工具，必须输出严格 JSON，不允许额外自然语言”）。
- ReWOO 模式：重点依赖 “任务拆分能力”，需将复杂需求拆分为独立、无依赖的子任务，对并行任务规划能力要求高。
- 推荐选型：GPT-4 Turbo、通义千问 Plus、Claude 3 Sonnet；
- 关键要求：模型需能识别子任务的独立性（如 “查询 CPU 使用率” 与 “查询内存使用率” 可并行，“查询错误数” 与 “分析错误原因” 需串行），避免拆分出存在依赖关系的子任务导致并行执行失败。
- CoT 模式：核心依赖 LLM 的“逻辑链拆解能力”与“步骤连贯性”，需选择强推理模型。
-
3.1.2、成本与性能的平衡策略
3.2、工程化落地要点 —— 从原型到生产的可靠性保障
设计模式的落地需解决“工具协同、错误容错、性能稳定”三大工程问题，避免因细节疏忽导致 Agent 无法规模化使用：
3.2.1、工具标准化：构建可复用的工具生态
工具是 Agent 与外部世界交互的 “手脚”，标准化设计能大幅降低模式适配成本，提升可扩展性：
-
-
-
- 接口协议统一：所有工具统一采用 HTTP/gRPC 协议，推荐 RESTful 风格设计（如工具调用使用 POST 方法，参数通过 JSON 传递），避免因协议不一致导致的适配冗余；
- 参数格式规范：定义统一的参数结构体（参考 Go 语言 ToolParam 设计），明确参数名称、类型、必填项、默认值、描述，例如：
-
-
// 标准化工具参数结构体
type StandardToolParam struct {
Name string `json:"name"` // 参数名（小写蛇形命名）
Type string `json:"type"` // 参数类型（string/int/bool/json）
Required bool `json:"required"` // 是否必填
Default interface{} `json:"default"` // 默认值（非必填项必设）
Description string `json:"description"` // 功能描述（明确参数用途与格式）
Example string `json:"example"` // 示例值（降低 LLM 理解成本）
}
-
-
-
- 工具元信息注册中心：搭建集中式工具注册平台，存储所有工具的元信息（名称、描述、参数、调用地址、权限要求），Agent 可通过注册中心动态获取工具列表，支持工具的热插拔与版本管理；
- 权限与安全控制：工具调用需添加身份校验（如 API Key、JWT 令牌），针对敏感工具（如服务器重启、数据库删除）设置权限白名单，避免 Agent 被恶意利用执行高危操作。
-
-
3.2.2、错误处理：设计全链路容错机制
Agent 执行过程中可能面临工具调用失败、任务拆分错误、反思偏差等问题，需设计“预防 - 降级 - 恢复”的全链路容错策略：
-
-
-
- 预防机制：
- 工具调用前：校验参数完整性（如 ReAct 模式调用工具前，检查必填参数是否缺失）、格式合法性（如日期参数是否符合 YYYY-MM-DD 格式）；
- 任务拆分前：通过 Prompt 明确子任务拆分规则（如“子任务需独立可执行，无依赖关系”），避免拆分出无效任务。
- 降级策略：
- 工具调用失败：支持自动重试（默认 3 次，间隔 1s），重试失败则切换备用工具（如 Elasticsearch 查询失败时，切换为日志文件本地查询），无备用工具则返回友好提示（如“当前查询工具不可用，请稍后重试”）；
- 任务拆分错误：若子任务存在依赖关系（如 ReWOO 模式拆分后发现子任务需串行执行），自动切换为 ReAct 模式串行执行，避免并行任务阻塞；
- 反思偏差：若 Reflexion 模式生成的经验规则存在逻辑漏洞（如 “查询错误数时无需指定时间范围”），通过人工审核机制过滤无效规则，避免误导后续任务。
- 恢复机制：记录任务执行的“快照”（每一步的思考结果、工具调用记录、上下文信息），当任务执行失败时，支持从失败节点恢复执行，无需从头重新运行（如 ReAct 模式工具调用失败后，基于已有上下文重新发起工具调用）。
- 预防机制：
-
-
3.2.3、性能优化：针对不同模式的专项调优
不同设计模式的性能瓶颈不同，需针对性优化执行效率，避免因性能问题影响用户体验：
-
-
-
- CoT 模式：
- 推理链截断优化：对于超长推理链（如超过 10 步），自动拆分推理过程，通过多轮交互完成，避免单轮 Prompt 上下文溢出；
- 推理步骤缓存：缓存高频重复的推理步骤（如 “计算环比增长率的公式推导”），后续遇到相同场景直接复用，减少 LLM 计算量。
- ReAct 模式：
- 工具调用缓存：缓存短期（如 5 分钟内）相同参数的工具调用结果（如“查询 2024-10-01 的服务器错误数”），避免重复调用工具；
- 循环次数限制：设置最大循环次数（默认 5 次），避免因工具调用结果不符合预期导致无限循环。
- Reflexion 模式：
- 反思日志存储优化：采用时序数据库（如 InfluxDB）存储反思日志，按任务类型、时间范围建立索引，提升日志查询效率；
- 反思频率控制：高频重复任务（如每小时执行的监控查询）可每 10 次执行后反思一次，避免每次执行都触发反思导致延迟。
- ReWOO 模式：
- 并行任务调度：基于任务优先级（如核心数据查询优先级高于非核心数据）与工具负载（如某工具当前并发数已达上限）动态调整并行数，避免工具过载；
- 超时控制：为每个并行子任务设置独立超时时间（如简单查询 3s，复杂分析 10s），超时任务自动降级为串行执行，避免单个任务阻塞整体流程；
- 结果整合优化：预定义结果整合模板（如 AIOPS 场景的 “CPU 使用率 + 内存使用率 + 错误数” 整合模板），减少 LLM 结果整合的计算量。
- CoT 模式：
-
-
3.3、Prompt 工程优化：让 LLM 精准理解模式逻辑
Prompt 是 Agent 与 LLM 沟通的 “语言”，针对不同模式设计专用 Prompt 模板，能大幅提升模式执行准确率：
3.3.1、模式专用 Prompt 模板设计（附示例）
-
-
- CoT 模式模板：强调 “分步推理 + 逻辑连贯”，明确每一步的思考目标与输出格式：
你是一个逻辑推理专家，解决以下问题时必须遵循以下步骤： 1. 明确问题核心目标（如“计算5月份营收”“定位服务器延迟原因”）； 2. 列出解决问题所需的已知条件、未知变量及关键逻辑； 3. 按“第一步→第二步→...→最后一步”的格式分步推导，每一步说明“做什么+为什么这么做”； 4. 最后汇总所有步骤，得出最终结论。 注意： - 推理过程需连贯，前一步的结果需作为后一步的输入； - 若遇到不确定的环节，明确标注“此处需进一步验证”，不凭空猜测； - 禁止直接输出最终答案，必须展示完整推理链。 问题：%s
- ReAct 模式模板：强调 “思考 - 行动 - 反馈” 的闭环，明确工具调用的格式要求：
你是一个工具调用专家，需按“思考→行动→反馈”的流程处理用户需求： 1. 思考阶段：分析用户需求，判断是否需要调用工具。若需要，明确“调用哪个工具+需要的参数”；若不需要，直接给出答案； 2. 行动阶段：若需调用工具，严格按以下 JSON 格式输出指令（无额外自然语言）： {"function":"工具名称","params":{"参数名1":"参数值1","参数名2":"参数值2"}} 3. 反馈阶段：根据工具返回结果，判断是否需要继续调用工具（如结果不完整、错误），或直接生成最终答案。 可用工具列表： %s 注意： - 工具参数需严格匹配工具元信息（必填项不可缺失，格式符合要求）； - 若工具调用失败，可尝试调整参数后重试，或切换备用工具； - 无需调用工具时，直接用自然语言回答用户问题。 用户需求：%s 工具返回结果（若有）：%s - Reflexion 模式模板：强调 “结果评估 + 问题定位 + 经验总结”，明确反思的输出格式：
你是一个复盘优化专家，需对以下任务执行过程进行全面反思： 1. 任务信息： - 目标：%s - 执行模式：%s（CoT/ReAct/ReWOO） - 执行过程：%s（思考步骤+工具调用记录+上下文） - 最终结果：%s（成功/失败+具体结果） 2. 反思要求： a. 结果评估：判断任务是否达到目标？若未达到，明确失败类型（推理错误/工具调用错误/任务拆分错误）； b. 问题定位：分析导致失败的核心原因（如“工具参数缺失日期范围”“推理步骤遗漏关键逻辑”）； c. 经验总结：提炼 1-2 条可复用的规则（格式：“当遇到【场景】时，应【操作】，避免【错误】”）； d. 优化建议：针对当前模式，提出具体的 Prompt 或流程优化方案。 反思输出格式： - 结果评估：xxx - 问题定位：xxx - 经验规则：xxx - 优化建议：xxx
- ReWOO 模式模板：强调 “任务拆分 + 并行规划”，明确子任务的独立性要求：
你是一个任务拆分专家，需将用户需求拆分为多个独立的子任务，用于并行执行： 1. 拆分规则： a. 子任务需独立可执行，无需依赖其他子任务的结果； b. 每个子任务对应一个工具调用（明确工具名称+完整参数）； c. 子任务数量不超过 5 个（避免并行压力过大）； d. 核心子任务（影响最终结果的关键步骤）优先拆分。 2. 输出格式： [ {"sub_task_id":"1","function":"工具名称","params":{"参数名1":"参数值1"...},"description":"子任务目标"}, {"sub_task_id":"2","function":"工具名称","params":{"参数名1":"参数值1"...},"description":"子任务目标"} ] 可用工具列表： %s 用户需求：%s
- CoT 模式模板：强调 “分步推理 + 逻辑连贯”，明确每一步的思考目标与输出格式：
-
3.3.2.1、领域知识注入：给 Prompt 加“行业滤镜”
-
-
- 原本的通用 Prompt 像“通用说明书”，而领域知识注入就是给说明书加“行业专属条款”—— 让 LLM 懂你所在领域的“黑话”和“规矩”。
- 比如 AIOPS 运维场景，直接让 LLM 处理“查服务器异常”，它可能不知道该调用什么工具、用什么参数；但在 Prompt 里明确加入“服务器 5xx 错误（HTTP 服务端异常）”，“Elasticsearch 索引命名规则（如 log-2024-10-* 格式）”“k8s 接口调用需带 namespace 参数”，LLM 就能精准匹配工具、生成合规参数，不会出现“外行式错误”。
- 核心目的：避免 LLM 因不懂行业规则而“瞎思考”，让 Prompt 更有针对性
-
3.3.2.2、动态 Prompt 调整：让 Prompt 会“自我修正”
-
-
- 不是写好一个 Prompt 就一成不变，而是根据 LLM 的实际输出 “打补丁”—— 发现问题，就给 Prompt 加约束，避免再犯同样错误。
- 比如用 CoT 模式解决故障排查，发现 LLM 经常跳过关键推理步骤（比如直接说 “是 CPU 过载”，不解释怎么判断的），就在下次的 Prompt 里加一句 “请确保推理步骤不低于 3 步，每步说明判断依据”；用 ReAct 模式调用工具时，发现 LLM 总把 “日期参数” 写成 “2024/10/01”（工具要求 “2024-10-01”），就补充 “日期参数需符合 YYYY-MM-DD 格式，参考示例：2024-10-01”。
- 核心目的：Prompt 不是 “死的”，而是跟着 LLM 的表现动态优化，解决实际落地中的细节问题。
-
3.3.2.3、多轮 Prompt 迭代：给 Prompt 做 “优胜劣汰”
-
-
- 同一个模式可能有多种 Prompt 写法，通过对比测试选出效果最好的，还会根据业务变化持续更新。
- 比如 CoT 模式有两种模板：一种是“分步引导”（第一步做什么、第二步做什么），另一种是“目标拆解”（先拆成几个小目标，再逐个推导）。通过 A/B 测试（一半任务用模板 1，一半用模板 2），统计哪种模板的推理准确率更高、步骤更完整，就用哪种；如果后续业务新增了“云服务器监控” 场景，再针对性调整模板，加入云服务器相关的推理逻辑。
- 核心目的：让 Prompt 始终保持 “最优状态”，而不是停留在初始版本。
-
总结下来，这三点的核心都是“不让 Prompt 脱节”—— 既不脱离具体行业场景，也不脱离 LLM 的实际表现，更不脱离业务的动态变化，最终让 Agent 能稳定落地、持续好用。
浙公网安备 33010602011771号