又接了一台设备 — 宿主没有动过

前两篇处理的是一台设备：它递出自己的画面，画面无需安装就能到达。

现场不会只有一台设备。驾驶室里发电机、压载和油量表在一起。这一篇讲把多台汇到一屏时会发生什么。

通常由宿主写结合

要在一屏里看多台设备，一般是应用用代码持有那份结合：哪台设备的哪个值放在哪里、哪个按钮通向哪台设备 — 应用都知道。

于是每加一台设备就要改一次应用。而且组合在构建时就被固定。现场设备构成一变，应用就得再出一版。

这里结合落到文档里

UI DSL 1.4 的合成规范把这份结合落到文档。宿主只做两件事 — 持有连接，以及打开文档点名的那一方。没有结合逻辑。

文档里写的是：这里放这条连接给出的画面，那里放那条连接给出的画面。

规范定下四条性质。

• 每台设备提供的画面原样不改地放进别人的应用里。设备不知道自己被合成了。
• 被嵌入部分的操作与订阅发往那台设备。
• 失败按贴片隔离。
• 加服务器不改变宿主。

四条都写在规范里。所以我们在画面上量。

量了什么 — 三个节点

立起三个 MCP 节点：Boiler A、Pump B、Valve C。各自提供自己的画面、持有自己的值、暴露自己的工具，彼此不认识。

然后写了一份把三者放到一页上的文档。那份文档没有写会画出什么，只写了哪条连接放在哪里。

① 三块贴片各自按自己的画面画了出来。 各有自己的名字、单位、颜色、数值。应用一样都没写。

② 贴片上的按钮只到自己的服务器。 按第一块的按钮，只有第一台的值动。我们直接问了服务器 — 29→30，另外两台不变。按第二块只动第二台，按第三块只动第三台。

这是合成里最容易悄悄出错的地方。画面画得没问题，而按钮去了别的服务器，这个症状不会显示在画面上。

③ 关掉了一台。 停掉第二个节点。只有那块贴片变成替代显示，第一块还活着。 页面和下面的内容继续渲染。四台里灭一台的画面，是三台还活着的画面，不是白屏。

④ 加了第三台。 文档里加了两处 — 一条连接、一个位置。然后对比了加前加后宿主二进制的哈希。

一样。没有重新构建。

所以标题这么写

这里必须准确。不是没动应用。 文档里多了两处。要加设备，总得有人说它放在哪。

没变的是宿主。可执行文件原封不动。这意味着不用重新过审、不用重新发布、不碰现场已有的机器。

量到的就是这个，标题也就这么写。

这一轮出来的东西

这次测量不是一遍就过的。一开始两块贴片都是替代显示，为了找原因摆了好几条对照线。

过程中这个结构这边出了四个缺陷，全部修好 — 连接失败沉默三十秒才超时、调用不存在的工具却返回成功、失败的连接没有走失败路径、以及一个回调上挂多个动作时被悄悄丢弃。

其中一半是我们自己的文档在契约之外造成的。 画面之所以空，真正的原因在那一边。而「不存在的工具返回成功」这一条，是为找原因顺手摆在旁边的一条对照线抓到的 — 那是没人在找的缺陷。

为量合成而搭的这块盘，同时把下面一层的缺陷也显了出来。