为什么 Theo 更看重编程智能体的稳定性，而非最佳表现

David Cramer 建议使用 Fable 或 Astra 的人试试更便宜的推理模型，比如 Opus 和 Sol，因为他们的任务可能不会表现出差异。我强烈反对把它当作普遍结论。我的意思不是便宜模型永远不够用，而是你如何定义任务，会改变你看到的差异。

我想先把 Astra 从其他比较中分开。根据我的经验，它能做到令人惊讶的事，也会作出出人意料的糟糕决定，所以我理解为什么有人在某些情况下更喜欢 Sol。我的模型偏好基于自己的工作，不能证明普遍排名。

我画了一张粗略的输出质量图，表达自己的印象：Astra 的高点更高，低点也更低，而 Fable 更稳定。这是主观示意图，不是基准数据。我认为人们常常注意到令人惊艳的最佳结果，却忽略最差结果对实际使用的影响。

这两种错误我都犯过：看到惊艳的结果就高估模型，也会因为一次特别糟糕的运行直接否定它。日常工作中，我往往更看重提高表现下限，而不是追求非凡的上限。能解决难题的模型，如果连基本指令也处理不好，仍可能打乱工作流程。

如果任务是一张精确写明文件和预期改动的工单，多个模型都可能达到要求。一次糟糕的失败也会让我们降低期望，只敢提出更小的任务。我想说的是，应该重新考虑让智能体承担工作流中的多少部分，而不只是某一次代码修改有多难。

我把这叫作提示词的宽度：从最初的问题到预期完成状态有多远，中间包含多少步骤。范围更宽的任务可能遇到更多出错机会。我的图表达的是稳定性如何影响体验的一种假设，并非特定模型的实测概率。

当前沿模型发生变化时，我会重试其他模型失败过的任务，再根据结果调整期望。对于描述充分的 Jira 工单，我承认 Cramer 的观点：多个模型都可能可靠地完成。让我在意的差异出现在智能体承担更多周边工作时。

例如，用户给我发来 T3 Code 故障截图。我可以在手机上把截图交给智能体，要求它调查、修复和测试问题，录制演示，提交 PR 并监看审查。重要变化是端到端的工作范围和明确的结果，并不一定是某个单独修改更难了。

这样的运行可能消耗更多 Token，但工程师的时间也有成本。如果投入更多能让有价值的工程师交付更多工作，我愿意付钱。这是一项商业判断，不是经过测量的生产率结果；团队需要比较实际用量、质量、人工审查和错误成本。

许多开发者给出的提示词简短集中，并在智能体工作时监督它。我鼓励大家在适合的情况下测试更长的工作流程。当智能体出错时，可以询问哪些文件和工具输出让它走到了那里；不过模型自己的解释未必是行为的真实原因。

一位开发者将通宵运行作为发现环境中反复出现的障碍的方法，而不只是为了产出代码。长时间运行可能碰到短任务较少遇见的阻碍。检查失败案例，有助于发现工具、指令、测试或代码库本身需要改进的地方。

我认为，如果代码库总是让新智能体困惑，新开发者加入时也可能觉得困难。这是值得调查的问题，但并不能证明所有智能体错误都是代码库造成的。我也承认，自己使用 T3 Code 和其他项目的经验未必适用于每个组织。

要扩大工作流范围，可以描述问题，让智能体自己寻找相关文件；也可以要求它运行模拟器、验证改动并在 PR 中附上视频。合适的权限和检查取决于任务。视频能帮助审查者看到结果，但不能证明所有行为都正确。

我展示了 Maria 的一个 PR，其中包含改动的可视化说明。对我来说，有两个有用的问题：智能体能在没有人工输入的情况下工作多久？人回来时，结果有多大可能可以使用？二者有关但不相同；运行时间长，结果仍可能不合格。

如果智能体工作半小时后反复遇到相同问题，就调查并改进工作流程。我提到过持续数小时、最终产出可供审查的 PR 的个人经历，但这些例子不能证明长时间自主工作在每个代码库中都可靠。

我的示意图还说明了为什么狭窄任务可能看不出模型差异：两个模型在短区间内都可能超过要求。工作流范围扩大后，出错机会也会增加。我偏好 Fable，是因为在我的工作中它似乎较少犯打乱流程的错误，并不是因为它的每次结果都更好。

Maria 说，她花了几天查看运行记录、改进技能，之后才能用一条提示词获得更顺畅的结果。这些准备工作很重要：自主运行成功不仅取决于模型，也取决于环境和工作流。比较方法时应把准备成本算进去。

我讨论了每月数百美元的订阅，也承认这对许多学生、富裕国家以外的人和其他开发者来说难以承担。我对套餐所含 Token 价值的估计取决于当时的价格和限制。便宜模型仍可能是正确选择，而总成本还包括重试和人工时间。

我的观点是，更强的模型能减少我在运行前后投入的工作。David Khourshid 等人认为，许多任务不需要最昂贵的模型；对他们的任务而言，这可能是真的。实际问题是额外的模型成本能否为你自己的工作流带来足够价值。

一位观众质疑我使用“指数级”一词后，我让智能体分析自己的使用历史。由于换过电脑，数据从 3 月才开始。在我描述的比较中，提示词运行时长的中位数从 53 秒上升到 2 分 20 秒，第 95 百分位从不到 7 分钟上升到超过 16 分 20 秒。

日志还显示，不同月份较长运行的时长增加，其中一次月度比较约从 12 分钟增至 22 分钟。这些是对我个人行为和环境的观察。任务、提示词、模型、工具以及我愿意等待的时间都可能变化，因此数字本身无法证明增长由新模型造成。

接着我给出一个简化计算：假设每个十分钟区间相互独立，失败概率都是 5%。三个区间都不失败的概率为 0.95 的三次方，约为 85.7%；24 个区间约为 29%。这展示了固定、独立概率下的累积效果，并非对真实智能体运行的测量。

如果每个区间的失败概率从 5% 降至 3%，同一个独立模型给出的四小时成功概率约为 48%，而原来约为 29%。大约 19 个百分点的差异说明，小变化在重复步骤中可能很重要。相关的失败、恢复过程和条件变化都可能让真实结果大不相同。

我将目前的长时间运行与过去的工作流对比：过去可能需要详尽规格，也可能在上下文压缩时失去进度。这是我的经验，并非受控研究。规格和明确验证仍可能很有价值；长时间运行是否省事，取决于环境和结果。

最后，我与 Cramer 和其他资深开发者的分歧在于准备与审查：我认为有些人可能只委派编码步骤，保留了过多周边工作。这是我对他们工作流的假设，无法仅凭一篇帖子证明。可以尝试改变任务范围、衡量结果，再选择与风险相符的监督程度。