企业官网建设流程全解析

1. 从一次账单异常说起：推理强度到底在调什么

上个月帮一个做 Agent 产品的团队看成本问题，他们后台的 Token 消耗曲线陡得吓人，日均调用量没涨多少，账单却翻了三倍。我让他们把请求日志拉出来，一眼就看到了问题：几乎所有请求的reasoning_effort参数都写死成了xHigh。问了一圈，回答很统一——“怕模型想得不够深，干脆拉满”。

这个思路听起来很稳妥，实际上是把推理强度当成了一个“越高越好”的旋钮。但推理强度不是音量键，它更像是一个思考预算：你给模型多少空间去展开中间推理过程，它就会消耗多少 Token，而这些 Token 里有一部分是真正有用的推导，另一部分只是反复确认、绕圈子、自我怀疑。选Low不是偷懒，而是在很多场景下，Low的产出质量和xHigh几乎没有可感知的差距，但成本和延迟能差出一个数量级。

先把概念理清楚。所谓推理强度（reasoning effort / reasoning intensity），指的是模型在给出最终答案之前，允许自己进行多少“内部思考”的档位控制。常见的档位大致是Low、Medium、High、xHigh这几级，不同厂商命名略有差异，但本质一样：档位越高，模型在内部推理链上愿意花的 Token 越多。注意这里的关键词是“愿意花”，不是“必须花”——它是个上限倾向，不是硬性配额。

为什么会有这个参数？因为大模型的推理过程本质上是自回归地一个 Token 一个 Token 往外吐。你让它“多想几步”，它就得把中间步骤也写成 Token。这些中间 Token 对最终答案有帮助，但边际收益递减得非常快。一道简单的分类题，模型想 50 个 Token 和想 500 个 Token，答案大概率一样；但后者你要为 450 个额外 Token 付费，还要多等好几秒。

所以标题里那个问题——“有 xHigh，为什么要选 Low？”——真正的答案不是“Low 更省钱”这么简单，而是你要先搞清楚你的任务到底需不需要那么多思考预算。接下来的内容，我会把推理强度的作用机制、不同档位的实际差异、什么场景该选什么档、以及怎么在 Agent 系统里做动态调度，一层层拆开讲。如果你正在做 Agent 开发、正在被 Token 账单和响应延迟两头夹击，这篇应该能帮你省下不少真金白银。

2. 推理强度的作用机制：模型到底把 Token 花在哪了

2.1 推理 Token 和输出 Token 不是一回事

很多人看账单的时候只盯着“输出 Token”，以为那就是模型回答的字数。实际上在支持推理强度的模型里，一次请求的 Token 消耗通常分成三块：输入 Token（你的 prompt）、推理 Token（内部思考链）、可见输出 Token（你最终看到的回答）。推理 Token 往往是大头，而且它不计入你看到的回答里，所以你会有一种“我没让它说这么多话，怎么这么贵”的错觉。

举个具体的量级感受。同一个任务，让模型判断一段用户评论是正面还是负面：

• Low档：推理 Token 大约 20 到 50 个，直接给结论。
• Medium档：推理 Token 大约 100 到 200 个，会简单复述判断依据。
• High档：推理 Token 可能到 500 个以上，会列举多个角度再权衡。
• xHigh档：推理 Token 轻松破千，甚至出现“我再想想”“等等，刚才那个判断可能有问题”这类自我纠偏。

最终那个“正面/负面”的结论，四个档位给出的答案在绝大多数样本上是一致的。你多花的钱，买到的是一份更长的草稿纸，而不是更准的答案。

2.2 推理强度影响的是“探索深度”而非“知识量”

这里有个特别容易误解的点：调高推理强度不会让模型知道更多东西。模型的知识在训练阶段就固化了，推理强度只影响它在已知信息上做多少步推导和验证。

打个比方。你让一个人算 17 乘以 24。他知不知道乘法口诀，这是“知识”；他愿不愿意在纸上列竖式、验算一遍，这是“推理强度”。如果这个人根本不会乘法，你让他验算十遍也没用；如果他本来就会，验算一遍和验算十遍的结果一样，只是后者更慢。

