---

一、研究背景与技术概述

1.1 AI Agent路径规划问题的定义

AI Agent的路径规划（Path Planning）是指Agent在面对复杂任务时，自主确定执行步骤序列的能力。传统LLM以自回归方式逐token生成输出，类似于"即兴发言"而非"深思熟虑"。这导致三类核心缺陷[1]：

1. 单一路径依赖：一旦某步推理出错，后续全链路受影响且无法回溯；

2. 无中间评估能力：无法判断每一步推理的合理性；

3. 缺乏全局规划：不会拆解复杂问题，不会多方案权衡。

1.2 LLM推理范式的演进脉络

AI推理技术经历了四个核心阶段的演进2：

范式	提出时间	核心特点	核心局限
IO（输入-输出）	基线	直接输出答案，无推理过程	完全无推理能力
CoT（思维链）	Google 2022	线性多步推理	单路径，不可回溯
ToT（思维树）	Yao et al. 2023	树形搜索+分支+评估+剪枝	Token消耗高，主观任务自评不准
GoT（思维图）	Besta et al. 2023	任意图结构推理，支持聚合/精炼	实现复杂度极高，运维成本大

1.3 核心技术原理

ToT（Tree of Thoughts）

论文来源：Yao, S. et al. (2023). Tree of Thoughts: Deliberate Problem Solving with Large Language Models. NeurIPS 2023. arxiv.org/abs/2305.10601

ToT由普林斯顿大学和Google DeepMind联合提出，将问题求解建模为树形搜索结构，包含三大核心组件4：

1. 思维生成器（G）：基于当前节点状态生成K个候选思路分支；

2. 状态评估器（V）：对每个候选节点打分/分类（如"sure/maybe/impossible"）；

3. 搜索算法：BFS（广度优先，适合浅层任务）或DFS（深度优先，适合深层推理）。

关键性能数据：在24点游戏中，GPT-4使用CoT成功率仅4%，而ToT方法成功率达74%[5]。

GoT（Graph of Thoughts）

论文来源：Besta, M. et al. (2023). Graph of Thoughts: Solving Elaborate Problems with Large Language Models. AAAI 2024. arxiv.org/abs/2308.09687

GoT由苏黎世联邦理工学院（ETH Zurich）提出，Google Scholar引用量已达499+（截至2025年3月）[6]。核心创新在于将LLM推理过程从线性链或树结构推广为任意有向图结构：

• 顶点代表"LLM思维"（中间推理状态）；

• 边代表思维间的依赖关系；

• 支持三大关键操作：聚合（合并多个思维）、精炼（反馈循环优化）、生成（基于现有思维产生新思维）。

关键性能数据：在排序任务中，GoT比ToT质量提高62%，同时成本降低31%以上[6]。GoT的架构模块包括Prompter、Parser、Scoring、Controller四个核心组件。

---

二、主流AI框架ToT/GoT集成方案深度分析

2.1 LangChain + LangGraph（推荐度：★★★★★）

概述

LangGraph是LangChain生态中的图状态机框架，由LangChain官方维护，是目前ToT/GoT实现最成熟、文档最完善的选择。截至2026年6月，LangGraph已发布稳定的ToT官方教程[7]。

适用场景

• 需要树形/图结构推理的复杂Agent应用

• 数学推理、逻辑谜题、代码生成、方案规划

• 需要状态持久化和回溯能力的长流程任务

集成方式

LangGraph实现ToT的核心架构[7]：

 StateGraph → 4节点 + 条件边循环
    ├── expand（扩展节点）
    │     └── 调用LLM生成候选解，接受先前种子为上下文
    ├── score（评分节点）
    │     └── 验证正确性 + 计算奖励分数
    ├── prune（剪枝节点）
    │     └── 按分数排序，保留Top-K候选
    └── should_terminate（终止判断）
          ├── 已达阈值或深度上限 → 结束
          └── 未达条件 → 回expand继续搜索

详细集成步骤

第一步：安装依赖

 pip install -U langgraph langchain-openai

