云升 Yunrise 项目调研报告

1结论速览

五个判断，细节和证据在后面各节。

1. 项目性质：云升是企业 Agent 应用平台。上游内核 DSH 锁定版本，云升自己的价值主要落在树外插件（39 个包）、角色预设、企业知识和技能上。桌面端、服务器 Web 版、飞书机器人共用同一套内核和插件。2026-08-17 立项，一个月内桌面端迭代到 0.9.x。仓库
2. 部署形态：不在 K8s 上。唯一的生产宿主是一台 4C/32G ECS（172.18.193.80）。这台机器实例名叫 aistore.tmall.tmall.01.sit，同时跑着门店 aistore 的 6 个服务和 agent-platform。公网流量走 yunrise.xforceplus.com → ALB feishu-dev → nginx:80。湖仓
3. 核心机制：nginx auth_request 加上 auth-service 进程管家，实现"每个用户一个 DSH 进程、一个独立 HOME、一个 bwrap 沙箱"的多用户隔离。插件经 GitLab npm 私服发布，由市场门户审核后下发。仓库 湖仓 L3 快照里看到 3 个 bwrap 沙箱内的用户实例在线，与此机制一致。湖仓
4. 湖仓可见性：湖仓能看到仓库、入口链、宿主进程和端口；看不到代码结构（没有镜像，所以没有代码抽取）、配置（不用 Apollo）、数据（不用 DMS）。ECS→GitLab 桥对 Node 服务的归属是 0。09-04 之后新增的 88 服务器、yunrise-ai 域名、票易通 MCP 都还不在湖里。湖仓
5. 主要风险：单宿主资源争用（09-01 出过 OOM 连锁故障）；多处单点（auth-service、80 主机、飞书长连接、市场与 MCP 只在 80）；88 迁移中首个用户沙箱出现"双活"会话分叉；88 回源的 ALB 健康检查只探 nginx 默认页；资源命名与成本归属漂移；上游 developer preview 内核的定制负担。仓库湖仓

2项目画像与时间线

时间线

• 08-07AgentOS 首次提交：Windows 桌面 Agent 平台，洁净室方式对标 WorkBuddy。仓库
• 08-13GitLab yunrise 组创建 agentos 与 agentos-cloud 两个项目。湖仓
• 08-17《云升企业级 Agent MVP 设计》定稿，决策 D1 选"路线 A"：DSH 锁版本作为上游，云升维护配置层和 Electron 壳。AgentOS 两仓此后停更。仓库推断
• 08-19~21创建 yunrise-Agent（内核主仓）、yunrise-server、yunrise-config、dsh-plugin-market 四个项目。湖仓
• 08-25~26公网双域名按 Host 分流上线；多用户隔离（每用户一进程）上线；realip 还原真实客户端 IP。仓库
• 08-30~31内核换底到 0.1.1-rc.2。仓库
• 09-01bwrap 沙箱全量启用；桌面 0.9.0 发布三模式工作台；同日发生 OOM 连锁故障，随后加了四道内存护栏。仓库
• 09-02服务器扩容到 30GB 内存。仓库 湖仓记录规格为 ecs.r7a.xlarge、32768 MB，两者一致。湖仓
• 09-04授权数据迁入 users.json 等文件；湖仓完成本次调研所用的批次抽取。仓库湖仓
• 09-06票易通 MCP 服务群上线（nginx 9084），授权备份与巡检定时器上线。仓库
• 09-14第二台服务器 172.18.193.88 独立栈建成，Hologres MCP 上线（nginx 9085）。仓库
• 09-16yunrise-ai.xforceplus.com 开通并指向 88；首个迁移沙箱出现双活，尚未正式切换。仓库

3资产盘点

6 个仓库都由同一位创建者（creator_id 364）在 08-13 ~ 08-21 之间建立。提交数有两个口径：湖仓 09-04 的 GitLab 统计，以及 09-16 实际检出的 git rev-list。

① GitLab 语言统计把 dsh/skills 下业务技能的 Python 脚本算进去了，auth-service 本身是 Node.js。

4架构图

三张图都由 archify 生成，已通过 showcase 质量校验（9/9 项）和四种桌面视口的浏览器实测。图内可以缩放、搜索、聚焦路径，点"打开交互版"查看完整视图和引导章节。