这个类比直接推导出一个实用结论：推理强度对“需要多步逻辑推导”的任务收益大，对“知识检索型”任务收益几乎为零。你问“法国的首都是哪里”，Low和xHigh没区别；你问“这段代码里的并发 bug 出在哪”，xHigh可能真的比Low强，因为它需要沿着执行路径一步步推。

2.3 高推理强度带来的三个隐性成本

除了显而易见的 Token 费用，高推理强度还有三个容易被忽略的成本，我在实际项目里都踩过：

延迟成本。推理 Token 是串行生成的，多 1000 个推理 Token 就意味着多等一到几秒。在 Agent 场景里，一个任务可能要调用模型十几次，每次多等两秒，整个任务就多等二三十秒。用户体感直接从“秒回”变成“卡住了”。

上下文污染成本。在多轮 Agent 循环里，如果推理链被塞进上下文传给下一轮，它会挤占宝贵的上下文窗口，还可能把上一轮的“犹豫”和“错误假设”带进下一轮，导致模型在错误的方向上越走越远。我见过一个 Agent 因为把冗长的推理过程反复累积，到第五轮时上下文爆掉，直接报错。

稳定性成本。推理链越长，模型“想岔了”的概率越高。Low档模型往往直奔答案，反而稳定；xHigh档模型有时会在中间步骤里引入一个错误假设，然后基于这个假设一路推下去，最后给出一个自信但错误的答案。这就是所谓的“过度思考”。

提示：如果你发现某个任务在High或xHigh下反而不如Low稳定，先别怀疑模型，很可能是任务本身不需要那么长的推理链，高预算反而给了它“想歪”的空间。

3. 各档位实测对比：什么任务该配什么强度

3.1 我做过的一组对照测试

为了把这件事说清楚，我用同一批任务在四个档位上跑了一轮对照。任务分四类：简单分类、信息抽取、多步数学推理、代码调试。每类 50 个样本，记录准确率、平均推理 Token 数、平均延迟。结果大致如下（数值是相对量级，不同模型会有差异，但趋势一致）：

这张表的信息量很大。前两类任务，xHigh相比Low只提升了 1 个百分点，但 Token 和延迟涨了七八倍——这 1 个百分点大概率还是噪声，不是真实提升。后两类任务，xHigh的提升是实打实的 20 多个百分点，这时候多花的钱就值。

所以选档的核心判断标准就一条：这个任务的正确率对推理深度是否敏感。敏感就往上调，不敏感就往下压。

3.2 简单分类和信息抽取：Low 是默认答案

这两类任务的共同点是“答案就在输入里”，模型不需要推导，只需要识别和搬运。情感分类、意图识别、实体抽取、格式转换、关键词打标，全都属于这一类。

这类任务用xHigh是纯粹的浪费。更麻烦的是，高推理强度在这类任务上还可能引入“过度解读”。我遇到过模型在判断一条中性评论时，xHigh档硬是推理出“用户可能隐含不满”，最后给了负面标签，而Low档直接按字面判断，反而对了。

我的默认配置是：所有抽取和分类类调用一律Low，只有在准确率不达标时才逐级往上试，而且每次只升一档，观察是否真的有提升。绝大多数情况下，Low就够了。

3.3 多步推理和代码任务：该给预算就给

反过来，有些任务你不给足推理预算，模型是真的做不对。典型的是多步数学应用题、复杂逻辑题、跨文件的代码 bug 定位、需要权衡多个约束的方案设计。

这类任务的特点是：中间任何一步错了，最终答案就错了，而且错误会累积。Low档模型倾向于“跳步”，直接凭直觉给答案，在简单样本上没问题，一遇到需要三四步推导的题就崩。High或xHigh档会让模型把每一步都写出来，虽然慢，但正确率提升明显。

不过这里也有个度。我实测下来，High和xHigh在多步推理上的差距，往往没有Low到High那么大。也就是说，从 Low 升到 High 是收益最大的区间，从 High 升到 xHigh 是边际收益递减的区间。所以我的建议是：多步推理任务默认High，只有在High明显不够时才上xHigh，别一上来就拉满。

3.4 一个反直觉的发现：xHigh 在长任务里可能更差

这是我在 Agent 项目里踩过的最大的坑。一个需要连续调用模型十几轮的任务，我一开始全程用xHigh，想着“复杂任务嘛，给足预算”。结果发现任务成功率反而不如全程Medium。