第二步：定义数据模型

 from typing import TypedDict, Annotated, List, Optional, NamedTuple
 from langgraph.graph import StateGraph, Send
 from langgraph.checkpoint.memory import MemorySaver
 import operator
 ​
 # 候选对象
 class Candidate(NamedTuple):
     candidate: Any
     score: Optional[float] = None
     feedback: Optional[str] = None
 ​
 # 状态定义
 class ToTState(TypedDict):
     problem: str
     candidates: Annotated[List[Candidate], update_candidates]
     scored_candidates: Annotated[List[ScoredCandidate], update_candidates]
     depth: Annotated[int, operator.add]
 ​
 # 配置
 class Configuration(TypedDict, total=False):
     max_depth: int     # 默认10
     threshold: float   # 默认0.9
     k: int             # 每轮生成候选数，默认5
     beam_size: int     # 剪枝后保留数，默认3

第三步：构建扩展器（任务特定组件）

 from langchain_core.prompts import ChatPromptTemplate
 from langchain_openai import ChatOpenAI
 ​
 prompt = ChatPromptTemplate.from_messages([
     ("system", "你正在解决一个复杂问题。请生成{k}个不同的候选解。"),
     ("user", "问题: {problem}\n\n之前的尝试: {candidate}")
 ])
 llm = ChatOpenAI(model="gpt-4o-mini")
 bound_llm = llm.with_structured_output(YourOutputSchema)
 solver = prompt | bound_llm
 ​
 def expand(state, *, config):
     configurable = _ensure_configurable(config)
     result = solver.invoke({
         "problem": state["problem"],
         "candidate": state.get("seed", ""),
         "k": configurable["k"]
     })
     return {"candidates": [Candidate(candidate=r) for r in result]}

第四步：构建评分器

 def compute_score(problem, candidate) -> ScoredCandidate:
     # 自定义评分逻辑（根据具体任务调整）
     # 建议返回0-1之间的分数
     score = your_custom_scoring(problem, candidate)
     return ScoredCandidate(candidate=candidate, score=score, feedback=feedback)

第五步：构建图并编译

 builder = StateGraph(state_schema=ToTState, config_schema=Configuration)
 ​
 builder.add_node("expand", expand)
 builder.add_node("score", score)
 builder.add_node("prune", prune)
 ​
 builder.add_edge("expand", "score")
 builder.add_edge("score", "prune")
 builder.add_conditional_edges(
     "prune",
     should_terminate,
     path_map=["expand", "__end__"]
 )
 builder.add_edge("__start__", "expand")
 ​
 graph = builder.compile(checkpointer=MemorySaver())

第六步：运行

 config = {"configurable": {"thread_id": "task_1"}}
 for step in graph.stream({"problem": "你的复杂问题"}, config):
     print(step)
 ​
 final_state = graph.get_state(config)
 best_solution = final_state.values["candidates"][0]

达成效果

• 成功率：24点游戏类任务，GPT-4o-mini配合ToT可达74%+成功率（对比CoT仅4%）[5]

• 可控性：最大深度（max_depth）、候选数（k）、beam size均可配置

• 并行能力：LangGraph支持通过Send实现beam search并行扩展

• 状态持久化：MemorySaver支持检查点保存/恢复

局限性

• Token消耗为CoT的3-5倍[2]

• 单次推理延迟从480ms增至2800ms（3分支场景）[2]

• 需要设计有效的评估函数

---

2.2 Dify（推荐度：★★★★☆）

概述

Dify是国内最流行的开源LLM应用开发平台（GitHub Stars 60k+），2025年推出Agent节点架构，支持可插拔的Agent推理策略（Agent Strategy Plugin）[8]。

适用场景

• 需要可视化工作流编排的Agent应用

• 中低复杂度推理任务

• 团队协作、企业级Agent快速搭建

• 对代码开发能力要求较低的场景

集成方式

Dify采用解耦设计——Agent节点（执行单元）与Agent策略（决策逻辑）分离[8]：

 工作流 → Agent节点（拖放式配置）
               ├── 选择推理策略（Function Calling / ReAct / 自定义）
               ├── 链接工具/模型
               └── 设置提示模板
 ​
 自定义Agent策略开发：
   ├── 使用CLI工具快速创建策略插件
   ├── 自定义配置表单和可视化组件
   └── 集成学术算法（CoT / ToT / GoT / BoT等）

Dify的Agent策略开放标准[8]：

• Dify明确声明支持集成ToT、GoT等前沿学术算法

• 策略定义包含：身份元数据、参数配置（模型/工具/查询）、源代码入口

• 执行分为三个阶段：初始化 → 迭代循环 → 最终响应

• 内置推理执行日志（树状结构可视化Agent思维过程）

