huawei-cloud-cloudrobo-infer

Windows / PowerShell： 示例使用 bash 语法。要在 Windows PowerShell 中运行：

• 将 \ 续行符合并为单行，或在行尾添加反引号。
• 使用 $env:NAME="value" 设置环境变量，而不是 export NAME="value"。
• 单引号括起来的 JSON '{"a":"b"}' 可直接使用。

概述

cloudrobo-infer 技能用于管理 CloudRobo 推理服务的完整生命周期 （也称为模型服务／推理服务）。它可以让 Agent 将模型（通过 --model-json JSON 对象传入 model_id + model_version_id）部署为长期运行的推理服务，监控并操作该服务（启动／停止／更新／删除／查看日志）， 还可以使用 wait-deploy 轮询，直到服务状态不再是 DEPLOYING （status != "DEPLOYING"），此时会返回其他任意状态（例如 RUNNING、FAILED、STOPPED）。

注意：wait-deploy 只等待 DEPLOYING 阶段，不会等待 CREATING 阶段结束。 有关确切语义，请参阅Wait-Deploy参考文档。

适用场景：

• 模型部署 — 将模型部署为推理服务（create → wait-deploy）
• Wait-Deploy — 每隔 5s 轮询一次，直到服务状态不再是 DEPLOYING（间隔为 5s，默认超时为 600s）
• 服务运维 — 列出已部署的服务、查看详情、更新配置、启动／停止服务
• 日志诊断 — 使用毫秒级时间范围和关键词筛选 list-logs
• 跨技能编排 — 使用 cloudrobo-train 导出的模型；通过 infer_service_id 将服务提供给 robo-dispatcher，用于具身任务。

架构：

