boss/docs/architecture/enterprise_ai_ops_architecture_cn.md

# Boss 企业 AI 运营中枢量产架构开发文档

更新时间：`2026-05-17`

## 1. 文档定位

这份文档把 `outputs/boss-product-intro-image2-full-raster.pptx` 里的产品架构、此前确认的量产 B+ 方案、以及 Codex App Server 最新开放协议思路统一成后续开发约束。

当前结论：Boss 不能只做一个“手机控制 Codex”的工具，而要升级成企业级 AI 运营中枢。Boss 负责组织、权限、任务、审计、数据安全、回退和跨设备协作；Codex、Computer Use、Skill、业务系统和第三方 Agent 都只是可替换执行能力。

本文件描述的是量产目标架构，不代表当前所有能力都已经落地。当前运行真相仍以 `docs/architecture/current_runtime_and_deploy_status_cn.md` 为准。

## 2. 来源材料

- 产品 PPT：`outputs/boss-product-intro-image2-full-raster.pptx`
- PPT 抽图校对目录：`outputs/pptx-architecture-read/slides`
- Codex App Server 官方文档：`https://developers.openai.com/codex/app-server`
- 当前 Boss 运行文档：`docs/architecture/current_runtime_and_deploy_status_cn.md`
- 当前 API 与服务清单：`docs/architecture/api_and_service_inventory_cn.md`

## 3. 产品总目标

Boss 的产品目标是把主 Agent、业务 Agent、组织角色、真实电脑、企业系统和 Skill 连接成可执行的企业管理系统。

PPT 中的核心判断需要进入产品开发主线：

- AI 已经能对话，但企业执行还没有被完整接管。
- 真正的成本不在模型本身，而在重复沟通、人工汇总、跨系统搬运和不可追踪的执行过程。
- Boss 的价值不是再做一个聊天机器人，而是让经营目标变成可拆解、可审批、可执行、可追踪、可复盘、可回退的闭环。
- 企业级 AI 必须先可控，再谈自动化。

## 4. 采用方案 B：Boss 企业控制面 + 可插拔执行协议

量产版本默认采用方案 B。

方案 B 的定义：

- Boss 是企业级控制面和数据事实源。
- Codex App Server、Codex MCP、Codex CLI、Computer Use、CUA Driver、Browser Automation、业务系统 API、Skill Runtime 都作为执行 provider 接入。
- 所有 provider 的原始事件必须先归一化为 Boss 自有事件和消息模型，再进入 APP、Web 管理后台、审计日志和回退系统。
- UI、权限、审计、备份、任务 SLA、风险处置和企业账号体系不能直接依赖某一个 provider 的私有字段。

选择方案 B 的原因：

- 企业客户最关心的是权限、审批、审计、稳定性、数据边界和可回退，不是某个单一执行引擎的能力展示。
- Codex 协议未来会持续变化，Boss 必须通过适配层快速跟进，而不是把协议字段写死到业务模型里。
- Boss 还需要支持我们自研的 Computer Use、未来的企业系统 API、Telegram/飞书/微信入口、Skill 分发和多租户后台，单独围绕 Codex 建模会限制长期扩展。

## 5. 方案 C 的优劣势

方案 C 指把 Codex App Server 作为更核心的数据和执行事实源，让 Boss 尽量贴近 Codex 原生 Thread、Turn、Item、Approval、Skill、Plugin 和 App Server event。

优势：

- 最接近 Codex 原生体验，线程、实时事件、审批、Skill、命令执行和文件变更可以更快跟随官方能力。
- APP 与 Codex 桌面端的同线程实时同步理论上更顺，重复实现更少。
- Codex 新增功能时，Boss 可以更快暴露给用户。

劣势：

