管道技能Skill pipeline

---

name: pipeline description: 将多个代理在顺序或分支工作流中串联起来，实现数据传递

管道技能

概述

管道技能使多个代理能够在定义的工作流中串联，其中一个代理的输出成为下一个代理的输入。这创建了强大的代理管道，类似于Unix管道，但专为AI代理编排而设计。

核心概念

1. 顺序管道

最简单的形式：代理A的输出流向代理B，然后流向代理C。

explore -> architect -> executor

流程:

1. 探索代理搜索代码库并生成发现
2. 架构师接收发现并生成分析/建议
3. 执行器接收建议并实施更改

2. 分支管道

根据输出条件路由到不同的代理。

explore -> {
  if "复杂重构" -> architect -> executor-high
  if "简单更改" -> executor-low
  if "UI工作" -> designer -> executor
}

3. 并行-合并管道

并行运行多个代理，合并它们的输出。

parallel(explore, document-specialist) -> architect -> executor

内置管道预设

审查管道

目的: 全面的代码审查和实施

/pipeline review <任务>

阶段:

1. explore - 查找相关代码和模式
2. architect - 分析架构和设计影响
3. critic - 审查和批评分析
4. executor - 在完整上下文中实施

适用于: 主要功能、重构、复杂更改

---

实施管道

目的: 有计划地实施和测试

/pipeline implement <任务>

阶段:

1. planner - 创建详细的实施计划
2. executor - 实施计划
3. tdd-guide - 添加/验证测试

适用于: 有明确需求的新功能

---

调试管道

目的: 系统化调试工作流

/pipeline debug <问题>

阶段:

1. explore - 定位错误位置和相关代码
2. architect - 分析根本原因
3. build-fixer - 应用修复并验证

适用于: 错误、构建错误、测试失败

---

研究管道

目的: 外部研究 + 内部分析

/pipeline research <主题>

阶段:

1. parallel(document-specialist, explore) - 外部文档 + 内部代码
2. architect - 综合发现
3. writer - 记录建议

适用于: 技术决策、API集成

---

重构管道

目的: 安全、已验证的重构

/pipeline refactor <目标>

阶段:

1. explore - 查找所有使用和依赖项
2. architect-medium - 设计重构策略
3. executor-high - 执行重构
4. qa-tester - 验证无回归

适用于: 架构更改、API重新设计

---

安全管道

目的: 安全审计和修复

/pipeline security <范围>

阶段:

1. explore - 查找潜在漏洞
2. security-reviewer - 审计并识别问题
3. executor - 实施修复
4. security-reviewer-low - 重新验证

适用于: 安全审查、漏洞修复

---

自定义管道语法

基本顺序

/pipeline agent1 -> agent2 -> agent3 "任务描述"

示例:

/pipeline explore -> architect -> executor "添加认证"

指定模型

/pipeline explore:haiku -> architect:opus -> executor:sonnet "优化性能"

带有分支

/pipeline explore -> (
  complexity:high -> architect:opus -> executor-high:opus
  complexity:medium -> executor:sonnet
  complexity:low -> executor-low:haiku
) "修复报告问题"

带有并行阶段

/pipeline [explore, document-specialist] -> architect -> executor "实现OAuth"

数据传递协议

管道中的每个代理接收来自前一阶段的结构化上下文：

{
  "pipeline_context": {
    "original_task": "用户的原始请求",
    "previous_stages": [
      {
        "agent": "explore",
        "model": "haiku",
        "findings": "...",
        "files_identified": ["src/auth.ts", "src/user.ts"]
      }
    ],
    "current_stage": "architect",
    "next_stage": "executor"
  },
  "task": "此代理的具体任务"
}

错误处理

重试逻辑

当代理失败时，管道可以：

1. 重试 - 重新运行同一代理（最多3次）
2. 跳过 - 继续到下一阶段，使用部分输出
3. 中止 - 停止整个管道
4. 回退 - 路由到替代代理

配置:

/pipeline explore -> architect -> executor --retry=3 --on-error=abort

错误恢复模式

模式1: 回退到更高层级

executor-low -> on-error -> executor:sonnet

模式2: 咨询架构师

executor -> on-error -> architect -> executor

模式3: 人机交互

any-stage -> on-error -> pause-for-user-input

