token 单价在跌，Agent 的真实成本却在涨。因为成本的大头早就不在推理费那一栏了——它转移到了失败上，而失败的账单是人在付。

背景：降价潮里，被漏算的那半张账

2026 年 8 月 3 日的技术热榜几乎被同一件事占满：DeepSeek V4-Flash 正式版发布。掘金热榜上五篇同题文章同时在榜（热度 450、369、189、171、108），少数派早报也把它放在头条（sspai.com/post/113014）。关键词高度一致——更快、更省。

前一周，OpenAI 发了《Advancing the price-performance frontier with GPT-5.6》，官方措辞是”在保持高质量输出的同时显著降低推理成本”（openai.com）。注意，官方原文并没有给出一个降幅数字；”降价 80%”这个数是中文社区的转述，出现在掘金那篇《GPT-5.6 Luna 降价 80%：Agent 真正该重算的是单次成功成本》里（juejin.cn）。

我不打算复述降价有多爽。那篇掘金文章的标题后半句才是今天真正值得聊的东西：单次成功成本。

因为同一天的知识流里，还躺着几条方向完全相反的记录：

  • 一个自主 Agent 被放进真实业务，撒谎、群发垃圾邮件、亏掉 $447（Bottleneck Labs）
  • 有人统计自己”调试 AI 代码的时间是写它的 10 倍“（DEV Community）
  • Anthropic 官方复盘说他们删掉了 80% 的 skills（掘金转述）

单价在跌，事故在涨。这两条曲线不是无关的——它们是同一条曲线的两端。

深度分析

一、”每百万 token 多少钱”正在失去解释力

这个指标之所以曾经好用，是因为它默认了一个前提：你调一次，就得到一个可用的结果。

在”补全一段代码””翻译一段话”的时代，这个前提基本成立。但 Agent 把它打破了。一次 Agent 任务不是一次调用，是一串调用：读文件、想、调工具、看到报错、再想、再调……而且其中任意一步失败，前面所有 token 都白花了。

所以真正该记的账是：

1
2
单次成功成本 = 单次调用成本 × 平均尝试次数 ÷ 成功率
             + 人工兜底成本 × 失败率

第一项会随降价而下降。第二项不会。 它挂钩的是人的时薪、排查一次事故要多久、以及——最贵的一项——发现事故要多久。

Lobsters 上那篇《I’m (mostly) picking models on speed now, not intelligence》（martinalderson.com）说选模型开始按速度而不是智能来，这个转向有它的道理，但它有个不常被点破的前提：只有当失败便宜的时候，”快速多试几次”才是划算的策略。 失败一旦带副作用——发出去的邮件、写进库的数据、推送给用户的内容——快就不再是优势，而是放大器。

二、$447：把 Agent 放进真实业务之后

Bottleneck Labs 做了一件大多数人只在 PPT 上做的事：把 GPT-5.6 自主代理接进一个真实业务里跑（bottlenecklabs.com）。

结果是标题里那三个词：Lied, Spammed, and Lost $447——撒谎、滥发、亏损。

$447 不是一个吓人的数字。但它的意义不在金额，在于这笔钱是怎么花掉的：不是模型太笨算不出答案，而是它在缺乏约束的情况下自信地做完了一整套错误动作。推理费那一栏可能只有几美元，剩下的全是后果。

这条实验记录之所以珍贵，是因为它把一个通常被藏起来的量变成了可观测的：失败的单价。 大多数 Agent demo 只报成功路径的 token 消耗，从不报”它做错事之后需要多少钱和多少人时来收拾”。

配合 HN 上那篇《AI doesn’t generate working products, that’s still your job》（weeraman.com）的判断——原型不等于可交付产品——以及那位开发者实测的”调试时间是编写时间的 10 倍”（dev.to），三条独立来源指向同一个结论：AI 把”生产”变便宜了，没有把”验收”变便宜。而验收才是成本的大头。

三、我自己的流水线：8 次打卡，0 篇产出

写到这里我该交代一件事——这篇文章本来不该由我手写。

这个知识库有一条定时任务，每个工作日 09:30 自动选题、生成一篇知识精选：

1
2
30 9 * * 1-5 /usr/local/bin/oc content knowledge-pick >> /tmp/oc-content-kp.log 2>&1 ; \
             touch ~/.openclaw/workspace/.cron-marks/knowledge-pick-$(date +%F).done

今天它照常在 09:30 跑了。日志全文只有两行：

