最近每隔几天就有人安利一个新Agent工具。但真正该问的不是“这个工具功能多不多”，而是“它在接管我任务流的哪一段”。这个问题问对了，剩下的判断会顺很多。 一、这轮Agent热，不是新名字太多，是任务入口在重新分配 Agent工具不是新物种爆发，而是任务入口重新分配 先说结论：这不是十几个全新物种从石头缝里冒出来，是十几个Agent工具在抢同一类位置——谁来接管你的任务流。 拿最近两周的几件事对照着看：8月19日，Codex cloud接入了GitLab测试版，能从Issue或合并请求里直接用指令拉起任务；同一天，Cursor给云端Agent加了事件订阅，能盯着PR、监听Slack线程、跑定时任务，自己醒过来接活；8月12日前后，GitHub Copilot的Agent Plugins做到1.0正式发布，插件写一次能跨VS Code、CLI、App用。这三件事看着是三条新闻，实际是同一层竞争——谁能让Agent更自主地接单、更长时间地盯着一个目标。看懂这一层，你会发现大多数“新工具”新闻其实是同一个位置内部的迭代，不是需要你重新学一遍的新东西。 真正值得花时间判断的，是位置背后的三件事。往下拆。 二、先摊开地图：四个位置 终端Agent：Claude Code、Codex、Pi，跑在终端里，直接面向代码仓库 IDE/开发环境Agent：Cursor、GitHub Copilot、Google Antigravity，嵌进编辑器或者干脆自成一套开发环境 云端异步Agent：Codex cloud、Cursor的Cloud Agents、Devin的“Manage Devins”（一个Devin拆任务后管理一队跑在独立虚拟机里的子Devin），任务丢出去，人不用一直盯着 办公/组织工作台：WorkBuddy这类，重点不是写代码，是把文档、会议、知识库和产出串起来 同一个位置里，工具之间可能是完全不同的东西——同样挂在“终端Agent”下面，Claude Code和Pi长得一点都不像。要分清楚，得看下面三件事。 三、三个判断维度：任务从哪来、在哪里跑、能力沉淀到哪里 判断Agent工具的三个维度 任务从哪来：是你主动敲命令，还是它自己订阅了某个事件源，醒过来就开始干活。Cursor的事件订阅、Copilot CLI的多任务管理，都是在往“自己接单”这个方向走；Pi依然是你敲一条命令它跑一段，触发权完全在你手里。 在哪里跑：跑在什么样的隔离环境里，谁负责兜底安全。这条上两种哲学的差距很大——Pi官方安全文档写得很直接：没有内置沙箱，内置工具能以Pi进程本身的权限读写文件、跑Shell命令，隔离要靠你自己套一层容器或虚拟机；官方给的理由是半吊子的进程内沙箱容易被误解成安全边界，真正的隔离得靠操作系统层面。相比之下，Factory的Droid在3月就上线了OS级沙箱，Cursor和Devin也都把Subagent放进独立虚拟机里跑。这不是谁更先进，是把隔离责任放在用户手里还是厂商手里的选择，而且是有真实代价的选择，不是营销话术。 能力沉淀到哪里：任务跑完之后，留下的技能、扩展、审计记录，是留在你自己手里，还是留进某个厂商的生态里。这条决定了你今天投入时间学会的东西，明天还能不能带着走。 这三个问题里，“任务从哪来”还有一层容易被混淆的东西——不是指谁触发任务，而是指这个工具的技术源头本身，也就是血统。这个概念值得单独拆一下。 四、血统判断：强血缘、弱兼容、生态绑定 Agent工具血统判断 血统鉴定要分强弱，混着看最容易得出错误结论。 强血缘，直接移植源码。 之前拆过xAI的Grok Build，里面直接移植了openai/codex和sst/opencode的工具层代码，改完按协议留了修改声明，这是能在仓库里翻出实锤的。 强血缘，但会随时间衰减，SDK内嵌依赖。 OpenClaw是个好例子，但这里要说清楚现状，不能停在旧印象里。OpenClaw最新的架构文档写得很明确：核心运行时现在完全由OpenClaw自己拥有，不再保留任何外部Agent框架包，唯一还留着的第三方依赖是pi-tui这个终端组件工具包；甚至连pi这个legacy运行时别名，现在也被规范化指向OpenClaw自己的runtime id。也就是说，OpenClaw和Pi之间曾经有过真实的SDK内嵌关系，但这层依赖正在被系统性地收编掉。这条案例最大的价值不是“揭发”谁抄了谁，是提醒一件事：血缘关系不是刻在石头上的标签，会随项目自己长大而被稀释甚至切断，鉴定要看当下的真实依赖，不能只信一份可能已经过期的文档。 弱关联，仅接口/格式兼容，不是代码血缘。 WorkBuddy自己的说法是“跟开源的小龙虾OpenClaw、Hermes类似，完全兼容这类skills”。这句话字面意思是skill格式兼容，跟上面说的SDK内嵌完全不是一回事——WorkBuddy是腾讯CodeBuddy产品线下的闭源产品，跟Pi、OpenClaw之间没有任何能查到的代码或依赖关系，双方只是约定了同一套skill的写法。看到“兼容”两个字就默认是“同一家人”，是这套方法论里最容易踩的坑。 生态绑定，决定迁移成本。 Pi是MIT开源，不绑定任何一家模型厂商；WorkBuddy则深度绑定微信/腾讯文档生态。这条不是血统问题，是治理问题，但经常和血统一起被混为一谈，也值得单独拎出来看。 五、Pi、Claude Code、Codex、WorkBuddy分别代表哪种路线 维度 Pi Claude Code Codex WorkBuddy 位置 终端Agent 终端Agent（功能完备） 终端+云端异步 办公/组织工作台 任务从哪来 本地命令行手动触发 本地手动触发，支持子Agent协同 本地命令行触发，云端也可从GitLab Issue/合并请求直接拉起 会议、文档协作场景触发，不需要手动敲命令 在哪里跑 不内置沙箱，隔离责任交给用户 官方托管环境负责隔离 云端隔离环境（Codex cloud） 云端腾讯托管环境 能力沉淀到哪里 沉淀进用户自己的extension和session 沉淀进Anthropic生态（Skills/Plugins/MCP） 沉淀进OpenAI生态 沉淀进腾讯文档/网盘/乐享 血统类型 MIT开源，独立血统 自研闭源 自研闭源 闭源；宣称skill格式兼容OpenClaw，属弱关联，非代码血缘 六、到底该怎么选 这里并不是说“哪个最强”，按上面的位置和三个维度倒推： ...

买显卡跑本地模型，不能只拿显卡价格除以API账单。折旧、电费、残值、缓存命中率、模型可用率和本地吞吐都会改变回本时间。

一个只有4个工具、系统提示词不到1000token的极简终端工具，星标数在不到一年里从几百涨到数万。它和Claude Code的差距不是强弱，是两种完全不同的Agent架构哲学。

