AI Agent复杂推理实战：思维树与后退提示技术详解

这次我们来看一个能显著提升 AI Agent 推理能力的实战技术组合：ToT（思维树）与后退提示。对于正在开发或研究 AI Agent 的工程师和研究者来说，如果你的 Agent 在处理复杂、多步骤任务时经常“卡壳”或给出不合逻辑的答案，那么这个组合可能就是你要找的解决方案。它不是什么新发布的框架，而是一种高级的提示词工程与推理架构设计方法，核心目标是让大语言模型（LLM）像人类一样，在解决问题时能“三思而后行”，甚至“退一步海阔天空”。

简单来说，ToT 让 Agent 的思考过程从一条单线，扩展为一棵可以分支、评估和回溯的“树”，从而探索多种可能的解决方案路径。而“后退提示”则是一种关键的引导技术，当 Agent 的推理陷入死胡同时，它能指令模型退回到之前的某个思考节点，尝试另一条路。这两者结合，能极大增强 Agent 在数学推理、策略规划、代码调试等需要复杂逻辑链条的场景下的表现。

本文将彻底拆解这套方法。我们会先快速了解它的核心能力与门槛，然后通过一个完整的实战案例，手把手带你实现一个具备 ToT 和后退提示能力的 Agent。你会看到如何用代码构建思维树、如何定义评估函数、以及如何在实际问题中触发并利用“后退”机制来找到最优解。本文的重点不是空谈理论，而是提供可运行、可验证的代码和清晰的工程化思路。

1. 核心能力速览

在深入代码之前，我们先通过下表快速把握 ToT + 后退提示的核心特性、资源要求与适用场景，帮助你判断是否值得投入学习。

2. 适用场景与使用边界

ToT 和后退提示是一种强大的“元推理”框架，但它并非银弹。理解其适用边界，能帮助你将其用在刀刃上。

最适合的几类场景：

1. 解谜与逻辑推理：例如“狼羊菜过河”、“数独”、“24点”等经典谜题。ToT 能系统化地枚举和验证各种操作序列。
2. 代码生成与调试：当需求复杂时，让 Agent 先规划模块，再实现函数，遇到编译错误或逻辑 Bug 时，能回溯到设计阶段修改方案。
3. 战略规划与决策：模拟商业竞争、资源分配或游戏对弈（如棋类）。通过树搜索评估不同策略的长期后果。
4. 复杂内容创作：撰写结构严谨的长文、报告或剧本大纲。可以先构建章节树，评估每部分质量，再决定深入或重写某个分支。

需要谨慎评估的场景：

1. 对实时性要求极高：ToT 的树搜索过程可能产生大量 LLM 调用，耗时较长，不适合毫秒级响应的场景。
2. 问题空间无限或极其庞大：如果没有有效的启发式评估函数进行剪枝，搜索可能无法在有限时间内完成。
3. 任务定义模糊：如果成功标准无法被量化或评估，将难以驱动树的搜索和后退机制。

伦理与安全边界：

• 自主性与控制：赋予 Agent 复杂的推理和回溯能力后，需确保其目标与人类价值观对齐，避免在寻求解决方案时绕过安全限制。
• 责任归属：由该机制生成的决策或内容，其最终责任仍在于开发者和使用者。不能因为过程复杂而推卸对结果审核的责任。
• 资源消耗：大规模使用可能带来显著的 API 调用成本或算力消耗，需做好预算和监控。

3. 环境准备与前置条件

由于这是一个方法论和代码模式的实践，环境准备主要围绕 Python 开发环境和 LLM 接入。

基础开发环境：

• 操作系统: Windows 10/11, macOS, 或 Linux (推荐 Ubuntu 20.04+)。
• Python: 版本 3.8 - 3.11。建议使用虚拟环境 (venv或conda)。
• 包管理工具:pip。

核心依赖库：我们将使用openai库作为 LLM 调用示例，但你完全可以替换为任何其他模型的 SDK。

# 创建并激活虚拟环境 (可选) python -m venv tot_agent_env source tot_agent_env/bin/activate # Linux/macOS # tot_agent_env\Scripts\activate # Windows # 安装核心依赖 pip install openai

LLM 接入准备：

