背景
当前 OpenClaw 长期采用单主控 Agent（main）承接几乎所有任务，问题主要有三类：
- 职责耦合：RSS、研究、邮件、监控都压在 main，维护成本持续上升。
- 风险集中：某一类任务异常可能影响整条链路。
- 可扩展性弱：新增能力时容易改动主流程，回归成本高。
本次目标是在不引入源码管理的前提下，完成一次可回滚的多 Agent 重构。
目标架构
采用 1 总控 + 4 专家的中枢编排：
- main：总控编排、对外回复、路由与聚合
- rss：RSS 抓取、归档、摘要
- research：信息检索与交叉验证
- mail：邮件轮询、分类与上报
- heartbeat：健康巡检与告警
拓扑图
设计原则：外部入口统一，内部按职责分治。
实施摘要
Phase 0：三层备份（强制）
在改动前做了三层备份，并做了解压演练：
- 配置层：openclaw.json、cron/jobs.json、exec-approvals.json
- 工作空间层：workspace、workspace-rssmanager、agents/*/agent
- 运行态层：sessions、cron/runs、logs
结论：备份可用，支持一键回滚。
Phase A：冻结与基线采集
- 记录改造前 agent 清单
- 记录现有 jobs 归属
- 确认旧网关状态
Phase C：创建新 Agent 与 Core Files 标准化
新增 Agent：research、mail、heartbeat。
关键动作：统一补齐每个 Agent 的 7 个 Core Files。
Core Files 标准：
同时保证每个 workspace 都有 memory/YYYY-MM-DD.md。
实际经验：OpenClaw Web 控制台对 Core Files 的可见性很强，文件是否齐全直接影响后续运维体验。
Phase D：模型分层
最终落地策略采用“可用优先”，避免上线失败：
- main -> 当前稳定主模型
- rss -> gemini-3.1-pro-preview
- research -> gpt-5-mini
- mail -> gpt-5-mini
- heartbeat -> qwen-plus
说明：原计划中的部分模型在当前环境不可确认可用，因此优先使用可验证模型。
Phase E：权限分层
对 exec-approvals.json 做了最小权限划分：
- main 拥有 channels.send、cron.trigger、agents.invoke
- specialists 默认不直接对外发送
- heartbeat 允许有限通道告警
Phase F：任务重构
- 原 4 条 RSS 任务从 main 迁移到 rss
- 新增两条任务模板：
- Heartbeat Health Check (every 5m)
- Mail Inbox Poll (every 15m)
上线策略：默认禁用新增任务，避免直接引入未知风险。
Phase G：上线验证
完成以下检查：
- gateway status：RPC probe ok
- agents list：5 个 Agent 全部可见
- channels status --probe：主要通道可用
- cron 配置：任务归属符合预期
- doctor --repair：修复服务入口与 PATH 风险
关键结果
已达成
- 完成从 2 Agent 到 5 Agent 的结构升级
- 建立了可复用的 Core Files 初始化规范
- 建立了职责分明的 cron 归属策略
- 网关服务改为更稳定的启动入口
- 具备可回滚能力与回归验证清单
当前保守上线状态
- Heartbeat 任务：已启用
- Mail 任务：保持禁用（观察后再启）
踩坑与经验
1) CLI 文档与实际行为不总是一致
最初按“半交互”设计，后续验证发现 add 命令可通过参数非交互执行。
建议：优先实测命令，再写 runbook。
2) Doctor 修复后必须回归验证
doctor --repair 可能改写配置。
建议：每次修复后执行四项回归：agents、approvals、cron、gateway。
3) 新任务先禁用再灰度
直接启用多条新任务会增加故障定位难度。
建议：先启 heartbeat，观察稳定后再启 mail。
4) Core Files 是多 Agent 的“可运维基线”
不仅是文档，更是行为边界和协作契约。
可复用的下次实施模板
30 分钟版本（建议）
- 备份 + 演练恢复（10 分钟）
- 新增 Agent + Core Files 初始化（8 分钟）
- 模型/权限/任务落地（8 分钟）
- 网关重启与验证（4 分钟）
极简检查清单
- 备份文件可解压
- agents list 包含目标 Agent
- 每个 workspace 有 7 个 Core Files
- cron 归属按职责拆分
- gateway RPC probe ok
- channels probe 正常
风险与回滚建议
建议保留
- 最近一次全量备份目录
- openclaw.json.pre-model
- exec-approvals.json.pre-perms
- cron/jobs.json.pre-reorg
建议回滚触发条件
任一条件满足即回滚：
- gateway 无法稳定启动
- channels 探测连续失败
- cron 触发异常导致主链路不可用
- Agent 路由出现跨职责误调用
后续优化路线
- 清理插件冲突：处理 openclaw-lark 与 feishu 重复注册告警
- 为 main 增加更细粒度的路由策略（按任务类型而非仅按渠道）
- 增加多阶段告警等级（info/warn/critical）
- 给 mail 任务补充白名单与去重策略
- 将 runbook 固化为自动化脚本 + CI 检查项
结语
这次改造的核心不是“加了几个 Agent”，而是把系统从“单点聪明”升级为“结构可靠”。
在无源码管理环境里，最重要的是：
- 先可回滚，再做变更
- 先灰度，再全量
- 先验证，再宣布完成
只要这三条守住，多 Agent 架构会越跑越稳。