OpenClaw实战指南：RAG+多智能体+DevOps深度集成

1. OpenClaw 不是“装完就跑”的玩具，而是你工作流里那个沉默但永远在线的副驾驶

很多人第一次听说 OpenClaw，是在某个 DevOps 群里看到一句：“刚在群晖上跑起来了，命令行敲两下就出来个 agent。”然后截图一张终端里绿色文字滚动的界面，底下配文：“AI 编程真香。”——这画面我见过太多次。但三个月后回访，八成的人已经把它关在 Docker 容器里，再没动过。不是它不好，是他们根本没搞懂：OpenClaw 的核心价值，从来不在docker-compose up -d那一下的爽感，而在于你每天打开 IDE、写测试用例、查线上日志、回客户邮件时，它能不能主动递给你那张“刚刚好”的知识卡片，或者替你把重复三遍的部署脚本生成出来，再顺手校验一遍 YAML 缩进。

这不是一个“AI 工具安装教程”，而是一份来自真实产线的 OpenClaw 使用地图。我过去 11 个月，在三个不同规模的技术团队（一家 SaaS 初创、一家传统金融中台、一家硬件 IoT 厂商）里，把 OpenClaw 深度嵌入到 CI/CD 流水线、专利文档协同、RAG 知识库运维、多智能体任务分发等场景中。过程中踩过的坑、调优的参数、绕开的 SDK 陷阱、甚至和飞书/微信/钉钉 API 对接时被吞掉的 401 错误码，我都记在了这张地图上。它不教你怎么git clone，只告诉你：当你的 Jenkins Pipeline 卡在“等待测试报告上传”时，该让哪个 Skill 触发、传什么上下文、怎么把失败堆栈喂给 RAG 引擎、又如何让另一个 Agent 自动拉起本地 Selenium 环境重跑——这才是 OpenClaw 的真实心跳。

关键词里没有“安装”，因为安装真的只是 15 分钟的事；关键词里反复出现“RAG”“多智能体”“DevOps”，是因为这三个词，构成了 OpenClaw 在现实世界落地的铁三角。RAG 是它的记忆，多智能体是它的手脚，DevOps 是它呼吸的节奏。下面这 29 个用例，全部来自我们团队正在运行的生产环境，每一个都附带了触发条件、Skill 组合逻辑、RAG 数据源类型、以及最关键的——它省下了多少人工小时。你可以跳着看，但建议从第 3 个开始，那是我们第一个真正“甩开鼠标”的用例。

2. RAG 不是知识库，是 OpenClaw 的“短期记忆+长期经验”混合体

2.1 为什么你搭的 RAG 总是召回不准？根源在 chunking 策略，而不是模型

绝大多数人部署 OpenClaw 后的第一步，是往rag/目录里扔一堆 PDF 和 Markdown。然后发现：问“Spring Boot 如何配置多数据源”，它返回的是《Java 并发编程实战》第 7 章的片段。这不是模型不行，是你没告诉 OpenClaw——哪些文本是“操作手册”，哪些是“原理白皮书”，哪些是“故障排查 Sop”。我们试过三种 chunking 方式：

  • 按文件粒度切分（默认）：整个 PDF 当作一个 chunk。问题：PDF 里混着目录、版权页、附录，模型注意力全被噪声吃掉。
  • 按标题层级切分（推荐）：用pandoc预处理 PDF，提取 H1/H2/H3 标题，每个标题下的正文为一个 chunk。例如《K8s Ingress 配置指南》这个 H2 下的所有内容，单独成 chunk。实测召回准确率从 41% 提升到 79%。
  • 按语义段落切分（高阶）：用langchain.text_splitter.RecursiveCharacterTextSplitter，但关键参数不是chunk_size=512，而是separators=["\n\n", "\n", ".", "!", "?"]+keep_separator=True。这样能保留“.”前后的主谓宾结构，避免把“spring.datasource.url=jdbc:mysql://...”这种关键配置项硬生生劈成两半。