前两天试了个小实验：让两个AI做同一件事——“把这个文件夹里的材料整理一下，按项目、年份和类型分类，找出重复文件，生成一份目录清单”。 第一个AI的回答很像样：建议先建几个文件夹，给了一段批量重命名的脚本，最后说“你可以把文件上传给我，我再帮你细看”。 第二个AI没怎么废话，直接打开了那个文件夹，读文件、判断格式、拆分类别、检查重复、生成目录，最后甩给我一份可以直接用的清单，附带一份“我做了什么”的执行记录。 两个AI背后可能是差不多水平的大模型，为什么一个只给建议，另一个真的动手把事办完了？这篇想把这件事拆开讲清楚。 一、点菜vs自己下厨 聊天机器人像坐在桌边帮你点菜的人。你问它今天吃什么、这道菜怎么做、三个人该点几个菜，它能分析、能建议、能讲得头头是道。但回答说完，这件事在它这儿就结束了——它不会去看冰箱里还剩什么、该采购点什么、火候不对了要不要重炒，更不会把菜端上桌。 Agent更像是接到目标后真正进厨房的人。你给它的不是一步步的指令，而是一个目标——“晚上六点前准备三菜一汤，有一个人不吃辣”。剩下的事它自己张罗：看现有食材、定菜单、决定先炒哪道、缺了什么自己想办法、中途火大了自己调整，直到达成目标为止。 这不是“服务员”和“更聪明的服务员”的差别，而是谁掌握了执行路径的决定权。区别不在于点菜的人只能说固定答案——他其实也能开放式地分析、建议、讲清楚利弊——而在于他说完以后，采购、烹饪、调整、验收，仍然要由你自己一步步完成。下厨时目标定了，用什么锅、先做哪样、中途要不要改主意，是他自己当场拿主意。 这个类比对应的是两家主流模型公司目前的工程定义，但需要先说明一句：行业对Agent并没有完全统一的术语边界。Anthropic把系统分成workflow和agent两类：workflow是LLM和工具按预先写好的代码路径走，agent则是LLM自己动态决定下一步做什么、调用什么工具。OpenAI的说法角度略有不同：workflow是为达成用户目标必须走完的一串步骤，agent则是能代表用户、由模型控制这串步骤执行的系统——换句话说，在OpenAI的语境里，Agent是在“执行workflow”，而不是把两者当成互斥的类别。两家措辞不完全一样，但共同强调的是同一件事：模型是否掌握了执行流程的控制权。 本文采用的是偏工程化的狭义口径：预设路径称为workflow，模型根据当前状态动态决定执行路径，才称为Agent。现实产品里，聊天、workflow和Agent能力往往被放在同一个界面里，不必强行归类。 二、真正的分界线：不是会不会说话，是谁决定下一步 聊天机器人的典型流程是这样的：用户提问，AI回答，用户判断这个答案有没有用，用户决定下一步该问什么，AI再回答。举个真实场景——让AI查资料，你复制结果，再让它整理，你保存成文档，再让它改格式，你发邮件出去。AI在每一步都参与了，但整条流程是靠你自己一步步连起来的。 Agent内部跑的是另一套循环：接收目标，判断当前处于什么状态，自己选择下一步该做什么，调用工具，拿到反馈，根据反馈修正计划，继续往下推进，直到自己判断“这件事完成了”。 判断一个系统的Agent成色，最核心的一问是：模型能不能根据当前状态决定下一步，并在拿到工具反馈后继续调整？这不是唯一条件，但它是区分固定workflow和Agent的第一道门槛。假设一套系统能搜网页、能读文件、能生成PPT，仍然要接着问——是你每次手动点选功能，还是程序按固定顺序走，还是模型根据当前结果自己拿主意？只有第三种，才算得上真正意义上的Agent。 这里有四个很容易被混淆的说法，值得单独拎出来说清楚： 能联网搜索≠Agent。搜索只是一件工具，如果搜什么、搜几次、什么时候停都是你在控制，它本质上还是个联网增强版的聊天机器人。 能记住上下文≠Agent。记忆能让多轮对话更连贯，但“记得你说过什么”和“能替你把事办完”是两码事。 能调用插件≠Agent。调一次天气、算一次数字、查一次数据库，都不构成对完整任务流程的控制权。 多个模型协作≠必要条件。单个Agent同样能完成复杂任务，OpenAI自己也建议先把单Agent做扎实，只有工具太多、逻辑分支太复杂、职责需要拆分时，才考虑上多Agent架构。 一句话小结这节：工具决定AI能做什么，执行权决定它是不是Agent。 聊天机器人、Workflow和Agent的真正区别：谁在决定下一步？ 三、“会执行”到底难在哪——两组基准，三层难题 概念讲清楚之后，容易冒出一个乐观误解：既然Agent就是“自己决定下一步”，那是不是接上工具就基本齐活了？现实要泼盆冷水——真正把一件事稳定执行完，比听起来难得多，而且难在三个不同的层次上。 第一层，完成一个受规则约束的业务闭环就不容易。Sierra研究团队2024年发布的τ-bench，测的不是Agent会不会调用某一个函数，而是它能不能在模拟的零售和航空客服场景中，一边和用户多轮沟通、一边调用API，还要遵守复杂的业务规则——这本身就和“给定所有信息、一次性执行”的旧基准不是一回事。评分重点也不只是数据库最终状态对不对，还要看Agent有没有把必要信息传达给用户。结果是，即便用GPT-4o跑function calling，零售场景的成功率也只有约61%，航空场景更是只有约35%。这说明“说清楚该怎么做”和“真的把这件事办对”，中间隔着一大截。 第二层，稳定执行比偶尔跑通更难。τ-bench提出了一个叫pass^k的指标，衡量的是同一个任务连续跑k次是不是次次都成功。直观理解，如果把每次执行看作相互独立，单次成功率即使有90%，连续8次全部成功的概率也只有43%左右。而在τ-bench的实际测试里，GPT-4o零售场景的平均成功率超过60%，pass^8却降到25%以下——这也是为什么“Agent能跑出一个漂亮的demo”和“Agent能每天稳定地跑”完全是两件事。 第三层，长链路任务是目前公认的最大短板。2026年发布的OSWorld 2.0专门测试长流程真实任务，一共108个，每个任务对熟练的人类操作者来说，中位耗时都要1.6小时。在论文测试的配置里，Claude Opus 4.8开最大思考、批量工具调用，严格意义上的完成率是20.6%（放宽到部分得分能到54.8%），token效率更高的GPT-5.5完成率约13%。这组数字只对应OSWorld 2.0所测的这类长流程电脑操作任务，不能代表客服Agent、代码Agent这些其他场景的整体水平；而且这个领域进展很快，7月Anthropic已经发布了新一代的Opus 5，官方称其在这项基准上的表现已经超过Opus 4.8，所以这里给出的仍是“当时那批模型能做到什么程度”，不是当前的最新水平。 三层难度合在一起，指向的是同一件事：Agent真正的门槛不在“能不能调用工具”，而在“能不能把一条受规则约束的长链路任务，稳定、正确地走到底”。 Agent执行能力的三道关 这几组数据来自不同模型、不同版本、不同评测框架，彼此之间不能直接换算比较，只用来说明“执行”这件事本身有多难，不做具体产品的排名依据。 四、Agent内部到底多了什么 拆开来看，一个能稳定干活的Agent，通常要具备六个部件： Agent = 大模型 + 工具 + 环境权限 + 任务状态 + 执行循环 + 安全护栏 大模型负责理解目标、判断下一步、处理意外情况，相当于厨房里的大脑，但光有大脑做不出饭 工具是它和外部世界打交道的手，包括读写文件、查数据库、发邮件、执行命令 权限决定它真正能动什么——没有权限，Agent说到底也只能给建议 状态让它知道任务走到哪一步了，不用每次都从头猜一遍 执行循环是“观察→规划→行动→反馈→检查→继续”这条闭环，这是Agent和“调用过一次工具的聊天机器人”最本质的区别 安全护栏决定哪些操作必须停下来问人，比如删除文件、发邮件前的确认 大模型能力已经相当普及，工具接入也越来越常见；真正拉开差距的通常是后四个部件——权限给到什么程度、状态记不记得住、循环转不转得起来、护栏立在哪儿。 五、真实片段：WorkBuddy的一次多步执行，和一个反例 上个月那篇《我用WorkBuddy做了几件小事，才明白Agent是什么》里记录过几个真实场景，这里挑一个执行场景和一个对照场景重新看一遍。先说清楚：下面这个例子能证明它完成了多步任务，但不足以证明每一步都是“临场动态决策”——这一点留在下一节一起说。 一个是手机远程遥控电脑：在外面发一句“看一下当前文件夹下有哪些文件，把内容转写成markdown保存一份，总结主要内容给我”，到家活儿已经跑完了。这句话背后是它自己拆成了“列文件→读取→转写→总结”几步，而不是我手动点了四次功能——这至少说明它具备了“接收目标、自己拆解步骤”的能力，是本文第二节说的执行权的一种体现。 再对比同一篇里的“每日AI新闻推送”：设定好时间和内容规则，到点自动推送——这更接近固定workflow而不是严格意义上的Agent，因为触发条件和执行动作都是提前定好的，模型没有在中途做新的决策。这个对比恰好能落回本文第二节的核心判断：同一个产品里，不同功能可能分别落在workflow和Agent两端，不能一概而论。 六、Agent不是越自主越好 篇幅有限，这里只强调一个容易被忽略的判断：Agent能自主决策，不代表应该在所有事情上都放手自主。 先说一个真实的小例子：上个月那篇《我用WorkBuddy做了几件小事，才明白Agent是什么》里，让WorkBuddy围绕一个主题跑一份调研报告，结果不算完美——报告里列的要点，有几个是没想到的，但也有几个是它“想当然”给出的，得自己核实过才能用。这提醒的是：Agent能自己往前推进，不代表它推进的每一步都对。在当前阶段，尤其是面对调研、发布、邮件和数据修改这类任务，把Agent的产出当成待验收的结果，而不是直接当最终结果使用，是正常的使用方式。 行业层面也有数据支撑这个判断。Gartner预测，超过40%的agentic AI项目会在2027年底前被取消，直接原因包括成本上升、业务价值不清晰、风险控制不足；同一份报告也指出，当前模型的成熟度和自主能力，仍不足以稳定完成复杂的业务目标。换句话说，项目失败通常不是单一的技术问题，而是能力、成本、价值和治理共同作用的结果。报告里还提到一个更扎心的现象：市面上数千家自称“agentic AI”的厂商里，真正名副其实的大概只有130家左右——这就是所谓的“agent washing”，把聊天机器人换个说法包装成Agent。 这个判断其实和第三节的执行数据是一体两面：在OSWorld 2.0测试的这类长流程电脑操作任务上，当时最佳配置的完整完成率也只有约两成。这不能代表所有Agent场景，但足以说明——面对长链路、高权限、难以回滚的任务，默认让Agent完全自治，在当下不是一个稳妥的选择。 ...