管道状态管理

管道在.omc/pipeline-state.json中维护状态：

{
  "pipeline_id": "uuid",
  "name": "review",
  "active": true,
  "current_stage": 2,
  "stages": [
    {
      "name": "explore",
      "agent": "explore",
      "model": "haiku",
      "status": "completed",
      "output": "..."
    },
    {
      "name": "architect",
      "agent": "architect",
      "model": "opus",
      "status": "in_progress",
      "started_at": "2026-01-23T10:30:00Z"
    },
    {
      "name": "executor",
      "agent": "executor",
      "model": "sonnet",
      "status": "pending"
    }
  ],
  "task": "原始用户任务",
  "created_at": "2026-01-23T10:25:00Z"
}

验证规则

在管道完成前，验证：

• [ ] 所有阶段成功完成
• [ ] 最终阶段的输出处理原始任务
• [ ] 没有未处理的错误在任何阶段
• [ ] 所有修改的文件通过lsp_diagnostics
• [ ] 测试通过（如果适用）

高级功能

条件分支

基于代理输出，路由到不同路径：

explore -> {
  if files_found > 5 -> architect:opus -> executor-high:opus
  if files_found <= 5 -> executor:sonnet
}

循环结构

重复阶段直到满足条件：

repeat_until(tests_pass) {
  executor -> qa-tester
}

合并策略

当并行代理完成时：

• concat: 连接所有输出
• summarize: 使用架构师总结发现
• vote: 使用评论家选择最佳输出

使用示例

示例1: 功能实施

/pipeline review "添加API限流"

→ 触发：explore → architect → critic → executor

示例2: 错误修复

/pipeline debug "OAuth登录失败"

→ 触发：explore → architect → build-fixer

示例3: 自定义链

/pipeline explore:haiku -> architect:opus -> executor:sonnet -> tdd-guide:sonnet "重构认证模块"

示例4: 研究驱动实施

/pipeline research "实现GraphQL订阅"

→ 触发：parallel(document-specialist, explore) → architect → writer

取消

停止活动管道：

/pipeline cancel

或使用通用取消命令检测活动管道。

与其他技能集成

管道可以在其他技能中使用：

• Ralph: 循环管道直到验证完成
• Ultrawork: 并行运行多个管道
• Autopilot: 使用管道作为构建块

最佳实践

1. 从预设开始 - 在创建自定义管道前使用内置管道
2. 匹配模型到复杂度 - 不要浪费opus在简单任务上
3. 保持阶段专注 - 每个代理应有一个清晰的职责
4. 使用并行阶段 - 同时运行独立工作
5. 在检查点验证 - 使用架构师或评论家验证进展
6. 记录自定义管道 - 保存成功模式以供重用

故障排除

管道挂起

检查: .omc/pipeline-state.json 中的当前阶段 修复: 使用/pipeline resume恢复或取消并重新开始

代理反复失败

检查: 重试计数和错误消息 修复: 路由到更高层级代理或添加架构师咨询

输出不流动

检查: 代理提示中的数据传递结构 修复: 确保每个代理都提示有pipeline_context

技术实现

管道编排器：

1. 解析管道定义 - 验证语法和代理名称
2. 初始化状态 - 创建pipeline-state.json
3. 顺序执行阶段 - 使用Task工具生成代理
4. 在阶段之间传递上下文 - 为下一个代理构建输出
5. 处理分支逻辑 - 评估条件和路由
6. 管理并行执行 - 生成并发代理并合并
7. 持久化状态 - 在每个阶段后更新状态文件
8. 强制执行验证 - 完成前运行检查

完成时状态清理

重要: 在完成时删除状态文件 - 不要只设置active: false

当管道完成（所有阶段完成或取消）：

# 删除管道状态文件
rm -f .omc/state/pipeline-state.json

这确保未来会话的干净状态。不应留下带有active: false的陈旧状态文件。

技能调用

此技能在以下情况下激活：

• 用户输入/pipeline命令
• 用户提到"代理链"、“工作流”、“管道代理”
• 检测到模式：带有代理名称的"X然后Y然后Z"

显式调用:

/oh-my-claudecode:pipeline review "任务"

自动检测:

"首先探索代码库，然后架构师分析它，然后执行器实施"

→ 自动创建管道：explore → architect → executor