提示：OpenClaw 的 RAG 引擎默认使用chroma向量库，但它对中文分词支持弱。我们强制在config.yaml里加了一行embedding_model: bge-m3-zh，并用jieba做了预分词注入。这一步让“微服务熔断阈值设置”这类长尾查询的召回延迟从 2.3s 降到 0.6s。

2.2 RAG 数据源不是越多越好，而是要分“角色”喂养

我们给 RAG 设计了三层数据源，每层对应不同 Skill 的调用权限：

数据源类型存储位置典型内容访问 Skill更新频率特点
SOP 层rag/sop/Jenkins Pipeline 脚本模板、Ansible Playbook 片段、Dockerfile 最佳实践devops-deploy-skill每周人工审核更新纯代码+注释，无解释性文字，chunk size=128
知识层rag/kb/内部 Wiki 截图转 Markdown、RFC 文档摘要、Spring AI 2.0 新特性对比表tech-qa-skill实时 webhook 同步含图表、表格、版本号，chunk size=512，启用bge-m3-zhembedding
案例层rag/case/过去 6 个月线上 P0 故障的根因分析、客户投诉邮件原文+技术回复草稿、专利审查意见答复范例incident-resolve-skill每日自动抓取 Jira/飞书日志高度口语化，含时间戳、人名、系统 ID，chunk size=256，启用m3e-baseembedding

这个分层不是为了炫技，而是解决一个实际问题：当devops-deploy-skill执行部署时，它只需要看 SOP 层的 YAML 模板，如果混入知识层的 RFC 解释，反而会干扰它生成精准命令。我们通过skill_config.yaml里的allowed_rag_sources: ["sop"]字段做了硬隔离。

2.3 RAG 投喂不是“扔进去就完事”，必须带“元标签”和“时效戳”

OpenClaw 的 RAG 支持自定义 metadata，但我们发现 90% 的用户根本没用。结果就是：问“当前生产环境 Kafka 版本是多少？”，它可能从一份 2022 年的架构文档里翻出kafka_2.13-3.1.0，而实际已是3.6.1。我们的解法是：所有投喂进 RAG 的文件，必须带两个强制字段：

# 文件头示例（放在每个 Markdown 文件最顶部） --- source: jenkins-job-config-prod updated_at: "2024-05-22T14:30:00+08:00" valid_until: "2024-08-22T14:30:00+08:00" tags: [prod, kafka, config] ---

然后在rag_config.yaml里配置过滤规则：

retrieval_filter: - field: "valid_until" operator: ">" value: "{{ now }}" - field: "tags" operator: "contains" value: "prod"

这套机制让我们在一次数据库迁移中，自动屏蔽了所有标注valid_until: "2024-03-01"的旧版 SQL 脚本，避免了人为遗漏。

3. 多智能体不是“多个 agent 一起跑”，而是“有指挥链、有责任边界的协作网络”

3.1 为什么你的多 agent 总是陷入死循环？因为你没定义“终止条件”和“兜底出口”

看过太多人写这样的流程：Agent A 查日志 → 发给 Agent B 分析 → B 说需要更多上下文 → A 又去查监控 → B 再分析……最后卡在无限递归里。OpenClaw 的多智能体协作，本质是状态机驱动的有限状态流转，不是自由对话。我们定义了四个刚性规则：

  1. 单次任务最大跳转次数 = 3：在multi_agent_config.yaml中设max_hops: 3，超限自动触发fallback-skill。
  2. 每个 Agent 必须声明输出 Schema：比如log-analyzer-agent的输出必须是 JSON，含{"root_cause": "string", "affected_services": ["string"], "suggested_fix": "string"}。OpenClaw 会在调用前做 schema 校验，不匹配直接报错，不往下传。
  3. 所有跨 Agent 调用必须带 trace_id：通过context.inject_trace_id()注入，这样在 Grafana 里能看到完整调用链，哪个环节耗时异常一目了然。
  4. 兜底出口必须是人工介入点：fallback-skill的最终动作不是重试，而是向飞书机器人发送一条带@负责人的消息，并附上当前所有中间产物（日志片段、监控截图、RAG 召回结果）。我们规定：任何任务进入 fallback，必须在 15 分钟内有人响应，否则升级告警。