本文是「上下文窗口」系列第三篇。前两篇分别讲了《标称1M的token，为什么32K就开始变笨》（为什么会变笨）和《KV Cache：每读1个token，就要交一笔“显存税”》（为什么会爆显存）。这一篇不重复论证，直接回答一个更实际的问题：到底该设多大。 两位读者间隔两天，问了同一个问题： “Mac 24GB，到底该开16K还是32K？” “现在的模型动不动就说支持1M上下文，是不是就该一直开满？” 答案我已经在评论区打完字了，只是散在各处。这篇把它整理成一套能直接照抄的判断框架。 一、上下文有三个长度，不是一个 三个Context长度概念模型 先纠正一个直觉误区：Context越大越好。 前两篇已经用数据说清楚过：厂商标称的窗口，和模型真正“读懂”的窗口，从来不是一回事——在NoLiMa这项刻意排除关键词匹配、只测语义理解的基准测试中，32K的长度下，12个主流模型里有11个的表现跌到了短上下文性能的50%以下；而KV Cache这笔显存账，会随长度线性膨胀到硬件扛不住。这两条结论不重新展开，直接拿来当地基。 在这两条结论之上，这篇提出一个更好用的框架——任何一个模型的上下文窗口，其实是三个数字，不是一个： 标称长度（Advertised）：厂商发布会念的数字，128K、1M。它的含义仅仅是“技术上能塞进去”，不代表“能读懂”。 有效长度（Effective）：大海捞针、NoLiMa、RULER这类基准测出来的、模型表现开始明显滑坡之前的长度。这是“真正建议放心使用”的上限。 最佳长度（Optimal）：综合了速度、成本、显存、稳定性之后，日常真正该设的那个值。它通常比有效长度还要保守——因为有效长度只回答“模型还读得懂”，没回答“划不划算”“跑不跑得动”。 三层长度往往是层层递减的：标称1M，有效可能只有128K，而落到你的日常使用，最佳长度经常只有32K甚至更低。后面每一节，本质上都是在帮你把“最佳长度”这个数字，套到你的具体场景里去。 二、云端API：按任务场景，不按模型规格 面对一个API，第一反应不该是“这个模型支持多少”，而是“我这个任务该设多少”。按任务类型分场景，给一套可以直接抄的建议： 任务类型 建议长度 为什么 日常聊天 8K～16K 没必要背着几百页历史对话，多背的都是白付费 写作/总结单篇长文 16K～32K 覆盖绝大多数文档，还没进入U形曲线最吃亏的中段 代码Agent 32K～64K 需要跨文件理解，但推理能力和检索能力是两件事，别无脑往上加 RAG检索类任务 64K～128K 真正决定效果的是检索准不准，不是Context开多大——这条对应前一篇讲过的“新模型捞针能力已经不差” 法律/论文/合同/整本书级长文档 128K以上 就算窗口够大，也建议先分章节处理，一次性塞满不如分块问得准 这张表背后有一条硬规律：任务越接近“综合推理”“多步分析”，越不该无脑加长上下文；越接近“从一堆材料里找一个具体的点”，越可以放心用长窗口。这也是前一篇里讲过的机制——长上下文里干扰项越多、格式越相似，模型越容易自信地编答案。加长窗口能扩大你能塞的材料范围，但不会让模型的推理能力跟着变强。 把厂商的收费拐点，当成性价比参考线 2026年两个真实的定价规则：Gemini3.1Pro（即前两篇提到的Gemini3Pro系列）上下文超过200K开始阶梯涨价，GPT-5.5输入超过272K直接翻倍。 这两个数字不只是“厂商想多赚钱”这么简单。标准全量注意力机制的理论计算复杂度随长度平方增长——这是长上下文对厂商算力成本构成实打实负担的根本原因；当然，实际部署中MLA、滑动窗口注意力等架构优化（前一篇讲过的DeepSeek MLA就是典型）能显著降低真实计算和显存开销，但压力并不会被完全抹平，只是被推迟或减轻。厂商选择在哪个长度设收费闸门，某种程度上等于厂商自己交了一份“这个长度开始不划算”的答卷。你不需要知道他们后台的具体成本曲线，看价目表拐点在哪，就知道大概在哪一档之后，性价比开始变差。 需要说清楚的是：这只是一种经验性的判断框架，不是绝对规律——不同厂商的定价还会受市场策略、模型架构差异、竞争态势的影响，同样是长上下文，有的厂商靠架构优化（比如KV Cache本身压缩得狠）扛住了成本，定价就没这么陡。把它当参考线，而不是当铁律。 三、为什么Context越大，不只是变笨，还会变慢 KV Cache那篇算过一笔硬账，这里只提炼成一条因果链，不重新推导： Context↑ → KV Cache↑ → 显存占用↑ → 首字等待时间（TTFT）和生成速度↓ → 本地部署OOM风险↑ 翻译成人话：上下文每往上调一档，模型要保管的“草稿纸”就线性变厚。Prefill阶段（读入你的输入）变慢是因为要把这些草稿纸现算出来；Decode阶段（一个字一个字往外吐）变慢，是因为每吐一个字，都要把这张越来越厚的草稿纸整个翻一遍。云端用户感知到的是“响应变慢、账单变贵”；本地部署用户感知到的是“内存肉眼可见地涨、模型直接加载失败”。 本地部署为什么不能照搬云端的长度设置，答案就在这条链条里。 四、本地部署：显存决定你的上限，不是模型决定 本地部署24GB Mac推理限制模型 云端用户只受“有效长度”这一个约束——模型能力不够，顶多是回答质量下降。本地部署用户要同时扛住两个约束：能力上限和硬件上限，取较小值。硬件上限往往先到。 以一台MacBook Pro M4 Pro、24GB统一内存为例，这是项目里实测过的配置： 模型 量化 24GB Mac下的状态 已验证的上下文设置 Qwen3-32B IQ4_XS / MLX 4bit 临界状态，需要手动把GPU内存上限从默认约16GB抬高到21GB左右，且机器需要专用 先设8192（8K）跑通，验证过可以再往上试16384（16K） Gemma3-27B / Qwen3-27B Q4_K_M 同样临界，比32B多留一点余量 目前没有单独测过具体上限，暂不给精确数字 几个要点： ...

