AI 在造火箭,但水管还在漏水

这两天字节跳动的云计算公司火山引擎召开源动力大会，专门发布了 Doubao-Seed-2.1-Pro 等产品。

专门提到了豆包的 18 小时芯片设计，这是真正的工业级应用。

这让我想起了前几天的 Codex 著名 bug。

这导致我最近养成了一个新习惯：每天打开终端，先跑一条命令查磁盘写入量。

不是我有强迫症。发现 Codex CLI 在后台以每秒 5MB 的速度往 SQLite 日志里灌 TRACE 级别的调试信息——一天就是 400GB，一年 640TB。够把一块消费级固态硬盘磨穿好几遍。

我在这边查磁盘，字节跳动的豆包 2.1 Pro 在同一天发布了。Agent 模式自主跑了 18 个小时，完成了一套芯片设计代码。不是 demo，是生产级端到端交付。

一边是 Agent 在造火箭。

一边是水管还在漏水。

这不是某一家公司的问题。这是整个 Agent 行业的激励结构问题。

豆包 2.1 这次发布，最值得关注的反而不是模型跑分。

是 Agent 模式。18 个小时不间断，自己理解需求、自己写代码、自己调试、自己交付。火山引擎的谭待说了一句话：模型好是 MaaS 的第一性原理。翻译一下：基础设施级别的能力，比单个功能的炫酷重要得多。

同一天，微信「小微」也开始内测。14 亿用户，从聊天框里就能调用 AI Agent——不需要下载新 App，不需要学习新界面。

量子位的评测原话是"比微信更好用的是小微版微信"。极客公园说这是"腾讯开始兑现国民 App 的 AI 潜能"。

这两件事放在一起看，信号很清晰：Agent 的能力正在从"能聊天"跨越到"能干活"，从"独立 App"渗透到"超级入口"。

能力层在发生质变。这是真的。

但一个 sqlite 文件，debug 日志不过滤，从 4 月挂到现在。

我和用 Codex 的朋友聊，大多数人根本不知道这件事。直到有人发现自己的 SSD 健康度在肉眼可见地往下掉。

根因很简单：Codex 的日志系统没接上 RUST_LOG 过滤。TRACE 级别的调试信息全量写入了 logs_2.sqlite。对开发者来说，加一个 filter 可能只需要改一行配置。

但这一行配置的优先级，排在了所有新功能后面。

OpenAI 在昨天，codex142 版本进行了修复，核心还是舆论爆炸了，不是他主动修复。

这不是能力问题。这是组织意志问题。新功能、benchmark 提升、PR 亮点——这些有可见度，有资源，有人推动。修 bug、加日志过滤、控制资源消耗——这些没人看见。做好了没人夸，做差了也没人第一时间发现。等到用户 SSD 健康度掉了，那已经是几个月以后的事。

更根本的问题是：大多数 AI 公司的组织结构，还没有为"运营一个生产系统"做好准备。它们仍然按研究机构的逻辑在运转——快速实验、快速发布、快速迭代。但 Agent 已经不只是实验了。用户把它装进自己的电脑，它就在用户的硬件上运行。"快速发布"的另一面，是"用户承担质量风险"。

翻译成企业管理的话：Agent 厂商把质量成本外部化了。日志写盘消耗的是用户的 SSD 寿命。排查时间消耗的是用户的精力。信任损耗由整个行业承担——但没有任何厂商的 OKR 里写着"减少用户硬盘写入量"。

我自己做过企业数字化转型，也搞过云计算架构。2010 年到 2015 年的云计算，和今天的 Agent 行业几乎一模一样。

AWS 的能力增长曲线极其陡峭，但宕机、数据丢失、账单失控的事故频率也极其高。当时行业里的主流声音是：云计算还不成熟，企业不该上云。

后来发生的变化不是技术突然变好了，而是事故够多了，多到行业建立了一整套可靠性基础设施：SLO/SLA 承诺、灾备标准、合规认证、FinOps 成本管控。企业上云不是因为云不出问题了，而是因为它的问题变得可预期、可管理、可追责了。

Agent 行业现在就在云计算的 2014 年。

能力已经足够惊艳了——豆包的 18 小时芯片设计，微信小微的 14 亿入口，没有人能否认这是历史级别的进步。但质量的基线，还停留在"能用就行"。

没有 Agent 工具的 SLO 标准。没有用户数据的处理承诺。没有资源消耗的透明度要求。

在基础设施领域有一个非常基本的判断：一个系统能不能进生产，看的从来不是它最好情况下能做什么，而是它最差情况下会出什么问题。Agent 也一样。

我不是在说 AI 工具不可靠所以别用。恰恰相反——正是因为这些工具越来越强，越来越深入日常工作，质量问题才变得真正要命。

几个你现在就能做的事：

第一，查一下自己的工具链健康状况。

Codex 用户：看 ~/.codex/logs_2.sqlite 的文件大小和写入频率。如果只有一个 SQLite 文件在疯狂增长，大概率你也中招了，赶快升级 142 版本。

Claude Code 这边好得多——日志策略相对克制，sandbox 隔离也减少了意外写入的路径。这是我自己用双工具链对比下来最直观的感受。不是说 Claude Code 没问题，是说它的工程团队在"不出错"这件事上花了更多心思。

这不叫踩一捧一。这叫用脚投票。

第二，选 Agent 工具时把"最差情况"纳入评估。

现在行业里选 AI 工具的标准基本上是：模型强不强、速度快不快、支持什么语言。

应该再加一条：这个工具在没人看的情况下会不会出问题？资源消耗透明吗？日志策略可控吗？错误处理体面吗？

这些问题，比 benchmark 分数更影响日常工作。

第三，建立自己的工具准入门槛。

小团队可以很简单：新工具入工具箱之前，跑一周观察期。监控磁盘、内存、网络。出一次资源失控就降级。

企业应该更正式：Agent 工具链的 SLO 标准——响应时间、资源上限、错误率红线。不达标的工具不进生产。

这不是折腾。这是基础设施的基本素养。

在两个工具链之间来回切换了半年，我现在判断一个工具靠不靠谱的标准很简单：不是它最好情况下多聪明，而是它最蠢的情况下会不会吃掉我的硬盘、烧掉我的时间、搞丢我的代码。

豆包能跑 18 个小时的芯片设计，微信小微能让 14 亿人零门槛接触 Agent——这些都是行业需要的能力峰值。

但如果一个 sqlite 日志能磨穿用户的硬盘，两个月没人修，那行业的质量底线就还在地下室。

这个标准，建议你也用起来。

之前写过 Codex 日志 bug 的具体自查和止血方案，也写过 Codex 正在变成企业 AI 管理系统的入口。这篇是对同一个问题的上层判断——为什么这种 bug 不是偶然的，怎么从工程质量角度选 Agent 工具。