- 业务核心会强绑定 Codex 协议，协议变更会直接冲击 Boss 的权限、审计、回退和消息账本。
- 企业级多租户、子账号授权、跨公司隔离、平台总后台、Skill 分配和数据留存不能完全交给 Codex 原生模型。
- 非 Codex 执行能力会变成二等能力，比如自研 Computer Use、业务系统 API、Telegram/飞书入口和后续企业 OA 集成。
- 数据自动备份和业务级回退会受限于 Codex 本地会话存储语义，不能满足 To B 生产级治理。

最终策略：

- 不采用方案 C 作为总架构。
- 在执行层内部吸收方案 C 的优点，优先新增 `CodexAppServerBackendAdapter`。
- Boss 数据模型保持独立，Codex App Server 只作为强执行 provider 和实时事件来源。

## 6. 多层级协作关系

PPT 第 3、4、5、8、9 页确定的协作链路必须成为产品模型的骨架。

### 6.1 组织层级

| 层级 | 角色 | 主要职责 | 可见范围 |
| --- | --- | --- | --- |
| 平台最高管理员 | Boss 平台运营方 | 创建企业、开通老板账号、查看全局风险、处理服务异常、管理套餐和授权 | 全平台治理数据，不默认看企业业务内容明细 |
| 企业老板端 | 企业超级管理员 | 看全局目标、成本、现金流、风险和最终结果；通过主 Agent 问询公司执行状态 | 本企业全局 |
| 经理端 | 部门或项目负责人 | 接收目标、拆解任务、审批异常、追踪团队进度、协调资源 | 授权团队、部门、项目 |
| 员工端 | 具体执行人员 | 处理具体任务、补充判断、上传材料、确认结果 | 自己任务和授权上下文 |
| 系统端 | Boss 控制面 | 维护账号、设备、权限、SOP、审批、审计、日志、备份和回退 | 按租户和权限隔离 |

### 6.2 Agent 层级

| 层级 | Agent | 职责 |
| --- | --- | --- |
| 调度层 | 主 Agent | 理解目标、判断权限、拆解任务、分配资源、汇总结果、协调多线程/多设备/多业务 Agent |
| 执行层 | 业务 Agent | 按 SOP 执行业务流程，如销售、客服、财务、HR、项目、行政、运维 |
| 设备层 | 本地 Agent | 接入真实电脑、Codex、Computer Use、浏览器、文件、系统权限和本地 Skill |
| Provider 层 | 执行 provider | Codex App Server、Codex CLI/MCP、CUA Driver、Browser Automation、业务系统 API、Skill Runtime |

### 6.3 主 Agent 与业务 Agent 分工

主 Agent 负责“为什么做、谁来做、能不能做”：

- 理解业务目标和约束条件。
- 拆解任务、里程碑和依赖关系。
- 判断账号、设备、项目、Skill 和数据访问权限。
- 选择合适业务 Agent、设备 Agent 或执行 provider。
- 在关键节点请求用户、经理或审批人确认。
- 汇总执行结果、风险、阻塞和下一步动作。

业务 Agent 负责“按 SOP 把事情做完”：

- 销售 Agent：线索跟进、商机管理、合同执行、回款跟踪。
- 客服 Agent：客户咨询、工单处理、服务跟进、满意度管理。
- 财务 Agent：费用报销、预算管理、账务处理、财务分析。
- HR Agent：招聘管理、入职管理、考勤管理、绩效管理。
- 项目 Agent：项目计划、进度跟踪、风险管理、交付验收。
- 行政 Agent：采购管理、资产管理、会议管理、用品管理。
- 运维 Agent：巡检、告警、故障复盘和修复建议。

## 7. 标准执行闭环

所有企业动作都应尽量落到同一条闭环：

1. 用户提出经营目标或执行请求。
2. 主 Agent 将自然语言目标拆成任务、里程碑、依赖和风险。
3. 系统检查账号、设备、项目、Skill、SOP 和数据权限。
4. 经理或授权人确认边界、资源、预算和高风险动作。
5. 业务 Agent 或设备 Agent 按 SOP 执行。
6. 员工只处理例外、补充材料、做判断和确认结果。
7. 系统回写过程记录、权限记录、结果记录和异常记录。
8. 主 Agent 形成复盘、版本记录、项目目标更新和下一步建议。

