跳到主要内容

规划税:为什么你的智能体把更多 Token 花在思考上而非执行上

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的智能体刚刚花了 6完成了一项直接API调用只需6 完成了一项直接 API 调用只需 0.12 就能处理的任务。如果你在生产环境中构建过智能体系统,这个比例大概不会让你感到惊讶。真正令人意外的,是那些 token 究竟去了哪里:不是工具调用,不是生成最终答案,而是智能体在推理下一步该做什么。分解任务、反思中间结果、在观察结果与预期不符时重新规划。这就是规划税——智能体在行动之前用于思考的 token 开销——对于大多数智能体架构而言,它在第一个有效动作触发之前就已消耗掉总 token 预算的 40–70%。

规划税本身并不是 bug。推理能力正是将智能体与简单的提示-响应系统区分开来的关键。但当决定做什么的成本超过实际去做的成本时,你面对的就是一个工程问题,再便宜的推理也无法解决它。自 2022 年底以来,每 token 价格已下降约 1,000 倍,然而智能体的总体支出仍在持续攀升——这是一个典型的杰文斯悖论:更便宜的 token 只会催生更多的 token 消耗。

规划开销的解剖

要理解规划税,需要追踪 token 在标准 ReAct 智能体循环中的实际流向。每个循环都遵循相同的模式:模型生成一个 Thought(对当前状态进行推理),选择一个 Action(选择工具和参数),接收一个 Observation(工具的输出),然后再次推理下一步该做什么。这条链上的每一步都有 token 成本,但 Thought 步骤才是预算流失最严重的地方。

考虑一个中等复杂度的任务——比如,回答一个需要查询两个 API 并综合结果的问题。一个 ReAct 智能体可能执行 5–8 个推理循环。在每个循环中,Thought 步骤通常生成 200–500 个思维链推理 token,而 Action 本身可能只是一个 50 token 的函数调用。Observation 被注入回上下文窗口,这意味着每个后续的 Thought 步骤都要重新读取整个对话历史。到第八个循环时,你的智能体正在对一个 80% 内容都是自己生成叙述的上下文进行推理。

token 数学会迅速复利叠加:

  • 推理 token 成本更高。 在各主要服务商中,输出 token 的定价是输入 token 的 3–8 倍。2026 年的中位数约为 4:1,顶级推理模型可达 8:1。每一个思维链步骤都要支付这笔溢价。
  • 上下文窗口急剧膨胀。 每个 observation 都被追加到对话中,因此输入 token 数会随着每个循环线性(甚至更快地)增长。一个以 2,000 token 提示开始的智能体,到第五次工具调用时可能正在处理 30,000 token 的上下文。
  • Reflexion 循环放大一切。 能够自我批评并重试的智能体——Reflexion、自洽性或思维树模式——消耗的 token 可能是单次通过的 50 倍。对一个本就需要五个推理步骤的任务进行十次重试,意味着 50 次思维链生成,而其中大多数只是对同一结论的略微变体。

结果是:智能体进行的 LLM 调用次数是简单聊天机器人的 3–10 倍,一个用户请求很容易消耗直接补全 5 倍的 token 预算。对于无约束的软件工程智能体,每项任务仅 API 费用就可达 $5–8。

效率与智能的权衡

规划税之下隐藏着一个更深层的问题:更多的规划并不总意味着更好的结果。苹果公司 2025 年的论文《思考的幻觉》对推理模型在逻辑谜题上进行了测试,发现了一个引人注目的规律。对于简单问题,没有思维链的标准模型更快,有时也更准确——额外的推理纯属浪费。对于中等难度的问题,推理确实有帮助。但对于困难问题,推理型和非推理型模型都陷入了崩溃,而推理模型在最难的实例上实际使用了更少的思考 token,仿佛模型意识到自己无法解决问题而提前放弃了。

这为智能体规划创造了一种双峰失效模式:

  • 简单任务的过度思考。 被要求查询股价的智能体不需要五步分解。但如果你的架构总是运行完整的 ReAct 循环,即便一个工具调用就足够了,你也要支付规划税。
  • 困难任务的规划不足。 矛盾的是,最需要仔细规划的任务,恰恰是扩展推理收益最小的任务——因为无论模型花多少 token 思考,都会触及自身能力的上限。

实际含义:存在一个任务复杂度的阈值,在这个阈值之后,规划开销会超过执行成本。低于这个阈值,规划是浪费;高于这个阈值,规划有帮助,但收益递减。额外推理 token 能产生相称的更好结果的甜蜜点,比大多数智能体架构假设的要窄得多。

降低规划税的架构模式

好消息是:规划税是一种架构选择,而非 LLM 智能体不可改变的固有属性。已经出现了几种无需牺牲能力便能收回 token 预算的模式。

先规划后执行(ReWOO)

ReWOO 架构(Reasoning WithOut Observation,无观察推理)将所有规划集中在单次前置通过中完成。一个 Planner 模块在任何执行开始之前生成完整的蓝图——每个工具调用、每个依赖关系。一个 Worker 模块随后执行该计划,无需为中间推理触发额外的 LLM 调用。最后由一个 Solver 模块综合结果。

token 节省非常显著:在相同任务上,ReWOO 相比 ReAct 轨迹将 token 用量减少了 5–10 倍,同时达到或超过了其准确率。在 HotpotQA 基准测试上,它以少用 64% token 的代价实现了 4.4% 的准确率提升。核心洞见是:ReAct 循环中大多数中间"推理"是冗余的——模型只是在更新的上下文中重新推导出它一开始就有的计划。

