AI圈子首页 · 最新大模型、AI产品、Agent与开源项目动态

DevDay 2026 的发布清单我归成四堆，最扎眼的不是新模型，是限量预览那格。

办公协作堆：Dots、ChatGPT Space、Pages、Teams 加团队自动化，ChatGPT 进了 Slack 和 Microsoft Teams，还有 Meetings 插件测试版、可分享的资料页，以及在合作应用里登录、直接查看订阅用量。

模型和档位堆：GPT-6.1 Sol、GPT-6 Astra Ultrafast、Pro 500 档。开发者工具堆最厚。Codex 云环境、带语音和 /agents 的新版 Codex CLI、Code Review 加自动评审加 GitLab 支持，还有 Codex Security Cloud。

Agents API 拿下了 computer use，Bedrock Managed Agents 由 OpenAI 驱动。平台堆是 MCP 自动化事件、Python 和 Node 两套 MCP 扩展 SDK、插件与 MCP 托管进 Sites，外加 ZDR with Private Safety Processing。

把我拽住的是 Decisions API 的限量预览。判断模型这条线追了这么久，各家在开源侧卷 Jev、Laya、JEMM，OpenAI 把官方接口直接摆上货架，还夹在 Codex 安全云和 computer use 中间。位置本身就是态度，决策要和执行、安全一起进主干，不是外挂玩具。

清单里还藏着一个信号：Code Review 带上了自动评审和 GitLab 支持。评审这道最吃判断的工序被官方接管，跟开源判断模型打的是同一个位置，只是它长在产品里。

整份清单收在一句感叹上：What an incredible time to be building。二十余项里，插件扩展 SDK 和 MCP 事件这两行留的空间最大。本地跑过 Laya，正好拿它跟官方接口对成色。

判断模型落地的最后一公里，被 Unsloth 用一个桌面应用铺平了。开源决策模型 Laya，也就是 Jev 的平替，现在能直接跑在自己电脑上。默认的多语言模型只有 678MB，最低 4GB 内存，CPU 就能跑，Windows、Mac、Linux 通吃，数据一步都不出本机。

规格读下来有四处值得记。首包加载后，多数 CPU 一秒内出结果。一次请求能同时问六十四个问题，是与否、选择、评分全带校准概率。端口开在 Jev 兼容的 API 上，已有集成改个地址就切换。装法三步，配置页打开 Serve requests、下载模型、请求打到本地 8888 端口。

本地化的分量比看起来重。工单路由、退款识别、安全告警分级这类活，最怕的不是算不准，是把内容发出去。数据不出本机这一条，直接解掉了一大批过不了合规审查的场景。以前要向安全团队解释半天，现在一句跑在你自己的机器上就完事。

它还把"要结论不要散文"这个定位又推远了一步。4GB 意味着一台普通办公电脑就能当判断层，不用申请 GPU，也不用等排队。判断和生成的分工落到采购清单上，就是便宜的那部分可以人手一台。

链接我按用途分开存：Mac 和 Linux 用 `curl -fsSL unsloth.ai/install.sh | sh` 一条装完，Windows 装法在 unsloth.ai/install.ps1 ，文档在 unsloth.ai/docs/models/de… ，仓库在 github.com/unslothai/unsl… 。

下一步就看 64 连发的校准概率成色如何，主打 #DecisionModel 和 #4GBRAM 这两张牌的组合。

判断模型的开源赛道又挤进一个。JEMM-27B 把图文决策、工具调用、网页操作和审核塞进了同一个模型。它是 Qwen 基座经专项多模态训练的产物，权重在 Hugging Face 搜 JEMM 就能下，地址在 huggingface.co/models?search=… ，标签里也带了 GitHub 出处。

数字对着 Jev 1.13 和 Laya 摆开：JevBench 二百三十一道公开题答对一百九十八道，准确率 85.7%，Laya 是 58.4%，Kev、Semlf、Von 都在后面。

工具调用从 88.7% 提到 93.3%，截图网页任务从 36.0% 到 54.6%。更要紧的是延迟，五种文字配置全部低于 Jev，单题中位数约 0.3 秒，汇总延迟降了 31.2%。

我最在意的是那个截图项。Jev 只吃文字，JEMM 原生读图，网页任务上的 18.6 个百分点差距基本来自这里。判断模型以前是闭着眼摸牌，现在桌上多了张图，能判的东西一下宽了。界面状态、图表走势、流程卡在哪，这些原本都得先转成文字才轮得到判断。

上手路径也给全了。下载 27B 权重，按 README 装依赖，加载 Qwen 基座加 JEMM 权重，传文本或截图，选择、判断、评分三类接口直接接进现有 agent 工作流。开放权重这条比分数更实在，谁想在自己环境里验一遍都不用求人。

赛道热闹起来是好事。Jev 立的规矩正在被后来者逐条对着打，比它准、比它快、还带图，下一轮该轮到 Jev 出牌了。

让机器人学会新活，Sakana AI 和东京大学这篇论文给的解法是别改模型，让它多试几次。这套方法叫 SAIL，将在 IROS 2026 发表，全称是 Scaling In-Context Imitation Learning。

先把难题摆出来。教机器人新任务，传统路子是收集演示再训练策略，一套下来周期长，换个任务从头来。可基础模型早在海量图像、文本和机器人数据上学过一肚子知识，能不能一分不改，把这些知识直接掏出来用。

GPT-6 Astra 已经能一边聊着天一边操作机械臂，大模型也早被证明能凭几条演示生成整套动作。问题在于，单次生成的轨迹并不可靠。动作目标上一点点偏差，整个任务就崩了，而表现好坏全看给了什么上下文。