这条闭环必须沉淀四类记录：

- 权限记录：谁在何时对哪些内容拥有什么操作权限。
- 过程记录：任务流转、操作步骤、审批意见和执行过程。
- 结果记录：关键输出、指标达成、交付物和数据回写。
- 异常记录：异常识别、处理过程、原因分析和改进措施。

## 8. 治理能力必须前置

PPT 第 8 页强调“AI 执行必须先可控，再谈自动化”。量产版本的功能优先级必须体现这一点。

| 治理能力 | 产品要求 |
| --- | --- |
| RBAC 角色权限 | 老板、经理、员工、子账号、设备、项目、Skill 和数据权限必须可裁剪 |
| 审批与确认 | 高风险任务必须进入人工确认，不允许 AI 越权操作 |
| 审计日志 | 记录任务来源、执行过程、结果回写、异常原因和审批链 |
| 账号与设备治理 | 管理 AI 账号、真实电脑、本地 Agent、Skill 能力和授权状态 |
| 数据边界 | 按企业、部门、项目、账号隔离上下文，越权数据不展示 |
| SLA 与风险处置 | 异常任务、离线设备、执行失败、超时任务必须进入风险台 |

## 9. 量产数据安全与自动备份机制

当前文件型 `data/boss-state.json` 只能支撑 MVP，量产必须迁移到数据库和可回退的数据架构。

### 9.1 数据事实源

量产推荐：

- PostgreSQL 作为主业务库。
- 对象存储保存附件、截图、执行产物、日志归档和备份包。
- Redis 或队列系统只做缓存、锁和异步任务，不作为最终事实源。
- 每一个重要状态变化都写入 append-only 事件账本。

核心原则：

- 普通业务表保存当前状态。
- 事件账本保存“发生过什么”。
- 审计表保存“谁允许了什么”。
- 快照表保存“某个时刻可以回到哪里”。

### 9.2 自动备份

必须具备：

- PostgreSQL WAL 归档和定时全量备份。
- 每日全量备份、小时级增量备份、关键变更前即时快照。
- 跨区域或独立对象存储备份。
- 备份加密、备份校验和定期恢复演练。
- 按企业租户拆分可导出数据包，便于企业级交付和迁移。

建议目标：

- RPO：普通业务不超过 15 分钟，关键企业客户可配置到 5 分钟。
- RTO：普通故障 1 小时内恢复，关键演示或生产客户 15 分钟内恢复核心链路。

### 9.3 业务级回退

量产回退不能只依赖数据库备份。必须提供业务级回退能力：

| 场景 | 回退方式 |
| --- | --- |
| 消息误删 | 软删除 + 会话级恢复 |
| 项目目标或版本记录误改 | 版本化保存 + 一键恢复上一版 |
| 权限误授权 | 授权变更事件可撤销，撤销后同步清理会话和任务上下文 |
| Skill 安装或升级失败 | 安装前备份、版本锁、回滚到上一可用版本 |
| 主 Agent 错误接管 | 关闭接管、取消 queued/running 主动任务、恢复原线程控制权 |
| Codex 开发任务误操作 | 执行前 checkpoint、Git 分支隔离、diff 审批、必要时 revert |
| Computer Use 错误点击 | 高风险动作前确认、动作录像/截图留档、支持人工中止 |
| 企业配置误改 | 配置快照 + 审计原因 + 指定时间点恢复 |

## 10. Codex 协议扩展策略

Codex App Server 官方文档明确了它面向深度产品集成，包含 authentication、conversation history、approvals 和 streamed agent events。它当前基于 JSON-RPC 形态暴露 Thread、Turn、Item、Approval、Skill、Plugin、App、MCP、文件系统和模型列表等能力。

