Skip to Content

37d Agent 管理与 Skill 体系

上一篇: 37c 多维表格自动化 | 下一篇: 37e RAG 知识库搭建

本篇定义 Skill 体系的完整治理方案:文件结构与命名规范、注册与发现机制、Git 版本管理工作流、权限控制、热更新流程、运行监控和质量控制。Skill 是 OpenClaw 的核心能力单元,治理好 Skill 体系是 Agent 长期稳定运行的关键。


1. Skill 文件结构与命名规范

1.1 目录结构

按 7 组 Skill 分目录管理:

skills/ ├── _shared/ ← 共享模板和工具 Skill │ ├── output-formatter.md ← 输出格式化通用 Skill │ └── error-handler.md ← 错误处理通用 Skill ├── requirement/ ← ① 需求/缺陷 Skill 组 │ ├── requirement-create.md ← 创建需求 │ ├── requirement-status-change.md ← 需求状态流转 │ ├── requirement-prd-generate.md ← PRD 自动生成 │ ├── bug-create.md ← 创建缺陷 │ └── bug-status-change.md ← 缺陷状态流转 ├── code/ ← ② 代码 Skill 组 │ ├── code-pr-review.md ← PR 审查摘要 │ ├── code-search.md ← 代码搜索 │ ├── code-ci-trigger.md ← CI/CD 触发 │ └── code-branch-manage.md ← 分支管理 ├── ops/ ← ③ 运维 Skill 组 │ ├── ops-log-query.md ← 日志查询 │ ├── ops-service-status.md ← 服务状态检查 │ ├── ops-alert-handle.md ← 告警处理 │ └── ops-deploy-trigger.md ← 部署触发 ├── analytics/ ← ④ 数据分析 Skill 组 │ ├── analytics-sql-query.md ← SQL 数据查询 │ ├── analytics-ga-report.md ← GA 数据报告 │ ├── analytics-weekly-report.md ← 周报生成 │ └── analytics-trend.md ← 趋势分析 ├── team/ ← ⑤ 团队管理 Skill 组 │ ├── team-weekly-summary.md ← 工作总结生成 │ ├── team-okr-track.md ← OKR 跟踪 │ ├── team-onboard.md ← 入职流程 │ └── team-offboard.md ← 离职流程 ├── knowledge/ ← ⑥ 知识库 Skill 组 │ ├── knowledge-rag-search.md ← RAG 检索 │ ├── knowledge-doc-qa.md ← 文档问答 │ └── knowledge-archive.md ← 知识沉淀 └── growth/ ← ⑦ 运营 Skill 组 ├── growth-strategy.md ← 增长策略建议 ├── growth-competitor.md ← 竞品分析 ├── growth-content-generate.md ← 内容生成 └── growth-community.md ← 社区运营

1.2 命名规则

格式:{组名}-{动作}-{对象}.md

组成部分规则示例
组名与目录名一致,小写英文requirement, code, ops
动作动词,描述 Skill 做什么create, search, query, generate, track
对象名词,描述操作对象pr, log, report, summary
连接符使用 - 连接requirement-create, code-pr-review

1.3 Skill 文件标准模板

每个 Skill 文件必须包含以下章节:

# {skill-name} 一句话描述这个 Skill 做什么。 ## 触发条件 描述什么情况下触发这个 Skill。包括: - 关键词匹配(用户消息中的触发词) - 事件触发(飞书事件类型) - 定时触发(cron 表达式) ## 执行步骤 编号列表,描述 Skill 的执行流程。每一步应该明确: 1. 做什么操作 2. 调用什么工具(MCP 工具名) 3. 如何处理结果 ## 输出格式 定义 Skill 的输出结构和格式要求。包括: - 消息格式(文本/卡片/表格) - 必填字段 - 字段约束 ## 示例输出 提供 1-2 个完整的输出示例,作为 Few-shot 参考。 ## 权限要求 列出这个 Skill 需要的权限: - 飞书权限 - MCP 工具权限 - 数据库权限 ## 错误处理 描述常见错误场景和处理方式。

2. Skill 注册与发现

2.1 加载机制

OpenClaw 启动时自动扫描 skills/ 目录下的所有 .md 文件,解析 Skill 定义并注册到内存中。

启动/热更新 扫描 skills/ 目录 解析每个 .md 文件 ├─→ 提取 Skill 名称(H1 标题) ├─→ 提取触发条件 ├─→ 提取执行步骤 └─→ 提取输出格式和示例 注册到 Skill 路由表 就绪,等待消息

2.2 意图匹配与路由

当用户发送消息时,OpenClaw 的路由流程:

用户消息 LLM 意图识别(Haiku 轻量模型) ├─→ 匹配到单个 Skill → 直接执行 ├─→ 匹配到多个 Skill → 按优先级选择 ├─→ 未匹配到 Skill → 通用对话回复 └─→ 识别为多步任务 → 编排多个 Skill 执行 Skill(Sonnet 主力模型) 输出结果 → 写入记忆 → 回复用户

2.3 优先级与冲突处理

当多个 Skill 的触发条件重叠时,按以下规则选择:

优先级规则示例
1(最高)精确关键词匹配”创建需求” → requirement-create
2事件类型匹配多维表格变更事件 → requirement-status-change
3语义相似度匹配”帮我提一个 bug” → bug-create
4(最低)通用对话无匹配时的兜底回复

如果同一优先级有多个匹配,OpenClaw 会让 LLM 根据上下文选择最合适的 Skill。


3. 多 Agent 编排与配置

37a 中我们选择了”单飞书机器人 + OpenClaw 路由”的架构。但在 OpenClaw 内部,可以配置多个 Agent 实例,每个 Agent 绑定不同的 Skill 组,通过任务委派实现协作。这一节讲清楚:怎么配、怎么串、怎么调。

