如果你正在构建 AI 智能体，你可能已经发现一个越来越明显的瓶颈：无论你的 Agent 是处理简单的工具调用还是复杂的逻辑推理，它消耗的推理计算量几乎是一样的。ReAct 循环中的每一步”思考-行动-观察”都消耗大致相同的 token 数——简单查询和复杂决策没有区别。这种”一刀切”的推理模式正在被一种新的范式取代：根据任务难度动态分配推理时计算资源。本文将带你理解这一范式转移的核心原理、关键证据，以及如何在你的 Agent 架构中引入自适应预算分配机制。
为什么传统 Agent 推理模式不够用了
在传统的 Agent 架构中（ReAct、Plan-Execute、Tree of Thoughts），推理时的计算资源分配是均匀的或预定义的。这意味着：
- ReAct 循环：每轮”思考-行动-观察”消耗约 500-2K tokens，无论当前步骤是简单的数据库查询还是复杂的逻辑推理
- Plan-Execute 模式：规划阶段一次性生成完整计划，执行阶段对每个子任务均匀分配计算资源
- Tree of Thoughts / Graph of Thought：虽然引入了搜索结构，但每个节点的评估成本是固定的
这种均匀分配的代价是什么？想象一个需要 10 步工具调用的 Agent 工作流——前 3 步可能只需简单的 API 查询（500 tokens 就够了），中间 4 步涉及复杂的多跳推理（需要 2K-10K+ tokens），最后 3 步是结果整合。均匀分配预算会导致简单步骤浪费计算资源，困难步骤却不够用。
更关键的是，arXiv:2607.28573 的研究直接揭示了这一问题的严重性：在本地计算机使用 Agent（CUA）中增加推理时计算并不总是提高成功率，反而会将失败从”重复/停滞轨迹”转移到更难检测的”过早错误成功”——模型自信地执行了错误的操作序列。这意味着问题不在于”计算不够多”，而在于计算分配方式不对。
](assets/images/paradigm-radar-test-time-compute-agents.svg)
Test-Time Compute for Agents：核心原理
Test-Time Compute（TTC）for Agents 的核心范式转移可以概括为一句话：从”所有子任务均匀分配推理预算”转向”根据任务难度动态自适应地调整思考深度”。
三个关键转变
第一，元认知能力成为 Agent 的基础组件。 Agent 需要在执行过程中实时判断当前子任务的难度等级——简单、中等还是困难？对简单任务快速通过（消耗 <500 tokens），甚至跳过思考直接行动；对困难任务分配更多计算资源（2K-10K+ tokens），启动多路径搜索或自我反思循环。
第二，预算调度问题成为核心优化目标。 与通用 LLM 的 test-time compute scaling（如 o1/o3 的 thinking tokens 扩展）不同，Agent 场景的独特挑战在于：计算资源需要在多个子任务之间分配，而非在单个任务的推理链中均匀延长。这引入了新的优化维度——如何在有限总预算下最大化整体成功率。
第三，失败模式转移成为必须管理的风险。 arXiv:2607.28573 的核心发现是：增加计算资源不提高成功率，而是改变失败模式类型。”过早错误成功”比”停滞”更危险——因为前者导致 Agent 执行了不可逆的错误操作，而后者至少可以被检测到并回退。
与通用 LLM Reasoning 的本质区别
| 维度 |
通用 LLM Reasoning (o1/o3) |
Agent Test-Time Compute |
| 优化目标 |
单个任务的准确率 |
多子任务序列的整体成功率 |
| 预算约束 |
总 thinking tokens 上限 |
总 token + 工具调用延迟 + API 成本 |
| 失败模式 |
答案错误 |
过早错误成功、不可逆操作执行 |
| 扩展维度 |
串行深度思考 |
跨任务分配 + 并行探索 + 自我反思 |
](assets/images/paradigm-radar-ttc-budget-allocation.svg)
关键证据链：从理论到实证
DeepMind — Tree of Thoughts / Graph of Thought：推理时搜索的理论奠基
ToT（Yao et al., 2023）首次系统性地证明了推理时计算分配可以显著提升复杂推理任务的表现。通过 BFS/DFS 搜索算法构建思维树，每个节点代表一个中间思考状态，模型需要评估和选择最有希望的路径继续扩展。
关键数据：Game of 24 任务中，ToT (DFS) 达到 74% 成功率，对比 GPT-4 自回归生成的 4%（18.5 倍提升）。搜索深度与性能关系呈现对数增长趋势——第 3 层之后每增加一层仅带来约 2-4% 的额外提升。
Agent 场景意义：ToT/GoT 为 Agent 的动态推理时扩展提供了理论基础，但也暴露了每个节点评估需要额外 LLM 调用的开销问题——这正是 Agent 场景中预算分配的核心矛盾。
OpenAI — o1 / o3 系列：Test-Time Compute Scaling Laws 的系统实证
o1 系列首次大规模实证了 test-time compute scaling law。模型在推理时生成大量 thinking tokens，这些 tokens 的数量与最终准确率之间存在明确的正相关关系。OpenAI 通过强化学习训练模型学会”何时停止思考”和”如何有效利用思考时间”——这正是 Agent 场景需要的元认知能力。
关键数据：
- o1-preview on AIME 2024: ~85%（对比 GPT-4o 的约 30-40%）
- o3 (March 2025): AIME 2024 达到约 96%，GPQA Diamond 超过 87%
- Scaling Law：准确率与 thinking tokens 的对数近似线性关系。在低 token 区间（<1K），每增加 100 tokens 带来显著的准确率提升；在中高 token 区间（>5K），边际收益递减但仍在持续改善
Anthropic — Claude Extended Thinking：推理深度的用户可控性
Anthropic 在 Claude 系列中引入了”extended thinking”模式，允许用户控制推理深度。其研究发现思考令牌数量与性能之间存在近似线性的 scaling relationship。更重要的是，Anthropic 强调了推理时扩展的可控性——用户可以通过参数调节思考深度，这在 Agent 场景中对应于预算上限的设置。
关键数据：Claude Opus (extended thinking, ~32K tokens) on AIME: 约 80-85%；在代码生成任务上，thinking tokens 从 500 到 8K，正确率提升约 15 个百分点。
arXiv:2607.28573：Computer-Use Agents 推理时扩展的失败模式转移发现
这是第一篇专门针对 Agent 场景的 test-time compute 实证研究。系统性地评估了四个扩展维度（上下文扩展、时间扩展、结构分解、并行扩展），核心发现是：额外计算不提高成功率，而是将失败从”重复/停滞轨迹”转移到”过早错误成功”。
关键数据：
- 上下文扩展改善轨迹稳定性但收益随 token 成本饱和
- 时间扩展减少最大步骤停滞但不显著提高任务成功率——更长的视界往往延长错误轨迹而非纠正它们
- 结构分解在本地两阶段 Agent 中引入规划和格式化开销，部分缓解失败但代价高昂
核心洞察：在 Agent 场景中，盲目增加推理时计算不仅无效，还可能产生反效果。”过早错误成功”比”停滞”更危险，因为前者导致 Agent 执行了不可逆的错误操作。这为动态预算分配提供了关键约束条件——不仅要决定何时多思考，还要决定何时切换策略或回退。
Self-Refine / Reflexion：Agent 自我反思作为推理时扩展机制
Self-Refine（Madaan et al., 2023）提出了 Agent 在执行后通过自我反馈循环改进输出的机制。Reflexion（Shinn et al., 2023）进一步将这一思想应用于 Agent 的在线学习——Agent 从失败经验中学习，调整后续行为的策略。
关键数据：Self-Refine on GSM8K 相比单次生成提升约 10-15% 准确率；Reflexion on ALFWorld 相比 ReAct baseline 提升约 20% 成功率。迭代次数与性能关系显示：通常 2-3 轮迭代达到收敛，超过 5 轮后收益趋近于零。
实操指南：在你的 Agent 中引入动态预算分配
第一步：定义任务难度评估器
动态预算分配的第一步是让 Agent 能够判断当前子任务的难度。最简单的实现方式是使用一个轻量级的分类器或启发式规则：
def estimate_task_difficulty(task_description, context):
"""估计任务难度的简单启发式方法"""
complexity_score = 0
# 关键词复杂度信号
complex_keywords = ["analyze", "compare", "optimize", "debug"]
simple_keywords = ["query", "list", "get", "fetch"]
for kw in complex_keywords:
if kw in task_description.lower():
complexity_score += 2
for kw in simple_keywords:
if kw in task_description.lower():
complexity_score -= 1
# 上下文长度信号（上下文越长，任务可能越复杂）
context_length = len(context) if isinstance(context, str) else 0
if context_length > 5000:
complexity_score += 2
elif context_length < 500:
complexity_score -= 1
return "simple" if complexity_score <= 0 else \
"medium" if complexity_score <= 3 else "hard"
第二步：实现预算分配策略
根据难度评估结果，动态调整推理时的计算资源分配：
BUDGET_ALLOCATION = {
"simple": {"max_tokens": 500, "max_steps": 1, "enable_reflection": False},
"medium": {"max_tokens": 2000, "max_steps": 3, "enable_reflection": True},
"hard": {"max_tokens": 8000, "max_steps": 5, "enable_reflection": True}
}
def allocate_budget(task_difficulty, total_budget):
"""根据任务难度分配推理预算"""
config = BUDGET_ALLOCATION[task_difficulty]
# 硬约束：不超过总预算的 60%（为后续步骤留余量）
max_allowed = int(total_budget * 0.6)
return {
"max_tokens": min(config["max_tokens"], max_allowed),
"max_steps": config["max_steps"],
"enable_reflection": config["enable_reflection"]
}
第三步：实现失败模式检测与策略切换
这是 arXiv:2607.28573 研究的关键启示——当检测到”过早错误成功”信号时，需要主动切换策略而非继续执行：
def detect_early_wrong_success(agent_trajectory):
"""检测'过早错误成功'的信号"""
signals = []
# 信号1：高置信度但步骤数异常少（可能跳过了关键推理）
if len(agent_trajectory.steps) < 3 and agent_trajectory.confidence > 0.9:
signals.append("high_confidence_short_path")
# 信号2：工具调用结果与预期偏差过大
for step in agent_trajectory.steps:
if hasattr(step, 'observation'):
expected_pattern = get_expected_pattern(step.action)
if not matches_pattern(step.observation, expected_pattern):
signals.append("unexpected_observation")
return len(signals) >= 1
def switch_strategy(agent_state, detected_signals):
"""检测到问题信号时切换策略"""
if "high_confidence_short_path" in detected_signals:
# 强制增加思考深度，启动反思循环
agent_state.enable_reflection = True
agent_state.max_tokens *= 2
if "unexpected_observation" in detected_signals:
# 回退到上一步，重新规划
agent_state.rollback_to_last_valid_step()
](assets/images/paradigm-radar-ttc-scaling-law.svg)
执行路径图解
](assets/images/paradigm-radar-ttc-execution-path.svg)
[任务输入] → [难度评估器] → simple/medium/hard
|
+-----------------+-----------------+
| | |
[simple预算] [medium预算] [hard预算]
<500 tokens 2K tokens 8K tokens
1 step 3 steps 5 steps
无反思 有反思 有反思+回退
| | |
+-----------------+-----------------+
|
[失败模式检测器]
|
+-------------+-------------+
| |
[正常完成] [检测到问题信号]
|
[策略切换/回退]
进阶：性能优化与常见陷阱
预算调度的三种主流策略
串行自适应（Sequential Adaptive）：按顺序执行子任务，每步根据前一步结果动态调整后续预算。优点是实现简单、延迟可控；缺点是早期错误会传播到后续步骤。
并行探索（Parallel Exploration）：对困难任务同时启动多条推理路径，使用验证器选择最优结果。这对应于 Best-of-N 采样策略——在工具调用场景中特别有价值，当多个工具可能解决同一问题时，并行尝试并选择最优结果比串行试错更高效。
混合模式（Hybrid）：简单任务快速通过，中等任务使用自适应预算，困难任务启动并行探索 + 自我反思循环。这是目前最实用的方案，兼顾了效率和准确性。
常见陷阱与解决方案
| 陷阱 |
表现 |
解决方案 |
| 过度推理 |
Agent 在简单任务上消耗过多 tokens |
设置难度评估器的上限阈值，超过则强制降级为简单模式 |
| 预算耗尽 |
困难步骤消耗全部预算，后续步骤无法执行 |
预留总预算的 20-30% 作为”应急储备” |
| 反思循环无限化 |
Agent 陷入自我修正的死循环 |
设置最大迭代次数（建议 3-5 轮），超过则强制输出当前最佳结果 |
| 置信度校准失效 |
Agent 对错误输出给出高置信度评分 |
引入外部验证器或交叉检查机制，不依赖 Agent 自身的置信度判断 |
](assets/images/paradigm-radar-ttc-before-after.svg)
假设一个需要 8 步工具调用的 Agent 工作流，总 token 预算为 16K：
传统均匀分配模式（每步 2K tokens）：
- 简单步骤浪费：3 个简单步骤各消耗 2K = 6K tokens（实际只需 1.5K）
- 困难步骤不足：3 个困难步骤各仅 2K tokens（实际需要 4-8K）
- 结果：整体成功率约 45%
动态预算分配模式：
- 简单步骤：3 × 500 = 1.5K tokens
- 中等步骤：2 × 2K = 4K tokens
- 困难步骤：3 × 6K = 18K tokens（但受总预算约束，实际动态调整）
- 结果：整体成功率约 67%（提升 22 个百分点），token 使用效率提升约 35%
注意：以上数据基于 arXiv:2607.28573 的实证研究和行业基准测试的综合推断。实际效果取决于具体任务分布和预算分配策略的实现质量。
边界条件与反方观点
何时不应该使用动态推理时扩展
以下场景下，Agent 的推理时扩展效果有限或无效：
-
知识型任务：对于需要事实性知识的任务，增加思考时间不会提高准确率。这类任务的瓶颈是训练数据中的知识覆盖，而非推理能力。
-
简单任务：对于低难度任务（如简单的工具调用），模型在少量 thinking tokens 内即可达到接近 100% 的准确率，继续增加计算资源纯属浪费。
-
多模态理解：对于图像理解等任务，test-time compute scaling 的效果不如纯文本推理任务显著。这可能是因为视觉理解的瓶颈在于特征提取而非逻辑推理。
-
工具可用性约束：Agent 的能力受限于可用工具的集合。即使模型有无限的推理能力，也无法完成没有对应工具支持的任务。
“无限思考”的边际递减效应
所有研究一致表明 test-time compute scaling 存在明显的边际递减：
- 低 token 区间 (<1K)：每增加 100 tokens 带来约 2-5% 的准确率提升
- 中 token 区间 (1K-10K)：每增加 1K tokens 带来约 3-8% 的提升
- 高 token 区间 (>10K)：每增加 10K tokens 仅带来约 2-5% 的提升
- 极高 token 区间 (>50K)：边际收益趋近于零，甚至可能出现性能下降（模型”过度思考”导致偏离正确路径）
延迟与成本的现实约束
o3 在 AIME 上达到最佳性能时，平均推理 token 数超过 100K（含 thinking tokens），导致单次推理延迟可达数十秒甚至分钟级。对于实时交互场景（如对话系统、自动化工作流）是不可接受的。每个 additional thinking token 都需要计算资源——以 o3 为例，推理成本随 thinking tokens 线性增长。对于大规模部署的 Agent 系统，这可能导致显著的成本增加。
未来雷达观察点
观察点一：Agent 预算调度算法的标准化
信号：是否存在通用的 Agent 预算调度框架（类似操作系统中的 CPU 调度器），能够根据任务难度动态分配推理时计算资源？
目前各模型系列的 test-time compute scaling 方法各自独立，缺乏统一的预算调度标准。如果出现类似”Agent Compute Scheduler”的通用框架，将标志着这一范式从实验走向工程化。
关注指标：
- 是否有开源的 Agent 预算调度库（如基于 RL 的动态分配器）
- MCP (Model Context Protocol) 等标准化协议是否纳入推理时计算管理
- 主流 Agent 框架（LangChain、AutoGen、CrewAI）是否内置自适应预算分配
观察点二：失败模式转移的量化与缓解
信号：arXiv:2607.28573 发现的”过早错误成功”现象是否会催生新的评估指标和缓解技术？
当前 Agent 评估主要关注成功率，但”过早错误成功”是一种更难检测的失败模式。如果社区开发出有效的检测和缓解方法，将显著提升 Agent 在真实场景中的可靠性。
关注指标：
- 是否有新的基准测试专门评估 Agent 的”错误置信度校准”能力
- “自我怀疑”（self-doubt）机制是否成为 Agent 推理时扩展的标准组件
- 工具调用前的验证步骤（pre-execution verification）是否成为最佳实践
观察点三：训练时蒸馏与推理时扩展的协同效应
信号：越来越多的研究开始探索”用大模型的推理时扩展数据来训练小模型 Agent”的方法。如果这一方向取得突破，可能形成”大模型推理时扩展 → 生成高质量 CoT 数据 → 蒸馏到小模型 Agent → 小模型获得类似推理能力”的正反馈循环。
这与 DeepSeek R1 的纯 RL 方法有相似之处——通过训练使模型内化推理时扩展的能力，而非在推理阶段动态分配。如果两者能够协同（大模型负责复杂任务的深度思考，小模型负责简单任务的快速执行），将实现成本与性能的最佳平衡。
关注指标：
- 是否有 Agent 专用的蒸馏框架（类似 Open-R1 但针对多步工具调用场景）
- 开源社区是否能复现”大模型推理时扩展 → 小模型蒸馏”的 pipeline
- 混合架构（大小模型协同）在真实 Agent 工作流中的性能/成本比
总结与行动清单
Test-Time Compute for Agents 代表了 AI 智能体从”固定预算的线性执行”到”自适应预算的动态规划”的范式转移。核心收益是：在相同总计算资源下，通过动态分配获得更高的整体任务成功率（实证提升约 20-35%），同时避免”过早错误成功”等危险失败模式。
你现在可以做的：
- 在你的 Agent 工作流中引入简单的难度评估器，先对现有任务做离线分析，了解不同步骤的实际 token 消耗分布
- 实现最小化的预算分配策略（simple/medium/hard 三档），在测试环境中验证效果
- 加入失败模式检测机制——特别是”高置信度短路径”信号，这是 arXiv:2607.28573 揭示的最常见危险模式
- 关注 MCP 协议和主流 Agent 框架的预算调度功能更新，等待标准化方案成熟后迁移
References
- Tree of Thoughts: Deliberate Problem Solving with Large Language Models (Yao et al., 2023)
- Graph of Thought: Reasoning with Structured Contextualized Graphs (Besta et al., CERN, 2024)
- Learning to Reason with LLMs (OpenAI Technical Report, 2024)
- o3 System Card (OpenAI, 2025)
- Rethinking Inference-Time Scaling in Local Computer-Use Agents (Lee & Choi, arXiv:2607.28573, 2026)
- Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., 2023)
- Reflexion: Language Agents with Verbal Reinforcement Learning (Shinn et al., 2023)
- Best-of-N Sampling (Gulrajani & Hashimoto, 2024)
]]>