AI 智能体在运行过程中会遇到一个很现实的问题任务还没有执行完成预算已经耗尽了。这里说的预算可能是大模型 API 的调用费用也可能是平台上购买的 credits还可能是内部系统为单个任务设置的资源配额。很多开发者在搭建 agent 时会把大量精力花在提示词、工具列表和知识库设计上却很少在代码里真正实现预算控制。结果就是一个包含规划、调用、反思、重试的多步任务可能在最后一步因为 token 额度不足而直接中断前面几轮调用的中间结果全部丢失。这篇文章围绕这个具体困境展开当 AI 智能体发现预算不足以支撑完整任务时应该怎么处理。我会先解释预算为什么会失控再给出一个可运行的预算感知 Agent 示例最后讨论降级、部分结果返回和用户确认三种“牺牲”策略。涉及 Dify、Coze 等可视化智能体平台时我会用通用的配置思路来说明不绑定具体版本原理在代码项目和低代码平台之间是相通的。1. 预算困境是什么Agent 为什么会在任务完成前把预算耗尽1.1 从一次失败的知识库问答说起假设用户向一个知识库问答 Agent 提问“对比上季度和本季度的销售数据找出异常变化并生成一份分析报告”。这个任务看上去只有一句话但 agent 执行时往往需要多次调用 LLM。第一次调用LLM 需要规划如何查数据第二次调用LLM 要把数据库返回的原始记录整理成对比结果第三次调用LLM 生成最终分析报告。如果第一次查询结果不完整agent 还会继续查询。每一轮都会产生 token 消耗轮数越多费用越高。在没有预算约束的代码里常见写法是这样的while not finished: response llm_call(prompt) if not response.get(ok): prompt prompt 请重新回答。这段代码只看“任务有没有完成”从不看“已经花了多少钱”。一旦 LLM 返回的结果持续不满足条件while 循环就会反复执行预算在短时间内被快速消耗。最后用户等到的不是分析报告而是一条超出额度限制的报错。1.2 三段式成本规划、工具调用、反思重试AI 智能体的成本不是单一的大模型输入输出费用而是由多个环节叠加出来的。可以拆成三段来理解。成本组成产生时机控制难度规划成本任务开始时LLM 生成执行计划中工具调用成本每次工具返回后LLM 需要理解结果并决定下一步高反思与重试成本结果不满足要求时LLM 重新生成或反复调用工具极高规划成本通常可控因为一次计划只调用一次。工具调用成本取决于任务的复杂度一个真实业务任务可能触发五次甚至十次工具调用。最不可控的是反思与重试成本。LLM 在判断“结果是否满足要求”这件事上并不稳定有时候会连续几次认为结果不完整然后不停地重新生成。每一次重新生成都会重新计算上下文中的全部内容成本会成倍增加。1.3 为什么超时机制解决不了预算问题有开发者会想给 agent 加一个超时时间不就行了。超时确实可以防止任务无限循环但它控制的是时间维度而不是费用维度。同一个任务用更强的模型可能在 10 秒内花掉 1000 credits用更弱的模型可能在 60 秒内只花掉 100 credits。只看超时时间无法区分这两种情况。更麻烦的是有些 agent 会在超时前刚好完成两三轮不必要的重试把预算消耗掉一大半却只返回一个不完整的结果。预算控制需要专门的数据结构记录总量、记录每次消耗、在执行前判断剩余额度、在执行后扣减实际费用。这些是超时机制无法替代的。2. 预算感知 Agent 的核心设计总量控制、分步限额与降级策略2.1 预算模型的关键参数要在代码里实现预算控制第一步是定义预算模型。不要只用一个数字表示总额真正可用的是一个包含多个参数的对象。参数含义示例值参数影响total_budget单个任务的总预算10000 credits超过后必须停止step_budget_limit单次 LLM 调用的预算上限500 credits防止单步调用耗尽全部预算estimated_cost子任务的预估成本200 credits在执行前判断是否继续reserve_ratio保留缓冲比例0.2为收尾阶段保留空间fallback_policy预算不足时的策略partial / confirm / fail决定返回部分结果还是抛错total_budget 是最终底线。step_budget_limit 解决的是单次调用失控的问题。reserve_ratio 很关键它让 agent 在执行过程中始终保留一部分预算用来完成结果汇总和最终回复。没有缓冲的 agent 会出现一种情况前面的步骤都成功了最后一步生成报告时预算不足整个任务功亏一篑。2.2 预算如何参与任务分解预算控制不能等到真正调用 LLM 时才检查而是在任务规划阶段就要参与。任务规划阶段agent 把一个大任务拆成多个子任务。每个子任务都应该带上一个 estimated_cost 字段。这个字段可以由 LLM 生成也可以根据历史任务的平均成本来计算。执行器拿到子任务列表后会依次执行判断剩余预算减去当前子任务的预估成本后是否还能保留缓冲。如果可以执行子任务并记录实际成本。如果不行进入降级策略不再发起新的 LLM 调用。执行完一个子任务后重新计算剩余预算。全部子任务执行完后用保留的缓冲预算生成最终结果。这个流程把预算从“事后统计”变成了“事前判断”。agent 不会等到预算耗尽才被迫停止而是在还剩一部分预算时就主动决定如何收尾。2.3 三种预算耗尽场景的决策矩阵预算不足并不只有一种表现需要区分三种场景分别制定策略。场景剩余预算表现推荐策略正常完成剩余预算大于 0足够完成最终汇总返回完整结果中途预算不足剩余预算大于 0但不足以完成后续所有子任务执行降级优先完成关键子任务预算即将归零剩余预算小于单步预算上限停止新调用整理已有结果并返回所谓“牺牲困境”本质就是在这里做取舍。当预算不足以支撑完整任务时程序员必须提前定义好哪些子任务可以被牺牲哪些子任务必须保留。一个常见做法是给子任务增加 required 字段。required 为 true 的子任务必须完成required 为 false 的子任务在预算不足时可以跳过。3. 用 Python 实现一个最小预算感知 Agent3.1 项目结构与依赖这一节用 Python 实现一个最小闭环示例。结构如下budget_agent/ ├── budget.py # 预算模型 ├── agent.py # 预算感知执行器 ├── run_demo.py # 运行入口 └── logs/ └── agent.log # 运行日志示例依赖很轻只需要 Python 3.10 以上的环境。真实的 LLM 调用部分我会抽象成函数你可以替换为 OpenAI SDK、内部大模型网关或任意兼容接口。先跑通预算控制逻辑再接入真实模型。3.2 预算模块不超支是一切控制的前提预算模块只需要做两件事记录已消耗、在执行前判断是否可以继续。from dataclasses import dataclass dataclass class Budget: total: float spent: float 0.0 reserved_ratio: float 0.2 property def remaining(self) - float: return self.total - self.spent def try_spend(self, amount: float) - bool: if self.remaining amount: return False self.spent amount return True def can_afford(self, amount: float) - bool: reserve self.total * self.reserved_ratio return self.remaining - amount reservetry_spend 保证任何情况下已消耗金额都不会超过总预算。can_afford 则是执行前的判断它要求执行完这一次调用后剩余预算仍然要大于等于保留缓冲。这里要强调can_afford 用的是“剩余预算减掉本次预估”而不是直接比较“剩余预算是否大于本次预估”。很多初级实现会犯这个错误导致当前这一步能跑通但下一步没有预算做结果汇总。3.3 任务分解为每个子任务准备预估成本执行器在运行时需要拿到子任务列表。为了示例清晰plan 方法直接构造子任务真实项目可以改成让 LLM 输出 JSON 计划再通过 Pydantic 转换成结构体。from dataclasses import dataclass from typing import Callable dataclass class SubTask: name: str prompt: str estimated_cost: float required: bool True class BudgetAwareAgent: def __init__( self, budget: Budget, llm_call: Callable[[str], dict], verbose: bool True, ): self.budget budget self.llm_call llm_call self.verbose verbose def plan(self, task: str) - list[SubTask]: # 实际项目中可以让 LLM 输出 JSON 计划这里直接返回固定结构 return [ SubTask(search_data, 查询上季度和本季度销售数据, 200), SubTask(analyze, 分析数据中的异常变化, 300), SubTask(report, 生成最终分析报告, 400), ]子任务里的 estimated_cost 是预估成本不是实际成本。它的作用是在执行前帮助执行器做决策必须允许出现误差。3.4 执行器检查、扣减、降级一体完成执行器的核心是循环遍历子任务并在每个子任务执行前做预算检查。def run(self, task: str) - dict: subtasks self.plan(task) results {} for sub in subtasks: if not self.budget.can_afford(sub.estimated_cost): self._log(f预算不足无法执行子任务{sub.name}) return self._fallback(subtasks, results, sub) response self.llm_call(sub.prompt) cost float(response.get(cost, 0)) if not self.budget.try_spend(cost): self._log(f实际消耗 {cost} 后预算超支停止继续执行) results[sub.name] response.get(content, ) return self._fallback(subtasks, results, sub) results[sub.name] response.get(content, ) self._log( f完成 {sub.name}消耗 {cost}剩余 {self.budget.remaining} ) return {status: success, data: results}fallback 方法体现了预期的“牺牲策略”def _fallback( self, subtasks: list[SubTask], results: dict, failed_sub: SubTask, ) - dict: if failed_sub.required: return { status: partial, message: 关键子任务未完成原因预算不足, data: results, } # 非关键子任务直接跳过继续尝试后续任务 if self.budget.remaining self.budget.total * self.budget.reserved_ratio: self._log(f跳过非关键子任务{failed_sub.name}) for sub in subtasks[subtasks.index(failed_sub) 1:]: if sub.required and self.budget.can_afford(sub.estimated_cost): response self.llm_call(sub.prompt) cost float(response.get(cost, 0)) if self.budget.try_spend(cost): results[sub.name] response.get(content, ) self._log(f完成 {sub.name}消耗 {cost}) return {status: partial, data: results} return {status: partial, message: 预算不足, data: results}这段代码体现了两个关键设计。第一非关键子任务可以在预算不足时被跳过但关键子任务必须执行到底。第二跳过一个子任务后agent 仍然会尝试完成后续的关键任务而不是直接放弃。这就是“牺牲一部分保全更重要的一部分”的工程化表达。3.5 运行示例与日志输出run_demo.py 里模拟一个 LLM 调用返回固定内容和成本from budget import Budget from agent import BudgetAwareAgent def mock_llm_call(prompt: str) - dict: # 替换为真实 LLM SDK 调用 return {content: f对{prompt}的处理结果, cost: 300} budget Budget(total1000) agent BudgetAwareAgent(budgetbudget, llm_callmock_llm_call) result agent.run(对比季度销售数据并生成报告) print(result)运行后日志大致如下[INFO] 完成 search_data消耗 300剩余 700 [INFO] 完成 analyze消耗 300剩余 400 [INFO] 预算不足无法执行子任务report [INFO] 关键子任务未完成原因预算不足这个结果说明整个执行器已经能感知预算并在预算无法覆盖后续任务时提前收尾。真实项目中你需要把 mock_llm_call 替换成真实调用的同时从返回对象中取出实际的 token 消耗和费用。4. 在可视化智能体平台上如何落地预算降级逻辑4.1 低代码平台的预算控制现状代码项目可以自由实现预算对象和检查逻辑但 Dify、Coze 这类可视化智能体平台的预算控制能力通常弱一些。平台更擅长设计节点编排、知识库检索、工具调用对费用的细粒度控制往往要依赖平台自带的企业版配额功能。这不代表平台项目无法实现降级策略。常见的平台节点类型里条件判断、错误处理和变量存储是标配。这三个能力组合起来可以在没有代码的情况下模拟一套简化的预算感知流程。4.2 用条件判断和失败分支模拟降级以常见平台的节点思路来说可以把预算设计成一个变量在每个 LLM 节点之后累加已消耗的 credits。然后在下一次 LLM 调用之前插入一个条件判断节点判断逻辑 if remaining_budget next_step_estimated_cost: 进入降级分支 else: 进入正常执行节点降级分支可以再拆成两条路径。一条路径是整理已有结果生成一个“任务部分完成”的最终回复。另一条路径是调用一个更便宜的模型使用精简 prompt 快速生成摘要尽量保住最终结果的可用性。在 Dify 这类平台上如果遇到文件上传后识别内容的场景也是同样的思路。文件解析节点负责把内容提取出来LLM 节点负责生成摘要或回答问题。如果上游解析完成后系统判断剩余预算不足可以让后续节点走“仅返回文件解析结果”的分支而不是强行消耗大量 token 做全文总结。4.3 多智能体协作时的预算传递多智能体系统里预算问题会更复杂。每个子智能体如果都按自己的总预算执行总成本可能超过任务协调者能接受的上限。推荐的做法是任务协调者持有总预算在分配子任务时同时下发子预算。任务协调器 1. 接收总预算 5000 credits 2. 分解任务分配子预算数据查询 1500分析 2000报告 1500 3. 将子预算传给对应子智能体 4. 子智能体执行后返回实际消耗 5. 协调器汇总剩余预算决定是否继续子智能体内部也要有一套同样的预算检查逻辑不能把希望寄托在协调器身上。因为一个子智能体的工具调用次数可能很多如果没有单步限额它可能在一次内部循环里就把自己的子预算花完。维度单 Agent多 Agent预算来源一个全局预算对象协调器持有总预算下发子预算超支影响当前任务失败可能拖垮整个协作流程控制位置执行器内部执行器 任务分发层降级复杂度中等较高需要汇总各子智能体的剩余预算5. 常见问题排查从日志倒推预算失控的根因5.1 预算耗尽相关问题的排查表实际项目中预算问题往往不是“突然出现”而是“一直都在只是日志里没有记录”。排查时建议按这个表格逐项核对。问题现象可能原因检查方式处理建议任务直接报 429 或配额不足预算限额在 API 网关前置层生效查看 API 控制台用量和账户配额提升账户额度或降低任务预算配置任务中途停在某一步单步调用超时或单步预算不足查看日志中最后完成的步骤和当时剩余预算调大 step_budget_limit或优化该步骤 prompt预算消耗远超预估存在重复循环调用统计同一提示词出现次数增加循环次数上限和去重逻辑返回空结果但费用已经产生异常直接抛出没有保存中间结果检查执行器是否有异常兜底逻辑在 finally 或异常分支中持久化 results剩余预算充足但任务停止误把 estimated_cost 等同于实际成本打印每个子任务的预估与实际消耗将预估逻辑改为基于历史实际消耗的平均值5.2 从重复日志识别异常循环异常循环通常有很明显的日志特征。如果日志里连续出现类似内容就要警惕[INFO] 调用 search 工具cost120 [INFO] 结果不完整重新生成cost205 [INFO] 结果不完整重新生成cost190 [INFO] 结果不完整重新生成cost230这种模式说明 agent 一直认为结果不满足要求于是反复重新生成。根因可能是工具返回的内容本身有噪音也可能是 prompt 里没有给出足够明确的完成标准。排查时可以先用命令统计日志中的重复次数grep 重新生成 logs/agent.log | wc -l如果数量超过 3 次基本可以判定存在非预期循环。修复方式是给执行器增加一个 max_iterations 参数并在循环体里检查当前重试次数。同时要检查工具返回的原始内容是否过长因为 prompt 变长后每次重试的 token 成本会显著上涨。5.3 预估成本失效后的动态校准预估成本很难一次写准。一个简单的动态校准方法是把每个子任务最近 N 次的实际成本存下来用平均值作为下一次的预估。estimate_store { search_data: [185, 210, 190], analyze: [320, 305, 340], } def estimate(name: str) - float: costs estimate_store.get(name, [200]) return sum(costs) / len(costs)每次任务执行后把实际 cost 追加到对应列表。当数据量足够时预估会逐渐逼近真实水平。这样可以减少因为预估过低导致的提前收尾也减少因为预估过高导致的不必要降级。6. 生产环境落地预算控制最佳实践与检查清单6.1 学习环境与生产环境的预算配置差异示例代码适合在本机快速验证逻辑直接拿到生产环境会遇到很多差异。最明显的就是预算值不该写死在代码里而应该从配置中心或环境变量读取。同样日志输出也不应该只打到控制台生产环境需要结构化日志方便接入监控和告警系统。维度学习环境生产环境预算来源代码里写死配置中心、环境变量日志输出控制台打印JSON 结构化日志 指标采集异常处理直接抛错优雅降级 结果持久化预估成本写死常量基于历史记录动态计算告警无剩余预算低于阈值时通知负责人生产环境建议对每个任务设置多级预算全局预算、用户预算、任务预算。全局预算防止所有用户的总消耗失控用户预算防止单个用户占用过多资源任务预算决定单个 agent 任务能走多远。三层预算之间的优先级是只要有一层超限任务就必须停止或降级。6.2 发布前检查清单把一个预算感知 Agent 发布到生产环境前可以按下面的清单逐项确认。总预算、单步预算、保留缓冲是否都已配置。是否有最大 LLM 调用次数限制。预算不足时是否返回部分结果而不是空结果。中间结果是否持久化能否在任务中断后恢复。是否记录了每次 LLM 调用的模型、token 数量、费用和时间。剩余预算低于阈值时是否有告警。用户级预算、任务级预算、全局预算是否都生效。预估成本是否来自历史数据而不是拍脑袋写死。降级策略是否经过测试确认不会返回误导性结果。是否有回滚方案比如把预算配置快速调整为双倍或停用。这份清单的核心思想是预算控制不是单点检查而是一条完整链路。从任务开始前、执行中、到最后收尾每个环节都要有对应的控制动作。6.3 扩展方向多级预算、工作路由与成本质量权衡预算控制并不只是为了省钱它还可以成为 Agent 运行时路由的依据。一个很实用的扩展是预算感知的模型选择剩余预算充足时对复杂任务使用高能力大模型。剩余预算不足时使用小模型或精简 prompt 完成低难度子任务。文档解析、简单分类、关键词提取这类任务可以优先分配给低成本模型。这种策略把预算从“限制条件”变成“调度信号”让 agent 在有限的资源里尽量完成更多有价值的工作。另一个扩展方向是结果持久化。把每一步的中间结果写入数据库或对象存储预算耗尽时agent 可以从上次断点继续执行而不需要重新跑一遍前面的步骤。预算控制不应该被当成事后补救。真正有价值的做法是把预算理解成 agent 执行的约束条件从任务分解阶段就参与决策。一个最简单的判断标准如果预算耗尽程序不应该只是抛出异常而是应该保留已完成的工作明确告诉用户哪些部分完成了、哪些部分因为预算被牺牲了。做到这一点预算控制的设计才算闭环。下一步你可以在自己的 agent 里先加上总预算和单步预算两个配置再观察日志里每一次 LLM 调用的成本分布。多数情况下仅这一步就能避免最严重的预算失控。