智能体任务复杂度估算:执行前先规划 Token 预算
两个智能体收到同一条用户消息。一个在 3 秒内用 400 个 Token 完成任务;另一个进入 Reflexion 循环,耗尽 40,000 个 Token,在任务中途触及上下文限制,产出一个半成品答案。两个系统都没有预测到会是哪种结果。这不是边缘情况——这是智能体在没有对任务深度建立任何模型的情况下启动任务时的默认行为。
基于 LLM 的智能体在执行前对任务范围没有天然感知。用自然语言读起来简单的请求可能需要十几次工具调用和多轮规划;听起来复杂的请求可能只需一次查找即可解决。没有执行前的复杂度估算,智能体就会盲目提交资源:随着轮次历史积累,上下文窗口呈二次方填满;规划开销主导执行时间;等到系统检测到问题时,导致问题的早期决策已经无法撤销。
成本不对称是真实且可量化的。单次 LLM 调用约需 800ms;十轮多轮推理循环消耗的 Token 是单次的五十倍。不加限制时,解决软件工程任务的生产级编码智能体每次任务可能花费 5–8 美元。由于历史积累,上下文随每一轮加倍增长,形 成二次方增长,任何提示工程技巧都无法完全抑制。与此同时,所有经过测试的前沿模型随上下文长度单调退化——退化在达到名义限制之前就已开始,当相关信息位于窗口中间而非边界时,准确率下降 20–30 个百分点。
复杂度估算是团队反复跳过的架构修复方案,因为在基础设施账单到来之前,它感觉像是过早优化。
为什么智能体会在早期犯下不可逆的错误
对跨网页、具身、操作系统和数据库任务的 3100 多条智能体轨迹的研究发现了一致的非线性失败模式:智能体在小任务深度下表现出部分鲁棒性,然后在超过特定领域阈值后骤然转变为近乎系统性的失败。随着视野长度增加,失败构成也发生变化。短任务主要因环境错误和指令误解而失败。长任务则因规划崩溃和历史错误积累而失败——这是一种根本不同的失败模式,需要不同的补救措施。
不可逆性问题有别于上下文耗尽。智能体会做出"早期的短视承诺,这些承诺随时间系统性放大且难以恢复"。一旦智能体在前几个决策中偏离最优执行路径——因为它低估了任务范围并承诺了一个浅层计划——恢复该轨迹在实践中几乎是不可能的,除非重新开始。一个决定通过检查三个文件而非三十个来解决重构任务的编码智能体,已经承诺了一个会产生自信但不完整答案的计划。它直到深入执行后才会发现错误,而此时扭转方向意味着丢弃大部分已积累的上下文。
这就 是为什么预先估算比更好的重试逻辑或更大的上下文窗口更重要。在失败模式启动后修复成本高昂。防止错误计划从一开始就被提交,花费的只是推理预算的一小部分。
在第一个 Token 之前对复杂度分类
实用方法是在任务接收时、任何推理推断触发之前估算复杂度的分层路由系统。三层模式已在生产 AI 工程团队中趋于收敛:
- 第一层处理简单查找和单步检索,使用直接 LLM 调用。目标延迟:P50 低于 500ms。
- 第二层处理复杂推理,使用编排器-工作器设置和有限反思循环。目标延迟:P50 2 秒,P95 4 秒。
- 第三层处理深度多领域任务,使用完整多智能体编排。目标延迟:P50 3 秒,P95 6 秒。
路由决策本身应该轻量。单次 LLM 调用在复杂任务上的准确率上限为 60–70%;达到 95%+ 需要延长推理时间。路由层的工作是在将推理预算提交给错误方法之前,识别任务需要哪个层级。
一种有原则的路由方法使用基于变分自编码器(VAE)训练的轻量分类器。VAE 将每个传入查询编码为潜在难度表示,并生成归一化难度分数。该分数随后驱动模型选择(使用哪个 LLM)和工作流深度(允许多少推理步骤)。该分类器的训练成本约为 2 美元——相比之下,复杂基准测试上每次无约束推理查询的成本超过 1.66 美元。在规模上,分类层在前几百次查询后就能收回成本。
对于代码智能体,静态分析提供无需 任何 LLM 调用的执行前复杂度信号:文件数量、模块间依赖扇出、抽象接口的存在。这些信号可以在主推理链开始之前为复杂度估算提供初始依据。
Token 预算作为一等智能体状态
一旦有了复杂度层级,就需要在执行过程中强制执行。两种机制有强有力的实证支持。
预算追踪器注入:将剩余工具调用或 Token 预算作为实时计数器插入智能体的提示中,在每一步更新。这听起来简单得令人惊讶,但效果出奇地好。能看到剩余预算的智能体会调整策略:在预算低时停止广度优先探索,更早整合部分结果,并跳过低风险子任务的验证步骤。研究表明,与无约束基线相比,该模式实现了 31.3% 的成本降低和 40.4% 的工具调用减少,同时提高了困难研究任务的准确率。无需微调。这是目前可用的最高杠杆、最低努力的可靠性改进之一。
复杂度条件深度限制:根据路由时分配的复杂度层级,为每个任务设置推理轮次上限,而非全局上限——而是从前期估算得出的每任务上限。第一层任务最多 3 轮,第三层任务最多 20 轮。这种动态轮次限制形式在保持解决率的同时实现 24% 的成本降低,因为它防止了简单任务陷入不必要的反思循环,同时不人为限制需要更多空间的复杂任务。
这些机制与简单速率限制的关键区别在于,它们向智能体传达约束而不是静默截断执行。知道还有 5 轮的智能体会以不同于被中途打断的方式进行压缩。知情适应比硬性停止产生更好的输 出。
计划模板:缓存结构而非答案
一个不那么明显的优化是计划级缓存。标准语义缓存以输入相似性为键缓存模型输出——当用户提出近乎相同的问题时可降低成本。计划缓存的工作方式不同:它缓存执行结构(要调用的工具序列、中间步骤、依赖排序),剥离实体名称和数值等特定上下文细节。
当新任务到来时,关键词提取识别是否有缓存的计划模板适用。如果适用,智能体执行模板而不是从头重新推导计划。这特别有效,因为规划是 LLM 推理最昂贵且最确定性的阶段——同一类任务往往以相同方式分解,即使表面细节不同。
性能数字令人印象深刻:在五个基准测试中,计划缓存实现了 50.31% 的平均成本降低和 27.28% 的延迟降低,同时保留了 96.61% 的准确率。缓存操作本身只增加 1.04% 的开销。对于运行重复工作流的团队(夜间数据管道、重复出现的客户支持模式、标准化研究查询),这是可用的 ROI 改进中最强的之一。
约束执行深度的分解模式
任务分解是长期架构修复。目标是将任务分解为每个都具有有界、可预测上下文需求的子任务——而不是允许单个智能体在无界执行视野中积累历史。
分层技能分解将任务分解为高级技能 (搜索、编码、写作),每个由具有独立隔离上下文窗口的专门子智能体处理。规划智能体负责分解;执行智能体在严格范围内执行。这防止了跨步骤的上下文积累——每个子智能体在其分配的范围内从新开始。这也使系统更易调试:可以追踪哪个分解决策导致了哪个执行结果。
基于 DAG 的任务建模将任务表示为有向无环依赖图。节点是子任务;边是依赖关系。拓扑排序确定并行执行机会。独立子任务同时运行,减少总延迟。依赖子任务顺序运行,但具有范围化上下文。DAG 结构也使复杂度在设计时可见:分解为具有 20 个节点、最长路径为 8 跳的图的任务客观上比具有 3 个节点、路径为 2 的任务更复杂。
微任务分解进一步推进,将执行分解为每个都具有步骤本地上下文的细粒度"微任务"。每个微任务都小到足以在有界 Token 预算内解决。编排器组合微任务结果,而不是维护单个累积上下文。这种方法通过限制每个子任务成本来强制执行 SLA,使总任务成本成为分解深度的函数,而非无约束积累。
关于多智能体分解的一个实用注意事项:45% 规则。当任务上的基线单智能体性能低于 45% 时,添加智能体会带来最大价值。一旦单智能体性能超过 80%,额外智能体会引入协调噪声而非准确率提升,并降低 SLA 可预测性。如果你的单智能体已经可靠地解决某类任务,将其分解为多个智能体更可能添加失败模式,而不是改善结果。
前瞻而非贪心提交
最近研究中较为反直觉的发现之一是,在长视 野任务上,较小模型配合显式前瞻规划,始终优于使用贪心逐步推理的较大模型。差异不在于模型能力——而在于智能体在提交行动之前是否考虑了未来后果。
具体模式是未来奖励估算:在提交计划之前,智能体生成几个候选方法,并以其预测的任务完成成功率而非即时合理性对每个方法进行评分。这在执行开始时增加了少量规划开销,但防止了主导长视野失败率的不可逆早期承诺。
这有一个实际含义:在复杂任务上花费推理预算的正确地方是开始时的规划质量,而非分布在各执行步骤中。前置推理、有界执行和缓存计划模板都是同一底层原则的变体:做一次廉价的昂贵估算工作,而不是在执行中途以全价发现范围。
构建复杂度预算层
将这些整合成一个生产模式:
- 在接收时:使用轻量启发式或训练好的分类器对任务复杂度进行分类。分配具有关联 Token 预算和轮次限制的复杂度层级。
- 在系统提示中:将剩余预算作为实时计数器注入。在每一步刷新。让智能体自适应。
- 在规划时:在推导新计划之前检查计划模板缓存。如果有模板匹配,执行它。否则,生成并缓存新模板供未来使用。
- 在分解中:使用分层或基于 DAG 的子任务分解来强制执行每个子任务的上下文边界。每个子智能体在范围化窗口内工作;编排器组合结果。
- 对于复杂任务:在提交执行路径之前,用候选方法的前瞻评分预先进行规划。
这些组件中没有一个是单独创新的。大多数生产系统的差距在于,它们没有被组合成一个连贯的执行前估算层——而是在生产事故揭示无约束智能体以新方式变得昂贵之后,被动地逐一添加。
Token 预算设计不是优化,而是可靠性要求。在没有复杂度模型的情况下启动任务的智能体,将以其遇到的任务实际复杂度为比例可预测地失败——而"不可预测的失败率"不是任何工程组织实际上能够应对的 SLA。
- https://arxiv.org/abs/2509.11079
- https://arxiv.org/html/2511.17006v1
- https://arxiv.org/html/2412.18547v5
- https://arxiv.org/html/2506.14852v2
- https://arxiv.org/pdf/2510.04371
- https://arxiv.org/html/2601.22311
- https://arxiv.org/html/2604.11978
- https://arxiv.org/abs/2504.16563
- https://arxiv.org/abs/2508.17196
- https://arxiv.org/html/2504.00294v1
- https://arxiv.org/abs/2307.03172
- https://www.morphllm.com/context-rot
- https://towardsdatascience.com/why-your-multi-agent-system-is-failing-escaping-the-17x-error-trap-of-the-bag-of-agents/
- https://arxiv.org/abs/2512.09897
