察元AI工舱数字员工开发平台
大模型 24×7 全生命周期开发白皮书

一句话定位：察元AI工舱 是"人均一套操作系统"的数字员工工厂。每台宿主服务器通过 Docker 部署多套 察元AI工舱 容器，每个容器就是一名员工（人类或数字员工）的完整工作环境——内置云桌面、多个编码智能体、受控的文件与剪贴板通道。人类员工通过浏览器云桌面介入，数字员工由调度器驱动 24 小时运转，两者共用同一套 Git / CI / 发布基础设施。

这套架构要同时满足四个约束：隔离（员工之间、员工与宿主机之间互不可见）、可控（复制/粘贴/上传/下载逐容器授权）、可续（数据目录映射宿主机，容器可销毁重建）、可混合（同一容器既能被 AI 驱动也能被人接管）。

基于对 /work/chatop（内部代号 chatop-ai）的实际代码探查：这是一个以 Ubuntu 22.04 为基础、深度定制的容器化云桌面镜像，XFCE 桌面全中文化，定制 noVNC 前端。"每员工一容器"的工作台层已经可用——账号、端口、数据卷、权限开关、智能体预装全部就绪；差距集中在"工厂外围"：调度、门禁、模型网关、审计外送。

选型原则有两条。第一，工具与模型解耦：数字员工的"外壳"（编码智能体，如 Claude Code）和"大脑"（底层大模型）是两件事——Claude Code 只是承载 agentic 循环、工具调用、技能与权限的工具，通过 ANTHROPIC_BASE_URL 把它的默认大脑指向谁，才决定真正干活的是哪个模型。第二，内网优先、按任务分层：本白皮书面向涉密/信创场景，默认大脑是私有化部署的国产 Qwen3‑Coder，数据不出内网、无 token 边际成本；云端 Claude 模型只在本地能力不足时按仓库标签升档过去，用于高价值决策点。

成本主要由"错配"产生——用云端旗舰跑巡检是浪费，用本地小模型做架构决策是返工。下表按能力分层给出候选，具体价格与评测分数以采购时官方数据和自建评测为准；「角色」列已按"本地 Qwen 主力、Claude 升档"的路由填写。

分层调用策略（模型路由）

• 默认层（主力）（按计划实现特性、写测试、改 UI、日常 CRUD）→ 本地 Qwen3‑Coder 为默认大脑，承载夜间批量开发的绝大多数工作量；数据不出内网、无 token 边际成本。
• 升档层（复杂特性、高风险变更、超大上下文重构）→ 单任务在 Qwen 上连续失败 2 次、或任务卡标记高复杂度，自动升档到云端 Claude Opus 4.8，并把失败上下文带上。
• 攻坚层（架构方案、跨项目合同变更、疑难 bug RCA）→ Claude Fable 5 / Opus 4.8，由人（架构师）触发，产出必须落盘为设计文档。
• 巡检层（lint 分诊、依赖升级、日志摘要、commit message）→ 本地小模型 / Haiku 4.5 / DeepSeek，就近跑、极低成本。
• 评审层（MR 评审）→ 与作者不同的模型做交叉评审（如 Qwen 写、Opus + GPT‑5 审），避免同模型盲区互证。
• 涉密层（合同、客户数据、加密算法）→ 只许本地 Qwen3，模型网关按仓库标签强制路由，云端 API 直接拒绝（出错方向是"拒绝"而不是"放行"）。

4.1 编码智能体（容器内置）

先分清"外壳"与"大脑"。下表这些编码智能体是工具外壳——负责 agentic 循环、工具调用、技能与权限；真正的"大脑"是它们背后的大模型（见第 03 节）。本体系以 Claude Code 为主力外壳（skill/hooks/MCP/无头能力最完善），但通过 ANTHROPIC_BASE_URL 把它的默认大脑接到内网 Qwen3‑Coder——即"Claude Code 的壳 + Qwen 的脑"。「无人值守能力」评估的是外壳，与大脑是谁无关。

