AI Agent 多步推理：把复杂命令拆成工具调用序列的正确姿势
一、一句话指令背后的迷宫：Agent 为什么总在多步调用中迷路
给 AI Agent 下指令时，最让人头疼的不是单步调用，而是那些看起来简单、实际上需要拆成多个步骤的复合任务。比如用户说"帮我把最近三个月的日志文件按错误类型分类，统计每种错误的出现频率，然后生成一份摘要报告发到 Slack"。这句话对人类来说不算复杂，但对 Agent 来说，它需要依次完成：查找日志文件、读取内容、按错误类型分类聚合、统计频率、格式化报告、调用 Slack API 发送——至少六个工具调用步骤，每一步的输出是下一步的输入。
问题出在哪儿？Agent 在执行多步推理时容易遭遇三种典型迷失：
- 规划迷失：拿到指令后直接开始执行第一步，没有先规划完整步骤序列，导致中途发现缺少某个工具或依赖关系出错。
- 上下文迷失：执行到第三步时，前两步的中间结果已经被上下文窗口挤压，Agent 忘了第一步的输出是什么，推理链断裂。
- 决策迷失：每一步执行完后，Agent 不知道该停下来校验中间结果，还是继续推进下一步，盲目推进导致错误累积。
这三类问题的根源在于：大多数 Agent 实现把"推理"和"行动"混在一起，没有显式的步骤规划和状态管理机制。ReAct（Reasoning + Acting）模式的核心思路就是把这两个阶段分离——先想清楚再动手，每一步都要有明确的推理记录和结果校验。
二、从混乱到有序：ReAct 推理链的状态流转机制
ReAct 模式的全称是 Reasoning-then-Acting，核心思想是让 Agent 在每一步都先做一次推理（Thought），然后基于推理结果选择一个行动（Action），行动完成后观察结果（Observation），再进入下一轮 Thought。这个循环不是无结构的递归调用，而是可以用有限状态机（FSM）严格管理的确定性流程。
下面这张时序图展示了 ReAct 推理链从用户指令到最终汇总的完整状态流转：
sequenceDiagram participant User as 用户 participant Planner as 规划器 participant FSM as 状态机引擎 participant Thought as 推理模块 participant ToolExec as 工具执行器 participant Validator as 结果校验器 User->>Planner: 发送复合指令 Planner->>Planner: 解析意图，生成步骤计划 Planner->>FSM: 初始化状态 → Idle loop ReAct 循环（每一步） FSM->>Thought: 状态 → Reasoning Thought->>Thought: 基于上下文推理当前步骤 Thought->>FSM: 返回选定的工具与参数 FSM->>ToolExec: 状态 → Acting ToolExec->>ToolExec: 执行工具调用 ToolExec->>Validator: 返回执行结果 Validator->>Validator: 校验结果是否满足预期 Validator->>FSM: 校验通过 → Reasoning / 校验失败 → Retry FSM->>Thought: 状态回转 → Reasoning（下一步） end FSM->>FSM: 所有步骤完成 → Completed FSM->>User: 汇总所有中间结果，返回最终答案这张图的核心信息是：整个推理链不是一次性生成的，而是由状态机驱动，在 Reasoning、Acting、Validating 三个状态之间循环切换。每一步的推理结果和工具输出都记录到上下文中，供下一步推理参考。如果校验失败，状态机不会继续推进，而是回退到 Retry 状态重新执行当前步骤。
这种设计的关键优势在于确定性：给定相同的初始状态和步骤计划，推理链的执行路径是可预测的。这和递归式的"自由发挥"推理完全不同——后者看起来灵活，但在生产环境中几乎不可调试。
三、Rust 实战：用有限状态机构建 ReAct 推理引擎
下面用一个可运行的 Rust 实现来展示 ReAct 推理引擎的核心结构。代码重点不是模型调用细节，而是状态机管理和推理步骤的编排逻辑。
3.1 状态定义与转移规则
首先定义状态机的所有状态和转移规则：
use std::collections::HashMap; /// Agent 推理链的状态枚举 /// 每个状态对应 ReAct 循环中的一个阶段 #[derive(Debug, Clone, PartialEq)] enum AgentState { /// 初始状态，等待规划器生成步骤计划 Idle, /// 推理阶段：分析当前步骤，决定调用哪个工具 Reasoning, /// 行动阶段：执行工具调用 Acting, /// 校验阶段：检查工具返回结果是否符合预期 Validating, /// 重试阶段：当前步骤校验失败，重新执行 Retry, /// 所有步骤完成，汇总结果 Completed, /// 推理链超出最大步数限制，强制终止 Halted, } /// 一次推理步骤的记录 /// 包含推理过程、工具调用和观察结果 #[derive(Debug, Clone)] struct StepRecord { /// 推理模块的思考过程文本 thought: String, /// 选定的工具名称 tool_name: String, /// 工具调用参数 tool_args: HashMap<String, String>, /// 工具执行后的返回结果 observation: String, /// 该步骤是否通过校验 validated: bool, } /// ReAct 推理引擎的主体结构 struct ReActEngine { /// 当前状态 state: AgentState, /// 已完成的步骤记录，用于上下文参考 history: Vec<StepRecord>, /// 规划器生成的步骤计划（步骤索引列表） plan: Vec<usize>, /// 当前正在执行的步骤索引 current_step: usize, /// 最大允许步数，防止推理链无限增长 max_steps: usize, /// 当前步骤的重试计数 retry_count: usize, /// 单个步骤的最大重试次数 max_retries: usize, }3.2 状态转移与 ReAct 循环核心
状态转移是引擎的灵魂。每个状态只能转移到合法的下一个状态，不合法的转移会被拒绝：
impl ReActEngine { fn new(max_steps: usize, max_retries: usize) -> Self { Self { state: AgentState::Idle, history: Vec::new(), plan: Vec::new(), current_step: 0, max_steps, retry_count: 0, max_retries, } } /// 状态转移方法：只在合法路径上允许转移 /// 返回 true 表示转移成功，false 表示非法转移被拒绝 fn transition(&mut self, next: AgentState) -> bool { let valid = match (&self.state, &next) { // Idle → Reasoning：规划完成后开始第一步推理 (AgentState::Idle, AgentState::Reasoning) => true, // Reasoning → Acting：推理完成，开始执行工具 (AgentState::Reasoning, AgentState::Acting) => true, // Acting → Validating：工具执行完毕，校验结果 (AgentState::Acting, AgentState::Validating) => true, // Validating → Reasoning：校验通过，进入下一步推理 (AgentState::Validating, AgentState::Reasoning) => true, // Validating → Retry：校验失败，重试当前步骤 (AgentState::Validating, AgentState::Retry) => true, // Retry → Acting：重试次数未超限，重新执行 (AgentState::Retry, AgentState::Acting) => true, // Retry → Halted：重试次数超限，强制终止 (AgentState::Retry, AgentState::Halted) => true, // Reasoning → Completed：所有步骤执行完毕 (AgentState::Reasoning, AgentState::Completed) => true, // 任何状态 → Halted：步数超限时的安全出口 (_, AgentState::Halted) => true, // 其他路径一律拒绝 _ => false, }; if valid { self.state = next; } valid } /// 构建推理上下文：把历史步骤压缩成文本 /// 防止上下文过长导致模型输入溢出 fn build_context(&self, max_chars: usize) -> String { let mut ctx = String::new(); for record in &self.history { // 每条记录只保留关键信息，截断过长的观察结果 let obs_truncated = if record.observation.len() > 200 { // 截断观察结果，保留前 200 字符 + 省略标记 format!("{}...(truncated)", &record.observation[..200]) } else { record.observation.clone() }; ctx.push_str(&format!( "Step {}: Thought={}, Tool={}, Obs={}\n", self.history.iter().position(|r| r == record).unwrap_or(0), record.thought, record.tool_name, obs_truncated, )); } // 如果上下文总长度超限，只保留最近几步 if ctx.len() > max_chars { let keep_lines = ctx.lines().rev().take(3).collect::<Vec<_>>(); keep_lines.into_iter().rev().join("\n") } else { ctx } } /// ReAct 循环的主运行方法 /// 模拟推理 → 行动 → 校验的完整循环 fn run(&mut self, initial_plan: Vec<usize>) -> Result<String, String> { self.plan = initial_plan; self.transition(AgentState::Reasoning)?; while self.state != AgentState::Completed && self.state != AgentState::Halted { // 安全检查：步数超限时强制终止，防止成本失控 if self.history.len() >= self.max_steps { self.transition(AgentState::Halted); return Err(format!( "推理链超出最大步数限制（{}步），强制终止", self.max_steps )); } match self.state { AgentState::Reasoning => { // 推理阶段：基于上下文决定下一步工具调用 let ctx = self.build_context(1000); let thought = self.reason_about_next_step(&ctx); let (tool, args) = self.select_tool_for_step(self.current_step); self.transition(AgentState::Acting); // 行动阶段：执行工具调用 let observation = self.execute_tool(&tool, &args); let validated = self.validate_observation(&observation); let record = StepRecord { thought, tool_name: tool, tool_args: args, observation, validated, }; self.history.push(record); // 校验阶段：根据结果决定下一步状态 if validated { self.retry_count = 0; self.current_step += 1; if self.current_step >= self.plan.len() { self.transition(AgentState::Completed); } else { self.transition(AgentState::Reasoning); } } else { self.retry_count += 1; if self.retry_count > self.max_retries { self.transition(AgentState::Halted); return Err(format!( "步骤 {} 校验失败，重试 {} 次后仍不通过", self.current_step, self.max_retries )); } self.transition(AgentState::Retry); // Retry 状态会回退到 Acting 重新执行 self.transition(AgentState::Acting); } } _ => unreachable!("状态机不应停留在非推理状态等待"), } } // 汇总所有步骤结果 let summary = self.history .iter() .map(|r| format!("{}: {}", r.tool_name, r.observation)) .join("\n"); Ok(summary) } }3.3 工具注册与类型安全的调用接口
工具不能随便调用，每个工具必须有明确的输入输出定义，Agent 只能从注册表中选取：
/// 工具定义：名称、参数规格和执行函数签名 struct ToolDef { name: String, /// 参数名称与类型描述，用于推理阶段的参数生成校验 param_schema: HashMap<String, String>, /// 工具的简要描述，供推理模块匹配步骤与工具 description: String, } /// 工具注册表：所有可用工具的统一管理入口 struct ToolRegistry { tools: HashMap<String, ToolDef>, } impl ToolRegistry { fn new() -> Self { Self { tools: HashMap::new() } } /// 注册工具：名称和参数规格必须完整 fn register(&mut self, tool: ToolDef) { self.tools.insert(tool.name.clone(), tool); } /// 查询工具：Agent 推理时只能从注册表选取，不能自行发明工具 fn lookup(&self, name: &str) -> Option<&ToolDef> { self.tools.get(name) } /// 校验参数：确保传入参数符合工具定义的规格 /// 防止推理模块生成不合法的参数导致工具调用失败 fn validate_args(&self, name: &str, args: &HashMap<String, String>) -> bool { match self.tools.get(name) { Some(tool) => { // 检查必选参数是否都提供了 tool.param_schema.keys().all(|key| args.contains_key(key)) } None => false, } } }这段代码的核心设计意图是：Agent 的推理模块只负责决定"调用哪个工具、传什么参数"，但工具本身的合法性由注册表和参数校验把关。推理模块不能绕过注册表直接构造调用——这是防止 Agent 越权执行的关键约束。
3.4 组装一个完整的推理流程
把上面的模块组装起来，一个完整的 ReAct 推理流程如下：
fn main() { // 初始化工具注册表 let mut registry = ToolRegistry::new(); registry.register(ToolDef { name: "find_log_files".into(), param_schema: HashMap::from([ ("directory".into(), "string".into()), ("pattern".into(), "string".into()), ]), description: "在指定目录中查找匹配模式的日志文件".into(), }); registry.register(ToolDef { name: "classify_errors".into(), param_schema: HashMap::from([ ("file_path".into(), "string".into()), ]), description: "读取日志文件并按错误类型分类".into(), }); registry.register(ToolDef { name: "send_slack".into(), param_schema: HashMap::from([ ("channel".into(), "string".into()), ("message".into(), "string".into()), ]), description: "发送消息到 Slack 频道".into(), }); // 初始化引擎：最大 10 步，每步最多重试 3 次 let mut engine = ReActEngine::new(10, 3); // 规划步骤序列：3 个步骤对应 3 个工具 let plan = vec![0, 1, 2]; match engine.run(plan) { Ok(summary) => println!("推理完成，最终汇总：\n{}", summary), Err(reason) => println!("推理终止：{}", reason), } }这段代码看起来简单，但它展示的是 ReAct 模式的关键约束：步骤计划在执行前就确定，工具只能从注册表选取，每一步都要通过校验才能继续。这三个约束共同构成了推理链的可控性基础。
四、推理链的边界：步数上限、幻觉累积与成本红线
ReAct 模式让多步推理变得可控，但可控不代表没有代价。实际使用中需要关注三个边界问题：
4.1 推理链长度与上下文窗口的矛盾
每一步 ReAct 循环都会往历史记录中追加一条 Thought-Action-Observation 三元组。如果推理链有 8 个步骤，上下文中至少要保留 8 条完整记录供后续推理参考。但大模型的上下文窗口是有限的——即使 128K token 的窗口，在 8 步推理后也可能被中间结果占满。
解决方案不是简单地增大窗口，而是分层压缩上下文：已完成的步骤只保留摘要，当前步骤保留完整记录。上面的build_context方法已经实现了截断机制，但更成熟的做法是让模型自己对历史步骤做一次摘要，把 8 条完整记录压缩成 1 条结构化摘要再传入下一步。
4.2 幻觉累积：小偏差滚雪球
ReAct 的每一步推理都依赖前一步的观察结果。如果第三步的工具返回了略有偏差的数据（比如日志文件少读了一行），第四步基于这个不完整数据做出的推理就已经偏离了正确路径。到第八步时，偏差可能已经滚成雪球，最终答案和用户预期完全不同。
校验机制（Validating 状态）是减缓幻觉累积的第一道防线，但它不是万能的。更务实的策略是：在关键步骤设置锚点校验——不是每一步都校验，而是在推理链的 1/3 和 2/3 位置做两次完整的中间结果审查。这比逐步校验成本低，但比无校验安全得多。
4.3 成本控制：每次推理都是一笔账
ReAct 模式中每一步都需要调用模型做推理，8 步推理意味着 8 次 API 调用。如果每次调用的平均 token 消耗是 2000（含上下文），8 步就是 16000 token。加上工具调用的延迟，一条推理链的总耗时可能达到 30-60 秒。
max_steps和max_retries两个参数就是成本红线。生产环境中建议max_steps不超过 12，max_retries不超过 3。超过这些阈值时，引擎强制进入 Halted 状态，宁可返回部分结果也不要无限制地消耗资源。
一个值得尝试的优化方向是并行步骤识别：规划器在生成步骤计划时，如果发现某些步骤之间没有数据依赖（比如"查找文件 A"和"查找文件 B"可以同时进行），就把它们标记为可并行执行。这需要规划器具备依赖分析能力，实现复杂度会上升，但能显著减少推理链的总耗时。
五、总结
多步推理是 AI Agent 从"玩具"走向"工具"的关键能力缺口。一条看似简单的用户指令，背后可能需要 5-10 个工具调用步骤依次执行，每一步的输出都是下一步的输入。没有显式的步骤规划和状态管理，Agent 在多步推理中必然迷失。
ReAct 模式的核心贡献是把推理和行动分离，用 Thought-Action-Observation 三元组结构化每一步的决策过程。用有限状态机管理这个循环，推理链的执行路径就变得可预测、可调试、可回溯——这是生产环境的基本要求。
Rust 实现中的三个关键约束值得记住：步骤计划前置确定、工具只能从注册表选取、校验不通过不推进。这三个约束不是限制 Agent 的灵活性，而是确保灵活性不变成失控性。
最后，三个边界问题需要持续关注：上下文窗口与推理链长度的矛盾要用分层压缩解决，幻觉累积要用锚点校验减缓，成本失控要用硬性阈值截断。ReAct 不是银弹，但它是目前把多步推理从混乱拉向有序的最务实方案。