权衡在于适应性。ReWOO 无法在执行过程中即兴发挥。如果第三个工具调用返回了意外数据,计划不会做出调整。对于执行路径可预测的任务,这不是问题。对于每个 observation 都真正改变策略的探索性任务,则需要混合方法。

计划缓存

智能体计划缓存(Agentic Plan Caching,APC)从已完成的智能体执行中提取结构化计划模板,并将其复用于语义相似的未来任务。当新请求到达时,系统通过关键词提取将其与缓存计划进行匹配,然后使用轻量级模型将模板适配到具体上下文。

结果令人信服:在保持任务准确率的同时,平均降低 50% 的成本,并改善 27% 的延迟。与聊天机器人的语义缓存(直接返回缓存响应)不同,APC 缓存的是计划结构,同时允许执行细节有所变化。这意味着第一个提出"比较这三个数据库中 Q3 收入"的用户支付全额规划税,但后续类似查询将完全跳过分解环节。

层次分解

层次分解不是让一个模型在平面规划循环中包揽一切,而是使用轻量级模型进行高层任务分解,将昂贵的模型保留给真正需要复杂推理的步骤。这与让高级架构师设计方案、初级开发者执行各个步骤的组织模式如出一辙。

在实践中,这意味着将 90% 的规划查询路由到更小、更便宜的模型,只将真正需要的 10% 决策升级到前沿模型。团队报告使用这种级联方法实现了 87% 的成本降低。

思考预算

现代推理模型支持显式的思考预算——你可以告诉模型内部推理最多花费 N 个 token。这是一种粗糙的工具,但出人意料地有效。关于 token 预算感知推理的研究表明,约束思考预算会迫使模型更加果断,减少模棱两可和重复的自我反思,且不会造成相称的准确率损失。

实用启发式方法:将思考预算与任务复杂度成比例地设置。工具选择步骤不需要 4,000 token 的深思熟虑。多步骤综合可能需要。从小预算开始、仅在模型表示置信度低时才扩展预算的自适应方法,可以用一小部分成本获取大部分收益。

工具税:隐藏的乘数效应

规划开销不仅来自推理 token。智能体工具包中的每个工具都会增加税负,即使该工具未被使用。工具 schema 会作为函数定义被序列化到提示中,在每次请求时被 tokenize 并计费。一个拥有 30 个可用工具的智能体,每次请求光是描述它从未调用的工具就可能花费 3,000–5,000 个 token。

解决方法很简单:在每次 LLM 调用之前按相关性过滤可用工具。如果智能体处于"数据检索"阶段,上下文中就不需要代码执行或发送电子邮件的工具。这相当于 LLM 版本的"只加载你需要的库"——事后看来显而易见,但由于成本在你对 token 用量进行监测之前是不可见的,所以往往被忽视。

类似地,条件式系统提示——仅在工具相关时才包含工具专属指令——可以在每次请求中消除数千个多余的上下文 token。

衡量你的规划税

无法衡量的就无法优化。大多数团队追踪每次请求的总 token 用量,但这个单一数字掩盖了规划与执行的分配情况。要诊断你的规划税,请对以下指标进行埋点:

  • 规划比率:推理步骤消耗的 token 除以总 token 数。如果超过 50%,你很可能存在过度规划。
  • 推理与动作比率:每次工具调用消耗的推理 token 数。健康的比率取决于你的业务域,但 10:1 或更高意味着模型在过度思考。
  • 重规划率:智能体在一次 observation 后重新规划的频率。频繁重规划表明初始计划质量差或工具行为不可预测。
  • 上下文增长率:每个循环对话上下文增长的速度。线性增长是正常的;超线性增长(来自冗长的 observation 或重复的自我反思)是一个危险信号。
  • 每 token 边际准确率:将思考预算翻倍是否能可测量地改善结果?如果不能,你已经超过了收益递减的阈值。

一旦有了可见性,优化路径通常遵循可预测的顺序:首先,削减工具 schema 和条件提示(低垂的果实,节省 20–30%)。然后为最常见的查询模式实施计划缓存(在缓存命中时再节省 30–50%)。最后,评估你的架构是否需要完整的 ReAct 循环,还是先规划后执行模式更适合你的用例。

未来展望

规划税是一个过渡性问题。随着模型在高效推理方面的进步——仅在能带来价值的地方花费 token——这一开销将会缩小。自适应思考方法(模型根据任务难度自我调节推理深度)已经在生产模型中落地。计划缓存和层次分解也正在从研究领域的新奇事物演变为标准基础设施。

但更深层的教训将比具体技术更为持久:在任何思考和行动都是计量资源的系统中,你需要分别为它们做预算。将 token 用量视为单一笼统数字,就像不区分 CPU 和 I/O 地追踪"计算量"——技术上正确,但在运营上毫无用处。那些能够控制智能体成本的团队,不仅会问"我们用了多少 token?",还会追问"其中有多少 token 真正推动了我们走向答案?"

规划税是真实存在的,它是可以衡量的,对于当今大多数生产智能体而言,它是推理预算中单项最大的支出。问题不在于是否要支付它——一定程度的规划是必要的——而在于你是否为智能体真正需要做出的决策支付了恰当的代价。

References:Let's stay in touch and Follow me for more thoughts and updates