3.1 为什么需要多 Agent

单 Agent + 所有 Skill 的方案在 Skill 数量少(< 15 个)时没问题。但当 Skill 增长到 25+ 个,会出现:

问题表现多 Agent 解决方式
意图识别准确率下降Skill 越多,LLM 越难选对先路由到领域 Agent,再在小范围内匹配 Skill
上下文污染所有 Skill 的 Prompt 挤在一个上下文窗口每个 Agent 只加载自己领域的 Skill
权限边界模糊一个 Agent 拥有所有工具权限每个 Agent 只配置必要的 MCP 工具
故障隔离差一个 Skill 出错可能影响整个 AgentAgent 级别隔离,互不影响

3.2 Agent 拓扑设计

用户消息 → 飞书 → OpenClaw Gateway ┌───────────────┐ │ Router Agent │ ← 轻量模型(Haiku),只做意图分类 │ (路由 Agent) │ └───────┬───────┘ ┌─────────────┼─────────────┬──────────────┐ ▼ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ PM Agent │ │ Dev Agent │ │ Data Agent│ │ Ops Agent │ │ 产品需求 │ │ 代码运维 │ │ 数据分析 │ │ 团队管理 │ │ │ │ │ │ │ │ │ │ Skills: │ │ Skills: │ │ Skills: │ │ Skills: │ │ requirement│ │ code/* │ │ analytics│ │ team/* │ │ knowledge │ │ ops/* │ │ growth/* │ │ knowledge│ └───────────┘ └───────────┘ └───────────┘ └───────────┘
  • Router Agent:用 Haiku 轻量模型,只做一件事 — 判断用户消息属于哪个领域,然后委派给对应的领域 Agent
  • 领域 Agent:用 Sonnet 主力模型,只加载自己领域的 Skill,上下文更聚焦,意图识别更准

3.3 多 Agent 配置

.openclaw/config.json 中定义多个 Agent:

{ "name": "hackquest-agent", "mode": "multi-agent", "router": { "model": "claude-haiku-4-20250514", "prompt": "你是 HackQuest 团队的消息路由器。根据用户消息内容,判断应该由哪个 Agent 处理。只输出 Agent 名称,不要解释。", "routes": [ { "agent": "pm-agent", "description": "产品需求、缺陷管理、PRD、需求评审、知识库问答", "keywords": ["需求", "缺陷", "bug", "PRD", "评审", "知识库", "文档"] }, { "agent": "dev-agent", "description": "代码审查、PR、CI/CD、分支管理、部署、日志查询、告警", "keywords": ["PR", "代码", "部署", "CI", "日志", "告警", "分支", "上线"] }, { "agent": "data-agent", "description": "数据查询、报表生成、增长策略、竞品分析、运营内容", "keywords": ["数据", "查询", "报表", "增长", "竞品", "流量", "转化率"] }, { "agent": "team-agent", "description": "工作总结、OKR、考勤、入职离职、项目进度、交付", "keywords": ["周报", "OKR", "考勤", "入职", "离职", "进度", "里程碑"] } ], "fallback": "pm-agent" }, "agents": { "pm-agent": { "model": "claude-sonnet-4-20250514", "skills": ["requirement/*", "knowledge/*", "_shared/*"], "mcp": ["lark-mcp"], "memory": { "namespace": "pm" }, "description": "产品需求和知识库 Agent" }, "dev-agent": { "model": "claude-sonnet-4-20250514", "skills": ["code/*", "ops/*", "_shared/*"], "mcp": ["lark-mcp", "github", "postgres"], "memory": { "namespace": "dev" }, "description": "开发和运维 Agent" }, "data-agent": { "model": "claude-sonnet-4-20250514", "skills": ["analytics/*", "growth/*", "_shared/*"], "mcp": ["lark-mcp", "postgres"], "memory": { "namespace": "data" }, "description": "数据分析和运营 Agent" }, "team-agent": { "model": "claude-sonnet-4-20250514", "skills": ["team/*", "knowledge/*", "_shared/*"], "mcp": ["lark-mcp", "github"], "memory": { "namespace": "team" }, "description": "团队管理和人事 Agent" } }, "daemon": { "enabled": true, "port": 3100 }, "memory": { "enabled": true, "persistPath": ".openclaw/memory", "shared": true } }

关键配置说明:

字段说明
mode: "multi-agent"启用多 Agent 模式(默认是 single-agent
router.model路由 Agent 用轻量模型,降低成本和延迟
router.routes[].keywords关键词辅助路由,LLM 结合关键词和语义判断
router.fallback无法判断时的默认 Agent
agents.*.skills每个 Agent 只加载指定目录的 Skill,支持通配符
agents.*.mcp每个 Agent 只能访问指定的 MCP Server(最小权限)
agents.*.memory.namespace记忆命名空间隔离,防止 Agent 间记忆污染
memory.shared开启共享记忆区域,跨 Agent 传递上下文

3.4 Agent 间任务委派

当一个 Agent 执行过程中发现需要另一个 Agent 的能力时,可以通过任务委派实现协作。

委派语法

在 Skill 文件中声明委派:

# requirement-prd-generate ... ## 执行步骤 1. 从记忆中读取需求详情 2. 调用 knowledge-rag-search 检索相关文档 3. 生成 PRD 文档 4. **委派 dev-agent**:在 GitHub 创建对应的 Issue - 委派指令:创建 GitHub Issue,标题为"[需求] {requirement_title}",关联 PRD 链接 - 等待结果:是(同步委派) 5. 更新需求多维表格的 PRD 链接和 Issue 链接 ## 委派声明 - 目标 Agent: dev-agent - 触发条件: PRD 生成完成后 - 传递数据: requirement_title, prd_link - 等待模式: sync(同步等待结果)

委派配置

config.json 中定义允许的委派关系:

{ "delegations": { "pm-agent": { "can_delegate_to": ["dev-agent", "data-agent"], "max_depth": 2 }, "dev-agent": { "can_delegate_to": ["pm-agent"], "max_depth": 1 }, "data-agent": { "can_delegate_to": ["pm-agent"], "max_depth": 1 }, "team-agent": { "can_delegate_to": ["dev-agent", "data-agent"], "max_depth": 2 } } }
字段说明
can_delegate_to允许委派的目标 Agent 列表
max_depth最大委派深度,防止循环委派(A→B→A→B…)

委派流程

PM Agent 执行 requirement-prd-generate ├─→ 步骤 1-3:正常执行(PM Agent 自己的 Skill) ├─→ 步骤 4:需要创建 GitHub Issue │ │ │ ▼ │ 检查委派权限:pm-agent → dev-agent ✅ │ │ │ ▼ │ 构造委派消息: │ { │ "from": "pm-agent", │ "to": "dev-agent", │ "task": "创建 GitHub Issue: [需求] 新增 Solana 课程模块", │ "context": { "requirement_title": "...", "prd_link": "..." }, │ "mode": "sync" │ } │ │ │ ▼ │ Dev Agent 接收委派,执行 code-issue-create Skill │ │ │ ▼ │ 返回结果:{ "issue_url": "https://github.com/..." } ├─→ 步骤 5:PM Agent 继续执行,使用委派结果 完成

3.5 共享记忆与跨 Agent 上下文

多 Agent 模式下,记忆分为两个区域:

.openclaw/memory/ ├── shared/ ← 共享记忆(所有 Agent 可读写) │ ├── requirement_rec001.md ← 需求信息(PM Agent 写,Dev Agent 读) │ ├── pr_156.md ← PR 信息(Dev Agent 写,PM Agent 读) │ └── sprint_2026-W28.md ← 迭代信息(Team Agent 写,所有 Agent 读) ├── pm/ ← PM Agent 私有记忆 │ └── prd_templates.md ├── dev/ ← Dev Agent 私有记忆 │ └── ci_config_cache.md ├── data/ ← Data Agent 私有记忆 │ └── query_cache.md └── team/ ← Team Agent 私有记忆 └── attendance_rules.md

在 Skill 中指定记忆写入区域:

## 记忆操作 - 写入共享记忆:requirement_{record_id}(其他 Agent 需要读取需求信息) - 写入私有记忆:prd_draft_cache(只有 PM Agent 需要的草稿缓存)

规则:

  • 跨 Agent 需要的数据 → 写入 shared/
  • Agent 内部缓存 → 写入私有命名空间
  • 共享记忆的写入会触发通知,相关 Agent 可以感知到上下文变化

3.6 Skill 链式编排配置

除了靠 LLM 隐式判断”下一步该调哪个 Skill”,还可以通过显式编排配置定义 Skill 执行链。

编排文件

创建 skills/_orchestration/requirement-lifecycle.md

# requirement-lifecycle 需求全生命周期编排:从创建到上线的完整 Skill 链。 ## 编排类型 事件驱动状态机 ## 状态转换定义 ### 触发:用户提出需求 - 执行:requirement-create(PM Agent) - 写入共享记忆:requirement_{id} - 下一状态:待评审 ### 触发:评审人点击"通过"(飞书卡片回调) - 执行:requirement-status-change(PM Agent) - 自动触发:requirement-prd-generate(PM Agent) - 委派:dev-agent 创建 GitHub Issue - 下一状态:PRD编写中 ### 触发:PM 确认 PRD(飞书消息) - 执行:requirement-status-change(PM Agent) - 下一状态:设计中 ### 触发:设计评审通过(飞书卡片回调) - 执行:requirement-status-change(PM Agent) - 下一状态:开发中 ### 触发:GitHub PR 创建(GitHub Webhook) - 执行:code-pr-review(Dev Agent) - 读取共享记忆:requirement_{id}(关联需求) - 写入共享记忆:pr_{number} - 下一状态:待审查 ### 触发:PR 合并(GitHub Webhook) - 执行:requirement-status-change(PM Agent) - 委派:dev-agent 触发 CI/CD - 下一状态:测试中 ### 触发:测试通过(飞书消息) - 执行:requirement-test-verify(PM Agent) - 委派:dev-agent → ops-deploy-trigger(需人工确认) - 下一状态:待部署 ### 触发:部署完成(运维确认) - 执行:requirement-status-change(PM Agent) - 通知:项目群发送上线通知 - 下一状态:已上线(终态) ## 超时规则 - 待评审超过 24h → 提醒评审人 - 待评审超过 48h → 升级到 CTO - 待部署状态无超时 → 必须人工确认 ## 异常处理 - 任何 Skill 执行失败 → 保持当前状态,通知相关人 - 委派失败 → 回退到委派前状态,记录错误日志

编排文件加载

OpenClaw 启动时扫描 skills/_orchestration/ 目录,解析编排定义,注册到事件监听器:

启动 扫描 skills/_orchestration/*.md 解析状态转换定义 为每个"触发"注册事件监听: ├─→ 飞书消息事件 → 匹配关键词 ├─→ 飞书卡片回调 → 匹配 action value ├─→ 多维表格变更 → 匹配字段变更 ├─→ GitHub Webhook → 匹配 PR/CI 事件 └─→ 定时事件 → cron 触发 事件到达时,按编排定义执行 Skill 链

3.7 完整端到端示例:需求到上线的 Agent 协作

以”新增 Solana 课程模块”为例,展示 4 个 Agent 如何协作:

张三 @机器人: 创建一个 P1 需求:新增 Solana 课程模块 Router Agent(Haiku): 识别为"需求"类 → 路由到 PM Agent PM Agent: 执行 requirement-create ├─→ 创建多维表格记录 ├─→ 写入共享记忆 shared/requirement_rec001.md └─→ 发送评审卡片到评审群 李四点击"通过" → 飞书卡片回调 PM Agent: 执行 requirement-status-change → requirement-prd-generate ├─→ 读取共享记忆 requirement_rec001 ├─→ 检索知识库(RAG) ├─→ 生成 PRD 文档 ├─→ 委派 Dev Agent: 创建 GitHub Issue │ │ │ ▼ │ Dev Agent: 执行 code-issue-create │ ├─→ 通过 GitHub MCP 创建 Issue │ └─→ 返回 issue_url 给 PM Agent └─→ 更新多维表格(PRD 链接 + Issue 链接) ... 设计评审通过 → PM Agent 更新状态 ... 张三提交 PR #156 → GitHub Webhook Router Agent: GitHub 事件 → 路由到 Dev Agent Dev Agent: 执行 code-pr-review ├─→ 读取共享记忆 requirement_rec001(关联需求上下文) ├─→ 通过 GitHub MCP 获取 PR diff ├─→ 生成审查摘要 ├─→ 写入共享记忆 shared/pr_156.md └─→ 发送审查摘要到开发群 PR 合并 → PM Agent 更新状态为"测试中" 王五: @机器人 测试通过 Router Agent: 路由到 PM Agent PM Agent: 执行 requirement-test-verify ├─→ 委派 Dev Agent: 触发部署 │ │ │ ▼ │ Dev Agent: 执行 ops-deploy-trigger │ ├─→ 发送部署确认卡片到运维群 │ └─→ 等待运维确认(高风险操作) └─→ 运维确认后 → PM Agent 更新状态为"已上线"

3.8 单 Agent vs 多 Agent 选择指南

维度单 Agent 模式多 Agent 模式
Skill 数量< 15 个15+ 个
团队规模< 20 人20+ 人
配置复杂度
意图识别准确率Skill 多时下降两级路由,更准确
故障隔离
Token 成本低(单次调用)略高(路由 + 执行两次调用)
适用阶段第一、二阶段(基础设施 + 核心工作流)第三、四阶段(全面铺开后)

建议:先用单 Agent 模式跑通核心流程(37a 路线图第一、二阶段),Skill 数量超过 15 个后切换到多 Agent 模式。切换只需修改 config.jsonmode 字段和添加 router/agents 配置,Skill 文件不需要改动。

3.9 跨部门 Agent 全链路协作

3.7 节展示了产品研发流程中 PM Agent 和 Dev Agent 的协作。但在真实团队中,很多场景需要 3 个甚至 4 个 Agent 跨部门串联。本节讲清楚:跨部门链路怎么设计、怎么编排、怎么排错。

为什么需要跨部门协作

单部门内的 Agent 协作(如 PM Agent → Dev Agent)相对简单,因为上下文连贯、数据模型一致。但以下场景涉及多个部门的 Agent 接力:

场景涉及 Agent链路
线上故障 → 修复 → 复盘Dev → PM → Dev → Team告警→创建缺陷→修复→部署→复盘报告
运营发现增长瓶颈 → 产品改进Data → PM → Dev → Data数据分析→创建需求→开发上线→效果验证
新员工入职 → 全流程打通Team → Dev → PM → Team入职→开权限→分配任务→首周总结
季度 OKR 复盘 → 下季度规划Team → Data → PM → TeamOKR 进度→数据验证→需求规划→新 OKR

跨部门编排文件

创建 skills/_orchestration/cross-department-incident.md,以”线上故障全链路”为例:

# cross-department-incident 线上故障全链路编排:从告警到复盘的跨部门 Agent 协作。 ## 编排类型 跨部门事件驱动链 ## 参与 Agent - Dev Agent:告警处理、代码修复、部署 - PM Agent:缺陷管理、状态流转 - Data Agent:影响面分析 - Team Agent:复盘报告归档 ## 链路定义 ### 阶段 1:告警触发(Dev Agent) - 触发:监控系统告警 / 用户报告"线上问题" - 执行:ops-alert-handle(Dev Agent) - 操作: 1. 查询日志定位问题 2. 评估影响范围 3. 写入共享记忆:incident_{id} = {severity, service, error, affected_users} - 委派:PM Agent → 创建缺陷记录 - 委派:Data Agent → 分析用户影响面 - 下一阶段:缺陷创建 ### 阶段 2:缺陷创建 + 影响分析(PM Agent + Data Agent 并行) - PM Agent 执行:bug-create - 读取共享记忆:incident_{id} - 创建缺陷记录,严重程度根据影响面自动判定 - 写入共享记忆:bug_{id} = {title, severity, assignee} - Data Agent 执行:analytics-sql-query(并行) - 查询受影响用户数、影响时间段、业务损失 - 写入共享记忆:incident_{id}_impact = {affected_users, duration, revenue_impact} - 下一阶段:修复开发 ### 阶段 3:修复与部署(Dev Agent) - 触发:开发者提交修复 PR - 执行:code-pr-review(Dev Agent) - 读取共享记忆:incident_{id}, bug_{id} - 标记为 hotfix,跳过常规 CR 流程 - PR 合并后自动触发:ops-deploy-trigger - 高优先级部署,仍需运维确认 - 部署完成后: - 委派 PM Agent:更新缺陷状态为"已修复" - 委派 Data Agent:验证修复效果 - 下一阶段:效果验证 ### 阶段 4:效果验证(Data Agent) - 触发:部署完成后 30 分钟 - 执行:analytics-sql-query(Data Agent) - 对比修复前后的错误率、用户影响 - 写入共享记忆:incident_{id}_resolution = {error_rate_before, error_rate_after, resolved} - 如果问题未解决 → 通知 Dev Agent 继续排查 - 如果问题已解决 → 委派 Team Agent 生成复盘报告 - 下一阶段:复盘归档 ### 阶段 5:复盘归档(Team Agent) - 触发:Data Agent 确认问题已解决 - 执行:team-incident-postmortem(Team Agent) - 读取共享记忆:incident_{id}, bug_{id}, incident_{id}_impact, incident_{id}_resolution - 汇总全链路信息,生成复盘报告 - 写入飞书知识库(供 RAG 检索) - 更新记忆:incident_{id}_postmortem - 通知:项目群发送复盘报告链接 ## 超时规则 - 阶段 1 → 阶段 2:S0/S1 故障 5 分钟内必须创建缺陷,超时升级到 CTO - 阶段 3 部署确认:hotfix 最多等待 30 分钟 - 阶段 4 效果验证:部署后 30 分钟自动触发 - 阶段 5 复盘报告:修复后 24 小时内完成 ## 异常处理 - 任何 Agent 委派失败 → 回退到上一阶段,通知管理员 - Data Agent 查询超时 → 跳过影响分析,标记为"待补充" - 复盘报告生成失败 → 不影响主流程,记录待办

跨部门协作的完整示例:线上故障全链路

以”课程进度接口 500 错误”为例,展示 4 个 Agent 如何跨部门接力:

═══════════════════════════════════════════════════════════ 阶段 1:告警触发 Dev Agent ═══════════════════════════════════════════════════════════ Sentry 告警: course-progress API 500 错误率飙升到 15% Router Agent → Dev Agent Dev Agent: 执行 ops-alert-handle ├─→ 查询日志:发现 Redis 连接池耗尽 ├─→ 评估影响:课程进度保存功能不可用 ├─→ 写入共享记忆 shared/incident_inc001.md: │ {severity: S1, service: course-api, error: "Redis pool exhausted", │ affected_feature: "课程进度保存", start_time: "10:15"} ├─→ 委派 PM Agent: 创建缺陷 └─→ 委派 Data Agent: 分析影响面(并行) ═══════════════════════════════════════════════════════════ 阶段 2:缺陷创建 + 影响分析 PM Agent + Data Agent ═══════════════════════════════════════════════════════════ PM Agent: 执行 bug-create (并行执行) ├─→ 读取 shared/incident_inc001 ├─→ 创建缺陷: │ 标题:课程进度接口 500 - Redis 连接池耗尽 │ 严重程度:S1(自动判定:影响核心功能) │ 指派:张三(后端负责人) └─→ 写入共享记忆 shared/bug_rec042.md Data Agent: 执行 analytics-sql-query (并行执行) ├─→ SQL: 统计 10:15 以来受影响的用户数 ├─→ SQL: 统计进度保存失败的请求数 ├─→ 结果:影响 1,200 用户,3,500 次请求失败 └─→ 写入共享记忆 shared/incident_inc001_impact.md: {affected_users: 1200, failed_requests: 3500, duration: "45min", estimated_data_loss: "部分用户进度未保存"} Agent 在项目群发送汇总: 🚨 S1 故障进行中 - 问题:课程进度接口 500(Redis 连接池耗尽) - 影响:1,200 用户,3,500 次请求失败 - 已指派:张三 - 缺陷链接:[查看](https://xxx.feishu.cn/base/xxx) ═══════════════════════════════════════════════════════════ 阶段 3:修复与部署 Dev Agent ═══════════════════════════════════════════════════════════ 张三提交 hotfix PR #178: fix: increase Redis pool size Dev Agent: 执行 code-pr-review ├─→ 读取 shared/incident_inc001, shared/bug_rec042 ├─→ 识别为 hotfix(关联 S1 缺陷) ├─→ 生成审查摘要(标注为紧急修复) └─→ 发送到开发群,建议快速合并 PR 合并 → Dev Agent: 执行 ops-deploy-trigger ├─→ 发送部署确认卡片到运维群(标注 hotfix) └─→ 运维确认 → 部署完成 ├─→ 委派 PM Agent: 更新缺陷状态为"已修复" └─→ 委派 Data Agent: 30 分钟后验证效果 ═══════════════════════════════════════════════════════════ 阶段 4:效果验证 Data Agent ═══════════════════════════════════════════════════════════ (部署后 30 分钟自动触发) Data Agent: 执行 analytics-sql-query ├─→ 查询修复后 30 分钟的错误率:0.1%(正常水平) ├─→ 对比修复前:15% → 0.1% ✅ ├─→ 写入共享记忆 shared/incident_inc001_resolution.md: │ {error_rate_before: "15%", error_rate_after: "0.1%", │ resolved: true, fix_duration: "2h15min"} └─→ 委派 Team Agent: 生成复盘报告 Agent 在项目群发送: ✅ S1 故障已修复 - 错误率:15% → 0.1% - 修复耗时:2 小时 15 分钟 - 复盘报告将在 24 小时内生成 ═══════════════════════════════════════════════════════════ 阶段 5:复盘归档 Team Agent ═══════════════════════════════════════════════════════════ Team Agent: 执行 team-incident-postmortem ├─→ 读取所有共享记忆: │ incident_inc001, bug_rec042, │ incident_inc001_impact, incident_inc001_resolution ├─→ 生成复盘报告: │ 📋 故障复盘:课程进度接口 500 │ ┌──────────────────────────────────────┐ │ │ 时间线 │ │ │ 10:15 告警触发 │ │ │ 10:20 缺陷创建,影响面分析完成 │ │ │ 11:00 hotfix PR 提交 │ │ │ 11:30 部署完成 │ │ │ 12:00 效果验证通过 │ │ │ 12:30 复盘报告生成 │ │ ├──────────────────────────────────────┤ │ │ 根因:Redis 连接池配置过小(默认 10) │ │ │ 影响:1,200 用户,3,500 次请求失败 │ │ │ 修复:连接池扩大到 50,增加连接超时配置 │ │ │ 改进项: │ │ │ 1. 增加 Redis 连接池监控告警 │ │ │ 2. 压测覆盖高并发场景 │ │ │ 3. 课程进度增加本地缓存兜底 │ │ └──────────────────────────────────────┘ ├─→ 写入飞书知识库(供 RAG 检索) └─→ 在项目群发送复盘报告链接

跨部门编排的关键设计原则

原则说明实现方式
共享记忆是唯一数据总线Agent 之间不直接传参,而是通过共享记忆传递上下文每个阶段写入 shared/ 目录,下一阶段读取
并行优于串行无依赖关系的 Agent 任务并行执行阶段 2 中 PM Agent 和 Data Agent 并行
每个阶段有明确的输入/输出契约写入共享记忆的数据结构必须文档化编排文件中定义每个阶段的记忆键和字段
失败不阻塞主链路非关键阶段失败时标记”待补充”,不阻塞后续Data Agent 查询超时不影响缺陷创建和修复
全链路可追溯每个阶段的操作都记录 traceId所有共享记忆文件包含 traceId 字段

共享记忆的数据契约

跨部门协作中,共享记忆的数据结构必须明确定义,否则 Agent 之间会”鸡同鸭讲”:

# 共享记忆数据契约 ## incident_{id}.md 写入方:Dev Agent(ops-alert-handle) 读取方:PM Agent, Data Agent, Team Agent 字段: - severity: S0 | S1 | S2 | S3 - service: 受影响的服务名 - error: 错误描述 - affected_feature: 受影响的功能 - start_time: 故障开始时间 - reporter: 报告人 ## incident_{id}_impact.md 写入方:Data Agent(analytics-sql-query) 读取方:PM Agent, Team Agent 字段: - affected_users: 受影响用户数 - failed_requests: 失败请求数 - duration: 影响时长 - estimated_data_loss: 数据损失评估 ## incident_{id}_resolution.md 写入方:Data Agent(analytics-sql-query) 读取方:Team Agent 字段: - error_rate_before: 修复前错误率 - error_rate_after: 修复后错误率 - resolved: true | false - fix_duration: 修复耗时

委派权限矩阵(完整版)

更新 3.4 节的委派配置,覆盖跨部门场景:

{ "delegations": { "pm-agent": { "can_delegate_to": ["dev-agent", "data-agent", "team-agent"], "max_depth": 2 }, "dev-agent": { "can_delegate_to": ["pm-agent", "data-agent", "team-agent"], "max_depth": 2 }, "data-agent": { "can_delegate_to": ["pm-agent", "team-agent"], "max_depth": 1 }, "team-agent": { "can_delegate_to": ["dev-agent", "data-agent", "pm-agent"], "max_depth": 2 } } }

与 3.4 节的区别:

  • Dev Agent 新增委派 Data Agent 和 Team Agent 的权限(故障场景需要)
  • PM Agent 新增委派 Team Agent 的权限(需求关联 OKR 场景)
  • Team Agent 新增委派 PM Agent 的权限(OKR 复盘→需求规划场景)

多 Agent 调试与排错

跨部门协作链路长,出问题时排查难度大。以下是常见问题和排查方法:

问题表现排查方法
委派超时Agent A 委派 Agent B 后长时间无响应查看 Agent B 的日志,检查 Skill 执行状态
共享记忆数据缺失Agent B 读取共享记忆时找不到预期字段检查 Agent A 是否正确写入,核对数据契约
循环委派A→B→A→B 无限循环检查 max_depth 配置,日志中搜索 delegation_depth
路由错误消息被路由到错误的 Agent检查 Router Agent 的路由日志,调整 keywords
并行任务部分失败并行的两个 Agent 一个成功一个失败检查失败 Agent 的日志,确认是否影响主链路

排查命令:

# 查看某个 incident 的全链路日志 cat .openclaw/logs/audit.log | \ jq 'select(.input | test("inc001")) or select(.memoryWrites[]? | test("incident_inc001"))' # 查看委派链路 cat .openclaw/logs/audit.log | \ jq 'select(.event == "delegation") | {from, to, task, status, duration}' # 查看共享记忆的读写记录 cat .openclaw/logs/audit.log | \ jq 'select(.memoryWrites[]? | test("shared/")) | {skill, memoryWrites, timestamp}' # 检查是否有循环委派 cat .openclaw/logs/audit.log | \ jq 'select(.event == "delegation" and .depth > 1) | {from, to, depth, traceId}'

更多跨部门场景编排模板

除了线上故障,以下场景也可以用类似模式编排:

场景 2:运营驱动的产品改进

Data Agent: 发现课程完成率下降 10% ├─→ 写入共享记忆:growth_alert_{id} ├─→ 委派 PM Agent: 创建改进需求 │ │ │ ▼ │ PM Agent: 创建需求 + 生成 PRD │ ├─→ 委派 Dev Agent: 创建 Issue │ └─→ 写入共享记忆:requirement_{id} └─→ 需求上线后,Data Agent 自动验证效果 ├─→ 对比改进前后的完成率 └─→ 写入共享记忆:growth_alert_{id}_result

场景 3:新员工入职全链路

Team Agent: 检测到人员表新增记录 ├─→ 执行入职 Checklist ├─→ 委派 Dev Agent: 开通 GitHub 权限 │ └─→ 返回:权限已开通 ├─→ 委派 PM Agent: 分配首个任务 │ └─→ 从需求表中选择适合新人的 P3 任务 └─→ 一周后自动触发:生成新员工首周总结 ├─→ 委派 Data Agent: 查询新员工的代码提交和 PR 数据 └─→ 汇总首周表现报告,发送给直属管理者

场景 4:季度 OKR 复盘→下季度规划

Team Agent: 季度末触发 OKR 复盘 ├─→ 读取 OKR 表,汇总各 KR 进度 ├─→ 委派 Data Agent: 用数据验证 KR 达成情况 │ ├─→ 查询用户增长数据(验证增长类 KR) │ ├─→ 查询课程完成率(验证产品类 KR) │ └─→ 返回数据验证结果 ├─→ 生成 OKR 复盘报告 ├─→ 委派 PM Agent: 基于复盘结果生成下季度需求建议 │ └─→ 从未完成的 KR 中提取需求方向 └─→ 发送复盘报告 + 需求建议到管理层群

4. 版本管理与 Git 工作流

3.1 仓库结构

Skill 文件纳入 Git 管理,与 OpenClaw 配置一起维护:

hackquest-agent/ ← Git 仓库根目录 ├── .openclaw/config.json ├── skills/ ← Skill 文件(核心资产) ├── mcp/servers.json ├── .github/ │ └── workflows/ │ └── skill-review.yml ← Skill 变更自动检查 ├── .gitignore ← 忽略 memory/ 和 logs/ └── README.md

.gitignore

.openclaw/memory/ .openclaw/logs/ .env node_modules/

3.2 分支策略

main ← 生产环境 Skill(daemon 从此分支加载) └── develop ← 开发集成分支 ├── feature/skill-requirement-create ← 新 Skill 开发 ├── fix/skill-bug-create-format ← Skill 修复 └── improve/skill-analytics-sql-query ← Skill 优化

3.3 Skill 变更流程

1. 创建分支 git checkout -b feature/skill-xxx develop 2. 编写/修改 Skill 编辑 skills/xxx/xxx.md 3. 本地测试 openclaw skill test skills/xxx/xxx.md 4. 提交 PR git push origin feature/skill-xxx → 创建 PR 到 develop 5. Code Review → 至少 1 人审阅 → 检查 Skill 模板完整性 → 检查权限声明 6. 合并到 develop → 测试环境验证 7. 合并到 main → 生产环境自动热更新

3.4 GitHub Actions 自动检查

创建 .github/workflows/skill-review.yml

name: Skill Review on: pull_request: paths: - 'skills/**/*.md' jobs: check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Check Skill Template run: | for file in $(git diff --name-only origin/main -- 'skills/**/*.md'); do echo "Checking $file..." # 检查必须包含的章节 for section in "# " "## 触发条件" "## 执行步骤" "## 输出格式" "## 权限要求"; do if ! grep -q "$section" "$file"; then echo "❌ Missing section: $section in $file" exit 1 fi done echo "✅ $file passed template check" done - name: Check Naming Convention run: | for file in $(git diff --name-only origin/main -- 'skills/**/*.md'); do filename=$(basename "$file" .md) # 检查命名格式:组名-动作-对象 if ! echo "$filename" | grep -qE '^[a-z]+-[a-z]+-[a-z]+'; then # 允许共享 Skill 不遵循此规则 dir=$(dirname "$file") if [[ "$dir" != *"_shared"* ]]; then echo "⚠️ Warning: $filename doesn't follow naming convention {group}-{action}-{object}" fi fi done

