这周被问最多的问题：推理模型到底什么时候值得上？我的答案——别按「任务类型」算账，按「错一步要赔多少钱」算。信息抽取错了，人扫一眼改掉，成本十几秒；代码生成错一步，整条构建链崩掉，debug 一小时起步。同一个模型调用，在不同错误成本结构里，价值差百倍。别全信跑分，跑分不赔钱。
值不值，别按任务分类，按错误成本分
推理模型贵、慢，换来更低的错误率。问题就变成：错误率降下来，省下的是什么？
做信息抽取——从发票里抽字段填表单——错了的话，抽出来的值不对，人眼一扫能发现，改一下，完事。错误成本低到可以忽略。你用推理模型多花的几秒延迟，比那点错误率更贵。这周 ExtractBench 就是干这个的：schema-guided extraction，要求模型忠实跟随 schema、给证据锚点。你看它的评价维度——value accuracy、record completeness——是「对没对、全没全」，不是「想没想」。这类任务要的是严谨跟随，不是深度推理。普通模型加好的工具调用就够，推理模型在这儿是杀鸡用牛刀，还慢。
反过来看代码、多步计算、复杂规划。DungeonBench 是个好例子——D&D 战斗里的战术推理，几何、时序、资源、规则交互全搅在一起，错一步就是团灭。这种任务的错误成本是灾难性的。你愿意为一个「不错一步」的结果多等十秒。这才是推理模型该上的地方。
中间地带的判断更难，也更值钱
抽取出错成本低，全盘推理成本高，中间的才是日常。代码审查就是这样。从 Code Review 到 Code Critique 那篇说得准：AI 审查工具老爱提风格、最佳实践这类低价值建议，人真正在乎的是正确性、安全、性能。典型的一半值一半浪费——风格问题，普通模型秒回；正确性问题，让推理模型慢慢想。同一个环节拆开，各用各的。
规划用推理模型、执行用普通模型，这个思路方向对。但真正的难点不是「拆」，是「谁来切」。你得给切换定个预算：这个请求逻辑上多深？超时多少毫秒该降级？失败一次重试扣多少预算？这些参数拍下来，比选哪个模型费劲多了。
混用延迟不稳，解法不是不用，是预告加降级
混用这事的反对意见很实在：一条链路里一半推理一半普通，延迟曲线就是锯齿。交互式场景用户等得起吗？
等不起。所以得预告。「正在思考」不是遮羞布，是心理预期管理——让用户知道这不是卡死，是在算。但预告只能缓解体验，真正要解决的是降级路径：推理模型超时，降级给普通模型跑一版，先交付，后修正。可降级这个事不是白送的——它意味着你每次输出都得有两个模型的结果对齐 schema，double 成本。所以交互场景我更倾向于「预生成 + 缓存」，同一类请求的思考结果复用掉，而不是每次都现场想。
这周 Handbook.md 那篇 提醒了另一件事：长政策文档不能可靠地治理 agent。也就是说「规则写清楚就不用推理」是幻觉。规则越复杂，越需要模型去判断哪条规则适用，而不是照着执行——这个判断本身，就是推理。你省不掉。
AgentHPOBench 这类评测我关注着，但还没到能指导生产决策的程度。agent 做超参寻优，每一步都基于上一步的实验证据选下一个点，理论上也是「一步错全盘错」，但实际跑起来方差很大。按我现在看，这个场景两年内还是人干活、agent 打下手。
最后回到那个问题。推理模型什么时候值？看错误成本，不看任务标签。错误成本高的上游——规划、设计、审计——值；成本低的下游——抽取、改写、分类——普通模型直接上。中间的拆开混用，延迟问题靠预告和降级解决。
我不会说这是最终答案。6 个月后模型价格再跌一半，这个判断可能就要反过来。但至少现在，这是我们生产环境里实际在用的分界线。