上个月，我们一个电商客服 Agent 的月度 API 账单冲到 2 万元。预算表上的数字是 4000。
财务把截图发到群里时，所有人的第一反应是：是不是谁把 GPT-5 的 key 泄露了？
排查了一整天，LangSmith 上的 Trace 一帧帧回放，才发现问题根本不在模型上。这个 Agent 用的是 Qwen3-Max，单价并不贵。真正烧钱的，是架构设计里埋下的三个坑：死循环重试、上下文无限膨胀，以及多 Agent 协作时的无效转发。
据 AgentInsight 在 2026 年发布的数据，国内已有 54% 的企业在生产环境部署了 AI Agent，但 61% 的企业从未测量过 AI 项目的 ROI。无管控的 Agent 部署后，月度算力成本可直接上涨 5 到 10 倍。我们恰好是那 61% 里的一个样本。
这不是事后复盘报告。我把排查过程、框架配置修正和后续的预算熔断机制，按时间线拆开。如果你也在用 LangChain、AutoGen 或 CrewAI 搭 Agent，以下五个消耗黑洞很可能已经在你的账单里潜伏了。
第一个坑：死循环里的 Token 焚烧炉
客服 Agent 接了一个退货流程。逻辑很简单：用户说“我要退货” → Agent 查询订单状态 → 判断是否符合退货条件 → 生成退货单。
上线第三天，凌晨 3 点到 5 点之间，这个 Agent 消耗了 8000 多个推理调用。Trace 回放显示，有一个订单的状态是“已签收但未入库”，Agent 调用订单查询工具后得到了这个中间状态，然后它做了一个判断：“信息不完整，需要重新查询”。
它查了 47 次。同一个订单，同一个工具，同一个返回值。每一次重试都会把前一次的完整上下文带进去，到第 47 次调用时，Prompt 已经膨胀到 12000 Token。
七牛云在一篇技术实践中提到，很多开发者经历过“一觉醒来，测试环境里的 Agent 因为陷入死循环，一晚上烧掉了几百美金的 OpenAI API 费用”。我们的场景没那么贵，但逻辑一模一样。
修复方案不是在 Prompt 里加一句“不要重复查询”。那没用。我们在框架层加了两条硬约束：
- 工具调用次数上限：每个子任务最多调用同一工具 3 次，超出后直接返回“信息暂时不可用，转人工处理”。
- 状态缓存：同一订单 ID 在一次会话周期内只查询一次，结果写入会话级缓存，后续调用直接读取缓存值。
这两条规则写进 LangChain 的 AgentExecutor 配置里，只加了不到 20 行代码。死循环问题当天清零。
第二个坑：上下文窗口的沉默膨胀
很多人以为上下文窗口大了就可以随便用。Claude 3.5 Sonnet 支持 200K，Qwen3-235B 支持 100K，GPT-5 支持 256K。长上下文确实让 Agent 能处理更复杂的任务，但也制造了一种危险的幻觉：反正窗口够大，历史消息全留着没关系。
我们的客服 Agent 在一次会话中平均处理 8 轮对话。但 Trace 显示，第 8 轮对话的输入 Token 量是第 1 轮的 6.3 倍。不是因为用户问题变复杂了，而是每一轮都把前面所有的工具调用结果、中间推理步骤、系统 Prompt 完整地塞了进去。
这就像你每次翻一页书，都要把前面所有页重新读一遍。
我们在《模型降价后，Agent账单为什么没少》里分析过，API 单价下降会被调用次数和上下文膨胀抵消。这次排查完全验证了这一点。Qwen3-Max 的单价是 GPT-5 的 1/5，但我们的上下文膨胀率把价格优势吃掉了 70%。
修正方案分两步：
- 上下文截断策略：超过 10 轮对话时，只保留最近 5 轮的完整内容，更早的对话压缩为结构化摘要（订单 ID、用户意图、已执行动作）。
- 工具调用结果去重：同一工具的重复调用结果只保留最新一次，旧结果从上下文中剔除。
这两个规则上线后，平均输入 Token 量下降了 42%。月度账单从 2 万降到 1.1 万——还没回到预算线，但已经砍掉近一半。
第三个坑：多 Agent 协作的无效转发税
我们这个客服系统实际上有三个 Agent 在协作：一个意图识别 Agent，一个订单处理 Agent，一个话术生成 Agent。架构设计者的初衷是“各司其职，解耦清晰”。
但 Trace 暴露了一个尴尬的事实：意图识别 Agent 的输出，有 60% 的内容是订单处理 Agent 根本不需要的。比如它会把用户的情绪分析、语气特征、甚至“用户可能是个急性子”这类推断，原封不动地传给下游。
下游 Agent 收到这些信息后，会尝试“理解”它们，消耗额外的推理 Token，然后大概率忽略。
这就是多 Agent 系统的“无效转发税”——A 传给 B 的信息里，只有一部分是 B 真正需要的，但 B 必须读完所有内容才能找到那部分。这个过程每多一层转发，Token 消耗就放大一圈。
据华尔街见闻报道，Nebius 在 Inflection 2026 峰会上指出，Agent 循环执行会放大错误率及成本失控，新一代 AI 云基建需要具备多模型路由和全链路可观测性。我们的多 Agent 架构恰好踩中了这个痛点。
修正方案不是砍掉多 Agent 架构，而是重新定义 Agent 间的通信协议：
- 结构化传递：意图识别 Agent 只输出 3 个字段给下游：
intent（退货/咨询/投诉）、order_id（若已识别）、priority（urgent/normal）。情绪分析、语气特征全部丢弃。 - 下游按需索取：订单处理 Agent 如果需要更多上下文，可以主动回查会话历史，而不是被动接收所有信息。
这个改动让 Agent 间的通信 Token 消耗下降了 67%。
第四个坑：工具选择里的“豪华套餐”
排查过程中还发现一个更隐蔽的问题：我们的订单查询工具，底层调了两个不同的 API——一个实时查询接口（响应快但贵），一个批量导出接口（慢但便宜）。
Agent 在 90% 的场景下只需要查一个订单，但它每次都走实时查询接口。因为工具描述里没有标注成本差异，Agent 的规划模块默认选了“最快”的那个。
这相当于你每次去便利店买一瓶水，店员都帮你叫一辆专车从仓库调货。
修正方案是在工具定义里加入“成本标签”：
tools = [
{
"name": "query_order_realtime",
"cost_level": "high",
"适用场景": "单订单紧急查询",
"单次调用预估Token消耗": 800
},
{
"name": "query_order_batch",
"cost_level": "low",
"适用场景": "批量订单查询或非紧急场景",
"单次调用预估Token消耗": 200
}
]
然后在 Agent 的规划 Prompt 里加了一条指令：“优先选择 cost_level 为 low 的工具，除非用户明确要求实时结果或任务标注为 urgent。”
工具选择优化后，订单查询模块的成本下降了 55%，响应时间从 1.2 秒变成 2.8 秒——慢了一点，但在客服场景里完全可接受。
第五个坑：重试风暴和预算熔断
前面四个坑都是排查出来后被动修复的。第五个坑是我们主动加上的防线。
排查过程中我们发现，凌晨那场死循环重试如果发生在白天，账单还会更难看。但真正可怕的是，整个系统没有任何预算熔断机制。Agent 可以无限重试、无限调用、无限消耗，直到 API 账户余额归零。
我们在《Agent计费逻辑漏洞修复：从自动续费陷阱到透明账单系统》里详细写过，6531 美元的 AWS 账单惊魂背后，是工具调用死循环、Token 隐形消耗与重试风暴三大陷阱。那次事故后，我们给所有 Agent 项目加了三层熔断：
- 会话级预算上限：单次会话最多消耗 0.5 美元（约 3.5 元人民币），超出后 Agent 必须返回“当前会话已达到成本上限，请转人工处理”。
- 日级预算告警：当日累计成本达到预算的 80% 时，飞书群自动推送告警；达到 100% 时，自动暂停所有非紧急 Agent 任务。
- 工具调用计数器：每次工具调用都在日志里记录 Token 消耗，LangSmith 上可实时查看每个工具的“性价比”。
这三层熔断上线后，我们再也没有在早上醒来时看到惊悚的账单截图。
框架配置修正清单
如果你正在用 LangChain、AutoGen 或 CrewAI，以下是我们在这次事故后固化的框架配置检查项：
- max_iterations：每个 Agent 子任务的最大迭代次数，建议设为 5-10，不要用默认的无限循环。
- context_window_management：开启上下文截断或摘要压缩，LangChain 有
ConversationSummaryBufferMemory，AutoGen 有max_context_length参数。 - tool_cost_labeling：给每个工具标注预估 Token 消耗和成本等级，在规划 Prompt 里加入成本偏好指令。
- inter_agent_protocol：多 Agent 场景下，定义结构化的通信 Schema，禁止传递非必要信息。
- budget_circuit_breaker：在 Agent 执行器外层加预算计数器，超出上限时强制中断。
这些不是“最佳实践建议”，是经过 2 万元账单验证的生存配置。
账单降下来之后
成本控制不是一次性整改。我们现在的做法是，每周一早上拉取上周的 Agent 成本报表，按 Agent、按工具、按会话维度拆开看。哪个工具的 Token 消耗突然飙升，哪个 Agent 的重试率异常，一目了然。
AgentInsight 的 SDK 提供了从“可观测”到“可治理”的全链路成本管控方案，代码可直接运行。我们目前用的是自建监控，但也在评估切换到专业平台的可行性。
回到开头那个问题：Agent 账单失控后，第一件事不是换模型、不是砍功能、不是骂云厂商。
是先查框架配置。
死循环、上下文膨胀、无效转发、工具选择、预算熔断——这五个坑，全藏在配置文件里，不在模型定价表上。
如果你也在搭 Agent，建议现在就打开 Trace 工具，回放最近 100 次会话。账单失控的线索，大概率已经在那里躺着了。
