Hermes实战01:我的AI助手烧光了一周额度,然后我给它上了三道闸

用AI Agent跑自动化任务，最贵的一课不是提示词写得不好，而是发现它会在你看不见的地方无休止地重试。我的一个对话曾经把一周的Codex套餐额度烧了个精光。后来我写了一个不到两百行的Python脚本挂在Agent的工具调用链上：按轮熔断、静默处理无人参与的任务、再把纪律写进它的“性格”文件。这篇文章把这套方案完整拆给你。

文｜半只土豆　本文为笔者Hermes Agent实战系列第一篇

事故现场：额度是怎么烧光的

事故现场：额度是怎么烧光的

 

先交代背景。我用Hermes Agent搭了一套个人自动化系统：多个独立的Agent实例各管一摊业务，每天有十来个定时任务在跑——新闻采集、选题雷达、舆情监测、公众号文章管线，模型则按任务混用各家订阅，其中一部分跑在Codex套餐上，按周刷新额度。出事的那次，是一个长任务的对话没有收敛。Agent在执行一个多步骤任务时，某一步出了问题——可能是检索失败，可能是页面抓不到——它没有停下来报告，而是换着姿势反复尝试：换个查询词再搜一次、换个工具再抓一遍、把整个流程从头捋一遍。每一轮尝试看起来都合理，单次成本都不大，但架不住次数多。等我察觉不对的时候，一周的套餐额度已经见了底。

复盘的时候我意识到，这类事故有三个非常讨厌的特征。第一，它是静音的：Agent每一轮都在正常返回，没有任何报错，账单是唯一的报警器。第二，它是复利的：对话上下文越长，每一轮携带的历史token越多，烧钱速度是加速的。第三，它发生在你看不见的时候——定时任务尤其危险，凌晨四点半跑的采集任务烧掉多少，你早上才知道。事后我去看执行记录，那种感觉很复杂：它做的每一步单拎出来都算得上勤奋，但整场表现是彻底的失控。勤奋和失控可以同时成立，这是我给AI管理上的第一课。

第一道闸：从“按对话”到“按轮”

 

我的第一版防线是警告。写了个脚本挂在Agent的工具调用链上——Hermes支持在每次工具调用前执行一个Hook脚本，脚本检查这个会话累计消耗的token，超过阈值就给企业微信推一条消息。挂上当天我觉得很安心，两天后发现没用：警告只是通知，通知不影响行为。Agent在半夜收到六十 percent的预警，没有人看，然后继续跑。于是升级到第二版：达到上限就切断。但很快发现了更根本的设计问题——我一开始按“对话”设的限额，而一个对话可以持续很多天。用户每发一条新消息，Agent就继续在同一个上下文里干活，账是累加的。一个对话的上限顶不住一个持续一周的会话。

真正的解法是把计量单位从“对话”改成“轮”。所谓一轮，就是从用户最新一条消息开始，到Agent给出最终回答为止。每一轮开始时，脚本记住当前的累计token数作为锚点，之后每次工具调用前检查“这一轮烧了多少”，超过上限就拒绝本轮剩余的所有工具调用。这个设计有个漂亮的自愈特性：用户手动发送任意一条消息，新一轮自动开始，额度重新计算。不需要管理员解锁，不需要重启进程，用户自己就是解锁钥匙。断路器做得太“安全”，用户反而会被锁在门外；把恢复权交还给用户本身，才是自动化系统该有的分寸。

第二道闸和第三道闸：分层与立法

第二道闸是分层处理。聊天会话和定时任务的风险模型完全不同：聊天有人在场，熔断时可以提醒“额度用完了，发条消息就能继续”；定时任务凌晨跑，没人看，提醒发了也是白发。所以最终的规则是双轨的——聊天会话每轮三百万token，到顶时发企业微信通知；定时任务每轮六百万（放宽一倍，因为采集类任务本来就要读大量网页），但完全静默，到顶只停工具，不响一声。这里有个实现上的讲究：熔断不是杀进程，而是拦截本轮剩余的工具调用，同时给模型留了一句指令——“用已有信息向用户总结进展，不要虚构工具结果”。也就是允许它体面收尾，不许它带伤硬编。

第三道闸最便宜，也最容易被低估：把纪律写进“性格”。Hermes的每个Agent实例有一个SOUL.md文件，相当于它的长期人格设定。我在里面加了一条额度纪律：单条工具结果超过两万字符不得整包留在对话里反复携带，先落盘再只提取需要的字段；长任务完成就明确收口，不要隔几小时被反复续跑。效果出乎意料——脚本管的是“超了怎么办”，这段文字管的是“从一开始就别超”。一个热搜页面的JSON有几十KB，以前每次都会整包塞进上下文、每轮都背着它跑；立法之后，Agent会先写文件再grep，一轮下来token消耗能差出一个量级。代码是行为的下限，提示词是行为的期望，两道都要有。

代码是行为的下限，提示词是行为的期望，两道都要有。

给想抄作业的人

 

整套方案拆开看没有任何高深的东西：一个读SQLite算token的Python脚本、一个JSON协议的Hook注册、几行写进人格文件的纪律。加起来不到两百行，一个下午能写完。但它背后有三个值得记住的判断。其一，对Agent的管控要设在动作层而不是意图层——警告等于提醒它“请注意”，拦截才是真正改变行为；其二，计量单位要跟恢复动作对齐，“按轮”之所以有效，是因为用户的一条消息天然就是一轮的边界；其三，无人参与的任务要用不同的风险模型，深夜静默熔断比半夜推送一条没人看的警报体面得多。

现在这套系统跑了半个多月，额度再没有失控过。偶发的长任务到了上限会被利落地掐断，模型按指令交出一份基于已有信息的总结，我回一句“继续”，新一轮重新计费——整个体验像给一张跑飞的信用卡设了单笔限额。回头看那次烧光一周额度的教训，我最想说的其实是：AI Agent的可靠性问题，大多数时候不是模型不够聪明，而是系统没有给“勤奋”设边界。人也会陷入无休止的重试，但人会累、会心虚、会看一眼账单；Agent不会，除非你替它看。管理AI的第一课，跟管理任何强大的东西一样——先假设它一定会失控，然后设计那个让它失控得体面的开关。