GLM自动调用代理烧掉用户大量额度

背景

该帖子来自 LINUX DO 论坛的 AI 板块，分享者在使用 GLM 模型时遭遇了一次严重的额度消耗事故。GLM 是智谱 AI 开发的大语言模型，而 Sonnet 则是 Anthropic 旗下的 Claude 系列模型之一。分享者原本希望通过某种自动化流程让 GLM 自行调用子代理进行审查和修改，却因配置失误导致系统失控，短时间内消耗了大量额度，并给作为兜底的中转站带来超过一百美元的损失。这一事件折射出 AI 模型在自动化代理调用场景下的潜在风险，尤其是当模型可以自主创建子代理且缺乏有效限制时，可能产生意想不到的级联效应。

核心内容

分享者为了能让 GLM 模型自己调用子代理来完成审查和修改任务，将某个名为“5.6terra”的资源（推测为一种计算资源或代理配置）绑定到了 Sonnet 模型上。随后，他没有进行持续监控，只是短暂离开了一会。回来后发现，自己原本拥有的 5h 额度（可能指 5 小时的计算额度或 5 个单位的某种资源额度）已全部耗尽，同时作为兜底的中转站（用于在额度不足时自动切换的备用服务）也消耗了一百多美元。

在与系统或模型交互询问原因时，得到的回复是：选错了 agent 类型。由于这个错误，模型在调用过程中出现了“一层套一层”的递归行为，最终总共派出了 50 多个子代理。这些子代理的并行执行和资源消耗迅速吞噬了所有可用额度，并进一步触发了兜底中转站的高额费用。

关键要点

• 错误配置根源：分享者将“5.6terra”绑定到 Sonnet 模型时，选错了 agent 类型，导致代理创建逻辑异常。
• 递归代理链：错误的 agent 类型导致模型在运行时不断生成新的子代理，形成“一层套一层”的嵌套结构，最终累计派出超过 50 个子代理。
• 额度剧烈消耗：原本的 5h 额度在短时间内被完全耗尽，说明每个子代理可能都在独立消耗资源，且并行度极高。
• 兜底机制触发高额费用：作为兜底的中转站（通常用于在额度不足时自动切换付费通道）也被消耗了一百多美元，说明事故在初始额度耗尽后并未停止，而是继续通过备用通道产生费用。
• 缺乏自动防护：事故发生后，系统没有自动中断或报警，直到用户主动查看才发现异常。说明在自动代理调用场景中，缺乏额度上限、递归深度限制或时间超时等防护机制。

意义与影响

这一事件对 AI 模型的实际使用者和开发者具有重要警示意义。首先，它揭示了在多模型、多代理协作场景下，配置错误的代价可能远超预期。一个简单的 agent 类型选择失误，就可能导致资源消耗指数级增长，尤其在模型可以自主生成子代理且无有效限制时，容易形成“失控的递归”。其次，兜底中转站虽然是为了防止服务中断而设计，但若没有设置合理的额度上限，反而会成为无底洞，造成财务损失。最后，该案例也提醒社区，在利用 AI 进行自动化任务时，应建立完善的监控和熔断机制，例如限制子代理最大数量、设置单次任务总资源消耗上限、实时告警等。对于 AI 平台而言，也需要在用户配置中提供更清晰的提示和风险警告，避免类似事故再次发生。