从单个工作流到体系
一个工作流很好管理。五个工作流开始出现问题：
- 用户不知道某个工作流的存在，或找不到正确的那个
- 两个工作流做的事情 70% 重叠，维护成本翻倍
- 某个团队修改了共享工作流，影响了所有依赖方
- 出了问题不知道是哪个版本的工作流导致的
Workflow Registry 解决发现问题，工作流组合解决重叠问题，治理机制解决修改和追责问题。
Workflow Registry
Skill Registry 管理单个 Skill 的发现，Workflow Registry 管理工作流的发现。
yaml
# workflow-registry.yaml
workflows:
- id: wf-bug-e2e
name: Bug 端到端修复
description: "从 Jira 工单触发，自动分析根因、生成修复代码、提交 Review"
version: "1.3.0"
trigger_keywords:
- 处理Bug
- 修复Bug
- 自动修复
domain: engineering
owner: "@chendongqi"
status: active
metrics:
monthly_runs: 45
e2e_success_rate: 0.82
avg_fix_rounds: 1.3
avg_cost_usd: 0.51
- id: wf-sprint-planning
name: 每周冲刺规划
description: "每周一自动触发，汇总 P0/P1 Bug 状态，生成本周工作计划"
version: "1.0.0"
trigger_keywords:
- 周计划
- 冲刺规划
domain: management
owner: "@team-lead"
status: active
metrics:
monthly_runs: 4
e2e_success_rate: 1.0
- id: wf-code-review-assist
name: 代码 Review 辅助
description: "Gerrit change 提交后自动分析代码质量，生成 Review 意见"
version: "0.5.0"
status: experimental # 实验性，不作为生产依赖Registry 的三个用途
用途 1：Workflow 发现
用户输入"帮我处理这个 Bug"，系统通过 trigger_keywords 匹配直接找到 wf-bug-e2e，自动路由，不需要用户从列表里选。
用途 2：监控看板
把 metrics 字段持续更新，就能做一个跨工作流的健康看板：
bash
Workflow 运行次数 成功率 平均成本
────────────────────────────────────────────────
wf-bug-e2e 45/月 82% $0.51
wf-sprint-planning 4/月 100% $0.08
wf-code-review-assist 12/月 67% $0.23 ← 成功率低，需要关注用途 3：版本依赖追踪
当 wf-sprint-planning 调用 wf-bug-e2e（见下一节），Registry 记录这个依赖关系。wf-bug-e2e 发布 MAJOR 版本时，系统可以检查哪些工作流依赖它，通知相关 owner。
工作流组合
工作流组合（Workflow Composition）是让一个工作流调用另一个工作流。
场景： wf-sprint-planning 每周一运行，需要对当前所有 P0 Bug 触发 wf-bug-e2e，等待结果后生成周计划报告。
markdown
# wf-sprint-planning/workflow.md
## Phase 2：处理 P0 Bug
对 phase_1 获取到的每个 P0 Bug，触发 wf-bug-e2e：
```yaml
phase_2_fix_p0:
type: workflow_fanout # 触发多个子工作流
child_workflow: wf-bug-e2e
inputs:
- source: phases.phase1.p0_bugs
map_to: jira_key
wait_strategy: collect-all # 等待全部完成
timeout: 4h
on_timeout: continue_with_available # 超时的继续，已完成的汇总Phase 3：生成周计划
基于 phase_2 的结果（每个 Bug 的修复状态）生成周计划报告。
yaml
**子工作流的接口设计：**
子工作流和子 Agent 一样，需要有输入契约和输出契约：
```yaml
# wf-bug-e2e 的对外接口声明（在 SKILL.md 里）
interface:
inputs:
- name: jira_key
type: string
required: true
outputs:
- path: workflow_state.json
fields:
- fix_result.passed
- fix_result.commit_sha
- fix_result.summary
- total_cost_usd父工作流只读取声明了的输出字段，不读取子工作流的内部状态文件。
跨工具可移植性
同一个工作流，在 OpenClaw 环境里调用 Claude Code 工具，在另一个环境里调用不同的工具实现------工作流定义本身不变。
yaml
# config.yaml 的 tool_bindings 配置
tool_bindings:
read_file:
openclaw: "claude_code_read"
generic: "python:open"
create_cron:
openclaw: "claude_code_cron"
generic: "python:crontab"
send_notification:
openclaw: "lark-im"
generic: "slack-webhook"
markdown
# workflow.md 里只写能力名，不写工具名
Phase 6 Step 6.1：创建定时轮询任务（capability: create_cron）
Phase 7 Step 7.2：发送结案通知（capability: send_notification）
python
# 执行时解析能力名到具体工具
def resolve_tool(capability: str, runtime: str) -> str:
return config["tool_bindings"][capability][runtime]
tool = resolve_tool("create_cron", current_runtime) # 当前运行时这个设计让工作流定义与执行环境解耦。换部署环境时，只改 config.yaml 的 runtime 设置，不改工作流逻辑。
三层治理机制
工作流进入生产后，需要回答三个问题：
问题 1：谁可以修改工作流？
个人工作流（owner 只有自己）：
→ 可以自由修改，不需要 review
团队共享工作流（owner 是团队）：
→ PATCH/MINOR 版本：至少 1 人 review，CI 通过后合并
→ MAJOR 版本：至少 2 人 review + 运行 Gate 3（端到端回归）
生产关键工作流（直接影响业务）：
→ 任何变更需要 owner + 业务方联合 review
→ 生产环境的工作流文件只读，通过发布流程更新（不能直接编辑）技术实现： 用 git 的 CODEOWNERS 文件声明 workflow 文件的 review 权限：
perl
# .github/CODEOWNERS
skills/wf-bug-e2e/** @chendongqi @team-lead
skills/wf-sprint-planning/** @team-lead问题 2：工作流执行了什么，谁来负责？
每次工作流完成后写 audit.json（W6 篇已经讲过），在此基础上增加责任链信息：
json
{
"workflow_id": "wf-bug-e2e-AE-33995-20260601",
"workflow_version": "1.3.0",
"triggered_by": "user:chendongqi",
"triggered_at": "2026-06-01T10:00:00+08:00",
"outcome": "success",
"external_writes": [
{"action": "git_push", "target": "gerrit/android-project", "phase": 5},
{"action": "jira_comment", "target": "AE-33995", "phase": 7}
],
"human_gates_triggered": ["gate_B"],
"human_approvals": [
{"gate": "gate_B", "approver": "user:zhang3", "at": "2026-06-01T11:30:00+08:00"}
],
"cost_usd": 0.51
}责任链：触发者 → 工作流版本 → 执行的 Phase → 人工确认人。任何外部写操作都可以追溯到具体的人和具体的工作流版本。
问题 3：出了问题如何快速回滚？
版本快照机制：
bash
# 发布新版本前，保存旧版本快照
cp -r skills/wf-bug-e2e skills/wf-bug-e2e.v1.2.0.bak
# 发现问题后，回滚到旧版本
cp -r skills/wf-bug-e2e.v1.2.0.bak skills/wf-bug-e2e
# 更新 SKILL.md 的版本号到旧版本
sed -i 's/version: "1.3.0"/version: "1.2.0"/' skills/wf-bug-e2e/SKILL.md更规范的做法： 在 git 里打版本 tag：
bash
# 发布时打 tag
git tag wf-bug-e2e-v1.3.0
# 回滚时 checkout 旧 tag 的文件
git checkout wf-bug-e2e-v1.2.0 -- skills/wf-bug-e2e/已在运行的工作流的处理：
回滚发布版本后，仍在运行（status != done）的工作流实例用哪个版本继续？
python
def handle_in_flight_on_rollback(state_dir: Path, old_version: str, new_version: str):
for state_file in state_dir.glob("**/workflow_state.json"):
state = json.loads(state_file.read_text())
if state["workflow_version"] == new_version and state.get("phase") != "done":
# 仍在运行的实例，通知 owner 决定如何处理
notify_owner(
f"In-flight workflow {state['workflow_id']} is using "
f"rolled-back version {new_version}. "
f"Options: 1) Let it complete with current version "
f"2) Abort and restart with {old_version}"
)Workflow Marketplace（进阶）
当企业内有足够多的工作流时，可以建立一个内部的 Workflow Marketplace：
功能：
→ 浏览可用的工作流（分 domain、状态、所有者）
→ 查看每个工作流的使用指南和接口文档
→ 给工作流评分和留评论
→ Fork 一个现有工作流，修改后发布为新工作流
类比：
→ npm registry（发现和复用 packages）
→ Anthropic Claude.ai 的 Skills marketplace实现上不需要复杂的系统，workflow-registry.yaml + 一个搜索界面就够。
落地路线图
lua
Level 1 --- 个人（立即可做）：
□ 创建 workflow-registry.yaml，列出所有现有工作流
□ 每个工作流填写 domain、owner、status、trigger_keywords
Level 2 --- 团队（1-2 周）：
□ git CODEOWNERS 声明 review 权限
□ 每次修改前写 CHANGELOG（W7 篇），记录修改原因
□ 团队共享工作流的 MAJOR 变更走双人 review
Level 3 --- 企业（持续建设）：
□ Registry metrics 持续更新，建立跨工作流健康看板
□ 关键工作流有完整的审计日志
□ 版本 tag + 快照，1 小时内可回滚任意版本总结
- Registry 是发现和监控的基础：没有 Registry，工作流增多后变成黑盒；有了 Registry，每个工作流的状态、成本、成功率一目了然，也支持 trigger_keywords 的自动路由
- 工作流组合让体系有层次：父工作流（冲刺规划）调用子工作流（Bug 修复），形成两层结构；子工作流需要声明输入输出契约，和子 Agent 的设计原则完全一致
- 治理的三个问题各有答案：修改权限用 CODEOWNERS + review 流程控制；责任链用 audit.json 记录触发者、版本、人工确认人；回滚用 git tag 实现，加上对在途实例的通知机制
欢迎访问 PrimeSkills ------ 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页