北京
同一个模型，不换更强的版本，只换执行策略，编码智能体能不能更早交付？Sunny Code 做了一组对照实验：模型和推理设置全部固定，只比较 Fast 与 Standard 两种执行策略。
结果很直接：在 9 个小任务上，Fast 在全部 36 组配对观测中都更早完成本地交付。按六个「队列×模型」聚合来看，平均完成时间下降 50.4%–80.1%，平均新增 token 用量下降 10.2%–38.7%。
这里有一条必须先划清的边界：这组数字衡量的是智能体结束任务所需的时间。独立的验收检查是在计时结束之后才跑的，不计入这段时长。交付更快，不等于每一次交付都通过。
实验怎么搭的
用的是 GPT-6.1 Sol 和 DS4.1 Flash，两者都开低思考档。每个任务在每个模型、每种模式下各跑两次：9 × 2 × 2 × 2 = 72 次运行。
配对时固定了任务、代码快照、依赖、模型和推理设置。运行是串行的，模式顺序交替。比较的是作为完整配置的产品模式；服务商缓存和服务负载没有被完全控制。
任务覆盖七个代码仓库。其中「廉价验证」类仓库的原生测试套件基线中位数约为 0.7–2.7 秒，用来检验当仓库测试本身已经很便宜时，这个结果是否依然成立。
时间与 token 的账
每个单元格是六次运行的平均值，失败的交付也计入其中。Fast 的思路是让智能体把注意力留在任务上，限制额外工作，在完成修改并检查后尽快交付。
两种模式执行的验证并不完全相同，所以这些数字不能被理解成「同样的活干得更快」。
新增 token 指服务商上报的输入加输出，不含 cacheRead 和 cacheWrite，既不是总处理 token，也不是真实账单。token 降幅和时间降幅并不同步：例如 Sol 在无测试队列中新增 token 少了 10.2%，完成时间却早了 51.1%。此前那组实验的 token 统计包含缓存输入，百分比不能直接对比。
通过的和没通过的
计时结束后，实验在交付代码的独立副本上跑了行为检查，同时跑可用的仓库回归测试。失败的运行保留在结果里，没有先修好源码再算作通过。
在 slugify 任务中，ASCII 输入本应绕过音译后端，但旧测试仍然期待后端初始化。更新后的上游测试在补充诊断中通过了，但这不能替代最初的失败。
通过数量相等，也不等于质量等价。留在 Standard 交付里的测试，可能还有这套计时指标捕捉不到的长期维护价值。
这组数据说明了什么
智能体的交付策略，值得和模型选择放在一起衡量。在这些任务上，即便原生验证很便宜甚至不存在，Fast 依然缩短了本地交付时间。实验没有单独隔离某一项实现改动的贡献。
样本是刻意挑选的 9 个任务、每种配置两次重复，不是 36 个独立任务。如果你的「交付」定义要求独立验收通过，那就得把验收时间和返工一并算进比较里。
所以问题回到定义本身：编码智能体的交付边界，画在改完代码那一刻，画在本地检查通过那一刻，还是画在独立验收之后？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
