顺序管道
数据按固定顺序流经多个处理阶段，每个阶段只处理一件事的架构模式
简介
顺序管道（Sequential Pipeline）是一种将复杂处理流程拆解为多个顺序执行阶段的架构模式。数据从第一个阶段进入，经过一系列转换后从最后一个阶段输出，每个阶段只负责一个明确的处理任务。
在 Multi-Agent 系统中，顺序管道是最常见的协同模式之一——每个 Agent 是管道中的一个阶段，只在前置 Agent 完成后启动，处理完后将结果传递给下一个 Agent。
这种模式特别适合有明确先后依赖关系的流程，例如数据必须先清洗再分类，必须先分类再对账。
关键信息
- 类型：架构模式 / 工作流模式
- 领域：系统设计 / 数据处理 / Multi-Agent 协同
- 核心原则：单一职责、顺序执行、数据流转
- 典型应用：数据处理管道、审批流程、内容生产流水线
- 相关概念：Multi-Agent 系统、AI Agent 智能体、工作流设计
核心特性
1. 顺序执行（Sequential Execution）
每个阶段严格按顺序执行，后一个阶段只在前一个阶段完成后启动。
典型流程（会计管道）：
原始数据 → [数据准备] → 标准化数据 → [分类] → 分类数据 → [对账] → 对账报告 → [报告] → 财务报表 → [洞察] → 业务洞察
每个箭头表示数据的流转，每个方括号表示一个处理阶段。
2. 单一职责（Single Responsibility）
每个阶段只负责一件事，不承担其他职责。
职责边界示例：
- 数据准备阶段：只标准化格式（日期、货币、字段），不分类、不验证业务逻辑
- 分类阶段：只给每条记录打上类别标签，不修改原始数据、不做汇总
- 对账阶段：只标记差异（重复、缺失、不匹配），不修改数据、不强行对齐
- 报告阶段：只聚合数字（总收入、总支出、分类汇总），不做解读、不给建议
- 洞察阶段：只解读数字背后的业务含义，不修改报告数据
职责边界清晰带来的好处：
- 每个阶段可独立测试
- 出问题时可快速定位责任
- 可替换单个阶段而不影响其他
3. 数据流转（Data Flow）
每个阶段的输出是下一个阶段的输入，数据像水流一样在管道中流转。
流转机制：
- 共享文件夹：阶段 A 写入
data/cleaned/，阶段 B 读取data/cleaned/并写入data/categorized/ - 消息队列：阶段 A 将结果推送到队列，阶段 B 从队列拉取
- 函数返回值：阶段 A 函数返回数据，直接作为阶段 B 函数的输入参数
数据格式标准化：
- 每个阶段的输出格式必须明确定义（JSON schema、CSV 列定义）
- 后续阶段只能依赖前置阶段的输出格式，不能依赖实现细节
4. 可测试性（Testability）
顺序管道天然支持分阶段测试：
- 准备测试输入 → 运行阶段 A → 检查输出是否符合预期
- 用阶段 A 的输出 → 运行阶段 B → 检查输出是否符合预期
- 逐个阶段验证后，再测试端到端流程
这比测试一个”全能黑盒”容易得多，出问题时也能快速定位是哪个阶段的责任。
不同素材中的观点
来自 2026-06-03-claude-code-multi-agent-accounting：
- 顺序管道适合规则驱动的业务流程：会计流程的每个步骤都是规则驱动（清洗按规则、分类按规则、对账按规则），规则+结构+顺序正是顺序管道擅长的场景。任何有明确规则、步骤、数据流转的业务流程都可以参考这个架构
- 5 Agent 顺序管道的实际案例：数据准备 → 分类 → 对账 → 报告 → 洞察，每个 Agent 通过共享
data/文件夹传递数据。这种设计使得从原始银行对账单到业务洞察实现了端到端自动化，每个 Agent 可独立开发和测试 - 职责边界是管道顺畅运行的关键：每个阶段明确”只做什么”和”不做什么”——数据准备只清洗不分类，对账只标记差异不修改数据，报告只聚合数字不做解读。职责混乱会导致管道难以维护和调试
- 逐个构建+测试是正确开发方式：不要一次性构建 5 个阶段后再测试，而是阶段 1 → 测试 → 阶段 2 → 测试 → … 的渐进式构建。这避免了在管道末端才发现前置阶段的问题
- 项目基础决定管道能否顺利运行：在写任何代码之前先建立共享工作区（
data/文件夹）、项目文档（CLAUDE.md）、规范指南、每个阶段的详细规格。这些基础比单个阶段的代码质量更重要
实用信息
设计顺序管道的步骤
-
识别处理阶段：
- 任务可以拆解为哪些明确的步骤？
- 每个步骤的输入输出是什么？
- 步骤之间的依赖关系是什么？
-
定义职责边界：
- 为每个阶段写清楚”只做什么”和”不做什么”
- 确保职责不重叠、不遗漏
- 每个阶段应该可以独立测试
-
标准化数据格式：
- 定义每个阶段的输入输出格式（JSON schema、CSV 列）
- 设计共享存储机制（文件夹、数据库、消息队列）
- 明确数据的命名规范和目录结构
-
逐个实现和测试：
- 先实现第一个阶段，用真实数据测试
- 再实现第二个阶段，测试与第一个的集成
- 逐步添加阶段，每次都验证端到端流程
-
记录管道架构：
- 画出数据流图：阶段 A → 阶段 B → 阶段 C
- 记录每个阶段的职责、输入格式、输出格式
- 写清楚异常处理策略（某个阶段失败时怎么办）
典型应用场景
数据处理管道：
原始数据采集 → 数据清洗 → 格式转换 → 数据验证 → 加载到数据库
内容生产流水线：
素材收集 → 初稿生成 → 编辑润色 → 格式排版 → 审核 → 发布
审批流程自动化：
申请提交 → 资格检查 → 一级审批 → 二级审批 → 归档存储 → 结果通知
机器学习训练管道：
数据采集 → 数据清洗 → 特征工程 → 模型训练 → 模型评估 → 模型部署
注意事项/避坑指南
- 不要把所有逻辑塞进一个阶段：如果某个阶段做了 3 件以上不同的事，考虑拆分为多个阶段
- 阶段之间不要有隐式依赖：阶段 B 不应该依赖阶段 A 的实现细节，只能依赖 A 的输出格式
- 数据格式变化要同步更新文档：如果阶段 A 的输出格式改了，必须更新文档并检查阶段 B 是否受影响
- 准备异常处理策略：如果某个阶段失败了（数据格式错误、处理超时），整个管道是重试、跳过还是中止？
- 避免阶段之间的循环依赖：顺序管道应该是单向的，不要让阶段 C 的输出又回到阶段 A
- 记录每个阶段的性能指标：哪个阶段耗时最长？哪个阶段失败率最高？这些指标帮助优化管道
顺序管道 vs 并行管道
顺序管道：
- 适合有先后依赖关系的流程（必须先清洗再分类）
- 每个阶段按顺序执行
- 数据像水流一样单向流转
并行管道：
- 适合无依赖关系的批量任务（同时处理 100 个文件）
- 多个阶段同时执行
- 需要最后汇总结果
大多数实际系统会混用两种模式：
原始数据 → [清洗] → 清洗后数据 → [并行分类 × 10] → 分类结果 → [汇总] → 最终报告