Boss 后续要把 Codex App Server 当作优先升级方向，但不能把业务模型绑死在它的字段上。

### 10.1 Provider 抽象

新增或强化统一执行 provider 接口：

```text
Boss Task
  -> ExecutionBackendSelector
  -> CodexAppServerBackendAdapter
  -> CodexMcpBackendAdapter
  -> CodexCliExecBackendAdapter
  -> NativeComputerUseBackendAdapter
  -> BrowserAutomationBackendAdapter
  -> BusinessSystemApiBackendAdapter
```

每个 provider 必须声明：

- `providerId`
- `protocolVersion`
- `capabilities`
- `riskPolicy`
- `approvalModes`
- `streamingModes`
- `rollbackSupport`
- `healthCheck`
- `fallbackProviderId`

### 10.2 事件归一化

Codex App Server 的原始事件不能直接进入前台 UI。必须先归一化为 Boss 事件：

| Codex 原始概念 | Boss 归一化概念 |
| --- | --- |
| Thread | ProjectConversation / CodexThreadRef |
| Turn | ExecutionTurn / UserRequest |
| Item | ExecutionItem / MessageSegment / ProgressStep |
| Approval Request | ApprovalCard |
| Command Execution | ExecutionStep |
| File Change | ChangeSet |
| Skill | SkillCapability |
| Plugin/App | ExternalCapability |
| Error | RiskEvent / TaskFailure |

### 10.3 版本兼容机制

每次 Codex 协议升级时必须走以下流程：

1. 拉取或生成当前 Codex App Server TypeScript / JSON Schema。
2. 保存到 `docs/protocol-snapshots/codex-app-server/<version>/`。
3. 自动生成 provider capability manifest。
4. 跑协议兼容测试，确认 Thread、Turn、Item、Approval、Skill、Plugin 和 model/list 是否仍能映射。
5. 新能力先挂 feature flag，不直接进入生产默认链路。
6. 对关键企业租户先做灰度，再全量开启。

### 10.4 禁止写死的内容

以下内容不得写死进业务逻辑或 UI：

- Codex CLI 输出 envelope。
- Codex Desktop 私有数据库字段。
- 某一个 Codex 版本的 stderr/stdout 文案。
- 某一个 App Server event 的完整原始字段。
- 本地线程文件路径。
- Codex 具体模型列表。
- Skill 的本地绝对路径。

允许写死的是 Boss 自己的领域模型、权限模型、审计模型和回退模型。

## 11. 进度卡与实时协作

PPT 强调从目标到结果的可追踪闭环，Codex App Server 又提供 streamed agent events。Boss 的聊天窗口必须把“正在做什么”表达为结构化进度，而不是刷屏输出过程噪音。

建议统一进度卡结构：

- 进度：计划、执行中、完成、失败、等待审批。
- 分支详情：Git 分支、diff 摘要、测试状态、生成产物。
- 生成结果：文档、APK、图片、代码文件、报告。
- 后台智能体：主 Agent、业务 Agent、Codex、explorer、Computer Use provider。
- 风险：权限不足、设备离线、测试失败、审批等待、回退点。

执行过程中的低价值输出默认折叠，只显示最终结果和关键节点。用户需要查看细节时再展开过程日志。

## 12. Skill 治理与共享

Skill 是 Boss 企业扩展性的关键能力，但不能只做本机目录同步。

量产 Skill 治理需要支持：

- 平台级 Skill 市场。
- 企业级私有 Skill 仓库。
- 按公司、部门、账号、设备、项目授权 Skill。
- Skill 安装、升级、回滚、版本锁。
- Skill 依赖、来源、checksum、签名和安全等级。
- Skill 使用审计和失败率统计。
- 多电脑共享 Skill，但执行时仍按设备本地能力和权限裁剪。