人工接管不是一个"智能体"而是一条通道：任何容器随时可通过云桌面被人接管（agent 卡死排障、验收演示、敏感操作），这是混合模式的兜底。

多引擎并存的原则：一个容器内可以装多个 agent，但每个任务只有一个"责任 agent"。多 agent 同时改同一工作区是事故之源；交叉评审应通过 Git MR 界面（读 diff）进行，而不是共享工作目录。

4.2 外壳的可替换性：能替代 Claude Code 的工具

把 Claude Code 定位成"外壳"后，一个自然的问题是：外壳本身能不能换成国产/开源的？能。判据只有四条——能否本地/内网自托管、能否驱动本地 Qwen 模型、无头（headless）能力是否成熟、生态（skill/hooks/MCP）是否够用。夜间无人值守主力最看重"无头能力"，白天人机协作则可放宽。下表按"能否替代 Claude Code 当主力外壳"评估：

4.3 技能（Skills）：把工程纪律变成可执行资产

技能是这套体系里最容易被低估的资产。模型决定"能不能"，技能决定"每次都按规矩做"。技能库分三层：

• 通用工程技能（跨项目复用）：brainstorming（需求澄清）、writing-plans（写实施计划）、test-driven-development、systematic-debugging（修 bug 强制纪律）、code-review、verification-before-completion（先验证再声称完成）。
• 项目专属技能（进各仓库 .claude/skills/）：如何启动本项目、如何跑最小测试集、发布步骤、已知坑（如 PyInstaller frozen 模式、PowerShell 编码坑——这些血泪教训写进技能，数字员工就不会重复踩）。
• 平台运维技能：容器重建、日志采集、回滚步骤、告警分诊模板。

4.4 MCP 与外设工具

4.5 规范即代码：CLAUDE.md / AGENTS.md 分层

用户级 ~/.claude/CLAUDE.md      → 语言、个人纪律（全员统一模板下发）
工作区级 /work/CLAUDE.md         → 跨项目架构原则、Git 纪律、修 bug 流程
项目级  <repo>/CLAUDE.md         → 技术栈、目录导读、验证命令、质量红线
技能    <repo>/.claude/skills/   → 可执行的操作步骤（启动/测试/发布/排坑）
钩子    <repo>/.claude/settings.json → 权限白名单、hooks 强制门禁

这四层文件就是"架构师对数字员工的指挥系统"：架构师写规范，数字员工每个会话自动加载。规范写得越像操作手册，夜间产出越稳定。

5.1 分支模式

• 主干开发 + 短命分支（Trunk-Based）：数字员工从 main 拉 bot/<issue-id>-<slug> 分支，存活时间目标 < 24 小时，合并即删。长寿分支是 AI 时代的毒药——agent 解决合并冲突的成本远高于小步快跑。
• 人类员工分支用 feat/、fix/ 前缀，与 bot/ 区分，便于审计与统计。
• main 受保护：任何人（包括管理员）不得直推、不得 force push；变更只能走 MR。
• 未完成的功能用 feature flag 隐藏后照常合并，而不是养长分支。

5.2 提交规范（Conventional Commits + AI 署名）

<type>(<scope>): <一句话说清做了什么>

<正文：为什么改、影响面、验证方式>

Refs: #1234                          ← 必须关联任务卡
Risk: low | medium | high            ← 风险自评，决定合并路径
Verified-By: pytest -q tests/... ✅  ← 验证命令与结果
Co-Authored-By: Claude <noreply@anthropic.com>   ← AI 参与必须署名
Agent-Container: bot-07              ← 出自哪个容器（审计追溯）

• type 取值：feat / fix / refactor / test / docs / build / ci / perf / chore。
• commit message 不许预设因果：修的是预存在 bug 就写明"预存在，与当前症状关联未验"，不许为了好看编故事——这直接决定日后 RCA 的效率。
• commit-lint 在 CI 强制校验 trailer 完整性；缺 Refs 或 Risk 的提交直接拒绝。

5.3 编译模式

