虫鱼的AI万花筒成本与限速陷阱
一次"看着没事"的请求可能烧掉几十元；一次并发飙升就能让你的整个 Agent 跑空账户。
Token 计费的真实速度
主流 API 按 token 计费，输入和输出分开计价，输出通常比输入贵两到三倍。一个直观参照：1000 个英文 token 约等于 750 个英文单词；中文因为单字常被切成 1 到 2 个 token，一段 1000 字的中文大约是 1500 到 2500 个 token。一次普通的"写一封邮件"任务，输入 200 token、输出 400 token，按主流模型价格约为几分钱到一两毛钱，看起来不贵。但放到生产环境，如果每天有 10 万次调用，账单就是几万到几十万元——这才是需要严肃对待的量级。
长上下文是一把双刃剑
把整本书、整份代码仓库塞进上下文窗口很方便，但成本按"输入 token"线性增长。一份 100 页的 PDF 可能就是 3 万到 5 万 token，单次请求就花掉一两元。更糟的是，模型在长上下文的中后段注意力会下降，把关键信息放在最前面、避免无意义堆砌，才能兼顾效果和成本。每次调用前先估算 token 数（大多数 SDK 都有计数器）、对长文档做截断或摘要、把历史对话定期压缩，是基本的工程纪律。
限速与并发陷阱
服务商按"每分钟请求数"（RPM）和"每分钟 token 数"（TPM）两个维度限速。超过任一维度都会返回 429 错误。Agent 类应用尤其危险：一个 Agent 循环可能一次发 10 到 30 个请求，如果并发启动了 10 个 Agent，每秒就是几百次请求，几分钟内就能触发限速甚至临时封号。代码层面必须有：请求队列（控制并发数）、指数退避重试（429 后等 1s、2s、4s 再试）、总成本熔断（单日花费超过阈值就停止）、最大步数限制（Agent 循环超过 N 步强制终止）。
一些节约成本的实操
第一，用更便宜的模型做初筛——让小模型判断"这个问题是否值得调大模型"。第二，缓存相同或相似请求的答案，对 prompt 模板做精确去重。第三，对输出做长度上限——明确告诉模型"用不超过 100 字回答"比留空更省 token。第四，定期审账单上的异常调用——很多团队第一次看到月度账单才发现某个后台任务在持续空跑。第五，自己跑一个轻量级监控（哪怕只是按小时统计 token 用量），不要等服务商的月度报告才看到问题。