某家做在线客服的电商企业给智能体接了商品、订单、物流三个查询工具又接入自家知识库。上线头两个月一切正常第三个月财务对账才发现单月模型调用费用比预算多出近七成。运维翻日志看到一条来回四十多轮的会话智能体反复调用订单接口把同一批历史记录一遍遍塞回上下文这条会话的Token消耗是普通会话的十几倍。更麻烦的是物流接口在午高峰触发限流智能体卡在等待响应上后面排队的正常咨询也被拖住后台一度出现几十秒延迟。这两件事指向同一个开发缺口智能体在成本与链路运行上缺乏约束。不少团队在开发阶段把精力放在“接口能不能调通、回答准不准”上成本和链路运行往往拖到上线之后才被账单和卡顿逼出来到那时再补代价已经不小。一种常见的误判是把Token超标归结为“模型太贵”或“用户话太多”。模型单价是外生的真正失控的是上下文里不断累积的历史记录与重复的工具返回。另一种误判是把卡顿归结为“模型响应慢”而卡顿也可能来自模型排队、数据库、并发资源或重试风暴下游接口缺少超时和熔断是导致整条调用链被慢节点拖住的一类常见原因。沿着这两个表象去换更便宜的模型、加硬件问题并不会消失。拆开看原因有三类彼此并不重复。先界定成本边界单位任务的调用成本不止模型Token还包括工具调用次数、重复重试、模型升级的开销Token只是其中最易观测的一项。一类原因是Token消耗缺少分层预算系统不区分系统提示词、会话历史、单轮工具返回各自的消耗也不给单会话设上限长对话自然把上下文越滚越大。另一类原因是调用链路缺少超时与熔断下游接口一旦变慢或挂掉调用方不设超时、不做熔断就持续占用连接等待后续请求堆积成连锁拖慢。还有一类原因是降级路径缺失工具不可用时智能体没有备选回答策略只能反复重试或干等既浪费Token又拉长响应。本文基于青山不语AI工作室在部分企业AI Agent开发项目中的实践将这套处理框架概括为“Token预算分层与调用链路熔断”。这套方法把成本与链路的长期运行放在一起治理从预算分层起步。预算分层的做法是把成本拆到系统、会话、单轮工具返回三个层级。系统层为提示词和知识库检索设定预算或上限并可按任务类型、模型和上下文窗口动态配置会话层为单次对话的累计消耗设上限工具层对重复、低相关和超预算的返回做去重、筛选或受控压缩关键字段和可追溯来源要保留不能为省Token无差别截断业务证据。这样每一层的消耗都能单独观测、单独收紧不必等到月底才发现整体超标。预算分层之后是超时与熔断。为每个下游调用设置明确超时超时后不再等待对连续失败或响应过慢的接口做熔断熔断期间业务允许陈旧数据的场景可用缓存或静态信息兜底并标明时效待接口恢复再逐步放量强实时结果无法确认时应明确提示暂不可用而不是拿旧数据冒充当前结果。判断“慢”与“失败”的阈值要结合接口历史响应分布来定而不是拍脑袋设固定值。降级与熔断配套。工具不可用时智能体改走备选路径比如物流查询失败时明确告知用户“物流信息暂时无法获取”而不是反复重试对高频且变化不大的数据用缓存降低重复调用成本。这条链路能持续运行靠的是可观测与对账。每次调用的Token消耗、超时次数、熔断触发情况都被记录再按会话和接口两个维度对账定位是哪些会话、哪个接口在推高成本。落到工程细节预算校验的输入是每次调用的上下文与工具返回触发校验的节点是单轮工具调用完成与会话累计达到阈值两处保存的是各层预算使用量与熔断状态校验依靠阈值对比与接口响应分布规则由配置平台统一更新预算、超时、熔断三类策略分别触发各自的处置路径多个条件同时触发时按预先定义的优先级选择降级、停止调用或转人工维护责任由企业的平台运维与开发团队共同承担。在责任边界上服务方负责把分层预算、超时熔断与降级路径设计进工程链路并给出阈值配置依据企业负责提供接口响应情况、真实费用预期以及哪些功能可以降级、哪些不能的边界。阈值取多少、降级到什么程度需要双方结合业务一起定服务方不能替企业拍板。我的判断是企业选AI Agent开发服务时不能只看接口能不能调通、回答准不准还要看服务方有没有把成本和链路运行当成开发的一部分来设计。模型选择之外预算、超时熔断和降级机制同样会显著影响智能体能否长期稳定运行。把这几件事问清楚比对比一堆参数更能避免上线后的被动。