2026-09-21 智能体系统从 OpenClaw 迁移到 Codex 方案

旭东 → OpenClaw：

我现在有一个需求，想要把整套智能体开发从openclaw转移到codex上面，怎么样转移才能保证智能体系统正常运转不会出错？给我一个方案

OpenClaw 响应：

已完成方案编制，并落成文档 reports/2026-09-21-openclaw-to-codex-migration-plan.md。核心结论如下：

一、前提判断：整套平移不存在

Codex CLI 是编码代理（coding agent），OpenClaw 是代理平台（agent platform），两者只在「读文件 + 调模型 + 跑命令 + MCP」这一层有交集。

Codex 侧完全没有对应物的层：通道层（钉钉 4 个机器人长连接与收发）、调度层（自动化任务宿主）、多代理层（机器人→代理路由绑定）、记忆层（memory-core 与 dreaming）、技能层（SKILL.md 自动注入）、控制面（Control UI / dashboard）。

二、实测盘点里最值钱的两个发现

195 个配置代理，真正在跑的只有 4 个（采购助手、数据处理助手、数据处理工作助手、工作助手各绑一个钉钉机器人），其余 191 个是未启用的角色模版，直接丢弃。
203 个自动化任务，真正要迁的只有 9 个；其余约 190 个是 skill-collection-review-* 每周自动生成的技能合集复审，无业务价值，建议直接删除。

三、两个方案

方案 A（推荐）：Codex 当大脑，OpenClaw 保留外壳（通道 + 调度 + 多代理 + 审批）。迁移对象只有「代理怎么思考干活」这一层，3–5 天、零停机、出问题切回原生模型即可。
方案 B（完全替换）：Codex + 自建钉钉桥接 + systemd 定时器。需自建 4 个组件（桥接服务、8 个 timer、会话映射存储、失败告警），2–4 周，运维责任完全转移到自有团队。现成的 dws CLI 是桥接层的关键，收发不必从零写。

四、分阶段与门禁

Phase 0 冻结备份 → Phase 1 Codex 单机跑通（只读任务对齐）→ Phase 2 造替代外壳（仅方案 B）→ Phase 3 影子运行 → Phase 4 按任务逐个切换 → Phase 5 退役。每阶段均设验证门禁与回滚路径。

五、两条必须守住的铁律

六、明确不做

不碰 11.79 生产、不碰云端、不动 dy-dashboard 代码与 MySQL、不迁 161MB 历史会话库、不迁 191 个未启用代理、不迁 190 个噪音任务。方案不含任何部署动作。

后续建议：先按方案 A 走 Phase 1（装 Codex、指向现有工作区、跑 3 个只读任务做同提示词对齐），用实测输出质量决定是否继续。

旭东 → OpenClaw：

现在帮我查询一下智能体现在的代码路径在哪里？

OpenClaw 响应：

已实测列出完整路径图（平台运行时、全局配置、4 个代理的状态目录与工作区、钉钉连接器插件源码、CLI 工具、技能目录、dy-dashboard 业务项目、知识库）。关键路径：

平台运行时：/home/gxd/.npm-global/lib/node_modules/openclaw（360M，2026.9.4）
全局配置：/home/gxd/.openclaw/openclaw.json（61 KB）
代理状态：/home/gxd/.openclaw/agents/<代理>/agent（采购助手 155MB 会话库）
代理工作区：/home/gxd/.openclaw/workspace/<代理>
钉钉插件源码：/home/gxd/.openclaw/extensions/dingtalk-connector（292M，@dingtalk-real-ai/dingtalk-connector 0.8.25）
dws CLI：/home/gxd/.npm-global/lib/node_modules/dingtalk-workspace-cli/bin/dws.js
业务项目：/home/gxd/.openclaw/workspace/dy-dashboard（gunicorn 端口 18888 运行中）
知识库：/home/gxd/蝶雅供应链