考察点
这道题出自拼多多大模型岗一面，考的是对推理模型与 Agent 体系关系的理解深度。三个子问题有陷阱：第二问「上下文窗口不够是不是主因」就是个坑，顺着答是就掉进去了。面试官想看你是否理解 FC 能力是训出来的不是开关打开的，以及 interleaved thinking（思考与调用交替）这个新范式的真实收益与代价。追问常往推理模型接入 Agent 的工程注意点走。
参考答案
早期不支持的主因：训练，不是窗口
先把第二问的坑拆了：上下文窗口不是主因。推理模型的思考链确实长，加上工具结果会挤占窗口，但 o 系列和 R1 的上下文窗口并不小，装下多轮工具调用绰绰有余。窗口是个工程约束，不是能力缺失的根因。
真正的根因在训练管线。推理模型的核心竞争力——长链条思考——是靠大规模 RL 在「单轮、封闭、可验证」的题目上训出来的：一道数学题，模型想几千 token，给出答案，判对错，更新策略。整个训练分布里没有工具调用轨迹：模型从没学过「想到一半可以停下来、发起一次结构化调用、等外部结果回来再接着想」。Function Calling 不是 API 加个参数就有的能力，它是 SFT 和 RL 阶段用工具轨迹数据喂出来的行为模式。直接把推理模型接上 tools 参数会怎样？三种典型翻车：思考链里把调用意图写成自然语言而不是合法 tool_calls；幻觉出不存在的工具；或者干脆无视工具，自己在脑子里把需要实时数据的问题「想」出一个答案。所以要补 FC，得专门构造推理-调用交替的训练数据再走一轮训练，这是早期版本没做的事，后来各家补上训练后陆续开放，就是这个原因。
interleaved thinking 解决了什么
interleaved thinking 指思考与工具调用交替进行：想一段、调一次工具、看结果、基于结果再想下一段、再调下一步，推理链贯穿整个多轮调用过程，而不是「先一口气想完，再一次性把调用发出去」。
它解决的核心问题是推理与工具的割裂。传统模式下模型在第一次响应里就要决定全部调用计划，后续拿到结果只是做个总结；多步任务里第二步怎么调往往依赖第一步的结果，没有中间推理，计划就是拍脑袋。交替模式下，每一步调用都被当下的推理指导，调用参数可以根据上一步结果精修，发现结果异常还能换策略——这是 Agent 任务成功率上的实质提升，尤其在深度检索、多跳问答这类场景。
没解决什么
也要说清它的代价，面试官爱听这个：
- token 成本成倍放大。每一轮调用后都重新进入思考，思考 token 按轮次累乘，一个五步任务的推理开销可能是单轮的十几倍，延迟同样恶化。
- 上下文膨胀。思考链、调用、结果全部累积进窗口，长任务照样可能顶到上限，只是比「能力缺失」好解——可以压缩、摘要，但是真实的工程负担。
- 错误传播。早期某步调错或想偏，错误结论进入后续推理的上下文，后面步步错。交替思考放大了单步质量的重要性，对模型的自我纠错能力要求更高。
- 训练数据仍然难造。高质量的「想-调-看-再想」轨迹比单轮推理数据贵得多，这仍是各家模型能力差距的来源。
实践上的建议：推理模型进 Agent 体系时，用 reasoning effort 之类的档位控制思考预算，简单任务别上满配推理；工具结果回填前做截断；对多步任务设置最大轮次和 token 预算熔断。
可能的追问
- 推理模型接入 Agent 体系，哪一环最容易出问题？ 答：工具结果回填后的续接推理——模型可能无视结果继续按原思路走，或对异常结果过度脑补；要在 prompt 里明确要求「先评估结果再决策」，并对结果做结构化包装。
- 怎么控制推理模型的 token 成本？ 答：任务分级，简单任务用低推理档或普通模型；设思考 token 上限；把确定性强的步骤从模型推理里剥离成代码逻辑。
- 推理模型还需要 Workflow 吗？ 答：更需要。推理能力强不代表该让它自由发挥，主干流程用 Workflow 固定，推理模型只在真正需要多步判断的节点上场，成本和可控性都更好。