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
正在加载内容卡片…
企业真正要准备的是换模型
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
正在加载内容卡片…
运行层也在重新分工
Rauch 同一窗口宣布，React 早期核心贡献者 Pete Hunt 将负责 Frameworks 并领导 Next.js，GraphQL 联合发明人 Nick Schrock 则负责 Agentic Developer Experience，目标是让更多 agent 能够开发和改进软件。推文没有给出产品路线图，但从岗位分工看，Vercel 正把框架、数据开发体验和 agent 开发体验放在同一条组织线上。这个判断是对公开任命信息的解读，不是 Vercel 已确认的功能清单。8
正在加载内容卡片…
这也解释了为什么单看模型排行榜不够。榜单回答的是一次任务跑得怎样，框架和 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 要处理邮件、日历和会议记录时，先把「生成待审清单」与「直接执行变更」分开，分别设权限和人工确认点。今天的产品信号已经足够说明，真正的摩擦会出现在这些工作流里。
参考来源
- 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 个月的推文
相似内容
- 登录后可发表评论。