量子-经典混合计算平台架构：从监控溯源到弹性推理引擎

1. 项目概述：当量子计算遇见经典算力

最近几年，我身边不少做高性能计算和AI的朋友，都开始把目光投向一个听起来有点“科幻”的领域——量子计算。但大家聊着聊着，总会回到一个非常现实的问题：我们实验室那台价值不菲的量子处理器，或者云上租来的量子比特，到底该怎么用起来？它和我们现在机房里的那堆GPU服务器、CPU集群，到底是什么关系？是取代，还是合作？这个“量子-经典混合计算平台架构”项目，就是我们在实践中摸索出的一个答案。它不是一个飘在空中的理论框架，而是一个实实在在的、试图把量子计算的潜力与经典计算的成熟生态拧成一股绳的工程实践。

简单来说，这个平台要解决的核心矛盾是：量子设备（如超导量子芯片、离子阱）本身极其脆弱且不稳定，其计算过程（我们称之为“量子线路”或“量子电路”）的执行结果具有概率性，并且需要极低温等苛刻环境。而我们的应用，无论是优化物流路线、模拟新药分子，还是训练更复杂的机器学习模型，都需要确定、可靠且可扩展的计算结果。因此，纯粹的“量子计算”在可预见的未来都难以独立完成任务。混合架构的思路由此而生：让量子处理器专注于它擅长的、具有指数级加速潜力的特定子任务（例如求解某个特定形式的矩阵本征值、或生成某种复杂的概率分布），而将任务分解、预处理、后处理、迭代优化、以及最终结果的整合与推理，这些“粗活累活”交给庞大而稳定的经典计算集群来完成。

这个项目的标题“从监控溯源到弹性推理引擎”，恰好勾勒出了这个混合平台的两个关键支柱与一个核心工作流。“监控溯源”是基石，指的是对量子硬件状态、量子线路执行过程、以及混合任务中每一阶段数据的全链路、可追溯的监控与度量。没有这个，量子计算就变成了一个无法调试的“黑箱”，任何错误都无法定位。“弹性推理引擎”则是大脑和肌肉，它需要根据任务类型、当前量子硬件保真度、经典集群负载等因素，动态地调配资源，决定多少工作交给量子端，多少留给经典端，并最终将可能带有噪声的量子计算结果，通过经典算法（如纠错、后处理、机器学习模型）提炼成可靠的答案。整个平台的目标，是让科研人员和开发者能够像调用一个GPU核心一样，相对“无感”地调用量子算力，专注于算法和业务逻辑，而不必深陷于控制微波脉冲、校准量子比特的物理细节中。

2. 核心架构设计：分层解耦与双向通信

要构建这样一个混合平台，我们不能把量子计算机简单地看作一台外设。它的特殊性要求我们在架构设计上，必须采用严格的分层解耦思想，并在经典与量子域之间建立高效、语义清晰的双向通信通道。

2.1 分层架构：从物理硬件到应用接口

我们的平台自底向上分为五层，每一层都封装了特定的复杂性，并向上一层提供更简洁的抽象。

第一层：量子硬件抽象层这一层直接与五花八门的量子硬件打交道，比如IBM的超导量子计算机、霍尼韦尔的离子阱系统，或是光量子原型机。它的核心工作是提供一个统一的硬件驱动接口。不同厂商的量子计算机，其控制指令（如量子门脉冲序列）、校准接口、数据返回格式天差地别。QHL（Quantum Hardware Abstraction Layer）的任务就是将这些差异隐藏起来，向上层暴露一组标准的操作原语，例如execute_circuit(circuit, shots)、get_qubit_fidelity()、calibrate()等。我们为每种主流量子硬件平台开发了对应的适配器。这一层还会缓存硬件的基本参数，如拓扑结构、相干时间、门保真度等，供上层调度器决策使用。

注意：量子硬件的校准数据（如频率、振幅）是时变的，可能几小时就漂移一次。因此，适配器必须支持定期或按需的自动校准流程，并在校准期间将硬件标记为“不可用”，避免任务提交到不稳定的设备上。

第二层：量子任务执行与监控层这是“监控溯源”能力的核心实现层。当上层提交一个量子线路后，这一层负责将其编译成目标硬件可识别的脉冲序列，并提交执行。但它的核心价值远不止于此：

