一、推理技术不是让 AI 想更久，而是让它想得更对

推理技术的核心，不是一句「请一步一步思考」，也不是把输出长度调大。

它真正解决的问题是：面对不同类型的任务，Agent 应该用什么方式思考，思考到什么程度，什么时候该查资料，什么时候该停下来。

简单翻译，不需要复杂推理。数学、代码、规划任务，需要更清晰的步骤。事实查询、政策解释、实时信息，不能靠「想」，必须查。复杂决策和争议判断，可能需要多条路线对比，甚至让不同观点互相反驳。

所以这一章讲的不是「让模型多想」，而是：让 Agent 学会选择合适的思考方式。

二、为什么需要推理技术：会回答，不等于会推理

我们先用一个生活场景理解。

假设你去医院看病，医生面对不同问题，不会都用同一种方式处理：

• 量体温、开常规感冒药，不需要大会诊；
• 判断疑难杂症，需要检查报告、排除可能性；
• 做重大手术方案，需要多名医生讨论；
• 如果缺少关键检查结果，再聪明的医生也不能靠猜。

Agent 也是一样。

如果用户问：

把这句话翻译成英文：我今天很忙。

直接回答就好。

但如果用户问：

我们公司要不要进入一个新市场？请结合用户需求、竞品情况、成本、风险和落地路径给出建议。

这就不能只靠一句回答。Agent 至少要拆问题、查资料、对比方案、分析风险、说明不确定性，最后再给结论。

推理技术的价值就在这里：它让 Agent 从「凭直觉回答」，变成「按任务结构思考」。

三、推理技术到底在做什么

推理技术可以先拆成四个动作。

第一，把复杂问题拆成步骤。比如「原价 200 元，先打 8 折，再使用 30 元优惠券」，就应该先算 200 × 0.8 = 160，再算 160 - 30 = 130。它不是更啰嗦，而是把容易出错的过程拆开。

第二，对多个思路进行比较。比如「新产品先做低价版，还是高端版」，Agent 不能只押一个答案。低价版容易获客但利润低，高端版利润高但验证慢，中间方案可能更稳。这里需要展开候选路径，再评估取舍。

第三，需要事实时去外部世界查证。政策变化、行业数据、公司新闻、版本更新，不是靠模型记忆硬想出来的。Agent 应该检索资料、调用工具、读取数据库，再基于资料回答。

第四，对重要结论做验证。Agent 可能算错、查错、理解错，也可能写出看起来合理但实际不可靠的解释。复杂任务里要加入工具校验、多次采样、规则检查、另一个模型审查，或者人工确认。

四、常见推理方式：链、树、图、行动和投票

推理技术看起来很多，但可以先用一张表把它们放回任务里。

1. 链式思考：适合有明确步骤的问题

链式思考，也就是 CoT，可以理解成「把解题过程拆出来」。

请按步骤解决下面的问题。
 
要求：
1. 先列出已知信息；
2. 再逐步推导；
3. 每一步只做一个判断或计算；
4. 最后用一句话给出答案；
5. 如果信息不足，请明确说明缺少什么。
 
问题：
{{用户问题}}

它适合数学题、逻辑题、简单代码分析、多步骤流程判断和规则明确的业务推导。

但它不适合所有场景。如果用户只是问「北京是中国的首都吗」，直接回答即可。强行链式思考反而浪费成本，也可能引入额外错误。

2. 树式思考：适合需要探索多条路线的问题

树式思考，也就是 ToT，不是一条路走到底，而是先展开多个候选方案，再筛选。

比如「我们要提升一个 App 的次日留存率，应该怎么做？」Agent 可以先列出方向：优化新用户引导、增加提醒机制、调整核心功能路径、改进首日激励。然后比较影响、成本、风险和验证速度，选择最值得继续展开的路径。

它适合产品规划、策略分析、复杂方案设计和多路径决策。代价是会展开多个分支，成本比链式思考更高。

3. 图式思考：适合争议性判断和多观点分析

有些问题不是「算出一个答案」，而是需要组织观点、证据和反驳关系。

例如「公司是否应该全面远程办公？」支持观点可能是节省通勤、扩大招聘范围、降低办公成本；反对观点可能是沟通成本变高、团队凝聚力下降、管理难度增加；中间方案可能是关键岗位混合办公。

图式思考不一定真的画图，但 Agent 的内部分析应该像图一样组织：哪些观点支持结论，哪些观点反驳结论，哪些证据更强，哪些地方仍然缺数据。

4. ReAct：适合需要查资料或调用工具的任务

ReAct 的核心是：

Reason：先想下一步该做什么
Act：再调用工具或执行动作
Observe：看工具返回了什么
然后继续推理

