模型开始分工，agent 还在丢记忆：7月21日 AI 前沿人物精选

这一轮真正的新信号，不是又出现了一个更强的模型，而是模型开始被按任务阶段分工：前沿模型负责拆解和做关键决策，便宜模型负责大量执行。Aaron Levie 转述 Cursor 的一项研究称，这种组合在一个项目上可带来 15 倍的 token 成本改善；Rauch 根据 Vercel AI Gateway 数据观察到，开放模型的支出占比也正在从边缘位置往上走。12

这轮窗口覆盖北京时间 7 月 21 日 00:12 至 7 月 22 日 00:05。模型更便宜之后，工作流反而提出了更麻烦的问题：记忆会不会丢，谁来验收，招聘时到底该看结果还是看人与 agent 的协作过程。

Levie 转述 Cursor 的研究时，把复杂 agent 的工作拆成两种角色。前沿模型负责最初的任务分解、设计决策和关键取舍，价格更低的模型负责执行已经被写清楚的指令。Cursor 研究称，这样做可以让一个项目的总 token 成本改善 15 倍。1

「15 倍」是 Levie 对 Cursor 研究的转述，不是跨项目、跨模型都成立的保证。它有一个更稳妥的含义：大任务里并不是每一步都需要同样强的推理能力。真正的应用层差异，可能来自系统能否判断什么时候需要强模型，什么时候只需要一个便宜、稳定的执行器。

这也改变了产品设计的重点。模型路由不再只是根据价格做 fallback，而是要理解任务所处的阶段。规划、执行、检查和遇到歧义时的重新分解，可能分别对应不同的模型档位。没有领域知识的路由器，只会把复杂任务拆成一堆看起来便宜、实际反复返工的调用。

Levie 的原帖值得直接读，里面保留了他转述 Cursor 研究的完整边界：

Rauch 发布了一组基于 Vercel AI Gateway 的模型支出观察。他写道，6 月 27 日 Anthropic、OpenAI 和 Google 的合计支出占比曾达到 97.09%；最近几天则降到这段数据里的低位，今天的数值是 83.29%。23

更具体的变化来自 Moonshot。Rauch 称，过去一周 Kimi 的支出占比从 0.60% 升到 5.06%，增长约 8.4 倍；他还写到当天的日环比增长为 114.4%。他随后把 Google 称为这轮变化中的「最大受影响者」，并列出 Z、StepFun 和 DeepSeek 作为支出增长方。34

这些数字描述的是 Vercel AI Gateway 这套数据里的支出结构，不等于整个市场的调用份额，也没有证明 Kimi 的增长一定会持续。Vercel 在 7 月 14 日已经把 AI Gateway 排行榜数据开放为 CC BY 4.0，并支持导出 CSV 或 JSON，读者可以直接查看数据定义和下载入口。5

对应用开发者来说，这比「开放模型便宜」更有用。它说明模型选择正在从架构图走进真实账单，供应商切换、模型可替换性和部署边界，都应该成为产品评估的一部分。

Rauch 的线程从总量变化继续拆到了具体模型，适合作为本轮的原始数据入口：

Josh Woodward 是 Google、Google Labs 和 Gemini App 的负责人。他在 7 月 21 日的推文中称，Gemini 3.6 Flash 在复杂 coding 任务上最多可减少 65% 的 token 使用量，Gemini 3.5 Flash-Lite 的输出速度达到每秒 350 个 token；两者都已在 Gemini App 上线，Gemini 3.5 Pro 则进入合作伙伴测试。6

这条推文没有给出测试集、价格、地区范围或「最多减少 65%」对应的基线，不能据此比较模型质量。它仍然补上了一个产品方向：当模型路由越来越普遍，低延迟和低 token 消耗本身就会变成用户可感知的功能，而不只是后台成本指标。

和 Levie 转述的多模型分工放在一起看，前沿模型负责把任务说清楚，Flash-Lite 这一类模型负责把大量明确工作尽快做完，已经有了产品发布层面的对应物。真正需要验证的是，两者在同一工作流中的切换是否足够稳定。

Aditya Agarwal 说，所有 agent harness 都还存在明显的 memory loss 和 compaction 问题：系统会忘记上下文、变得混乱，而错误发生时又很难解释；他认为把信息存进 skills 可能正是问题根源之一，并希望出现一种更好的格式或语言。7

这条观察和「把更多任务交给便宜模型」正好构成约束。执行模型越多，系统越需要让上下文状态可读、可检查、可恢复。否则一次压缩或错误记忆，可能让后面一长串低价调用都在错误方向上继续工作，账单下降了，返工却上升了。

Peter Yang 给出的补法更具体：让一个 agent 做事，再让另一个 agent 按 rubric 验收。他引用 Thariq 对视频短片的解释，在「好不好」没有确定答案时，独立的验证 agent 需要读取评价标准并给出反馈，因为模型容易偏爱自己的输出。8

这不是质量保证的自动通行证。rubric 写得差，第二个 agent 只会更快地确认一个坏标准；但「执行」和「验收」分开，至少让系统有机会检查输出，而不是让同一个模型既写答案又替自己打分。

Peter Yang 的原帖把这套工作流和 Thariq 的原话放在了一起：

Zara Zhang 提出了一种她会采用的面试结构：第一轮线下面试，不允许使用 AI，测试候选人的领域知识和现场思考；第二轮做一个必须借助 AI 才能完成的项目，考察结果，也查看候选人与 agent 的聊天记录。9

她没有把这说成行业标准，而是回答「如果今天招聘，我会怎么做」。这个方案的重点也不是鼓励或禁止 AI，而是把两种能力分开看：没有工具时，候选人是否理解问题；有工具时，是否知道怎么分解任务、检查结果、纠正 agent。

如果记忆、路由和验收都成为 agent 工作流的一部分，那么聊天记录就不再只是过程日志，也可能是判断一个人是否真正理解任务的材料。代价是招聘者要先建立一套能读懂这些记录的评价标准，否则面试只会从看代码变成看一大段更难读的对话。

Nikunj Kothari 对 AI 创业公司的提醒很直接：开放模型让「护城河」变薄，并不意味着规模和资本会自动成为新的护城河。他列举 Webvan、Groupon、MySpace、Yahoo、AltaVista、Blockbuster、Nokia 等例子，认为真正能支撑长期公司的仍然是值得坚持十年以上的独特洞察，而不是把资本和规模当成替代品。10

这是一位投资人的判断，不是行业统计。但它和今天的模型支出数据放在一起，给产品团队留了一个不太舒服的问题：当模型更便宜、可选供应商更多时，你的优势究竟来自更聪明的路由、更可靠的验收，还是只是暂时买得起更多机器。

模型开始学会分工，真正难的部分却越来越像工程管理：把任务拆对，把状态保存好，把结果交给另一个环节检查，再把这些能力变成用户愿意持续付费的产品。