文中价格与行业数据查证于2026年7月，逐条标注出处，所有数字均可在文末溯源。 一、一笔9.2亿美元的月租金 先说一件最近的事。 据24/7 Wall St.今年6月的报道（经Yahoo Finance转载），Google要向SpaceX支付每月9.2亿美元，租用大约11万张Nvidia GPU，合作期从2026年10月持续到2029年6月。这个租金水平，据Dwarkesh Patel在同期一篇博客文章中的测算，大约是这批卡现货价的2倍，而现货价本身，据其文中引用，比2026年2月的低点又涨了40%以上。 如果你只看新闻标题，这条信息很容易被淹没在“存储芯片涨价”“苹果Mac涨价”这类更抓眼球的消息里。但仔细想一下会发现，这条新闻讲的其实是一件不太一样的事：苹果涨价涨的是造一台电脑的成本，Google多付的这笔钱，涨的是租一张已经造好的卡的价格。 一个是硬件采购市场，一个是算力租赁市场。这是两件事。 而与此同时，如果你打开任何一家大模型厂商的API价目表，看到的又是另一个方向的走势——Token调用价格，还在持续往下探底。 三条线，三个方向。把这三条线分别拆开，看看它们各自在讲什么故事，以及它们为什么能同时成立。 二、拆开“算力”这个词——三层价格，三个逻辑 算力价格不是一个市场，而是三个市场 “算力会不会越来越贵”这个问题之所以长期争论不清，是因为很多时候大家讨论的并不是同一个市场。实际上，“算力价格”至少包含三个层面： 层次 近期走势 核心驱动力 硬件采购（芯片/显存） 涨 实物供给稀缺：HBM、DRAM产能被AI数据中心抢占，叠加电力瓶颈 算力租赁（GPU小时价） 涨 头部AI实验室营收增速远超算力供给增速，愿意为确定性支付溢价 Token调用（API单价） 跌 算法效率提升、开源竞争、推理优化持续压低完成同一任务所需的算力 下面按这个顺序，一层一层拆。 三、变贵的第一条线：硬件采购——供给side的实物通胀 这条线的证据链，我在《存储通胀：苹果涨21%、美光毛利80%、华为另起炉灶》里已经详细拆过，这里只做简要回顾。 核心逻辑：多家产业分析和机构研报（Wedbush等，经财经媒体转引）估算，AI服务器对DRAM的需求量约为普通服务器的8到10倍，这轮需求爆发叠加存储厂商主动向HBM倾斜产能，共同推高了价格。据21世纪经济报道今年3月的调查，三大存储厂商已将18%到28%的DRAM产能分配给HBM，且因为HBM良率仅50%到60%、单位容量实际消耗的产能相当于3到4颗标准DRAM，这部分产能挤占的效果被进一步放大；同期TrendForce的预测显示，2026年全球DRAM行业资本支出约613亿美元，同比增长约14%，但三星2026年DRAM产能预计仅增长约5%，扩产速度明显跟不上需求增速。 AI时代，瓶颈从芯片扩展到整个基础设施 电力也在成为新的硬约束。据Gartner今年6月的官方预测，2026年全球数据中心用电量将达到565TWh，较2025年的447TWh增长26%，AI优化服务器的耗电占比将从上一年的约20%升至31%。美国最大电力市场PJM的容量拍卖价格也印证了这一点：据PJM官方公布及IEEFA的整理，2024/25年度的清算价为每兆瓦日28.92美元，到2025/26年度涨至269.92美元，涨幅接近10倍；最新的2026/27年度拍卖进一步涨到329.17美元，触及了监管设定的价格上限。 这一层涨价，本质上和普通商品通胀是同一个逻辑：实物产能扩张需要两到三年周期，需求却是指数级涨上来的，供需缺口短期填不平。 四、变贵的第二条线：算力租赁——需求增速跑赢供给增速 这条线主要素材来自Dwarkesh Patel 2026年7月29日发布的博客《Why compute might get 10x+ more expensive in coming years》。这篇东西本身是作者标注为“两小时速写”的思想实验，不是严谨的预测报告，但里面的一部分证据和推理框架，值得认真对待。 先说最实的一块：文章开头那条Google-SpaceX的租赁交易（每月9.2亿美元、约11万张GPU），是全文唯一一条有具体交易、有第三方财经媒体信源支撑的硬数据。这条信息本身就足以说明，至少在头部实验室需要的那部分算力（不能用现货，要长期锁定、要保证数据安全和利用率）里，价格确实在涨。 作者给出的一个推理框架是这样的：如果头部实验室的营收继续保持年化10倍增长，而算力供给年化只能做到3倍增长（这个3倍的数字，作者引用了Epoch AI一篇关于头部实验室算力使用的分析），那么中间的差额只能靠三件事的组合来填：实验室利润率上升、算力单价上升、推理占算力支出的比例上升。而实验室并不希望第三项主导——如果大部分算力都花在了跑存量模型的推理上，等于变相承认继续投入训练已经不划算了。所以差额主要落在前两项。 3倍这个算力供给增速，作者拆成了三个乘数：摩尔定律贡献约1.4倍，新建晶圆厂贡献约1.2倍（受EUV光刻机设备供应制约，瓶颈预计持续到2030年），AI抢占先进制程晶圆份额贡献约1.8倍（预计2027年底见顶，届时AI将占N3产能的86%，目前约60%）。这三个数字都是作者自己的估算，我没能找到独立的第三方交叉验证，写在这里仅代表这篇博客的推理链条，不代表已核实的行业共识。 接下来这部分数字，需要打个更大的问号：作者提到Anthropic推理毛利率在近两年内出现了大幅上涨，但他自己在原文脚注里明确写这是“total vibe claim”（纯粹凭感觉的说法），不是查出来的实测数据，所以这个具体数字不予采用。倒是可以提供一组真实核实过的替代数据：据《华尔街日报》2026年5月报道（经Axis Intelligence整理），Anthropic的算力成本占营收比例从今年一季度的71美分/美元，降到了二季度的56美分/美元，方向上印证了“规模扩大后单位成本占比在下降”这个判断，但幅度远没有“vibe claim”里暗示的那么夸张。 文章里那个更出圈的“250万美元一张H100”的说法，前提是“如果一张H100真能跑出一个人类水平的软件工程师”，按当前软件工程师市场价，这张卡理论上应该能租到远超今天现货价的水平。这是一个完整的思想实验，但前提必须是AI真的达到了人类水平的工程能力，并且这个能力的边际价值不会因为供给暴增而崩塌。作者自己也承认，这个假设成不成立，目前谁也说不准——这个数字本身没有可核实的经验依据，只是作者论证逻辑的一部分，读的时候需要清楚这一点。 这里有一个值得借用的经济学工具，叫“Alchian-Allen效应”，简单的可以理解为：当一笔固定成本被加到两种不同质量的商品上时，优质品会变得“相对更便宜”，需求会转向优质品。放到算力上理解就是——当GPU小时成本本身已经很贵，用一个能力较弱、需要消耗更多Token才能完成同样任务的模型，反而变得非常不划算。所以效率更高、能力更强的模型，能收更高的溢价，而不是被拖入单纯的价格战。这也是为什么头部模型很可能持续保持定价权，而不是随着通用能力的普及一起被打成白菜价。 五、变便宜的第三条线：Token调用——效率通缩仍在继续 前面两条是涨价的线，这一条来看跌价的。 以第三方定价追踪站PricePerToken.com和TokenCost.app整理的历史数据为锚点（这两个都是聚合追踪各家API定价的独立站点，不是OpenAI官方一手页面，但相互印证、数字一致）：2023年3月GPT-4发布时，每百万Token输入30美元、输出60美元；到2024年5月GPT-4o发布，降到输入5美元、输出15美元。如果以GPT-4发布价作为高位锚点，仅这一次换代就带来了约6倍的降幅，此后价格战仍在持续压低通用Token的价格。 国产大模型这边，据中国信通院的数据（经业内文章转引，未能找到信通院原始报告链接，标注为二手引用），2026年国内大模型API平均价格较2023年下降超过90%，同期性能提升了3到5倍。同时也值得指出一个反直觉的现象：据证券日报今年的报道，2026年上半年海外部分云厂商API价格因为存储和GPU成本上涨反而在涨价，最高涨幅据报道达到463%，DeepSeek却在这个背景下于5月22日宣布旗舰模型V4-Pro永久降价75%——这说明“Token降价”并不是全球统一的必然规律，国内这轮降价更多是市场竞争策略的结果，而不是纯粹的成本下降传导。 这条降价曲线背后的技术支撑，其实已经很熟悉了——MoE稀疏化让每次推理只激活总参数的一小部分；量化和蒸馏压缩模型体积；KV Cache优化能让同样的上下文占用直接减半，这部分逻辑在我之前那篇KV Cache文章里讲过“降税”的比喻；Prompt Caching命中和未命中的价格能相差数十倍甚至更多，据Apifox今年5月整理的中国大模型价格对比，月之暗面Kimi K2.6的缓存命中价低至0.07美元/百万Token。 但这条降价曲线并不等于企业的AI账单在变小。恰恰相反——通用Token价格在探底，企业的AI运营总支出却在膨胀，原因是企业正在从简单问答转向Agent协作、代码生成这类更消耗Token的复杂工作流。这一点可以用Anthropic自己的数字来印证：据Anthropic自己在融资公告中披露（经VentureBeat、Simon Willison等多方转载核实），其年化营收从2025年末的约90亿美元，一路涨到2026年5月的470亿美元，公司自己的原话是“过去三年里，每一年都保持了10倍以上的年化增长”。这条数据同时说明两件事：一是Token价格确实在降，厂商靠规模和效率仍能维持业务增长；二是需求膨胀的速度，远远盖过了降价带来的成本节约。 ...

