让 Agent 先想清楚，再动手。

1. 为什么需要推理技术

简单问题，模型可以直接回答。复杂问题，不能。

复杂任务通常有依赖、有分支、有不确定性。只靠一次生成，模型容易漏步骤、跳结论、编理由。

推理技术解决的不是“让模型说更多废话”，而是让 Agent 有一套可执行的问题解决流程。

• 先拆解：把大问题拆成小步骤。

• 再探索：不要只相信第一条路径。

• 再验证：能用工具确认的，就不要靠猜。

• 最后收敛：输出结论、证据和风险。

2. 它到底是什么

推理技术，是给 Agent 配一套“思考框架”。

它不等于把“请一步步思考”塞进提示词。真正工程化的推理，需要策略选择、工具反馈、结果验证和成本控制。

常见方法包括 CoT、Self-Consistency、Step-back、Tree of Thoughts、ReAct、代码执行和推理预算控制。

3. 核心流程

推理链路可以很复杂，但核心动作并不复杂。

先判断任务复杂度。简单问题直接回答。复杂问题进入推理链。

推理链会选择合适策略：拆步骤、走多路径、调用工具、校验结果。最后输出可读结论，而不是把内部过程原样扔给用户。

4. 5 种常用推理方式

4.1 CoT：把问题拆成步骤

CoT 的核心是分步。适合多步逻辑、规则判断、数学推导、排障分析。

但生产环境不建议把完整内部推理直接展示给用户。更好的做法是：内部保留步骤摘要，外部输出结论、依据和关键判断。

4.2 Self-Consistency：多想几遍再选

一次推理可能走偏。Self-Consistency 会生成多条推理路径，再用投票、评分器或规则校验选择更稳定的答案。

它适合高价值问题，但成本更高，不能滥用。

4.3 Step-back：先抽象，再落地

遇到复杂问题，先问一个更高层的问题。

比如不是直接问“这个接口为什么慢”，而是先抽象为“接口变慢通常有哪些原因”，再回到具体日志和指标。

4.4 ToT：同时探索多条路径

ToT 像树搜索。先展开多个可能方向，再评分、裁剪、回溯。

适合规划、排障、方案选择。缺点是成本高、延迟高，需要限制分支数量和最大深度。

4.5 ReAct：边想边做

ReAct 把 Reason 和 Act 合在一起。Agent 不只是想，还会调用工具。

它会不断循环：思考下一步，调用工具，观察结果，再决定下一步。适合需要外部信息的任务。

5. 一个案例：慢 SQL 排查 Agent

场景：订单查询接口突然变慢。

普通模型可能直接猜：“可能是数据库压力大”。这种答案没有价值。

推理型 Agent 会先拆分原因，再用工具逐个验证。

• 先确认问题范围：是全量变慢，还是某个租户、某个时间段变慢。

• 再看证据：慢日志、EXPLAIN、索引、锁等待、监控指标。

• 再走分支：索引缺失、大表扫描、锁等待、缓存失效。

• 最后输出：最可能原因、证据、修复动作、风险提示。

6. 工程落地

6.1 不要所有问题都开重推理

推理不是免费的。它会增加 token、延迟和工具调用次数。

简单 FAQ、固定查询、格式转换，直接走普通链路即可。复杂决策、排障、代码修复、数据分析，再进入推理链。

6.2 推理必须绑定验证

推理如果不能验证，就容易变成“更有条理的胡说”。

能查数据库就查数据库。能跑测试就跑测试。能看日志就看日志。能用规则校验就校验。

6.3 控制推理预算

推理链必须有上限。

• 最大推理步数。

• 最大工具调用次数。

• 最大 token 成本。

• 最大执行时间。

• 失败后的降级策略。

6.4 记录推理轨迹

不要只记录最终答案。要记录任务复杂度、策略选择、工具调用、验证结果、失败原因。

这不是为了展示给用户看，而是为了排查、评估和持续优化。

7. 上线检查清单

8. 总结

推理技术的核心，不是让模型话更多，而是让 Agent 做事更稳。

CoT 负责拆步骤。Self-Consistency 负责稳定性。Step-back 负责抽象。ToT 负责多路径探索。ReAct 负责工具反馈。

真正可上线的推理型 Agent，一定不是单独靠提示词完成。它必须和工具、状态、验证、监控、成本控制一起设计。

一句话：复杂任务先想清楚，关键结论必须验证。