5公网入口链

按 scenarios/incident.md INC-3 的 ODS 三段链逐跳实测（dws.v_ingress_chain 当前不可用）。湖仓

6服务器运行时

下表把湖仓 ECS L3 进程快照（2026-09-04 19:18 UTC）和仓库里声明的 nginx/systemd 配置对齐。该主机是 L3 首梯队 3 台已采集机器之一。

88 独立栈（迁移中）仓库

• 规格 2 核 7.4G 加 2G swap，Alibaba Cloud Linux 4，cgroup v2（MemoryHigh=5G / MemoryMax=6G）。有自己独立的 nginx、auth-service 和账号库，没有 3080 共享兜底，实例拉起失败时直接返回 502。
• 插件市场（9082）、票易通 MCP（9084）、下载页（9081）仍通过内网回调 80；飞书机器人只能在 80 上跑一份。
• 截至 09-16：首个迁移沙箱在 80 和 88 上同时有实例在跑，两边会话已经分叉（当天各自新增会话），正式切换步骤（强制下线、停实例、挪走目录）还没执行。
• 湖仓 09-04 批次的 ECS 台账里找不到 172.18.193.88。

7鉴权与多用户隔离

依据 auth-service/server.js、proc-manager.js、config.js 与 nginx 配置。仓库

8研发与发布链路

CI 配置取自湖仓 gitlab_ci_configs湖仓，打包与部署流程取自运维文档仓库。湖仓里 gitlab_pipelines / gitlab_jobs 整体为空，看不到流水线运行记录。

• 插件优先原则：功能改造能做成树外插件就不改内核，判据是"升级到 rc.N+1 时这个功能需不需要人工动手"。目前内核仍有 9 个定制包（品牌文件、ModelSelect 等），每次升级都要重放移植。仓库
• 提交规范：GitLab pre-receive 钩子要求提交信息带飞书子任务编号（subtask:TAXWARE-…），可以写在 trailer 位置。仓库
• 插件分发平台：09-13 起门户支持 ?platform=desktop|server，老客户端只能看到全平台插件。仓库

9外部依赖

10湖仓覆盖与治理发现

从研发本体湖仓的视角看，云升这类"ECS 裸部署 + Node.js + 文件型状态"的项目，哪些看得见，哪些看不见。

治理发现

1. 命名与成本归属漂移：承载云升生产流量的宿主叫 aistore.tmall.tmall.01.sit，名字里是 sit 环境，成本标签却记在 aistore；ALB 名叫 feishu-dev，09-04 批次时已挂 4 个域名，09-16 又加上 yunrise-ai；new-api 网关跑在一台叫 prometheus 的机器上。湖仓
2. Node 服务归属缺口：L3 已经采到进程的 script_path（例如 /home/appuser/yunrise-dsh/auth-service/server.js、/home/appuser/dsh-market-portal/portal/server.mjs），它们和仓库文件路径（yunrise-server 的 auth-service/server.js、dsh-plugin-market 的 portal/server.mjs）存在稳定的后缀对应。建议给 v_ecs_workload_gitlab 增加"脚本路径后缀 ↔ 仓库文件"匹配通路。湖仓仓库
3. 单元级命令缺失导致 GAV 丢失：同一台主机上，tmall-billing、tmall-store 在进程级能读到 jar 的 GAV，但单元级 exec_command 为空，DWD 层判成 no-jar。建议 DWD 层在单元级缺失时回退使用进程级 jar。湖仓
4. 跨项目端口漂移：云升文档说 cliproxyapi 的 8317 端口已废弃，但 ticket-tax-ai-ops-service（PROD）等仍配着 :8317，需要确认这些服务的模型调用是否受影响。湖仓仓库推断
5. 非镜像项目缺少代码入口：建议给 yunrise 组增加"源码直抽"的抽取入口（按默认分支或发布标签），补上端点、配置键、依赖这些结构元数据。推断

关键查询（逻辑层名，可直接用 probe 执行）