SAIL 的思路是测试时缩放，把可靠性堆出来。流程分四步。policy VLM 先以几条成功演示为条件，生成候选轨迹。生成的轨迹不直接上真机，先丢进模拟器里跑。评估 VLM 审看跑出来的视频，指出进度卡在哪。policy VLM 拿着这个反馈修订轨迹，MCTS 也就是蒙特卡洛树搜索负责探索备选、精修有希望的候选。只有挑中的那条才发给真机。

模拟器这一步的位置很关键。它不参与决策，只负责把错误提前暴露出来。真机试错的成本是摔坏东西，模拟试错的成本是几秒钟算力。把试错搬到便宜的场子里，再把结果带回真机，这套换法在自动驾驶和代码评测里早用滥了。搬到机器人上反而显得新鲜，原因就是机器人以前缺一个像样的评审环节。

论文里"评估 VLM 看视频找卡点"这半句，其实是整套设计的枢纽。它说明评审不需要精确到关节角，一段人能看懂的视频就够了。生成的和判断的分工再一次清晰了：一个负责出方案，一个负责看录像挑毛病。这跟我前面聊过的判断层是同一个思路换了壳。

数字给得干脆。六个模拟操作任务里，把搜索预算从一个候选提到四十五个，找到成功轨迹的平均比率从 25% 涨到 73%。他们还把 SAIL 放到了真机上测，说明这套流程不只停在仿真里。多花的算力没有用来让模型更聪明，全用来在模拟里试错和打磨。同一个模型，换的是花算力的位置。

25% 意味着单发单中四次才中一次，这种成功率没人敢让机器臂上产线。73% 也不是高枕无忧，但它把人的角色从随时救场变成了抽检兜底。中间那段距离，全靠四十五次模拟试错垫出来的。

换个角度看，这预示着机器人开发的账本会变。过去贵在演示采集，一段演示要人带着机器臂反复摆，一天下来采不了几条。如果生成加模拟试错这条路走通，贵的部分就挪到算力上。而算力恰恰是这几年一直在降价的东西。成本结构一变，小团队玩机器人的时间点就往前挪了。

落回日常，这套东西对不用机器人的开发者也有参照价值。它示范了给生成环节配评审的完整接法：生成器照常干活，评审只看产出物挑毛病，搜索负责在两者之间多试几轮。写代码的、做内容的都能照抄这个骨架，区别只在于把模拟器换成测试用例、把看视频换成读 diff。哪里有能自动打分的沙盒，哪里就能上测试时缩放，这句话几乎可以当选型口诀。

这跟我近来一直在看的那条线对上了：生成和判断分开，让便宜的判断去喂贵的生成。这篇的特别处是判断对象从文本和代码换成了动作，反馈也不再是打分，是一段能看出卡点的视频。轨迹这种一错全错的东西，恰恰最吃这一套。

论文自己留了余地，说现有模型能从这类反馈里学到多少、还能不能迁移到物理机器人，都还有得学。这句话我信，25% 到 73% 的跳跃发生在模拟里，物理世界的摩擦另算。

博客在 pub.sakana.ai/sail ，论文在 arxiv.org/abs/2603.08269 。四十五倍的搜索预算换接近三倍的成功率，这笔账值不值，得看真机上的返修率怎么算。真机那组数据出来之前，这 73% 先当仿真里的里程碑记着。

jevgrep 出 v0.4 了，省钱比例反而降了，这步取舍值得记。作者把话说明白：又跑了一轮 24 小时的自动研究循环，现在它的智能和 codex、claude 自家的 subagent 持平，成本省 30%。

注意这比原版宣传的 40% 低，他自己的解释是一句大实话，用一点成本换更多智能。仓库在 github.com/dzhng/jevgrep 。

这个数字的变化比数字本身有意思。v0.3 靠砍检索深度省钱，省得多但脑子弱；v0.4 把研究循环补回来，钱多花一点，回答质量追平了原厂。我前几次聊这个工具时留的问题就是它敢不敢砍省下的钱，这版算是给了回答：先保智商，再谈价格。

省钱和保质的排序一向是这类工具的分水岭。只卷价格的，最后都卷到没人敢用；先补能力再回头算账的，才可能进生产环境。24 小时循环这个细节也说明作者把研发当成了产品的一部分在投，不是一次性把代码甩出来就完。

跑分只是起点，敢在版本说明里自曝比例下滑的项目不多见，这份坦诚倒让我更愿意盯它的后续。下一版如果能在持平之上再把 40% 捞回来，那就是两头都赢的曲线。

遥测出错，能让装到用户手里的 app 当场崩掉，Firebase 刚演示了一遍。事故从 2026 年 9 月 28 日 17:41（太平洋时间）开始，131 分钟后 Google 推完服务端修复，全程没动 SDK。

根因是 Firebase Analytics 返回了格式错误的 payload，SDK 收到 200 响应，实验 worker 一处理就崩。18 分钟 56 次崩溃，四个已发布版本同时中招，期间没有任何应用更新。缓存还让尾巴更长，部分实例得再崩最多四小时。

最扎心的是责任错位。遥测本该是旁观者，这次它亲手把产品拉下了线。应用团队只能等修复、等缓存过期，崩溃在 SDK 内部，端上改不了。issue 在 github.com/firebase/fireb… 。

Gergely Orosz 那句我记着：任何 SDK 都不该这么业余，何况工程门槛那么高的公司。包版本锁死了不等于行为锁死了，厂商服务端随时能改你线上应用的行为，这类集成得按生产服务对待。

下次再审 SDK 就问一句：你能不能让应用打不开。答能的，输入验证、故障隔离、赶在初始化前生效的关闭开关，一个都不能少。