1. 执行监控：实时收集硬件在执行过程中的原始数据，如每条脉冲的波形、实际发射功率、量子比特的读取信号等。这些数据会与预期的理想值进行比对。
2. 溯源数据生成：为每一次任务执行生成一个唯一的“溯源ID”。所有相关的数据——输入线路、编译后的脉冲、硬件参数快照、原始结果数据、中间处理日志——都通过这个ID关联起来，存入专用的时序数据库（如InfluxDB）或对象存储中。
3. 健康度检查：基于监控数据，实时计算当前量子处理器的“健康度评分”，例如平均门保真度、读出误码率、串扰水平等。这个评分是弹性调度的重要依据。

第三层：经典计算资源池与管理层这一层管理着平台所有的经典算力，包括本地的高性能CPU/GPU集群、以及可能接入的云上虚拟机或容器服务。我们使用Kubernetes作为统一的资源编排器，但对其进行了增强：

• 混合任务感知调度器：Kubernetes默认调度器只关心CPU/内存。我们开发了一个自定义调度器插件，它能理解“混合任务”的资源需求，例如“需要2个量子比特，并附带一个拥有16核CPU和1块V100 GPU的经典Pod用于实时数据分析”。
• 弹性伸缩组：根据混合任务队列的长度和优先级，自动伸缩经典计算节点。例如，当一批需要大量经典后处理的量子化学模拟任务涌入时，自动在云上扩容一批GPU实例。

第四层：混合运行时与弹性推理引擎这是平台的“智能中枢”，也是最具挑战性的部分。它包含几个关键组件：

• 任务分解器：接收用户提交的混合算法（例如QAOA用于组合优化，VQE用于量子化学），自动将其分解为一系列量子子任务和经典子任务，并定义好它们之间的数据依赖关系（DAG）。
• 弹性调度器：这是“弹性”二字的体现。它根据以下因素动态决策：
  • 量子硬件状态：从监控层获取的健康度评分。如果某台量子计算机的保真度下降，调度器会倾向于将高精度要求的任务路由到其他机器，或增加该任务的重复执行次数（shots）。
  • 经典资源负载：当前CPU/GPU的利用率。
  • 任务特性：某些任务对量子噪声敏感，有些则对经典迭代速度要求高。
  • 成本与预算：使用云端量子算力和经典算力都有成本，调度器需要在预算约束下优化整体完成时间或结果精度。
• 推理引擎：负责量子结果的“去噪”与“提炼”。量子设备返回的是概率分布（例如，测量1000次，得到“00”状态650次，“11”状态350次）。推理引擎会利用经典机器学习模型（如神经网络）、或传统的滤波与估计算法，结合任务的历史溯源数据，从嘈杂的概率分布中推断出最可能的、更精确的答案。它可以是规则驱动的，也可以是模型驱动的。

第五层：统一应用接口与SDK最上层面向最终用户（算法研究员、应用开发者）。我们提供Python为主的SDK，其核心是一个“混合任务”抽象。用户通过高级API描述问题，例如定义一个需要优化的分子哈密顿量，或一个组合优化问题的代价函数。SDK会将其转换为底层混合运行时可以理解的描述。同时，我们还提供强大的可视化工具，允许用户追踪其混合任务的执行状态，钻取溯源数据，查看量子硬件实时监控仪表盘，以及分析推理引擎的输出结果。

2.2 双向通信总线的设计考量

量子与经典部分不是单向的“提交-返回”关系，而是需要紧密的、多回合的交互。我们设计了一个基于消息队列（如Apache Pulsar或RabbitMQ）和gRPC流的双向通信总线。

• 经典 -> 量子：这条路径主要传递的是“控制流”和“计算图”。例如，弹性调度器发出的任务指令、需要编译执行的量子线路描述（通常用OpenQASM或Cirq等中间表示法）。
• 量子 -> 经典：这条路径传递的是“数据流”和“状态流”。包括：
  1. 原始结果数据：量子测量得到的比特串。
  2. 实时监控数据流：硬件传感器数据，以高频率流式推送给经典端，用于实时健康评估和潜在的错误缓解。
  3. 硬件事件：如校准完成、错误发生、设备离线等。

总线需要极高的可靠性和低延迟（尤其是监控数据流）。我们为不同类型的消息定义了不同的QoS（服务质量）等级。例如，硬件警报消息需要最高优先级和持久化，而某些中间计算结果可以容忍一定的延迟或丢失。