详细集成步骤（ToT/GoT策略插件开发）

第一步：环境准备

 # 安装Dify CLI
 pip install dify-cli
 ​
 # 创建新策略插件
 dify plugin init my-tot-strategy --type agent-strategy

第二步：定义策略配置（function_calling.yaml或自定义）

 parameters:
   - name: model
     type: model-selector
     scope: tool-call&llm
   - name: tools
     type: array[tools]
   - name: max_iterations
     type: number
     default: 5
   - name: branch_count
     type: number
     default: 4
     description: "ToT分支数量"
 extra:
   python:
     source: tot_strategy.py

第三步：实现ToT策略核心逻辑

 # tot_strategy.py 核心框架
 class ToTAgentStrategy:
     def __init__(self, model, tools, max_iterations, branch_count):
         self.model = model
         self.tools = tools
         self.max_iterations = max_iterations
         self.branch_count = branch_count
     
     def _invoke(self, parameters):
         # 初始化：解析问题，建立根节点
         problem = parameters["query"]
         active_nodes = [ThoughtNode(problem)]
         
         for iteration in range(self.max_iterations):
             # 扩展：为每个活跃节点生成branch_count个候选
             new_nodes = []
             for node in active_nodes:
                 candidates = self._generate_branches(node, self.branch_count)
                 for c in candidates:
                     score = self._evaluate(c)
                     c.score = score
                     new_nodes.append(c)
             
             # 剪枝：保留Top-K
             new_nodes.sort(key=lambda x: x.score, reverse=True)
             active_nodes = new_nodes[:self.branch_count // 2]
             
             # 终止条件检查
             if any(n.score > 0.9 for n in active_nodes):
                 break
         
         return {"answer": active_nodes[0].content}

第四步：在工作流中使用

1. 在Dify工作流画布中拖入Agent节点

2. 选择自定义的ToT/GoT策略插件

3. 配置关联的工具和模型

4. 通过内置日志调试推理路径

达成效果

• 开发效率：低代码/可视化开发，适合团队协作

• 可观测性：内置树状结构推理日志，可实时查看总时间、Token消耗、每轮推理和工具调用轨迹

• 扩展性：插件化架构支持任意推理策略扩展

局限性

• 复杂图结构推理（GoT）需要更多自定义开发

• 相比LangGraph的代码级灵活性有一定差距

• ToT/GoT策略插件生态仍处于早期阶段

---

2.3 GitHub开源GoT框架：graph-of-thoughts（推荐度：★★★★☆）

概述

由ETH Zurich团队官方实现的GoT框架（GitHub: spcl/graph-of-thoughts），是GoT原始论文的参考实现，提供完整的图结构推理引擎[9]。

适用场景

• 需要真正图结构推理的生产级应用

• 排序优化、多源信息融合、跨领域知识整合

• 学术研究和实验

集成方式

核心架构：Graph of Operations（GoO）作为抽象层，自动将复杂问题建模为操作图，以LLM作为执行引擎[6]。

框架模块[9]：

• Prompter：生成LLM提示

• Parser：从LLM输出提取结构化信息

• Scoring：评分和验证

• Controller：协调整个推理过程，决定如何推进

操作类型：

• generate：生成多个候选后续思路

• aggregate：合并多个节点信息为一个新思维

• refine：对单个节点进行迭代优化

• select：从多个候选中选择最优路径

详细集成步骤

 # 克隆仓库
 git clone https://github.com/spcl/graph-of-thoughts.git
 cd graph-of-thoughts
 ​
 # 安装依赖
 pip install -r requirements.txt
 ​
 # 配置LLM（支持OpenAI API）
 export OPENAI_API_KEY="your-key"

关键配置：

 from graph_of_thoughts import controller, operations, prompter, parser
 ​
 # 配置操作用图（Graph of Operations）
 goo_config = {
     "operations": [
         {"type": "generate", "k": 5},       # 每节点生成5个候选
         {"type": "score", "threshold": 0.8}, # 评分阈值
         {"type": "aggregate", "method": "vote"}, # 聚合方法
         {"type": "refine", "max_iter": 3},   # 最多精炼3次
     ],
     "max_depth": 5,
     "beam_size": 3
 }

达成效果

• 质量提升：排序任务比ToT提高62%，错误率降低[6]

• 成本优化：通过图结构共享子图，Token消耗比ToT低15-30%[10]

• 灵活性：支持自定义操作类型，适配多样化任务

局限性

• 实现复杂度极高，运维成本约为CoT的8倍[2]

• 需要图计算框架支持

• 仅适合高频值、低频次的场景[10]

---

2.4 Microsoft Semantic Kernel + AutoGen（推荐度：★★★☆☆）

概述

Microsoft的Agent框架生态经历了重大整合。2025年10月，Microsoft宣布AutoGen并入新的Microsoft Agent Framework，与Semantic Kernel统一[11]。其路径规划策略与ToT/GoT的原生推理范式有根本差异。

适用场景

• Microsoft技术栈企业用户

• 多Agent协作场景

• 需要企业级安全和可观测性的场景

集成方式

Semantic Kernel的规划策略演进[12]：

1. 早期：Function Calling Stepwise Planner（基于ReAct的提示驱动规划）

2. 中期：Handlebars Planner（模板语言生成计划，已废弃）

3. 现在：推荐使用原生Function Calling（"vanilla function calling"）

4. 未来：Python-based Planner（利用LLM生成Python代码执行规划）

Microsoft的官方立场[12]：

"Function calling has gotten increasingly more accurate and efficient. The need for additional planning logic on top of the model has become less necessary."

即Microsoft选择的是深度依赖模型自身Function Calling能力而非外部推理架构（如ToT/GoT）的路径。

Semantic Kernel中的ToT/GoT实现路径：

• 不提供原生ToT/GoT API

• 用户可通过自定义Function Calling流程模拟树/图搜索

• 建议结合LangGraph等专用框架实现高级推理

达成效果

• 延迟：原生Function Calling路径延迟最低

• 企业集成：原生支持Azure生态、容器安全执行

• 可控性：通过Azure Container Apps动态会话安全运行LLM生成的代码

局限性

• 不原生支持ToT/GoT，需要外部框架配合

• Microsoft的战略方向是"简化而非复杂化"推理链路

• 官方已废弃Handlebars Planner，未来规划尚在演进

---

2.5 CrewAI（推荐度：★★★☆☆）

概述

CrewAI是最流行的多Agent角色扮演框架，采用角色（Agent）+ 任务（Task）+ 团队（Crew）三层抽象[13]。其核心优势在于任务编排和Agent协作，而非底层推理路径规划。

适用场景

• 需要多Agent角色分工和协作的场景

• 复杂业务流程自动化

• 多角度分析的决策任务

集成方式

CrewAI通过Hierarchical Process模式支持任务规划[14]：

• Manager Agent负责任务分解和分配

• 各专业Agent执行各自子任务

• 支持顺序执行和层级管理

ToT/GoT的间接实现方式： CrewAI本身不内置ToT/GoT推理，但可通过以下方式集成：

1. 将每个Agent的推理过程设计为分支探索模式

2. 使用Manager Agent模拟评估和剪枝功能

3. 结合LangGraph在单个Agent内部实现ToT推理

达成效果

• 多Agent协作效率高：适合任务可分拆的场景

• 角色清晰：每个Agent专注特定领域

• 可组合性：可与其他框架（LangGraph等）组合使用

局限性

• 不原生支持树/图推理

• 多Agent通信开销大

• 复杂推理场景需要配合其他框架

---

2.6 DSPy（推荐度：★★★☆☆）

概述

DSPy（Declarative Self-improving Python）是斯坦福大学推出的LLM编程框架，核心理念是"编程而非提示词"（Programming—not prompting）[15]。2025年成为提示工程的"终结者"框架。

适用场景

• 需要自动优化推理链路的场景

• 学术研究和实验

• 对提示词质量有极致要求的场景

集成方式

DSPy通过Signature + Teleprompter机制自动优化推理链路[15]：

• Signature：声明式定义输入/输出规范

• Teleprompter：自动搜索最优提示词和推理策略

DSPy可间接实现ToT/GoT效果：

 import dspy
 ​
 class ComplexReasoning(dspy.Signature):
     """多步推理任务"""
     question = dspy.InputField()
     reasoning_steps = dspy.OutputField(desc="推理步骤树")
     answer = dspy.OutputField()
 ​
 # 自动优化推理策略
 optimizer = dspy.BootstrapFewShot(metric=accuracy)
 optimized_program = optimizer.compile(program, trainset=train_data)

达成效果

• 自动化程度高：无需手动设计提示词

• 持续优化：基于反馈自动改进

• 效果稳定：90%的QA场景中RAG+DSPy优于手动Agent[15]

局限性

• 学习曲线陡峭

• 不直接提供ToT/GoT的显式API

• 更适合"优化现有方案"而非"构建全新推理架构"

---

2.7 国内框架生态概览

百度飞桨（PaddleNLP）

• 定位：模型微调和底层NLP任务

• Agent能力：通过PaddleNLP提供基础的Agent开发工具链

• ToT/GoT支持：无原生支持，需基于底层API自行实现

阿里通义千问（Qwen）

• 定位：全模态大模型服务平台

• Agent能力：Qwen3-Coder具备编程Agent能力

• 关键发现：在性能实测中，DeepSeek-V2的工具调用成功率93%、ToT分支质量4.5分（满分5分），表现优异[2]

华为MindSpore

• 定位：AI计算框架

• Agent能力：华为专家观点认为，Agent的核心推理模式包括CoT、ToT、ReAct等，并强调ReAct框架在企业级应用中的价值[16]

DeepSeek

• 定位：前沿AI模型

• Agent能力：提供API接口构建Agent，支持ReAct、CoT等推理

• ToT/GoT支持：需结合LangChain等框架实现

Coze（扣子）

• 定位：字节跳动AI Bot开发平台

• Agent能力：工作流+Agent节点编排

• 核心能力：可视化工作流、插件市场、知识库集成

• ToT/GoT支持：无原生ToT/GoT推理节点，可通过自定义工作流模拟分支探索

---

三、四代推理范式综合对比

3.1 性能实测对比（基于A100 80G × 2测试环境）[2]

模型	CoT准确率	ReAct成功率	ToT分支质量(1-5)	GoT图稳定性
DeepSeek-V2	89%	93%	4.5	★★★★★
Qwen2-72B	91%	88%	4.2	★★★★☆
Llama3-70B	85%	82%	3.8	★★★☆☆
InternLM2-20B	83%	79%	3.9	★★★★☆
Phi-3-mini	42%	35%	2.1	★☆☆☆☆

3.2 成本与延迟对比（客服场景实测）[2]

框架	平均延迟	P95延迟	单次GPU成本	用户满意度(NPS)
直接问答	320ms	410ms	$0.0012	32
CoT	480ms	620ms	$0.0018	41
ReAct	1250ms	2100ms	$0.0045	68
ToT（3分支）	2800ms	4500ms	$0.0120	53

3.3 生产环境30天压测故障分析[2]

框架	主要故障模式	占比	推荐恢复策略
CoT	思考步骤断裂	92%	框架层强制格式校验，temperature降至0.3
ReAct	Observation解析失败	76%	沙箱+JSON Schema校验+降级本地缓存
ToT	评估失焦（各分支得分相同）	89%	引入外部二分类评估器
GoT	节点死锁	67%	500ms硬性超时+注入默认值

3.4 工程投入与运维复杂度对比[2]

维度	CoT	ReAct	ToT	GoT
工程投入	低	中	高	极高
Token消耗(相对CoT)	1×	1.5-2×	3-5×	5×以上
运维复杂度	基准	2-3×	4-5×	≈8×
Token节省(vs ToT)	-	-	基准	节省15-30%

---

四、核心开源项目与资源索引

项目	地址	说明
LangGraph ToT 官方教程	github.langchain.ac.cn/langgraph/tutorials/tot	LangChain官方ToT实现教程
GoT 官方实现	github.com/spcl/graph-of-thoughts	ETH Zurich论文参考实现
ToT 论文	arxiv.org/abs/2305.10601	Yao et al. NeurIPS 2023
GoT 论文	arxiv.org/abs/2308.09687	Besta et al. AAAI 2024
DSPy	github.com/stanfordnlp/dspy	斯坦福LLM编程框架
Dify	github.com/langgenius/dify	开源LLM应用开发平台
AutoGen	github.com/microsoft/autogen	微软多Agent框架
CrewAI	github.com/crewAIInc/crewAI	多Agent协作框架
Awesome AI Agent Frameworks	github.com/Vincentwei1021/awesome-ai-agent-frameworks	AI Agent框架汇总

---

五、实战选型建议

5.1 分场景推荐矩阵

场景	推荐框架	推理范式	理由
数学推理/逻辑题	LangGraph + ToT	ToT	效果最验证，成功率74% vs CoT 4%
客服/信息检索	LangChain + ReAct	ReAct	NPS最高(68)，"确定性"优先
企业工作流编排	Dify Agent节点	Function Calling + 自定义	低代码、可视化、团队协作友好
跨领域知识融合	GoT (ETH官方)	GoT	质量比ToT高62%，成本低31%
多Agent协作	CrewAI + LangGraph	混合	角色分工 + 推理增强
学术研究/实验	DSPy + LangGraph	可编程优化	自动优化推理链路
简单QA/标准化任务	CoT Only	CoT	成本最低，延迟最低

5.2 选型决策树[2]

 问题是否需要外部数据验证？
   ├── 是 → ReAct（Dify / LangChain）
   │         └── 问题是否存在多个合理解？
   │               ├── 是 → ToT（LangGraph）
   │               └── 否 → ReAct即可
   └── 否 → CoT
             └── 解法是否需要跨领域知识融合？
                   ├── 是 → GoT（需先稳定运行ReAct半年以上）
                   └── 否 → ToT（仅在决策价值>计算成本时使用）

5.3 核心原则

1. CoT是底线：任何项目都应先用CoT建立baseline

2. ReAct是分水岭：答案依赖外部验证时必上ReAct

3. ToT要克制：仅用于"决策结果价值远高于计算成本"的场景

4. GoT要慎之又慎：未经历过ReAct半年稳定运行前不要碰GoT

5. 用最简单的方案解决最痛的问题 — 技术先进性 ≠ 用户体验最优解

---

六、参考文献

[1] 知乎. (2026). 思维树（TOT）原理之最全详细图解. https://zhuanlan.zhihu.com/p/2016203803507041619

[2] CSDN. (2026). AI推理四代演进：CoT、ReAct、ToT、GoT实战选型指南. https://wenku.csdn.net/column/4t3s1jjmn04

[3] CSDN. (2026). 【AIAgent架构决策指南】：ReAct、CoT、ToT三大范式性能对比实测. 【AIAgent架构决策指南】：ReAct、CoT、ToT三大范式性能对比实测（2024 LLM推理延迟/准确率/可解释性三维权威评测）-CSDN博客

[4] Yao, S. et al. (2023). Tree of Thoughts: Deliberate Problem Solving with Large Language Models. NeurIPS 2023. https://arxiv.org/abs/2305.10601

[5] PromptingGuide.ai. (2026). 思维树 (ToT) 技术文档. 思维树 (ToT) | Prompt Engineering Guide

[6] 知乎. (2025). Graph of Thoughts：让大语言模型解决复杂问题的新框架. https://zhuanlan.zhihu.com/p/1888306237273257919

[7] LangChain. (2026). LangGraph Tree of Thoughts 官方教程. 思科树 - LangChain 教程

[8] 知乎. (2025). Dify "Agent节点" 让工作流学会"自主推理". https://zhuanlan.zhihu.com/p/1914039414579003555

[9] Besta, M. et al. (2023). Graph of Thoughts: Solving Elaborate Problems with Large Language Models. AAAI 2024. https://arxiv.org/abs/2308.09687

[10] CSDN. (2025). AI Agent设计模式 Day 8：Graph-of-Thoughts模式：图结构推理网络. AI Agent设计模式 Day 8：Graph-of-Thoughts模式：图结构推理网络_graph of thought-CSDN博客

[11] 腾讯云开发者社区. (2026). AutoGen 架构演进全梳理. AutoGen 架构演进全梳理：从 v0.4 到 Microsoft Agent Framework-腾讯云开发者社区-腾讯云

[12] Microsoft. (2024). The future of Planners in Semantic Kernel. The future of Planners in Semantic Kernel | Microsoft Agent Framework

[13] GitHub. (2026). Awesome AI Agent Frameworks. https://github.com/Vincentwei1021/awesome-ai-agent-frameworks

[14] CSDN. (2025). CrewAI Hierarchical Process 实战示例. CrewAI Hierarchical Process 实战示例：层级管理模式 Embeddings 和向量数据库_crewai 如何存储到数据库-CSDN博客

[15] 知乎. (2025). AI智能体，第7章 提示词工程的终结：DSPy自动优化. https://zhuanlan.zhihu.com/p/1978742952189776400

[16] 时习知（华为）. (2026). 华为大咖说丨AI Agent在软件工程工具领域有何应用？ - 微信公众号文章