排查下来原因有两个。一是前面说的上下文污染：每轮的冗长推理链累积起来，到后面几轮上下文里全是“我之前想过……”“但是也可能……”，模型被这些犹豫的表述干扰，决策越来越不果断。二是延迟导致的超时：单轮多等几秒，十几轮下来总时长翻倍，部分请求触发了上游的超时限制，直接失败。

后来我改成动态调度：任务开头用Medium做规划，中间的执行步骤用Low，只在遇到明确的“卡点”（比如连续两次失败、或者需要做关键决策）时才临时升到High。成功率上去了，总成本还降了一半多。这个经验我后面会单独展开讲怎么落地。

4. 在 Agent 系统里做推理强度的动态调度

4.1 为什么静态配置一定会出问题

Agent 和单次问答最大的区别是：一个 Agent 任务里包含很多性质完全不同的子步骤。规划、工具选择、参数填充、结果校验、错误恢复，这些步骤对推理深度的需求天差地别。如果你在代码里写死一个档位，要么是简单步骤被浪费，要么是复杂步骤被饿死。

我见过太多项目在初始化客户端的时候写一句reasoning_effort="high"就完事了，然后所有调用都吃这个配置。这种做法在 demo 阶段没问题，一上量就是灾难。正确的做法是把推理强度当成一个每次调用都可以独立决定的参数，根据当前步骤的性质动态给值。

4.2 按步骤类型分配预算的实操方案

我现在的默认策略是这样的，你可以直接拿去改：

• 意图识别 / 路由决策：Low。这一步只需要判断“用户想干什么”，答案空间很小，不需要深度推理。
• 任务规划 / 步骤拆解：Medium或High。这一步需要权衡多个方案，值得给预算，但也不用拉满。
• 工具调用参数生成：Low。参数格式基本是确定的，模型只需要按 schema 填，不需要想太多。
• 工具返回结果解析：Low。解析是识别任务，不是推理任务。
• 关键决策点 / 冲突消解：High。当多个信息源冲突、或者需要在几个方案里选一个时，给足预算。
• 错误恢复 / 重试：High或xHigh。失败往往意味着常规思路走不通，需要模型换个角度想，这时候高预算才有价值。

这套策略落地后，我那个项目的平均推理 Token 消耗降了大约 60%，任务成功率还涨了几个点。核心逻辑就是：把预算花在真正需要思考的少数步骤上，而不是平摊到每一步。

4.3 用失败信号触发档位升级

动态调度里最实用的一个技巧是“失败升级”。不要一上来就猜这个任务难不难，而是先用低档跑，失败了再升档重试。具体逻辑：

1. 第一次尝试用Low。
2. 如果输出格式校验失败、或者工具调用报错、或者结果明显不合理，升到Medium重试。
3. 再失败升到High，还失败升到xHigh。
4. 设一个重试上限，比如 3 次，超过就交给人工或降级处理。

这个模式的好处是，大部分简单请求一次Low就过了，只有真正难的请求才会走到高档位。整体成本由简单请求的低成本主导，而难请求又能拿到足够预算。这比“一刀切High”在成本和效果上都更优。

注意：升级重试的时候，记得把上一次失败的输出和错误信息一起放进新的 prompt，告诉模型“上次这样失败了，换个思路”。否则模型很可能在同一个坑里再摔一次，白白多花 Token。

4.4 监控指标：别只看总 Token

做动态调度必须配套监控，否则你不知道调得对不对。我建议至少盯这几个指标：

• 各档位的调用占比：如果xHigh占比超过 10%，大概率是哪里配置错了。
• 各档位的成功率：如果Low的成功率和High差不多，说明这个任务根本不需要高档位。
• 单任务平均推理 Token：这是成本的核心指标，按任务类型分组看。
• 升级重试率：如果大量请求都要升级才成功，说明你的初始档位设低了。

这几个指标一摆出来，哪里浪费、哪里不足，一目了然。我一般每周看一次，发现异常就调策略。

5. 那些年我在推理强度上踩过的坑

5.1 把 xHigh 当成“质量保险”的代价