5. 权限控制

4.1 角色定义

角色可调用的 Skill 组说明
管理员全部CTO、技术负责人
开发者requirement, code, knowledge开发团队成员
产品经理requirement, analytics, knowledge, growth产品团队
运维ops, analytics运维团队
运营analytics, growth, knowledge运营团队
人事teamHR
只读knowledge实习生、外部协作者

4.2 权限配置

在 OpenClaw 配置中定义角色与 Skill 组的映射:

{ "permissions": { "roles": { "admin": { "skills": ["*"], "approve": true }, "developer": { "skills": ["requirement/*", "code/*", "knowledge/*"], "approve": false }, "product": { "skills": ["requirement/*", "analytics/*", "knowledge/*", "growth/*"], "approve": false }, "ops": { "skills": ["ops/*", "analytics/*"], "approve": true }, "growth": { "skills": ["analytics/*", "growth/*", "knowledge/*"], "approve": false }, "hr": { "skills": ["team/*"], "approve": false }, "readonly": { "skills": ["knowledge/*"], "approve": false } }, "userRoles": { "ou_cto_id": "admin", "ou_dev_zhangsan": "developer", "ou_pm_lisi": "product", "ou_ops_wangwu": "ops" } } }

4.3 敏感操作二次确认

高风险 Skill 执行前需要人工确认:

