前两篇处理的是一台设备：它递出自己的画面，画面无需安装就能到达。
现场不会只有一台设备。驾驶室里发电机、压载和油量表在一起。这一篇讲把多台汇到一屏时会发生什么。
通常由宿主写结合
要在一屏里看多台设备，一般是应用用代码持有那份结合：哪台设备的哪个值放在哪里、哪个按钮通向哪台设备 — 应用都知道。
于是每加一台设备就要改一次应用。而且组合在构建时就被固定。现场设备构成一变，应用就得再出一版。
这里结合落到文档里
UI DSL 1.4 的合成规范把这份结合落到文档。宿主只做两件事 — 持有连接，以及打开文档点名的那一方。没有结合逻辑。
文档里写的是：这里放这条连接给出的画面，那里放那条连接给出的画面。
规范定下四条性质。
- 每台设备提供的画面原样不改地放进别人的应用里。设备不知道自己被合成了。
- 被嵌入部分的操作与订阅发往那台设备。
- 失败按贴片隔离。
- 加服务器不改变宿主。
四条都写在规范里。所以我们在画面上量。
量了什么 — 三个节点
立起三个 MCP 节点：Boiler A、Pump B、Valve C。各自提供自己的画面、持有自己的值、暴露自己的工具，彼此不认识。
然后写了一份把三者放到一页上的文档。那份文档没有写会画出什么，只写了哪条连接放在哪里。
① 三块贴片各自按自己的画面画了出来。 各有自己的名字、单位、颜色、数值。应用一样都没写。
② 贴片上的按钮只到自己的服务器。 按第一块的按钮，只有第一台的值动。我们直接问了服务器 — 29→30，另外两台不变。按第二块只动第二台，按第三块只动第三台。
这是合成里最容易悄悄出错的地方。画面画得没问题，而按钮去了别的服务器，这个症状不会显示在画面上。
③ 关掉了一台。 停掉第二个节点。只有那块贴片变成替代显示，第一块还活着。 页面和下面的内容继续渲染。四台里灭一台的画面，是三台还活着的画面，不是白屏。
④ 加了第三台。 文档里加了两处 — 一条连接、一个位置。然后对比了加前加后宿主二进制的哈希。
一样。没有重新构建。