Agent / LLM
    │
    ├── CLI  →  cloudrobo infer <command>
    └── SDK  →  InferClient (Python)
                    │
                    ▼
              cloudrobo-service (REST API)
              /v1/infer-services/*

所有操作都针对 cloudrobo-service 后端，并且需要有效的 workspace_id（除非明确提供，否则使用默认工作空间）。部署服务会占用计算资源池资源 — 启动长期运行的服务前务必确认。

前提条件

• 有关 CLI 安装、AK/SK 身份验证和工作空间配置，请参阅 references/cli-installation-guide.md。
• 有效的 workspace_id（通过 cloudrobo workspace current 或 list + use 获取）。
• 可部署的模型：model_id（=asset_id）+ model_version_id（=latest_version_id）， 作为一个 --model-json 参数传给 create： --model-json '{"model_id": "<asset_id>", "model_version_id": "<latest_version_id>"}'。 模型的 show-asset 输出中必须包含 ONLINE_DEPLOYMENT 操作，且其 status: "ENABLE"。 状态为 DRAFT／CREATING 的模型无法部署（会返回 403 错误）。
• 计算资源池：pool_id（在 resource_id 前加上 pool- 前缀，即 pool-<resource_id>）
  • pool_type + flavor，通过 cloudrobo resource list-pools --resource-type MODELARTS 获取。只有 状态为 AVAILABLE 的资源池可用。
• 实际上，create 需要 --stop-schedule-json（虽然 CLI 并未将其设为必填）。 格式：{"duration": <N>, "time_unit": "MINUTES"}。

工作流

自然语言优先原则

以下每个工作流都从用户意图开始（1–2 句话），而不是手动编排 CLI/SDK。 然后，技能会执行相应的命令链，并报告状态反馈 （状态变化、轮询进度）。

模型部署工作流（交互式参数解析）

场景：“我想创建一个推理服务”／“将模型 X 部署为推理服务。”

核心原则：查询每个必需参数 → 提供选项 → 让用户选择 → 组装完整命令 → 执行。

1. 解析工作空间 — cloudrobo workspace current。

   • 如果已设置默认工作空间 → 直接使用 workspace_id 和 asset_catalog_id。
   • 如果未设置 → 执行 cloudrobo workspace list → 向用户展示工作空间名称和 ID → 执行 cloudrobo workspace use --workspace-id <id> → 重新运行 current 以确认。

2. 询问模型来源和类型——按以下顺序询问用户两个问题：

   • 来源（搜索位置，先询问）：具身广场、空间资产或自定义。来源决定下方的全部参数策略——具身广场模型已在平台上预配置，只能携带必需的核心参数；空间资产／自定义模型则执行自动发现流程。
   • 类型（依据 ext_metadata.model_type，后询问）：感知、导航、操作、规划。
   • 如果用户描述含糊（例如“so101 相关的模型”）→ 跳过这两个问题，使用 search-assets 进行全局关键词搜索。
   • 确定来源后，立即根据 模型来源 → 参数策略 表中的对应策略，再组装 create。

3. 查询模型——根据用户的选择进行搜索：

   • 具身广场：cloudrobo asset list-publication-assets --type model --actions ONLINE_DEPLOYMENT --action-status ENABLE（返回已启用在线部署的 RELEASE 模型）。
   • 空间资产：cloudrobo asset list-assets --catalog-id <asset_catalog_id> --type model（注意：使用工作区中的 --catalog-id，而不是 --repository-id）。
   • 关键词搜索：cloudrobo asset search-assets --keyword "<keyword>" --type model。
   • 向用户展示匹配的模型（名称、asset_id、状态、model_type），供其选择。

4. 解析模型版本——cloudrobo asset show-asset --asset-id <asset_id>。

   • 使用 latest_version_id 填入 --model-json 中的 model_version_id 字段。
   • 如果 version_count > 1 → cloudrobo asset list-versions --asset-id <id> → 让用户选择。
   • 验证是否可部署：检查 actions 数组——ONLINE_DEPLOYMENT 的 status 必须为 "ENABLE"。如果为 DISABLE，则无法部署该模型（会返回 403 错误）。
   • 验证模型状态：status 应为 RELEASE（具身广场）或已发布状态。DRAFT／CREATING 模型会被拒绝，并返回 403 "Model asset permission deny"。

5. 自动发现部署参数——仅适用于空间资产／自定义模型。 **具身广场模型：跳过整个步骤，且不要携带下列任何参数（此处列出的参数，以及 --cmd／--image-swr-url／--envs-json／--skill-config-json／--service-invoke-json／--readiness-health-json／--model-ext-metadata／--model-json.mount_path 中的任何参数）。**具身广场模型已在平台上预配置——其编排、镜像、环境变量、技能、健康探针和 r2c 映射都已绑定到模型。为具身广场模型传递这些额外参数可能导致部署无效或配置不匹配，这正是此工作流禁止的“不该带的参数”。

   空间资产／自定义模型：解析模型版本后，检查模型是否关联了可提供部署参数的算法资产。这些参数会从模型的算法资产和配置文件中自动发现：

   a. 检查 ONLINE_DEPLOYMENT 操作——在第 4 步的 show-asset 输出中，查看 actions[] 里是否有 type: "ONLINE_DEPLOYMENT"。如果存在且 status: "ENABLE"，其中会包含指向关联算法资产的 algorithm.asset_id + algorithm.version_id。 b. 查询算法资产（如果找到对应操作）—— 执行 cloudrobo asset show-asset --asset-id <algorithm.asset_id>，然后执行 cloudrobo asset show-version --asset-id <algorithm.asset_id> --version-id <algorithm.version_id>，获取算法的 ext_metadata：

   • ext_metadata.command → --cmd
   • ext_metadata.engine.image_url → --image-swr-url
   • ext_metadata.environment_variables（数组，格式为 {"name":"K","default":"V"}） → 转换为映射 {"K":"V"} → --envs-json
   • ext_metadata.deployment_config.model_mount_path → --model-json.mount_path
   • ext_metadata.deployment_config.service_invoke → --service-invoke-json
   • ext_metadata.deployment_config.readiness_health → --readiness-health-json

   c. 下载 skill_config.json —— 通过 download-url API（CLI/SDK 未封装，需直接使用 HttpClient）：

   from cloudrobo_core.sdk import Config, HttpClient
   from cloudrobo_asset.client import AssetClient
   import requests
   
   config = Config()
   http = HttpClient(config)
   asset_client = AssetClient(http)
   
   resp = http.get(
       asset_client._url(f'/v1/assets/{asset_id}/versions/{version_id}/download-url'),
       params={'file_name': 'skill_config.json'}
   )
   skill_config = requests.get(resp['file_url']).text
   

   • 技能项仅保留 name + prompt 字段（移除 priority/ description 等额外字段）→ --skill-config-json
   • strict 字段：控制已部署的服务是否仅接受预定义技能提示词，还是也允许用户自定义提示词：
     • strict: true — 服务仅接受预定义技能（按 name 匹配）；用户无法在运行时输入自定义提示词
     • strict: false 或未设置 — 除预定义技能外，服务还允许用户在运行时输入自己的自定义提示词
     • 如果客户希望接受自定义提示词，请确保 skill_config.json 中的 strict 为 false 或未设置

   d. 下载 r2c 配置 —— 使用相同的 download-url API，并按以下规则回退：

   • 首先尝试 file_name=r2c_config.yaml
   • 如果失败（404），尝试 file_name=r2c.json
   • 如果两者都失败（未找到 r2c 配置文件）：
     • 询问用户是否要提供自己的 r2c 配置文件
     • 说明缺少 --model-ext-metadata 不会阻止部署，但会导致后续 robo-dispatcher 操作无法正常运行（有关 robo-dispatcher 工作流的详情，请参阅 huawei-cloud-cloudrobo-dispatch 技能）
     • 如果用户提供配置文件，请将其内容用作 --model-ext-metadata
     • 如果用户拒绝，则不使用 --model-ext-metadata 继续操作（并警告用户 robo-dispatcher 操作将不可用）
   • 文件内容（原始字符串）→ --model-ext-metadata

   优先级：配置文件 > ext_metadata 字段 > 询问用户。如果无法找到某个参数，静默跳过（不要因此阻止部署）。对于没有关联算法的“裸”模型，请询问用户是否要手动提供可选参数。

6. 确定资源池和规格 —— 执行 cloudrobo resource list-pools --resource-type MODELARTS。

   • 向用户展示可用资源池（resource_name、pool_type、status、flavors）。
   • 仅 status: "AVAILABLE" 的资源池可用。
   • 资源池字段：resource_id → --pool-id（添加前缀 pool-，例如 pool-d1cc6d45-...），pool_type → --pool-type（可选值：DEDICATED / SHARED）。
   • 规格位于 config.flavor 下，并按硬件类型（CPU/GPU/ASCEND）分组。
   • 让用户选择资源池和规格字符串（例如 "1 * SNT9B2 | 24 vCPUs | 192 GiB"）。

7. 确认参数并部署——向用户展示 create 命令，选择与步骤 2 中模型来源匹配的变体（参见 模型来源 → 参数策略表格）。两种变体不得混用。

   变体 A——具身广场模型（具身广场，仅限必需的核心参数）：

   cloudrobo infer create --name <service-name> --flavor "<flavor>" --model-json '{"model_id": "<asset_id>", "model_version_id": "<latest_version_id>"}' --workspace-id <workspace_id> --pool-id pool-<resource_id> --pool-type <pool_type> --stop-schedule-json '{"duration": 60, "time_unit": "MINUTES"}' [--dry-run]
   

   • 不要添加 --cmd/--image-swr-url/--envs-json/--skill-config-json/ --service-invoke-json/--readiness-health-json/--model-ext-metadata/--model-json.mount_path。 广场模型已在平台上预先配置；携带这些额外参数会带来部署风险，并且此工作流明确禁止这样做。

   变体 B——空间资产/自定义模型（包含自动发现的参数）：

   cloudrobo infer create --name <service-name> --flavor "<flavor>" --model-json '{"model_id": "<asset_id>", "model_version_id": "<latest_version_id>", "mount_path": "<mount_path>"}' --workspace-id <workspace_id> --pool-id pool-<resource_id> --pool-type <pool_type> --stop-schedule-json '{"duration": 60, "time_unit": "MINUTES"}' [--cmd "<command>"] [--image-swr-url "<image_url>"] [--envs-json '{"KEY":"VALUE"}'] [--skill-config-json '{"skills":[{"name":"...","prompt":"..."}],"strict":true}'] [--service-invoke-json '{"auth_type":"...","port":8080,"protocol":"HTTP"}'] [--readiness-health-json '{"path":"/ready","port":8080}'] [--model-ext-metadata '<r2c_config_file_content>'] [--dry-run]
   

   • 仅包含实际发现的参数（步骤 5）；省略未发现的参数。
   • 仅当算法的 deployment_config 提供 --model-json.mount_path 时才包含该参数。
   • --envs-json 必须从资产数组格式转换为映射格式。
   • --skill-config-json 中的技能项仅保留 name+prompt；删除 priority/description。
   • --model-ext-metadata 接受原始文件内容（字符串）。
   • 建议先使用 --dry-run 验证参数组装是否正确。
   • 实际上必须提供 --stop-schedule-json（尽管 CLI 未强制要求）；否则后端可能拒绝创建。格式：{"duration": <N>, "time_unit": "MINUTES"}。
   • dry-run 成功后，先向用户确认，再不带 --dry-run 执行。
   • 记录返回的 service_id。

8. 等待部署——使用 cloudrobo infer wait-deploy --service-id <sid> 每隔 5s 轮询，直到状态不再是 DEPLOYING（status != "DEPLOYING"），并返回后续的任意状态 （例如 RUNNING、FAILED）。

   • create 之后，服务会自动进入 CREATING → DEPLOYING。不要在 create 后立即调用 start ——这会返回 400 错误：“Status DEPLOYING does not support start”。
   • start 仅用于重启 STOPPED 服务，不用于初次部署。
   • 精确语义：wait-deploy 在 status != "DEPLOYING" 时立即返回。它不会等待 CREATING 阶段结束——如果服务仍处于 CREATING 状态时调用，它会立即返回 CREATING 状态。实际使用时，请在 create 后调用该命令，让后端完成 CREATING → DEPLOYING → RUNNING 状态转换；该辅助命令会在 DEPLOYING 阶段阻塞。

9. 报告——输出 service_id、模型名称、规格和最终状态。

   • 如果状态为 FAILED → 运行 cloudrobo infer list-logs 进行诊断。
   • 切勿自动删除失败的服务。 如果需要清理，请展示 delete 命令，并在执行前明确征求用户确认。

资产说明：必须通过上述查询命令动态解析 model_id/version_id/flavor/pool_id；切勿将其硬编码。始终让用户从查询结果中选择。

模型来源 → 参数策略（权威决策表）

此表是根据第 2 步解析出的模型来源决定要携带哪些 create 参数的唯一事实来源。cloudrobo-model-workflow 的第 3 阶段会引用此表，以确保两个技能保持一致。创建任何推理服务时，先解析模型来源，然后严格应用对应的列 — 不要混用不同方案。

模型来源（来自第 2 步）	搜索命令（第 3 步）	自动发现（第 5 步）	要携带的 create 参数
具身广场	asset list-publication-assets --type model --actions ONLINE_DEPLOYMENT --action-status ENABLE	完全跳过 — 模型已在平台上预配置	仅必需核心参数：--name、--flavor、--model-json（model_id+model_version_id）、--workspace-id、--pool-id、--pool-type、--stop-schedule-json。不要携带 --cmd/--image-swr-url/--envs-json/--skill-config-json/--service-invoke-json/--readiness-health-json/--model-ext-metadata/--model-json.mount_path
空间资产/自定义	asset list-assets --catalog-id <asset_catalog_id> --type model / search-assets --keyword ...	完整执行第 5 步 — 查询算法资产（cmd/image/envs/mount_path/service-invoke/readiness-health）+ 下载 skill_config.json + r2c 配置	必需核心参数以及第 5 步实际发现的所有参数；未发现的参数直接省略
未知模型 id（用户传入了明确的 id）	asset show-asset --asset-id <id>	根据 show-asset 判断：如果模型携带指向平台算法的 ONLINE_DEPLOYMENT 操作 → 按空间资产路径处理（执行第 5 步）。如果模型的部署配置是自包含/预配置的 → 仅携带必需核心参数	根据解析出的路径执行

原因：具身广场模型已在平台上集成编排、镜像、环境变量、健康探针、技能和 r2c 特征映射。为具身广场模型在 create 中重新提供这些内容是多余的，并可能导致部署无效/不匹配（这就是“不该带的参数不要带”规则）。空间资产/自定义模型没有此类集成配置，因此必须自动发现其参数并显式传入。

等待部署工作流（CLI 便捷功能）

场景：“等待此推理服务完成部署。”

1. cloudrobo infer wait-deploy --service-id <sid> [--timeout 600]
   • wait-deploy 是 CLI 客户端侧轮询助手：每隔 5 秒轮询一次 show，直到服务状态不再是 DEPLOYING（status != "DEPLOYING"），然后返回任何其他状态（例如 RUNNING、FAILED、STOPPED）。
   • 默认超时为 600s（CLI --timeout 范围为 1–3600）；如果超时，客户端会引发 RuntimeError，CLI 会报告超时错误（JSON 错误 + ClickException，非零退出码）。
2. 反馈 — 报告最终状态；如果状态为 FAILED，建议使用 list-logs 进行诊断。

注意：wait-deploy 不会创建服务。先调用 create，然后再调用 wait-deploy。 不要在 create 后调用 start — 服务会自动部署（CREATING → DEPLOYING → RUNNING）。 start 仅用于重启处于 STOPPED 状态的服务。

服务运维/查询工作流（模块 + 工作空间）

场景：“我的工作空间中有哪些推理服务正在运行？”

1. cloudrobo infer list --workspace-id <ws> [--status <status>] [--model-id <mid>] [--name <name>] [--model-name <mn>] [--model-version-id <mvid>] [--model-version-name <mvn>] [--user-name <un>] [--user-id <uid>]，并使用分页参数（--limit/--offset） 和排序参数（--sort-key/--sort-dir）。
2. 使用 cloudrobo infer show --service-id <sid> 获取完整配置快照。
3. 报告状态和关键字段（模型、规格、状态、资源池）。

服务启动/停止工作流（模块）

场景：“停止此 API 后面的推理服务。”/“重新启动它。”

1. 使用 show --service-id <sid> 确认服务。
2. cloudrobo infer stop --service-id <sid> 或 cloudrobo infer start --service-id <sid> （会修改数据；执行前需确认）。
3. 轮询 show，直到达到所需的终态（STOPPED / RUNNING）。

日志诊断工作流（模块）

场景：“我部署的服务为什么失败了？给我看看日志。”

1. cloudrobo infer list-logs --service-id <sid> --start-time <ms> --end-time <ms> — 两个 时间戳的单位均为毫秒（13 位）。可选筛选参数：--keywords、--limit、 --line-num、--is-count、--highlight、--is-desc。
2. 查看日志行，并与 show 状态进行关联（例如 CREATE_FAILED / START_FAILED）。
3. 建议修复措施（资源池容量、模型制品、健康检查配置）。

服务更新/删除工作流（模块）

场景：“重新配置此服务”/“关闭并移除此服务。”

• 更新 — cloudrobo infer update --service-id <sid> [--description <desc>] [--model-ext-metadata <json>] [--dry-run]（会修改数据；需确认）。
• 删除 — cloudrobo infer delete --service-id <sid> [--dry-run]（会修改数据；不可撤销；需确认）。

组合工作流 A — 部署训练好的模型（infer + train + asset）

场景：“我训练了一个 VLA 模型；将它部署为推理服务。”

1. 确定工作区：cloudrobo workspace current（或使用 list + use）。
2. 查询训练好的模型：cloudrobo asset list-assets --catalog-id <asset_catalog_id> --type model（或使用训练技能的 output_models）；获取 asset_id。
3. 确定模型版本：cloudrobo asset show-asset --asset-id <asset_id> → 在 --model-json 的 model_version_id 字段中使用 latest_version_id。验证 ONLINE_DEPLOYMENT 操作的 status: "ENABLE"。
4. 确定资源池和规格：cloudrobo resource list-pools --resource-type MODELARTS → 让用户选择 resource_id 和 flavor。 4a. 训练好的模型是一个空间资源 → 遵循模型部署工作流中的变体 B / 空间资源路径。（如果训练好的模型关联了算法）按照步骤 5 自动发现部署参数 — 查询算法资源以获取 cmd/image/envs/service-invoke/readiness-health，下载 skill_config.json 和 r2c config。 对于空间资源，携带这些参数才是正确做法；“不要携带”的规则仅适用于具身广场模型。
5. cloudrobo infer create --name <name> --flavor "<flavor>" --model-json '{"model_id": "<asset_id>", "model_version_id": "<latest_version_id>"}' --workspace-id <ws> --pool-id pool-<resource_id> --pool-type <type> --stop-schedule-json '{"duration": 60, "time_unit": "MINUTES"}' — 添加在步骤 4a 中实际发现的任何参数（按照步骤 7 的变体 B）。
6. cloudrobo infer wait-deploy --service-id <sid> — 每 5 秒轮询一次，直到状态不再是 DEPLOYING（创建后服务会自动部署；不要调用 start — 该操作会因 400 而失败）
7. 报告 service_id 和状态。此时服务已可供使用。

参数自动发现：对于空间资源/自定义模型，部署参数 （cmd、image、envs、skill-config、health-checks、model-ext-metadata 等） 会按照上述步骤 5 从模型关联的算法资源和配置文件中自动发现。完整的发现 表、download-url API 代码和关键规则，请参见 references/service-config-catalog.md →“参数自动发现 来源”。

CLI 命令摘要

cloudrobo infer <command> [OPTIONS]

子命令	描述	关键选项
create	部署新的推理服务	--name、--flavor、--model-json、--workspace-id、--pool-id、--pool-type、--stop-schedule-json
wait-deploy	轮询直至部署完成	--service-id、--timeout
list	列出推理服务	--workspace-id、--status、--limit、--offset
show	显示服务详情	--service-id
start / stop	启动或停止服务	--service-id
update	更新服务配置	--service-id、--description、--model-ext-metadata
delete	删除服务	--service-id
list-logs	查询服务日志	--service-id、--start-time（毫秒）、--end-time（毫秒）、--keywords

完整的 CLI/SDK 示例、参数解析表和边界情况：请参阅 references/service-config-catalog.md →「命令示例」、「参数解析与确认」和「边界情况」。 SDK 提供 9 个方法，CLI 提供 9 个命令（无差异）； wait-deploy 是 CLI 和 SDK 均提供的客户端轮询辅助工具。 如果 CLI 使用不便（例如处理动态 JSON、跨包查询），请直接使用 Python SDK——InferClient 提供这 9 个方法。

参考文档

• CLI 安装指南 — cloudrobo CLI 的安装和配置
• IAM 策略 — 最小权限凭证和访问模型
• 验证方法 — 验证方法详情
• 数据流图 — Mermaid 数据流图
• 验收标准 — 验收标准
• 服务配置参考 — InferServiceDto 字段、健康检查、状态、日志、参数自动发现、CLI/SDK 命令示例、参数解析与确认、边界情况、覆盖矩阵

边界情况

完整的场景处理表（包括缺少 model_id、无效 JSON、时间戳单位错误、403 权限拒绝、500 内部错误、缺少 stop-schedule、r2c 配置回退、envs 格式不匹配、跨技能调用等），请参阅 references/service-config-catalog.md →「边界情况」。

验证方法

规范符合性验证

bash scripts/test-cli-commands.sh

功能测试

bash scripts/test-cli-commands.sh

测试用例

完整的测试用例列表请参阅 templates/test-vars.json，其中涵盖部署、wait-deploy、服务生命周期、日志和安全场景。

验证清单

• create 后，服务会以正确的状态显示在 list 中
• wait-deploy 后，服务状态不再是 DEPLOYING（status != "DEPLOYING"；超时或失败时会提供日志排查指引）
• start/stop 后，show 会显示新状态
• delete 后，show 返回未找到
• 使用 毫秒 时间戳调用 list-logs 会返回日志行；关键词筛选有效
• 无效 JSON / 路径遍历会被拒绝；validate_safe_id 会阻止 ../
• 修改操作（尤其是 start）会提示用户确认

最佳实践

• 通过查询命令解析每个 create 参数，然后让用户选择——切勿硬编码
• 参数策略由模型来源决定：先解析来源（步骤 2），再应用模型来源 → 参数策略表。具身广场模型仅携带必需的核心参数（绝不使用 --cmd/--image-swr-url/--envs-json/--skill-config-json/--service-invoke-json/--readiness-health-json/--model-ext-metadata/--model-json.mount_path）；空间资产／自定义模型则执行步骤 5 的自动发现，并携带实际发现的参数
• 搜索模型：对于可部署的广场模型，优先使用 list-publication-assets --actions ONLINE_DEPLOYMENT --action-status ENABLE；对于工作区模型，使用 list-assets --catalog-id <id>；对于模糊／关键词搜索，使用 search-assets --keyword "<kw>"
• --model-json 的 model_version_id 必须使用 show-asset 返回的 latest_version_id，而不是 actions[].algorithm.version_id
• 在 create 中始终包含 --stop-schedule-json '{"duration": N, "time_unit": "MINUTES"}'
• create 后使用 wait-deploy 轮询，直到部署完成（间隔 5s，默认超时 600s）。create 后不要调用 start——服务会自动部署
• wait-deploy 会在 status != "DEPLOYING" 时返回；它只会在 DEPLOYING 阶段阻塞（不会在 CREATING 阶段阻塞），因此应在 create 后调用，让后端完成 CREATING → DEPLOYING → RUNNING 状态转换——如果它在仍处于 CREATING 时返回，请立即再次调用 wait-deploy
• 在 create 中使用 --dry-run，在实际提交前验证参数组装是否正确
• 将健康检查的拾取情况作为部署验证的一部分报告
• 使用 list-logs 搭配 --keywords 快速筛选错误；注意时间戳单位为 ms
• 除非用户明确需要出站访问，否则保持 internet_access_enable 关闭
• 对敏感环境变量／值进行脱敏；绝不回显凭据
• 结合工作区（cloudrobo workspace current）和资产技能解析工作区／模型上下文；结合调度功能执行具身任务