我们站在哪里 — 从哪里开始，又提出什么

走过十三篇。收一下。

两条轴

「这和那些有什么不同」原来是两个问题。

对在设备里跑应用的平台 — 生意归谁。 那边由拥有设备的一方做生意，扩张按台数计。这里由拥有领域的人各自去做，扩张按领域数计。而且两者不是要打的位置 — 作为一个应用走进去，那块屏幕就成了操作外部设备的位置。

对模型打开的窗 — 那扇窗归谁。 MCP Apps 是模型给人看的窗，这一扇是人直接操作机器的窗。前者拿掉模型就消失，后者没有模型也照转。而且两者可以同处一屏。

层不同，两个答案就不互相削减。这一卷按这个顺序写，正是为了不削任何一方。

从哪里开始

这项工作不是看了 MCP 才开始的。

「只靠声明就能跑起应用」的运行时在那之前就一直在做，带着自己的沙箱、状态隔离、资源管理和执行引擎。MCP 公开之后，才在上面加了连接层。

公开记录如下。

现在的 UI 运行时实现 1.4 规范。158 个组件、Material 3 主题、设计令牌往返、多服务器编排。形态因子有六种，其中之一是 embedded — 由宿主固定使用，面向自助终端、工业设备与车载控制台。

不是要把日期摆在前面。 这一卷前面十三篇一次都没提日期，就是这个意思。先说差别，被问到再说日期。

这张表说的只有一件事 — 另一边也在解同一个问题。 他们从网页宿主出发，我们从设备出发。只是彼此不知道而已。

从这里起，由领域来做

结构打开的位置，和填满这个位置的人，是两回事。

每条通道不同等级的画面。 一台服务器按接入方给出不同画面，这一点本卷已在画面上确认。分成几级、哪个位置能打开什么，由懂这台设备的人来定 — 而这个决定不会外流，这正是结构的要点。

现场的通信规范。 工业总线也好，船级规范也好，承接它的位置在设备一侧。设备把自己的功能递出来，画面就照旧跟上 — 规范变了也不必重写画面。

领域的验证体系。 被验证的主体仍然是造装备的那一方，因为画面从不复制功能。这正是本卷两条轴之一。

这三个位置都由造装备的一方来填。结构不代替它们，只把各自接入的位置定下来。

提案

MCP 已经开出扩展的路径，并在走向工作组委托模式。现有的席位是传输、授权、注册表、安全、多模态、合规。

「受限环境与物理设备」的席位还空着。

我们提议开始这个讨论。不是要写一份新规范，而是带着能跑的实现，把嵌入式上什么行、什么不行整理出来。有些事情必须真的装上去才知道 — 这一卷的十三篇就是那份清单的一部分。

想和从另一边解同一个问题的人聊聊。

最后

这一卷一次都没有写「我们更好」。因为没有必要。

归属不同，能做什么、不能做什么就自己分开了。我们把这条分界写了十三次，能确认的都在画面上确认过。

而这个结构立在文档之上。声明保证什么，那里写着；画面就照着写下的样子出来。这一卷的依据全部出自那里。

---

makemind.dev 「探索」— 这一卷的所有实测，都来自随刊发布的样例与探针。