主 Agent 在选择 Skill 时，只能看到当前用户、当前企业、当前设备和当前项目被授权的 Skill。

## 13. 当前落地进度与量产剩余清单

本节用于承接当前开发状态。这里的“已落地”只表示代码和本地回归已具备，不代表已经完成生产灰度、客户验收或长期稳定性验证。

### 13.1 已落地的量产底座

| 方向 | 当前状态 | 关键文件 / 接口 |
| --- | --- | --- |
| 多租户与 RBAC | 已具备最高管理员、企业管理员、成员账号、公司归属、设备 / 项目 / Skill 授权和审计日志 | `src/lib/boss-permissions.ts`、`GET/POST /api/v1/admin/access` |
| 设备撤权 | 已支持 `revoke_device`：清空设备 token、置离线、写 `device.revoked` 审计，并阻断 heartbeat、任务认领、Skill 同步、日志上报、boss-agent OTA | `src/lib/boss-data.ts`、`src/app/api/device-heartbeat/route.ts`、`src/app/api/v1/admin/access/route.ts` |
| 设备心跳安全 | 已禁止无 token 的已存在设备续命，禁止未准备 enrollment 的新设备自注册，吊销设备不会刷新 `lastSeenAt / status / projects / projectCandidates` | `POST /api/device-heartbeat` |
| 主 Agent 任务租约 | 已支持 `attemptCount / maxAttempts / leaseExpiresAt`，运行中任务租约过期可重试认领，超过上限转 `timed_out` | `claimNextMasterAgentTask()`、`POST /api/v1/master-agent/tasks/claim` |
| 主 Agent 任务取消 | 已支持取消 `queued / running / needs_user_action`，写 `canceledAt / canceledBy / cancelReason`，迟到 complete 不覆盖终态 | `POST /api/v1/master-agent/tasks/[taskId]/cancel` |
| Codex 桌面同步 | 已支持 APP 用户消息镜像到 Codex Desktop rollout，并通过本机刷新桥提示桌面端感知更新 | `local-agent`、Codex Desktop Refresh Bridge |
| Codex App Server 接入 | 已有第一批 provider runner，turn 启动前失败可回退 CLI，turn 启动后不重复执行 | `local-agent/codex-app-server-runner.mjs` |
| 电脑控制 provider | macOS 链路优先 Codex Computer Use，失败后回退 CUA Driver；browser / desktop 任务统一走 `MasterAgentTask` 和进度卡 | `local-agent/computer-use-task-runner.mjs`、`scripts/codex-computer-use-runtime.mjs`、`scripts/cua-driver-computer-use-runtime.mjs` |
| 状态快照与回退 | 文件状态已有自动快照、手动创建快照和恢复前 pre-restore 快照 | `src/lib/boss-state-backups.ts`、`GET/POST /api/v1/admin/backups` |
| PostgreSQL 切换前置 | 已有 Postgres JSONB store、schema 校验、dry-run 迁移、Postgres 备份导出和恢复脚本 | `src/lib/boss-state-store.ts`、`scripts/boss-state-store-maintenance.mjs` |
| boss-agent Mac OTA | 已支持 Mac agent 包检查、下载、校验和覆盖安装，并保留绑定配置 | `src/lib/boss-agent-ota.ts`、`local-agent/boss-agent-ota-runner.mjs` |
| Skill 生命周期治理 | 已支持 install / update / uninstall / rollback / version_lock 请求、设备端 claim / complete、source allowlist、checksum、更新前备份和失败恢复 | `GET/POST /api/v1/admin/skills/requests`、`skill-requests/claim` |

### 13.2 量产 P0：上线前必须补齐

P0 的定义：不补齐会影响企业客户数据安全、权限边界、稳定演示或生产事故恢复。

