在腾讯云 OpenCloudOS 9 上部署OCManager 上手实操从零纳管到 AI 诊断一次跑通完整闭环前跑起来之后怎么把它用起来。我会把主机纳管、命令下发、整机监控、AI 助手四大模块从头点一遍途中踩到的 5 个真实 Bug 也会全部记录下来包括对应的修复方案和 PR 素材。一、写在前面本文的定位如果你只想看OCManager 怎么用的干货可以直接跳到 三、主机管理。但如果你正在评估这套系统能不能满足自己的运维需求、或者准备参与它的共建我建议你完整读一遍——因为我会试图回答几个官方文档没直接给出、但你上手前一定会问的问题「关联主机」到底关联了什么为什么控制台看不到我刚加的机器命令助手里那 12 条内置命令有什么用我能自己加吗整机监控上不上得来数据数据链路是什么样OCAI 是本地跑还是调云端我的 API Key 怎么接一个开源项目控制平面本身能不能被自己管起来以下每一个问题本文都会用实操 截图 数据库/网络抓包证据给出答案。二、我的环境与前置工作操作系统OpenCloudOS 9.4腾讯云 CVM2C8G公网 IP49.232.173.18OCManagerv1.0.0通过scripts/deploy.sh up一键拉起16 容器全部健康前端入口http://49.232.173.18:13070账号admin/Admin123456本次新增部署ocai-service独立 AI 后端后文详述LLM 提供方阿里云百炼qwen-plusOpenAI 协议兼容部署过程写在系列第 1 篇这里默认已经登录进控制台。登录后先建立一个心智地图左侧菜单一共 5 个一级项——主机管理、系统诊断、整机监控、OCAI 智能助手、设置。除了「设置」是配置项其余 4 项都是能干活的模块本文按这个顺序展开。三、主机管理从纳管到看见的完整闭环3.1 三级模型项目 → 集群 → 主机先把概念理清楚否则后面容易懵。OCManager 用三层来组织资源Project项目/租户 └─ Cluster集群 ← 一个业务单元的机器集合 └─ Instance主机 ← 具体的物理机 / 虚拟机一台主机的归属信息存在中间表cluster_instance_mappings它连接了三方project_id、cluster_id、instance_id。这个设计意味着同一台机器可以属于多个集群比如既算生产 web 集群也算IDC-北京-1非常灵活但也提高了初期理解门槛。3.2 主机列表页进入主机管理 → 主机就是整个系统的门面页面顶部 4 张统计卡片一目了然主机总数、物理机、虚拟机、Agent 离线主机。这里我特意只放了 1 台机器——它就是运行 OCManager 自己的这台服务器。这是我做的一个骚操作让控制平面把自己也纳管进来稍后详细说。右上角三个按钮关联主机把已有主机加进当前项目 集群不装 agent只做元数据关联导出把主机列表导出 xlsx列配置自定义显示哪些列想看内存/CPU 就勾上不想看厂商就取消筛选面板足够齐全环境、固资、Agent 状态、IP、发行版、内核版本都能筛。对于运维场景“我要找所有 kernel 版本还没升级到 6.6 的机器” 这种需求一条筛选就能出结果。3.3 关键真相「关联主机」不装 agent这是我最开始被文档劝退的地方也是很多人第一次上手会踩的坑。翻遍docs/user-guide/host-management.md的原话是这样的此操作仅做集群关联——把已选中的主机关联到当前项目下的指定集群不会向目标机器安装 Agent。是否安装 Agent、如何安装由部署环境另行决定。也就是说控制台上的「关联主机」弹窗只能选择数据库里已经存在的主机加入到集群它不做从零开始纳管一台新机这件事。而让机器出现在数据库里这件事正确的姿势是在目标机上跑 agent让它主动上报——但 agent 制品不在 ocmanager 主仓库里需要另外获取。这个设计合理但反直觉。它把发现主机和管理主机解耦了agent 是唯一的真相来源。可对于评估者来说第一次登进控制台一看主机数是 0很容易以为系统没启起来。好在文档给了第二条路大批量或离线 IP 列表请使用footstone HTTP API如ImportClusterInstanceMapping、AddClusterInstanceMapping等这句话背后的意思是——如果你有能力直接跟数据库或 API 打交道就能绕开 agent。下节我就走这条路让控制平面自己被纳管进来。3.4 骚操作让控制平面纳管自己思路很简单这台服务器本身就是控制平面instances、instance_ip_mappings、cluster_instance_mappings三张表都在它自己的 MySQL 里。我完全可以在instances里插一条真实数据IP、hostname、内核都从uname -a拿在instance_ip_mappings里补上instance_id → ip的关联这一步不做前端会拿不到详情后面会讲这个坑在cluster_instance_mappings里把它关联到pod集群单独写一个采集脚本把这台机的 CPU/内存/网络指标写进 ClickHouse 的msg_etl.os_monitor模拟 agent 上报为什么走这条路因为我没有 agent 制品又想让文章有真实数据可看。事后想想这套操作其实等价于手写了一个最小可用 agent——从数据视角来看它跟真 agent 上报的效果是一样的。灌数据的 SQL 我贴在文末附录里感兴趣可以直接抄。灌完刷新页面就有了截图里1 台机器、pod 集群、AST-CTL-001 固资号这一条整整齐齐的数据。3.5 主机详情页与我踩到的第一个 Bug点主机 IP → 进入详情页顶部三个 tab主机信息 / 整机监控 / 命令助手都是可以直接对这台主机操作的。右侧锚点导航把主机信息进一步分成 7 个板块基础信息、硬件信息、网络信息、系统信息、软件包、内核模块、内核参数。但是——我第一次点进来的时候整个页面是空白的。API 请求都是 HTTP 200但没数据渲染。排查过程记录如下这里想把它做成一个可复现的 debug case因为很有代表性浏览器 DevTools 看接口POST /trpc.ocmanager.footstone.Instance/DescribeInstance返回 200但 body 只有 114 字节明显没数据。服务端 audit 日志docker logs oc-footstone | grep DescribeInstance显示请求收到了但没打错误。翻instancerepo/repo.go源码DescribeInstance的 GORM 查询链是这样的errtx.Table(instances ins).Order(updated_at desc).Joins(left join instance_ip_mappings ii on ins.idii.instance_id).Take(ins).Error查询走的是ii.ip ?也就是instance_ip_mappings.ip不是instances.ip。手动跑等价 SQL结果为空——因为我灌数据时没往instance_ip_mappings表插记录即使instances表里有完整的 IPLEFT JOIN出来的ii.ip也是 NULLWHERE ii.ip 49.232.173.18永远匹配不到。修复INSERTINTOinstance_ip_mappings(created_at,updated_at,instance_id,ip)VALUES(NOW(),NOW(),1810,49.232.173.18);刷新页面基础信息板块立刻出现完整数据所属部门 默认、环境 pod、发行版 OpenCloudOS、UUID、机型 cvm.s6.2c8g一切正常。这条经验是给共建者的如果你打算给 OCManager 写一个自定义的批量导入主机 API一定要同时维护三张表——instances、instance_ip_mappings、cluster_instance_mappings——三者缺一前端就会出现接口 200 但页面空的迷之状态。这个约束目前只体现在源码里文档没有明说我打算作为一个 doc PR 提交回上游。3.6 硬件信息板块为什么依然是空的看截图会发现基础信息有数据但下面的硬件信息CPU 架构、核数、主频、BIOS 等是空的。这是合理的行为硬件信息、系统信息、软件包、内核模块、内核参数——这五类必须依靠 agent 从目标机采集上报才能得到。数据库里的instances表只存控制平面知道的元数据hostname、IP、OS 名称等CPU 主频这种要跑dmidecode/lscpu才能拿到的东西本来就不是 SQL 能编造的。所以在没有 agent 的评估环境里你只能看到基础信息一栏。这是产品设计的合理结果不是 Bug。四、整机监控从数据链路到可视化主机详情页切到「整机监控」tab这一屏是我最喜欢的一屏。理由如下4.1 你能一眼看懂的信息设计左上时间轴1h / 6h / 24h / 3d / 7d一键切换。这套设计对 SRE 太友好了——排障 90% 场景都在这几个时间粒度里概览卡片CPU 100.0%顶着红色偏高标签、内存 3.31 GB、磁盘 --%、入方向流量 --MB右侧指标分组CPU 11 项、内存 2 项、磁盘 IO 9 项、网络 4 项总共 26 项指标可选当前展示 8 项每张图上方标签负载区间、TOP6、avg、max——你可以只看平均、只看最大、只看排名靠前的实例多主机场景下极其顺手4.2 数据是怎么进来的我认真挖了一下 ClickHouse 的结构链路是这样的主机 (Agent) │ ▼ 上报 Kafka (topic: os_monitor) │ ▼ ETL msg-etl 服务 (Go / go-zero) │ ▼ 批量写入 ClickHouse 表 msg_etl.os_monitor │ ▼ 查询 footstone 服务 (tRPC HTTP 网关) │ ▼ API 前端图表渲染os_monitor表的核心字段字段类型说明group_nameLowCardinality(String)CPU / Mem / Net / IOmetrics_nameLowCardinality(String)cpu_usage、mem_used、rx_bytes…ipString主机 IPserver_timeDateTime落表时间DoubleDelta 压缩非常小data/num_dataString / Float64数值字符串 数字两份前者兼容富文本tagsMap设备/挂载点等标签我为了让整机监控页有真实曲线写了一个 60 行的 bash 采集脚本读/proc/loadavg、/proc/meminfo、/sys/class/net/eth0/statistics/*这些 procfs 数据每 10 秒往msg_etl.os_monitor里写一批。它本质就是一个最小 agent30 分钟就能补出一张漂亮的曲线。顺手回填 30 分钟历史数据的技巧脚本加一个backfill分支用date -d N seconds ago循环插入过去 180 个时间点。这样即使刚部署也能一进来就看到完整曲线不用等半小时。完整脚本贴在文末附录4.3 那个CPU 100%是怎么回事细心的读者会发现截图上CPU 使用率一直贴着 100%顶。真相很尴尬我第一版脚本里用awk BEGIN{srand(i); print 5 rand()*15}造模拟数据rand()在某些 awk 实现下会退化——当 srand 参数变化不足时rand 会持续返回接近 1 的值。所以 CPU 曲线一路飙到 100%。后来在下一节的 AI 对话里这个 bug 反而变成了亮点——AI 助手一眼看穿CPU 持续满载还热情建议我用top -c定位进程。我看着它的建议差点笑出声它诊断得完全正确只不过是在诊断我脚本的 bug。五、命令助手内置命令库与自定义扩展切回主机管理或者从左侧「系统诊断 → 命令助手」进入5.1 内置的 12 条公共命令这一页展示的是 OCManager 开箱自带的全局命令库。我按截图和源码盘点了一下一共 12 条按domain分组网络类net3 条命令类型说明Ping其他基础连通性MTR 探测其他每跳丢包/延迟诊断排查网卡丢包ethtool检查rx_out_of_buffer等丢包计数器审计类audit4 条全部用auditctl挂钩覆盖文件访问、系统调用、用户命令、系统重启监控。通用运维 4 条命令说明查看文件内容带参数的cat重置密码生成 root 新密码加解密openssl 对文件做加解密新增/更新 yum repo生成或改写/etc/yum.repos.d/*.repo软件包类 1 条安装指定版本的 Python。盘点下来这个命令库有几个明确特点优先满足国产化场景——audit、yum repo、ethtool都是 CentOS/OpenCloudOS 系运维的常客参数化程度不错——Ping、查看文件内容、yum repo都会弹出参数表单不是死命令数量偏保守——目前只覆盖了最基础的 20% 场景剩下的 80% 期待社区共建5.2 参数模板{param_name} 占位符 三种类型在「执行命令」弹窗里我看到Ping命令的目标 IP 是一个可选/必填的参数。翻sysdiagnose服务源码命令模板里支持三种参数类型input手动输入自由文本list下拉选择预定义候选值if条件分支根据前一个参数值决定是否显示举个例子新增/更新 yum repo命令用了if条件参数——先选新增还是更新选新增时只显示filenamecontent两个输入框选更新时会追加一个backup: 是/否的开关。这种设计比裸 shell 强了不少也比一堆 if-else 的 bash 脚本可维护。5.3 自定义命令与执行记录界面顶部除了「公共命令」还有两个 tab自定义命令 / 执行记录。自定义命令租户自己的命令库模板/参数完全跟公共命令一致只是可见范围仅限本项目执行记录所有历史任务列表状态机是running / success / failed / timeout默认 timeout 6 分钟执行流程 5 步用户选中命令 目标主机 ↓ sysdiagnose 服务生成任务 (task_id) ↓ 下发到 tms (task management service) ↓ tms 通过 agent 通道调用目标主机 ↓ agent 执行 回传 stdout/stderr/exit_code再次提醒agent我们仍然没有部署所以执行命令点了会 timeout。这一步的截图我没放因为纯粹是空 loading本文暂时不做命令执行的真实演示等我把 agent 拉起来后再补上。六、OCAI把 AI 助手真接进来这是我最想写的一节。因为它挑战了一个前提——开源项目要不要内置 AI 能力OCManager 的答案很聪明内置前端不绑后端。6.1 第一眼坦白的 502打开右侧菜单「OCAI 智能助手」如果你没接后端看到的是这个我特意把这张图放在这里因为它极度诚实没配 AI 服务就明明白白告诉你请求失败提示信息里明示这里是 OCAI需要独立部署ocai-service不装样子、不搞占位假答复、更没有内嵌任何具体 LLM 品牌这个设计的技术优势不与任何一家云服务商绑定——OpenAI / Azure / DeepSeek / Kimi / 通义千问 / 智谱 / Ollama谁 OpenAI 协议兼容就能接推理成本由部署方自己决定——想省钱用小模型想追求效果上 GPT-4都行合规友好——数据不出私有环境本地 Ollama 部署也 OK而它的用户体验代价是明显的开箱即用为 0你必须先自己搭一个后端。6.2 接入 ocai-service踩过的 7 个坑ocai-service是一个独立仓库gitee.com/OpenCloudOS/ocai-servicePython FastAPI 实现。它做两件事提供/api/v2/ocai/*系列 HTTP 接口对话、流式、会话历史、模型列表把用户消息 工具定义打给上游 LLM阿里百炼 / DeepSeek / OpenAI…把工具调用回来的参数转发给oc-footstone或msg-etl实现AI 主动查主机、AI 主动读监控我这一路踩了 7 个坑全部有解一次性列出来避免下一位共建者重复受苦#现象根因解法1docker build拉ghcr.io/astral-sh/uv卡死ghcr.io 国内不通改用南京大学镜像ghcr.nju.edu.cn/astral-sh/uv:latest2Debian slim 层apt-get update极慢deb.debian.org 出海慢Dockerfile 里 sed 换成mirrors.aliyun.com3uv sync 阶段卡在 pypi 20 秒超时files.pythonhosted.org 直连不通直接sed替换uv.lock里所有 URL 为mirrors.tuna.tsinghua.edu.cn/pypi/web967 处替换4deploy.sh找不到.env默认在 workspace 根服务子目录看不到ln -s建软链5容器起来立刻退出日志报 access deniedMySQL 新库ocai_service未授权给oc_manager用户GRANT ALL ON ocai_service.*6报ModuleNotFoundError: No module named ocaiuvicorn 子进程重置 cwd找不到/appcompose 里加PYTHONPATH: /app7起来 5 秒又重启日志 permission deniedlogs 挂载卷是 root容器 uid1001chown 1001:1001 deploy/compose/logs/ocai-service注意相对路径的起点是 compose 文件目录不是 workspace 根第 3 个坑最有趣uv.lock是 uv 的锁文件锁定了每个包的确切 URL。给 uv 配--index-url或环境变量UV_DEFAULT_INDEX不生效因为 uv 会严格按 lock 文件里的 URL 拉。唯一的解法就是直接改 lock 文件——这个技巧对任何 uv 项目都通用。6.3 前端反向代理与 JWT 打通ocai-service起来了还差最后一步——前端怎么调它。OCManager 前端调 AI 走的是相对路径/api/v2/ocai/*。所以我在oc-frontend的 nginx 配置里加一段反代location /api/v2/ocai/ { proxy_pass http://ocai-service:8000/api/v2/ocai/; proxy_http_version 1.1; proxy_set_header Host $host; proxy_buffering off; # SSE 流式必须 proxy_read_timeout 600s; proxy_send_timeout 600s; chunked_transfer_encoding on; }proxy_buffering offchunked_transfer_encoding on不能少否则 AI 的流式输出会被 nginx 缓存到全部完成再一次性吐出去用户会看到卡死几秒然后一大段文字的体验。认证问题的坑这个我调了近一个小时ocai-service 拿到 JWT 后会用OCAI_JWT_SECRET校验签名但它默认从oc-footstone的QueryJWTSecret端点动态拉密钥而 footstone 的17778端口是 tRPC 二进制协议21000/20000端口才是 HTTP 网关我一开始配了OCAI_OC_MANAGER_HOSThttp://oc-footstone:17778导致每次拉密钥都RemoteDisconnected最终修复OCAI_OC_MANAGER_HOSThttp://oc-footstone:20000容器内 HTTP 网关端口OCAI_JWT_SECRETabcedefghijklmn与 footstoneapplication.yaml里的jwtsecret完全一致OCAI_JWT_HEAD_KEYAuthorization与 footstone 一致注意只docker restart不生效.env只在容器创建时读取必须docker compose down up才能重载6.4 效果AI 主动调用工具配好之后回到浏览器问一句「我的所有机器」注意看第 1 轮次里的绿色小卡片——工具调用 / ocm_list_instance_ips JSON 参数{project_id: 1}。这是 OCAI 的核心能力AI 不是猜答案而是主动调用真实工具。整个对话的隐含流程是用户: 「我的所有机器」 LLM: 我需要查数据库让我调用工具 → 生成工具调用 { name: ocm_list_instance_ips, args: {project_id: 1} } ocai-service: 拿到工具调用转发给 footstone footstone: 返回 { ips: [49.232.173.18] } LLM: 收到工具结果用自然语言总结给用户再问一个更复杂的「健康状态如何」AI 调用了ocai_metrics_overview参数{ip:49.232.173.18, since:1h}。工具返回近 1 小时的 CPU / 内存 / 磁盘 / 网络指标AI 自动分析出CPU 利用率持续 100%min 100.0%p95 100.0%latest 100.0%且趋势为flat平稳这就是运维 AI 助手的正确姿势不当聊天机器人只当能读监控 能列主机 能诊断异常 能给建议的运维加速器。我甚至觉得这个能力值得在下一篇文章里单独展开——如果给 AI 加上我允许它下发命令的授权链路OCAI 完全可以做到一句话完成一次告警响应。七、我在这次实操中提交的两个 Doc PR 素材参与共建的读者最关心的部分。我把这次实操过程中发现的两个文档改进点整理成了 PR 素材正在走活动方式二文档优化通道。PR 素材 1主机数据模型补全约束问题docs/user-guide/host-management.md提到批量导入主机可以走 footstone HTTP API但没告诉读者三张表必须同步维护。建议补充的段落放在批量导入小节末尾⚠️数据模型约束手工/脚本方式导入主机时必须同时维护三张表instances主机主表instance_ip_mappings主机 → IP 的映射前端DescribeInstance依赖cluster_instance_mappings主机 → 集群 → 项目 的映射仅插入instances会导致前端主机详情页空白接口 200 但 body 为空。推荐使用ImportClusterInstanceMappingAPI它会一次性处理三张表若直连数据库导入请务必手写 3 条 INSERT。PR 素材 2OCAI 部署踩坑白名单问题docs/OCAI-DEPLOY.md只讲了clone → 改 .env → deploy.sh up但没说国内网络环境下会踩 7 个坑。建议补充的段落作为附录国内网络环境部署指南附录 A国内网络环境部署 ocai-service由于ocai-service使用 uv 管理依赖、基础镜像来自 ghcr.io/pypi.org国内网络下可能遇到以下问题1.ghcr.io/astral-sh/uv:latest拉取超时Dockerfile 中替换为ghcr.nju.edu.cn/astral-sh/uv:latest2. Debian 包安装慢在FROM python:3.12-slim之后追加RUN sed -i s|deb.debian.org|mirrors.aliyun.com|g /etc/apt/sources.list.d/debian.sources3. pypi 包下载超时uv.lock 中的 URL 硬编码为files.pythonhosted.org环境变量无法覆盖。执行一次sed-is|https://files.pythonhosted.org|https://mirrors.tuna.tsinghua.edu.cn/pypi/web|guv.lock这两个 PR 已经在起草会附上真实修复的 diff 和验证结果走活动方式二通道。八、写在最后一路点下来OCManager 给我的整体感受可以浓缩成三句话架构选型很硬——tRPC-Go Kafka ClickHouse FastAPI都是能扛大厂日活的技术栈不是玩具文档给了下限但没给上限——基本流程写得清楚但如果 agent 不装怎么演示、如果国内网络会踩什么坑这些高频疑难都要靠自己实操摸出来AI 助手的开放式设计是加分项——把 LLM 选择权交给部署方同时又提供了一套完整的工具调用框架比内置一个特定厂商 AI高级得多附录 A让控制平面纳管自己的完整 SQL-- 1. 插主机主表INSERTINTOfootstone.instances(created_at,updated_at,uuid,status,ip,agent,hostname,asset_id,os_name,os_name_version,is_oc,os_kernel,os_kernel_version,biz_desc,machine_type,machine_sub_type,maintainer)VALUES(NOW(),NOW(),UUID(),1,49.232.173.18,1,VM-0-4-opencloudos,AST-CTL-001,OpenCloudOS,OpenCloudOS 9.4,1,Linux,6.6.119-49.22.oc9.x86_64,OCManager 控制平面自监控,1,cvm.s6.2c8g,admin);SETiidLAST_INSERT_ID();-- 2. 补 IP 映射表这一步不做前端详情页会空白INSERTINTOfootstone.instance_ip_mappings(created_at,updated_at,instance_id,ip)VALUES(NOW(),NOW(),iid,49.232.173.18);-- 3. 关联到 pod 集群cluster_id4, project_id1INSERTINTOfootstone.cluster_instance_mappings(created_at,updated_at,project_id,cluster_id,instance_id,asset_id,uuid,ip,datasource)SELECTNOW(),NOW(),1,4,id,asset_id,uuid,ip,manualFROMfootstone.instancesWHEREidiid;附录 B60 行的最小指标采集脚本#!/bin/bash# collect_metrics.sh - 采集本机真实指标 → 写入 msg_etl.os_monitor# 每 10 秒一次另有 backfill 分支回填过去 30 分钟历史IP49.232.173.18UUID$(dockerexecoc-mysql mysql-uroot-poc_manager-Nse\SELECT uuid FROM footstone.instances WHERE ip$IP LIMIT 1)CHdocker exec oc-clickhouse clickhouse-client --querycollect_once(){localnow$(date-u%Y-%m-%d %H:%M:%S)# CPU 使用率localcpu_idle$(top-bn1|awk/Cpu\(s\)/ {gsub(/[^0-9.]/,,$8); print $8})localcpu_usage$(awkBEGIN{print 100 -$cpu_idle})localload$(cut-d -f1/proc/loadavg)# 内存localmem_used$(free-k|awk/^Mem:/ {print $3})# 网络localrx$(cat/sys/class/net/eth0/statistics/rx_bytes)localtx$(cat/sys/class/net/eth0/statistics/tx_bytes)$CHINSERT INTO msg_etl.os_monitor (group_name, metrics_name, ip, server_time, local_time, tags, data, num_data, uuid) VALUES (CPU,cpu_usage,$IP,$now,$now,{device:total},$cpu_usage,$cpu_usage,$UUID), (CPU,cpu_load,$IP,$now,$now,{period:1m},$load,$load,$UUID), (Mem,mem_used,$IP,$now,$now,{},$mem_used,$mem_used,$UUID), (Net,rx_bytes,$IP,$now,$now,{device:eth0},$rx,$rx,$UUID), (Net,tx_bytes,$IP,$now,$now,{device:eth0},$tx,$tx,$UUID)}# 常驻采集每 10 秒一次whiletrue;docollect_once2/dev/null;sleep10;done丢到nohup后台跑起来30 分钟后回到「整机监控」页就能看到完整曲线。附录 Cocai-service 完整 .env 关键项# 基础环境SERVER_HOST10.2.0.4CONNECT_HOST49.232.173.18# 数据库与 OCManager 共用MYSQL_HOSTmysqlMYSQL_PORT3306MYSQL_USERoc_managerMYSQL_PWDoc_manager# Redis与 OCManager 共用REDIS_HOSTredisREDIS_PORT6379REDIS_PWDoc_managers# 网络关键容器名而不是宿主机 IPOCAI_DOCKER_NETWORKocmanager-netOCAI_OC_MANAGER_HOSThttp://oc-footstone:20000# HTTP 网关端口非 tRPC 17778OCAI_MSG_ETL_HOSThttp://oc-msg-etl:8080# 认证与 footstone 完全一致否则永远 401OCAI_JWT_SECRETabcedefghijklmnOCAI_JWT_HEAD_KEYAuthorization# LLM阿里百炼 qwen-plusOpenAI 协议兼容OCAI_LLM_DEFAULT_NAMEqwen-plusOCAI_LLM_DEFAULT_HOSThttps://dashscope.aliyuncs.com/compatible-mode/v1OCAI_LLM_DEFAULT_API_KEYsk-***your-key-here***本文所有截图均取自 OCManager v1.0.0运行于腾讯云 OpenCloudOS 9.4。写作过程中所有 API 调用日志、SQL 变更记录、Docker 部署日志均已归档。如需交叉验证或深入讨论某个技术细节欢迎评论区留言。