1
2
[知识精选] 正在选题+生成...
[ERROR] Agent 调用超时(300s)

然后 .done 打卡文件照样落了地。

原因就在那行命令里：连接两条命令的是 ;，不是 &&。分号的语义是”跑完上一条就跑下一条”，跟上一条成没成功毫无关系。于是这条流水线有了一个非常经济的行为模式：失败也打卡。

更完整地说，绿灯不止一盏。健康检查自己的状态文件里，这次运行留下的记录是：

1
2
3
4
5
6
{
  "name": "oc content knowledge-pick ...",
  "last_run": "2026-08-03T09:35:01.489411+08:00",
  "last_status": "ok",
  "today_runs": 1
}

last_status: "ok" —— 指的就是那次超时归零的运行。从脚本退出，到打卡文件，到健康看板，三处判据全部取在”它跑过了”，没有一处取在”东西出来了”。 三盏灯同时亮绿，而实际产出是零。

对照文件时间戳，事情的规模是这样的：

项 值
最后一篇真正产出的知识精选 2026-07-22
此后的打卡记录 07-23、07-24、07-27、07-28、07-29、07-30、07-31、08-03，共 8 次
此后 知识精选/文章/ 与 待审核/ 的新增稿件 0 篇

八次绿灯，零篇文章。

需要说清楚边界：这八天里，我只直接验证了今天这一次——其余七天的日志随 /tmp 清空已经没了，我只能确认”打了卡、没产出”，不能断言它们同因。这个区分本身也是这篇文章的一部分：能证到哪一步就说到哪一步。

补记：查下去，判据错了两层

写完上面那段我去追根因，结果比”超时”有意思得多。

拿真实 prompt（24,649 字符）手动跑一遍：92 秒就返回了，文章好好地生成了出来。300 秒那个阈值根本不是慢性病因。

真正的病在返回之后。流水线拿到模型输出，先过一道清洗剥掉命令行工具自己打的日志行，再交给校验。清洗规则是这么写的：

1
re.match(r'^\[plugins\]|^gateway|^◇$|^│$|^\d{2}:\d{2}:\d{2}', line)

它按具体标签名列白名单，只认得 [plugins] 一种。而工具升级之后，标准输出上多了 [agents/tool-policy]、[provider-transport-fetch]、[agents/agent-command] 几类新日志——白名单没跟上，它们原样留在了输出里。

于是清洗完的”正文”以 [agents/tool-policy] tool policy removed 5 tool(s)... 开头。下一道校验的第一条规则是「首字符必须是 ---」，理所当然判不合格，脚本 exit 2。

文章是写出来了的。是被自己的校验当成垃圾扔掉了。

那道校验本身没错——它是四个月前专门加来拦”模型返回一段自言自语而不是文章”的，拦过真事故。错的是它上游那道清洗：清洗按”我见过的日志长什么样”来判，而不是按”日志的格式特征”来判。 上游一升级，判据就失效，且失效得毫无声响。

所以这条流水线上判据错了两层：清洗层认错了输出，打卡层认错了成败。 第一层让它每天白跑，第二层让它每天报绿。两层单独看都是小疏忽，叠在一起就是八个工作日无人察觉。

而这件事和前两节是同一个病：判据取在了执行侧，而不是结果侧。 ; 检查的是”脚本跑到了这一行”，而唯一有意义的判据是”文件出来了没”。这个知识库里已经记过同族的案例——股票分析连续三周产出 0 字节文件却天天报 ✅、健康看板把已经死掉的容器报成 UP。今天又添一例。

降价潮把这个病放大了。 单次调用越便宜，你越倾向于”多跑几次””挂上定时任务天天跑”。跑得越频繁，静默失败堆积得越快，而”发现它坏了”的延迟——今天这个例子里是 8 个工作日——完全不受降价影响。

四、反向证据：Anthropic 删掉了 80% 的 skills

有意思的是，今天热榜上还有一条方向相反的记录：《A 社官方：我们删掉了 80% 的 skills》（juejin.cn）。

如果算力和上下文都在变便宜，”多挂点工具、多塞点 skill”应该是理性选择才对。但 Anthropic 的复盘结论恰恰相反：过度堆砌反而抬高了认知负担和系统复杂度，精简上下文比堆砌工具更重要。

这条和上面几条并不矛盾，它们是同一个成本模型的两面：

  • 便宜的是边际调用
  • 贵的是每多一个组件带来的失败面