3. 监控溯源系统的深度实现

“监控溯源”是混合计算平台的“眼睛”和“黑匣子”。没有它，整个系统将运行在盲目和不可调试的状态。我们的设计目标是：对每一次混合计算，都能完整回答“What, When, Where, How, and Why”。

3.1 全链路数据采集点

我们在混合任务生命周期的关键节点部署了数据采集探针：

1. 任务提交时：记录用户身份、任务类型（VQE, QAOA等）、算法参数、期望精度、预算约束等元数据。
2. 量子线路编译时：记录输入的抽象线路、目标硬件类型、编译优化策略、最终生成的脉冲序列（包括每个脉冲的数学描述）。
3. 硬件执行前：记录量子处理器的“快照”状态，包括所有量子比特的标定参数（频率、衰减时间T1/T2、单/双门保真度）、芯片拓扑连接图、环境温度等。
4. 硬件执行中：通过硬件供应商提供的底层API（如IBM的qiskit-ibm-runtime的runtime程序），流式采集原始信号数据。这部分数据量巨大，我们采用采样和聚合策略。例如，并非保存每一次发射的脉冲波形，而是记录其关键特征参数（如振幅、频率、相位的统计值）。
5. 硬件执行后：采集原始的、未处理的测量结果（一个长度为shots的比特串列表）。
6. 经典后处理与推理时：记录推理引擎的输入（原始量子结果）、所采用的算法或模型、参数配置、以及每一步迭代的中间输出。
7. 最终结果输出时：记录最终答案、置信度评分、以及整个任务消耗的量子资源（量子比特-时间积）和经典资源（CPU小时、GPU小时）。

3.2 溯源数据模型与存储

所有采集的数据都被建模为一个以“任务溯源ID”为核心的图结构。我们使用一个混合存储方案：

• 关系型数据库（PostgreSQL）：存储结构化的元数据和关联关系。例如，任务基本信息、硬件快照的索引、数据文件的存储路径等。这里方便做复杂的关联查询。
• 时序数据库（InfluxDB）：存储所有时间序列数据，这是监控的基石。包括硬件传感器数据（温度、磁场强度）、量子比特的实时错误率、任务队列长度、系统负载等。它的高效时间范围查询能力，对于绘制监控图表和设置警报至关重要。
• 对象存储（如S3/MinIO）：存储大型非结构化或半结构化数据，如完整的脉冲序列文件、原始比特串结果、推理模型的检查点等。我们通过数据库中的指针来引用这些对象。

一个典型的溯源查询场景是：用户发现某个VQE任务收敛结果异常。他可以通过平台UI，输入任务ID，首先看到任务的基本信息和最终结果。然后，他可以向下钻取，查看该任务执行时量子硬件的健康度图表（来自InfluxDB），发现当时T2时间有显著下降。接着，他可以进一步查看那次任务编译后的具体脉冲序列（从S3下载），并与正常任务的脉冲进行对比。最后，他还可以检查推理引擎的中间迭代数据，判断是量子数据本身噪声过大，还是经典优化器陷入了局部最优。

3.3 可视化与告警

我们基于Grafana构建了监控仪表盘，集成了多个数据源：

• 全局视图：显示所有量子处理器的实时状态（在线/离线/校准中）、健康度评分、当前任务负载。
• 硬件详情视图：针对单台量子计算机，展示其所有量子比特的参数趋势图（T1, T2, 频率漂移）、门错误热力图、串扰矩阵等。
• 任务追踪视图：以甘特图形式展示混合任务的执行流水线，清晰看到量子执行、经典计算、数据传输各阶段耗时。
• 系统资源视图：展示经典Kubernetes集群的CPU/GPU/内存使用情况。

告警规则通过InfluxDB的连续查询或Grafana的警报功能配置。关键告警包括：

• 量子比特保真度低于阈值（如单门保真度<99.5%）。
• 任务失败率突然升高。
• 经典与量子之间的通信延迟超过阈值。
• 系统资源即将耗尽。

4. 弹性推理引擎的调度策略与算法

弹性推理引擎是平台的“大脑”，其智能程度直接决定了混合计算的效率和效果。它的核心挑战在于：在量子噪声、硬件不稳定、经典资源有限、任务目标多样等多重不确定性下，做出动态的、近似最优的资源配置决策。