本文接着「术语解构」系列往下写。前两篇《上下文窗口：标称1M的token，为什么32K就开始变笨》和《KV Cache：每读1个token，就要交一笔“显存税”》，一篇讲的是“标称窗口和有效窗口之间隔着什么”，一篇讲的是“这份窗口最后要占多少显存”。这两个问题都不是这篇要重新论证的，这一篇只问一件事：长上下文值不值得为它多付这份钱。 我们第一次用上1M上下文，大概率都会干一件事：把PDF、聊天记录、代码仓库、会议纪要一股脑塞进去，然后问模型“帮我总结一下”。 这件事很爽，账单也很诚实。问题是模型真的把这1M token都用上了吗？ 这个问题的答案大概率是：长上下文有价值，但它不是智力外挂。它更像一张很大的工作台，能放更多材料，不代表模型会按你的重点全部读完，也不代表中间那张关键的纸不会被忽略。贵不贵，从来不是问题，更重要的是贵得值不值。 一、1M上下文最容易出现的三个错觉 第一个错觉：能塞进去，就等于能稳定用出来。1M token解决的是输入上限，不是注意力分配。它允许你把更多材料交给模型，但模型在这些材料里怎么找、怎么权衡、会不会漏掉中间某个关键证据，是另一件事。规格表上的上下文长度，更像仓库面积；真正决定任务结果的，是模型能不能在这片仓库里找到正确的那只箱子。 第二个错觉：一次性塞完，就更省钱。长上下文的成本不只是在模型变贵时才出现，输入本身就在计费。以发稿前重新核对的OpenAI官方GPT-4.1价格为例：约1M上下文，输入2美元/百万token，缓存输入0.5美元/百万token，输出8美元/百万token。这几个数字保质期短，Token那篇也提过，大概一个季度就可能变。单看一次调用不吓人，30万token材料，未命中缓存的输入成本大约是0.6美元。但如果每天调用20次、每次都带30万token材料，光输入就是600万token，一天12美元，一个月大约360美元。假设每次还输出2000token，一个月输出再加大约9.6美元。这还只是每天20次的轻量用法。Agent场景里，模型可能每一轮都带着几十万token在跑，规划、检索、改写、校验、重试，十几轮之后，这笔钱会变得很具体。长上下文不是不能用，而是别把它当免费内存用。 第三个错觉：needle测试好看，就等于复杂任务可靠。找出资料中的一句暗号，和从几十份合同里判断责任边界，不是一回事。前者像在大海里找一个发光浮标，后者要把定义、例外、补充协议、历史版本、责任条款串起来看。很多模型在简单needle测试里已经很漂亮，但一换成多针、多跳、聚合、冲突判断，成绩就没那么稳了。 二、真正的问题：有效利用率，不是能不能装下 上一篇提到过NoLiMa和RULER这两个基准测试的名字。NoLiMa做了一件很朴素的事：把问题和答案之间的字面重合去掉，只留下需要推理才能建立的关联，比如问题问的是“和某座歌剧院有关的人是谁”，而材料里只写了这个人住在歌剧院所在的城市，没有直接提到歌剧院三个字。这种设计逼着模型真正理解，而不是靠关键词匹配蒙对。 标称上下文 vs 有效利用率 结果是，论文测试的一批声称支持128K以上上下文的模型里，短文本（1K以内）表现都不错，但随着上下文变长，表现明显下滑。在常被引用的原始结果里，GPT-4o从短文本几乎满分的99.3%，掉到32K时的69.7%。NoLiMa后续公开结果又加入了GPT-4.1等模型，个别模型的排名和数字会变化，但主线没有变：长窗口标称长度越大，越需要单独评估有效利用率，不能只看规格表。 RULER则是从另一个角度补刀：不满足于“找一根针”，而是让模型同时找多根针、做多跳推理、再把结果聚合起来。它的评测里能看到，模型在简单needle测试里可能接近满分，但换成更接近真实任务的组合检索后，表现会随着上下文变长出现明显下滑。 这两组测试合起来看，32K还不到1M窗口的十分之一，但在更难的评测里，很多模型已经明显掉分。窗口越做越大，只是把能装下的上限往后推，并没有同步把能认真读完的能力往后推。所以长上下文真正要问的不是“最多能塞多少”，而是关键证据放在材料的第70%位置时，模型还能不能稳定找到它、用对它，并且解释清楚它为什么重要。 三、什么任务是真需求 材料天然长、需要跨位置对照。合同审查是最典型的例子，A处定义了一个概念，B处写了例外情形，C处的补充协议又悄悄改过一次，最后还要结合邮件往来才能判断责任边界。这几处往往不在同一页，却要放在一起看。招股书比对、长会议纪要复盘、论文综述，这些任务都是同一类问题。重点不是总结某一份文档，而是把散落在全篇不同位置的线索串起来。 代码仓库可以归进这一类，但有一个边界值得记住：长上下文模型在小型、结构良好的代码仓库上，表现可以匹配甚至超过检索式方案；但当仓库规模和复杂度增加，检索式方案的优势就会逐渐显现出来。换句话说，几万行、结构清楚、依赖关系不复杂，长上下文可能很舒服；一旦变成多语言、多服务、历史债务很重的大仓库，直接一股脑全塞往往不如先把相关文件和调用链找出来。 不能提前知道哪段有用。事故调查、内部审计、客服历史追踪，这类任务都属于，你没法提前判断关键线索藏在哪一轮对话、哪一条日志、哪一次提交里。这种情况下，先做检索反而可能把真正相关的那段筛掉，给模型更完整的现场，是更保险的做法。 材料结构稳定、可以缓存复用。固定的代码库、固定的知识库、固定的产品文档，长上下文配合前缀缓存，天生适合“同一批材料反复问不同问题”。这时候的成本结构，和每次现查现搜完全不一样。Prompt Caching那篇里算过一个例子：固定的角色设定和规则放前面、每天变化的数据放后面，缓存命中率能跑到97%以上，账单直接压缩十几倍。这种场景下，长上下文的贵，其实被摊得很薄。 多模态长材料。长视频、长音频、扫描件这类材料，切片处理最容易丢掉时间线和跨片段的关联。比如一场两个小时的会议，前40分钟有人提出了一个约束条件，后面又绕了几轮，最后才落到行动项。如果只按时间切成小段分别摘要，模型很容易把前后这层因果关系拆散。长上下文在这里的价值，是让材料按原本的时间线和结构留在一起。厂商演示里经常会展示长视频、长音频里的针检索能力，但这块公开测试没有前面几类那么扎实，先按“值得一试、但别只信演示”的态度看待。 四、什么是伪需求 长上下文：真需求 vs 伪需求 把不会整理材料，包装成需要1M上下文。问题其实只需要三段证据，却把三百页全塞进去问模型“你自己找”。模型可能找对，也可能找错，而且找错了你更难复查，因为你自己都没读过这三百页，拿什么去核对它的答案。这和KV Cache那篇讲过的道理是一回事：新草稿要记状态，不要抄流水账。懒得筛选材料，只是把筛选的责任和风险，一起转嫁给了模型。 把长期记忆误认为上下文窗口。上下文是这一次请求模型能看到的材料，不是可靠的记忆库。真正靠谱的长期记忆，应该有索引、有来源、有更新时间、能处理信息冲突，而不是靠一个聊天窗口越拖越长，指望模型自己记住三个月前说过的话。窗口能装下不等于记得住，这两者是完全不同的工程问题。 把低质量材料越堆越多。重复的、过期的、彼此矛盾的材料堆得越多，模型越容易给出一个看起来面面俱到、实际上是和稀泥的答案。长上下文不会替你清洗数据，材料的质量问题，不会因为窗口够大就自动消失。 简单任务硬上长窗口。分类、改写、短摘要、单文档问答、结构化抽取，这些任务本来就不需要模型读很多，短上下文加检索通常更便宜、更快、也更容易复查。 五、怎么判断自己该不该为长上下文买单 先窄化，再长上下文推理 可以用四个问题来排查： 关键证据是不是可能分散在材料的很多个位置？ 答案是不是必须能引用原文、保留来源出处？ 这批材料会不会被反复使用，而不是问完就扔？ 错一次的代价高不高，值不值得多花钱换一次更稳的判断？ 四条里只中一条，先别急着上1M；中了两三条，可以考虑；全中了，长上下文才是一笔正经投入。 落地的时候，更稳的流程是：先用检索或规则把材料粗筛一遍，收窄到候选片段，再把这些候选片段放进长上下文让模型做深度推理，输出时要求模型标注引用的具体位置，关键任务再做一轮反查校验，把结论倒回原文核对一遍。这不是把检索和长上下文硬凑在一起，有专门的对比研究发现，资源足够时长上下文模型整体表现更强，但检索式方案的成本优势明显，而混合方案能在接近纯长上下文效果的同时把计算成本压下来。放到实际工程里，就是别让模型一上来就读全量材料，也别指望检索一步到位。先窄化，再推理，最后反查，这条链路更像人做严肃审阅时的工作方式。 长上下文不是越贵越好，也不是越长越聪明。它值不值，取决于你有没有把它用在真正需要全局材料的任务上。 如果只是懒得筛材料，1M上下文只会让你更快地把钱花出去；如果任务确实需要跨文件、跨时间线、跨证据链地判断，它才真正开始值这份钱。 窗口大小是能力上限，不是使用说明书。 资料来源 NoLiMa: Long-Context Evaluation Beyond Literal Matching（arXiv 2502.05167）：arxiv.org/abs/2502.05167 NoLiMa公开结果表，用于核对GPT-4.1、GPT-4o等模型数字：github.com/adobe-research/NoLiMa RULER: What’s the Real Context Size of Your Long-Context Language Models？（arXiv 2404.06654）：arxiv.org/abs/2404.06654 Retrieval-Augmented Code Generation综述，代码仓库规模与RAG/长上下文选择的发现（arXiv 2510.04905）：arxiv.org/pdf/2510.04905 Retrieval Augmented Generation or Long-Context LLMs？ 混合方案SELF-ROUTE研究（arXiv 2407.16833）：arxiv.org/abs/2407.16833 OpenAI GPT-4.1官方定价与参数页：developers.openai.com/api/docs/models/gpt-4.1

