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

你的智能体刚刚花了 $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 都真正改变策略的探索性任务，则需要混合方法。