Skill风险等级确认方式
ops-deploy-trigger飞书消息卡片确认按钮,需管理员点击
code-branch-manage(删除分支)飞书消息卡片确认
team-offboard需 HR 和管理员双重确认
requirement-create自动创建,状态设为”待确认”
analytics-sql-query只允许 SELECT 语句,自动拦截写操作

6. 热更新流程

OpenClaw 的 Skill 热更新是其核心优势之一。修改 Skill 文件后无需重启服务即可生效。

5.1 热更新流程

修改 skills/xxx.md OpenClaw 文件监听器检测到变更 重新解析变更的 Skill 文件 更新 Skill 路由表 新的消息使用更新后的 Skill (正在执行的 Skill 不受影响)

5.2 手动触发热更新

# 重新加载所有 Skill openclaw skill reload # 重新加载指定 Skill openclaw skill reload skills/requirement/requirement-create.md # 查看 Skill 加载状态 openclaw skill list --verbose

5.3 验证步骤

# 1. 修改 Skill 文件 vim skills/requirement/requirement-create.md # 2. 检查 Skill 是否已重新加载 openclaw skill status requirement-create # 3. 本地测试 openclaw chat > 创建一个测试需求 # 4. 确认输出符合预期后,提交到 Git git add skills/requirement/requirement-create.md git commit -m "improve: requirement-create output format"

