2. 量子云平台与任务提交接口概览

要在量子云上跑通一个任务，第一步不是写量子线路，而是搞清楚“从哪进、用什么调、怎么证明身份、任务怎么流转”。主流平台在入口形态、SDK 风格、认证机制和工作流上差异明显，选错入口往往会在环境配置和权限上耗费大量时间。本节按“入口—接口—认证—工作流”四个维度，对 IBM Quantum、Amazon Braket、Azure Quantum 和本源量子云做横向梳理，并给出可直接对照的实践要点。

四个平台的任务提交入口与接口形态

IBM Quantum 以 IBM Quantum Platform 网页控制台为管理入口，任务提交主要依赖 Qiskit 及其运行时（Qiskit Runtime）。开发者用 QiskitRuntimeService 建立会话，把线路和观测值打包成 Primitive（Sampler 或 Estimator）提交，返回的是作业句柄，再轮询或等待结果。它的接口形态是“Python SDK + 托管运行时”，适合以线路为中心、需要频繁迭代的算法开发。

Amazon Braket 的入口是 AWS 控制台与 Braket SDK，认证完全复用 AWS 的 IAM 体系。开发者通过 boto3 配置凭证，用 braket.devices 选择设备，AwsQuantumTask 提交任务，结果写入指定的 S3 桶。它的特点是“云原生”：任务、日志、结果都落在 AWS 资源里，适合已经在 AWS 上构建数据管道的团队。

Azure Quantum 以 Azure 门户为管理入口，接口层是 Azure Quantum SDK 与 Q#、Qiskit、Cirq 多语言支持。认证走 Microsoft Entra ID（原 Azure AD）与服务主体，工作区（Workspace）是资源组织单位，任务提交后通过作业 ID 查询。它更强调“工作区 + 多后端供应商”的统一编排。

本源量子云 提供网页版量子计算云平台与 Python SDK（pyQPanda 生态），认证采用平台账号的 API Key/Token 方式，任务以“量子程序 + 后端芯片/模拟器”的形式提交，结果在平台任务列表中查看。对国内网络环境和中文文档更友好，适合教学与快速上手。

认证方式的差异决定了“代码怎么写”

四个平台的认证差异，直接决定了初始化代码的形态。IBM Quantum 需要在代码里显式传入 API Key 和实例 CRN，通常通过环境变量或 save_account 持久化；Braket 则完全交给 AWS 凭证链，代码里几乎不出现密钥，靠 aws configure 或 IAM Role 完成；Azure Quantum 需要先创建工作区，再用服务主体或 az login 的凭据连接；本源量子云则是在 SDK 初始化时填入平台发放的 API Key。实践中最容易踩的坑是：把密钥硬编码进脚本并提交到代码仓库。正确做法是统一走环境变量或平台提供的凭证管理，例如：

# IBM Quantum：凭证从环境变量读取，避免写入源码
export QISKIT_IBM_TOKEN="你的_API_KEY"
export QISKIT_IBM_INSTANCE="crn:v1:bluemix:public:quantum-computing:..."

# Amazon Braket：使用 AWS 凭证链
aws configure   # 或配置 IAM Role
export AWS_DEFAULT_REGION="us-east-1"

典型工作流的共性与分歧

尽管接口不同，四者的任务生命周期高度一致：初始化凭证 → 选择后端 → 构建量子程序 → 提交任务 → 轮询状态 → 取回结果。分歧主要在“任务对象”和“结果落点”：IBM 返回 job_id 并由 Runtime 直接回传计数或期望值；Braket 返回 Task ARN，结果异步写入 S3，需要再读桶；Azure 返回 Job ID，结果存在工作区关联存储中；本源量子云返回任务编号，结果在平台任务列表里查看。这意味着跨平台迁移时，真正要改的不是线路本身，而是“提交—取结果”这一段胶水代码。

选型时的实践判断

如果团队已在 AWS 上运行数据管道，Braket 的 IAM + S3 组合最省心；如果以 Qiskit 生态为主、需要频繁使用 Primitive 做误差缓解，IBM Quantum 的运行时更顺手；如果组织统一使用 Azure 且需要多供应商后端对比，Azure Quantum 的工作区模型更合适；如果是教学演示、需要中文文档和国内网络直连，本源量子云的上手成本最低。选型不必追求“最强”，而应看“认证体系是否与现有基础设施一致、结果落点是否便于后续分析”。