02. 代码还是文字？CodeSteer 与推理模式的动态选择

上一篇讲了 PoT 和 CoC，结论是：把计算外包给解释器，比语言模型自己算更可靠。这个结论没错，但不完整。

有一个问题被跳过了：给定一个任务，语言模型应该生成代码去执行，还是直接用文字推理？ 听起来很简单——复杂计算就用代码，其他就用文字——实际上这个选择比你想象的复杂得多，而且错误的选择会让准确率明显下降。

CodeSteer（ICLR 2025）是第一篇系统研究这个问题的论文，结论让人出乎意料。

反直觉的发现：代码不总是更好

CodeSteer 做了一个大规模实验：把 7 种"推理模式"（纯文字 CoT、PoT、CoC、few-shot 代码等）跨 14 个任务、6 种 LLM 全面测试，看各个组合的准确率。

发现了一个"令人惊讶的逆向缩放规律"：

在小模型（7B、13B）上，生成代码有时比文字推理更差。 原因是小模型的代码生成质量不稳定，生成的代码里有逻辑错误，而这些错误比纯语言推理的错误更难被模型自己发现（代码"跑通了"，但逻辑是错的）。

在大模型上，代码和文字的优劣取决于任务类型：

• 数值计算密集型：代码几乎总是赢
• 纯符号推理（逻辑谜题、因果推断）：文字有时反而更好
• 语义理解任务（NLI、情感）：文字推理更自然，代码反而引入不必要的形式化
• 混合型任务：取决于哪个"瓶颈"更大——计算误差还是语义理解误差

更关键的发现：目前没有任何一种固定的推理模式能在所有任务上都最优。这意味着"一律用代码"或"一律用文字"都是次优策略。

为什么动态选择这么难

从研究的结果看，要做好"选代码还是选文字"的决策，需要同时考虑：

任务类型识别：这个任务是数值密集型、符号推理型还是语义型？分类本身就不容易——很多任务是混合的。

模型能力校准：当前模型在哪类代码上更可靠？不同模型的代码能力结构差异很大。

错误类型权衡：代码推理的典型错误是"逻辑正确但实现错"（变量命名错、边界条件漏），文字推理的典型错误是"计算错或被前文误导"。这两种错误在不同任务上的发生概率不同。

Token 成本：生成代码通常比文字推理消耗更多 token，延迟也更高（需要执行）。在边际收益不大的任务上，代码反而性价比更低。

CodeSteer 的三种引导方法

论文提出了三种让模型做出更好选择的方法：

方法一：Prompted Steering（提示引导）

用 few-shot 示例告诉模型"这类任务用代码，那类任务用文字"：

system_prompt = """你是一个推理助手。根据任务类型选择推理方式：
- 涉及数值计算、统计、序列操作 → 使用 Python 代码
- 涉及逻辑推断、因果分析、文字理解 → 使用文字推理
- 混合任务 → 代码处理计算部分，文字处理语义部分

示例：
任务：计算 3 组数据的方差
选择：代码（数值计算密集）
---
任务：分析以下论点的逻辑漏洞
选择：文字（纯逻辑推断）"""

简单，但泛化性差——新任务类型出现时，few-shot 示例可能覆盖不到。

方法二：Classifier Steering（分类器引导）

训练一个轻量分类器，输入任务描述，输出"code" 或 "text"：

from transformers import pipeline

# 用 CodeSteer 论文的数据集微调的分类器
steering_classifier = pipeline(
    "text-classification",
    model="your-finetuned-steering-model"
)

def choose_reasoning_mode(task: str) -> str:
    result = steering_classifier(task)[0]
    return result["label"]  # "code" or "text"

def solve(task: str):
    mode = choose_reasoning_mode(task)
    if mode == "code":
        return solve_with_code(task)
    else:
        return solve_with_text(task)

比 prompted steering 更系统，但需要有标注数据来训练分类器。

方法三：Self-Steering（模型自选）

让模型在回答前先显式做一步"模式选择"：

[推理模式选择]
任务：计算一组学生成绩的标准差，并判断班级水平
分析：该任务包含数值计算（标准差）和语义判断（水平评估）
选择：混合模式——数值计算用代码，最终判断用文字