1. 数据库正式切换：把 `BOSS_STATE_STORE=postgres` 从可选适配层推进到生产主路径，补正式 PostgreSQL 表拆分、迁移脚本、灰度开关和回滚剧本。
2. 事件账本：新增 append-only event ledger，覆盖账号、设备、权限、任务、审批、Skill、备份、Computer Use 动作和主 Agent 接管。
3. 备份恢复演练自动化：把文件快照和 Postgres 备份纳入后台“恢复演练”流程，记录演练时间、耗时、校验结果和负责人。
4. 任务调度服务化：把 `MasterAgentTask` 从状态文件轮询升级为数据库任务队列或可靠队列，支持 lease、retry、cancel、dead-letter 和 worker 心跳。
5. 企业 SSO / IdP：补 OIDC/SAML 之一，支持企业管理员配置登录策略、MFA 强制、离职回收和会话全量吊销。
6. 设备绑定与正版授权：boss-agent 绑定二维码、授权到期、许可证校验、设备换绑、离线宽限期和吊销恢复流程需要闭环。
7. 审计不可抵赖：关键操作需要稳定审计 ID、操作者、来源 IP、UA、前后快照、关联任务和导出能力。
8. 高风险审批：Computer Use、代码提交、部署、权限变更、批量 Skill 下发必须进入审批卡，不允许只靠主 Agent 自行判断。
9. 生产监控与告警：补服务端 metrics、错误率、任务积压、设备离线、API 失败、OTA 失败、备份失败和客户维度 SLA 告警。
10. 客户数据隔离验收：对所有 Web / APP / API 投影视图做租户隔离回归，确保子账号看不到未授权设备、项目、线程、Skill、日志和附件。

### 13.3 量产 P1：首批企业客户试点必须补齐

P1 的定义：不影响最小上线，但会影响试点客户规模化复制、运营效率和长期留存。

1. 管理后台企业化：平台总后台和企业自管后台进一步拆清，补租户套餐、授权席位、设备额度、用量统计、客户健康分和客户成功视图。
2. Skill 市场：支持平台 Skill、企业私有 Skill、版本签名、依赖扫描、灰度发布、回滚统计和失败率看板。
3. 业务 Agent 目录：把销售、客服、财务、HR、项目、行政、运维 Agent 做成可配置目录，并绑定 SOP、权限和数据源。
4. 进度卡增强：把 `execution_progress` 扩展为统一 task timeline，支持步骤、截图、文件变更、测试结果、审批记录和可展开过程日志。
5. Codex 协议快照：建立 `docs/protocol-snapshots/codex-app-server/`，自动比较 protocol version、capabilities、model/list、approval、skill、plugin 变化。
6. 多入口一致会话：Telegram 已有最小链路，后续补飞书、企业微信或微信生态入口，并统一权限、审计、通知和会话状态。
7. 企业知识库与长期记忆：把项目目标、版本记录、任务结果、回退点、客户 SOP 和主 Agent 记忆纳入统一版本化记录。
8. Computer Use 证据链：关键桌面动作需要截图 / 屏幕录制 / AX tree 摘要 / 操作序列留档，便于复盘和客户信任。

### 13.4 当前验证基线

截至本次文档更新，以下本地验证命令作为当前量产底座的最小回归基线：

```bash
npx tsx --test tests/device-revocation-auth.test.ts tests/master-agent-task-reliability.test.ts tests/device-import-draft.test.ts tests/ai-account-validation.test.ts tests/device-import-candidate-id-regression.test.ts tests/master-agent-task-claim-route.test.ts tests/device-execution-conflict.test.ts tests/browser-desktop-control-summary-message.test.ts tests/skill-lifecycle-route.test.ts tests/state-store-maintenance-script.test.ts tests/boss-state-store.test.ts
npm run lint
npm run build
```

本次验证结果：49 项核心测试通过，`npm run lint` 通过，`npm run build` 通过。

## 14. 90 天量产试点路径

PPT 第 10 页给出的 90 天路径进入后续 To B 交付方法论。

### 阶段 1：0-30 天