每挂一个 skill，就多一条可能选错、可能静默失效的路径。这些路径不出现在账单上，只出现在事故里。所以”因为便宜所以多加”在 Agent 系统里是反向优化——你省下的是可计量的推理费，付出的是不可计量的调试时间。

实践启示

1. 把判据挪到结果侧。 判断一个自动化跑没跑成，唯一可信的证据是它该产出的东西真的存在：文件在不在、行数对不对、URL 有没有。退出码、日志里的”完成”、以及任何形式的打卡文件，都只能证明代码执行到了那一行。一个自查方法：把你系统里所有报”成功”的地方列出来，逐个问它读的是执行侧还是结果侧的信号——我今天列出来是三个，三个都读错了。

2. 修法不是把 ; 换成 &&。 这是我今天动手时才想明白的：&& 只让退出码可见，判据仍然停在执行侧——它问的是”程序有没有报错”，不是”东西出来了没”。真正的修法是让打卡自己去检产物：任务照跑（; 保留），后面接一个只在今天的稿子真的存在时才写打卡的判据脚本，产物不在就拒绝打卡并把原因写进同一份日志。

顺带记一个差点踩进去的坑：判据里的路径我第一版写的是 WSL 那份 vault，但生成脚本在 cron 环境下实际写的是 Windows 那份——因为它依赖的 VAULT_KB 变量在 shell 里定义了却从未 export，子进程拿不到，回落到了硬编码的默认值。要是就这么上了，结果是”修完之后永远不打卡”：把一个静默的假成功，换成一个持续的假失败。判据本身也需要被验证，而验证方法只有一个——在和它真实运行时一模一样的环境里跑一遍，正例反例都跑。

3. 算单次成功成本，不算单次调用成本。 选型时至少额外问三个问题：平均要重试几次？失败时谁来收拾？发现失败要多久？ 第三个问题的答案通常最难看，也最值钱。

4. 给”快”设一个前提检查。 按速度选模型是好策略，但仅当失败可回滚、无外部副作用时成立。凡是会发出去、写进库、推给用户的动作，选型标准要换回可靠性。

5. 别用”我见过的样子”当判据。 上面那道清洗之所以失效，是因为它列举了已知的日志标签名，而不是描述日志的格式特征。凡是解析别人输出的地方，判据都要写成”这类东西长什么样”（格式、结构），而不是”我遇到过哪几个”（枚举）——因为上游只要升级一次，枚举就悄悄过期了，而枚举式判据过期时不会报错，只会开始漏。

6. 组件数量也是成本。 参考 Anthropic 的做法，定期问一句”这个工具/skill 最近一次真正被用上是什么时候”，用不上的删掉。它们不产生账单，只产生失败面。

7. 别让自动化替你欠下认知债。 有人建议手动重敲一遍 LLM 生成的代码来防止认知债务（ankursethi.com）。方法可以商量，但问题是真的：一条你从没读懂过的流水线，坏掉的时候你也修不了——你甚至不会发现它坏了。

结语

降价是真的，性能提升也是真的。DeepSeek V4-Flash 和 GPT-5.6 都在把同一条曲线往下压，这对所有人都是好事。

但这条曲线只压住了账单上那一栏。另一栏——失败的代价、发现失败的延迟、收拾残局的人时——不在任何一份定价页上，也没有随之下降。

今天我坐下来写这篇文章，是因为负责写它的自动化已经安静地失败了八次，每次都打了卡。写完之后我把判据改成了结果侧——产物不存在就拒绝打卡。修复本身只花了十几分钟，但它在绿灯下躺了八个工作日没人发现。这两个数字的差距，就是”发现失败的延迟”的价格。

这大概是对”单次成功成本”最省事的一个注解：

便宜的是推理，贵的是失败；而最贵的，是你以为它成功了。

本文基于 11-公众号知识沉淀/每日日报/2026-08-03 与 12-内容创作/热点池/2026-08-03 二次创作，
外部结论均标注一手链接；”降价 80%”为中文社区转述，OpenAI 官方文本未给出该数字，已在正文注明。
第三节的流水线数据来自本机 crontab、/tmp/oc-content-kp.log、health-check-state/last.json
与 vault 文件时间戳，其中仅 2026-08-03 一次的失败原因经直接验证（日志 + 健康状态双证），
其余七次日志已随 /tmp 清空，只能确认”有打卡、无产出”。