上周帮团队调试一个知识库问答智能体时我遇到了一个很典型的“预算耗尽”场景。用户问的是“新员工入职需要完成哪些培训请结合信息安全制度和财务报销规定给出完整清单”。Agent 先调用了文档检索又查了三个知识库接着开始生成了两轮“中间结论”然后尝试调用内部系统做验证。一切看起来都很正常直到最后一步控制台跳出一条错误预算耗尽任务终止。我翻开日志一看真正回答用户问题的那一步根本没执行完可 token 消耗已经接近上限。大部分预算被“总结中间结论”“格式化输出”“反复生成礼貌性的过渡文本”吃掉了。这不是个例。AI 智能体在预算耗尽前确实会进入一种“牺牲困境”任务还没做完资源却不够了系统必须决定先砍掉什么保留什么。很多团队遇到这个问题时第一反应是加预算、换大模型、买更多并发额度。但我自己的判断是预算耗尽不是账上没钱的问题而是智能体设计里的优先级问题。好的智能体不是不做牺牲而是在任务开始前就定义清楚“什么最值得保留”。1. 先搞清楚智能体里的“预算”到底指什么1.1 预算不只有 token还有时间、步数和上下文很多人一提到预算首先想到的是 token 数量。确实在大模型 API 的计费逻辑里输入 token 加输出 token 是最直观的资源。但对一个真正会调用工具、轮询状态、循环处理子任务的智能体来说预算远比 token 复杂。我一般会把智能体的预算拆成五类预算类型代表资源耗尽后的典型表现Token 预算输入输出 token 总量输出被截断、生成质量下降、任务中断调用次数预算API 请求次数或平台配额后续工具无法调用直接报错时间预算单轮执行的最大秒数超时终止返回部分结果上下文窗口上下文长度上限早期信息被遗忘模型“忘记”关键约束步骤次数预算Agent 可执行的最大迭代步数陷入循环、反复重试、无法正常终止理解这五点很重要因为“预算耗尽前的牺牲”往往不是某个单一指标到达上限而是多个预算同时逼近临界。比如一个 Agent 在检索文档时返回了超长内容token 预算先吃紧接着它又要调用下一个工具但调用次数也已经接近上限这时候如果再拖几秒时间预算也会耗尽。所以真正的预算困境不是“差一个 token”而是“所有资源都在同一个时刻不够了”。1.2 预算耗尽的真实信号往往不是报错很多智能体平台在预算耗尽时不会直接抛异常而是会给你一个看起来还算完整的输出。比如回答只覆盖了问题的一半后半段被截断。关键结论放在最后一步但最后一步没有执行。工具调用失败后Agent 没有重试而是自己“编”了一个结果。多轮对话中模型把系统最初的约束给忘了。这些不叫正常输出叫“隐性预算耗尽”。实际开发中这种隐性耗尽比显性报错更麻烦因为它不会阻断流程却会污染下游数据。所以处理预算耗尽的第一步不是写更长的提示词而是先在日志里把预算状态完整记录出来知道哪些资源在被谁消耗。注意单次跑通并不代表预算管理合理。真正需要关注的是在最坏输入下系统是否还能保住核心结果。2. 为什么智能体总把预算耗在最不值得的地方2.1 默认行为是“尽可能完整”而不是“优先重要”我见过太多新手设计的 Agent第一版提示词永远写着“请完整地、详细地回答用户问题”“请逐步分析并给出所有相关细节”。这种默认行为非常危险。大模型本身有“尽量满足用户指令”的倾向。如果你告诉它要完整、详细它就会在检索到任何一点相关信息后先输出大段铺垫再用冗长的中间步骤展示“思考过程”。在预算有限的前提下“完整”是最大的敌人。这里不是说要让 Agent“不完整”而是要先定义“这次任务必须成的样子”。如果没有最小成功标准Agent 会把精力平均分配给所有子任务结果就是每一步都做了一点但最重要的一步没有足够的预算。2.2 多智能体协作会放大预算浪费在多智能体系统里预算浪费会更严重。每个子智能体都会消耗自己的 token 和调用次数但全局预算往往只有一个总闸。常见问题包括子智能体之间互相传递完整上下文而不是传递摘要。每个子智能体都重新读取一次原始文档导致重复计费。协调者要把所有子结果拼在一起结果协调者自己的输出 token 占了大头。某个子智能体失败后协调者反复重试没有设置重试上限。举例来说一个“销售线索分析智能体”可能包含三个子智能体客户资料提取、产品推荐、邮件生成。如果产品推荐子智能体为了展示“逻辑严谨”把产品规格表全部复制进上下文那么预算会迅速被消耗等轮到邮件生成时预算已经不够用了。这跟“预算耗尽后的牺牲困境”有直接关系多智能体之间的优先级别不够清晰导致预算被不重要的中间流程抢走。2.3 上下文是一条隐形预算即使 token 总量很高上下文窗口本身也是一个限制。上下文越长模型处理速度越慢且早先的信息越容易被“淹没”。一个很常见的场景Agent 连续执行了五步工具调用每步都返回了一长串 JSON。到第六步时模型需要参考第一步返回的结果但它已经把注意力放在最近的几步上第一步的信息被“忘记”了。这里的本质不是“模型不行”而是上下文预算没有做压缩管理。每走一步都应该把旧结果摘要化或者用结构化存储替代直接堆在上下文里。否则即使 API 还允许继续调用模型的决策质量也已经严重下降。建议每次工具调用后先问自己“返回结果里真正需要被模型记住的核心字段是什么”把不必要的内容从上下文里清掉才是真实的预算优化。3. 预算耗尽前的“牺牲设计”三步法3.1 第一步先定义“这次任务必须成的样子”在写任何 Agent 流程之前先写一句话如果只有一次机会这个智能体至少要交付什么这句话就是最小成功标准。它不能是“回答用户的问题”这么宽泛而应该是“在最多检索 3 篇文档后用不超过 200 字准确回答用户问题并给出文档编号”。定义最小成功标准有几个好处可以倒推需要多少预算。判断哪些步骤属于“核心链路”。当预算不足时知道该放弃什么。我在实际操作中一般会用一个问题来检验标准是否够具体如果这一步被砍掉用户会不会认为这个 Agent 没有完成工作如果会那它就是核心步骤如果只是“更好”那它就不是。3.2 第二步给任务分三档必做、可降级、可跳过定义完成标准后把整个任务拆成几个子任务并按重要性分成三档档位含义预算不足时的默认策略必做直接决定任务是否成功优先分配预算最后才降级可降级影响体验但不影响核心结果简化输出、跳过验证、使用缓存结果可跳过锦上添花与目标弱相关直接不执行记录状态区分“可降级”和“可跳过”是这套方法的关键。可降级的意思是这个步骤要做但可以降低质量。比如“生成引用来源”可以不生成完整文档链接只返回文档编号比如“校验用户输入”可以只做正则校验不做语义校验。可跳过则意味着这个步骤在预算不足时可以完全不做。比如“生成一份精美 PDF”或“输出可视化图表”。这些功能对用户体验有帮助但就算没有核心答案也已经给出了。3.3 第三步为每档设计默认策略分类之后要让系统在预算不足时自动切换策略。这里不是靠模型自己“临场发挥”而是在代码层面预设好动作。以知识库问答智能体为例必做检索知识库 → 提取关键条款 → 生产最终回答。可降级引用来源。预算充足时返回完整路径预算不足时只返回文档标题。可跳过生成排版好的 Markdown 表格。预算不足时直接输出纯文本。对应策略就是一旦检测到剩余预算低于阈值系统自动把“生成表格”步骤跳过把“引用来源”降级成“文档标题”把所有预算集中到最终回答上。3.4 一个示例从“报错中断”到“主动降级”回到开头的知识库问答场景。如果按照三步法重新设计核心目标回答“新员工入职培训清单”必须包含信息安全制度和财务报销规定两者的要点。可降级给出每个要点的完整出处。可跳过输出一段总结性的开场白。那么当预算剩余 20% 时Agent 应该停止继续检索新文档立即基于已有信息生成回答如果还需要引用来源就只附文档编号开头那段“根据您的提问我查阅了相关制度……”直接不写。这样用户最终得到的是一个核心答案而不是一个报错。这个过程就是“牺牲设计”——提前规划好牺牲什么比最后被动中断要可靠得多。经验先跑通最小链路再增加“完整表达”和“富文本输出”。顺序反了后面会被预算问题反复折磨。4. 工程落地给 Agent 装上预算仪表盘4.1 核心接口用量读取、阈值判断、降级动作要让智能体具备“预算感知”最好在 Agent 主循环里加入三个模块用量读取记录每次大模型调用的输入输出 token、API 调用次数、耗时。阈值判断根据剩余预算状态切换执行模式。降级动作在预定义的目标函数中决定保留哪些步骤、简化哪些步骤、跳过哪些步骤。下面是一个常见的伪代码结构不是某个具体平台的实现但思路可以通用# 伪代码预算感知的 Agent 主循环 budget Budget(token_limit10000, step_limit8, time_limit30) for step in agent_loop(): budget.record_step() if budget.need_degrade(): planner.mode DEGRADE planner.keep_required_only() if budget.need_skip(): executor.skip_optional() if budget.exhausted(): return partial_result( successFalse, reasonbudget_exhausted, partial_outputplanner.required_action() )这段代码的关键不是语法而是顺序先判断是否降级再判断是否跳过最后判断是否耗尽。也就是说系统要尽可能在预算耗尽之前就已经把“核心答案”准备好了而不是等到耗尽后返一个空结果。4.2 关键日志与指标没有数据就无法优化预算。建议至少记录以下指标指标说明用途每步 token 消耗输入 输出 token 数定位最大消耗点每步调用耗时从请求到返回的秒数定位慢步骤工具返回结果长度字符数或 token 数判断是否需要压缩当前执行模式正常 / 降级 / 跳过复盘降级决策是否合理最终成功标准达成情况是否完成必做项验证牺牲策略是否正确有了这些日志就可以在每次任务后回看预算到底被哪一步吃掉了有没有一条本可以更省的分支然后针对性地优化。4.3 常见平台的落地配置如果你是在 Dify、Coze 这类智能体开发平台上搭建 Agent不一定需要自己写底层代码但同样可以配置预算相关参数设置最大迭代步数避免死循环。设置单次请求模型不使用过大的上下文模型来跑简单任务。在知识库检索时限制召回数量比如从 5 条改成 3 条。在多人协作场景中给每个子智能体分配独立的 token 上限而不是共享一个总预算。对工具返回结果做“结果摘要”节点只把关键字段传给下一步。这些配置看起来简单但能减少大多数无效消耗。4.4 排查链路先解决“预算被谁吃掉”如果智能体还是会在预算耗尽后牺牲核心结果不要急着加预算。按这个顺序排查看现象是报错中断还是结果不完整是否出现循环看输入用户问题是否过长检索文档是否过多工具返回是否过重看环境API 版本、平台配置、模型上下文窗口是否匹配看参数最大步数、超时时间、token 上限、并发数设置得是否合理看日志找出单次任务中 token 消耗最高的步骤看它是不是“必做”步骤。大部分预算问题最后都能在日志里找到答案。真正要警惕的是某些步骤消耗非常大但并没有给最终回答带来增量信息。这些步骤就是预算里的“黑洞”。5. 预算困境的长期解法让“牺牲”变成产品策略5.1 从“追预算”到“预算规划”很多团队等到开发后期才意识到预算问题然后把所有精力花在“压缩 token”上。这其实是被动应对。更长期的做法是在设计智能体流程时就把“预算分配”当成一个功能来对待。比如在任务开始前先评估用户诉求的复杂度选择不同的执行模板。对不同类型的用户诉求设置不同的预算上限。允许用户手动选择“快速回答”和“深度回答”两个模式。把“降级行为”参数化而不是写死在提示词里。这样做的好处是智能体面对简单问题不会浪费预算面对复杂问题时也不会因为预算不足而失守。预算不再是一个限制而是一个可调节的产品开关。5.2 这个方案适合谁不适合谁这套“牺牲设计”方法更适合任务路径复杂、需要多步调用和工具组合的智能体场景比如知识库问答、数据分析助手、客服工单分类、销售线索处理等。但如果你的智能体只是做简单的单轮翻译或文案生成其实不需要复杂的预算分级只要设置最大 token 数和超时时间就够了。任务越复杂预算管理的收益越大任务越简单优先级设计的复杂度反而会拖累体验。另外如果是法律、医疗、金融等对结果准确性要求极高的专业场景我的建议是再好的降级策略也不能替代人工复核。预算不足时宁可返回“未能完成”并要求用户增加补充信息也不要生成一个半吊子的结论让用户误用。5.3 长期维护把每一次“牺牲”都当成一次需求输入预算分布会随着模型版本、知识库规模、用户提问方式的变化而变化。所以预算策略不是一次性配置而是一个需要持续迭代的机制。我一般会每两周复盘一次日志重点看三件事哪些步骤被降级或跳过了降级后用户是否还满意核心必做项有没有因为预算不足而失败失败原因是什么有没有哪类用户提问总是触发预算告警能不能通过前置引导避免把每一次“牺牲”都记录下来下次设计新智能体时就能直接复用。这比每次都从零开始调参有效得多。最终AI 智能体在预算耗尽前的“牺牲”困境本质上是在问一个问题当资源不够时你希望这个智能体优先守护什么答案不在模型参数里而在你的任务设计里。优秀的智能体不是永不耗尽预算而是即使在预算即将耗尽时也知道怎么保住那个最值得被保住的结果。