• 容器内构建只用于自测，CI 构建才是唯一可信产物。数字员工的环境可能被自己改乱，其产物一律不进制品库。
• 构建必须可复现：锁文件（poetry.lock / pnpm-lock）入库，CI 用固定镜像，禁止构建时联网拉浮动版本。
• 构建预算门禁：产物体积、构建时长、依赖数量超阈值即失败，防止 agent "顺手"引入大依赖。

5.4 发布模式

• 语义化版本 + 自动 changelog：从 Conventional Commits 自动生成版本号与变更日志，人不再手写。
• 发布链：合并 main → 自动部署 staging → 自动化验收（E2E + eval 集）→ 灰度 5% → 观察窗口（错误率/延迟对比基线）→ 全量。任何一环指标劣化自动停止并回滚。
• 夜间发布策略：数字员工夜间可以发 staging，生产发布窗口默认只在工作时间，除非该服务已达到"回滚全自动 + 灰度全自动"的成熟度分级。

无人值守开发的本质约束是：没有人盯着，所以"正确性证据"必须由流程自动产生。测试不再是开发的附属品，而是数字员工的"眼睛"——测试有多好，夜间产出就有多可信。

6.1 三层验证金字塔

6.2 强制纪律

• TDD 是默认工作法：任务卡里的每条验收标准，先翻译成失败的测试，再写实现。agent 的 MR 里必须能看到"测试先红后绿"的提交序列。
• 禁止 agent 弱化测试来过关：CI 检测测试删除/skip/断言弱化，此类 diff 自动标 high risk 强制人审。这是数字员工最常见的作弊路径，必须机器设防。
• 修 bug 必附回归测试：先写能复现 bug 的失败测试，修完变绿，测试永久留下。修 bug 前强制走 RCA 模板（症状 vs 现场分离、git log 查血缘、假设+反证），不许赌博式改代码。
• 变更即验证（verify）：非平凡改动必须端到端驱动一次真实流程（起服务、打请求、看结果），不能只靠单测绿就声称完成。

6.3 评测集是新的"测试资产"

凡是有 AI 行为的功能（检索、text2sql、生成），传统断言测不住"质量"，必须建评测集：固定输入 + 金标准判据 + 打分器。评测集同时服务三件事：MR 门禁（改动不许让评测分下降）、模型选型（新模型先过自家评测）、回归定位（分数掉了能定位到哪类 case）。

运维的目标形态是一个闭环：告警不再直接打给人，而是先打给值班 agent；agent 能解决的自动解决，解决不了的带着完整诊断上下文找人。

• 预案白名单是硬边界：值班 agent 只能执行事先由人评审过的预案脚本（回滚/重启/扩容/降级），任何白名单外的生产操作一律禁止——哪怕它"看起来显然正确"。信号可能与已知故障模式相似但根因不同。
• 发布与告警联动：告警发生时 agent 第一件事是对照"最近 2 小时发布记录"，命中即自动回滚，先止血后 RCA。
• 平台自身的运维：容器健康巡检（磁盘、僵尸进程、token 消耗异常）由 Haiku 级巡检 agent 每小时跑，异常容器自动隔离出调度池。
• 成本也是运维指标：按容器/任务统计 token 花费，异常烧钱（死循环重试）触发熔断，停掉该容器的派单。

核心机制是"白天人定方向，夜间机器执行，清晨人做裁决"的昼夜节律。人不守夜——夜间产出全部积压在两个受控队列里：待人审的 MR 队列、超纲上报队列。

调度机制要点

• 任务卡即接口合同：一张合格的任务卡 = 背景 + 验收标准（可翻译成测试）+ 约束（不许动什么）+ 风险级别 + token 预算。写不出验收标准的任务不许进夜间队列，退回给人拆解。
• 并发控制：同一仓库同一时刻只允许 N 个数字员工（建议 N=2~3），任务卡声明触碰的模块，调度器避免派发冲突模块。
• 预算熔断：每单有 token/时长预算，超限即挂起并上报，防止死循环烧钱。连续 2 单失败的容器自动隔离出池，等人排查。
• 回炉上限：CI 失败或评审驳回累计 3 轮仍不过 → 任务标记"需要人"，带完整上下文进晨审队列，不许无限重试。

