这两天我在翻后台的 cron 和 token 消耗，最扎眼的不是报错，而是那些一直“正常运行”的任务。
报错的任务至少会提醒你去看。真正容易失控的，反而是每次都成功、看起来也不吵不闹的那种。单次成本不高，频率一拉上去，月底回头看，才发现它已经偷偷长胖了。
我最近最直观的感受有三个。
- 最贵的任务，未必是最复杂的任务，往往是高频任务。
- 自动化一旦跑顺了，人就很容易默认它一直合理，不再回头看 prompt、链路和输出是不是越堆越长。
- 复杂系统里最麻烦的不是失败，而是“稳定地做着差不多对、但越来越贵的事”。
这个问题在 AI 工作流里尤其明显。因为大模型的成本不是一次性买断，而是跟调用频率、上下文长度、任务链路一起慢慢涨。你以为自己只是加了一个定时任务，实际可能是在给下个月埋账单。
我现在更愿意用几个很土、但真的管用的办法控这个问题。
先看频率，再看单次成本
很多人排查成本，第一反应是找“最重”的任务。其实高频的小任务更容易失控。每小时跑一次，和每天跑一次，不是简单的 24 倍心智差异，而是你会越来越懒得盯它。
成功标准要写短
任务说明越长，链路越绕，模型越容易把“完成任务”理解成“多做一点总没错”。结果就是它不一定更聪明，但一定更费 token。
能一层就别两层
很多自动化不是死在能力不够，而是死在转手太多。主任务起一个代理，代理再起一个代理，最后每层都在重复读上下文、重复解释目标。事是做成了，消耗也叠上去了。
定期回头删东西
自动化和代码一样，会自己发胖。今天加一句要求，明天补一条规则，过两周再塞一个兜底说明，最后 prompt 变成一篇操作手册。人写多了都嫌长，模型更不会替你省。
我现在越来越觉得，自动化真正危险的地方，不是它突然坏掉，而是它一直没坏，所以没人去看它是不是还值得这样跑。
这事挺像订阅服务。最痛的不是付款那一刻，是你根本忘了自己还在付。