推理模型与 Agent 大脑：agentic 推理的工程化（10 题）

题目结构说明：每题四部分。考点定位讲面试官在考察什么；深拆是机制加数字加失败模式，数字是可信度的来源；工程方案给 Python 风格伪代码，逐行中文注释，注释就是面试时口述的话术，个别题换成可复制提示词模板；追问链是答完后大概率跟上的问题，附答法。标记：⭐ 高频（出现率过半）、🔥 近两年新增。

Q1 推理模型 vs chat 模型做大脑：能力差异从哪来 ⭐🔥

考点定位：验的是对「推理模型为什么强」的理解深度。答「参数更大」的没入门，答「RL 后训练换了目标」但说不出 Agent 场景的收益和代价各是什么的，没落地过。

深拆：同代产品底座都是 Transformer 解码器，能力差异主要来自后训练目标：chat 模型的 RLHF 以人类偏好对齐单轮回复，推理模型用可验证奖励的 RL（数学答案比对、代码测试通过）训练整条推理链，学会长思考、自我检查、走错回头。这就是 test-time compute scaling 的来源：答案质量随思考 token 数近似平滑上升，把算力从预训练挪到解码阶段。Agent 场景的收益集中在三处：多步规划更稳、工具调用出错后能自我修正、长链路里目标不容易漂移。代价同样硬：思考 token 按输出价计费，延迟从秒级涨到十几秒甚至分钟级；简单任务上过度思考，分类抽取这类一步任务多花十倍 token 换不来一个点的提升。失败模式两种：把推理模型当万能大脑全量路由，成本账爆炸；反过来在排错类任务上省着用 chat 模型，失败重试烧掉的 token 比一次思考还多。

工程方案：

def pick_brain(task):
   # 复杂度信号：预估步骤数、是否要排错、是否多工具组合
   c = estimate_complexity(task)      # 0-1，规则或小分类器给出
   if c < 0.3:
       return \”chat\”                  # 单步任务：分类、抽取、格式改写
   if c < 0.7 and task.need_tools:
       return \”chat_with_cot\”         # 中等：chat 模型加显式推理提示
   return \”reasoning\”                 # 规划、排错、多约束权衡才上推理模型
​
# 路由器每月复盘一次：看各档位的正确率和成本分布，档位边界要跟着调

追问链：

• 「能力差异的根源为什么是后训练不是架构？」-> 底座同构，推理模型与同代 chat 模型规模未公开，行业普遍按同一量级估算；差异来自 RL 让模型把算力花在解码阶段的思考 token 上，同一架构换了训练目标。

• 「推理模型调工具会更准吗？」-> 工具选择和参数填写这类格式化任务未必强，个别实现里格式遵循反而变差；优势在「调不调、调完之后怎么办」的策略层。

• 「什么时候坚决不用推理模型？」-> 高 QPS 的简单任务、延迟敏感的交互场景、按单条消息计成本的批量流水线，这三类上了就是白花钱。

Q2 思考预算：think budget 怎么定 ⭐🔥

考点定位：考工程化程度。用上推理模型的团队必然碰到预算旋钮，能不能按任务分级、能不能动态调、耗尽后系统什么行为，决定成本和质量能不能同时保住。

深拆：思考预算是显式参数：GPT-5 起统一为单一模型加自适应推理投入（effort 由低到高可调、由模型自适应决定想多深），o 系列的独立命名已成历史（截至 2026-08）；Claude 4.5 系起改为 effort 低/中/高参数档，早期按 token 下限控制的写法已成历史。定预算先按任务分级：一步能答的（分类、抽取）给零档或直接走 chat 模型；中等任务（单工具调用、短规划）给数千 token；深度任务（排错、多约束权衡、deep research）给数万 token。动态调整有两个方向：根据首轮思考的自检结果追加一轮；根据同类任务的历史消耗分布做预测修正。预算耗尽的行为要心里有数：主流实现会强制收束，基于已有思考给出当前最佳答案，质量掉一截但任务不空手，所以预算别贴着下限定。失败模式：全站一个默认档，简单任务烧钱、难任务思考被截在关键处；设了预算但不监控实际消耗分布，P95 早超了预算几个月没人发现。

工程方案：

def decide_budget(task, history):
   # 一级：按任务类型给基线档位
   base = {
       \”classify\”:  0,        # 走非推理路径，不花思考的钱
       \”tool_call\”: 2000,     # 单步工具调用：短思考确认参数够用
       \”plan\”:      8000,     # 多步规划：拆解加排序
       \”debug\”:     24000,    # 排错：假设生成与逐一验证
  }[task.type]
   # 二级：用同类任务历史 P70 消耗修正，贴分布而不是拍脑袋
   past = history.p70(task.type)
   budget = max(base, past) if past else base
   # 三级：自检不过允许追加一轮，只批一次，防无限续思考
   return budget, allow_ext=(task.type in (\”plan\”, \”debug\”))
​
def run_with_budget(task):
   budget, allow_ext = decide_budget(task, history)
   ans = reasoning_llm(task, max_think=budget)
   if ans.self_check_failed and allow_ext:
       # 追加一次预算重跑；二次失败也强制收束，不再续
       ans = reasoning_llm(task, max_think=budget * 2)
   return ans.final   # 预算耗尽时模型给当前最佳答案，不会空转

追问链：

• 「预算耗尽那一刻模型在干什么？」-> 停止继续思考，基于已有推理收束输出；所以预算是软截断，表现为质量降级而不是任务失败。

• 「预算和延迟什么关系？」-> 思考 token 串行解码，预算近似等于延迟上限；交互场景按可容忍延迟反推预算，比按质量定更实际。

• 「档位定得对不对怎么验证？」-> 分桶看消耗分布和正确率的关系，正确率