目标：选择 1-2 个高频流程，搭好企业账号、权限、设备和数据接入基础。

交付：

- 梳理老板、经理、员工权限。
- 选择高频、规则清晰、跨系统搬运多的流程。
- 接入关键系统和数据，如 CRM、ERP、财务、OA、知识库。
- 接入真实电脑和本地 Agent。

### 阶段 2：31-60 天

目标：部署主 Agent 和 2-3 个业务 Agent，跑真实任务。

交付：

- 主 Agent 统筹，业务 Agent 执行具体流程。
- 建立审批、审计、异常处理和权限边界。
- 跑通真实任务并持续优化 SOP。
- 形成可复制配置模板。

### 阶段 3：61-90 天

目标：接入经营看板，评估效率和复制条件。

交付：

- 实时展示任务进度、效率指标和业务价值。
- 评估从发起到结果的整体响应时间。
- 评估人工汇总减少、流程稳定性和复制条件。
- 输出下一部门复制方案。

成功标准：

- 可持续执行。
- 可审批。
- 可追踪。
- 可复制。

## 15. 产品开发优先级

第一优先级：稳定和治理。

- 数据库正式替换文件状态。
- append-only 事件账本。
- 自动备份和恢复演练。
- 业务级回退。
- 主 Agent 任务取消、接管关闭和主动任务清理。当前已有任务 cancel / timed_out 底座，仍需数据库队列化和 dead-letter。
- 设备离线、执行失败、审批超时进入风险台。

第二优先级：Codex App Server 深度接入。

- App Server provider adapter。当前已有第一批 runner，仍需协议快照、能力清单和 streamed events 完整映射。
- Thread / Turn / Item 映射。
- Approval card 映射。
- streamed events 进入进度卡。
- skills/list、model/list、plugin/list 进入能力清单。
- 协议快照和兼容测试。

第三优先级：企业协作网络。

- 老板端、经理端、员工端权限视图。
- 业务 Agent 目录和 SOP。
- 部门/项目维度执行闭环。
- Skill 企业分配和跨设备同步。
- 平台总后台风险与客户成功视图。

第四优先级：前瞻扩展。

- Telegram、飞书、微信、Web、APP 多入口一致会话。
- 自研 Computer Use 与 Codex Computer Use 并存。
- 多 provider 智能路由。
- 企业知识库和长期记忆。
- 自动复盘、流程优化和策略建议。

## 16. 非协商性原则

- 不允许把系统提示词、内部 prompt、设备 token、API key、工作目录调度说明写进用户可见消息。
- 不允许主 Agent 在用户取消接管后继续主动向线程发起任务。
- 不允许没有审计记录的高风险操作。
- 不允许没有回退点的批量权限、Skill、数据或代码变更。
- 不允许把 Codex 当前某个版本的协议字段直接作为 Boss 业务事实源。
- 不允许把过程噪音当作未读消息。
- 不允许让企业子账号看到未授权设备、项目、Skill 或线程上下文。

## 17. 下一步落地清单

1. 输出 PostgreSQL 正式 schema 设计：账号、企业、设备、项目、线程、消息、任务、审批、事件账本、审计、备份、Skill。
2. 把 `MasterAgentTask` 调度从文件状态轮询迁到可靠队列或数据库任务表，并保留现有 lease / retry / cancel 语义。
3. 新增 `docs/protocol-snapshots/codex-app-server/` 目录规范和兼容测试。
4. 把 `execution_progress` 进度卡扩展成统一 task timeline。
5. 把项目目标、版本记录、任务结果和回退点纳入同一套版本化记录。
6. 为平台总后台增加恢复演练、租户风险、设备离线、主 Agent 失败和任务积压看板。
7. 为 Skill 治理增加签名、依赖扫描、灰度发布和失败率统计。
8. 为 boss-agent 增加企业正版授权、授权到期提醒、离线宽限和设备换绑流程。