同样的活分三次说，编程智能体花费约翻倍

编程智能体花多少钱，不只看模型和题目，还要看人怎么把需求说出来：同样一件活，分三次交代，智能体的花费约翻了一倍，而做成的比例没有稳定变化。

先说结论。现在流行的编程榜单，几乎都是把一个 GitHub 问题一次性交给智能体，看它能不能交出通过测试的补丁，顺带算出单题成本。JetBrains 研究团队的新论文用自家 IDE 里的真实会话说明，开发者不是这样用智能体的。我们的看法是：拿榜单上的单题成本去估自己团队的账单，大概率会估低；榜单测的是「一次说清楚」的理想情况，而这种情况在真实使用里只占一部分。

发生了什么

据 JetBrains Research 10 月 20 日的博客，团队拿到 4,782 次软件工程师在 JetBrains IDE 里与编程智能体的会话，约 1.4 万条开发者消息。一半的会话（50.9%）只有一条消息；论文重点看的是至少三条消息的长会话，占 33%。全部消息里，修 bug 占 26%，加新功能占 19%，合起来不到一半；剩下的是解释项目代码、一般编程问题、做计划、代码审查、重构、调试和执行命令。作为对照，用同一个分类模型去标公开榜单 SWE-Bench Pro 的题目，55% 是新功能、39% 是修 bug、6% 是重构，没有别的类型。

论文正文（arXiv 2610.09633）接着做了一个实验。他们把 SWE-Bench Pro 的 731 道公开题，用模型改写成三条按顺序给出的需求，智能体做完第一条才看到第二条；原需求一条不少、一条不加，测试不变。31 道没通过拆分检查被剔除，剩 700 道。用同一个智能体框架、四个模型（OpenAI 的三个 GPT 型号和 Google 的一个 Gemini 型号）各跑三遍，结果是：分步给需求让平均花费约翻倍，成功率的变化在不同模型之间方向不一，幅度和重复运行之间的波动相当。在中间插入关于仓库的提问后，花费再往上加一些，回答准确率在四个模型间为 69.8% 到 83.0%。拆分后的题目已公开在 Hugging Face 的数据集页面。

为什么这件事重要

拿一件具体的事说。论文举了一个浏览器项目的例子：原题是约 1,000 个字符的一条消息，把问题、原因、修法和边界情况全写清了；拆开后，第一条只说「修好这个网站打不开的问题，用补丁方式兼容旧引擎」，边界情况放到后面两条里。据博客的描述，长会话里的开发者常常是这样提需求的：先说个大概，中间问一问、审一审，再补条件。分析推断（依据：论文只报告了花费翻倍，没有拆解原因）：智能体每收到新的一条，可能要重新查看代码、重新运行测试，这是花费上升的一个可能来源。

分析推断（依据：论文的单次与分步对照，以及博客给出的真实会话分布）：站内此前多篇稿件讨论过「按完成一个任务的成本」比较模型，那些单题成本基本都是在一次给全需求的条件下测出来的。如果一个团队的工程师习惯边看边改，实际花费落在榜单数字之上是更可能的情况，差多少要看各自的对话方式，不能直接套用「翻倍」。

最强反方

最有力的反驳是：这只是一家公司、一种用户群体的数据，而且会话来自 JetBrains 自家 IDE 里的智能体，强调「交互方式」也契合它的产品叙事。论文自己也承认，三个公开会话语料彼此差别很大，自家的长会话只是其中一种用法；分类靠模型打标签，三个分类模型的一致率是 76.1%，没有人工标注的准确率集。再者，实验用的是一个轻量的公开智能体框架（mini-swe-agent），如果商用产品做了缓存和上下文压缩，分步给需求的额外花费可能小得多。

我们部分让步：「约翻倍」不能当成通用倍数，换框架、换产品都可能不同，我们在标题里写的也只是这次实验的结果。但我们仍坚持论点的方向，原因是实验设计本身是对照的——同样的题、同样的测试、同样的框架，只改了需求给出的方式，花费就明显变了，这说明交互方式是测成本时绕不开的一个变量，而现有榜单基本没把它算进去。

我们不知道什么

• 这 4,782 次会话来自哪些产品、哪些用户、什么时间段，博客和论文只给了汇总统计，我们无法核对样本是否有偏。
• 在带缓存和上下文管理的商用编程智能体上，分步给需求的额外花费是多少，论文没有测。
• 成功率「没有稳定变化」是在 700 题、每种设置三遍的条件下得出的，更多重复或更难的任务上会不会出现差别，目前不知道。

接下来看什么

一看主流编程榜单会不会加入分步给需求或中途提问的题型，并单独报告花费；二看智能体厂商公布单任务成本时，是否写明交互方式；三看有没有其他团队用自己的真实会话数据复现这次的对照。