这套规则让我们把平均故障定位时间（MTTD）从 47 分钟压到 11 分钟。最关键的是，它让工程师从“救火队员”变成了“流程审计员”——他们不再盯着终端刷日志，而是看飞书里 OpenClaw 自动生成的故障摘要，快速判断是否需要介入。

3.2 多智能体的 Skill 组合，不是功能叠加，而是“责任田划分”

我们拆解了一个典型需求：“客户反馈订单支付失败，需要定位是前端、网关、还是支付服务的问题”。如果用单个 Agent，它得自己决定查哪里、怎么查、怎么比对。而用多智能体，我们划了三块责任田：

  • Frontend-Agent：只负责解析 Sentry 上报的前端错误（payment_failedevent），提取user_id,order_id,browser_info，输出结构化 JSON。它不碰后端日志，也不查数据库。
  • Gateway-Agent：只接收order_id，查 APISIX 日志，输出upstream_status,response_time,upstream_addr。它不知道前端长什么样，也不管支付服务是否存活。
  • Payment-Agent：只接收order_id，查支付服务的 MySQL 订单表和 Redis 缓存，输出payment_status,retry_count,last_update_time。

三个 Agent 的输出，由triage-coordinator-skill统一收口，用规则引擎比对：

  • 如果Frontend-Agent有错误，且Gateway-Agent的upstream_status是502→ 定位网关超时，触发gateway-restart-skill；
  • 如果Gateway-Agent正常，但Payment-Agent的payment_status是PENDING且retry_count > 3→ 定位支付服务卡住，触发payment-retry-skill；
  • 其他情况 → 进入fallback-skill。

这种设计的好处是：每个 Agent 极其轻量，可以独立升级、灰度、替换。上周我们把Payment-Agent从 Python 换成 Rust 实现，其他两个 Agent 完全无感，业务也没停一秒。

3.3 多智能体的一致性，靠的是“共享上下文总线”，不是消息队列

很多团队用 Kafka 或 RabbitMQ 做 Agent 间通信，结果发现消息堆积、顺序错乱、消费失败。OpenClaw 原生提供context_bus，这是一个内存级的、带 TTL 的键值存储，所有 Agent 共享同一个实例。我们用它存三类东西：

  • 任务元数据：task_id,created_at,owner,priority
  • 中间产物快照：frontend_error_json,gateway_log_line,payment_db_row
  • 决策标记：triage_decision_made: true,gateway_restarted: false

关键技巧：context_bus的 key 命名必须带task_id前缀，比如task_abc123_frontend_error_json。这样即使并发跑 100 个任务，也不会互相污染。而且我们设置了ttl: 3600（1 小时），超时自动清理，避免内存泄漏。

注意：context_bus是内存存储，不能替代数据库。我们只存临时中间态，最终结果一定落库。曾经有次线上事故，就是因为把payment_db_row存在 context_bus 里忘了落库，重启 OpenClaw 后所有中间状态丢失，导致故障无法复盘。现在我们强制所有 Skill 的on_complete回调里，必须调用persist_to_db()方法。

4. DevOps 场景不是“用 AI 写脚本”，而是用 OpenClaw 重构交付节奏

4.1 CI/CD 流水线里的 OpenClaw：从“人工卡点”到“自动守门员”

传统 CI/CD 的痛点是：PR 合并前，要等 QA 手动点“测试通过”，等安全扫描出报告，等合规同事确认 License。这中间平均卡 2.7 小时。我们把 OpenClaw 插入到 Jenkins Pipeline 的post阶段：

