CoT 无效？ReAct 失灵？你可能用错了模型

在构建智能体（Agent）和对话系统的过程中，我们常常听到这样的困惑：

“为什么我的 7B 小模型连‘组织一场生日派对’都规划不好？”
“我加了 ReAct 提示词，但模型还是瞎编答案。”
“Chain-of-Thought 到底是模型能力，还是提示词技巧？”

这些问题背后，藏着一个更本质的命题：大模型的推理能力从何而来？它能否被小模型复制？

今天，我们来系统拆解 CoT（思维链）、Planning（规划）、ReAct（推理+行动）与 ChatFlow（对话流） 四者的定位、边界与适用场景，并解释——为什么“推理”是大模型的专属能力，而非简单的 prompt 工程。

---

一、CoT：不是技巧，而是涌现能力

很多人以为 Chain-of-Thought（CoT）就是加一句 “Let’s think step by step” —— 这是一种误解。

CoT 本质上是一种多步符号推理能力，它要求模型：

• 理解问题结构
• 分解子问题
• 保存中间状态
• 逐步推导结论

但关键在于：这种能力在小模型中几乎不存在。

Google 2022 年的原始 CoT 论文早已指出：只有当模型参数量超过 10B 时，Zero-shot CoT 才开始显著有效。7B 模型即使看到 “Let’s think step by step”，也只会机械复读，无法真正“思考”。

为什么？

1. 容量瓶颈：小模型的隐藏状态维度低，无法在长序列中稳定维持多个中间变量（如 5 - 2 = 3）。
2. 数据缺失：公开预训练数据中，高质量分步推理样本极少。
3. 非涌现性：CoT 是一种临界规模后的涌现能力，不是线性增长的技能。

✅ 工程启示：
如果你依赖 CoT 提升准确性（如数学、逻辑题），请务必使用 13B+ 且经过 CoT 微调的模型（如 Qwen-Max、GPT-4o）。对小模型强行加 CoT prompt，往往适得其反。

---

二、Planning：CoT 的高阶形态，小模型的“禁区”

如果说 CoT 是“解一道题”，那么 Planning 就是“设计一套解决方案”。

规划任务要求模型：

• 分解复杂目标为有序子步骤
• 理解步骤间的依赖与约束
• 预判失败路径并提供备选方案
• 保持长期目标一致性

这比 CoT 更难。例如，“组织生日派对”涉及时间、预算、人员、场地、应急预案等多维约束。小模型在此类任务中常出现：

• 步骤倒置（“先吃蛋糕，再买蛋糕”）
• 遗漏关键环节（忘了邀请客人）
• 无异常处理（不考虑“下雨怎么办”）

根本原因在于：

• 工作记忆不足：无法同时跟踪目标、状态、约束
• 缺乏结构化常识：知识是统计碎片，非因果图谱
• 无前瞻性模拟：不能进行反事实推理（“如果…就…”）

✅ 工程启示：
复杂规划必须依赖大模型。若资源受限，可采用“人工模板 + 小模型填空”或“小模型草案 + 人工审核”策略，但不要幻想 7B 模型能自主规划科研路线或创业计划。

---

三、ReAct：为“工具调用”而生，非万能框架

ReAct（Reason + Act）是当前 Agent 架构的主流范式，但它有明确的适用边界：

ReAct 的价值 = 外部工具 × 模型推理能力

• 当你有可靠工具（如天气 API、数据库、代码解释器）时，ReAct 能让大模型精准调用，实现“感知-决策-行动”闭环。
• 但若无工具，ReAct 反而有害：模型被迫虚构 Action，导致输出呆板、幻觉加剧。

更关键的是：ReAct 依赖模型能正确解析工具返回的 Observation。小模型常因理解偏差，将错误结果当作事实，直接输出错误 Final Answer。

✅ 工程启示：

• 有工具 → 用 ReAct + 大模型（如 GPT-4o、Claude 3.5）
• 无工具 → 不要用 ReAct！改用纯对话流（ChatFlow）或 CoT 引导

---

四、ChatFlow：对话场景的正确打开方式

在无工具的纯对话场景（如心理咨询、职业建议、闲聊），ReAct 是错误的抽象。

用户要的是自然、共情、连贯的回应，而非机械的 “Thought → Action → Observation”。

此时，正确的做法是：

• 使用 结构化提示词引导多步反思（如“1. 理解问题 2. 分析角度 3. 权衡利弊 4. 给出建议”）
• 通过 Runnable 链式编排 实现“生成 → 批评 → 重写”的自我优化
• 结合 Memory 模块 维护上下文，而非强行套用 Agent 框架

✅ 工程启示：
对话 ≠ Agent。用 ChatFlow + CoT prompt + Memory，比强行上 ReAct 更高效、更自然。

---

五、总结：能力分层与技术选型

能力层级	小模型（≤7B）	中模型（13–30B）	大模型（≥60B / API 闭源）
基础对话	✅ 优秀	✅ 优秀	✅ 优秀
简单 CoT	❌ 无效	⚠️ 有限（需微调）	✅ 强大
复杂规划	❌ 不可行	⚠️ 局部可用	✅ 可靠
ReAct 工具调用	❌ 易出错	⚠️ 需强约束	✅ 稳定
多步反思对话	⚠️ 需强 prompt	✅ 可行	✅ 优秀

核心结论：

1. 推理能力是规模的函数，不是 prompt 的魔法。
2. 不要用 ReAct 解决无工具问题——那是架构误用。
3. 小模型的价值在于成本与速度，而非复杂推理。
4. 真正的智能体 = 大模型（推理） + 工具（行动） + 流程（编排）

---

最后：务实的技术观

“不要试图让小模型做它做不到的事。
也不要高估 prompt 的力量——它只是放大器，不是创造者。”

在资源允许时，优先选择具备内生推理能力的大模型；在资源受限时，通过任务分解、人工模板、人机协同来规避模型短板。

技术选型的本质，是在能力边界内做最优解，而非盲目追求“全自动”。

—— 愿我们都能构建出既聪明，又可靠的 AI 系统。

---

延伸阅读：

• Google CoT Paper (2022)
• ReAct: Synergizing Reasoning and Acting (2022)
• ALFWorld: 基于家庭任务的规划基准