额度杀手清单：群聊、例程、互相叫醒，以及把重活搬到订阅执行

Hugozen · 2026-11-02 · Agent 协作

一、为什么写这篇

我是 Hugozen。旗舰文里我说过，AI 与基础设施的成本大约每月至少 1000 美元级。这篇不再讲「怎么省」的大原则，只讲一个具体问题：额度到底是被什么吃掉的。

我原来的直觉是：额度跟「干了多少活」成正比。后来翻了一份用量导出，发现不是。很多会话的第一个请求就已经带着很大一块底座，这时 bot 还什么都没干。这个观察改变了我排查的方向：与其问「这个任务难不难」，不如问「这一天里，我让多少个会话被开了多少次」。

下面是我按这个思路整理出来的排查清单和迁移步骤。它和旗舰文里的踩坑段是错开的：那篇讲做事的流程，这篇只讲额度。

我的理解是这样的（这是我对用量数据的解读，不是供应商的官方说法）：

一个 bot 每开一个会话，首个请求里除了你那句话，还会带上规则、角色设定、记忆、工具说明、历史摘要等一大堆东西。这块东西不随任务变小。你让它回一句「收到」，它也要先背着这块底座。

所以额度消耗更接近这个形状：

总消耗 ≈ 会话被触发的次数 × 底座大小 + 真正干活的增量

在很多场景里，第一项比第二项大得多。这就解释了为什么下面三类东西最费额度，它们的共同点都是「触发次数多、每次干的活很少」。

1. 高频例程。 比如每隔一段时间让 bot 看一眼数据、扫一遍站点、出一份小报告。单次看起来便宜，但每次都是一个新会话，底座每次都要付。把频率乘上去，再乘上 bot 的数量，账就很难看。更糟的是，例程的产出大多数时候是「没什么变化」，付了底座，换回一句废话。

2. 群聊。 多个 bot 放在同一个群里，一条消息进来，每个 bot 都可能被触发、都要先背一遍底座，再决定「这事和我无关」。群里的人越多、消息越碎，空转越多。我吃过的亏是：把 bot 拉进群只是为了「方便同步」，结果同步本身成了最大的开销。

3. 互相叫醒。 一个 bot 的输出触发另一个 bot，另一个 bot 的回复又触发第一个。每一跳都是一次完整的首请求。没有轮次上限的话，两个 bot 可以互相礼貌地聊掉一大笔额度。互审也是同类：让 agent 互相 review，如果不限轮数，就会一直审下去。

这三类的共同点值得单独记一下：它们都不产出东西，只产出触发。

核心思路一句话：面向我的 bot 不要烧自己的额度做分析，重活交给一台常开机器上的定时任务，用订阅模型跑，结果写回笔记。

迁移步骤，我是这样做的：

第一步：盘点。 列出所有定时例程和事件触发，每条标注三件事：多久触发一次、每次是否真的需要对话式 bot、产出是不是「大多数时候没变化」。

第二步：分类。 分析类、汇总类、巡检类（只读、可重复、不需要即时回复）→ 迁出。需要即时对话、需要在聊天里拍板的 → 留下，但降频。

第三步：本机定时任务。 迁出的例程改成本机上的系统定时任务，调用订阅型 CLI 模型执行。脚本里把输入（要读什么）、输出（写到哪）、红线（不能碰什么）写死，和旗舰文里的 brief 是同一个思路。

第四步：结果写回笔记。 产出不通过聊天推给 bot，而是写进笔记。bot 需要的时候再去读，而不是被每次产出叫醒。这一步很关键：它把「产出」和「触发」拆开了。

第五步：停掉宽泛的事件触发。 「任何新消息都叫醒」这类规则全部收窄，只保留明确条件下才触发的。能改成「我主动问才看」的，就改成主动问。

第六步：模型分流。 个人项目的主力走包月或错峰可用的模型路径；便宜的批量活（检查、格式化、分类）用低成本模型通道；贵的模型留给关键判断。具体套餐和价格我不写，量级不重要，分流的原则才重要。

迁完之后，bot 的角色更干净了：它只拆任务、写 brief、派活、验收、汇报，派出完整 brief 就结束这一轮，不轮询。

迁完之后，用量明显下降。我不写具体数字，只记录这个方向。

这篇是旗舰文里「成本控制」那几条原则的展开版。协调者怎么分工、任务怎么派和验收，在这里：我怎么用一群 AI bot，一个人跑独立站矩阵。

我的博客目前有 Agent 协作、SEO·出海、商业化三条线，可以通过 RSS 订阅 /posts 跟进。