2026 年，开源模型把 Agent 单任务成本打到了去年的 1/50——但桌面端场景下，token 单价远不是成本故事的全部。本文从真实数据出发，拆解 Agent 的完整成本结构。
2026 年 7 月，Fireworks AI 发布了一组让业界重新算账的数据：开源模型 Kimi K3 在真实 Agent 任务中的单次成本可以做到闭源旗舰模型 Fable 5 的 1/50。但如果你以为 Agent 的成本故事到此为止——选个便宜模型就完事了——那你还漏掉了桌面端场景下真正吃预算的两个黑洞。
在讨论成本之前，先把量级搞清楚。Fireworks AI 在约 1,030 个真实 Agent 任务上的实测数据[1]揭示了几个关键数字：
这意味着什么？Agent 的 token 消耗不是固定的——同一个任务交给不同模型，轮次和 token 量可能差一个数量级。做成本测算时，不能只比 token 单价，必须把「这个模型在你这类任务上会跑多少轮」一起算进去。关于 token 计费机制的更多细节，我们在AI 应用架构成本测算中做过更系统的拆解。Fireworks 的文章直接给出了结论：单模型跑所有任务是浪费，而且也不再是 SOTA。
K3 能在 agentic 任务上压到 Fable 的 1/50，靠的不是单一魔法，而是三个因素叠加[1]：
对于桌面端场景，这一点尤其关键。桌面端跑不了 405B 参数的巨型模型，但一个精心微调的 7B–70B 开源模型配合 prompt caching，完全可以在代码补全、本地文件操作、终端命令生成等高频任务上替代云端 API——成本从「按 token 付费」变成「一次性硬件投入 + 电费」。
把 Agent 搬到桌面端，成本结构会发生根本性变化。云端模式是纯 OPEX——每调一次就计费一次；桌面端则是 CAPEX + 微量 OPEX——GPU 或 Apple Silicon 的一次性投入，加上运行时的电力和散热。关于桌面端软件项目的通用成本估算方法，可参考我们之前写的软件定制开发桌面端成本测算。
没有放之四海皆准的「哪个更便宜」，但可以从两个维度建立测算框架：
| 维度 | 本地推理 | 云端 API |
|---|---|---|
| 单任务边际成本 | 趋近于零（电费可忽略） | $0.01–$0.50/任务（取决于模型和 token 量） |
| 初始投入 | GPU / 高配主机（一次性） | 零 |
| 模型能力上限 | 受限于本地硬件（通常 ≤70B 参数） | 可调用最强前沿模型 |
| 延迟 | 取决于本地 GPU，可优化至毫秒级 | 网络 RTT + 推理排队，通常 1–5 秒 |
| 数据隐私 | 数据不离开设备 | 需信任云厂商的数据处理政策 |
| 离线可用 | 是 | 否 |
实操中的最优解通常是混合路由：高频、低难度任务走本地模型（零边际成本 + 低延迟），复杂推理或需要最新知识的任务才调用云端。Fireworks 那套 routing 思路完全可以搬到桌面端——只不过路由决策从「K3 vs Fable」变成了「本地 Llama / Qwen vs 云端 Claude / Gemini」。
2026 年 7 月 21 日，ML 工程师 Teng Li 发布了一份对 36 个流行 MCP 服务器的审计报告[2]。结果令人不安：三分之一得分 D 或 F。排名垫底的 firecrawl-mcp 在 134 个错误中，有 132 个是「参数没有描述」。
这跟成本有什么关系？关系大了。Teng Li 的评测揭示了一条直接的成本链：
桌面端场景下这个问题更突出。云端 Agent 烧的是 API 费用，你至少能看到账单；桌面端本地 Agent 烧的是用户的时间和耐心——工具链质量差导致 Agent「看起来卡住了」或「做了莫名其妙的事」，用户信任崩塌的速度比任何 token 账单都快。Teng Li 总结得很精准：Agent 可用性本质上是一个写作问题，而不是工程问题。这恰好呼应了我们在AI Agent 落地企业的三个工程债中讨论过的观点：授权、上下文和成本是 Agent 工程化的三个硬骨头，而工具链质量直接决定了后两者的天花板。
Fireworks 的文章标题几乎是一句宣言：「Don't pick a model. Route.」[1]。
他们在五类 Agent 任务上的 oracle routing 实验表明：按任务类型动态路由，总体准确率达到 93%，高于单独使用任何一个模型。更关键的是成本——因为 72%–96% 的流量被路由到了便宜的 K3，总成本接近「只使用便宜模型」的水平，但质量超过了「只用最贵模型」。
这个策略对桌面端 Agent 的工程化落地有三个直接启示：
取决于你跑多大的模型。7B–8B 参数的量化版本（如 Qwen 2.5 7B Q4_K_M）在 Apple Silicon M2/M3 的 16GB 统一内存上即可流畅运行，推理速度可达 20–40 tokens/s。13B–34B 级别需要 32GB+ 内存或独立 GPU。70B 模型在消费级硬件上勉强可跑但速度不实用，更适合作为云端 fallback。
边际成本接近零（仅电费），但初始硬件投入和模型下载/更新的带宽成本不可忽略。如果把一台 GPU 工作站按三年折旧、每天跑 500 次 Agent 任务，单次硬件摊销远低于云端 API 的典型单任务费用。但如果任务量很低（如每天 10 次以内），云端按需付费反而更划算。
Teng Li 的 mcpgrade 工具[2]提供了一个立即可行的检查清单：给每个参数加 description（含格式说明和一个示例值）、用 enum 声明固定值集合、显式声明 required 字段、统一 verb_object 命名风格。实施成本最高的也就是花一个下午补齐描述——但回报是模型选工具准确率从 84% 拉回 100%。
路由决策本身如果是基于规则或轻量分类器，延迟通常小于 10ms，相比 Agent 任务整体耗时（秒级到分钟级）可以忽略。真正的延迟风险在云端 fallback——如果本地模型完成后还要等云端结果做合并，需要仔细设计异步流水线。
