开源电路熔断器：为LLM代理套上成本与死循环缰绳

当代理陷入死循环，账单也在悄悄膨胀

构建自主AI代理时，最令人头疼的往往不是模型能力边界，而是那些失控的瞬间：一次未捕获的异常触发重试，带着庞大的上下文窗口反复调用API，等收到OpenAI或Anthropic的账单告警时，损失已经发生。云端计费提醒的滞后性，让开发者急需一个能在本地实时拦截的“保险丝”。

Reddit社区一位开发者正是基于这一痛点，用Python和TypeScript构建了一个零依赖的本地电路熔断器（Circuit Breaker）。它的核心逻辑简单直接——在代理行为越界之前硬性中止，而不是事后补救。

电路熔断器概念图

三层防护：预算、循环与实时成本

这个熔断器提供了三个关键机制，覆盖了成本失控的主要路径：

1. 会话级美元预算硬顶 开发者可以设定单个会话的最高花费（例如1美元），一旦累计消耗触达阈值，熔断器立即中止所有后续调用。这相当于给代理装了一个“预付费电表”，余额耗尽自动断电。

2. 无限循环检测器 针对代理反复执行相同工具调用或陷入循环逻辑的情况，熔断器通过动作签名哈希比对来识别重复模式。以下是其纯Python实现的核心循环检测逻辑：

import hashlib

class CircuitBreaker:
    def __init__(self, max_repeats=3):
        self.max_repeats = max_repeats
        self.hashes = []

    def check(self, action_signature: str):
        h = hashlib.sha256(action_signature.encode()).hexdigest()
        self.hashes.append(h)
        recent = self.hashes[-self.max_repeats:]
        if len(recent) >= self.max_repeats and len(set(recent)) == 1:
            raise RuntimeError(f"Infinite loop detected! Tripped circuit on: {action_signature}")

这段代码维护一个动作签名的哈希列表，当最近N次动作完全一致时触发异常。虽然简单，但能有效拦截最典型的重复调用场景。

3. 跨模型实时成本计算 熔断器内置了OpenAI、Claude和Gemini等主流模型的token定价，能够根据每次调用的输入输出token数实时累加花费。这意味着预算控制不再依赖云服务商的事后账单，而是发生在调用发生的当下。

代码与成本监控

电路熔断器（Circuit Breaker） 是分布式系统容错模式的一种，最早由 Michael Nygard 在《Release It!》中系统化阐述。其核心思想是：当某个依赖服务连续失败达到阈值时，熔断器立即“跳闸”，后续请求直接快速失败，而不是继续等待超时或重试，从而防止故障级联扩散和资源耗尽。典型实现包含三种状态——闭合（正常放行）、断开（直接拒绝）、半开（试探性放行少量请求以探测恢复）。本文将其从“服务可用性”领域迁移到“财务安全”领域：触发条件不再是错误率，而是美元消耗或动作重复模式。这种类比之所以成立，是因为两者共享同一控制逻辑——在损失扩大前主动中断调用链。

LLM 的 token 计费机制是理解实时成本计算的前提。主流大模型 API 按输入 token 和输出 token 分别计价，单价通常以每百万 token 的美元数表示，且输出 token 单价普遍高于输入。不同模型、不同上下文长度档位的价格差异显著，部分模型对长上下文收取溢价。因此，代理的单次调用成本取决于：所选模型、输入上下文长度（包括系统提示、历史对话、工具返回结果）和生成长度。代理场景下上下文会随轮次累积膨胀，导致成本非线性增长——这正是需要会话级硬顶而非仅靠单次调用限额的原因。熔断器内置定价表，才能在每次调用返回 usage 字段后即时累加，而不是等待云端账单。

免费计算器与付费完整包

除了核心熔断逻辑，作者还提供了一个免费的网页版成本计算器，支持对比13+当前主流模型的token费用。对于想要快速估算不同模型组合开销的开发者，这是一个直观的辅助工具。

而完整的生产级包（包含15+模型的预配置token定价、美元上限设置以及TypeScript版本）则以19美元的价格在Polar平台上出售。这种“核心逻辑开源+生产工具付费”的模式，在开发者工具领域并不少见，既降低了尝试门槛，也为持续维护提供了动力。

为什么本地熔断比云告警更关键

云服务商的计费告警通常存在小时级的延迟，对于高频调用的代理场景，几小时内足以产生可观的费用。本地熔断器的价值在于将控制点前移：在每次API调用发出之前就完成预算检查和循环判断，而不是等待事后通知。

这种思路与传统的软件容错模式一脉相承——电路熔断器在分布式系统中用于防止级联故障，如今被移植到LLM代理的财务安全领域。对于任何在生产环境运行自主代理的团队，这类本地防护层应当成为标配，而非可选项。

作者在帖子中邀请社区对计算器和熔断逻辑提供反馈，这种开放态度也意味着该工具仍处于迭代早期。对于想要自行实现的开发者，上述循环检测代码已经提供了足够的起点；而对于需要快速落地的团队，付费包省去了适配多模型定价的时间成本。

开发者协作

实施建议与局限

在实际集成时，熔断器需要嵌入到代理的调用链中，确保每次工具调用和模型请求都经过检查。对于使用LangChain、AutoGPT等框架的开发者，可以在工具执行器的包装层插入熔断逻辑。

需要注意的是，基于哈希的循环检测只能捕获完全重复的动作签名。如果代理在循环中微调参数（例如每次传递略微不同的输入），简单的哈希比对可能失效。更复杂的语义级循环检测需要额外的设计。此外，实时成本计算依赖于准确的token计数，不同模型的tokenizer差异需要妥善处理。

尽管如此，这个项目切中了LLM代理落地过程中的一个真实痛点。在代理能力快速提升的同时，成本控制和安全护栏的配套工具同样需要跟上。本地熔断器或许不是终极方案，但它指出了一个正确的方向：让成本可见、可控、可中断。

动作签名（action signature） 指的是对代理一次具体行为进行确定性编码后得到的字符串，通常由工具名称加上结构化参数（如排序后的 JSON）拼接而成。哈希比对的有效性完全取决于签名的构造粒度：若签名包含时间戳、随机 ID 或每次略有差异的参数，则相同语义的循环会产生不同哈希，检测即失效。反之，若签名过于粗略（只取工具名），则可能把正常的多次同类调用误判为循环。实践中需要在“抗噪”与“敏感”之间调参，并可结合滑动窗口、动作频次统计或语义相似度做二级判断。本文示例用 SHA-256 对完整签名取哈希，属于最简形态，适合拦截参数完全一致的死循环。