Signal #25：更贵的模型，为什么完成任务反而可能更便宜？

如果一个模型的价格是另一个模型的两倍，我们通常会认为，用它完成任务也会更贵。但在 Agent 场景中，仅凭 Token 单价推断任务成本，已经越来越不可靠。

JetBrains 最近在《Securing the frontier: How JetBrains evaluates and deploys Claude Fable 5》中介绍了自己的内部模型评测体系。与只比较公共 Benchmark 或 Token 单价不同，他们使用私有代码仓库和 Monorepo 构建任务集，同时维护“质量最好”“单任务成本最低”和“速度最快”三类排行榜。

其中一个很有意思的结果是：Fable 5 虽然每 Token 更贵，但在部分复杂任务中通过率更高、执行步骤更少，最终的单任务成本反而更低。在 JetBrains 公布的 Python 内部测试中，Fable 5 的通过率为 44.3%，Opus 4.8 为 28.2%，完成任务所需的步骤约少 22%。

这些数字来自 JetBrains 自己的任务集，不能直接推广到其他团队，但它指出了一个越来越重要的问题：

当模型开始以 Agent 的方式执行任务，我们究竟应该按什么单位计算成本？

在传统的大模型调用中，成本相对容易计算。输入多少 Token、输出多少 Token，再乘以模型单价，就可以得到一次调用的大致费用。

Agent 执行的却不是一次孤立调用。以一个代码修改任务为例，它可能需要读取仓库说明，检索相关文件，理解调用关系，制定修改计划，调用工具编辑代码，再运行测试和静态检查。如果测试失败，它还需要重新定位问题、继续修改，直到结果满足交付要求。

一次任务因此可能包含十几次甚至几十次模型调用。模型之外，还会消耗代码执行环境、搜索与检索工具、浏览器、数据库以及测试基础设施。任务如果中途失败，之前的消耗并不会自动消失；如果需要工程师接手，人工确认和返工同样构成交付成本。

从这个角度看，Token 单价描述的只是一次模型调用的边际价格。企业真正承担的，则是整个执行链条的成本：

一次任务的总成本，包括模型调用、工具与运行环境、失败重试、结果验证，以及必要的人工介入。

实际统计时，可以先区分两个层次：模型、缓存、工具和运行环境构成直接执行成本；再把验证、失败重试和人工介入计算在内，形成完整交付成本。两种口径服务于不同的管理目的，但都比单独比较 Token 单价更接近一次任务的真实代价。

这也解释了为什么低价模型未必带来低成本。如果它需要更多轮调用、更长的上下文和更多人工纠正，完成同一个任务的费用可能更高。反过来，一个单价更高的模型，如果能够用更少步骤得到可接受的结果，单任务成本反而可能下降。

除了模型能力，Agent Session 的组织方式也会直接改变成本。

Anthropic 在《Maximizing the value of your Claude Code sessions》中提到，按照其计费结构，输出 Token 的单位成本大约是输入 Token 的五倍；模型、Thinking Effort、Fast Mode 和 /compact 等配置还可能改变 Prompt Cache 的行为。

更容易被忽略的是，CLAUDE.md、MCP Tool Definition、已经读取的文件和命令输出，都会进入 Session 上下文。随着任务继续，模型在后续调用中需要不断处理这些内容。

如果测试输出了几千行日志，Agent 以后的每一轮都可能携带这部分历史；如果加载了大量暂时用不到的 MCP 工具，它们的定义也会持续占用上下文；如果一个复杂任务始终停留在同一个 Session，中间产生的分析和失败尝试还会继续累积。

因此，同一个模型、同一个任务，仅仅因为上下文组织方式不同，最终成本也可能出现明显差异。

这也是为什么 Anthropic 建议将长期规则与按需加载的 Skill 分开，关闭暂时不用的 MCP Server，减少测试和日志中的噪声，并使用 Subagent 隔离会产生大量中间内容的任务。这些做法看起来属于上下文工程，背后其实也是成本工程。Agent 的费用不仅取决于用了什么模型，还取决于 Session 以什么形状增长、缓存是否稳定，以及多少无效内容被反复处理。

如果不再只看 Token，下一个问题就是：什么叫完成一次任务？

Agent 写出了代码，并不等于任务已经完成。代码可能无法编译、测试没有通过，也可能没有满足原始需求。即使 Agent 顺利提交了 Pull Request，最终仍可能因为 Review 不通过而被重新修改。

因此，“单任务成本”只有和明确的验收标准结合，才是有意义的指标。

