03 分层架构¶
目的¶
本章定义参考框架的分层架构。
设计原则¶
参考 Word 草案对该架构原则的表述可以概括为一句话：统一控制信息，而不是统一物理载波。本仓库将这一点保留为规范性架构原则。
超导、离子阱、中性原子、自旋、光子与模拟器后端可以在统一控制平面下共存，同时保留各自的物理执行差异。
各层职责¶
QOS 层¶
QOS 层负责运行时问题，包括会话管理、任务提交、调度、资源管理、审计与系统级编排。它是 canonical 程序被验证、封装、导出、调度和执行的系统上下文。
UQCI 层¶
UQCI 层负责 canonical 程序对象、验证语义、Bundle 语义与后端无关的执行意图。语义含义在这一层被定义并得到保持。
OpenQASM 层¶
OpenQASM 层负责兼容绑定、导出 profile 与工具链交换。它是交换表示，不是 canonical 语义内核。
Backend 层¶
Backend 层负责合法性检查、资源分配、排程、编译、执行与诊断，并体现具体硬件或模拟器语义。
跨技术路线解释¶
本架构被有意设计为支持不同物理技术路线，而不假设它们在物理层上彼此同构。参考草案中典型的后端家族包括：
- 使用微波驱动、Flux 类控制与谐振腔读出的超导系统
- 使用光学与 RF 控制、以荧光为主要测量手段的离子阱系统
- 使用光镊、Rydberg 相互作用与成像读出的中性原子系统
这些例子说明，共享控制平面并不意味着必须共享单一物理载波词汇。
强制隔离¶
以下边界具有规范性：
- canonical 协议语义必须与 backend-specific 模块隔离
- 兼容导出逻辑必须与 canonical 模型拥有关系隔离
- 运行时与编排语义不得与 OpenQASM 导出逻辑混为一体
- 设备与校准细节必须主要保留在 sidecar 工件和 backend 逻辑中
典型流程¶
参考草案隐含的分层路径可以表示为：
UQCI canonical program -> optional OpenQASM compatibility export -> backend driver lowering -> execution
在仓库实现中，这一路径进一步嵌入到更完整的 QOS 工作流中：
UQCI Program -> validation -> bundle formation -> compatibility export if needed -> backend planning -> execution -> standard results
该流程既保留 canonical 语义，又允许 profile 驱动的交换与 backend-specific 实现。
架构效果¶
这种分层架构带来的结果是：
- 协议层保持 canonical 语义中心
- 后端层保留技术路线灵活性
- 兼容层保持务实可交换
- QOS 层为未来运行时扩展保留空间