# Boss 外部执行生态融合方案 这份文档定义 Boss 与两个外部项目的统一融合策略： - `claw-code` - `oh-my-codex` 目标不是把外部项目直接写死进 Boss，而是在 Boss 现有产品主链保持稳定的前提下，引入可升级、可替换、可回退的执行底座与编排能力，让 Boss 能持续吸收外部 runtime 和 orchestration 的迭代成果。 --- ## 1. 总结论 采用统一的“三层融合”方案： 1. **Boss 保留产品层** 2. **`claw-code` 作为执行内核候选** 3. **`oh-my-codex` 作为编排增强层** 一句话概括： - Boss 负责整车 - `claw-code` 负责发动机候选 - `oh-my-codex` 负责多 worker 编排和变速系统 ### 1.1 不做的事 明确不做： - 不把 `claw-code` 或 `oh-my-codex` 整仓直接 vendoring 进 Boss 作为主实现 - 不让 Boss 的 Web / Android 前台直接理解外部 runtime 的内部概念 - 不把群聊、审批、设备导入、多租户这类 Boss 核心业务逻辑下沉到外部项目 - 不让外部项目反向塑形 Boss 的产品结构 ### 1.2 要做的事 明确要做： - 在 Boss 内部先抽一层稳定执行抽象 - 用适配器接入 `claw-code` - 用独立编排适配器接入 `oh-my-codex` - 通过 checkpoint 升级机制持续吸收上游更新 --- ## 2. 为什么要统一规划，而不是分别硬接 Boss 当前已经有一条完整但复杂的产品主链： - Web - Android - 多租户 - 会话 / 群聊 / 审批 - 设备导入 - 主 Agent - 提示词 / 记忆 - 文件账本与聚合投影 而外部两个项目的强项并不相同： ### 2.1 `claw-code` 的价值 更适合提供： - runtime - session - tool registry - permission model - remote runtime 抽象 - 可恢复执行语义 它的优势在“执行内核”。 ### 2.2 `oh-my-codex` 的价值 更适合提供： - 多 worker 编排 - mailbox - dispatch lock - approvals - team runtime - tmux / worktree 驱动的 durable coordination 它的优势在“编排层”。 如果分别直接硬接： - Boss 会同时被两个上游内部结构牵动 - 维护成本会迅速升高 - 运行时边界会变得模糊 所以必须先由 Boss 定义自己的稳定抽象层，再接两个外部后端。 --- ## 3. 三者分工 ### 3.1 Boss 负责的部分 Boss 永远继续负责： - 多租户与账号体系 - Web 与 Android 前台 - 会话模型 - 项目归档与线程下钻 - 群聊 - 审批流 - 设备导入 - 提示词与记忆数据归属 - 账本、聚合投影与事件流 - OTA 与移动端分发 ### 3.2 `claw-code` 负责的部分 `claw-code` 只适合承载： - 单次执行 runtime - 会话级执行状态 - tool execution contract - permission enforcement - remote runtime adapter - 长任务恢复语义 定位：**执行内核候选**。 ### 3.3 `oh-my-codex` 负责的部分 `oh-my-codex` 只适合承载： - 并行 worker 编排 - team state - mailbox / approvals / dispatch locks - durable multi-agent runtime - worktree / tmux 协作执行 定位：**编排增强层**。 --- ## 4. Boss 内部必须先抽出来的稳定接口 在真正接任何外部项目之前，Boss 先抽一组内部稳定接口。 ### 4.1 ExecutionBackend 职责： - 统一描述“谁来执行一次任务” 建议能力： - `executeTask` - `resumeTask` - `cancelTask` - `getExecutionStatus` 候选实现： - `MasterCodexNodeBackend` - `OpenAIBackend` - `AliyunQwenBackend` - `ClawBackendAdapter` ### 4.2 SessionRuntime 职责： - 统一描述运行态会话 建议能力： - create - resume - compact - inspect - close ### 4.3 PermissionPolicy 职责： - 统一描述某次任务允许哪些工具、哪些行为、是否需要审批 建议覆盖： - 工具级权限 - 下发权限 - 群聊协作模式 - approval_required 闸口 ### 4.4 ToolRegistry 职责： - 统一描述 Boss 对外声明和下发的工具能力 未来来源可包括： - Boss 自己的内建工具 - `claw-code` 的 tool surface - `oh-my-codex` 的 workflow/skill surface ### 4.5 PromptAssembler 职责： - 统一组装主 Agent 与线程执行时的提示词输入 必须覆盖： - 管理员全局主提示词 - 用户私有主提示词 - 当前对话附加提示词 - 用户通用记忆 - 项目记忆 - 运行时上下文 ### 4.6 MemoryResolver 职责： - 按当前任务和项目筛选真正需要注入的记忆 ### 4.7 RemoteRuntimeAdapter 职责： - 统一接不同设备上的远程执行能力 当前已有来源： - `local-agent -> codex exec resume` 未来可扩： - `claw remote runtime` - `omx team runtime` ### 4.8 OrchestrationBackend 职责： - 统一承载“多线程 / 多 worker / 群聊分发”级别的编排能力 候选实现： - `BossNativeOrchestrator` - `OmxTeamBackendAdapter` --- ## 5. 推荐目标架构 推荐调用链如下： ```text Boss Product Layer -> Boss Domain Services -> Execution/Prompt/Permission Abstraction Layer -> Backend Selector -> MasterCodexNodeBackend -> OpenAIBackend -> AliyunQwenBackend -> ClawBackendAdapter -> Orchestration Selector -> BossNativeOrchestrator -> OmxTeamBackendAdapter ``` ### 5.1 关键原则 1. Boss 业务层不直接调用外部仓库私有代码结构 2. 外部项目只能通过 adapter 层进入 Boss 3. 单线程执行和多线程编排要分成两类 backend 4. 前台页面只感知 Boss 自己的业务语义，不感知外部 runtime 术语 --- ## 6. 推荐接入顺序 ### 第一阶段：重构 Boss 执行底座抽象层 目标： - 只做内部重构 - 不改变当前生产主链 范围： - `ExecutionBackend` - `PermissionPolicy` - `ToolRegistry` - `PromptAssembler` - `MemoryResolver` - `RemoteRuntimeAdapter` - `OrchestrationBackend` 目的： - 先把 Boss 自己的结构理顺 - 避免后面接外部项目时边接边重构 ### 第二阶段：接 `ClawBackendAdapter` 目标： - 把 `claw-code` 接成一个可选执行后端 先支持： - session create / resume - tool permission handoff - remote runtime selection - result normalization 不先支持： - 群聊审批主链 - 设备导入主链 - 多租户关键主链默认切换 定位： - 受控实验 backend - 可运行、可验证、可对比 ### 第三阶段：接 `OmxTeamBackendAdapter` 目标： - 把 `oh-my-codex` 接成可选编排后端 优先适用场景： - 多线程协作 - 长任务 - 需要 durable worker state 的任务 - 复杂群聊 dispatch 不建议一上来就用它替代普通单线程执行。 ### 第四阶段：形成统一调度策略 Boss 再根据任务特征自动选择后端： - 单线程任务：优先执行 backend - 群聊复杂协作：优先 orchestration backend - 高风险审批任务：优先 Boss 原生审批流 --- ## 7. 哪些能力适合先借 ### 7.1 从 `claw-code` 先借 优先级最高： 1. runtime / session contract 2. execution registry 3. permission context 4. remote runtime adapter 原因： - 这些能直接提升 Boss 当前执行底座稳定性 - 不会立刻冲击前台产品模型 ### 7.2 从 `oh-my-codex` 先借 优先级最高： 1. approvals 2. mailbox 3. dispatch-lock 4. worktree-aware worker coordination 原因： - 这些非常契合 Boss 现有群聊、审批、线程调度主链 - 但更适合作为编排层，而不是执行内核 --- ## 8. 哪些能力不要直接借 ### 8.1 不要直接借 `claw-code` 的部分 - 整体 CLI 产品壳 - 直接面向终端用户的 slash command 产品模型 - 直接绑定它当前仓库私有状态布局 ### 8.2 不要直接借 `oh-my-codex` 的部分 - 直接把 tmux/worktree/runtime 概念暴露给 Boss 终端用户 - 直接把 `.omx/` 状态目录作为 Boss 账本 - 让 `team` 机制替代 Boss 自己的产品审批与群聊模型 --- ## 9. 升级策略 ### 9.1 总原则 Boss 不追“任意最新 main”，只做 checkpoint 升级。 ### 9.2 上游跟踪方式 需要长期维护两类信息： 1. `claw-code` 更新观察 - runtime - permissions - tools - OAuth - remote runtime 2. `oh-my-codex` 更新观察 - team runtime - approvals - mailbox - worktree - dispatch orchestration ### 9.3 升级流程 每次升级时固定执行： 1. 拉取上游代码 2. 评估契约变化 3. 检查 adapter breakage 4. 更新 adapter 5. 跑 Boss 自己的验证矩阵 6. 通过后再提升使用范围 ### 9.4 验证矩阵 至少覆盖： - 主 Agent 单聊 - 普通线程单聊 - 群聊 dispatch - approval_required - 设备导入 - 提示词与记忆 - 主控切换与备用链回退 --- ## 10. 风险 ### 10.1 技术风险 - `claw-code` 仍在快速变化，Rust 线可能继续重构 - `oh-my-codex` 的 runtime/state 机制也会持续演进 - 直接依赖其私有文件布局会让 Boss 非常脆弱 ### 10.2 产品风险 - 如果前台直接承载外部 runtime 概念，会破坏 Boss 当前产品心智 - 如果太早把生产主链切给外部后端，群聊/审批/导入可能被拖坏 ### 10.3 维护风险 - vendoring/fork 会让升级成本指数上升 - 没有 adapter contract 的情况下，任何上游变动都会扩散到 Boss 业务层 --- ## 11. 推荐最终路线 当前推荐路线非常明确： 1. 先完成 Boss 执行底座抽象层重构 2. 先接 `ClawBackendAdapter` 3. 再接 `OmxTeamBackendAdapter` 4. 初期都作为可选后端，不替代默认生产主链 5. 形成 checkpoint 升级机制，而不是写死版本 --- ## 12. 验收标准 只有满足下面条件，才算这条融合路线设计正确： 1. Boss 产品层不直接依赖外部仓库私有目录结构 2. 升级 `claw-code` 或 `oh-my-codex` 时，主要改动只在 adapter 层 3. Boss 主链不因为外部 runtime 变化而被动重构 4. 单线程执行与多线程编排明确分层 5. 前台仍然只暴露 Boss 自己的产品语义 6. 外部项目可以持续升级，而 Boss 不会被写死在某个旧版本上 --- ## 13. 后续文档建议 这份总方案之后，建议拆出 3 份后续设计文档： 1. `Boss 执行底座抽象层重构` 2. `ClawBackendAdapter 最小接入设计` 3. `OmxTeamBackendAdapter 编排接入设计` 在这 3 份文档完成前，不建议直接开始把 `claw-code` 或 `oh-my-codex` 接入当前生产主链。