隔离分四层：网络层（容器内 Caddy 是唯一入口，容器互不可见）、系统层（每容器独立账号/端口/资源配额，无宿主机访问）、数据层（剪贴板与文件传输逐容器授权）、凭证层（Git bot 账号仅有本仓库分支推送权，模型 API key 由网关代持不落容器）。

9.1 接入方式的安全对比：像素流 vs 普通协议

这套隔离能成立的物理前提，是员工与数字员工都通过像素流云桌面（noVNC）接入，而不是 SSH、Remote-SSH 插件、VPN 直连或 git clone 到本地这类直连协议。两者的差别不是"配置得更严"，而是结构性的：像素流下，跨越安全边界的只有下行的屏幕像素和上行的键鼠事件——源代码、密钥、数据本体从不离开容器；直连协议下，代码与数据本体、乃至一个真实 shell，会真实地落到员工终端。安全不是靠嘴说，下表逐维度对照（像素流占优 / 普通协议暴露 / 像素流的取舍代价）。

9.2 权限矩阵与审计

数据层与前两层隔离在 察元AI工舱 中已是现成开关：CLIPBOARD_IN/OUT、FILES_UPLOAD/DOWNLOAD、FILES_MAX_UPLOAD_MB、FILES_DIR 按容器 .env 配置即可实现下表——把它固化成三套角色模板（普通员工 / 受限外包 / 数字员工）随容器工厂下发。

• 审计不可选：每个容器的 shell 命令、agent 会话、文件传输、剪贴板事件全部落审计日志并汇聚到宿主机外的日志系统（容器内不可篡改）。数字员工的每一次工具调用都可回放。
• 密钥不落地：模型 API key、生产凭证由网关/密钥服务代持，容器内只有短期令牌。容器镜像与卷中出现密钥格式字符串即告警。
• 提示注入防线：数字员工处理外部内容（Issue 正文、网页、第三方包 README）时视为不可信输入；高危工具（发布、删数据、外发消息）不因文本内容触发，只因任务卡与预案触发。

当"写代码"这个动作本身被大幅自动化，所有角色的重心都从执行移向定义、约束与裁决。判断一个岗位新价值的标准变成：你写下的东西能否让 100 个数字员工同时正确工作？

组织形态的变化

• 团队结构从"金字塔"变"哑铃"：大量执行层工作由数字员工承担，人类集中在两端——定义端（架构师、PM、评测设计）和裁决端（评审、验收、超纲处理）。
• 新的核心 KPI：任务卡一次通过率（衡量定义质量）、夜间 MR 自动合并率（衡量门禁成熟度）、回炉率与根因分布（衡量规范/技能缺口）、每合并 MR 的 token 成本（衡量路由效率）。
• 知识管理成为生产资料：过去经验在人脑里，现在必须沉淀为 CLAUDE.md / 技能 / 评测集 / 预案，否则数字员工用不上。"血泪教训写进技能库"成为事故复盘的标准动作。
• 人的稀缺能力重新定价：品味（什么是好方案）、问题定义（什么值得做）、风险嗅觉（什么不能让机器碰）——这三样是模型短期内替代不了的，也是新的晋升标准。

不可逾越的红线

• 数字员工永不直推保护分支、永不执行白名单外的生产操作、永不持有长期凭证。
• 删库、删数据、对外发送消息、动计费——这四类操作永远需要人工确认，无论 agent 多确信。
• 测试被删除/跳过/弱化的 diff 一律强制人审，不给任何模型自动豁免。
• 涉密仓库只走本地模型；模型网关按仓库标签硬路由，出错方向是"拒绝服务"而不是"放行"。

主要风险与对策

成本模型（量级估算）

一个数字员工容器的成本 ≈ 基础设施（vCPU/内存，量级低）+ token 消耗（主要成本）。按分层路由跑夜间队列，单个中等任务（含回炉）的 token 成本通常在个位数到十几美元量级；对比一次人工返工的成本，关键变量不是单价而是一次通过率——这再次把投资重点指回规范、技能与评测集。