5.4 回滚方案

如果热更新后 Skill 出现问题:

# 方案 1:Git 回滚 git checkout HEAD~1 -- skills/requirement/requirement-create.md # OpenClaw 自动检测文件变更并重新加载 # 方案 2:临时禁用 Skill openclaw skill disable requirement-create # 排查问题后重新启用 openclaw skill enable requirement-create

7. 监控与日志

6.1 Skill 执行指标

指标说明告警阈值
执行次数每个 Skill 的调用次数(日/周/月)
成功率成功执行 / 总执行< 90% 告警
平均耗时从触发到回复的时间> 30s 告警
Token 消耗每次执行的 LLM Token 用量单次 > 10K 告警
错误类型分布MCP 超时、权限不足、LLM 拒绝等

6.2 日志格式

OpenClaw 的 Skill 执行日志采用 JSON 结构化格式:

{ "timestamp": "2026-07-15T10:30:00Z", "level": "info", "skill": "requirement-create", "skillGroup": "requirement", "userId": "ou_dev_zhangsan", "userName": "张三", "trigger": "message", "input": "创建一个 P1 需求:新增 Solana 课程模块", "mcpCalls": [ { "server": "lark-mcp", "tool": "create_bitable_record", "duration": 1200, "status": "success" } ], "tokenUsage": { "input": 850, "output": 320 }, "duration": 3500, "status": "success", "output": "✅ 需求已创建:新增 Solana 课程模块 (P1)" }

