企业内部的第一轮混乱

2026 云栖大会（9 月 22–24 日杭州，主题"智以致用"）发完新品的那几个小时，企业内部一般会经历同一套动作：有人把新闻链接转进项目群，产品同学问"这个我们能不能上"，工程同学回"ID 还不确定"，然后这件事就没有下文了。等两周后有人真去写代码，撞上"模型不存在"，排查半天才发现当初那句"不确定"从来没有被收敛成一个结论。

缺的不是信息，是验收动线。新闻稿给的是品牌名，生产配置要的是目录里的工程 ID，中间必须有一步可复跑的核验把这层落差填掉，并且把结果留档。

这篇记录我在 2026-09-23 用阿里云百炼 CLI（bl 2.0.1）做完的一轮核验，以及把它变成团队常规动作的三件事：目录核验进 CI、模型 ID 白名单、单模型调用与多服务编排的分工。

一轮完整验收：清单、核验、真调、台账

先把大会发布归集成清单（来源：云栖官网与公开报道，9 月 22–23 抓取），只有能在模型目录里查到的条目才进后续步骤：

• 模型：Qwen3.8-Max（厂商口径总参数量 2.4 万亿，主打编程与协同办公）、Qwen3.8-27B（桌面端开源）、Qwen3.8-Omni-Flash（全模态）、Qwen-Image-3.1、Qwen-Audio-3.1、Wan3.0、LiveTranslate 同传、HappyOyster-2.0 世界模型
• Agent 与服务：千问办公公测（益海嘉里金龙鱼、一汽丰田、中国数联、方达律所同日宣布接入）；千问 AI 平台的 Agent Studio 与 One Key MCP
• 终端与算力：Qwen Intelligence AI 手机全栈方案（面向手机厂商，荣耀 Magic9 首发）、QwenNote A2 录音卡、QwenBook 平板演示版；平头哥真武 V900（2027 年 Q1 量产）、倚天 CPU 路线图、磐九 AL128 超节点；软件底座 AgentCore / Agent Sandbox / Agentic OS。下一代视频模型预计 2026 年 11 月

模型侧的核验命令是这一条，只读、无副作用、本机实跑时不要求鉴权，因此适合放进流水线：

bl model list --model qwen3.8-max --output json

八个候选 ID 逐个跑完（除大会新品外，我加了同系列的 qwen3.8-flash——它不是这次发布的，但适合当降级位，一起验掉），2026-09-23 的结果分两堆：

"在目录"只是准入，不是可用。我对进白名单的模型各真调一次，验收标准只有一条：请求成功、有正常文本返回。

bl text chat --model qwen3.8-max --message "用一句话介绍你自己"
bl text chat --model qwen3.8-27b --message "用一句话介绍你自己"

两次都正常返回，原始命令与输出一起存档，写进接入评审材料。半年后有人问"当初凭什么判定这个模型可用"，拿得出东西，而不是靠某个人的记忆。

台账那一堆同样重要。"暂无"有两种成因：尚未上架，或上架时用了另一种 ID 写法。这两种在当天分不开，所以复验时要用多种候选写法各问一遍，并且每份核验产物都带日期与环境标识。

目录核验进 CI：设计的是事件，不是红绿灯

把核验放进流水线，最容易做错的地方是把它当健康检查：查不到就让流水线红。结果是每次新模型发布前后，CI 都在报一些没人需要立刻处理的失败，几周后大家开始忽略这条检查。

更合适的语义是状态变更事件。定时任务（每日或每周）跑一遍白名单加台账，把结果落成带日期的产物，只在两类变化上通知人：

跑批部分是一个很土的循环，命令本体就是核验过的那一条：

for id in $(cat model-ids.txt); do bl model list --model "$id" --output json >> "catalog-$(date +%F).jsonl"; done

（示意脚本，按自己的目录结构与产物规范改；model-ids.txt 里同时放白名单和台账 ID。）

--output json 是让这套东西能自动判定的前提。文本输出要靠人读，JSON 产物可以按字段比对，两次产物 diff 出来就是状态变更清单。

