这次我们来看一个能显著提升 AI Agent 推理能力的实战技术组合ToT思维树与后退提示。对于正在开发或研究 AI Agent 的工程师和研究者来说如果你的 Agent 在处理复杂、多步骤任务时经常“卡壳”或得出错误结论那么这个组合值得你立刻关注。它不是什么新模型而是一套系统性的提示词工程与推理框架能让现有的大语言模型LLMAgent 表现得像拥有了“深思熟虑”和“回溯纠错”的能力。简单来说ToT 让 Agent 像人类一样在解决问题时考虑多种可能的路径分支并评估每条路径的优劣后退提示则是在 Agent 推理走入死胡同时提供一套标准化的“回退”机制引导它回到上一个正确的决策点尝试其他可能性。两者的结合相当于为 Agent 装上了“规划地图”和“安全气囊”。本文将直接切入实战带你快速理解 ToT 和后退提示的核心思想并通过一个具体的代码示例演示如何将它们集成到你的 Agent 项目中。我们会重点关注这套方法的实现门槛、对现有代码的改造量、以及实际效果验证让你能快速判断是否值得投入并知道如何上手。1. 核心能力速览在深入代码之前我们先通过一个表格快速把握 ToT 后退提示这套组合拳的核心价值与特点。能力项说明核心目标提升 AI Agent 在复杂、多步骤任务中的规划、推理和纠错能力。技术本质提示词工程与推理框架非新模型。可与 GPT-4、Claude、DeepSeek 等主流 LLM 结合使用。硬件门槛无额外要求。完全依赖你所使用的 LLM 的 API 调用成本与速率限制。本地部署的模型同样适用。主要组件1.ToT (Tree of Thoughts): 思维树用于多路径探索与评估。2.Backtracking Prompt (后退提示): 用于在路径失败时引导 Agent 回溯并尝试其他分支。启动/集成方式通过代码集成到现有 Agent 循环或工作流中。通常需要改造 Agent 的plan或reasoning步骤。是否支持 API是。其核心是组织 Prompt 和调用 LLM API天然支持远程 API 调用。是否支持批量任务是但需谨慎设计。由于涉及多轮探索可能增加 API 调用次数和成本需要实现任务队列和状态管理。适合场景数学推理、多约束规划如旅行规划、代码调试、策略游戏如24点、复杂决策制定等需要分步思考的任务。不适合场景简单单轮问答、情感分析、纯分类任务。引入 ToT 会带来不必要的复杂度。2. 适用场景与使用边界ToT 和后退提示不是银弹理解其适用边界能帮你更有效地应用。它最适合谁AI Agent 开发者正在构建需要多步骤任务分解和规划的智能体如自动化客服、编码助手、游戏 AI。提示词工程师希望突破简单 Chain-of-Thought思维链的瓶颈实现更稳健的复杂问题求解。LLM 应用研究者探索如何在不微调模型的情况下通过框架设计最大化现有模型的推理潜力。能解决什么问题路径单一导致的失败传统 Agent 按一条链思考一旦某步出错全盘皆输。ToT 允许多路径探索找到更优解。缺乏评估与选择Agent 生成一个方案就执行ToT 引入“状态评估”步骤让 Agent 能比较不同方案的优劣。陷入死循环或无效状态后退提示提供标准化操作让 Agent 能主动承认当前路径无效并安全地回溯避免“卡死”。需要警惕的边界成本与延迟多路径探索意味着更多的 LLM API 调用直接增加经济成本和响应时间。需要设置最大探索深度和宽度分支数作为止损点。评估的可靠性由 LLM 自己评估自己的“思维状态”可能不可靠可能需要引入更复杂的评估机制如验证器、工具调用。问题定义需要将问题清晰地形式化为“状态”和“操作”这对于非结构化的开放域问题可能比较困难。合规与安全当 Agent 用于自动化决策如金融、医疗建议时其多路径推理过程必须可解释、可审计。回溯机制不应被用于规避安全护栏。3. 环境准备与前置条件由于 ToT 后退提示是一个框架层面的实现它不依赖特定的 GPU 或复杂的本地环境。你的准备主要围绕编程环境和 LLM 接入。Python 环境推荐 Python 3.8。这是大多数 AI 框架和 LLM SDK 支持的主流版本。依赖管理使用pip和virtualenv或conda创建隔离环境。核心依赖包openai/anthropic/ 其他 LLM SDK用于调用大模型 API。langchain/llama-index(可选)如果你已有的 Agent 基于这些框架可以更方便地集成。但 ToT 核心逻辑可以独立于这些框架实现。tenacity/backoff(推荐)用于处理 API 调用时的速率限制和临时错误实现重试机制。LLM API 密钥准备好你选择的 LLM 服务如 OpenAI, Anthropic, DeepSeek 等的 API Key并确保有足够的额度。代码编辑器或 IDE如 VS Code, PyCharm 等。4. 核心概念与代码框架在动手集成前我们需要用代码来定义几个核心概念。下面是一个高度简化但完整的 ToT 框架示例包含了后退提示的雏形。# tot_framework.py from typing import List, Dict, Any, Optional, Tuple import openai # 此处以 OpenAI 为例可替换为任何 LLM 客户端 class ThoughtState: 表示思维树中的一个‘状态’或‘节点’。 def __init__(self, description: str, parent: Optional[ThoughtState] None): self.description description # 当前状态的文本描述 self.parent parent # 父节点 self.children: List[ThoughtState] [] # 子节点后续可能的状态 self.value: Optional[float] None # 评估值越高越好 self.is_terminal: bool False # 是否为目标状态问题解决 class ToTAgent: 一个简单的 ToT Agent 实现框架。 def __init__(self, llm_client, max_depth5, max_width3): self.llm llm_client self.max_depth max_depth # 最大探索深度 self.max_width max_width # 每个节点最多扩展几个子节点 def generate_thoughts(self, state: ThoughtState) - List[str]: 给定当前状态让 LLM 生成可能的下一步‘思考’操作。 prompt f 你正在解决一个复杂问题。当前的状态是{state.description} 请列出最多 {self.max_width} 个合理的下一步行动或思考方向。每个方向用一行短句描述。 输出格式 - 行动1 - 行动2 response self._call_llm(prompt) # 简单解析按行分割并清理 thoughts [line.strip(- ).strip() for line in response.split(\n) if line.strip().startswith(-)] return thoughts[:self.max_width] def evaluate_state(self, state: ThoughtState) - float: 评估一个状态的好坏0-1之间。 prompt f 评估以下问题解决状态的好坏分数在0到1之间1表示非常接近最终正确答案0表示完全错误或无关。 状态{state.description} 只输出一个浮点数不要有其他文字。 try: response self._call_llm(prompt).strip() score float(response) return max(0.0, min(1.0, score)) # 钳制在0-1 except: return 0.0 # 评估失败则给低分 def _call_llm(self, prompt: str) - str: 调用 LLM 的封装函数。这里是一个 OpenAI 示例。 # 在实际应用中请添加错误处理和重试逻辑 response self.llm.chat.completions.create( modelgpt-4, # 可根据需要更换模型 messages[{role: user, content: prompt}], temperature0.7, max_tokens500 ) return response.choices[0].message.content def is_goal_reached(self, state: ThoughtState) - bool: 判断当前状态是否已解决问题。 # 这是一个简化版实际可能需调用LLM或规则判断 prompt f 判断以下状态是否已经完全解决了最初提出的问题只回答‘是’或‘否’。 状态{state.description} response self._call_llm(prompt).strip().lower() return 是 in response or yes in response def backtrack_and_try_alternative(self, current_state: ThoughtState) - Optional[ThoughtState]: 后退提示的核心回溯到父节点并尝试一个未探索过的兄弟节点。 if not current_state.parent: return None # 已经是根节点无法回溯 parent current_state.parent # 查找父节点下是否有尚未被评估为‘死胡同’的子节点 for sibling in parent.children: if sibling ! current_state and sibling.value is not None and sibling.value 0.3: # 假设评估值0.3是可接受的 # 找到了一个可能的替代路径 print(f[后退提示] 从死胡同回溯尝试替代路径{sibling.description[:50]}...) return sibling # 如果兄弟节点都不行继续向上回溯 print(f[后退提示] 当前分支无可行替代向上一级回溯。) return self.backtrack_and_try_alternative(parent)这个框架定义了最基础的组件ThoughtState状态节点和ToTAgent代理主体。backtrack_and_try_alternative方法体现了后退提示的逻辑。5. 实战演练解决“24点”游戏问题我们用一个经典的“24点”游戏给定4个数字通过加减乘除得到24作为例子将上述框架实例化。这是一个完美的 ToT 应用场景因为需要尝试多种运算组合。# game_24_solver.py import random from tot_framework import ThoughtState, ToTAgent import openai class Game24State(ThoughtState): 针对24点游戏的状态。 def __init__(self, numbers: List[int], expression: str , parentNone): # description 格式 “剩余数字[a, b, c], 当前表达式: expr” desc f剩余数字{numbers}, 当前表达式{expression if expression else 无} super().__init__(desc, parent) self.numbers numbers self.expression expression class Game24ToTAgent(ToTAgent): 专用于24点游戏的 ToT Agent。 def generate_thoughts(self, state: Game24State) - List[str]: if len(state.numbers) 1: return [] # 只剩一个数字无法继续操作 thoughts [] # 生成所有可能的两两组合及运算 for i in range(len(state.numbers)): for j in range(i1, len(state.numbers)): a, b state.numbers[i], state.numbers[j] remaining [state.numbers[k] for k in range(len(state.numbers)) if k not in (i, j)] for op in [, -, *, /]: # 避免除零和产生非整数根据游戏规则可调整 if op / and b 0: continue if op /: result a / b # 如果结果不是整数可以跳过根据规则 # if not result.is_integer(): # continue else: result eval(f{a}{op}{b}) new_numbers remaining [result] # 构造新的表达式 new_expr f({a}{op}{b}) if not state.expression else f({state.expression}{op}{b}) # 这里简化直接生成状态描述实际可调用LLM来“思考”哪个操作更好 thought_desc f选择数字 {a} 和 {b}, 进行运算 {op}, 得到中间结果 {result}。新数字集合{new_numbers}。表达式{new_expr} thoughts.append(thought_desc) return thoughts[:self.max_width] # 限制宽度 def evaluate_state(self, state: Game24State) - float: # 24点游戏的评估函数可以更精确 if len(state.numbers) 1: # 只剩一个数字检查是否为24 if abs(state.numbers[0] - 24) 1e-9: return 1.0 # 完美解决 else: return 0.0 # 失败 # 否则评估当前数字集合离24有多“近” # 一个简单的启发式计算所有数字的平均值看与24的差距 avg sum(state.numbers) / len(state.numbers) score 1.0 / (1.0 abs(avg - 24)) # 越接近24分数越高 return score def is_goal_reached(self, state: Game24State) - bool: return len(state.numbers) 1 and abs(state.numbers[0] - 24) 1e-9 def solve_24_game(numbers, api_key): 主求解函数 client openai.OpenAI(api_keyapi_key) agent Game24ToTAgent(client, max_depth10, max_width4) root_state Game24State(numbers) current_state root_state path [current_state] for step in range(agent.max_depth): print(f\n 步骤 {step} ) print(f当前状态: {current_state.description}) # 1. 检查是否已达目标 if agent.is_goal_reached(current_state): print(f✅ 成功找到解表达式{current_state.expression}) return True, path # 2. 生成后续思考 thoughts agent.generate_thoughts(current_state) if not thoughts: print(⚠️ 无法生成更多后续步骤尝试回溯。) # 触发后退提示 current_state agent.backtrack_and_try_alternative(current_state) if current_state is None: print(❌ 回溯失败无解。) return False, path path.append(current_state) continue print(f生成 {len(thoughts)} 个可能步骤:) for i, t in enumerate(thoughts): print(f {i1}. {t}) # 3. 评估并选择最佳子节点 (这里简化选择第一个) # 实际ToT中会评估所有子节点选择评估值最高的 best_thought thoughts[0] # 根据 thought_desc 解析出新的状态 (此处简化实际需要解析描述更新numbers和expression) # 假设我们有一个函数 parse_thought 来创建新状态 new_state parse_thought_to_state(best_thought, current_state) # 需要实现 new_state.value agent.evaluate_state(new_state) # 4. 将新状态加入树 new_state.parent current_state current_state.children.append(new_state) current_state new_state path.append(current_state) # 5. 简单剪枝如果评估值太低直接回溯 if new_state.value 0.2: print(f⚠️ 步骤评估值过低({new_state.value:.2f})触发回溯。) current_state agent.backtrack_and_try_alternative(current_state) if current_state is None: print(❌ 回溯失败无解。) return False, path path.append(current_state) print(❌ 达到最大深度限制未找到解。) return False, path # 辅助函数将文本思考解析为 Game24State 对象 (简化版) def parse_thought_to_state(thought_desc, parent_state): # 这是一个非常简化的解析仅用于演示。实际应用需要更健壮的解析。 import re # 尝试从描述中提取数字和表达式 # 示例 “选择数字 4 和 6, 进行运算 *, 得到中间结果 24。新数字集合[24, 3, 2]。表达式(4*6)” nums_match re.search(r新数字集合\[([\d\., ])\], thought_desc) expr_match re.search(r表达式(.)$, thought_desc) if nums_match and expr_match: nums_str nums_match.group(1) new_numbers [int(n.strip()) for n in nums_str.split(,)] new_expr expr_match.group(1) return Game24State(new_numbers, new_expr, parent_state) else: # 解析失败返回一个默认状态 return Game24State(parent_state.numbers, parent_state.expression, parent_state) if __name__ __main__: # 替换为你自己的 API Key OPENAI_API_KEY your-api-key-here # 测试用例 test_numbers [4, 6, 3, 2] # 有解(4*6)*(3-2)24 success, solution_path solve_24_game(test_numbers, OPENAI_API_KEY) if success: print(\n 求解成功) else: print(\n 未能在限制内找到解。)运行这个脚本记得填入有效的 OpenAI API Key你将看到 Agent 如何一步步探索不同的运算组合并在评估值过低时触发后退提示回溯到上一个节点尝试其他分支。控制台输出的日志清晰地展示了 ToT 的搜索和回溯过程。6. 功能测试与效果验证如何验证你的 ToT Agent 是否工作正常可以从以下几个维度设计测试用例1. 基础推理能力测试目标确认 Agent 能对简单问题生成多步思考。方法使用一个已知有解的“24点”题目如 [3, 3, 8, 8]。输入初始数字列表。操作运行solve_24_game函数。预期结果在最大深度内找到至少一个解并输出正确的表达式。成功标准Agent 输出表达式且计算结果等于24。失败排查检查generate_thoughts是否生成了包含正确运算的组合检查evaluate_state函数是否给接近解的状态打了高分。2. 后退提示机制测试目标确认 Agent 在走入死胡同时能有效回溯。方法设计一个测试其中某条分支明显是错的例如过早地使用了除法导致出现分数。输入数字列表并可能在generate_thoughts中暂时“误导”Agent 优先选择不好的操作。操作观察控制台日志。预期结果当错误分支的评估值低于阈值如0.2时能看到[后退提示]日志并且 Agent 切换到了另一个分支。成功标准Agent 没有在错误分支上无限循环最终通过回溯找到了解或探索了其他分支。失败排查检查backtrack_and_try_alternative逻辑确保它能正确找到未探索或可接受的兄弟节点检查评估阈值是否设置合理。3. 多路径探索测试目标验证 ToT 的“宽度”搜索能力。方法设置max_width大于1观察每个步骤生成的thoughts列表。输入任意数字列表。操作运行并打印每一步生成的所有thoughts。预期结果每一步都产生了多个最多max_width个不同的后续步骤描述。成功标准generate_thoughts方法返回了多样化的选项而不是重复或相似的。失败排查检查 Prompt 设计是否鼓励多样性LLM 的temperature参数是否设置得当太低的温度可能导致输出单一。4. 性能与成本监控目标了解框架的 API 调用开销。方法在_call_llm函数中添加计数器。操作运行求解器记录总的 LLM 调用次数。预期结果调用次数与探索的节点数深度 x 宽度正相关。成功标准在可接受的时间和成本内找到解。对于“24点”通常应在几十次调用内解决。优化方向如果调用次数过多考虑优化评估函数减少调用或使用更小的模型进行评估步骤。7. 接口 API 与批量任务集成虽然上述示例是脚本形式但 ToT Agent 可以很容易地封装成 API 服务供其他系统调用。1. 封装为 Web API (使用 FastAPI 示例)# api_server.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List import asyncio from your_agent_module import Game24ToTAgent, Game24State, solve_24_game # 导入之前定义的类 app FastAPI(titleToT-24点求解器API) class SolveRequest(BaseModel): numbers: List[int] max_depth: int 10 max_width: int 4 api_key: str # 生产环境应从安全配置读取而非请求体 class SolveResponse(BaseModel): success: bool solution: Optional[str] steps: int api_calls: int error_message: Optional[str] None app.post(/solve/24game, response_modelSolveResponse) async def solve_24game(request: SolveRequest): 异步求解24点游戏 try: # 初始化Agent注意实际生产环境需要管理API Key和客户端 # 这里简单传递实际应用需考虑安全性和客户端复用 success, path solve_24_game(request.numbers, request.api_key) solution_expr path[-1].expression if success and path else None return SolveResponse( successsuccess, solutionsolution_expr, stepslen(path), api_callsgetattr(your_agent, api_call_counter, 0) # 假设你在Agent里统计了 ) except Exception as e: raise HTTPException(status_code500, detailstr(e)) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)2. 批量任务处理对于需要处理大量独立问题的场景如批量为100组数字求解24点你需要一个任务队列。设计要点任务队列使用 Redis (RQ) 或 Celery 管理待求解任务。资源隔离每个任务运行在独立的进程或协程中避免状态污染。结果存储将求解结果成功/失败、表达式、步骤数存入数据库如 SQLite/PostgreSQL或文件。限流与重试由于依赖外部 LLM API必须实施速率限制和失败重试机制。伪代码示例# batch_processor.py import redis from rq import Queue from your_solver import solve_24_game_wrapper # 一个包装函数处理单次求解 redis_conn redis.Redis() q Queue(connectionredis_conn) def submit_batch_tasks(number_lists: List[List[int]]): for nums in number_lists: q.enqueue(solve_24_game_wrapper, nums, result_ttl86400) # 任务入队 # Worker 端会从队列取出任务并执行 solve_24_game_wrapper8. 资源占用与性能观察由于 ToT 框架本身不涉及本地大模型推理其“资源占用”主要体现在API 调用成本、延迟和程序内存上。API 调用成本主要消耗点generate_thoughts、evaluate_state、is_goal_reached以及可能集成在其中的_call_llm。观察方法在_call_llm方法中添加计数器并在任务结束时输出。监控你的 LLM 服务提供商的控制台用量。优化策略缓存对相同的状态描述 (state.description) 的评估结果进行缓存。简化评估用更简单的规则或小模型如 GPT-3.5-turbo进行评估步骤用大模型如 GPT-4进行关键步骤的生成。限制探索合理设置max_depth和max_width这是控制成本最直接的阀门。响应延迟影响因素网络延迟、LLM API 响应速度、探索的节点总数。观察方法使用 Python 的time模块记录每个_call_llm的耗时和总耗时。优化策略异步调用如果生成了多个子节点需要评估可以使用asyncio.gather并发调用 LLM API需确认 API 支持。提前剪枝在generate_thoughts阶段就用简单规则过滤掉明显无效的操作减少需要评估的节点。程序内存与状态管理占用内容主要是维护的ThoughtState对象树。观察方法对于深度和宽度不大的问题内存占用可忽略。对于超大搜索空间可使用tracemalloc监控。优化策略对于已评估为非常差低分且无需回溯的分支可以主动释放其子节点的引用让垃圾回收器工作。9. 常见问题与排查方法在实现和运行 ToT Agent 时你可能会遇到以下问题问题现象可能原因排查方式解决方案Agent 陷入无限循环不断重复相同步骤。1.generate_thoughts生成的选项缺乏多样性。2. 状态描述没有包含足够信息导致LLM认为不同状态是相同的。3. 后退提示逻辑有误无法找到有效的兄弟节点。1. 打印每一步的状态描述和生成的thoughts检查是否重复。2. 检查ThoughtState的description是否唯一标识了状态。3. 在backtrack_and_try_alternative中添加详细日志。1. 在 Prompt 中强调“生成不同的、新颖的”思考。2. 在状态描述中加入步骤计数器或随机种子以确保唯一性。3. 确保回溯时能访问到父节点的完整子节点列表并正确判断哪些是“未尝试”或“可接受”的。评估函数 (evaluate_state) 打分不准确导致总是选错分支。1. Prompt 设计不合理LLM 无法理解评估标准。2. 评估任务本身对 LLM 来说太难或太模糊。1. 手动检查几个状态的描述和 LLM 给出的分数看是否符合直觉。2. 尝试用更明确的规则如果可能替代 LLM 评估。1. 重构评估 Prompt提供更清晰的指令和示例Few-shot。2. 实现一个混合评估器先用简单规则过滤再用 LLM 对候选集进行精细排序。API 调用次数爆炸成本过高。max_depth和max_width设置过大搜索空间呈指数增长。记录每个任务的 API 调用次数并与 (max_depth * max_width) 的理论上限对比。1.大幅降低max_width这是最有效的控制手段优先尝试最有希望的少数分支。2. 使用启发式搜索如 A*优先探索评估值高的分支而不是广度优先。3. 在达到成本预算时提前终止。后退提示很少或从不触发。1. 评估阈值 (value 0.2) 设置得太低。2.backtrack_and_try_alternative逻辑无法找到符合条件的兄弟节点。1. 打印每个节点的评估值。2. 检查当评估值低于阈值时代码是否确实执行了回溯函数。1. 调整评估阈值或改为动态阈值例如如果连续 N 步分数未提升则触发回溯。2. 改进回溯逻辑允许回溯到更早的祖先节点或尝试生成全新的兄弟节点而不仅仅是已有的。对于某些问题Agent 很快宣布无解。1.max_depth设置过小问题需要的步骤更多。2.generate_thoughts函数未能生成关键的正确操作。1. 增加max_depth并重新运行。2. 分析问题手动思考解决方案检查你的generate_thoughts函数是否有可能生成导致该解的操作。1. 根据问题复杂度动态调整max_depth。2. 增强generate_thoughts的能力例如通过更丰富的 Prompt 或结合领域知识库来生成操作。10. 最佳实践与使用建议将 ToT 和后退提示投入实际项目前请考虑以下建议从小开始迭代验证不要一开始就用于最复杂的任务。选择一个像“24点”这样有明确规则和答案的基准问题进行原型验证。确保框架的基本逻辑生成、评估、回溯工作正常。精心设计状态描述ThoughtState.description是 LLM 理解当前进度的唯一窗口。它应该包含解决问题所需的所有关键信息并且格式要清晰、一致。分离生成与评估模型如果成本允许使用一个能力强但贵的模型如 GPT-4进行“生成”使用一个便宜且快的模型如 GPT-3.5-turbo进行“评估”。这能在保证思考质量的同时控制成本。实现持久化和可视化将搜索树节点、边、评估值保存为 JSON 或图结构。使用graphviz等库进行可视化。这对于调试搜索过程和理解 Agent 的“思考”路径至关重要。设置严格的超时和成本上限在 Agent 主循环中除了深度和宽度限制还要设置最大运行时间或最大 API 调用次数。避免因 bug 或困难问题导致无限运行和巨额账单。为你的领域定制本文的“24点”示例是一个特定领域。要将 ToT 应用到你的任务如代码调试、旅行规划你需要定义专属的YourDomainState类。实现领域相关的generate_thoughts例如代码调试中可能是“检查变量X”、“添加打印语句”、“查阅文档Y”。设计有效的evaluate_state函数例如代码调试中可能是“程序崩溃了”得0分“通过了更多测试用例”得更高分。合规与伦理考量当 Agent 用于做出影响现实的决策时必须确保其推理过程是可控、可解释的。ToT 生成的搜索树本身是一种可解释的审计轨迹应妥善记录。ToT 思维树与后退提示的结合为 AI Agent 的推理能力提供了一个强大的框架范式。它最吸引人的地方在于不依赖于模型本身的升级而是通过架构设计释放出现有模型的潜力。实战的关键在于将你的具体问题巧妙地映射到“状态”和“操作”上并设计出有效的状态评估函数。建议你从文中的“24点”示例代码开始替换成你自己的 API Key 运行一遍观察整个搜索和回溯过程。然后尝试将其改造用于一个你熟悉的简单问题比如为一个周末活动做计划。通过这个过程你会对如何控制搜索成本、设计评估标准有更深刻的理解从而能够将这套方法真正应用到你的 Agent 项目中去解决那些令传统单链思维 Agent 头疼的复杂任务。