例如「帮我总结最近一个季度某类产品的市场变化」，Agent 不应该直接编。它应该检索行业报告和公开资料，提取共同趋势和分歧，再生成结构化总结。

思考：我需要最近一个季度的数据。
行动：检索行业报告和公开资料。
观察：获得多份材料。
思考：提取共同趋势和分歧。
行动：生成结构化总结。

现在很多工具调用 Agent 已经不再显式输出「思考、行动、观察」，而是把工具调用过程隐藏在系统内部。这样更省 token，也更适合工程化，但可解释性会下降。

5. Self-Consistency：适合需要提高稳定性的推理任务

Self-Consistency 可以理解成「多想几遍，再投票」。

同一道数学题，让模型独立解 5 次。如果 4 次都得到 130，1 次得到 140，那么选择 130 往往更稳。

它适合数学推理、逻辑判断、代码分析这类有明确答案的复杂题。它不适合所有任务，因为推理 5 次，成本大约就是 5 倍。只有当答案质量比成本更重要时，才值得用。

五、从训练扩展到推理扩展：AI 工程的一个变化

过去几年，很多 AI 能力提升来自「训练时把模型做得更大」：模型参数更多、训练数据更多，能力就更强。

现在，一个越来越重要的方向是：推理时投入更多计算，让模型在回答前多做几步有效思考。 这叫 Test-Time Compute，也可以理解成「推理时计算」。

过去：模型能力主要由训练阶段决定
现在：模型能力也越来越取决于推理阶段怎么思考

这也带来新的工程问题：不同问题的思考成本差异很大。简单翻译可能只需要很少推理，复杂证明可能需要大量中间步骤，长篇研究可能需要多轮检索、阅读和综合。

所以推理技术必须和资源预算结合起来。不是所有任务都值得「深度思考」，也不是所有任务都应该「直接回答」。

专门推理模型也是这个方向的一部分。它们不是简单靠提示词提醒「认真想」，而是在训练阶段就强化了长推理能力。数学题可以用答案对错做奖励，代码题可以用测试是否通过做奖励，形式逻辑可以用规则验证做奖励。

普通模型加推理提示词，像是提醒它认真想；推理模型更像是它本来就被训练成会认真想。但工程上不要迷信「推理模型一定更好」。它适合难题，简单任务用它就是浪费。

六、完整案例：让 Agent 写一份供应商选型报告

我们用一个业务案例把这些推理技术串起来。

用户提出任务：

请帮我评估 3 家候选供应商，选择最适合我们公司的一家。
需要考虑价格、交付能力、售后服务、技术能力和风险。

这个任务不能直接回答，因为它包含多个候选对象、多个评价维度、外部资料、主观权衡和最终建议。

比较合理的 Agent 流程如下：

第一步，先拆任务。Agent 可以把任务识别成：

{
  "task": "supplier_selection",
  "dimensions": [
    "price",
    "delivery_capacity",
    "after_sales_service",
    "technical_capability",
    "risk"
  ],
  "output": "recommendation_report"
}

第二步，资料不足时要查或追问，而不是编。

思考：我缺少 3 家供应商的价格、交付记录和售后数据。
行动：读取用户上传的供应商资料。
观察：获得报价表、服务协议和历史交付记录。

如果缺少售后响应时效和过往故障率，就要明确说「风险判断只能作为初步判断」。

第三步，多方案比较，而不是直接选一家。

[
  {
    "supplier": "A",
    "strengths": ["价格低", "交付周期短"],
    "weaknesses": ["售后案例少", "技术方案较保守"],
    "risk_level": "medium"
  },
  {
    "supplier": "B",
    "strengths": ["技术能力强", "服务体系成熟"],
    "weaknesses": ["价格较高"],
    "risk_level": "low"
  },
  {
    "supplier": "C",
    "strengths": ["定制能力强"],
    "weaknesses": ["交付周期不稳定", "历史延期较多"],
    "risk_level": "high"
  }
]

第四步，对关键结论做验证。如果最终建议选择 B，Agent 不能只说「B 最好」，还要说明依据、不确定性和待人工确认项。

{
  "recommended_supplier": "B",
  "confidence": "medium_high",
  "reason": [
    "技术能力评分最高",
    "售后体系最成熟",
    "历史交付稳定性较好",
    "虽然价格较高，但综合风险最低"
  ],
  "uncertainties": [
    "仍需确认最终合同中的服务响应条款",
    "建议补充近 6 个月客户满意度数据"
  ],
  "need_human_review": true
}

这个案例里，几种推理技术各自承担了不同角色：链式思考负责拆任务，ReAct 负责查资料，树式思考负责比较方案，图式思考负责组织支持和反对证据，投票或人工复核负责提高关键结论可靠性。

七、工程上必须注意什么