4.1 多目标自适应调度策略

我们的调度器不是简单的FIFO（先进先出）队列，而是一个多目标优化器。它需要权衡以下几个常常冲突的目标：

1. 任务完成时间：用户通常希望任务尽快完成。
2. 结果精度/保真度：这是科学计算和某些商业应用的核心要求。
3. 资源利用率与成本：最大化昂贵的量子硬件和经典算力的使用效率，控制云资源开销。
4. 公平性：避免少数大任务长时间独占资源。

我们实现了一个基于加权分数的调度算法。每个提交的混合任务都会被计算一个动态优先级分数：

Priority_Score = w1 * f(Deadline) + w2 * g(Accuracy_Requirement, Current_Hardware_Fidelity) + w3 * h(Resource_Estimation) + w4 * i(User_Priority) - w5 * j(Already_Waiting_Time)

其中：

• f(Deadline)：距离截止时间的函数，越近优先级越高。
• g(Accuracy_Requirement, Current_Hardware_Fidelity)：衡量“任务精度要求”与“当前可用量子硬件质量”的匹配度。如果当前硬件保真度很高，而任务要求不高，分数可能中等；如果任务要求极高，而只有低保真度硬件可用，调度器可能会选择“等待更高保真度硬件”或“建议用户增加shots/使用错误缓解技术”，这会影响其立即执行的分数。
• h(Resource_Estimation)：基于任务分解器预估的经典资源消耗（CPU/GPU/内存）。消耗越大，可能扣分（为了公平），也可能加分（如果系统资源空闲，希望利用起来）。
• i(User_Priority)：基于用户等级或项目预算的静态权重。
• j(Already_Waiting_Time)：已等待时间的函数，用于防止任务饿死，等待越久，加分越多。

权重w1~w5可以由系统管理员根据平台的整体运营策略进行调整。调度器周期性地（例如每10秒）重新计算队列中所有任务的分数，并选择分数最高的任务，结合当前资源状态，为其分配合适的量子硬件和经典计算Pod。

4.2 量子资源弹性分配：Shots与比特数的动态调整

对于单个量子子任务，弹性体现在对“测量次数”和“使用量子比特数”的动态调整上。

• 动态Shots调整：量子计算是通过多次重复测量来估计概率的。测量次数（Shots）越多，统计噪声越低，结果越精确，但耗时和成本也越高。我们的推理引擎会根据初期少量Shots（如1000次）得到的结果的方差（波动大小），来动态决定是否需要增加Shots。如果方差已经很小，说明结果已经稳定，无需再增加；如果方差很大，则自动增加Shots（如到10000次），直到达到预设的精度目标或成本上限。这个过程可以嵌入到像VQE这样的迭代算法中，在每一轮优化中动态调整下一轮量子计算的Shots。

• 动态量子比特映射：一个算法理论上需要N个量子比特，但当前可用的最高保真度硬件只有M个比特（M可能大于、等于或小于N）。如果M < N，调度器需要决定是等待更大规模的硬件，还是尝试在现有硬件上用更深的线路（需要更多门操作）来模拟缺失的比特（这通常会引入更多噪声）。如果M > N，调度器则可以选择硬件上性能最好的N个比特来执行任务，避开那些已知错误率较高的比特。这需要与监控溯源系统紧密集成，实时获取比特级的性能数据。

4.3 经典推理算法的可插拔设计

推理引擎的核心是各种“去噪”和“提炼”算法。我们将其设计为可插拔的模块，以便随时集成最新的研究成果。目前主要支持以下几类：

1. 基于模型的纠错：训练一个经典的机器学习模型（如神经网络），学习从有噪声的量子测量结果到理想结果的映射。这个模型需要在大量“有噪声输入-理想输出”配对数据上训练，这些数据可以来自更精确的经典模拟，或者是在极低噪声情况下运行的量子硬件。
2. 后处理滤波：适用于量子优化问题。例如，在QAOA中，量子处理器返回的是一组比特串（候选解），其中一些可能由于噪声而不满足问题的约束条件。经典后处理步骤可以快速过滤掉这些无效解，并对有效解进行局部优化，提升最终解的质量。
3. 错误缓解技术集成：集成如零噪声外推、概率错误消除等成熟的错误缓解协议。这些协议需要在不同噪声强度下运行量子线路，然后通过经典计算来外推零噪声时的结果。调度器需要协调这些额外线路的执行。