最开始做 Agent 的时候，我的心态就是“宁可多花钱，也要保证质量”，所有调用全上xHigh。结果第一个月账单出来，我盯着那个数字看了半天。更讽刺的是，质量并没有更好——前面说的长任务成功率反而下降，因为上下文被推理链撑爆了。

后来我才想明白，推理强度不是质量保险，它是思考预算。预算给多了，模型不会更聪明，只会更啰嗦、更犹豫。真正决定质量的是任务本身是否适合深度推理，以及你的 prompt 和工具设计是否合理。

5.2 推理链被当成上下文传递的连锁反应

这个坑特别隐蔽。有些框架会把模型的完整响应（包括推理过程）原样塞进下一轮的上下文。单轮看没问题，多轮下来就出事了：上下文里堆满了“让我想想”“等等”“另一种可能是”，模型被自己的犹豫带偏，决策质量断崖式下跌。

解决办法很简单：只把最终的结构化输出传给下一轮，推理过程该丢就丢。如果框架默认保留，你就在代码里显式裁剪。这一步做完，我那个 Agent 的稳定性肉眼可见地变好了。

5.3 延迟超时引发的雪崩

高推理强度带来的延迟，在单次调用里可能只是“慢一点”，但在 Agent 循环里会累积成超时。我遇到过一次线上事故：某个任务因为xHigh导致单轮延迟从 2 秒涨到 8 秒，十几轮下来超过了上游网关的 60 秒限制，请求被中断，Agent 进入错误恢复，又用xHigh重试，再次超时，形成雪崩。

修复方案是给每个步骤设独立的超时预算，并且在高延迟步骤上主动降档。延迟和成本一样，是需要被主动管理的资源，不能放任。

5.4 不同模型对同一档位的响应差异

还有一个容易忽略的点：High这个档位在不同模型上的实际表现可能差很多。有的模型High就已经很克制，有的模型High会放飞自我。所以换模型的时候，推理强度的配置必须重新测一遍，不能直接沿用。我一般会拿一组标准样本在新模型上跑一遍各档位，重新确定默认值。

6. 一套可以直接抄的推理强度配置模板

6.1 配置表

把前面的经验整理成一张可以直接用的表：

6.2 落地时的三个检查点

第一，默认值设Low，按需升级。不要反过来。默认低档位能帮你省下大部分成本，只有明确需要时才升。

第二，每次调用独立传参。别在客户端初始化时写死，把推理强度作为每次请求的参数传进去，这样才能动态调度。

第三，配套监控和回归测试。改完配置后，拿一组标准样本跑一遍，对比准确率和 Token 消耗，确认改动是正向的再上线。

6.3 一个判断该不该升档的简单方法

如果你拿不准某个任务该用哪个档位，用这个方法快速判断：问自己“这个任务的答案，是不是需要把中间步骤写出来才能得到”。如果答案是“不需要，看一眼就知道”，用Low；如果是“需要，得一步步推”，用High；如果是“需要推，而且中间容易出错”，考虑xHigh。

这个方法不精确，但能覆盖 80% 的判断场景，比拍脑袋强。

7. 关于推理强度，我最后想说的几句实在话

回到标题那个问题——“有 xHigh，为什么要选 Low？”——现在应该能给出一个完整的回答了。选Low不是因为抠门，而是因为大部分任务根本不需要那么多思考预算，多给的预算不会变成更好的答案，只会变成更长的账单和更慢的响应。真正专业的做法不是把所有旋钮拉满，而是知道每个旋钮在什么场景下该拧到哪一档。

我在实际项目里最大的体会是：推理强度这个参数，用好了是成本优化的利器，用不好就是隐形的成本黑洞。它不像 bug 那样会报错，它只是安静地把你的钱和延迟一点点吃掉，直到某天账单出来你才后知后觉。所以别等到账单爆炸才想起来调它，从项目第一天就把它当成一个需要认真对待的配置项。

最后分享一个小技巧：如果你现在手上有一个跑着的 Agent 项目，不妨花半小时把最近的请求日志拉出来，统计一下各档位的调用占比和对应的成功率。我敢打赌，你会发现至少有一半的高档位调用是完全可以降到Low的。把这部分降下来，成本立竿见影地降，效果大概率一点不受影响。这件事的投入产出比，比你去优化 prompt 里的措辞高多了。