对于代码任务，这个标准可能是测试和静态检查通过，并且修改最终被 Review 接受；对于数据分析，可能是结果能够复现并通过业务校验；对于浏览器自动化，则可能要求流程成功完成，同时没有发生重复提交或其他副作用。

不同任务之间也不能直接混在一起比较。修复一个拼写错误和完成一次跨模块重构，本来就不应该使用相同的成本基线。企业需要先建立可比较的任务类别，再在固定的质量门槛下观察：

这里更准确的指标不是笼统的 cost per task，而是：

cost per verified successful task——完成一个经过验证并被接受的任务，需要多少成本。

最近发布的 Evo-Bench 从另一个角度提供了支持。它评测的是 Agent 改进自身 Harness 的能力。这里的 Harness，可以理解为围绕模型组织提示词、上下文、工具、执行循环和验证过程的运行框架。

实验显示，即使不直接训练模型，改进 Harness 也可以提高任务表现，但提升程度高度依赖具体领域：在搜索和通用任务上效果较好，在 Office 等特定工作流中仍然困难。Harness 一旦改变任务成功率，完成一次成功任务所需的平均成本也会随之变化。

因此，模型性能需要放在具体执行环境中观察。最终结果来自模型、Harness、工具和任务领域的共同作用，成本评测也需要把这些因素放进同一条执行链中。

当成本单位从 Token 转向任务，企业选择模型的方式也会发生变化。

过去常见的问题是：“哪个模型最好？”接下来更有价值的问题可能是：“对于这类任务，哪一种模型和执行配置最划算？”

简单、重复、容易验证的任务，可以交给速度更快、价格更低的模型；复杂的调试和跨文件修改，则可以使用能力更强的模型。Agent 还可以先由低成本模型尝试，在置信度不足、测试连续失败或任务风险升高时，再升级到更强的模型。

模型之外，Thinking Effort、上下文范围、可用工具、是否启用 Subagent，以及验证强度，都可以成为一次任务的运行参数。

Visual Studio 已经开始允许开发者为 Copilot 选择 Low、Medium 和 High Thinking Effort，同时展示模型能力、上下文窗口和成本。更新说明

AWS 展示的 Agent 架构，则让 Claude Haiku 负责判断和路由任务，由 Claude Sonnet 与自部署的 Qwen 分别处理不同领域的工作，同时共享同一套 Agent Runtime。案例

NVIDIA 开源的 Switchyard 也在探索类似方向：在同一套服务接口后面，根据任务选择弱模型、强模型或分阶段升级策略。它目前仍处于早期阶段，但反映出的方向很明确——企业不必再为所有任务静态绑定同一个模型。

模型路由由此逐渐成为 Agent 执行系统的一部分，需要在成功率、延迟、风险和总成本之间寻找更合适的组合。价格较低的模型负责能够稳定完成的工作，更昂贵的模型则被保留给真正需要它们的任务。

我们曾在《Agent 开始进入团队账本》中讨论过：当 Agent 从个人工具进入团队级生产流程，成本、质量、效率和收益也需要被持续记录。

OpenAI 最新的企业使用研究显示，使用深度最高的前 10% 企业，每个活跃用户产生的输出 Token 是典型企业的 8.3 倍；它们每周使用 Plugin 和 Skill 的用户比例也明显更高。OpenAI 将输出 Token 视为使用深度的代理指标，并没有把它直接等同于 ROI。

这一区分非常重要。输出更多 Token，可能意味着 Agent 承担了更多工作，也可能意味着上下文过长、执行效率较低或者发生了大量重试。仅看使用量，无法判断团队是否真正得到了更好的结果。

GitHub 的 AI Usage Report 已经可以按模型拆分 Input、Output、Cache Read 和 Cache Write Token，并将其与实际消耗的 AI Credits 对应。更新说明

这解决了“钱花在哪里”的一部分问题，但下一步还需要继续把这些消耗关联到具体任务、Pull Request、测试结果和最终交付。一套更完整的 Agent 账本，不应只记录模型调用了多少次、消耗了多少 Token，还应该能够回答：

这笔消耗对应哪个任务？任务最终成功了吗？经过了多少次尝试？使用了哪些工具？人工参与了多久？结果是否真正进入了生产流程？

只有这些信息被连在一起，企业才有可能判断某种模型、Harness 或工作流是否真的划算。Token 单价仍然重要，但它更像执行系统中的一个参数，而不是最终答案。

当 Agent 开始承担完整任务，企业需要优化的也不再只是“每百万 Token 能便宜多少”，而是：

在满足相同质量和风险要求的前提下，完成一个经过验证的任务，究竟需要付出多少成本。