推理引擎的API设计为inference(raw_quantum_data, task_context, algorithm='auto')。当算法参数为'auto'时，引擎会根据任务类型和溯源数据中记录的历史性能，自动选择最合适的推理算法。

5. 平台部署与运维实战经验

构建这样一个平台是一回事，让它稳定、高效地跑起来是另一回事。我们在部署和运维中踩过不少坑，也总结了一些关键经验。

5.1 基础设施选型与部署拓扑

我们采用混合云部署模式，核心考量是平衡性能、成本和对量子硬件的物理访问。

• 核心控制平面与经典计算池（私有云）：我们将Kubernetes Master节点、监控溯源数据库（PostgreSQL, InfluxDB）、消息队列、弹性调度器等核心控制组件部署在本地数据中心。这保证了核心系统的低延迟和网络安全性。本地的GPU/CPU服务器也作为经典计算池的一部分，用于处理延迟敏感或数据保密性要求高的任务。
• 量子硬件接入层：对于位于本地的量子计算机（如一些实验室原型机），我们通过专用高速网络直连到核心控制平面。对于使用云量子服务（如IBM Quantum, Amazon Braket），我们在云服务商的VPC内部署一个轻量级的“边缘代理”。这个代理负责与云量子API通信，接收来自核心控制平面的任务，收集监控数据并回传，同时管理在同一个云区域内创建的经典计算资源（如EC2实例），用于执行需要与云量子服务低延迟交互的经典计算部分。
• 弹性计算资源（公有云）：当本地经典计算资源不足时，弹性调度器通过Kubernetes的Cluster API或云服务商的插件（如AWS EKS Anywhere, GKE Autopilot），在公有云上快速创建和管理一个“临时”的节点池，用于处理计算密集型但非延迟关键的后处理任务。任务完成后，节点池自动缩容。

5.2 关键配置与性能调优

1. Kubernetes配置：

   • 资源请求与限制：为每个运行混合任务经典部分的Pod精确设置CPU、内存请求（requests）和上限（limits）。特别是内存，一些量子化学后处理程序非常耗内存。设置不当会导致节点内存溢出（OOM Kill）。
   • 节点亲和性与反亲和性：利用亲和性规则，确保需要低延迟通信的量子任务和其对应的经典Pod被调度到同一个可用区（甚至同一台物理主机）。同时，使用反亲和性避免单一节点负载过重。
   • Horizontal Pod Autoscaler (HPA)：基于自定义指标（如混合任务队列长度）来伸缩经典计算服务的Pod副本数，而不仅仅是CPU使用率。

2. 网络性能：

   • 经典与量子部分之间，特别是与云端量子服务之间，网络延迟和稳定性至关重要。我们为所有云上组件配置了高质量的网络连接（如AWS的Enhanced Networking, GCP的Premium Tier）。
   • 在消息总线上，对监控数据流启用压缩，并对控制消息启用确认和重传机制。

3. 数据流水线优化：

   • 量子原始数据（比特串）可能很大（例如，100万次测量，100个比特，就是100MB的文本数据）。我们使用Protocol Buffers或Apache Avro进行高效的二进制序列化，而不是JSON。
   • 在推理引擎中，对频繁访问的中间数据（如预训练的纠错模型）进行内存缓存。

5.3 运维监控与故障排查

平台的运维监控超越了传统的IT基础设施监控，需要深度融合量子硬件的特殊性。

日常运维仪表盘：除了之前提到的Grafana看板，我们还定制了几个关键视图：

• “量子资源效率”看板：展示每日/每周量子处理器的“有效运行时间”占比（扣除校准、维护、错误停机时间），以及量子比特-小时的使用量。这是衡量平台利用率和计算价值产出的核心指标。
• “任务成功率与错误分类”看板：统计混合任务的成功/失败率，并对失败原因进行分类（如“量子硬件错误”、“经典超时”、“用户参数错误”）。这有助于持续改进平台的稳定性和用户体验。
• “成本分析”看板：整合云量子服务账单和云经典资源账单，按项目、用户或任务类型进行成本分摊，实现精细化的成本管控。

故障排查手册（部分摘录）：

定期维护流程：