pipeline { agent any stages { stage('Build') { steps { sh 'mvn clean package' } } stage('Test') { steps { sh 'mvn test' } } } post { success { script { // 调用 OpenClaw 的 devops-gate-skill def result = sh( script: 'curl -X POST http://openclaw:8080/skill/devops-gate-skill -d \'{"pr_id":"${env.CHANGE_ID}", "branch":"${env.BRANCH_NAME}"}\'', returnStdout: true ) if (result.contains('"status":"approved"')) { echo "OpenClaw 自动放行" } else { error "OpenClaw 拒绝放行：${result}" } } } } }

devops-gate-skill干三件事：

  1. 调sonarqube-skill获取本次 PR 的代码质量报告，检查blocker_issues == 0 && coverage > 75%；
  2. 调license-check-skill扫描pom.xml，确认无GPL-3.0等高风险 License；
  3. 调compliance-skill查询飞书审批流，确认该模块的合规负责人已点击“同意”。

只有三者全满足，才返回"status":"approved"。这个 Skill 每天自动处理 83 个 PR，把平均合并等待时间从 2.7 小时压到 11 分钟。更重要的是，它把“人盯人”的过程，变成了可审计、可追溯、可回滚的机器决策。

4.2 生产环境巡检：不是“定时跑脚本”，而是“带着意图的主动侦察”

以前的巡检是 Cron Job：每小时跑一次kubectl get pods --all-namespaces，把结果发到钉钉群。问题是谁去看？谁来判断CrashLoopBackOff是偶发还是真故障？我们改用 OpenClaw 的proactive-patrol-skill，它的工作模式是：

  • 意图驱动：不是被动查状态，而是带着“我要确认支付链路健康”这个意图出发。它会先查payment-service的 Pod 状态，如果正常，再查它的上游api-gateway，再查下游redis，形成一条健康链路。
  • 动态阈值：payment-service的 CPU 使用率阈值不是固定 80%，而是根据历史 7 天同时间段的 P95 值动态计算。比如凌晨 3 点，历史 P95 是 12%，那当前超过 18% 就告警。
  • 自动取证：一旦发现异常（如redis连接数突增），它不只发告警，而是自动执行：
    • kubectl top pods -n redis获取实时资源；
    • kubectl logs -n redis redis-master-0 --tail=100抓最近日志；
    • curl http://prometheus:9090/api/v1/query?query=redis_connected_clients拉指标；
    • 把三者合成一份 PDF 报告，发到飞书“SRE-Alert”群。

这个 Skill 让我们把 70% 的 P1/P2 故障，从“客户投诉后才发现”提前到“故障发生前 3 分钟预警”。它不是替代 SRE，而是让 SRE 的精力从“看屏幕”转向“做决策”。

4.3 自动化测试的终极形态：用 OpenClaw 构建“测试用例生成-执行-分析”闭环

毕业设计里常写的“DevOps 自动化测试”，往往止步于mvn test。我们用 OpenClaw 把它推得更远：

  1. 生成阶段：test-gen-skill接收 Git Commit Message（如 “fix: order status update race condition”），调 RAG 查《订单状态机设计文档》，自动生成 3 个边界测试用例（test_order_status_race_1,test_order_status_race_2,test_order_status_race_3），代码写进src/test/java/。
  2. 执行阶段：test-runner-skill启动一个临时 Docker 容器，装 JDK/Maven，执行mvn test -Dtest=OrderStatusTest#test_order_status_race_1，捕获 stdout/stderr。
  3. 分析阶段：test-analyzer-skill解析 Surefire 报告，如果失败，自动调log-analyzer-agent查失败堆栈，再调code-search-skill在代码库中搜索相关方法，最后生成一句话根因：“OrderStatusService.updateStatus()未加@Transactional，导致并发更新丢失。”

这个闭环让我们的单元测试覆盖率年增长 34%，更重要的是，它把“写测试”这个工程师最抵触的任务，变成了提交代码后自动完成的背景音。新人入职第一周，就能看到自己的代码被 OpenClaw 自动生成测试并跑通——这种正向反馈，比任何培训都管用。

5. 29 个真实用例详解：从“今天就能抄作业”到“明年还能延展”

5.1 用例 1-5：RAG 驱动的即时知识响应（适合所有团队）

用例编号触发场景Skill 组合RAG 数据源节省时间/天关键配置点
1新人问：“生产数据库密码在哪？”security-qa-skill+vault-lookup-skillrag/kb/（加密的 Vault 文档）12 分钟vault-lookup-skill必须用approle认证，禁止硬编码 token
2客户邮件问：“你们支持 OAuth2.0 的 scope 有哪些？”customer-qa-skill+api-doc-skillrag/kb/（Swagger 导出的 Markdown）8 分钟api-doc-skill输出必须带curl示例，格式化为代码块
3开发查：“spring-boot-starter-webflux依赖了哪些 transitive jar？”dep-analyze-skill+maven-central-skillrag/kb/（Maven Central API 返回的 JSON）5 分钟maven-central-skill超时设为3s，失败则返回缓存的上周数据
4运维查：“上个月 15 号 Kafka Topicorder-events的峰值流量？”kafka-metrics-skill+prometheus-skillrag/kb/（Prometheus 查询语法手册）15 分钟prometheus-skill的 query 模板必须预编译，避免 run-time 注入
5法务问：“Apache-2.0License 是否允许商用？”license-qa-skill+oss-compliance-skillrag/kb/（OSI 官网 FAQ 翻译版）3 分钟oss-compliance-skill输出必须带法律效力免责声明

实操心得：这 5 个用例，我们第一天就上线了。它们共同特点是——输入明确（一个问题）、输出确定（一段文字或一个值）、RAG 数据源静态。新手照着skill_config.yaml模板改三行就能跑通。但要注意：所有涉及敏感信息（如密码、Token）的 Skill，必须在config.yaml里开启enable_sensitive_redaction: true，OpenClaw 会自动把日志里的password=xxx替换成password=***。

5.2 用例 6-15：多智能体协同的复杂任务（需团队协作）

用例编号任务目标Agent 协作链关键难点我们的解法ROI（月节省工时）
6自动修复 CI 失败的 Java 编译错误ci-fail-detector→error-parser→code-fix-skill→pr-creatorcode-fix-skill生成的代码可能编译不过加入compile-validator-skill作为闸门，失败则回退到error-parser重试120h
7专利初稿撰写：根据技术交底书生成权利要求书tds-parser→patent-template-skill→legal-review-skill法律术语准确性难保证legal-review-skill不生成内容，只做diff比对，标红所有非模板词汇85h
8微信小程序发布前的全链路检测（代码+配置+素材）miniprogram-scan→config-validator→asset-checker→report-generator微信审核规则频繁变更config-validator的规则库每周从微信开放平台 API 自动同步62h
9客户投诉自动分类与 SLA 预警email-parser→sentiment-analyzer→sla-calculator→manager-alert邮件口语化严重，情感分析易误判sentiment-analyzer输入前，先用jargon-normalizer-skill把“卡死了”映射为“系统无响应”98h
10群晖 NAS 上 OpenClaw 的自动备份与灾备切换nas-backup-skill→backup-verifier→failover-trigger群晖 Docker 卷权限混乱nas-backup-skill用rsync -a --delete而非cp，确保权限继承40h
11Spring AI 2.0 升级兼容性检查spring-ai-upgrade-skill→dep-conflict-skill→api-change-skill→migration-guide-genSpring Boot 版本锁死问题api-change-skill的 diff 引擎，只比对@Bean和@Configuration类75h
12多目标优化：同时最小化部署成本 & 最大化服务可用性cost-optimizer→availability-simulator→tradeoff-analyzer仿真环境与生产环境偏差大availability-simulator的输入参数，必须从生产 Prometheus 拉取真实指标110h
13Ontology-RAG：从非结构化专利文本构建领域知识图谱patent-parser→entity-extractor→relation-classifier→neo4j-loader专利文本歧义多（如“bank”指金融机构还是河岸）entity-extractor的 prompt 里，强制要求输出confidence_score，低于 0.8 的实体丢弃135h
14Geo-RAG：根据用户地理位置，动态调整 RAG 召回策略geo-locator-skill→region-rag-skill→content-localizerIP 定位不准，用户实际在海外geo-locator-skill优先读取 HTTP HeaderX-Forwarded-For，Fallback 到 MaxMind DB55h
15Dify 数据流增强：用户输入文章 → RAG 召回事实 → 重写文章dify-input-skill→fact-retriever→rewrite-skill→plagiarism-checker重写后事实性错误plagiarism-checker不只查重复率，还用fact-consistency-skill校验重写句与召回事实的逻辑一致性90h

5.3 用例 16-29：深度集成与前沿探索（适合技术攻坚团队）

用例编号技术亮点关键实现遇到的坑我们填坑的方法当前状态
16OpenClaw 接入飞书多维表格，实现“需求-开发-测试”自动对齐用飞书开放平台bitableAPI，监听表格变更事件，触发requirement-sync-skill飞书 Webhook 签名验证失败率高改用feishu-botSDK 的verify_signature()方法，且增加重试 3 次逻辑已上线
17OpenClaw 接入微信公众号，客户扫码即查订单状态用微信 JS-SDK + OpenClawwechat-order-skill，用户扫码后自动获取openid微信access_token有效期 2 小时，过期后请求失败wechat-order-skill启动时预加载 token，并用schedule每 110 分钟刷新已上线
18群晖 Docker 部署 OpenClaw，解决cgroup权限问题在docker-compose.yml里加privileged: true和cgroup_parent: /docker群晖 DSM 7.2 后cgroupv2 默认启用，与 OpenClaw 冲突改用cgroup_mode: host，并禁用群晖的Container Manager自动 cgroup 管理已上线
19Cursor AI 编程插件与 OpenClaw 联动：Cursor 里写注释，OpenClaw 自动生成代码用 Cursor 的custom_commands.json，调 OpenClaw/skill/code-gen-skillAPICursor 的editor.getText()返回带\r\n，OpenClaw 解析失败code-gen-skill的 input parser，强制text.replace(/\r\n/g, '\n')已上线
20AI 浏览器插件：在任意网页按Ctrl+Shift+O，调 OpenClaw 分析页面内容用 Chrome Extension Manifest V3，content script 注入openclaw-client.js页面 CSP 策略阻止外链请求openclaw-client.js改用chrome.runtime.sendMessage()与 background script 通信，绕过 CSPBeta 测试
21Spring AI Alibaba 适配：让 OpenClaw 调用阿里云百炼大模型修改llm_config.yaml，provider: alibaba，model_name: qwen-max阿里云AccessKey泄露风险llm_config.yaml不存 AK/SK，改用alibaba-cloud-credentialsSDK 的StsAssumeRoleSessionCredentialsProvider已上线
22Production Agentic RAG：千万级文档的毫秒级召回用milvus替换chroma，bge-m3-zhembedding，HNSW索引Milvus 2.4 的search接口返回top_k不稳定改用Milvus 2.3.5+consistency_level: Strong参数已上线
23OpenClaw Skill 延迟诊断：为什么某个 Skill 总是 2s 响应？用 OpenClaw 内置metrics_exporter，暴露/metrics，接入 Prometheus + Grafana默认 metrics 不包含 per-skill 的 p95 延迟在skill_base.py里重写execute()方法，手动打点SKILL_EXECUTION_LATENCY_SECONDS已上线
24AI 辅助专利撰写：从技术方案自动生成“说明书摘要”和“权利要求书”patent-gen-skill调用ontology-rag+legal-template-engine权利要求书格式不符合国知局要求legal-template-engine的 Jinja2 模板，严格按《专利审查指南》第二部分第二章格式编写已上线
25多智能体系统一致性：三个 Agent 同时修改同一份配置，如何避免冲突？用distributed-lock-skill（基于 Redis RedLock），所有写操作前 acquire lockRedLock 在网络分区时可能失效distributed-lock-skill的 lock key 带task_id+agent_id，且所有写操作加version字段乐观锁已上线
26多智能体协同：前端 Agent 生成 UI，后端 Agent 生成 API，自动联调ui-gen-skill→api-gen-skill→contract-test-skillOpenAPI Spec 与实际 API 行为不一致contract-test-skill用pact-js生成消费者契约，再用pact-broker验证提供者Alpha 测试
27多目标多智能体：同时优化“模型推理延迟”、“GPU 显存占用”、“预测准确率”latency-optimizer+memory-optimizer+accuracy-optimizer→multi-objective-orchestrator三个优化目标互相矛盾（降延迟常以牺牲精度为代价）multi-objective-orchestrator用 NSGA-II 算法，输出 Pareto 最优解集供人工选择Research
28多智能体混合驱动的分层强化学习：底层 Agent 控制 Kubernetes Pod，高层 Agent 决策扩缩容策略k8s-control-agent（PPO） +scaling-strategy-agent（DQN）RL 训练样本稀疏，收敛慢scaling-strategy-agent的 reward 函数，加入cost_saving和sla_violation双权重Research
29OpenClaw 与美梦 AI、岚鸣泉-AI 剪辑创作联动：用 OpenClaw 生成视频脚本，喂给剪辑 AIscript-gen-skill→video-editing-api（美梦 AI） →clip-render-skill美梦 AI 的scene_duration参数单位是毫秒，文档写成秒video-editing-api的 client SDK，强制duration_ms = int(duration_sec * 1000)PoC 阶段

6. 你不需要成为 OpenClaw 专家，但必须掌握这 7 个“保命”配置原则

6.1 配置不是写完就扔，而是要像管理生产代码一样做版本控制

我们把整个openclaw/config/目录，连同skills/下的所有 Python 文件，全部纳入 Git 仓库，分支策略是：

  • main：生产环境配置，只接受 PR 合并，且 PR 必须包含config-diff-report.md（用openclaw-cli diff --from prod --to staging生成）；
  • staging：预发环境，每天自动从main合并，用于灰度测试新 Skill；
  • feature/*：功能分支，每个新用例一个分支，命名如feature/payment-retry-skill。

提示：OpenClaw 的config.yaml里有个config_version字段，我们强制要求每次修改都加 1。CI 流水线会校验：git tag的最新版本号，必须等于config_version，否则拒绝部署。这让我们在一次误操作中，及时拦截了把max_hops: 3改成max_hops: 100的危险配置。

6.2 Skill 不是越“智能”越好，而是越“专注”越稳

我们曾写过一个“万能 Skill”：universal-assistant-skill，它试图回答所有问题。结果上线三天，崩溃 17 次，日志全是RecursionError: maximum recursion depth exceeded。后来我们把它拆成 12 个单一职责 Skill：

  • code-search-skill：只搜代码，不答问题；
  • log-search-skill：只搜日志，不写报告；
  • doc-qa-skill：只答文档问题，不执行命令。

每个 Skill 的代码行数控制在 200 行以内，requirements.txt只有 3 个依赖。现在它们的平均 uptime 是 99.992%，比我们核心支付服务还高。

6.3 RAG 不是“投喂越多越好”，而是要建立“