01 一个看似很小的能力

它做的事情表面上很简单：在 brainstorming 过程中，如果需要讨论视觉方案，agent 可以启动一个本地浏览器页面，把生成的 HTML mockup 展示出来。用户在页面里点击选择方案，再回到终端补充文字反馈。下一轮，agent 会读取浏览器里的点击事件，再结合终端里的文字继续推进。

如果只看第一眼，它像是一个“浏览器预览 mockup”的小工具。但真正有意思的地方不在预览，而在它把语言、agent、skill、浏览器和用户点击连接成了一个闭环。

这就很不一样了。UI 不再只是提前做好的产品界面，也不是聊天窗口旁边附带的一张图。它是在某个具体问题出现时，由 agent 临时生成出来，帮人完成判断，然后把结果再送回 agent 工作流。

这个小能力真正刺中的地方是：软件界面可以不再固定存在，而是按需出现。

02 它不是预览，而是一个交互闭环

更震撼的是，它的实现并没有依赖什么庞大的系统。核心就是几个文件：brainstorming skill、visual-companion 指南、启动脚本、本地 server、浏览器 helper 和页面模板。

当前版本运行时没有第三方依赖。`server.cjs` 用 Node 内置模块实现本地 HTTP server、WebSocket、文件监听和事件记录，甚至自己实现了 WebSocket text frame 的编解码。

流程也很克制：agent 启动本地 server，写入 HTML fragment；server 自动套模板并注入 helper；浏览器打开 localhost 后，随着新 HTML 自动刷新。用户点击页面里的选项后，helper 通过 WebSocket 把事件发回 server，server 再把事件写入 `state/events`。

下一轮，agent 读取这些 events，再结合用户在终端里的文字反馈继续推进。也就是说，agent 并没有真的“控制浏览器”。它只是写了一个 HTML 文件。浏览器也没有变成聊天界面，它只是一个视觉协作显示器。

文字对话仍然在终端里进行，视觉判断则被放到浏览器里完成。这种分工非常轻，但非常有效。

03 Skill 不只是流程说明书

过去对 skill 的常见理解，往往会停留在“给 agent 的流程说明书”这个层面：遇到需求先澄清，写代码前先写 spec，实现前先写 plan，遇到 bug 先系统性调试，完成前必须验证。

这当然已经很有价值。因为 agent 很容易犯一些典型错误：没理解需求就动手，没验证就说完成，看到 bug 就猜 patch，写完实现再补一个看起来合理的测试。skill 可以把这些失败模式挡住。

但 Visual Companion 把 skill 的边界往外推了一步。它不只是告诉 agent “应该怎么做”，还把一套可执行的轻量软件能力一起带了进来。

skill 不只是规则。它可以携带工具、协议、运行时和 UI 模板。它开始像一个 agent-native 的产品模块。

04 真正被重构的是产品形态

过去我们理解软件工具，通常会从“做一个软件”开始：设计产品，定义功能，做固定 UI，让用户进入这个 UI 完成工作。

但 Visual Companion 展示的是另一种路径：用户先用语言表达意图，agent 理解上下文，skill 判断什么时候需要视觉协作，本地 runtime 被启动，agent 临时生成 UI，用户在 UI 里做选择，选择结果再回到 agent 工作流。

这里的 UI 不是一个长期存在的软件产品。它是为了当前这个问题、当前这个决策、当前这个上下文临时生成出来的。

需要比较启动页方案，就生成 A/B/C mockup。需要确认信息架构，就生成结构图。需要选择流程设计，就生成 flowchart。需要判断视觉层级，就生成几版界面让人直接看。

这些 UI 的价值不在于长期存在，而在于精确服务于此刻的人机协作。用完以后，它甚至可以消失。

05 软件没有消失，但中心位置变了

这不是说软件不重要了。恰恰相反，Visual Companion 背后仍然需要软件：本地 server、WebSocket、HTML 模板、文件协议、浏览器运行时、事件记录机制，这些都是软件。

但软件的中心位置变了。过去软件是用户工作的入口；现在，在 agent + skill 的形态里，语言可能先成为入口。

用户先说清楚自己要什么，agent 负责理解和推进，skill 负责约束流程和调用能力，runtime 负责把能力跑起来，UI 只在关键节点出现，用来帮助人确认、比较、选择和干预。

这更像一个新的基本单元：skill + runtime + generated UI + event protocol + agent workflow。

06 软件工具的价值会重新排序

如果沿着这个方向继续想，软件工具的价值可能不再只是功能更多、界面更完整、集成更多。

新的问题会变成：谁更能理解人的意图，谁更能组织复杂工作流，谁更能把工程纪律变成可执行约束，谁更能在合适节点生成合适的交互，谁更能让人保持控制，而不是被自动化淹没。

过去的软件工具主要解决“人如何操作机器”。现在的问题逐渐变成“人如何和 agent 共同推进工作”。在这个问题里，UI 的角色会变化。

UI 不再只是功能入口，也不只是状态展示。它可能变成一种临时生成的协作媒介：帮人看清楚选项，帮人比较差异，帮人表达偏好，帮人确认方向，也帮 agent 把抽象讨论落成可感知对象。

这和“做一个页面”不是一个层级的问题。这是软件生产过程里的表达方式变了。

07 这不是一个孤立变化

放到更大的讨论里看，Visual Companion 不是一个孤立现象。Karpathy 讲 Software 3.0，Vercel 讲 Generative UI，Google A2UI 直接把问题命名成 Agent-to-User Interface，Microsoft Research 的 Magentic-UI 则从 human-in-the-loop agentic systems 角度讨论人如何监督、控制和协作。

这些方向和 Visual Companion 不是同一个东西，但它们指向同一个变化：纯文本对话不够了，固定软件界面也不够了，agent 需要在合适的时机，把合适的交互界面生成出来。

更有冲击力的是，Superpowers 这个例子不是一个大平台，不是一套完整 UI framework，也不是某个云端产品。它只是一个 skill 里的轻量能力。

几个文件，一个本地 server，一个 HTML 模板，一个浏览器 helper，一套事件回传协议，再加上 skill 里的流程规则，就把一个临时交互系统编排出来了。

所以真正的变化也许不是“AI 会帮我们写更多代码”，而是软件本身的组织方式开始变化了。这个判断还需要继续消化，也需要缓一缓。