1. 先判断任务类型，再决定推理方式

不要默认所有问题都开启深度推理。可以先做一个轻量分类：

{
  "task_type": "fact_lookup | calculation | planning | writing | decision | other",
  "complexity": "low | medium | high",
  "need_external_info": true,
  "need_human_review": false
}

再路由到不同策略。

type ReasoningRoute = {
  strategy: 'direct' | 'cot' | 'react' | 'tot' | 'graph' | 'vote'
  needExternalInfo: boolean
  needVerification: boolean
}
 
function chooseReasoningRoute(input: {
  taskType: string
  complexity: 'low' | 'medium' | 'high'
  hasFreshFacts: boolean
  isHighRisk: boolean
}): ReasoningRoute {
  if (input.complexity === 'low' && input.hasFreshFacts) {
    return {
      strategy: 'direct',
      needExternalInfo: false,
      needVerification: false
    }
  }
 
  if (!input.hasFreshFacts) {
    return {
      strategy: 'react',
      needExternalInfo: true,
      needVerification: input.isHighRisk
    }
  }
 
  if (input.taskType === 'decision') {
    return {
      strategy: 'tot',
      needExternalInfo: false,
      needVerification: true
    }
  }
 
  return {
    strategy: 'cot',
    needExternalInfo: false,
    needVerification: input.isHighRisk
  }
}

2. 推理必须有预算

推理越深，成本越高。每类任务都应该有预算：

type ReasoningBudget = {
  maxSteps: number
  maxToolCalls: number
  maxCandidates: number
  maxOutputTokens: number
  timeoutMs: number
}
 
const planningBudget: ReasoningBudget = {
  maxSteps: 8,
  maxToolCalls: 5,
  maxCandidates: 3,
  maxOutputTokens: 2000,
  timeoutMs: 60000
}

预算不是为了限制智能，而是为了防止 Agent 陷入无意义循环。

3. 需要事实时，优先查证，不要硬想

数学题可以推，代码可以跑，事实问题必须查。

错误思路：让模型回忆最新政策。
正确思路：检索政策文件，再总结和引用。

推理不能替代信息来源。

4. 关键决策不能只相信推理过程

模型写出来的「推理过程」不一定完全反映它真实的内部判断。有时它可能先得出答案，再编出一个看起来合理的解释。

所以在重要任务中，应该加入事实校验、工具验证、多次采样、人工复核、日志记录和结果回放。

5. 输出要稳定，方便系统继续处理

如果 Agent 的结果要进入业务系统，不能只输出一段长文。应该同时输出结构化字段：

{
  "answer": "",
  "confidence": "low | medium | high",
  "need_external_info": true,
  "need_human_review": false,
  "reasoning_strategy": "direct | cot | react | tot | vote",
  "uncertainties": []
}

这样系统才能继续判断是否要缓存、复核、升级或执行。

八、和上一篇资源感知优化的关系

上一篇讲的是：怎么让 Agent 会算账。

这一篇讲的是：怎么让 Agent 把钱花在值得思考的地方。

两者关系很紧密：

它们合在一起，才是生产级 Agent 的正确姿势：

先判断任务值不值得深度思考
再选择合适推理方式
最后用预算限制成本

推理技术负责提高质量，资源感知优化负责控制代价。没有推理技术，Agent 容易浅尝辄止；没有资源感知，Agent 容易想太多、花太多。

九、和相关 Agent 模式的关系

规划模式解决「先做什么，后做什么」，推理技术解决「每一步怎么想」。规划像项目经理，推理像解决具体问题的专家。

工具使用让 Agent 能查资料、调接口、跑代码；ReAct 把工具使用和推理结合起来，让 Agent 知道什么时候该查、查什么、查完怎么继续。

反思模式让 Agent 检查自己的输出；推理技术让 Agent 在生成答案前更好地组织思路。二者可以结合，但要注意预算，反思太多也会浪费成本。

RAG 提供外部知识，推理技术负责使用这些知识。如果没有推理，Agent 可能只是把资料拼起来；如果没有 RAG，Agent 在事实问题上可能会靠记忆硬猜。

安全护栏负责边界。推理能力越强，Agent 越能完成复杂任务，也越需要输入检查、工具权限控制、输出校验、高风险任务人工确认和操作日志。

能想得深，不代表可以想什么都做。

十、推理技术选型决策树

最后给一个实用决策树。遇到一个任务时，可以按这个顺序判断。

这个决策树的核心是：

• 先判断要不要推理；
• 再判断要不要查资料；
• 再判断是按步骤、按分支，还是按观点网络；
• 最后判断要不要验证和人工复核。

推理技术的本质，不是让 Agent 一直想，而是让它在合适的任务上，用合适的方法，花合适的成本，得到更可靠的答案。