• 量子硬件校准验证：虽然适配器支持自动校准，但我们仍每周进行一次手动验证校准。运行一组标准的基准测试线路（如随机基准测试），将结果与历史基线对比，确保自动校准的可靠性。
• 溯源数据清理：原始监控数据和结果数据体积增长极快。我们制定了数据保留策略：原始监控数据保留30天，之后聚合为小时级均值；任务结果数据根据重要性保留1-5年；所有数据在删除前会归档到冷存储。
• 灾难恢复演练：定期演练核心数据库（PostgreSQL, InfluxDB）的备份恢复流程。由于量子硬件不可替代，我们的恢复点目标主要针对控制平面和经典数据。

6. 应用场景与未来演进思考

这个混合平台并非为某个特定应用而建，它提供的是一个通用的“量子算力接入与增强”能力。目前，它已经在几个典型场景中支撑了我们的内部研究和外部合作项目。

场景一：量子化学模拟（VQE算法）这是目前最成熟的应用之一。用户通过SDK提交一个分子结构（如咖啡因），平台会自动将其转换为对应的量子化学哈密顿量。弹性调度器会将其分解为数百个需要量子处理器求解的“期望值”子任务。每个子任务都是一个相对简单的量子线路。监控系统确保每次求解都在硬件状态良好时进行。推理引擎则负责将数百个带有噪声的期望值结果汇总，并通过经典的优化器（如梯度下降）迭代调整参数，最终得到分子的基态能量。平台的价值在于，化学家完全不需要关心量子线路的编译、硬件的选择、错误的处理，他们只需要关注分子本身和最终的能量值。

场景二：组合优化（QAOA算法）例如，解决一个物流中心的货物分拣路径优化问题。平台将优化问题映射为量子比特间的相互作用（伊辛模型）。量子处理器负责生成一系列可能解（路径）的概率分布。由于噪声，这些解可能不全是有效的（例如，路径不连续）。经典推理引擎会快速过滤无效解，并对有效解进行经典的局部搜索优化，输出Top-K个最优解供决策者选择。弹性调度器在这个过程中，可以根据问题的规模和实时硬件情况，动态调整QAOA算法的层数和测量次数，在求解时间和解的质量之间取得平衡。

场景三：量子机器学习用于训练一个经典的神经网络可能过于奢侈，但量子处理器在生成特定复杂分布的数据方面有潜力。我们探索的一个方向是，用小型量子电路作为生成对抗网络中的“生成器”，来产生用于增强训练数据的样本。混合平台负责协调量子生成器与经典判别器的训练循环，管理梯度信息的交换，并处理量子生成样本中的噪声。

未来演进的方向，我们团队内部也在持续讨论：

1. 更智能的编译器：当前的编译链路还是相对静态的。未来的编译器需要与监控和调度器联动，实现“自适应编译”。例如，当知道接下来要运行的硬件上，某个量子比特的T1时间较短时，编译器可以主动优化线路，避免将需要长时间保持的量子态放在那个比特上。
2. 跨平台任务分割：一个大型混合任务，是否可以将它的量子子部分同时提交给多个不同厂商的量子云服务执行，以规避单一硬件故障或获取更优的综合性能？这需要平台具备更复杂的元调度和结果融合能力。
3. 联邦学习式混合架构：考虑数据隐私场景，未来的混合计算可能不止是“一个量子设备+一个经典集群”，而是“多个边缘量子传感设备+多个边缘经典计算节点+一个中心协调平台”的联邦模式。平台架构需要向更分布式、更安全的方向演进。
4. 标准化接口的推动：我们正在尝试将平台中与硬件无关的部分，如任务描述格式、混合运行时接口、监控数据模型等，逐步抽象并贡献给开源社区。希望未来能形成一个事实标准，让不同团队开发的量子算法和应用，都能无缝运行在不同的混合计算平台之上，真正加速整个生态的发展。

构建和运营这样一个平台的过程，就像在一条尚未完全绘制好的地图上探索前行。最大的体会是，可靠性比先进性更重要。一个能稳定产出可重复、可追溯结果的“混合计算系统”，哪怕其量子加速优势在初期并不明显，其对科研和产业界的价值，也远大于一个性能卓越但时好时坏的“原型演示系统”。我们的工作，就是尽力将量子计算的不确定性，封装在一个尽可能确定和可靠的经典工程框架之内，让探索者们能够安心地使用这把新的钥匙，去尝试打开那些经典计算难以撼动的大门。