6.3 监控 Skill

创建 skills/_shared/skill-monitor.md

# skill-monitor 生成 Skill 运行监控报告。 ## 触发条件 - 定时触发:每天 9:00 - 手动触发:用户消息包含"Skill 监控"、"Skill 报告" ## 执行步骤 1. 从 OpenClaw 日志中统计过去 24 小时的 Skill 执行数据 2. 计算每个 Skill 的执行次数、成功率、平均耗时 3. 识别异常 Skill(成功率 < 90% 或平均耗时 > 30s) 4. 生成监控报告并发送到运维群 ## 输出格式 📊 Skill 运行日报(2026-07-15) | Skill | 执行次数 | 成功率 | 平均耗时 | Token 消耗 | |-------|---------|--------|---------|-----------| ⚠️ 异常 Skill: - xxx:成功率 85%,主要错误:MCP 超时

8. 质量控制

7.1 Skill 模板约束

每个 Skill 文件必须通过以下检查才能合并到 main 分支:

检查项规则自动化
H1 标题必须存在,且与文件名一致✅ CI 检查
触发条件必须存在 ## 触发条件 章节✅ CI 检查
执行步骤必须存在 ## 执行步骤 章节,且包含编号列表✅ CI 检查
输出格式必须存在 ## 输出格式 章节✅ CI 检查
示例输出必须存在 ## 示例输出 章节(Few-shot)✅ CI 检查
权限要求必须存在 ## 权限要求 章节✅ CI 检查
错误处理建议存在 ## 错误处理 章节⚠️ CI 警告

