笔记
油门到底
最近，我开始给自己写过的一些 AI 基础设施安排退休。
VASMC 和 Symbiont-d 就这么安静地埋了。基础开销在可完成工作量中越来越不显眼，Infra Sentinel 的意义也开始变弱。Dev Mesh 也不好说：如果模型厂商自己的框架把 agent 之间的通信、交接和协作作为一等公民，再维护一层自己的 mesh，没有多少意义。
它们不是不好，有些东西跑得很顺，只是坑没了。
几个月前，我还在考虑一个长期独立工作的 agent 应该怎样持续回应。不能太沉默，也不应该是个话唠；什么时候主动冒泡，什么时候继续工作，什么时候主动探索，都需要设计。现在，OpenAI 的 Dots 已经把云端常驻、持续工作、中途沟通和语音通话放在一起，也可以把任务交给 Codex。对话不再是一次提问对应一次回答，而是在一段持续工作中随时发生。
这些功能背后的设施，对个人而言维护成本很高。现在平台打包提供了，Symbiont-d 这种连实时交互都还不够利索的新古董，实在没必要留着过年。
但这也不值得顺手给自己颁一张先驱证书。
AI 时代，总有人看到行业往自己设想的方向发展，就觉得远见得到了验证。可很多人用过一阵子，自然就会想到一块去。云端常驻的 agent、人和 agent 的连续沟通，未必需要多么独到的洞见。真正困难的，可能一直是把它们做成可以放心交付、舒适使用的产品。
想到一个方向，做出一个 demo，把它跑成自己的工具，再让大量用户愿意长期使用，是几笔不同的账。前面越来越便宜，不代表后面的摩擦、运维和真金白银已经消失。先做出来，当然有价值，但它不自动意味着先占住了未来。行业把这一层补上以后，也得承认有些东西已经不用自己做了。
越来越快的循环
两个多月前，我写过一个为旅行而诞生的软件。旅途中遇到不顺心的地方，晚上回酒店改一改，检查、部署，第二天继续用。修改不必等到旅行结束，反馈能在原来的情境里回来。
现在，云端 agent 又把时间单位改了一次。我不再需要先回到电脑前，恢复开发环境，再挤出一段时间修改。一句聊天、一次通话，把问题和预期讲清楚，它就可以继续往下做。也许半小时以后，改善后的版本已经部署好，我还在做刚才那件事。以前按天发生的循环，开始按小时发生。
Ultrafast 加快的不只是文字出现的速度，还能缩短长任务里一轮轮推理和修正的等待。工具执行和网络往返仍然需要时间，但只要模型推理占的时间足够多，推理提速就能继续压缩整个循环。
Alok 用 Qwen 3.8 27B 演示按需生成网页的实验，已经让人看见另一种使用感。按演示者的说法，模型每秒输出近两千 token；界面不再总要提前存在，也可以随着操作出现。页面生成出来，当然不等于产品已经完成验证。它展示的是某一段等待开始短到不再像等待。
如果生成、执行和检查都能足够快，一部分局部修改就可能留在同一次连续交互里完成。指出问题，看见变化，再调整，继续使用。开发不再总是使用之外的一件事，而可能成为使用中的一个动作。那时候，“开发一次”这个说法都会显得有些生硬。
工程方法也要重新算账。过去迁移很贵，我们保留旧接口、旧结构和兼容层，尽量不动已经运行的东西。如果一次迁移可以自动完成并通过验证，继续维持两套结构，反而可能比一次迁走更贵。兼容仍然有价值，但为兼容而永久保留旧实现，不再天然是一种美德。
开发、测试和使用可以更紧密地交错，验证、迁移和回退却不能顺便省掉。它们应该一起进入更短的循环，而不是被“实时”两个字挤出去。
放慢节奏
最近行业还有一场颇有喜剧效果的插曲。Dario 高喊，我们要放慢前沿。Sam 和 Elon 随后也表示赞同。
然后，在我看到的信息流里，GPT-6 Sol 和 Grok 4.7 挨了一轮“不及预期”，Anthropic 则接连端出 Opus 5.5 和 Sonnet 5.5。发布节奏与减速口号摆在一起，节目效果很足。至少看起来，Dario 可能是被 Elon 的单踏板模式坑了。
不过，对使用者来说，最值得放慢的，未必是模型。我看到过一个调侃，大意是：Astra 发布以后，电脑里多了一堆不知何用的 3D 模型；Opus 5.5 发布以后，又多了一堆不知何用、但是很酷的动画。
模型越来越强，工作流越来越顺，但你真的有足够值得实现的愿望吗？过去，一个想法要付出几天甚至几个月的实现成本，人多少会先掂量一下。现在，随口说一句，东西就出现了。实现摩擦被消除以后，原来藏在摩擦里的那次犹豫，也可能一起消失。
于是，额度快重置了，要找点事情做；模型升级了，要造点东西试；第一版出来了，模型又热情地建议第二版、第三版。人以为自己不断产生新想法，实际上可能只是不断接受下一项任务。哪怕只是许愿，也值得问一句：这是你的愿望吗？
我可以接受一个 agent 跑八小时，其中大半时间没有直接产出。只要它在检验真实假设、发现边界、排除路径，这些时间就有价值。为了省掉它的探索，反而让我高频介入，并不划算。
需要分清的是：它在扩大我们对问题的理解，还是只在扩大仓库。前者可以继续烧。后者哪怕每次都交付成功，也可能只是在不断生产债务：以后还要花额度维护，自己又舍不得放下。
等世界回答
模型可以更快，测试可以并行，agent 可以复制，开发 loop 可以从一天变成一小时，再接近实时。但使用经验不会因此自动快一百倍。
一个工作流是不是舒服，要真的使用。一个架构是不是合适，要承受变化。一个新产品有没有解决问题，不能只看生成时是否漂亮。
对模型自己的迭代，我也有同样的疑问。递归自我改进可以加快很多过程，但不能把学习已有知识的速度，直接外推成创造新知识的速度。人类几千年探索留下的结果，已经被整理成概念、教材、代码和实验记录。模型能够迅速吸收它们，不代表第一次得到这些结果也同样容易。
当现成知识不够用了，下一步仍然可能需要实验、测量和漫长的观察。复制一万个模型，可以扩大探索、改进实验设计，却不能顺手复制一万个已经完成的实验，更不能要求所有结果即时返回。
物理世界怎么教碳基做人，也会怎么教硅基。换一个更聪明的研究员，不会让它改掉自己的规律。
而反馈慢，也不意味着可以放心一路加速。有些错误会先发生，代价很久以后才显出来。该等待的时候，得主动留下观察的距离，不能总等撞到墙，才发现原来这里需要刹车。
回到眼前的软件，也一样。Opus 做出的画面，我可能亲手剪不出来，但它表达得对吗？符合我的意图吗？Astra 写出的代码已经运行成功，但一个月后还有必要存在吗？当初为模型补上的结构，现在究竟还在帮忙，还是已经开始挡路？
碳基的脑子，不能因为有了硅基，就只剩下点击“继续”的职责。
油门到底
我曾经写过，速度的价值，是缩短判断接触现实的距离。这个距离还在继续缩：一天，几个小时，几十分钟，也许以后只是一次连续交互里的几次呼吸。
它让更多东西来得及被尝试，也让更多旧结构来得及被推翻。很多今天仍被叫作“AI 工程”的方法，可能还没来得及形成护城河，就成了默认能力。
这没有什么可惜。软件因为一个问题出现，问题消失了，它也可以消失。不能因为当初认真写过，就一直舍不得埋。
油门可以继续踩。让能压缩的等待尽快消失，让能验证的事情尽早得到结果，也让那些只为旧限制存在的设施尽快退休。但不必为了维持速度，不断给自己制造下一项任务。我们需要的不是更多已经生成的东西，而是更少未经判断就留下的东西。
再往前，等的就不只是模型了。
是世界的回答。