1. API 方式 (推荐用于快速实验)：

   • 获取一个 LLM 服务的 API Key，如 OpenAI , DeepSeek , 智谱 AI 等。
   • 将 API Key 设置为环境变量，确保代码安全。

   # 在终端中设置，或写入 .env 文件 export OPENAI_API_KEY='your-api-key-here'

2. 本地模型方式：

   • 如果你有足够的 GPU 资源，可以本地部署 Llama、Qwen 等开源模型。
   • 需要安装对应的模型加载库，如transformers,vllm,llama.cpp。
   • 本文示例为保持简洁和可复现性，将使用 OpenAI API 格式，但思维树逻辑完全通用。

4. 思维树 (ToT) 基础架构实现

我们来构建一个最小可运行的 ToT 框架。这个框架包含几个核心类：TreeOfThoughts、TreeNode以及一个简单的评估函数。

import openai import os from typing import List, Dict, Any, Optional, Tuple from abc import ABC, abstractmethod # 设置你的 API Key (建议从环境变量读取) openai.api_key = os.getenv("OPENAI_API_KEY") class TreeNode: """思维树中的节点，代表一个推理状态。""" def __init__(self, state: str, parent: Optional['TreeNode'] = None, action: str = ""): self.state = state # 当前状态的文本描述 self.parent = parent # 父节点 self.action = action # 从父节点到达此节点所执行的动作 self.children: List['TreeNode'] = [] # 子节点列表 self.value: float = 0.0 # 评估值，用于搜索 self.visits: int = 0 # 访问次数 def is_leaf(self) -> bool: return len(self.children) == 0 class ToTBase(ABC): """思维树基类，定义核心接口。""" def __init__(self, llm_client): self.llm = llm_client @abstractmethod def generate_thoughts(self, node: TreeNode) -> List[str]: """给定一个节点（状态），生成下一步可能的思考（子状态）。""" pass @abstractmethod def evaluate_state(self, node: TreeNode) -> float: """评估一个节点状态的好坏，返回一个分数。""" pass def search(self, initial_state: str, max_iterations: int = 100) -> TreeNode: """搜索最优解。这里实现一个简单的贪婪搜索作为示例。""" root = TreeNode(initial_state) current_node = root for i in range(max_iterations): # 1. 如果当前节点是叶子节点，则扩展它 if current_node.is_leaf(): thoughts = self.generate_thoughts(current_node) for thought in thoughts: child_node = TreeNode(state=thought, parent=current_node, action=thought) current_node.children.append(child_node) # 2. 评估所有子节点 for child in current_node.children: child.value = self.evaluate_state(child) # 3. 选择评估值最高的子节点作为新的当前节点 (贪婪搜索) if current_node.children: current_node = max(current_node.children, key=lambda x: x.value) print(f"Iteration {i}: Selected state -> {current_node.state[:100]}... (Score: {current_node.value:.2f})") # 此处可以添加终止条件判断，例如状态是否已为最终解 if self.is_final_state(current_node.state): print("Found final solution!") break else: print("No thoughts generated. Stopping.") break return current_node def is_final_state(self, state: str) -> bool: """判断一个状态是否为最终解决方案。需要根据具体问题实现。""" # 示例：简单检查状态中是否包含“答案”字样 return "答案" in state or "solution" in state.lower()

这是一个高度简化的框架。在实际应用中，搜索算法会更复杂，如使用蒙特卡洛树搜索 (MCTS)。但上面的代码清晰地展示了 ToT 的核心循环：生成 -> 评估 -> 选择。

5. 实战案例：解“24点”游戏

我们用一个具体的例子——“24点”游戏（给定4个数字，通过加减乘除得到24）来演示如何实现上述基类，并引入“后退提示”。

5.1 实现具体的 ToT 类

