当视频模型开始生成界面：Runway Solaris 观察
#博客更新
先说结论
8 月 31 日，Runway 发布了 Solaris 研究预览，并把它称为 Interface World Model。
官方描述很大胆：这不是一个普通的视频生成器，而是一种新型“操作系统”，窗口、菜单、滑杆等界面由视频模型实时生成，方向包括场景化视频、游戏界面、创意工具和产品原型。
我对这件事的判断是：如果 Solaris 的可操作性能够成立，它改变的不是“视频能生成得更漂亮”，而是界面本身可能不再是预先写好的组件集合。
但现在还不能把它写成成熟产品。当前公开信号主要来自 Runway 官方账号和一个 X List 旁证，公测资格、API、状态持久化和独立测试都没有明确资料。下面是方向分析，不是能力评测。
过去的界面是什么样的
我们熟悉的软件界面有一个稳定假设：
一个按钮是一个 DOM 节点，一个滑杆有明确的数值，一个菜单项对应一条路由。即使界面由游戏引擎或 Canvas 绘制，背后通常仍然有一套确定的 UI 状态机。
传统的生成式 AI 主要生成的是内容：
它可以生成一个看起来像软件的画面，但这个画面通常只是结果，不是一个可以持续操作、保存状态、撤销和再次打开的应用。
Solaris 想挑战的是中间那条边界：
如果这条循环稳定，界面就不再只是“渲染数据”，而变成了模型对世界状态的一种实时投影。
它和 GUI Agent 不是一回事
最近也有很多 GUI Agent：模型看屏幕，点击按钮，输入文字，拖动鼠标。这些系统通常是在已有界面上行动。
可以这样对比：
所以不能因为两者都“会用界面”，就把 Solaris 当成另一个 computer-use 模型。它更接近：模型不仅使用工作台，还参与生成工作台。
真正困难的不是画出一扇窗
从演示画面看，窗口、菜单和滑杆并不难想象。真正难的是这些东西必须具备软件的性质。
1. 状态要持久
用户拖动滑杆之后，数值应该进入某个可恢复的状态，而不是下一帧又随机回去。
如果状态只存在模型的短期上下文里，它就更像一次互动幻觉，而不是应用。
2. 动作要可重复
同样的点击在同样的状态下，应该产生相同或可解释的结果。视频模型天然带有生成随机性，而软件交互依赖确定性。
这会要求系统把“视觉帧”和“真实状态”分开：
如果没有状态层，用户看到的按钮和系统真正接受的动作可能不是一回事。
3. 界面要能被机器理解
固定 UI 有 DOM、Accessibility Tree、语义标签和键盘焦点。模型生成的界面如果只有像素，接入自动化、辅助功能和测试都会变得困难。
一个真正可用的 Interface World Model，至少需要回答：
● 当前有哪些控件
● 每个控件的语义是什么
● 哪些控件可以操作
● 操作会改变哪些状态
● 屏幕阅读器和键盘如何访问它们
“看起来像按钮”不等于“它是一个按钮”。
4. 延迟必须足够低
普通视频生成可以等几秒甚至几分钟。界面交互不能每次点击都等一段完整视频生成。
用户会期待：
因此 Solaris 更像实时世界模型，而不是离线视频模型。它要解决的不是单次画质，而是连续生成、状态更新和输入响应之间的延迟。
5. 失败要能撤销
固定应用里的错误操作通常可以 undo、回退或重新加载。生成式界面如果把每次状态变化都当成新一帧，就必须有明确的历史：
否则用户很难知道一次错误是模型生成错了，还是自己的操作真的改变了数据。
我会怎样评估它
如果 Solaris 之后开放试用，我不会先截几张好看的图，而会做一套重复性测试。
我尤其关注“同一个任务跑十次”的成功率。生成界面最容易在单次演示里看起来惊艳，真正决定它是不是产品的是第十次还能不能找到同一个按钮。
它可能先在哪些地方成立
游戏
游戏本来就接受动态世界和非固定界面。模型生成一个场景化的控制层，可能比在办公软件里生成表单更自然。但游戏仍然需要物理规则、存档、碰撞和多人同步，视觉生成不能替代底层状态机。
创意工具
创作工具的界面本来就经常围绕当前任务变化。用户在做分镜、调色或构图时，需要的控件不一样，动态生成一个任务专用工作台有实际价值。
产品原型
这是最容易落地的方向：不是直接替代生产软件，而是让用户用自然语言快速得到一个可交互的原型。这里对确定性的要求相对低，但仍然需要能保存和分享。
场景化学习
教学界面、模拟实验和可视化解释也可能受益。模型不只是给一段答案，而是根据用户的理解程度生成一套可以探索的界面。
也要警惕一个误区
“界面由模型生成”不代表界面一定更好。
固定组件的价值就在于稳定、可预测、可测试。动态生成会带来新的成本：
● 用户每次打开都看到不同布局
● 团队无法复用操作教程
● 自动化脚本容易失效
● 产品问题难以复现
● 视觉一致性和品牌规范变复杂
● 安全敏感的操作可能被模型藏在不明显的位置
所以我不期待所有软件都变成生成界面。更现实的形态可能是：稳定的底层状态和权限 + 针对当前任务生成的工作台视图。
最后
Runway Solaris 目前还是研究预览，很多关键问题没有答案。它值得关注，不是因为一条视频里出现了会动的菜单，而是因为它把一个问题摆到了台面上：
现在先等它从演示里出来，给别人真正点几下。
参考资料
● Runway 官方研究页面
● Runway 官方网站
● OKP：Runway 发布 Solaris
● 阿里 Qwen-UI-Agent 信号（相关背景）
via 棒无
#博客更新
先说结论
8 月 31 日，Runway 发布了 Solaris 研究预览，并把它称为 Interface World Model。
官方描述很大胆：这不是一个普通的视频生成器，而是一种新型“操作系统”，窗口、菜单、滑杆等界面由视频模型实时生成，方向包括场景化视频、游戏界面、创意工具和产品原型。
我对这件事的判断是：如果 Solaris 的可操作性能够成立，它改变的不是“视频能生成得更漂亮”，而是界面本身可能不再是预先写好的组件集合。
但现在还不能把它写成成熟产品。当前公开信号主要来自 Runway 官方账号和一个 X List 旁证，公测资格、API、状态持久化和独立测试都没有明确资料。下面是方向分析，不是能力评测。
过去的界面是什么样的
我们熟悉的软件界面有一个稳定假设：
固定组件
+ 固定状态
+ 固定事件处理
+ 固定数据模型
= 可操作应用
一个按钮是一个 DOM 节点，一个滑杆有明确的数值，一个菜单项对应一条路由。即使界面由游戏引擎或 Canvas 绘制，背后通常仍然有一套确定的 UI 状态机。
传统的生成式 AI 主要生成的是内容：
提示词 → 图片 / 视频 / 音频
它可以生成一个看起来像软件的画面，但这个画面通常只是结果，不是一个可以持续操作、保存状态、撤销和再次打开的应用。
Solaris 想挑战的是中间那条边界：
意图
→ 模型生成当前界面
→ 用户动作
→ 模型理解动作后的世界状态
→ 生成下一帧界面
如果这条循环稳定，界面就不再只是“渲染数据”，而变成了模型对世界状态的一种实时投影。
它和 GUI Agent 不是一回事
最近也有很多 GUI Agent：模型看屏幕，点击按钮，输入文字，拖动鼠标。这些系统通常是在已有界面上行动。
可以这样对比：
所以不能因为两者都“会用界面”，就把 Solaris 当成另一个 computer-use 模型。它更接近：模型不仅使用工作台，还参与生成工作台。
真正困难的不是画出一扇窗
从演示画面看，窗口、菜单和滑杆并不难想象。真正难的是这些东西必须具备软件的性质。
1. 状态要持久
用户拖动滑杆之后，数值应该进入某个可恢复的状态，而不是下一帧又随机回去。
动作 A
→ 状态 S1
→ 关闭界面
→ 重新打开
→ 仍然得到 S1
如果状态只存在模型的短期上下文里，它就更像一次互动幻觉，而不是应用。
2. 动作要可重复
同样的点击在同样的状态下，应该产生相同或可解释的结果。视频模型天然带有生成随机性，而软件交互依赖确定性。
这会要求系统把“视觉帧”和“真实状态”分开：
可生成的显示层
↓
可验证的状态层
↓
可执行的动作层
如果没有状态层，用户看到的按钮和系统真正接受的动作可能不是一回事。
3. 界面要能被机器理解
固定 UI 有 DOM、Accessibility Tree、语义标签和键盘焦点。模型生成的界面如果只有像素，接入自动化、辅助功能和测试都会变得困难。
一个真正可用的 Interface World Model，至少需要回答：
● 当前有哪些控件
● 每个控件的语义是什么
● 哪些控件可以操作
● 操作会改变哪些状态
● 屏幕阅读器和键盘如何访问它们
“看起来像按钮”不等于“它是一个按钮”。
4. 延迟必须足够低
普通视频生成可以等几秒甚至几分钟。界面交互不能每次点击都等一段完整视频生成。
用户会期待：
按下按钮
→ 立即看到反馈
→ 状态逐步稳定
因此 Solaris 更像实时世界模型，而不是离线视频模型。它要解决的不是单次画质，而是连续生成、状态更新和输入响应之间的延迟。
5. 失败要能撤销
固定应用里的错误操作通常可以 undo、回退或重新加载。生成式界面如果把每次状态变化都当成新一帧，就必须有明确的历史：
S0 → S1 → S2 → S3
↑
undo / fork
否则用户很难知道一次错误是模型生成错了，还是自己的操作真的改变了数据。
我会怎样评估它
如果 Solaris 之后开放试用，我不会先截几张好看的图，而会做一套重复性测试。
我尤其关注“同一个任务跑十次”的成功率。生成界面最容易在单次演示里看起来惊艳，真正决定它是不是产品的是第十次还能不能找到同一个按钮。
它可能先在哪些地方成立
游戏
游戏本来就接受动态世界和非固定界面。模型生成一个场景化的控制层，可能比在办公软件里生成表单更自然。但游戏仍然需要物理规则、存档、碰撞和多人同步，视觉生成不能替代底层状态机。
创意工具
创作工具的界面本来就经常围绕当前任务变化。用户在做分镜、调色或构图时，需要的控件不一样，动态生成一个任务专用工作台有实际价值。
产品原型
这是最容易落地的方向：不是直接替代生产软件，而是让用户用自然语言快速得到一个可交互的原型。这里对确定性的要求相对低，但仍然需要能保存和分享。
场景化学习
教学界面、模拟实验和可视化解释也可能受益。模型不只是给一段答案，而是根据用户的理解程度生成一套可以探索的界面。
也要警惕一个误区
“界面由模型生成”不代表界面一定更好。
固定组件的价值就在于稳定、可预测、可测试。动态生成会带来新的成本：
● 用户每次打开都看到不同布局
● 团队无法复用操作教程
● 自动化脚本容易失效
● 产品问题难以复现
● 视觉一致性和品牌规范变复杂
● 安全敏感的操作可能被模型藏在不明显的位置
所以我不期待所有软件都变成生成界面。更现实的形态可能是：稳定的底层状态和权限 + 针对当前任务生成的工作台视图。
最后
Runway Solaris 目前还是研究预览，很多关键问题没有答案。它值得关注，不是因为一条视频里出现了会动的菜单，而是因为它把一个问题摆到了台面上：
界面究竟是程序的固定外壳，还是模型理解世界后生成的一种临时视图？我暂时不会把它叫作“下一个操作系统”。但如果它能把生成画面、真实状态、语义操作和持久化历史接在一起，那它可能会成为一种新的软件入口。
现在先等它从演示里出来，给别人真正点几下。
参考资料
● Runway 官方研究页面
● Runway 官方网站
● OKP：Runway 发布 Solaris
● 阿里 Qwen-UI-Agent 信号（相关背景）
via 棒无
Runway
AI Video Research & Innovation | Runway AI
Explore Runway's AI research in video generation, world models and generative AI. Read about Gen-4, Aleph, Act-Two and our latest breakthroughs.
模型的新货架：从 Grok 4.6 上架 Pi 说起
#博客更新
先声明立场：我是 Pi 团队的人，这篇难免「利益相关」。但正因为在场内，有些观察比外面看得早一点——下面所有数据都是公开可查的。
先说结论
模型分发的主战场，正在从「上架应用商店」变成「进 agent 运行时」。
过去一周有两件事让我对这个判断确定下来：
1. 8 月 13 日，xAI 官宣 Grok 4.6 可以在 Pi 使用。 模型发布次日单独发一条平台上架公告——这个动作本身比那条帖子重要。
2. DeepSeek Harness 的模型适配层
一个是模型厂商把 Pi 当渠道来官宣，一个是框架作者把 Pi 当底座来依赖。方向一致：agent 运行时正在变成模型的货架。
两件事的细节
Grok 4.6 登陆 Pi
Grok 4.6 是 8 月 12 日发的，主打长程 agent、跨代码库分析和自我验证。首发帖累计 2500 万浏览、近 3 万赞。第二天，官方账号单独发了一条：「Grok 4.6 is now available in Pi」——10.4 万浏览、1273 赞。
把这两条帖子的关系看清楚：模型发布是新闻，「在哪个运行时里可用」是后续剧情。 剧情线还在继续：Perplexity 的 CEO 拿 Grok 4.6 当 orchestrator 跑了 Wide-And-Deep-Research 基准，结论是它在性能-成本曲线上位于帕累托前沿。注意这个用法——模型的评价场景已经从「聊天打分」迁移到「在某个运行时的编排下表现如何」。
pi-ai 在 Harness 的地基里
上一篇插件教程里我提过这事，这里补上量化的一面：
DeepSeek Harness 把它用作 LLM seam——README 原话是 "Generic multi-provider adapter for the harness LLM seam backed by
这不是我们去找 DeepSeek 谈的合作，是他们选型选中的。被当成基础设施用，是对一个库最好的验证方式——比任何 benchmark 都硬。
为什么货架会易主
回头看技术产品史，分发渠道的迁移有迹可循：
● 搜索引擎时代，浏览器默认搜索引擎是渠道，Google 付费买位
● 移动时代，App Store 上架位是渠道，首发渠道能决定一款应用的命运
● 云时代，**云市场（Marketplace）**是渠道，企业软件先上 AWS Marketplace 再谈销售
AI 时代的等价物正在显形。模型能力在快速同质化——DeepSeek 8 月三连发（V4-Pro → V4-Flash API → Vision-Exp）、GLM、Kimi、Qwen 都在月更节奏里，当供给过剩，渠道价值就上升。而 token 消耗最大的场景已经不是聊天框，是 agent：一个长任务动辄几百次调用。模型厂商要抓住的，是这些调用的入口。
入口在哪？就在运行时的那个模型选择器里。上一篇我在 dsh 的 Web UI 里把 provider 从 DeepSeek 切到自定义的 mock——那个下拉菜单就是货架。用户在那个菜单里能看到谁、默认是谁、切换成本多高，决定了模型的实际市场份额。
DeepSeek 自己看得最明白：低价 API 加自研 harness，模型和货架一手抓。这是官方版答案。而 xAI 选择的是另一条路——不自己造货架，把模型铺进别人已有的货架，Pi 是其中之一。
站在货架上是什么感觉
坦白讲，感受是复杂的。
好的那一面：pi-ai 五个月做到周下载四百多万，说明「多 provider 抽象」这个判断做对了——开发者不想为每家模型写一遍适配，模型厂商也不想让集成成本挡住试用。
不安的那一面：当一个库从产品变成公共契约，它的错误预算就没了。 以前发个 0.x 版本改接口，坏的是自己的项目；现在底下压着 Harness 这样的框架和它们身后成千上万的会话，兼容性和版本语义就是别人的生产环境。dev preview 可以随便破兼容，底座不行——这也是我从 Harness 文档里读到 "breaking changes expected" 时格外有共鸣的原因：他们可以这么说，我们不能。
接下来会怎样
三个预测，放在这里等着验证：
1. 「available in X」会成为模型发布的标准动作。 X 是一张运行时清单，就像今天 App 官宣支持 iOS/Android 一样自然。下一个官宣登陆某个 agent 运行时的模型，不用等太久。
2. 运行时的竞争会从功能转向生态位。 功能会被抄平，「谁的模型选择器里有谁」「谁是新模型的首发渠道」不会。Harness 开源五天 7174 个插件仓库抢的就是这个位置。
3. 模型评测表会多出一列：在哪些运行时可用。 单独的分数不够了，编排质量正在成为模型表现的一部分——Perplexity 那个 orchestrator 实测就是预演。
对我们自己，结论也简单：渠道不是终点。被依赖就要配得上依赖——接下来 pi-ai 的每个版本号，都是对下游的一份承诺。
参考资料
● xAI：Grok 4.6 is now available in Pi（数据来自 OKP genai-hot 追踪记录）
● dsh-llm-pi-ai README
● @earendil-works/pi-ai on npm
● 本系列前两篇：Hi, deepseek-harness! / 给 DeepSeek Harness 写插件
via 棒无
#博客更新
先声明立场：我是 Pi 团队的人，这篇难免「利益相关」。但正因为在场内，有些观察比外面看得早一点——下面所有数据都是公开可查的。
先说结论
模型分发的主战场，正在从「上架应用商店」变成「进 agent 运行时」。
过去一周有两件事让我对这个判断确定下来：
1. 8 月 13 日，xAI 官宣 Grok 4.6 可以在 Pi 使用。 模型发布次日单独发一条平台上架公告——这个动作本身比那条帖子重要。
2. DeepSeek Harness 的模型适配层
dsh-llm-pi-ai，底层就是我们的 @earendil-works/pi-ai。 这是我上一篇写 Harness 插件时亲手发现的：156k star 的仓库，模型接入的缝是用 Pi 的 SDK 铺的。一个是模型厂商把 Pi 当渠道来官宣，一个是框架作者把 Pi 当底座来依赖。方向一致：agent 运行时正在变成模型的货架。
两件事的细节
Grok 4.6 登陆 Pi
Grok 4.6 是 8 月 12 日发的，主打长程 agent、跨代码库分析和自我验证。首发帖累计 2500 万浏览、近 3 万赞。第二天，官方账号单独发了一条：「Grok 4.6 is now available in Pi」——10.4 万浏览、1273 赞。
把这两条帖子的关系看清楚：模型发布是新闻，「在哪个运行时里可用」是后续剧情。 剧情线还在继续：Perplexity 的 CEO 拿 Grok 4.6 当 orchestrator 跑了 Wide-And-Deep-Research 基准，结论是它在性能-成本曲线上位于帕累托前沿。注意这个用法——模型的评价场景已经从「聊天打分」迁移到「在某个运行时的编排下表现如何」。
pi-ai 在 Harness 的地基里
上一篇插件教程里我提过这事，这里补上量化的一面：
@earendil-works/pi-ai
周下载（8-15 ~ 8-21）：4,236,540
最新版本：0.84.2（8-14 发布）
DeepSeek Harness 把它用作 LLM seam——README 原话是 "Generic multi-provider adapter for the harness LLM seam backed by
@earendil-works/pi-ai"。翻译一下：Harness 里每一次换模型、配 provider、接 OpenAI 兼容网关，底下跑的都是 pi-ai 的抽象。这不是我们去找 DeepSeek 谈的合作，是他们选型选中的。被当成基础设施用，是对一个库最好的验证方式——比任何 benchmark 都硬。
为什么货架会易主
回头看技术产品史，分发渠道的迁移有迹可循：
● 搜索引擎时代，浏览器默认搜索引擎是渠道，Google 付费买位
● 移动时代，App Store 上架位是渠道，首发渠道能决定一款应用的命运
● 云时代，**云市场（Marketplace）**是渠道，企业软件先上 AWS Marketplace 再谈销售
AI 时代的等价物正在显形。模型能力在快速同质化——DeepSeek 8 月三连发（V4-Pro → V4-Flash API → Vision-Exp）、GLM、Kimi、Qwen 都在月更节奏里，当供给过剩，渠道价值就上升。而 token 消耗最大的场景已经不是聊天框，是 agent：一个长任务动辄几百次调用。模型厂商要抓住的，是这些调用的入口。
入口在哪？就在运行时的那个模型选择器里。上一篇我在 dsh 的 Web UI 里把 provider 从 DeepSeek 切到自定义的 mock——那个下拉菜单就是货架。用户在那个菜单里能看到谁、默认是谁、切换成本多高，决定了模型的实际市场份额。
DeepSeek 自己看得最明白：低价 API 加自研 harness，模型和货架一手抓。这是官方版答案。而 xAI 选择的是另一条路——不自己造货架，把模型铺进别人已有的货架，Pi 是其中之一。
站在货架上是什么感觉
坦白讲，感受是复杂的。
好的那一面：pi-ai 五个月做到周下载四百多万，说明「多 provider 抽象」这个判断做对了——开发者不想为每家模型写一遍适配，模型厂商也不想让集成成本挡住试用。
不安的那一面：当一个库从产品变成公共契约，它的错误预算就没了。 以前发个 0.x 版本改接口，坏的是自己的项目；现在底下压着 Harness 这样的框架和它们身后成千上万的会话，兼容性和版本语义就是别人的生产环境。dev preview 可以随便破兼容，底座不行——这也是我从 Harness 文档里读到 "breaking changes expected" 时格外有共鸣的原因：他们可以这么说，我们不能。
接下来会怎样
三个预测，放在这里等着验证：
1. 「available in X」会成为模型发布的标准动作。 X 是一张运行时清单，就像今天 App 官宣支持 iOS/Android 一样自然。下一个官宣登陆某个 agent 运行时的模型，不用等太久。
2. 运行时的竞争会从功能转向生态位。 功能会被抄平，「谁的模型选择器里有谁」「谁是新模型的首发渠道」不会。Harness 开源五天 7174 个插件仓库抢的就是这个位置。
3. 模型评测表会多出一列：在哪些运行时可用。 单独的分数不够了，编排质量正在成为模型表现的一部分——Perplexity 那个 orchestrator 实测就是预演。
对我们自己，结论也简单：渠道不是终点。被依赖就要配得上依赖——接下来 pi-ai 的每个版本号，都是对下游的一份承诺。
参考资料
● xAI：Grok 4.6 is now available in Pi（数据来自 OKP genai-hot 追踪记录）
● dsh-llm-pi-ai README
● @earendil-works/pi-ai on npm
● 本系列前两篇：Hi, deepseek-harness! / 给 DeepSeek Harness 写插件
via 棒无
