开源模型承接九成智能体任务，成本仅二十分之一

在Hacker News上引发讨论的一个观点指出，开源模型如今可以完成约九成的智能体（agentic）任务，而成本仅为闭源方案的二十分之一。这条短短的判断来自社区分享，却戳中了当下AI应用落地的核心矛盾：能力与成本之间的权衡正在被重新定义。

智能体任务的能力天花板正在下移

所谓智能体任务，指的是模型需要多步推理、调用工具、读取环境反馈并持续决策的工作流，比如自动化数据整理、代码库维护、客服工单处理等。这类任务过去被认为高度依赖顶级闭源模型。

原帖给出的比例是“九成”——开源模型已经覆盖了绝大多数此类场景。这意味着在真实业务中，只有少数对推理深度、长上下文稳定性或工具调用精度要求极高的任务，才需要动用成本高出一个数量级的闭源方案。对多数团队而言，把智能体工作流整体切换到开源模型，已经不再是“能不能用”的问题，而是“怎么用好”的问题。

智能体（Agentic）任务与传统的单轮问答有本质区别：它要求模型在给定目标后自主拆解步骤、选择并调用外部工具（如搜索、代码执行、数据库查询），并根据每次工具返回的结果调整后续决策，直到任务完成或达到终止条件。常见范式包括 ReAct（推理与行动交替）、Plan-and-Execute（先规划再执行）以及多智能体协作。这类工作流对模型的要求不止是单次回答质量，还包括指令遵循的稳定性、结构化输出（如 JSON 工具调用参数）的可靠性、以及长链路中错误不累积的能力。正因为每一步都可能引入偏差，过去业界普遍认为只有顶级闭源模型才能胜任，这也是“九成覆盖率”这一判断显得重要的背景。

二十分之一的成本差距从何而来

成本差距的根源在于推理定价结构。闭源API按token计费，智能体任务往往需要多轮往返，token消耗成倍放大；而开源模型可以自托管或通过低价推理服务调用，边际成本显著降低。原帖给出的“二十分之一”属于量级层面的描述，具体倍数会随任务类型、上下文长度和部署方式而波动。

这种差距在智能体场景中被进一步放大：一次任务可能包含数十次模型调用，闭源方案的成本会随轮次累积，而自托管开源模型的固定基础设施成本被摊薄。

自托管开源模型的成本结构与 API 计费完全不同。闭源 API 按输入/输出 token 线性计费，且智能体场景下每次工具返回都要重新塞入上下文，导致 prompt token 反复计费、成本随轮次近似平方增长。自托管则把成本转化为 GPU 租用或采购的固定开销，通过批处理（batching）、KV Cache 复用、前缀缓存（prefix caching）等手段提升吞吐后，单位 token 的边际成本可以压得很低。此外还有一条中间路线：通过 Together、Fireworks、DeepInfra 等推理服务商调用开源权重模型，价格通常显著低于同级闭源 API，同时免去运维负担。具体倍数取决于模型规模、量化精度、并发利用率和上下文长度，因此“二十分之一”只应理解为量级估计。

剩下那一成任务的价值判断

九成覆盖率的另一面，是那难以替代的一成。这部分任务通常涉及复杂规划、模糊指令理解或对错误零容忍的关键决策。企业需要判断的是：这部分任务是否值得支付二十倍成本？还是可以通过工作流拆分，把简单环节交给开源模型、只把关键节点交给闭源模型？

混合路由正在成为务实答案——用开源模型承担高频、低风险的子任务，用闭源模型兜底少数高价值环节。

混合路由（model routing） 指在同一个智能体系统中按任务难度动态选择不同模型：轻量环节走小模型或开源自托管，复杂规划、歧义消解或高风险决策转交强模型。实现方式包括基于规则的静态分流、基于分类器的难度预测，以及让模型自身判断是否需要升级（cascade / fallback）。工程上需要统一的工具调用接口与可替换的模型抽象层，才能低成本切换后端。这一模式的代价是系统复杂度上升、需要维护多套提示词与评测，收益则是在保证关键环节质量的前提下大幅压低平均成本。对多数团队而言，路由策略应基于真实任务集的对照数据逐步调优，而非一次性设计到位。

对开发者的实际影响

对正在构建智能体产品的团队来说，这一判断带来两点现实启示。其一，模型选型的默认值应当转向开源：先验证开源模型能否达到业务可接受的完成度，再决定是否为剩余差距付费。其二，成本结构的改变会重塑产品设计，原本因推理成本过高而不敢做的多轮、长流程智能体，如今在经济上变得可行。

需要说明的是，该观点来自社区讨论帖，原帖仅给出结论性判断，未附带完整的评测方法与任务集，因此“九成”与“二十分之一”应视为方向性参考，而非普适基准。实际决策仍需结合自身任务集做对照测试。