人类觉得难不难，预测不了 Agent 要花多少钱

很自然的期望是：资深工程师扫一眼工单，就能猜 Agent 会花多少；或者让 Agent 先探索一下，再自己报价。2026 年在 OpenHands 与 SWE-bench Verified 上的研究显示，这两种期望都偏弱。

人类难度几乎是另一条轴

在 SWE-bench Verified 中，专业程序员依预期解题时间把任务分成三档：少于 15 分钟、15 分钟到 1 小时、大于 1 小时。与 Agent 实际 Token 消耗相比，肯德尔相关系数仅约 0.32，属极弱相关。

• 约 6.7% 人类标为「少于 15 分钟」的简单题，实际消耗仍高于「大于 1 小时」困难题的平均值
• 约 11.1% 人类标为「大于 1 小时」的困难题，实际消耗反而低于「少于 15 分钟」简单题的平均值

说穿了其实直觉：一个小小语法问题，可能逼 Agent 扫遍大型仓库；一个看起来很可怕的架构问题，却可能靠预训练里的模式几轮就解决。人类复杂度与 Agent 计算开销，不是同一个旋钮。

让 Agent 自预测，也只是粗信号

研究团队把目标改成：保留工具能力去探索仓库，但不修 bug，而是预估输入、输出与总 Token。皮尔逊相关多停在弱到中等；文中突出的较佳数字是 Claude Sonnet 4.5 对输出 Token 约 0.39，多数模型的输入预测约在 0.2–0.3。

更糟的是，模型会系统性低估——尤其是输入 Token。即便实际消耗到数百万，预测点仍远低于完美预测对角线。拿掉上下文示例后，低估不但没消失，反而更严重。这比较像结构性盲点：模型难以预判长上下文、多轮交互会把输入账单炸到什么程度。

产品上仍有用的做法

运行前的精确报价是个坏承诺。粗粒度信号仍然有用：预算上限、消耗预警、中途授权，以及承认 Agent 波动的定价。不要把「这题感觉简单」当成成本预测——也不要把 Agent 的自估当成确定发票。