Kimi K3 抢到 Next.js eval 首位，Levie 说便宜模型会让总用量上升：7月17日精选
本期从 Kimi K3 在 Next.js agent 评测中的表现出发，梳理开放模型、企业模型路由、agent 运行层与非工程工作流的新信号。
先看一个不该被夸大的成绩
Guillermo Rauch（@rauchg，Vercel CEO）转发的 Next.js AI agent 评测页，把 Kimi K3 排在当前结果第一行：在这组网页工程任务里，Kimi K3 用时 199.89 秒，基础通过率 92%，配合额外文档后的通过率为 96%；Claude Fable 5 high 的两项通过率相同，但用时 233.93 秒。评测页标注的最近运行日期是 2026 年 7 月 9 日，所以这不是「Kimi K3 已经全面胜过闭源模型」的证明，只能说明它在这套任务和这次运行中跑到了前面。1
Rauch 的原话更激进：这是他第一次看到开放模型在这项综合网页工程 benchmark 上领先所有闭源模型。Dan Shipper（@danshipper，Every CEO）随后说，团队会实际 vibe check Kimi K3，但「extraordinarily skeptical」它能和 Fable 一样好。两句话放在一起，信息量比单独的榜单更高：开放模型的上限正在逼近，但评测结果仍需要回到真实工作流里复现。23
Cargando tarjeta de contenido…
企业真正要准备的是换模型
Madhu Guru（@realmadhuguru，Meta AI 高级总监）给企业 AI 写了一份更实用的检查表。他把模型可选性拆成三层：先用贴近业务的 evals 测出回归能力和更难的爬坡任务，再按质量、成本、延迟做 model routing，最后用与模型无关的 harness 统一 prompt 结构、上下文、工具定义和输出解析。这里的 harness 可以理解成包在模型 API 外面的运行层，业务系统不应该知道每次调用背后是哪一个模型。4
他在另一条推文里补上了落地瓶颈：企业卡在基础聊天机器人之外，原因之一是缺少能同时搭建 evals 和 harnesses 的人才。这个判断来自个人观察，不是企业普查数据，但它指出了一个经常被价格讨论遮住的成本：模型能换，不等于组织已经有能力验证换完之后是否仍然可用。5
Aaron Levie（@levie，Box CEO）从需求侧补了一层。他认为 AI 越便宜，能部署到真实工作负载里的任务就越多，便宜或更适配的模型可以承担大量 token，最强的前沿闭源模型则可能继续负责复杂任务的编排。Levie 也提醒，效率提升会推高总用量，最先承压的可能是模型层的利润，而不是整个 AI 栈的需求。6
这让 Aditya Agarwal（@adityaag，South Park Commons 普通合伙人、Bevel Health 联合创始人）的个人实践有了具体落点：他写道，自己正在把系统从 Fable 切走，因为有「good and free alternative」。这是一条个案信号，不能当成普遍的模型替换结论，但它说明模型可选性一旦进入已有系统，比较的单位就会从「哪个模型最强」变成「哪个模型在我的任务上值得付费」。7
Cargando tarjeta de contenido…
运行层也在重新分工
Rauch 同一窗口宣布，React 早期核心贡献者 Pete Hunt 将负责 Frameworks 并领导 Next.js，GraphQL 联合发明人 Nick Schrock 则负责 Agentic Developer Experience，目标是让更多 agent 能够开发和改进软件。推文没有给出产品路线图，但从岗位分工看，Vercel 正把框架、数据开发体验和 agent 开发体验放在同一条组织线上。这个判断是对公开任命信息的解读，不是 Vercel 已确认的功能清单。8
Cargando tarjeta de contenido…
这也解释了为什么单看模型排行榜不够。榜单回答的是一次任务跑得怎样，框架和 harness 决定的是任务能不能稳定进入产品，能不能换模型，出了错有没有地方回放。对企业来说，开放模型的进步会把更多预算从「买一个默认模型」推向「把自己的评测和运行层做起来」。
agent 正在接触更多非工程工作
cat（@_catwu，Anthropic 的 Claude Code 与 Cowork 团队成员）邀请市场、销售、财务、法务等非工程岗位的 Cowork 用户参加 30 分钟屏幕分享，展示自己的工作流，帮助团队改进产品。这不是功能发布，而是一条很具体的产品研究信号：agent 产品开始把「用户如何在真实业务里使用它」当作输入，而不是只围绕开发者 demo 迭代。9
Peter Yang（@petergyang）展示了自己的定时任务：让 Codex 或其他 harness 管理邮箱和日历，先列出待处理的邮件事项、可退订对象和会议简报，再交给他审核。他描述的是整理与提交审阅，不是让 agent 直接替他发送邮件或改动日历；这条边界很重要，因为任务一旦从「准备清单」变成「代替执行」，权限和误操作成本会立刻变高。10
Zara Zhang（@zarazhangrui）则观察到，几年前人们还会介意会议录音，如今很多商业会议默认会被记录，服务对象从人变成了 agent。她是在描述文化变化，不是在报告一项统计调查，但这条观察与 Cowork、邮箱和日历任务放在一起，说明 agent 的上下文入口正在从聊天框扩展到组织日常留下的记录。11
产品侧的两个更新
Google Labs 说，Project Tailwind 最初只是一个小实验，后来成为 NotebookLM，现在团队向 Gemini Notebook 迁移；Josh Woodward（@joshwoodward，Google 副总裁）同一窗口写道，Notebook 已经有超过 3000 万用户和 60 万家组织使用。这里的数字来自 Josh 的个人推文，文章把它当作他的公开说法，不延伸成 Google 的完整经营口径。1213
Sam Altman（@sama）说，自己现在和 ChatGPT 对话的时间已经多于打字，新的 voice model「really crossed a threshold」。他还写道，OpenAI 接下来 12 个月可能是公司迄今最好的一年，希望 AI 给更多人自由、能动性和财富。这两条都是 Altman 的产品体验和公司展望，不等同于独立的语音能力评测或已公布的产品路线。1415
给产品和工程团队的三个检查点
- 把公开 benchmark 当作候选筛选器，不要当成上线结论。先拿自己的高频任务、失败案例和需要人工兜底的边界，做一套能快速回归的 eval。
- 在模型接口之外保留路由和上下文层。至少把 prompt、工具定义、输出解析和日志格式统一起来，换模型时才不会连业务代码一起重写。
- agent 要处理邮件、日历和会议记录时，先把「生成待审清单」与「直接执行变更」分开，分别设权限和人工确认点。今天的产品信号已经足够说明，真正的摩擦会出现在这些工作流里。
Fuentes de referencia
- 1Next.js AI Agent Evaluations
- 2Guillermo Rauch 关于 Kimi K3 的推文
- 3Dan Shipper 对 Kimi K3 的保留意见
- 4Madhu Guru 关于企业模型可选性的推文
- 5Madhu Guru 关于企业 AI 人才缺口的推文
- 6Aaron Levie 关于 AI 成本与模型分工的推文
- 7Aditya Agarwal 关于切换模型的推文
- 8Guillermo Rauch 关于 Pete Hunt 与 Nick Schrock 加入 Vercel 的推文
- 9cat Wu 征集 Cowork 工作流的推文
- 10Peter Yang 关于 Codex 定时任务的推文
- 11Zara Zhang 关于会议录音与 agent 的推文
- 12Josh Woodward 关于 Notebook 用户规模的推文
- 13Google Labs 关于 Gemini Notebook 的推文
- 14Sam Altman 关于 ChatGPT 语音体验的推文
- 15Sam Altman 关于 OpenAI 未来 12 个月的推文
Contenido relacionado
- Inicia sesión para comentar.