模型 ID 白名单：变更走 PR，不走群聊

白名单要解决的是"谁都能改模型 ID"这件事。生产配置里的模型名散落在代码各处、由不同人按需替换，出问题时既难定位也难回滚。

我给白名单定的四条规则：

1. 来源是核验产物，不是人手维护。 白名单里的每个 ID 都必须有一条可复跑的核验记录，记录里含日期与环境。
2. 生产配置只允许白名单内的 ID。 配置层做校验，不在名单内的 ID 直接拒绝，避免临时试用的档位悄悄留在生产。
3. 新增 ID 走 PR，附一次真调留痕。 评审要看的是核验日期、真调输出、降级档是否同步更新，而不是"新闻里说发布了"。
4. 降级档必须同时在白名单内且验过。 主档不可用时才去翻目录，等于把核验推迟到故障现场。

应用侧配置我一般这么放，ID 全部集中在一个文件里：

{
   
  "primary": "qwen3.8-max",
  "fallback": "qwen3.8-flash",
  "multimodal": "qwen3.8-omni-flash",
  "local_reference": "qwen3.8-27b",
  "pending": ["qwen-image-3.1", "qwen-audio-3.1", "qwen3.8-livetranslate", "wan3.0"]
}

（这是应用自己的配置文件，不是 CLI 的功能；pending 字段用来生成复验清单。）

27B 这一档要单独说一句：它是桌面端开源档，同时在云上目录里可直调。对既要本地部署又要云端兜底的团队，两条路可以用同一个 ID 对齐，环境切换时业务代码不必改。

单模型调用与多服务编排，是两层入口

企业侧真正要划清的是分工。大会同期发布的千问 AI 平台（官方）提供 One Key MCP 与 Agent Studio：前者用一个 Key 打通 100+ 生态服务，不必为每个服务单独配凭证；后者把模型能力直接搭成 Agent，不必自己写编排。千问办公则面向企业级通用 Agent，目前已开启公测。

分工的判断标准是依赖数量：只依赖一个模型的链路，用 CLI 最短，加编排层是白增依赖；依赖多个外部服务的链路，逐个配凭证和逐家做鉴权治理的成本，会超过引入编排层的成本。

两种门禁也不要混用。单模型链路的门禁是"ID 在不在目录"；多服务编排的门禁往后挪到"每个服务连不连通、权限够不够"，模型 ID 只是编排里的一个节点。拿串服务的思路写单模型脚本会多一层依赖，拿单模型的思路搭多服务 Agent 会在凭证管理上重复劳动。

接入前的五条验收标准

团队要跟进大会新品，这五条可以直接抄进接入文档：

1. 核验必须可复跑。 一条命令、一个 ID、一份带日期的产物，任何人任何时候重跑结果一致。
2. 真调留痕不可省。 目录状态不等于可用性，至少一次成功调用并保存原始输出。
3. 降级档同时验。 主档与降级档在同一轮核验里一起跑，不允许只有主档有记录。
4. 环境一致性。 在与生产一致的地域和账号下核验；本文结论只属于 2026-09-23 的本机环境，跨地域需重跑。
5. 凭证走统一密钥设施。 API Key 不写进批量脚本、不提交进仓库，CI 里通过密钥托管注入。

边界

本文只做了可用性验收，没有做任何能力评测，因此不提供模型之间的能力结论。四个"暂无"的 ID 之后可能上架，也可能以其他写法上架，需要在自己的环境重跑核验。候选 ID 由品牌名按命名习惯推测，推测本身可能不准，核验失败时要区分"模型没有"和"写法不对"。图像、语音、视频类模型上架后使用各自的命令组，不能套用 bl text chat，届时以对应命令的 --help 输出为准。

上手

npm install -g bailian-cli
bl model list --model qwen3.8-max --output json
bl text chat --model qwen3.8-max --message "用一句话介绍你自己"

Key 在控制台密钥管理页创建（地域选华北2 北京），命令文档与安装说明在阿里云百炼 CLI（bl），模型清单可在阿里云百炼首页浏览。