一、界面模式的消亡正在发生
2025 年快结束，仍有人认真在问一个问题：“AI 应该坐在界面的哪里？”。
Sharang Sharma 在《Where should AI sit in your UI?》一文中写道，AI 应当被“安放”在合适的界面结构里——一个 Side Panel、一个 Inline Assistant、或一个 Magic Button。设计师仍相信「智能有位置」，ta们讨论的是“界面容纳智能”的空间逻辑，而非智能本身的运行逻辑。
回到 2023 年，微软设计团队在《Behind the Design: Meet Copilot》中描绘了一场壮丽的协作神话：AI 被邀请进入文档，坐在文字的边缘，成为人类思考的“第二光标”。那时的界面仍是舞台，而 AI 是演员。设计语言、光效、呼吸节奏都在暗示一种崭新的「人机共创叙事」。
我们当时仍深信——“智能需要一个位置”，仍相信设计师的任务，是为 AI 造一张椅子、一道入口、一个召唤符。
然而，Atlas 出现后，一切问题都变得过时。
在 Atlas 的世界里，AI 不再被安放在界面之中，而是贯穿其间、驱动其行。智能成为运行时的电流，UI 则退化为短暂的感应层。所有关于“放置”的讨论，都成了失效的建筑图纸。
到这里，我们真正失去的，也许不是某种界面样式，而是对“界面”这一概念的依恋。某种更深的转向，正在静默地发生。
二、Atlas 带来设计范式坍塌
Atlas 的出现，并非一次线性的版本演化，而是一次范式的坍塌——它终结了那种将“界面视为人机沟通中介”的古典假设——那种人机之间的往返、点击与反馈、界面与任务的映射关系，正在被溶解。随着计算逻辑与智能推理的融合，交互层退化为短暂的显影——智能成为真正的操作系统。
然而，崩塌的并非界面本身，而是我们对“交互范式”这一概念的想象。
在旧的秩序中，界面是一种有形的建筑——它以边界维系秩序：标签页、按钮、菜单栏构成了可见的操作几何，行为被限定在明确的框架之内。而在 Atlas 的逻辑中，这种结构被解除了。墙体消失，空间变得渗透而流动。智能不再被召唤，它始终在场；操作不再发生，而是在被推理、被理解中完成。界面不再是“人机交互的表面”，而是一种持续的感知媒质。
而按钮与菜单被保留下来，只为让人类暂时不感到迷失。真正的智能界面早已下沉：它不再显现在屏幕表层，而是在运行时逻辑中以智能方式运作。
Atlas 不是新范式的代表，而是范式本身的终结者。它让设计失去了对象，却因此重新获得了维度——因为设计的焦点，从形态转向了运行时。
三、Atlas背后的OWL
Atlas 的根基不是一个视觉或交互层面的创新，而是一种架构性断裂。它的核心在 OWL——OpenAI Web Layer，一套将 Chromium 浏览进程完全抽离到宿主之外的系统架构。
在技术层面，OWL不仅是一个比喻性的“层”，它是一种全新的浏览器进程架构。传统浏览器（例如 Chromium）把界面逻辑与渲染引擎封装在同一应用进程中，而 OWL 通过 IPC（进程间通信） 将两者彻底解耦：Atlas App 负责系统界面与交互层，而 Owl App 独立承载 Chromium 的所有渲染与网络进程。
这种结构设计的关键考量有三点：
隔离性：把 Chromium 进程移出主应用可防止引擎级的 Jank 或崩溃波及界面层。Atlas 得以保持即时响应和稳定运行，哪怕渲染线程阻塞或崩溃，也不会“拖垮”整个应用。 异步通信：两者通过 Mojo 通道交互，Swift 端调用宿主接口时不再等待引擎同步返回。这意味着推理、渲染、输入事件处理等流程可以并行展开，使 UI 与 AI 推理真正实现时间解耦。 可移植与可维护：OWL 将 Chromium 封装为预构建二进制组件，而非源级依赖。这样开发者无需重编译 Chromium，即可在 SwiftUI 层快速试验交互、动画与 Agent 模式。它让浏览器不再是一个庞大的单体应用，而是一个可以被智能系统“调用”的服务。
这种“宿主-引擎分离”的体系，正是 Atlas 能成为 AI 运行时 UI 的前提。
OWL 使 Atlas 获得了三种特性：可自治（Autonomous）、可并行（Concurrent）、可持久（Persistent）。它把浏览器从一个用户入口，转化为智能系统的执行节点，一种实时的、可被 AI 调度的可视操作层。
随着 OWL 的引入，界面不再是交互的表层，而是智能运行的可视层。计算进入常驻态，设计也随之失去了“形态”的稳定性。这并非视觉的革新，而是一场认知的重置：当系统持续运行，设计必须重新定义自身。
四、从模式设计到运行时设计
如果回到计算史去看，我们就会发现：所谓的“交互革新”，从来不是由界面语言自发产生，而是被执行层的结构变化一步步逼出来的。
在真空管批处理时代，计算仍是离线的，尚无交互可言；到分时系统与桌面操作系统，促成了“直接操纵”这一范式的诞生；再到分布式的 AI 推理，将“操作”让位给“意图—执行”的长事务——每一次交互的诞生，都是运行时约束被解除的副作用，而设计的每一次进化，也都是运行时性能的副产品。
当执行结构的重构达到临界点，设计的任务也被迫改写。界面不再是结果的容器，而成了过程的副产物；用户不再操作系统，而与其并行运算。于是，“模式”与“运行时”这两个词，开始在设计语境中并置——前者维护秩序，后者管理流动。
模式设计与运行时设计的区别，不仅是方法的更替，更是设计对象的转移。模式设计建立在确定性的系统之上，关注视觉与交互模板的复用，以静态定义维持一致性；而运行时设计面向动态系统，处理持续变化的执行行为，需要在不确定的环境中保持自洽。
这场转变意味着设计的焦点，正在从形态的控制转向机制的编排，从模板化的秩序转向系统性的透明。
运行时设计的任务，是为分布式、异步、持续学习的智能环境建立秩序。它关注系统如何在时间中维持解释性、稳定性与信任感——包括决策过程能否被追踪，响应是否可被中断与修正，反馈是否保持一致。
设计师的角色也在随之变化：他们需要理解执行机制的节奏与边界，确保智能的行为在可见范围内被感知、被调节。这不是放弃设计，而是让设计进入系统的运行结构之中。
过去，设计师塑造的是人与计算机之间的界面；如今，他们面对的是智能与人类之间的交互结构。设计不再停留在“如何看见”，而延伸到“如何持续运作”。
五、模式正在消亡，运行时已来
我们正在进入一个难以命名的时代。界面依旧存在，却不再是经验的前台；模式依旧运作，却不再统治形式。计算的表层被剥离，显露出一个持续运行、无需呈现、以自身逻辑维持秩序的智能世界，设计随之从形象生产转向时间与过程的组织。
过去的范式以“形态的控制”为中心，我们为操作划定边界、为系统设定模式；如今，运行时接管了界面的地位，设计的任务变成对过程的治理与对可变性的容纳。符号更多用于触发而非表述，美学关心的也不再是构图的平衡，而是行为在时间维度上的稳定与可解释，人机之间的距离被持续压缩，交互被吸收入执行的连续体。
这一转向并非偶然，而是计算史的必然结果。从批处理到分时，从窗口到智能，每一次界面的出现都源于运行时能力的扩展，每一次设计的进化都是系统复杂度的副产物。常驻、并行、自校正的智能系统出现之后，设计不再主要塑造图形，而是调节智能与人之间的透明与信任，设计师从“创造界面的人”变成“编排运行的人”。
模式的消亡，并不是设计的终结，而是语言的迁徙：它离开视觉的疆域，进入系统内部，离开手势的控制，进入算法的自我调度。旧有模式的崩塌，为新的运行秩序提供了能量，浪费不再是错误，而是演化的机制。
The Wasted Modes 不是一首哀歌，而是一场告别仪式。
消亡的，并不是那些界面本身，而是它们所承诺的确定性。当这种确定性被消耗殆尽，运行时才显露出作为时间结构的真正面貌：一种不再依赖形态的设计语言。设计的未来将不再属于界面，而属于时间。
我们创造的一切，将在持续的运行之中被理解、被见证、被延续。
