评估编程 Agent 成本要算成功任务耗时
文章以 DeepSeek 模型的任务成本为例，将沙箱、CI、并发资源和人员等待纳入核算，强调比较每个成功任务的总成本。相同权重在不同托管端的吞吐差异，也会影响任务耗时和所需并发量。
AI 深度解读
当一次编程任务的 token 费用降到不到 20 美分，继续盯着每百万 token 的报价，可能已经抓错了成本重点。作者以 DeepSeek V4.1-Flash-1017 为例提出：运行环境占用多久、并发槽位被卡住多久，以及人要等多久，才更可能决定 agent 的实际账单。
这篇短文值得看的地方，是把模型选型从「谁的 token 便宜」推进到「谁能以更低总成本完成任务」。不过，文中给出了计算示例，没有展开完整测试过程，结论需要带着前提读。
token 很便宜，为什么任务仍然可能很贵
作者称，DeepSeek V4.1-Flash-1017 解决一个 SWE 基准任务的 token 成本略低于 20 美分。这里说的是单个任务的 token 支出，并不是所有编程任务的平均成本，也不是整套 agent 系统的总成本。
把等待期间的资源占用算进去，作者使用了这个近似公式：
cost per task ≈ token_cost + wall_clock_hours x hourly_rate_of_everything_waiting
要看的是第二项：任务从开始到结束的实际耗时，也就是墙钟时间（wall-clock time），乘以等待期间所有相关资源的每小时成本。
沙箱、CI runner、并发槽位，以及等待结果的人，都可能进入这笔账。token 费用越低，这些开销在总成本里的占比就越值得关注。不过，各项成本如何折算，原文没有给出统一口径。
同一个模型，为什么还要挑托管服务
作者列出的例子是：同一套采用 MIT 许可证的模型权重，在 OpenRouter 不同托管服务上的生成速度，从每秒 24 tokens 到每秒 290 tokens 不等，价格却没有随速度明显变化。
因此，选择模型名字之后，还没有完成选型。具体由谁提供推理服务，同样会影响任务耗时。
耗时又会传导到并发需求。按每小时 1,000 个任务计算，作者给出两组数字：
| 生成速度 | 单任务耗时 | 所需并发槽位 |
|---|---|---|
| 210 tok/s | 7.6 分钟 | 约 127 个 |
| 42 tok/s | 23.5 分钟 | 约 392 个 |
这里的计算逻辑是：任务到达速度不变，单个任务占用槽位越久，同时运行的任务就越多。
但别把表格读成通用换算关系。生成速度下降多少，完整任务耗时不一定按相同比例增加；agent 还可能花时间调用工具、运行测试和等待外部服务。原文没有交代这些耗时的具体构成。
跑得快，还得看成功了多少次
作者进一步强调：应该比较每个成功任务的成本，而不是每次调用或每个 token 的价格。
文中的例子是，耗时 8 分钟、成功率 55% 的方案，与耗时 12 分钟、成功率 85% 的方案大致打平。前者单次结束得快，但失败消耗也要由成功结果承担。
单次任务便宜，不等于拿到一个可用结果便宜。
这个比较需要相近的资源单价，以及一致的「成功」定义。如果一个方案只是生成了补丁，另一个要求测试通过，两者的成功率就不能直接相除比较。
价格和版本也会干扰结果。作者提醒，DeepSeek direct API 在工作日高峰时段价格翻倍；deepseek-flash 别名会在发布日切换指向，因此应固定版本。原文没有说明高峰窗口的具体时间，不能据此安排调用时段。
我的判断
我认同把「每个成功任务的总成本」作为评估单位。对于持续运行、需要沙箱和 CI 的编程 agent，它比单独比较 token 单价更贴近实际支出，也比只看生成速度完整。
但这篇短文还不足以证明某个托管服务最划算。它没有展开任务样本量、重试策略、成功判定和资源计费方式，也没有提供完整的服务对照实验。相关数字应视为作者给出的示例，不能直接套进一般团队的预算。
原文提到另有完整算例、成本脚本和 Python 测量框架，但当前材料没有提供这些内容。因此，能拿走的是核算方法，具体选型仍要靠自己的任务验证。
能拿来做什么
- 给日常 AI 编程任务同时记录 token 支出、开始到结束的耗时和最终是否成功，再统计每个成功任务的平均成本。
- 如果 agent 会启动沙箱或 CI，把环境占用时间一起计入；评估托管服务时，用同一批任务比较实际完成时间。
- 批量运行任务前，用每小时任务量乘以平均任务耗时估算并发需求，再结合自己的排队和失败情况调整容量。
- 做成本对比时固定 DeepSeek V4.1-Flash-1017 等具体版本，避免
deepseek-flash切换后，把模型变化误判成服务性能变化。