市场正在传播一组极具冲击力的信息：OpenAI推出“全天候自主智能体”Dots，GPT-6.1 Sol性能接近Astra，标准Token价格只有后者的五分之一。
但截至现有公开信息，Dots是否已经成为OpenAI正式产品、具体形态是什么，GPT-6.1 Sol是否为正式模型名称，以及它与Astra之间是否存在可比性能测试，仍不足以确认。“五分之一”比较的是输入还是输出Token、标准价还是促销价，也没有完整披露。这个数字可以成为市场叙事，却不能直接当作企业成本下降比例。
真正值得追问的问题是：当企业部署的不是一次问答，而是一套能够检索、调用工具并自行修正的Agent，模型单价下降后，单位任务成本究竟会怎样变化？
一、从API价格表转向任务账单
传统API账单通常围绕输入Token和输出Token计价。Agent的账单则更像一条调用链：模型先理解任务并拆解步骤，生成查询或操作指令；系统再调用数据库、浏览器或其他工具；工具返回结果后，模型需要判断信息是否可信，必要时重新检索、修正错误，最后生成答案。过程中还会产生上下文传递、日志留存和安全校验成本。
因此，一个Agent任务通常不是一次模型请求。可以用一个更接近生产实际的框架核算：
单位任务成本＝输入Token成本＋输出Token成本＋调用次数成本＋工具调用成本＋日志与存储成本＋失败重试成本＋人工复核成本。
其中，输入Token不只是用户最初输入，还包括系统提示词、历史对话、工具返回结果和不断累积的上下文；输出Token也不只是一段最终答案，还可能包含规划、查询、解释和中间推理。调用次数越多，长上下文被重复发送的次数越多，账单就越容易被放大。
实际采购时还要把输入、输出、缓存Token和长上下文是否适用不同费率分开核对，同时确认模型是否有推理模式、调用上限、工具权限和并发限制。对于GPT-6.1 Sol与Astra，公开信息尚未完整披露这些口径，因此不能仅凭“标准价格五分之一”完成测算。
二、为什么单价下降不必然带来总成本下降
低价模型首先会降低试用门槛。客服回复、文本分类、数据整理和简单代码修改等高频任务，过去可能停留在人工处理或小规模试用阶段；当每百万Token价格下降，企业更容易把它们纳入生产系统，调用量也可能随之扩大。
公开资料显示，OpenAI此前披露的GPT-6 Sol和GPT-6 Luna，API价格较GPT-5.6此前促销价格下降50%。这能够说明API价格战仍在继续，但与市场传播的“GPT-6.1 Sol价格为Astra五分之一”不是同一口径。OpenRouter对约12万家使用Anthropic和OpenAI工具的企业分析显示，9月份两家公司的企业支出份额大致相当；Ramp经济学家援引9月中旬7万家客户数据称，企业在OpenAI模型上的支出首次超过Anthropic。支出份额变化更接近使用扩张和供应商切换的信号，不能直接证明单项任务成本已经下降。
价格传导还要经过成功率这一关。假设低价模型完成一次分类任务的单次调用成本只有高价模型的五分之一，但它更容易误判，系统就可能追加一次结果校验、一次重新检索，甚至转交人工。若一个任务需要多轮工具调用，模型每次都重新读取增长中的上下文，Token消耗也会迅速上升。
可以把影响机制概括为：Token单价下降，带来更多生产调用；能力或稳定性不足，带来更多重试和校验；上下文累积与工具返回扩大输入规模；人工复核和日志存储继续增加；最终单位任务成本未必按单价同比下降。由此看，“五分之一”不能直接等同于企业任务成本下降80%，更不能直接用于产业链规模测算。
三、多模型协作如何改写Agent成本结构
企业更现实的选择，可能不是在强模型和低价模型之间二选一，而是让它们分工。强模型适合承担任务拆解、复杂规划、异常处理和最终决策；低价模型则可以处理摘要、分类、数据库查询、上下文压缩，以及相对标准化的Subagent执行。
这种架构有机会降低平均调用价格，但前提是执行层足够稳定。低价模型负责查询时，如果经常生成错误参数，强模型就要介入纠错；工具返回结果不完整时，系统还要增加校验轮次。此时，企业表面上减少了高价模型调用，实际却增加了调用次数、等待时间和人工干预。
Agent的竞争因此不应只看某个Benchmark（BHE）排名。Benchmark（BHE）成绩对应的推理强度、测试子集、工具调用条件和是否允许多次尝试，都可能影响结论。真正有采购价值的比较，是在同一业务流程中观察：任务成功率是多少，平均调用几次，失败一次要付出多少重试成本，最终能否减少人工处理。
这也是低价模型的差异化机会所在。它未必需要在所有复杂任务上替代强模型，只要在高频、规则相对清晰的环节保持足够稳定，就可能通过规模化调用形成商业价值；反过来，如果执行层不稳定，多模型协作反而会把流程变成“低价模型干活、强模型不断救火”。
四、企业应建立哪些单位任务指标
企业采购模型时，第一张表不应只是每百万输入和输出Token价格，而应是按业务任务拆分的经营账。客服回复记录每千次请求的成功率和人工升级率；文本分类记录单条成本、误判率和复核比例；数据整理观察工具调用次数、平均延迟和批处理吞吐；简单代码修改则记录一次交付的通过率、回滚率和重试次数。
至少应持续跟踪五组指标：成功率、单位任务成本、平均延迟、重试率和客户留存。工具调用、日志存储、缓存策略和人工复核都要进入总账单，不能只统计模型API发票。若是面对外部客户，还应把退款、投诉和流失纳入任务经济性，因为一次错误输出可能抵消大量低价调用带来的节省。
后续最值得观察的变量有三类。第一，OpenAI是否公布Dots的正式产品形态、工具权限和使用范围；第二，GPT-6.1 Sol与Astra是否出现可复核的同口径输入、输出价格和性能测试；第三，企业生产调用是否在成功率、留存和业务产出同步改善的情况下持续增长。
模型价格下降只有在这三个条件同时成立时，才真正具备规模化意义：更多任务进入生产，单项任务成功率没有明显下降，企业和终端客户愿意持续使用。否则，价格战可能只是把成本从Token账单转移到了重试、算力等待、安全测试和人工复核上。
Dots的消息能否最终落地，仍待官方披露验证。但无论这款产品是否按市场描述出现，Agent时代的算账方式已经发生变化：企业买的不是一个便宜的Token，而是一项能够稳定完成、可被复盘、最终产生业务结果的任务。
但截至现有公开信息，Dots是否已经成为OpenAI正式产品、具体形态是什么，GPT-6.1 Sol是否为正式模型名称，以及它与Astra之间是否存在可比性能测试，仍不足以确认。“五分之一”比较的是输入还是输出Token、标准价还是促销价，也没有完整披露。这个数字可以成为市场叙事，却不能直接当作企业成本下降比例。
真正值得追问的问题是：当企业部署的不是一次问答，而是一套能够检索、调用工具并自行修正的Agent，模型单价下降后，单位任务成本究竟会怎样变化？
一、从API价格表转向任务账单
传统API账单通常围绕输入Token和输出Token计价。Agent的账单则更像一条调用链：模型先理解任务并拆解步骤，生成查询或操作指令；系统再调用数据库、浏览器或其他工具；工具返回结果后，模型需要判断信息是否可信，必要时重新检索、修正错误，最后生成答案。过程中还会产生上下文传递、日志留存和安全校验成本。
因此，一个Agent任务通常不是一次模型请求。可以用一个更接近生产实际的框架核算：
单位任务成本＝输入Token成本＋输出Token成本＋调用次数成本＋工具调用成本＋日志与存储成本＋失败重试成本＋人工复核成本。
其中，输入Token不只是用户最初输入，还包括系统提示词、历史对话、工具返回结果和不断累积的上下文；输出Token也不只是一段最终答案，还可能包含规划、查询、解释和中间推理。调用次数越多，长上下文被重复发送的次数越多，账单就越容易被放大。
实际采购时还要把输入、输出、缓存Token和长上下文是否适用不同费率分开核对，同时确认模型是否有推理模式、调用上限、工具权限和并发限制。对于GPT-6.1 Sol与Astra，公开信息尚未完整披露这些口径，因此不能仅凭“标准价格五分之一”完成测算。
二、为什么单价下降不必然带来总成本下降
低价模型首先会降低试用门槛。客服回复、文本分类、数据整理和简单代码修改等高频任务，过去可能停留在人工处理或小规模试用阶段；当每百万Token价格下降，企业更容易把它们纳入生产系统，调用量也可能随之扩大。
公开资料显示，OpenAI此前披露的GPT-6 Sol和GPT-6 Luna，API价格较GPT-5.6此前促销价格下降50%。这能够说明API价格战仍在继续，但与市场传播的“GPT-6.1 Sol价格为Astra五分之一”不是同一口径。OpenRouter对约12万家使用Anthropic和OpenAI工具的企业分析显示，9月份两家公司的企业支出份额大致相当；Ramp经济学家援引9月中旬7万家客户数据称，企业在OpenAI模型上的支出首次超过Anthropic。支出份额变化更接近使用扩张和供应商切换的信号，不能直接证明单项任务成本已经下降。
价格传导还要经过成功率这一关。假设低价模型完成一次分类任务的单次调用成本只有高价模型的五分之一，但它更容易误判，系统就可能追加一次结果校验、一次重新检索，甚至转交人工。若一个任务需要多轮工具调用，模型每次都重新读取增长中的上下文，Token消耗也会迅速上升。
可以把影响机制概括为：Token单价下降，带来更多生产调用；能力或稳定性不足，带来更多重试和校验；上下文累积与工具返回扩大输入规模；人工复核和日志存储继续增加；最终单位任务成本未必按单价同比下降。由此看，“五分之一”不能直接等同于企业任务成本下降80%，更不能直接用于产业链规模测算。
三、多模型协作如何改写Agent成本结构
企业更现实的选择，可能不是在强模型和低价模型之间二选一，而是让它们分工。强模型适合承担任务拆解、复杂规划、异常处理和最终决策；低价模型则可以处理摘要、分类、数据库查询、上下文压缩，以及相对标准化的Subagent执行。
这种架构有机会降低平均调用价格，但前提是执行层足够稳定。低价模型负责查询时，如果经常生成错误参数，强模型就要介入纠错；工具返回结果不完整时，系统还要增加校验轮次。此时，企业表面上减少了高价模型调用，实际却增加了调用次数、等待时间和人工干预。
Agent的竞争因此不应只看某个Benchmark（BHE）排名。Benchmark（BHE）成绩对应的推理强度、测试子集、工具调用条件和是否允许多次尝试，都可能影响结论。真正有采购价值的比较，是在同一业务流程中观察：任务成功率是多少，平均调用几次，失败一次要付出多少重试成本，最终能否减少人工处理。
这也是低价模型的差异化机会所在。它未必需要在所有复杂任务上替代强模型，只要在高频、规则相对清晰的环节保持足够稳定，就可能通过规模化调用形成商业价值；反过来，如果执行层不稳定，多模型协作反而会把流程变成“低价模型干活、强模型不断救火”。
四、企业应建立哪些单位任务指标
企业采购模型时，第一张表不应只是每百万输入和输出Token价格，而应是按业务任务拆分的经营账。客服回复记录每千次请求的成功率和人工升级率；文本分类记录单条成本、误判率和复核比例；数据整理观察工具调用次数、平均延迟和批处理吞吐；简单代码修改则记录一次交付的通过率、回滚率和重试次数。
至少应持续跟踪五组指标：成功率、单位任务成本、平均延迟、重试率和客户留存。工具调用、日志存储、缓存策略和人工复核都要进入总账单，不能只统计模型API发票。若是面对外部客户，还应把退款、投诉和流失纳入任务经济性，因为一次错误输出可能抵消大量低价调用带来的节省。
后续最值得观察的变量有三类。第一，OpenAI是否公布Dots的正式产品形态、工具权限和使用范围；第二，GPT-6.1 Sol与Astra是否出现可复核的同口径输入、输出价格和性能测试；第三，企业生产调用是否在成功率、留存和业务产出同步改善的情况下持续增长。
模型价格下降只有在这三个条件同时成立时，才真正具备规模化意义：更多任务进入生产，单项任务成功率没有明显下降，企业和终端客户愿意持续使用。否则，价格战可能只是把成本从Token账单转移到了重试、算力等待、安全测试和人工复核上。
Dots的消息能否最终落地，仍待官方披露验证。但无论这款产品是否按市场描述出现，Agent时代的算账方式已经发生变化：企业买的不是一个便宜的Token，而是一项能够稳定完成、可被复盘、最终产生业务结果的任务。