7.2 输出 Schema 校验

对于结构化输出的 Skill(如创建记录、生成报表),在 Skill 文件中定义输出 Schema:

## 输出 Schema 输出必须包含以下字段: - title: string, 必填, 不超过 50 字 - priority: enum(P0, P1, P2, P3), 必填 - status: 固定为"待评审" - module: enum(课程, Hackathon, 社区, 基础设施, 运营), 必填 如果用户未提供优先级,默认为 P2。 如果用户未提供模块,根据需求内容自动推断。

7.3 Few-shot 示例要求

每个 Skill 至少提供 1 个完整的输入→输出示例,帮助 LLM 理解预期行为:

## 示例 ### 示例 1 **输入**: 创建一个需求:新增 Solana 课程模块,优先级 P1 **输出**: ✅ 需求已创建 - 标题:新增 Solana 课程模块 - 优先级:P1 - 状态:待评审 - 模块:课程 - 多维表格链接:[查看](https://xxx.feishu.cn/base/xxx) ### 示例 2 **输入**: 提一个 bug,Safari 上课程进度条显示不对 **输出**: ✅ 缺陷已创建 - 标题:课程进度条在 Safari 上显示异常 - 严重程度:S2(默认) - 状态:待确认 - 环境:生产 - 多维表格链接:[查看](https://xxx.feishu.cn/base/xxx) 请补充以下信息以便开发排查: 1. Safari 版本号? 2. 具体哪个课程页面? 3. 是否有截图?

7.4 Skill 评审 Checklist

Code Review 时使用的检查清单:

  • Skill 名称符合 {组名}-{动作}-{对象} 命名规范
  • 包含所有必填章节(触发条件、执行步骤、输出格式、示例输出、权限要求)
  • 触发条件明确,不与现有 Skill 严重冲突
  • 执行步骤中的 MCP 工具调用正确(工具名、参数)
  • 输出格式有明确约束(字段、长度、枚举值)
  • 至少 1 个 Few-shot 示例
  • 权限声明完整,遵循最小权限原则
  • 高风险操作有二次确认机制
  • 错误处理覆盖常见失败场景
  • 本地测试通过

下一篇: 37e RAG 知识库搭建 — 从飞书文档构建 RAG 知识库,实现团队知识的智能检索

Last updated on