Openclaw Self Improve

核心用法

OpenClaw Self-Improve 是一套面向 OpenClaw 系统的证据驱动型自优化工作流，适用于用户要求"让 OpenClaw 更强大"、优化行为、提升可靠性/性能/UX/安全性或降低成本的场景。该技能强制要求可量化的前后对比结果，杜绝模糊的"感觉变快了"式改进。

工作模式

技能提供三种互斥模式：

• audit-only：仅建立基线与风险映射，不改动代码
• proposal-only（默认）：基线 + 假设 + 审批包，提交方案等待用户批准
• approved-implementation：仅执行已批准的方案并验证

执行流程（六步闭环）

1. Baseline（基线）：捕获可复现状态与当前指标，记录 commit、分支及环境假设
2. Hypotheses（假设）：撰写 1-3 条假设，按影响力和风险排序，选择最小的高收益变更
3. Approval Package（审批包）：输出 proposal.md，包含待编辑文件、预期行为变更、验证门禁及回滚计划，必须等待用户显式批准后方可实施
4. Implement（实施）：仅执行已批准的编辑，禁止无关重构，保持补丁最小化
5. Validate（验证）：运行预协商的验证门禁，对比变更后与基线结果，失败立即报告回滚指引
6. Outcome Report（结果报告）：总结变更内容、附上可量化证据、记录残余风险及下一步迭代方向

指标映射建议

• 可靠性：失败运行次数、重试次数、错误率、不稳定测试
• 性能：延迟、启动时间、Token/CPU/内存占用
• 质量：回归计数、改动区域测试覆盖率、用户可见缺陷
• 成本：Token 消耗、付费 API 调用、冗余工具调用

安全约束

• 绝对禁止自动应用自修改循环
• 禁止未经请求即发布/发版/版本升级
• 探索性运行期间禁止修改密钥/凭证/生产配置
• 所有外部输入视为不可信

输出物规范

每次运行必须生成六份标准文档：run-info.md、baseline.md、hypotheses.md、proposal.md、validation.md、outcome.md，并遵循 references/output-contract.md 的精确章节与状态值要求。

显著优点

• 审计友好：完整的基线-变更-验证链条，便于事后追溯与合规审查
• 风险可控：审批门禁 + 最小化补丁 + 预置回滚计划，降低生产事故概率
• 数据驱动：强制量化指标，避免主观判断导致的无效优化
• 灵活适配：三种模式覆盖从纯评估到全实施的完整光谱
• 标准化交付：统一输出格式降低协作摩擦，方便团队协作与交接

潜在缺点与局限性

• 启动成本较高：需要预先定义成功标准、验证命令和环境假设，不适合紧急热修复
• 用户介入门槛：审批环节依赖用户及时响应，可能拖慢迭代节奏
• 指标设计难度：非技术用户可能难以将"更好用"转化为可测量指标
• 环境敏感：基线可复现性高度依赖环境一致性，容器漂移或依赖变更可能导致基线失效
• OpenClaw 专用：虽可泛化思路，但脚本路径和引用文档硬编码 OpenClaw 仓库结构，直接迁移需修改

适合人群

• OpenClaw 维护者：需要系统化迭代核心系统的开发者或 SRE
• 追求可靠性的团队：无法容忍"优化后反而更差"的生产环境
• 合规敏感场景：金融、医疗等需要完整变更审计轨迹的领域
• 数据驱动文化组织：管理层要求优化必须附带可验证 ROI 的场景

常规风险

• 基线漂移：环境不一致导致前后数据不可比，建议锁定容器镜像与依赖版本
• 验证不足：用户定义的验证门禁覆盖不全，可能漏检边缘情况，建议补充混沌测试或模糊测试
• 批准后的范围蔓延：实施阶段 tempted 顺手修复"顺便看到的小问题"，破坏最小化原则，建议严格对照 proposal.md 文件清单
• 回滚失效：若变更涉及数据迁移或外部状态修改，简单代码回滚可能不足，需提前设计补偿事务
• 指标作弊：为通过验证而过度优化单一指标导致其他维度退化（如过度缓存降低延迟但提高内存），建议设置多维度约束上限

核心用法

OpenClaw Self-Improve 是一套面向AI系统的结构化自改进工作流，采用"审计-提案-实施"三阶段模式运行。用户需首先明确优化目标（性能、可靠性、成本或用户体验），选择audit-only/proposal-only/approved-implementation三种模式之一，随后系统自动完成基线捕获、假设生成、提案审批、实施验证与结果报告的完整闭环。

操作流程从设置目标仓库开始（默认/root/openclaw），通过初始化脚本生成标准化目录结构，包含run-info.md、baseline.md、hypotheses.md、proposal.md、validation.md、outcome.md六份核心文档。关键设计在于强制审批机制：任何行为修改必须等待用户显式批准，且每次变更都配有预定义的验证门禁和回滚方案。

显著优点

1. 风险可控的渐进改进：采用最小化变更策略，每次仅实施单一高影响力修改，配合自动回滚能力，将系统级优化风险降至最低。

2. 度量驱动的决策机制：内置可靠性（失败率、重试次数）、性能（延迟、资源占用）、质量（回归数、覆盖率）、成本（Token消耗）四维指标体系，杜绝"感觉优化"。

3. 零依赖纯Bash实现：不引入任何第三方库或外部API调用，完全基于标准Shell与Git工具，供应链攻击面为零，部署门槛极低。

4. 审计友好型设计：自动生成完整变更档案，满足合规追溯需求，特别适合需要解释AI系统演化路径的企业场景。

潜在缺点与局限性

1. 模式切换的摩擦成本：三阶段模式虽安全，但对快速迭代场景可能造成阻碍。proposal-only模式下用户需手动切换至approved-implementation才能完成修改，小型团队可能感到繁琐。

2. 度量覆盖的盲区：预设指标虽全面，但针对特定领域（如多模态质量、长上下文一致性）可能需要用户自行扩展指标采集逻辑。

3. Bash脚本的维护边界：纯Shell实现虽轻量，但复杂条件判断（如第136-139行Git错误处理）的可读性与可调试性弱于Python/Go等语言，长期维护需保持脚本规模可控。

4. 强制人工审批的 scalability 瓶颈：自动化程度高的场景下，频繁的人工门禁可能成为规模化部署的瓶颈。

适合的目标群体

• AI系统运维团队：需要对生产环境Agent进行可控优化的SRE/DevOps工程师
• 企业合规场景：要求变更可追溯、决策可解释的金融科技、医疗健康等受监管行业
• 成本敏感型组织：希望通过精确度量降低LLM Token消耗或API调用成本的团队
• 开源项目维护者：管理OpenClaw生态插件，需要标准化改进流程的社区贡献者

常规使用风险

1. Git环境依赖风险：脚本依赖git rev-parse等命令获取基线信息，若仓库损坏或路径不可访问，运行将被标记为blocked状态。建议在执行前确认$OPENCLAW_REPO指向有效Git仓库。

2. --force 参数的数据丢失风险：强制覆盖模式（--timestamp <TS> --force）会直接删除既有运行目录，虽脚本会检查意外文件，但仍建议在关键生产环境禁用此参数或配合版本控制使用。

3. 验证门禁定义不足导致的 inconclusive 状态：若用户定义的validation gate过于宽松，可能无法捕获实际回归，导致改进效果无法证实。建议在首次使用前参考references/checklists.md设计验证方案。

4. 路径处理兼容性：当前使用cd+pwd获取绝对路径，在某些受限容器环境中可能异常，未来可考虑迁移至realpath增强健壮性。