-- 入口链：域名 → ALB 规则 → 服务器组 → 后端
SELECT r.priority, r.host, g.name AS server_group, s.type, s.server_id, s.server_ip, s.port
FROM ods_current.alb_rules r
JOIN ods_current.alb_load_balancers a ON a.load_balancer_id = r.load_balancer_id
LEFT JOIN ods_current.alb_server_groups g ON r.forward_server_group_ids::jsonb ? g.server_group_id
LEFT JOIN ods_current.alb_servers s ON s.server_group_id = g.server_group_id
WHERE a.dns_name = (SELECT value FROM ods_current.dns_records
                    WHERE domain_name = 'xforceplus.com' AND rr = 'yunrise');

-- 宿主上的进程 × 监听端口（L3）
SELECT p.unit_name, p.exe_name, p.script_path, lp.addr, lp.port
FROM ods_current.ecs_processes p
LEFT JOIN ods_current.ecs_listen_ports lp
  ON lp.instance_id = p.instance_id AND lp.pid = p.pid
WHERE p.instance_id = 'i-bp15teisdgaryc16mtcs' AND p.unit_name ILIKE 'yunrise-%';

-- ECS workload → GitLab 归属（Node 服务全部 no-jar / none）
SELECT unit_name, match_route, match_quality
FROM dws.v_ecs_workload_gitlab
WHERE instance_id = 'i-bp15teisdgaryc16mtcs';

11风险与建议

• 高单宿主资源争用。云升的 N 个用户实例、aistore 门店 6 个服务、agent-platform 挤在同一台 4C/32G 上，09-01 已经出过 OOM 连锁故障。
  建议：把云升和 aistore 拆到不同宿主（88 独立栈方向是对的）；给 tmall 系服务也加上 cgroup 限额；把 spawn ENOMEM 和 OOM 次数接入告警。
• 高迁移双活导致会话分叉。首个迁移沙箱 09-14 起同时在 80 和 88 上被使用，两边会话已经不一致。
  建议：按指南先把 80 当天独有的会话补到 88，再执行强制下线、停实例、挪走目录；把"同步即切换"写成一个脚本原子完成，避免只做一半。
• 高多处单点。每个请求（包括静态资源）都要经 auth-service 的 /check；80 是唯一生产主机；飞书机器人长连接只能在一台上跑；88 依赖 80 的市场、MCP 和下载页。
  建议：给 /check 结果做短时缓存或对静态资源放行；明确 88 在 80 故障时的降级行为；把市场和 MCP 部署成两台都能用的服务。
• 中共享 ALB 与健康检查。ALB feishu-dev 同时承载 yunrise、aistore、cliproxyapi2 和默认业务；文档记载 88 回源的健康检查只探 nginx 默认页，证明不了云升本身活着（80 侧的检查路径未核实）。
  建议：健康检查路径改为 /_auth/login；为云升单独建服务器组或 ALB，并按实际用途重新命名。
• 中上游内核与定制负担。DSH 仍是 developer preview，会有破坏性变更；云升在内核上仍有 9 个定制包，还出现过内核自带插件与种子插件 id 冲突导致升级即崩的事故（0.6.9）。
  建议：继续把定制收敛回插件，把插槽补丁推给上游；发版前固定跑 verify-load 的 id 冲突检查。
• 中模型供给集中。Token Plan 周配额耗尽会让全服对话瘫痪；cliproxyapi 端口变更会影响还在用旧端口的调用方。
  建议：配额和 401 做监控告警；利用 dsh-model-tiers 的档位自动回落到其他 provider。
• 中权限与暴露面。服务器种子 settings 的默认权限预设是 danger-full-access，完全依赖 bwrap 沙箱兜底；市场 9082 机器口零凭据，/api/refresh 无鉴权，安全性依赖内网边界。
  建议：服务器实例改用更严格的默认预设，高危工具走审批；9082 限制来源 IP，refresh 加共享令牌。
• 低可观测与治理缺口。湖仓看不到云升的代码结构、配置和运行记录；CI lint 报错；AgentOS 两仓停更后去留未定。
  建议：落实第 10 节的湖仓补桥建议；修复 yunrise-Agent 的 CI needs 顺序；决定 AgentOS 两仓归档还是继续，并清理 /opt/agentos 的历史命名。

12方法与局限