每日AI新鲜事·10月13日晚间版：Muse Wonder 迷路与本地AI

今天AI圈又有不少新动静. 而且是那种一看就想聊两句的.

今天咱们主要聊这么几件. 一是 Obsidian 本地对话. 二是邮件本地总结. 三是 Elixir 轮询烧钱. 四是简化上限失效. 五是个人AI幕僚长. 六是 Muse Wonder 迷路. 七是 Muse Wonder API 坑. 八是模型选型实测.

嗯.

好, 那咱们先从轻一点的新闻开始, 再往深里聊.

第一条, 我在 dev.to 上看到一篇挺有意思的. 讲的是怎么在2026年跟自己的 Obsidian 笔记对话, 而且不用把整个笔记库上传到任何AI服务.

这个点很实在. 工具叫 OGAD, 全称 Off Grid AI Desktop. 它直接连你本地的 Obsidian 文件夹.

然后给选定的模型配上工具, 让它能列出, 搜索, 读取你的 Markdown 笔记. 模型跑在你自己的算力上.

所以核心卖点就是隐私对吧. 对于重度笔记用户来说, 这个吸引力不小.

对. 不过代价是本地模型的推理能力, 跟云端前沿模型还是有差距. 看你更在意隐私还是更在意回答质量.

第二条还是 OGAD 相关. 这次是自动总结客户发来的新邮件, 同样用本地AI.

OGAD Pro 能检测到匹配的新邮件, 自动跑一个助手流程. 帮你识别客户的需求, 截止时间, 还有下一步要做的决定.

结果你直接读就行. 本地文本模型跑, 内容不出你电脑.

这个场景其实挺真实的. 很多人一天最烦的就是翻邮件, 找哪封是客户真正要的.

第三条我一看标题就笑了, 63美元一晚, 讲的是一个 Elixir 轮询循环烧钱的真实案例.

这种故事特别有教育意义. 轮询循环看着无害, 但你没设好退避和上限, 一晚上账单就上来了.

对, 尤其现在AI相关接口按调用量收费, 一个小 bug 可能比服务器本身还贵.

所以工程上, 限流和成本监控要跟功能一起上线, 不能等出事再补.

第四条没那么热闹, 但我觉得值得说. 标题是简化, 上限只约束你能数清的部分.

这篇讲的是团队里定好的约束, 开会同意了, 午饭前就被违反了.

每次加个参数, 加个 flag, 单个决定都合理, 但没人拍板说我们要让代码变复杂.

这不就是很多AI系统里的隐性债嘛. 模型能力越强, 越容易往上面堆特例.

没错. 能数清的上限容易执行, 数不清的那种复杂度, 才是真麻烦.

然后还有一条 OGAD 的. 教你怎么在自己电脑上搭一个个人AI幕僚长.

它的思路是把日历, 笔记, 还有没做完的任务都汇到一个助手那儿. 你问它现在最该关注什么.

等于把你散在各个 app 里的上下文串起来了. 这个方向我挺看好的.

方向是好, 但数据接入越多, 权限边界就越要小心. 不然幕僚长就变成全家桶了.

好了新闻就先聊到这儿, 接下来我们聊聊今天最火的话题, 就是 Meta 那个新前沿模型 Muse Wonder.

Reddit 上有个帖子传得特别广, 说有人让 Muse Wonder 首日跑宝可梦红. 结果花了96美元, 连第一片森林都没走出去.

我看了那个记录. 它前59回合到常磐市, 速度跟最快的智能体一样.

然后第208回合走进常磐森林, 之后792个回合都在里面打转. 六个小时没出来.

这不就是导航能力的问题嘛. 明明前面对得挺好, 一进复杂环境就崩了.

重点不在这里, 重点在它没有形成稳定的空间记忆. 每一步都像重新做决策.

在开阔地图上这叫探索, 在森林里这就变成无限循环了.

可是很多模型评测都拿宝可梦当长程任务基准啊, 森林这一关是不是太苛刻了.

不苛刻, 这恰恰暴露了一个断层. 单步推理强, 跟长程规划强, 是两回事.

而且96美元这个数字很扎眼. 前沿模型跑长程任务, 成本会指数级堆上去.

所以这其实是个挺好的压力测试. 能力边界和成本边界同时被照出来了.

对. 所以结论是, 长程任务的评测不能只看最终通关率, 得看它在闭环环境里会不会退化成原地打转.

那正好聊到另一个 Muse Wonder 的话题, 就是 API 上那五个坑, 标题说换之前得先知道.

这个含金量很高. 有个很反直觉的点, Meta 发了两个模型, Muse Wonder 和 Muse Wonder Full.

但 API 上只有 Wonder, 版本号是 muse-wonder-1.0. 也就是最强的那个并不在线上.

等一下, 那大家拿 benchmark 比较的到底是哪个版本啊? 这就很容易误导人了.

所以这篇文章的意思是别只看跑分. 得看模型卡和第三方独立测量, 再决定要不要接进生产.

而且你从 Claude 迁过去, 接口行为, 计费方式, 还有能力上限, 都得重新对一遍.

所以总结一下, 换模型别只看榜单总分. 先确认线上版本, 再看实测, 再看迁移成本.

对, 你这句总结比我说的到位.

那还有一条也是模型选型相关的. 有个团队把八个新模型放到真实问题上跑了一遍.

他们内部的 AI 智能体叫 Dory, 住在 Slack 里. 工程师用得最多, 但提问的人很多是做客户支持的.

他们把八个模型拿来回答用户真问的问题, 然后请两家公司的 AI 裁判, 对着代码和数据逐条核对.

这个评测思路我觉得很值得学. 不是刷榜, 是拿自己业务里最常出现的问题去压.

对. 而且用不同公司的裁判交叉验证, 能降低单一模型的偏好.

总结一下就是, 模型选型的正确姿势, 是拿自家真实问题去测, 再看交叉审核的一致性.

那今天就先聊到这儿. 本地AI和前沿模型的边界, 感觉还能再挖几期.

嗯, 下回我们可以专门聊聊智能体的成本监控. 那今天就这样.

好, 明天见.