[代码部分]
```python
scores = [78, 85, 92, 70, 88, 95, 65, 82]
import statistics
std_dev = statistics.stdev(scores)
mean = statistics.mean(scores)
print(f"均值: {mean:.1f}, 标准差: {std_dev:.1f}")

[文字部分] 执行结果：均值 81.9，标准差 9.9。 标准差约 10，相对于均值约 12%。这说明班级成绩分布较为集中，水平整体偏中等偏上，没有明显的双峰分布...

这种方式最灵活，也最重要——它把"模式选择"变成了推理链的一个显式步骤，可以被检查、被调试、被改进。

### 现实工程里的动态路由

CodeSteer 的研究结论在工程上的映射是：**Agent 的工具调用不应该只有一个"代码执行"工具，而是应该有多个推理工具，加上路由逻辑**。

一个实用的设计：

```python
from enum import Enum

class ReasoningMode(Enum):
    CODE = "code"       # 数值/算法密集
    TEXT = "text"       # 语义/逻辑推理
    HYBRID = "hybrid"   # 混合任务

def classify_task(task: str, model: str = "gpt-4o-mini") -> ReasoningMode:
    """用轻量模型快速分类任务类型（不走昂贵的主模型）"""
    resp = openai.chat.completions.create(
        model=model,
        messages=[{
            "role": "user",
            "content": f"""判断这个任务最适合哪种推理方式，只输出一个词：code/text/hybrid

任务：{task}

判断依据：
- code：需要精确数值计算、排序、统计
- text：纯语言理解、逻辑推断、情感分析
- hybrid：既有计算又有语义判断"""
        }],
        max_tokens=10,
    )
    mode_str = resp.choices[0].message.content.strip().lower()
    return ReasoningMode(mode_str) if mode_str in ("code", "text", "hybrid") else ReasoningMode.HYBRID

async def smart_solve(task: str):
    mode = classify_task(task)

    if mode == ReasoningMode.CODE:
        code = await generate_and_execute_code(task)
        return code.result

    elif mode == ReasoningMode.TEXT:
        return await text_chain_of_thought(task)

    else:  # HYBRID
        # 先代码提取数值结果
        code_result = await generate_and_execute_code(task, extract_only=True)
        # 再用文字推理整合语义
        return await text_reasoning_with_context(task, code_result)

这个设计额外的好处：可以在 trace 里记录每次的模式选择，分析哪类任务路由错了，迭代改进分类逻辑。这直接接入了第 16 篇讲的可观测性体系。

逆向缩放的启示

CodeSteer 发现的"逆向缩放"值得多说一下。通常我们的直觉是：更强的方法 × 更大的模型 = 更好的结果。但 CodeSteer 发现：在小模型上，复杂的推理格式（代码）有时比简单的格式（文字）更差。

这暗示了一个更普遍的原则：推理方法的效果和模型能力之间有交互效应。一种方法对能力强的模型是增强，对能力弱的模型可能是负担。

工程上的含义：

• 在选用推理方法前，先评估你的基础模型在这类任务上的能力
• 用 7B 量化模型跑的 Agent，不要无脑复制大模型上的最佳实践
• 新方法的 benchmark 数字通常在最强模型上测，换小模型时要重新验证

小结

CodeSteer 的核心贡献是把一个被默认为"已解决"的问题重新变成了一个开放问题：给定任务，选代码还是选文字推理？

答案不是"永远选代码"。正确的答案取决于任务类型、模型能力、错误类型偏好、成本约束。这四个因素的组合空间很大，而且它们之间有反直觉的交互。

动态路由是应对这个复杂性的工程答案——但路由本身也需要被设计、被测试、被迭代。把"推理模式的选择"显式化，让它成为可观察的、可调试的系统组件，而不是隐藏在 prompt 里的隐式假设。

下一篇进入代码推理的另一个维度：如果生成的代码本身有错，怎么通过执行反馈让模型自己迭代修正——CodeRL 和 RLTF 的强化学习路线。

相关阅读

• CodeSteer 原始论文 (ICLR 2025) — 代码 vs 文字推理的系统研究
• Scaling LLM Test-Time Compute (Snell et al., 2024) — 推理时计算分配
• Self-Evaluation Guided Beam Search (Xie et al., 2023) — 模型自选策略的相关工作
• Tool-Augmented Language Models (Schick et al., 2023) — 工具选择与推理结合