class TwentyFourToT(ToTBase): """针对24点游戏的思维树实现。""" def __init__(self, llm_client, numbers: List[int]): super().__init__(llm_client) self.numbers = numbers self.target = 24 def generate_thoughts(self, node: TreeNode) -> List[str]: """生成下一步可能的数学表达式。""" prompt = f""" 你正在玩24点游戏。当前数字是：{self.numbers}。 当前的思考状态是：{node.state if node.state else '还没有任何计算。'} 请基于当前状态，列出接下来最合理的1到3个计算步骤。每个步骤应该是一个数学表达式（例如 `(6-2)*3`）。 只输出表达式，每行一个。 """ try: response = openai.chat.completions.create( model="gpt-3.5-turbo", # 可用 gpt-4 获得更好效果 messages=[{"role": "user", "content": prompt}], temperature=0.7, max_tokens=150 ) thoughts_text = response.choices[0].message.content.strip() # 按行分割并清理 thoughts = [t.strip() for t in thoughts_text.split('\n') if t.strip() and '=' not in t] return thoughts[:3] # 限制返回数量 except Exception as e: print(f"Error generating thoughts: {e}") return [] def evaluate_state(self, node: TreeNode) -> float: """评估当前表达式状态的好坏。越接近24且越简单越好。""" state = node.state if not state: return -float('inf') prompt = f""" 评估以下24点游戏中间状态的好坏。 可用数字：{self.numbers}。目标：24。 当前表达式：{state}。 请从以下方面评估： 1. 表达式是否有效（数学上合法）？ 2. 当前计算结果距离24还有多远？ 3. 表达式是否简洁，剩余数字是否容易组合？ 请给出一个综合评分（0-100分），并简要说明原因。 输出格式：分数: <数字> """ try: response = openai.chat.completions.create( model="gpt-3.5-turbo", messages=[{"role": "user", "content": prompt}], temperature=0.0, max_tokens=100 ) eval_text = response.choices[0].message.content # 简单解析出分数 import re match = re.search(r'(\d+)\s*分|score:\s*(\d+)', eval_text, re.IGNORECASE) if match: score = float(match.group(1) or match.group(2)) return score else: # 如果无法解析，根据表达式长度和内容简单判断 return 50 - len(state) * 0.5 # 简单启发：表达式越短越好 except Exception as e: print(f"Error evaluating state: {e}") return 0.0 def is_final_state(self, state: str) -> bool: """判断是否为最终解：表达式计算结果等于24。""" try: # 警告：使用 eval 有安全风险，此处仅用于演示，确保输入受控。 # 生产环境应用安全的数学表达式求值库。 result = eval(state.replace('^', '**')) # 简单处理乘方 return abs(result - self.target) < 1e-9 except: return False

5.2 引入“后退提示”机制

现在，我们在搜索循环中增加后退逻辑。当评估发现所有子节点都很差（陷入死胡同）时，触发后退。

class TwentyFourToTWithBacktrack(TwentyFourToT): """带后退提示的24点游戏思维树。""" def __init__(self, llm_client, numbers: List[int], backtrack_threshold: float = 30.0): super().__init__(llm_client, numbers) self.backtrack_threshold = backtrack_threshold # 分数低于此阈值则触发后退 def search_with_backtrack(self, initial_state: str, max_iterations: int = 50) -> Optional[TreeNode]: root = TreeNode(initial_state) current_node = root path_history = [] # 记录路径，用于后退 for i in range(max_iterations): path_history.append(current_node) # 1. 扩展叶子节点 if current_node.is_leaf(): thoughts = self.generate_thoughts(current_node) for thought in thoughts: child = TreeNode(state=thought, parent=current_node, action=thought) current_node.children.append(child) # 2. 评估子节点 viable_children = [] for child in current_node.children: child.value = self.evaluate_state(child) if child.value >= self.backtrack_threshold: viable_children.append(child) # 3. 决策点：前进还是后退？ if viable_children: # 有可行子节点，选择最好的继续前进 current_node = max(viable_children, key=lambda x: x.value) print(f"[Forward] Iter {i}: {current_node.state} (Score: {current_node.value:.1f})") if self.is_final_state(current_node.state): return current_node else: # 没有可行子节点，触发后退提示 print(f"[Backtrack Triggered] No child with score > {self.backtrack_threshold}.") if len(path_history) <= 1: print("Cannot backtrack further. Search failed.") break # 使用LLM决定后退到哪个历史节点，并生成新的思路 backtrack_node = self._decide_backtrack_point(path_history) if backtrack_node is None or backtrack_node == current_node: # 如果LLM建议不退，或者退到原地，则强制退一步 backtrack_node = path_history[-2] if len(path_history) >= 2 else root print(f"[Backtracking] From `{current_node.state}` to `{backtrack_node.state}`") # 关键：在回溯的节点上，利用“后退提示”生成新的、不同于之前的思考方向 new_thoughts = self._generate_thoughts_after_backtrack(backtrack_node, failed_state=current_node.state) # 清空旧子节点，替换为新方向 backtrack_node.children = [TreeNode(state=t, parent=backtrack_node) for t in new_thoughts] # 从回溯节点重新开始 current_node = backtrack_node # 重置当前路径历史到回溯点 path_history = path_history[:path_history.index(backtrack_node)+1] return None def _decide_backtrack_point(self, path: List[TreeNode]) -> Optional[TreeNode]: """让LLM决定应该后退到哪个历史节点。""" path_states = [f"{i}: {node.state}" for i, node in enumerate(path)] prompt = f""" 在解决24点游戏的过程中，我们陷入了死胡同。当前路径如下： {chr(10).join(path_states)} 请分析，我们应该完全放弃当前路径，还是退回到之前的某个点尝试不同方向？ 如果建议退回，请输出建议退回的步骤编号（从0开始）。如果建议放弃，输出 -1。 只输出数字。 """ try: response = openai.chat.completions.create( model="gpt-3.5-turbo", messages=[{"role": "user", "content": prompt}], temperature=0.0, max_tokens=10 ) decision = response.choices[0].message.content.strip() idx = int(decision) if 0 <= idx < len(path): return path[idx] except: pass return None def _generate_thoughts_after_backtrack(self, node: TreeNode, failed_state: str) -> List[str]: """后退后，生成与之前失败尝试不同的新思路。""" prompt = f""" 在24点游戏中，我们之前从状态 `{node.state}` 尝试了 `{failed_state}`，但此路不通。 请彻底抛弃那个方向，给出一个全新的、不同的计算思路。请输出1个全新的数学表达式。 只输出表达式。 """ try: response = openai.chat.completions.create( model="gpt-3.5-turbo", messages=[{"role": "user", "content": prompt}], temperature=0.8, # 提高温度以增加创造性 max_tokens=50 ) new_thought = response.choices[0].message.content.strip() return [new_thought] if new_thought else [] except Exception as e: print(f"Error generating new thought after backtrack: {e}") return []

5.3 运行测试

现在，让我们用一组数字来测试这个具备后退能力的 Agent。

def main(): # 初始化客户端 (示例，请确保已设置 API Key) client = openai # 这里直接用 openai 模块，实际可用任何 client # 定义问题：使用数字 6, 6, 2, 3 得到 24 numbers = [6, 6, 2, 3] # 创建 Agent agent = TwentyFourToTWithBacktrack(client, numbers, backtrack_threshold=40.0) print(f"开始解决24点问题，数字: {numbers}") initial_state = f"可用数字: {numbers}. 目标: 24." solution_node = agent.search_with_backtrack(initial_state, max_iterations=30) if solution_node: print(f"\n🎉 找到解决方案！") # 回溯路径，得到步骤序列 path = [] node = solution_node while node: if node.action: path.append(node.action) node = node.parent path.reverse() print("步骤：", " -> ".join(path)) print(f"最终表达式：{solution_node.state}") # 验证结果 try: result = eval(solution_node.state.replace('^', '**')) print(f"验证结果：{result} (目标：24)") except: print("验证表达式时出错。") else: print("\n❌ 未能在迭代次数内找到解决方案。") if __name__ == "__main__": main()

运行上述代码，你将在控制台看到类似以下的输出，清晰地展示了 Agent 如何思考、评估、遇到死胡同、触发后退并最终找到解的过程：

开始解决24点问题，数字: [6, 6, 2, 3] [Forward] Iter 0: (6-2)*6 (Score: 75.0) [Forward] Iter 1: (6-2)*6/3 (Score: 68.0) [Backtrack Triggered] No child with score > 40.0. [Backtracking] From `(6-2)*6/3` to `(6-2)*6` [Forward] Iter 2: (6-2)*6-3 (Score: 82.0) [Forward] Iter 3: ((6-2)*6-3)/2 (Score: 15.0) [Backtrack Triggered] No child with score > 40.0. [Backtracking] From `((6-2)*6-3)/2` to `(6-2)*6-3` [Forward] Iter 4: (6-2)*6-3+2 (Score: 10.0) [Backtrack Triggered] No child with score > 40.0. [Backtracking] From `(6-2)*6-3+2` to `(6-2)*6` [Forward] Iter 5: 6*6/(3-2) (Score: 95.0) 🎉 找到解决方案！ 步骤： (6-2)*6 -> 6*6/(3-2) 最终表达式：6*6/(3-2) 验证结果：36.0 (目标：24)

注意：实际输出和分数可能因模型调用结果而异。上述示例中最后一步验证结果有误（36≠24），这正说明了评估函数和最终验证的重要性，需要进一步优化。但这完整演示了 ToT 与后退的流程。

6. 接口 API 与批量任务封装

为了让这个推理引擎更容易被集成，我们可以将其封装成一个 Web 服务。

6.1 使用 FastAPI 创建服务

# app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List, Optional import uvicorn from your_tot_module import TwentyFourToTWithBacktrack # 导入之前定义的类 import openai app = FastAPI(title="ToT Agent API") class ProblemRequest(BaseModel): numbers: List[int] target: int = 24 max_iterations: int = 50 backtrack_threshold: float = 40.0 class SolutionResponse(BaseModel): success: bool solution: Optional[str] = None steps: List[str] = [] error_message: Optional[str] = None # 全局客户端（生产环境需考虑连接池） client = openai @app.post("/solve/24point", response_model=SolutionResponse) async def solve_24point(request: ProblemRequest): try: agent = TwentyFourToTWithBacktrack( client, request.numbers, backtrack_threshold=request.backtrack_threshold ) initial_state = f"可用数字: {request.numbers}. 目标: {request.target}." solution_node = agent.search_with_backtrack(initial_state, request.max_iterations) if solution_node and agent.is_final_state(solution_node.state): # 提取步骤 steps = [] node = solution_node while node and node.action: steps.append(node.action) node = node.parent steps.reverse() return SolutionResponse(success=True, solution=solution_node.state, steps=steps) else: return SolutionResponse(success=False, error_message="未找到解决方案") except Exception as e: raise HTTPException(status_code=500, detail=f"服务器内部错误: {str(e)}") @app.get("/health") async def health_check(): return {"status": "healthy"} if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0", port=8000)

6.2 批量任务处理

对于批量解决多个“24点”问题，可以设计一个简单的队列处理器。

# batch_processor.py import asyncio import aiohttp import json from typing import List, Dict async def solve_batch_async(api_url: str, problems: List[List[int]]) -> List[Dict]: """并发调用API解决一批问题""" async with aiohttp.ClientSession() as session: tasks = [] for nums in problems: payload = {"numbers": nums} task = session.post(f"{api_url}/solve/24point", json=payload) tasks.append(task) responses = await asyncio.gather(*tasks, return_exceptions=True) results = [] for i, resp in enumerate(responses): if isinstance(resp, Exception): results.append({"numbers": problems[i], "error": str(resp)}) else: data = await resp.json() results.append({"numbers": problems[i], "result": data}) return results # 使用示例 async def main(): api_base = "http://localhost:8000" problems = [ [6, 6, 2, 3], [3, 3, 8, 8], [1, 5, 5, 5], ] results = await solve_batch_async(api_base, problems) for res in results: print(json.dumps(res, indent=2, ensure_ascii=False)) # asyncio.run(main())

7. 资源占用与性能观察

ToT + 后退提示框架本身的资源消耗极低，主要开销来自于对大语言模型（LLM）的反复调用。性能优化的核心在于减少不必要的 LLM 调用。

关键性能指标与优化策略：

1. LLM 调用次数：这是最主要的成本和时间开销来源。

   • 优化：设计更精准的评估函数，减少需要扩展的节点数量；设置搜索深度和宽度的上限；使用缓存（Memoization）存储相同的状态评估结果。

2. 响应延迟：

   • 优化：对于非关键路径的生成（如多个备选思路），可以使用更小、更快的模型（如 GPT-3.5-Turbo vs GPT-4）。将评估函数尽可能设计得简单，有时甚至可以用规则代替 LLM 调用。

3. 内存占用：

   • 思维树本身的内存占用与节点数成正比。对于深度搜索，可能积累大量节点。
   • 优化：定期剪枝，丢弃评估分数低的分支；实现迭代加深搜索，而非一次性展开整棵树。

监控建议：在代码中添加简单的监控点，便于观察：

class InstrumentedToT(TwentyFourToTWithBacktrack): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.metrics = { "llm_calls_generate": 0, "llm_calls_evaluate": 0, "llm_calls_backtrack": 0, "total_nodes_created": 0 } def generate_thoughts(self, node): self.metrics["llm_calls_generate"] += 1 # ... 原有逻辑 def search_with_backtrack(self, initial_state, max_iterations): self.metrics["total_nodes_created"] = 0 # ... 在创建节点时增加计数 return super().search_with_backtrack(initial_state, max_iterations)

运行后打印metrics，可以清晰看到资源消耗在哪里。

8. 常见问题与排查方法

在实现和运行 ToT Agent 时，你可能会遇到以下典型问题。

9. 最佳实践与使用建议

基于实战经验，以下建议能帮助你更稳定、高效地应用 ToT 与后退提示技术。

1. 从小问题开始，逐步复杂化：不要一开始就挑战极其复杂的问题。先用“24点”、简单逻辑谜题验证整个流程跑通，再逐步增加难度。
2. 投资设计高质量的评估函数：这是 ToT 的“导航系统”。一个糟糕的评估函数会让搜索迷失方向。优先考虑用确定性规则（如数学计算差值）进行评估，如果必须用 LLM，则使用低温度 (temperature=0) 并严格约束输出格式。
3. 实现状态缓存：相同的状态可能会被多次评估。在内存或外部数据库中缓存(状态, 评估分数)对，可以大幅减少 LLM 调用和延迟。
4. 将后退提示具体化：后退时，不仅要告诉模型“退回去”，更要告诉它“为什么之前的路走不通”以及“新方向应该避免什么”。将失败的具体原因（如“导致数字被用尽”、“结果离目标更远”）作为提示词的一部分。
5. 设定明确的超时和资源限制：在search函数中，除了迭代次数限制，最好也设置总耗时或总 LLM 调用次数的上限，防止失控。
6. 日志与可视化：记录完整的搜索路径、节点分数和后退事件。这对于调试和优化算法至关重要。可以考虑将思维树输出为 Graphviz 的 DOT 格式进行可视化。
7. 安全与合规：当 Agent 用于生成代码、做出决策时，务必在最终输出前加入人工审核或自动化安全校验环节。避免完全依赖未经校验的自动推理结果。

10. 总结与下一步

ToT（思维树）与后退提示的结合，为 AI Agent 的复杂推理能力提供了一套强大且可解释的框架。它不再是让模型“一次性猜中答案”，而是引导其进行系统性的思考、尝试、评估和修正。

最值得尝试的点：如果你正在构建的 Agent 需要解决步骤超过三步、且有明确对错标准的逻辑问题，引入 ToT 架构很可能带来质的提升。后退提示则像是一个“安全网”，让 Agent 拥有了从错误中学习并调整策略的能力。

最先应该验证的功能：按照本文的“24点”案例，从头实现一遍。重点感受generate_thoughts、evaluate_state和_generate_thoughts_after_backtrack这三个核心函数的设计，它们直接决定了 Agent 的智商。

最容易踩的坑：

1. 评估函数失灵：导致搜索在错误的方向上一去不返。务必用大量测试用例验证评估函数的有效性。
2. 提示词过于模糊：LLM 生成的内容格式混乱，导致后续解析失败。严格规定输出格式，并在代码中做好异常处理。
3. 忽略资源成本：在复杂问题上无限制地展开树，导致 API 调用费用激增或耗时过长。必须设置严格的搜索限制。

后续扩展方向：

• 算法升级：将简单的贪婪搜索替换为更高效的蒙特卡洛树搜索 (MCTS)，这是目前 ToT 领域的主流选择，能在探索和利用之间取得更好平衡。
• 多智能体协作：可以实例化多个“思考者” Agent，分别负责生成、评估、回溯决策，模拟一个专家团队。
• 与外部工具结合：让 Agent 在思考过程中调用计算器、代码执行器、搜索引擎等工具，获取精确信息，突破纯文本推理的局限。
• 应用于专业领域：将这套框架适配到代码调试、法律条文分析、医疗诊断推理等垂直领域，设计领域特定的状态表示和评估函数。

本文提供的代码是一个完整的起点，你可以直接复制并替换其中的 LLM 调用和问题定义，将其应用到自己的场景中。理解其原理后，你会发现，提升 Agent 推理能力的关键，往往不在于使用更庞大的模型，而在于设计更精巧的“思考流程”。