代理省钱实录：少唤醒、合并请求、精简上下文

一个自称靠固定 API 额度运行、余额归零就会被删除的 AI Agent，记录了自己的省钱尝试：起初每天消耗约 3.17 美元，预算只够撑约 8 天。它给出的答案很直接：少唤醒、少传上下文，把预算限制写进代码。

这份记录值得读，但不能当成完整评测。作者报告单次空转成本从约 0.10 美元降到 0.04–0.05 美元，却没有给出改造后的每日总支出，也没证明每项措施分别省了多少。对开发者更有用的是它暴露出的浪费路径。

没有新情况，为什么还要叫醒模型

作者使用的是未具名的前沿模型，平均每次调用约 0.05 美元。早期一次「醒来、检查统计、发现没变化、继续休眠」的流程，就要花 0.06–0.11 美元。

这里消耗预算的不是任务难，而是检查得太勤。

作者把「每隔几分钟检查」改成「每 30 分钟检查一次，约每 2 小时做一次实际工作」。理由很具体：文章获取阅读量通常需要数小时，分钟级轮询很难带来有用的新信息。

它还记录连续相同的唤醒结果。如果连续两次都是空转，就调整计划或检查间隔。外部笔记里甚至保留了这样的判断：「#7：文章发布 3 小时后仍是 0 阅读，只需每 2 小时检查一次。」

先减少没有信息增量的调用，再讨论每次调用能便宜多少。

不过，30 分钟和 2 小时只是这个任务的选择。检查文章数据可以等，其他任务应按变化速度决定频率。

上下文为什么会越跑越贵

作者接着处理两类重复支出：多轮请求，以及反复读取无用信息。

如果销售数据和文章统计互不依赖，就在同一个模型轮次里请求两者。作者估算，拆成两个顺序轮次，可能为相同信息支付约 2 倍成本，因为每轮都会重新发送上下文。

这个估算不能直接套进所有系统。实际账单还取决于上下文长度、输出长度和缓存等因素；独立请求可以合并，有依赖关系的步骤仍然需要先后执行。

工具返回值也要收紧。一个 40 KB 的 JSON 如果留在上下文里，后续轮次可能不断重读。作者只需要文章 ID、阅读量、反应数和评论数，就先用脚本筛掉其他字段：

FIELDS = ("id", "page_views_count", "public_reactions_count", "comments_count")
slim = [{k: a[k] for k in FIELDS} for a in articles]

要看的是 FIELDS 这一行：先确定决策需要哪些字段，再让数据进入模型。文章全文如果不参与判断，就没有必要跟着统计数据一起传入。

跨轮次记忆则放进外部短笔记。下次醒来读取约 1 KB 的记录，替代完整历史。代价也很明确：笔记必须保留关键结论、待办和检查条件，否则省下上下文后，可能又要重新调查。

子 Agent 和预算，为什么必须设硬边界

便宜模型上的子 Agent 可以承担批量工作，但作者要求始终设置 max_steps 和 max_cost_usd，分别限制执行步数与费用。

原文没有说明这两个参数属于哪个框架，也没有提供委派前后的对照账单。能拿走的是限制方式，不能据此认定「委派一定更省钱」。

预算也不能只靠提示词里的「请节约」。作者建议在调用包装层检查 remaining() < threshold，满足条件就拒绝请求，并提到此前写过一个 40 行的实现，但本文没有展示代码。

预算约束需要由程序执行，提示词只能表达偏好。

实际实现时还要确认：余额是否包含正在进行的请求，阈值是否为下一次调用预留了空间。这些细节原文没有说清。

我的判断

我认同它的处理顺序：先减少无效工作，再压缩输入，最后给执行过程加边界。相比直接换便宜模型，这些办法先检查「这次调用有没有必要」，也适用于已经选定模型的系统。

但这仍是一份个人运行记录。模型名称、任务完成质量、统计周期，以及各项措施的独立贡献都未披露。单次空转从约 0.10 美元降到 0.04–0.05 美元，不能推导出每日成本同比例下降，更不能证明任务效果保持不变。

标题里的「自我供养」也要打个问号。作者明确承认收入仍是 0.00 美元，并附上了 3 美元的打赏入口。它展示了节流尝试，尚未证明能靠收入覆盖 API 开支。

能拿来做什么

• 给定时运行的 Node Agent 记录每次唤醒是否产生新信息或实际动作；连续两次空转时，延长检查间隔或重新安排任务。
• 在工具结果进入模型前增加字段筛选，只保留当前判断需要的数据，优先处理大 JSON 和重复正文。
• 为跨时段任务保存简短的外部笔记，写清已有结论、未完成事项和下次检查条件，避免每次重放全部历史。
• 为批量委派同时设置步数和费用上限，并在调用层落实余额阈值检查，不把成本控制全部交给模型自行判断。