AI Agent账单砍掉97%的实战复盘

八周前，我把自己"全自动化的"AI Agent 业务的运行成本加了一遍，那个数字让我肉疼。Agent 确实在干活——监控收件箱、生成内容、观察基础设施——但 token 账单悄悄膨胀成了硬件之外最大的支出项。最要命的是：大部分开销都是浪费。不是"可以优化"的浪费，而是结构性的浪费——你为一个每天回答四十八次"有没有新邮件？"的问题在付前沿模型的钱。

我花了一个周末重新设计成本架构。账单下降了 97%。没有任何自动化停下来。下面是完整的拆解，包括真实的数字和代码模式，因为当初要是有谁能直接给我这份东西，我就不用从账单里学这些了。

审计：token 到底花在哪了

我连续两周记录了所有自动化调用并做了分类。分布情况令人尴尬：

再看一下第一行。我的 AI 预算有 60% 花在那些大多数时候整个输出就是"无"的任务上。每次轮询很便宜——几千 token 的上下文加一个简短回答。但便宜 × 每 30 分钟一次 × 多个监控项 × 30 天，就是一笔真实的钱了，而且这些调用每一次都带着完整的 Agent 系统提示词一起跑。

那个搞定一切的洞察：轮询不是智能。如果一个检查可以用规则表达，那就应该是脚本，而不是 Agent。只有当脚本发现有什么值得思考的事情时，才应该调用 Agent。

方案一：干掉 Agent 轮询，保留告警

我的收件箱监控是一个 Agent 定时任务：醒来，加载 Agent 运行时，通过 IMAP 连接 Gmail，扫描买家消息，总结，退出。每半小时一次，永无止境，每次都消耗数百 token 的系统提示词加上工具脚手架。

替换方案是一个极简的 Python 脚本，只用标准库——imaplib，不用任何 Agent 框架。调度器（我的 cron 系统支持"无 Agent"模式，只运行脚本，有输出就交付 stdout）每 30 分钟运行一次。有东西时打印发件人和主题，没有就静默——只有这时候才真正需要动用 Agent。

import imaplib, sys

m = imaplib.IMAP4_SSL("imap.gmail.com", 993, timeout=30)
m.login(USER, APP_PASSWORD)
m.select("INBOX")
_, data = m.search(None, '(UNSEEN SUBJECT "order")')
ids = data[0].split()
if ids:
    for i in ids[-5:]:
        _, msg = m.fetch(i, "(BODY[HEADER.FIELDS (SUBJECT FROM)])")
        print(msg[0][1].decode("utf-8", "ignore").strip())
    sys.exit(0)   # output -> notification fires
# no output at all = silent, zero cost
m.logout()

改动前：每月约 1,400 次 Agent 调用，分布在所有监控项上。改动后：零 token。这个脚本要么什么都不说，要么说值得注意的事情。这一项改动占了 97% 中的大部分。

可推广的规则：任何成功输出为空的任务，都不应该在 LLM 上下文中运行。健康检查、队列深度、磁盘空间、收件箱扫描、价格监控——所有这些都是穿着 Agent 外衣的 if 语句。

方案二：模型分层，并显式锁定

对于那些确实需要模型的任务，第二个漏洞更隐蔽：模型漂移。我的调度器允许任务继承"当前默认模型"，而默认模型会随着我测试更强的模型而改变。一个用预算模型完全没问题早晨简报任务，因为没人告诉它不要升级，悄悄跑在了成本高 20 倍的模型上。

每个任务显式锁定模型。每个定时任务现在都写明自己要用的模型。不继承、不默认、不漂移。

按任务难度分层：

预算闪存层值得特别强调。我之前在一篇文章里做过正经的对比——对于结构化、短输出的任务，便宜模型的失败率和贵的那个没什么区别，价格大约是后者的 11%。为"把这六行状态格式化成一段话"付前沿模型的价格，就是在烧钱。

方案三：把批量生成搬到本地

内容生成占支出的 30%，且随着输出量线性增长——这是最糟糕的成本结构。所以我把它迁移到了本地模型：一个约 465GB 的 MoE，运行在 Mac Studio（M3 Ultra，512GB 统一内存）上。每篇文章生成大约需要七分钟，约 14 tokens/秒，听起来很慢，但直到你意识到边际成本是电费——几乎为零，而且这台机器晚上本来就是闲置的。

300+ 篇文章后的质量结论：对于公式化的长篇（书籍摘要、指南、结构固定的解说），本地模型轻松越过门槛。我用——你猜对了——一个脚本（非 Agent）抽检每批内容，检查禁用短语和事实性错误。

如果你用 Apple Silicon，想要我用的精确服务器配置、内存调优和下载工具，都在底部链接的套件里。

方案四：每个服务独立密钥 + 用量上限（这个是事故换来的）

再补一条， hard way 学到的。我在多个内部服务中复用一个 API 密钥。某天下午，一个持有旧版密钥的外部程序反复提交一个 90K 上下文的任务。每次重试都燃烧一整轮 90,000 token 的 prefill。它弹了好几个小时我才注意到支出异常，而唯一能终止它的方法是轮换密钥——这暂时也破坏了合法服务。

现在：每个服务一个密钥，provider 支持的地方加上 per-key 用量上限，密钥只放在一个地方。那个 90K 事故的代价超过了我整个优化方案一个月的花费。枯燥的卫生习惯，昂贵的教训。

剩下的 3% 几乎全是推理层——模型质量直接决定结果的工作。这才是 Agent 账单的正确形态：钱集中在智能真正起作用的地方。

本地推理这一半——带调优参数的模型服务器配置、内存/sysctl 调优笔记、可恢复的模型下载器（支持镜像/中继）、隧道一行命令——打包成了 Mac 版 AI Dev Kit（$9.99，一次性买断）。它就是在 M3 Ultra 上运行上述生成流水线的精确配置，已在 macOS 14+ Apple Silicon 上测试通过。轮询脚本模式上面文章里已经免费给了，因为它就十行，谁都应该直接抄过去用。

如果你做过自己的 Agent 成本审计，我很想知道你的分布是什么样的——尤其是有没有人的轮询桶像我的一样夸张。评论区开放。