开源了代理的预调用消费门控——在首次错误通话之前停止失控循环,而非账单之后
摘要
开源了一个预调用消费门控和防篡改审计日志,以防止自主代理中递归循环导致的失控API成本,MIT许可,附带Postgres+TypeScript演示。
我的联合创始人一直在部署自主代理,我们遇到的最可怕的失败模式不是错误答案——而是递归循环或工具解析错误在夜间悄悄烧掉API预算。我看到的大多数“修复”都是反应式的:统计重复调用次数,或者事后检查账单。那时钱已经没了。所以我们构建了一个小型MIT许可的参考实现,包含两个相互配合的部分:一个预调用消费门控(在LLM/工具调用触发前授权消费)和一个哈希链式防篡改审计日志,使得每一条批准/拒绝决策都有可验证的记录。演示模拟了一个恶意代理触发每日限制——循环1-3被批准,循环4被拒绝,执行终止,链验证通过。使用Postgres + TypeScript,但这两种模式是语言/数据库无关的。好奇这里其他人如何处理代理消费限制——反应式监控,还是上游控制?
相似文章
我构建了一个开源中间件,防止AI智能体超出花费/策略限制——v0.2现已发布
ActionFence 是一个开源中间件,可为 AI 智能体和 MCP 服务器强制执行花费上限、策略限制和安全检查。v0.2 版本新增了滚动窗口上限、断路器以及模式漂移检测等功能。
如何阻止失控的LLM API支出在调用发出之前(调用前预算执行)
一份实用指南,介绍如何为LLM API调用实施调用前预算执行,涵盖估算、对账、故障开放决策、范围预算和并发处理,以防止失控成本。
我们构建了一个开源授权网关,因为我们的AI代理一直失控
团队发布了一个开源授权网关,以防止AI代理出现意外或恶意行为。
因为失控的 agent 浪费几百美元 API 额度,基本上已经成为一种入门仪式了。这是我的经历。
我现在开始觉得这是一种共同经历了。我认识的所有构建 agentic AI 的人,git 历史深处都藏着同样的悄悄话:那个让 agent 无人看管跑了一整个周末的经历、周一收到的账单、试图弄清楚它到底做了什么的取证工作。我的经历是两天内花了 400 多美元。我的 agent 对着同一个研究任务换着法子自言自语了 48 小时,结果什么都没产出。感觉就像被一个非常有礼貌的 Phi
为可被MCP调用的代理构建了公开审计追踪收据URL,以Apache 2.0开源协议发布
为可被MCP调用的代理构建了公开审计追踪收据URL,以Apache 2.0开源协议发布,通过提供包含监督检查且消费者可读的审计收据,以应对采购环节的质疑。