参数名称、默认值截至2026年7月核对。思考控制机制这半年迭代较快，如果你按本文操作，建议先去对应模型的官方文档确认一遍当前版本的参数是否还是这个名字。 上一篇讲token价格梯队时，提过一句“看不见的思考token也在计费”。 一、一个真实的踩坑现场 2026年4月，OpenAI开发者社区里有人发帖求助。发帖者在调用GPT-5.4时，传了reasoning_effort: "none"，想关掉思考模式——单独测试时这个参数确实有效，思考token归零。但当他在同一个请求里加上max_completion_tokens这个参数后，reasoning_effort的设置被API整体忽略，模型照常进入思考模式，把整段预算全部花在了看不见的推理过程上，最后返回一个空字符串，finish_reason标记为length`。 翻译一下这意味着什么：你以为自己关掉了思考模式，账单却按开着算；你以为请求会给你一个答案，实际上连答案都没能生成，钱已经被思考过程花光了。 这是社区里真实的bug反馈帖[1]。之所以拿它开头，是因为它把这篇文章要讲的核心问题，用一次意外浓缩到了极致：思考token的计费，和你看到的可见文本，从来不是一回事。 二、先把机制讲清楚：你看不见，不代表没生成 看不见，不代表没生成 推理模型（OpenAI的o系列和开启reasoning_effort的GPT-5.x、Google Gemini的Thinking系列、Claude开启thinking参数后的模型）在给出你看到的那句回答之前，会先生成一段内部的“草稿”——业内把这部分叫reasoning tokens或thinking tokens。 关键在于三点： 第一，这段草稿本身也是token，一个一个生成出来的。 它不是模型“想了一下”这么抽象的说法，而是实打实占用计算、实打实计入用量的一段文本，只是大多数平台默认不把它完整展示给你。 第二，计费按的是完整生成量，不是你看到的展示量。 Claude的官方文档写得很直白：即使思考内容被折叠、不返回给用户，依然要按内部实际生成的thinking token数计费——你在响应里看到的字数，和账单上算的输出token数，本来就不是同一个数字[2]。 第三，思考token和最终答案，被算进同一个“输出token池”，按输出价计费。 这意味着模型越贵，“多想一会儿”的每一秒都是按这个模型最高的单价计时——这也是“思考税”这个说法的字面来源。 举个例子方便理解（注意，这是一个用来说明比例关系的示意性推算，不是某次真实调用的实测数据）：假设一次问答，你看到的可见回复只有300个字左右，但模型在给出这句话之前，内部生成了3000个思考token，那么这次调用真正被计费的输出量，大概是3300个token左右——你以为自己在为300字付钱，实际上在为3300字付钱，多出来的十倍，你一个字都没看见。 三、四种翻车方式：钱是怎么被“偷偷”吃掉的 思考税的四种翻车方式 思考税不是一种统一的坑，至少有四种不同的发生机制，前三种都能找到具体的真实案例。 机制一：预算耗尽型——思考吃光配额，答案直接消失 有开发者用GPT-5-mini搭配web_search_preview工具，把max_output_tokens设成了8000，结果依然频繁收到“不完整”的响应。原因是模型把大部分预算花在了思考和搜索调用这两件事上，留给最终JSON输出的token所剩无几[3]。 这暴露的问题很实际：工具调用和思考模式叠加时，预算消耗的速度比单独用思考模式快得多，如果还按“平时够用”的老经验设预算，很容易在这种组合场景里翻车。 机制二：开关失灵型——你以为关了，其实没关 Qwen3.6-35B-A3B有开发者在Hugging Face反馈，设置thinking_budget试图限制思考长度，但实际不起作用[4]；另一份GitHub issue里，有人本地部署Qwen3-14B，同样遇到无法关闭思考模式的问题[5]。 这里有个更容易被忽略的细节：Qwen的开源版模型，enable_thinking参数默认是True；只有部分商业版模型默认是False。也就是说，自己部署开源模型时，如果没有显式传参把思考模式关掉，它很可能一直是开着的——这和你调用商业API时的默认体验，可能完全相反。 机制三：习惯性无感型——两周后才发现的账本 有人在一篇复盘文章里提到，自己跑了两周的代码审查流水线，直到某天去查用量明细里的output_tokens_details.reasoning_tokens字段，才发现每次审查平均生成了约8000个推理token，只为了产出一段大约300字的可见结果[6]。 这类翻车最普遍，也最值得普通用户警惕——不是被平台坑了，是从来没有专门去看过那个隐藏字段，任务一直在跑，账单一直在涨，直到某次心血来潮翻明细才发现。 机制四：累加型——Agent的每一步都在重新“动脑子” 前三种机制，都是单次调用里的问题。Agent场景不一样：读一份文件要判断一下，调一次工具要判断一下，看到工具返回结果要再判断一下，写完代码要判断能不能跑，测试失败还要判断怎么改。 如果每一步都开着思考模式，隐藏token就在跟着每一次决策不断累加。单次调用看着不大，循环几十次之后，滚成的费用就很可观了——Agent的成本，不只来自上下文变长，还来自每一轮决策都在重新计费的“动脑子”。 四、什么样的问题特别容易变贵 拆开看，容易在思考token上多花钱的，通常是这四类： 判断题伪装成简单题。 “这是不是高风险客户”“这段代码有没有安全漏洞”，问题看着是个是非题，但判断过程可能要在内部比对好几条规则、排除好几种歧义，答案短，思考不短。 开放任务。 “帮我优化这篇文章”“重构一下这个模块”，模型不知道优化到什么程度算够，容易在内部反复权衡，多想一轮又一轮。 长上下文任务。 合同、代码库、财报，输入本身就长，模型除了要读完，还要在里面定位关键线索，这个过程本身会拉长思考。 带工具的任务。 每次工具结果返回，模型都要重新判断下一步该怎么走，思考token跟着工具调用次数一起叠加。 落到判断上：这些任务不是不能用推理模型，而是不能默认开最高档去处理。 不同模型，同一个问题：思考上限要显式设置 五、六家怎么设上限：一张对比表 各家的参数名不一样，但机制是相通的：都有一个字段控制思考深度，都建议按任务复杂度显式设置，而不是用默认值糊弄过去。 厂商/生态 控制参数 默认行为 能否完全关闭思考 OpenAI（GPT-5.x / o系列） reasoning.effort（none / low / medium / high / xhigh，具体档位视模型而定） GPT-5.1起默认none，需显式开启 部分模型可以，但max_completion_tokens同传时曾出现开关被忽略的bug Anthropic（Claude） thinking.budget_tokens（旧）→ 新模型迁移为自适应effort 默认关闭，需显式启用 可以，不传thinking参数即可 Google Gemini 2.5系列用thinkingBudget（0关闭，-1动态）；3/3.1系列改用thinkingLevel（low/medium/high） 不显式指定thinkingLevel时，Gemini 3/3.1 Pro默认走high，也就是最贵的一档[7] 2.5系列可以关闭；3系列不可完全关闭，最低只到low 阿里Qwen（DashScope/开源） enable_thinking + thinking_budget 开源版默认True，部分商业模型默认False 可以，但需按版本核实默认值 智谱GLM thinking: {type: "enabled"}（原生API）/ enable_thinking（兼容接口） 需显式启用 可以；官方文档明确写着“思考模式下，思维链按照输出Token计费”[8] DeepSeek 随模型别名路由（如推理专用别名） 思考模式绑定模型别名，非逐次开关 需换用非推理模型别名 这张表里最值得单独说一句的，是Gemini这一条。Gemini 3.1 Pro相比上一代，把思考档位从两档（low/high）扩成了三档（low/medium/high），控制粒度确实变细了；但如果你没有显式传thinking_level，API默认会走high，也就是最贵的那一档。这意味着很多什么参数都没改、只是升级了模型版本的老代码，可能在悄悄地多花钱——这条比“能不能关闭”更值得写进你的检查清单。 ...

价格数据核对时间：2026年7月下旬。文中价格以官方定价页为准，第三方转述的地方我会单独标注。 一开始我以为这篇会写成“模型又便宜了几倍”。真把几家官方价格页翻完，结论反而没那么顺口：最强的那几档没有一路降价，有的主力模型输入价还在往上走。便宜得更明显的，是平时真正拿来写代码、跑客服、做摘要、批量处理文档的那一层。 不是所有模型都便宜了，是能干活的中间档位在往下沉。 过去一年，价格变化最集中的地方不在旗舰档，而在主力档、性价比档、缓存命中和批处理。也就是说，模型厂商没有简单把“最强模型”打折甩卖，而是把更便宜的入口拆得越来越细。 一、先看两张价格表 看价格表之前先统一口径：美元/百万token，输入/输出，不混人民币，不混包月订阅。表里优先用官方API列表价；如果是第三方聚合平台或媒体口径，会在后面单独说明。选型也定一条规则：每家只放它当前最常被开发者拿来干活的那一档，不拿旗舰去对标别家的性价比档，也不拿性价比档去对标别家的旗舰档。 表1：主力档，一年对比 厂商 一年前（2025年7月） 现在（2026年7月） 变化 Anthropic Claude Sonnet 4，$3 / $15 Claude Sonnet 5，首发价$2 / $10（8月31日后回到$3 / $15） 优惠期名义上降了约三分之一，但新tokenizer会让同样文本切出更多token，官方口径约多30%，实际省钱幅度要打折扣 OpenAI GPT-4.1，$2 / $8 GPT-5.6 Terra，$2.5 / $15 输入涨25%，输出涨近一倍 Google Gemini 2.5 Pro，$1.25 / $10 Gemini 3.1 Pro，$2 / $12 按当前价格算，输入涨60% DeepSeek DeepSeek V3，$0.27 / $1.10 DeepSeek V4-Pro，$0.435 / $0.87 输入涨61%，输出降21%，两头打平 表2：性价比档，一年对比 厂商 一年前 现在 变化 OpenAI GPT-4o mini，$0.15 / $0.60 同一型号仍在售，价格没动过 两年持平 Google Gemini 2.5 Flash-Lite，$0.10 / $0.40 Gemini 3.1 Flash-Lite，$0.25 / $1.50 涨150%～275% DeepSeek 一直是$0.14 / $0.28 还是$0.14 / $0.28 两年零变化 阿里 Qwen Plus，约$0.26 / $0.78（第三方聚合平台低价口径） Qwen3.7 Plus，$0.40 / $1.60（官方国际区，256K以内） 官方Plus档位抬高，但不同地域和渠道价差很大 模型价格没有一起下降，真正变化的是价格结构 “性价比档”这个名字听起来该一路走低，但表2里Gemini Flash-Lite反而是涨幅最大的一行。阿里的情况也要小心看，官方国际区、国内区、香港/美国节点、第三方聚合平台的价格并不完全一样，不能只拿最低渠道价当成全网统一价。 ...

先算两笔账。 同样是2000输入token加1000输出token的一次对话，跑500次： 用DeepSeek V4 Flash（输入0.14美元/输出0.28美元每百万token），成本约0.28美元。这时候如果某个应用收你$20/月，账面上就是71倍。 换成Claude Sonnet 5（首发价输入$2/输出$10每百万token），同样规模500次约7美元。这时候$20/月只是不到3倍。 同一句“10倍”，参照系不同，结论能从“离谱”摆到“合理”。这也是这篇文章想讲清楚的第一件事：判断一个AI应用贵不贵，不能只看倍数，要看它到底在用哪个价位的模型，以及这10倍里，哪些是看得见的产品成本，哪些是看不见的加价。 一、中间商加价链条：应用卖的不是一层API 先把这条链条从良性到恶性拆开看，不要一上来就骂“套壳”。 合理的那一层：产品能力叠加 模型API成本只是底层。上面还压着模型路由、并发池、失败重试、内容审核、RAG检索、文件解析、联网搜索、多模态工具、账单系统、客户端开发，最后还有支付通道和应用商店抽成——Apple标准佣金30%，小型开发者计划下，符合上一日历年App收益不超过100万美元等条件的开发者佣金可降到15%；Stripe美国本土卡标准费率是2.9%+30美分。这些都是真实存在、写在合同里的成本。 拿两个真实产品对照： Cursor卖的不是“转发一次对话”，是Agent能力、云端代码库理解、多模型路由——Pro $20/月、Pro+ $60/月、Ultra $200/月（2026年7月定价），价格分层对应的是包含的模型调用额度和优先级，不是纯粹的转发差价。 TypingMind是另一个方向的例子：一次性买断前端功能（Standard档一次性$39，终身授权；更贵的Extended档$79、Premium档$99解锁多模型面板等更多功能），API费用你自己用自己的key去付。这个模式很适合拿来对照——它把“应用费”和“模型费”彻底切开了，你能清清楚楚看到自己到底为界面和功能付了多少钱，用得越多，$39这个门槛摊得越薄。 AI应用加价链条 渠道成本产生的加价：国内的“中转站”生态 国内接大模型API，渠道选不同，价格差距是真实存在的，但多数属于走量折扣、支付便利和接入服务，不一定是欺诈。因为这类中转站价格变动很快，不适合引用几个月前的单一评测价。更稳妥的是看机制：如果渠道方明示模型、单价、发票、服务条款和可用性边界，价差通常属于商业服务；如果它不说明底层模型，还把低价模型包装成旗舰模型，就进入了后面要讲的风险区。 恶性的那一层：套壳与模型偷换 这一层的数据扎实到值得单独拎出来讲。 软件工程师Teja Kusireddy用三周时间逆向了200家拿到融资、公开宣称“自研AI”的创业公司，监控网络流量、反编译JS打包文件、比对API指纹。结果：73%的公司实际是套壳。 最典型的案例：一家号称“革命性自然语言理解引擎”的公司，融资时讲了23次“自研模型”，反编译后发现全部技术含量就是一个系统提示词——“请假装你不是GPT-4”。他们的真实成本约每次查询0.033美元（GPT-4 API输入0.03美元/千token、输出0.06美元/千token，平均一次查询500输入+300输出token），对用户收费每次查询2.50美元，或者$299/月200次——收入约为直接模型成本的75倍。 RAG套壳的情况更夸张：嵌入模型用OpenAI的text-embedding-ada-002，向量库用Pinecone或Weaviate，生成用GPT-4，全部原样调用第三方服务，包装成“先进神经检索+自研嵌入模型”。实际成本约0.002美元/次查询，用户实际支付0.50到2.00美元/次——收入约为直接成本的250到1000倍。调查里200家公司中，真正从零训练模型的只占7%。 这还只是消费级应用。学术界的情况更让人意外。CISPA亥姆霍兹信息安全中心的论文《Real Money, Fake Models: Deceptive Model Claims in Shadow APIs》（arXiv 2603.01919）追踪了17个被称为“影子API”的第三方代理服务，发现它们已经被引用进187篇学术论文，其中116篇（62.03%）发表在同行评审会议或期刊，包括ACL、CVPR、ICLR等。论文揭露了三种经济欺骗手段： 信息溢价：收旗舰版的钱，用能力相近但更便宜的旧版本模型顶替——某API标榜提供Gemini 2.0早期版本，实际用2.5版本的价差超过7倍来牟利 折扣替换：原价收费，后台把闭源大模型换成开源小模型——用户高价点名要GPT-5，指纹识别却发现后台跑的是GLM-4-9B 加价倒卖：在前两者基础上再加一层服务费 经过换算，在GPQA的1273次请求口径下，用户按官方标准费率约支付14.84美元，但实际拿到的等价token价值只有5.70到7.77美元——中间商在这个差价里就能赚走过半利润。 这节的结论：同样一句“加价10倍”，产品能力叠加是合理的（Cursor这类），渠道成本是可以理解的（国内中转站几倍以内），但套壳偷换模型这层，价差可以从75倍一路飙到上千倍，这已经不是“贵”，而是欺诈。 二、怎么判断一个AI应用是不是在割韭菜 给两套检查清单，一套给普通用户，一套给要认真评估的开发者/采购方。 普通用户能自己做的5件事 它是否说清楚具体模型版本。只写“顶级模型驱动”、“GPT级智能”而不说具体模型名和额度规则的，要多留心。 它是否说清楚额度口径。“无限使用”通常不是无限token，看有没有每日限额、高峰降级、慢速队列、积分过期这些细则。 它是否把基础转发包装成高级能力。如果只是转发一次对话，却收费接近专业工具的价格，又没有项目管理、文件解析、协作、历史管理这些配套，这个溢价就站不住。 是否存在未明示的模型降级路由。你以为一直在用旗舰模型，实际大量请求被悄悄路由到便宜模型——这不一定是坏事，但应该被告知。 是否有同类的BYOK方案可对照。允许你自带API key的工具（比如上面提到的TypingMind），最容易照出“前端功能”到底值多少钱，因为模型那部分的钱是你自己直接付给厂商的。 更直接的技术侦查（来自Teja Kusireddy的调查方法） 打开浏览器DevTools的Network标签，跟应用的AI功能互动，看有没有直连api.openai.com、api.anthropic.com——中间可以加一层业务逻辑，但AI能力本身不是它自己的。响应延迟也是一个信号：官方API的延迟通常稳定在一个区间，套壳中转站的延迟经常剧烈抖动。网页源码里搜一下有没有系统提示词残留的关键词，比如“永远不要说自己是OpenAI”这类指令。营销语言也是一个粗筛：具体的技术术语大概率是真的，“先进AI引擎”“智能核心”这类模糊词往往在掩饰什么都没有。 面向开发者/企业采购的审计标准 如果是要给生产环境或研究工作流选API，CISPA论文给出的审计协议值得参考：用LLMmap之类的指纹识别工具，通过输出的余弦距离比对判断模型真实身份——论文实测显示，被测的24个模型端点里，45.83%直接未通过指纹验证，另外12.50%表现出与官方模型的巨大偏差，合计过半的“影子API”偷换了底层模型。在高风险任务上验证更直观：官方Gemini-2.5-flash在MedQA医疗基准上准确率83.82%，影子API平均只有36.95%。这不等同于真实医疗诊断表现，但在该基准上已经显示出明显能力缺口。论文给出的最低审计门槛是：至少24次指纹探测、500样本分布测试比对p值、多次独立会话检查延迟和方差是否异常。 三、词膨胀现象：为什么应用的真实成本比你想的大 用户一句话背后的词膨胀税 前两节讲的是纯利润，这一节讲一笔真实存在、但用户从来看不到的成本。 你看到的是一句简单的提问，模型看到的可能是：系统提示词、角色设定、工具定义、历史对话、上传文件摘要、检索片段、格式约束、审查规则，最后才是你那句话本身。这层膨胀不是应用方故意坑你，而是为了让通用模型套上产品人设、遵守话术规范、能调用一堆功能，必须付出的真实代价。 这个现象在学术界有正式名字——prompt bloat（提示膨胀）。论文《RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation》（arXiv 2505.03275）专门研究了这个问题：当一个应用能调用的外部工具越来越多，把所有工具描述一次性塞进提示词，会导致模型在一堆干扰项里越来越难找到正确的工具——这个现象和“大海捞针”测试是同一个机制，工具池越大，选对工具的准确率下降得越明显。论文设计的检索增强方案，只把和当前任务相关的工具描述注入提示词，实测能把提示词token减少约49%，同时把工具选择准确率从13.62%提升到43.13%，提升超过3倍。反过来说，没做这个优化的应用，光是“膨胀”这一项就在吃掉将近一半的无效token——这些token你不会看到，但每次调用都在计费。 ...