cfdaily
672 lines
30 KiB
Markdown
672 lines
30 KiB
Markdown
# v2.8 Pipeline 架构设计
|
||
|
||
**版本**: v2.0
|
||
**日期**: 2026-05-27
|
||
**作者**: 庞统
|
||
**状态**: 调研完成 → 设计提案 v2.0，待用户确认
|
||
|
||
> v1.0→v2.0 变更：补充执行模式调研（parallel/loop/saga/interactive/event-driven），补充场景×执行模式映射表，明确业务类型 vs 执行模式的分层关系。
|
||
|
||
---
|
||
|
||
## 1. 设计目标
|
||
|
||
1. **消灭 46 处 if/_mail 分支**（ticker 14 + dispatcher 23 + spawner 9）
|
||
2. **不同 task_type 走不同执行路径**（代码评审不需要 planning，数据下载不需要路由）
|
||
3. **新增 task_type 只加配置不改核心代码**（Plugin/Registry）
|
||
4. **执行模式是有限的几种，业务类型无限扩展**（用户选业务类型，系统映射到执行模式）
|
||
|
||
---
|
||
|
||
## 2. 两层抽象：业务类型 vs 执行模式
|
||
|
||
### 2.1 概念
|
||
|
||
| 层 | 定义 | 谁选 | 数量 | 例子 |
|
||
|----|------|------|------|------|
|
||
| **业务类型**（task_type） | 用户视角的"做什么" | 用户创建任务时选 | 无限扩展 | coding, review, data, deploy, research, discuss, data_collect, risk_patrol, ... |
|
||
| **执行模式**（execution_pattern） | 系统视角的"怎么跑" | YAML Profile 声明 | 有限（~7种） | single_step, multi_step, parallel, loop, saga, interactive, event_trigger |
|
||
|
||
### 2.2 映射关系
|
||
|
||
```yaml
|
||
# config/pipelines/review.yaml
|
||
task_type: review # 业务类型（用户视角）
|
||
execution_pattern: single_step # 执行模式（系统视角）
|
||
```
|
||
|
||
**业务类型无限扩展，执行模式有限**。新增业务类型 = 新增一个 YAML。新增执行模式 = 新增代码。
|
||
|
||
---
|
||
|
||
## 3. 执行模式调研
|
||
|
||
> 每种模式的结论来自外部来源，不自己发明。
|
||
|
||
### 3.1 single_step（单步执行）
|
||
|
||
**描述**：一个 agent 一次 spawn 就完成。
|
||
|
||
**适用场景**：代码评审、数据下载、Mail 投递、异常监控告警。
|
||
|
||
**优秀实践**：
|
||
- Temporal 的 Activity 概念——原子操作，独立执行，失败可重试（来源：Temporal docs）
|
||
- Hermes Kanban 的 `todo → ready → claimed → running → done` 生命周期——单步但状态完整（来源：知识库 hermes-agent）
|
||
- OpenClaw Lobster 单步 command——`exec --shell 'cmd --json'`（来源：`/opt/homebrew/lib/node_modules/openclaw/docs/tools/lobster.md`）
|
||
|
||
**关键设计点**：
|
||
- 完成 ≠ 成功：需要 verification（如检查产出文件是否存在）
|
||
- 失败可重试，但有上限
|
||
|
||
### 3.2 multi_step（多步串行）
|
||
|
||
**描述**：多个 stage 依次执行，前一步的输出是后一步的输入。
|
||
|
||
**适用场景**：编码（plan→implement→verify）、调研（plan→research→report）、部署（build→test→deploy）。
|
||
|
||
**优秀实践**：
|
||
- Lobster 的 `steps` + `stdin: $step.stdout` 管道——声明式步骤链，步骤间 JSON 管道传递（来源：`lobster.md`）
|
||
- OpenClaw TaskFlow——持久化多步 flow 管理，跨 gateway 重启（来源：`taskflow.md`）
|
||
- Temporal Workflow——步骤自动持久化，不怕进程重启（来源：Temporal docs）
|
||
|
||
**关键设计点**：
|
||
- 步骤间数据传递：通过 DB（stages_json）或 prompt 注入前序 stage 的 output
|
||
- 每个 stage 对应一次 agent spawn
|
||
- 中间 stage 失败 → 可从当前 stage 重试（不需要从头开始）
|
||
|
||
### 3.3 parallel（并行执行 / Fan-Out / Scatter-Gather）
|
||
|
||
**描述**：同一个任务拆成多个子任务并行执行，结果汇聚。
|
||
|
||
**适用场景**：批量回测（N 组参数）、并行协作（张飞写代码 + 关羽做风控）、多角度评审（乐观/悲观/务实三路并行）。
|
||
|
||
**优秀实践**：
|
||
|
||
| 来源 | 做法 | 关键点 |
|
||
|------|------|--------|
|
||
| **AWS Prescriptive Guidance** | scatter-gather：分发→并行执行→汇聚 | "sends tasks to multiple services in parallel, waits for responses, aggregates results"（web_search 摘要） |
|
||
| **Azure Architecture Center** | concurrent orchestration / fan-out-fan-in / map-reduce | "also known as parallel, fan-out/fan-in, scatter-gather, map-reduce"（web_search 摘要） |
|
||
| **Temporal** | `asyncio.gather(*futures, return_exceptions=True)` | `return_exceptions=True` 意味着部分失败不阻塞整体，结果里包含异常（来源：dev.to Temporal AI agents） |
|
||
| **open-multi-agent** | `AgentPool.runParallel()` + fan-out-aggregate pattern | 多 agent 并行，结果由 synthesizer 聚合（来源：知识库 `examples/patterns/fan-out-aggregate.ts`） |
|
||
| **GSD (get-shit-done)** | Wave Execution——按依赖分组，wave 内并行，wave 间串行 | "Plans are grouped into waves. Within each wave, plans run in parallel. Waves run sequentially."（来源：知识库 `get-shit-done/README.md`） |
|
||
|
||
**关键设计点**：
|
||
1. **结果汇聚**：需要一个 aggregator（可以是固定逻辑，也可以是一个 agent）
|
||
2. **部分失败处理**：
|
||
- `fail_fast`：一个失败全部取消（适合 saga 类场景）
|
||
- `best_effort`：收集所有结果，失败标记，汇总时报告（适合批量回测）
|
||
3. **并发控制**：受 counter 全局上限约束（`max_global_agents`）
|
||
4. **GSD 的 Wave 启发**：parallel 可以和 multi_step 组合——一个多步 pipeline 的某个 stage 是并行的
|
||
|
||
### 3.4 loop（循环 / 审议 / Evaluator-Reflect-Refine）
|
||
|
||
**描述**：执行→评审→不通过→修改→再提交，循环直到通过或达到上限。
|
||
|
||
**适用场景**：审议循环（门下省封驳重做）、自愈（检测→诊断→修复→验证循环）、质量迭代（写→评审→改→再审）。
|
||
|
||
**优秀实践**：
|
||
|
||
| 来源 | 做法 | 关键点 |
|
||
|------|------|--------|
|
||
| **AWS Prescriptive Guidance** | Evaluator-Reflect-Refine Loop | "The loop repeats until the result meets criteria, is approved, or reaches a retry limit"（web_search 摘要） |
|
||
| **三省六部 Edict** | 门下省封驳→返回中书省→修改→重新审议，最多 3 轮 | 制度化循环，有硬上限（来源：知识库 `edict/docs/task-dispatch-architecture.md`） |
|
||
| **Cloudflare Agents** | Human-in-the-loop + schedule escalation | "Implement timeouts — use schedule() to escalate or auto-reject after reasonable periods"（web_search 摘要） |
|
||
| **Reddit AI_Agents 实战** | "Set a hard rule: if no CRITICAL items, output APPROVED — loop terminates. Max 3 cycles, then escalate to human"（web_search 摘要） |
|
||
|
||
**关键设计点**：
|
||
1. **终止条件**：通过 / 达到 max_rounds（硬上限）/ 人工介入
|
||
2. **收敛保障**：max_rounds 防止无限循环
|
||
3. **上下文传递**：每次循环需要把上一次的评审意见传给执行者
|
||
4. **和 multi_step 的关系**：loop 是 multi_step 的某个阶段加上循环条件。可以建模为 `multi_step + loop_guard`
|
||
|
||
### 3.5 saga（补偿事务）
|
||
|
||
**描述**：多步串行执行，任何一步失败，反向执行之前步骤的补偿动作。
|
||
|
||
**适用场景**：数据 ETL（下载→清洗→入库，入库失败要清掉已洗的数据）、实盘交易（下单→成交确认→风控检查，失败需要撤单）、策略上线（回测→模拟盘→实盘，失败需要回退）。
|
||
|
||
**优秀实践**：
|
||
|
||
| 来源 | 做法 | 关键点 |
|
||
|------|------|--------|
|
||
| **SagaLLM (arXiv:2503.11951)** | AI Agent 场景的 saga——保留 context 用于 recovery，按 dependency graph 反向执行补偿 | "Upon failure, system invokes compensatory actions using logs and rollback specifications stored in... traverses dependency graph to orchestrate reverse execution paths"（web_search 摘要） |
|
||
| **SparkCo** | 每步定义 forward + compensate 动作，orchestrator 管理补偿链 | "Each step treated as independent transaction, with compensating actions defined for rollback scenarios"（web_search 摘要） |
|
||
| **Temporal** | 内置 Saga 支持：`await workflow.execute_activity(compensate_A)` | 每个 Activity 注册对应的补偿函数（来源：Temporal docs） |
|
||
|
||
**关键设计点**：
|
||
1. **补偿动作定义**：每个 stage 必须声明 `compensate` 动作（可以是 agent spawn 或固定脚本）
|
||
2. **补偿链**：失败后从当前 stage 反向执行之前所有 stage 的 compensate
|
||
3. **补偿也可能失败**：需要记录补偿状态，人工介入
|
||
4. **和 multi_step 的关系**：saga 是 multi_step + compensate 定义。可以建模为 `multi_step + per-stage-compensate`
|
||
|
||
### 3.6 interactive（人机交互 / Human-in-the-Loop）
|
||
|
||
**描述**：执行到关键点暂停等人确认，确认后继续。
|
||
|
||
**适用场景**：策略上线审批、实盘交易确认、多级审批链。
|
||
|
||
**优秀实践**：
|
||
|
||
| 来源 | 做法 | 关键点 |
|
||
|------|------|--------|
|
||
| **OpenClaw Lobster** | `approval: required` + `resumeToken`——暂停等审批，resume 不重跑已完成步骤 | "Halted workflows return a token; approve and resume without re-running everything"（来源：`lobster.md`） |
|
||
| **Redis AI HITL** | 工作流暂停在 decision point，保存 state，等 human approve/reject/modify 后 resume | "Workflow pauses at decision point, saves state, waits for human to approve/reject/modify before resuming"（web_search 摘要） |
|
||
| **Cloudflare Agents** | 审批超时自动 escalate 或 auto-reject | "Implement timeouts — use schedule() to escalate or auto-reject"（web_search 摘要） |
|
||
| **MindStudio** | Iterative Kanban Pattern——agent 产出 → human 评审 → agent 修改 → human 确认 | "Task gets handed to agent, agent produces output, human reviews, sends it back, agent revises, human approves"（web_search 摘要） |
|
||
|
||
**关键设计点**：
|
||
1. **resume 机制**：暂停时保存状态 + 产出 token，恢复时从 checkpoint 继续
|
||
2. **超时处理**：审批等待超时 → escalate / auto-reject / auto-approve（可配置）
|
||
3. **Lobster 启发**：moziplus 可以直接用 Lobster 的 `approval: required` 模式，不需要自己实现暂停/恢复
|
||
4. **和 multi_step 的关系**：interactive 是 multi_step 的某个 stage 加了 approval 门控。可以建模为 `multi_step + approval_stage`
|
||
|
||
### 3.7 event_trigger（事件触发 / 统一触发入口）
|
||
|
||
**描述**：不是一种执行模式，而是一种触发方式。和执行模式正交——任何执行模式都可以被事件触发。
|
||
|
||
**适用场景**：cron 定时触发、webhook 触发、依赖完成触发、条件触发。
|
||
|
||
**优秀实践**：
|
||
|
||
| 来源 | 做法 | 关键点 |
|
||
|------|------|--------|
|
||
| **Gobii (hermes-agent #491)** | 统一 scheduled 和 event-driven 到一个 durable processing loop——cron / IMAP idle / webhook / agent-to-agent message 全部统一 | "unifies scheduled and event-driven execution into a single durable processing loop"（web_search 摘要） |
|
||
| **AgentC2** | Agent 同时支持 cron + webhook，hybrid pattern | "Agent can have both cron schedule and event triggers — daily summary at 6 AM + webhook for critical alerts"（web_search 摘要） |
|
||
| **Edict** | Event Bus + 主题路由（`task.created`, `task.completed` 等） | 所有状态变更发布事件，订阅者按需触发（来源：知识库 `edict/edict_agent_architecture.md`） |
|
||
| **OpenClaw Cron** | `cron add --cron "0 7 * * 1-5" --session session:xxx --message "..."` | 定时触发 agent session，声明式配置（来源：OpenClaw cron 工具） |
|
||
|
||
**关键设计点**：
|
||
1. **触发方式 vs 执行模式正交**：trigger 是"什么时候开始"，execution_pattern 是"开始后怎么跑"
|
||
2. **四种触发**：manual（人工）/ cron（定时）/ webhook（外部事件）/ dependency（前序完成）
|
||
3. **Gobii 启发**：统一到一个 loop，不需要为每种触发建独立系统
|
||
4. **OpenClaw Cron 已有能力**：当前 moziplus 可以直接用 OpenClaw cron 做定时触发，不需要自己实现
|
||
|
||
---
|
||
|
||
## 4. 执行模式关系图
|
||
|
||
```
|
||
┌─────────────────────────────┐
|
||
│ Trigger（正交层） │
|
||
│ manual / cron / webhook / │
|
||
│ dependency │
|
||
└──────────────┬──────────────┘
|
||
│ 触发任务
|
||
▼
|
||
┌──────────┐ ┌──────────────┐ ┌──────────┐ ┌──────────┐
|
||
│ single │ │ multi_step │ │ parallel │ │ mail │
|
||
│ _step │ │ │ │ │ │ │
|
||
└──────────┘ └──────┬───────┘ └──────────┘ └──────────┘
|
||
│
|
||
┌────────┼────────┐
|
||
▼ ▼ ▼
|
||
┌──────────┐ ┌──────┐ ┌──────┐
|
||
│interactive│ │ loop │ │ saga │
|
||
│ (审批门控)│ │(循环)│ │(补偿)│
|
||
└──────────┘ └──────┘ └──────┘
|
||
```
|
||
|
||
**关系说明**：
|
||
- `single_step` 和 `multi_step` 是两种基础执行模式
|
||
- `parallel` 是独立的执行模式（并行子任务）
|
||
- `mail` 是特殊的 single_step（独立 pipeline，不走通用路径）
|
||
- `interactive`、`loop`、`saga` 是 **multi_step 的增强**——它们在 multi_step 骨架上加了额外能力
|
||
- `trigger` 和执行模式正交
|
||
|
||
### 建模方式
|
||
|
||
| 增强类型 | 本质 | 建模 |
|
||
|---------|------|------|
|
||
| interactive | multi_step + approval stage | `multi_step` + profile 中某些 stage 声明 `approval: required` |
|
||
| loop | multi_step + 循环 guard | `multi_step` + profile 中声明 `loop: { max_rounds: 3, convergence_check: true }` |
|
||
| saga | multi_step + compensate | `multi_step` + profile 中每个 stage 声明 `compensate: { agent: "...", message: "..." }` |
|
||
|
||
**不需要 3 个独立的 Pipeline 子类**。只需要 `MultiStepPipeline` 识别 profile 中的增强声明，执行时加入对应逻辑。
|
||
|
||
---
|
||
|
||
## 5. 场景 × 执行模式映射
|
||
|
||
### 5.1 已有业务类型
|
||
|
||
| 业务类型 | 执行模式 | 触发方式 | 说明 |
|
||
|---------|---------|---------|------|
|
||
| **coding** | multi_step | manual | plan→implement→verify→review |
|
||
| **review** | single_step | manual / dependency | 固定 agent，一杆到底 |
|
||
| **data** | single_step | manual / cron | 固定 agent（赵云），下载+验证 |
|
||
| **deploy** | multi_step (interactive) | manual | build→test→approve→deploy |
|
||
| **research** | multi_step | manual | plan→research→report |
|
||
| **discuss** | single_step | manual | 讨论，一杆到底 |
|
||
| **mail (request)** | mail | API 创建 | 点对点投递 |
|
||
| **mail (inform)** | mail | API 创建 | 点对点，自动 done |
|
||
|
||
### 5.2 调研的 28 个场景映射
|
||
|
||
| # | 场景 | 业务类型 | 执行模式 | 触发 |
|
||
|---|------|---------|---------|------|
|
||
| A1 | Mail 投递 | mail | mail | API |
|
||
| A2 | Task 派发 | coding/review/... | 各自映射 | manual |
|
||
| B1 | 定时数据采集 | data_collect | single_step | cron |
|
||
| B2 | 早朝简报 | morning_brief | multi_step | cron |
|
||
| B3 | 批量回测 | batch_backtest | parallel | manual |
|
||
| B4 | 风控巡查 | risk_patrol | single_step | cron / event |
|
||
| B5 | 策略上线审批 | strategy_launch | multi_step (interactive) | manual |
|
||
| B6 | 实盘交易信号 | trade_signal | multi_step (saga) | event |
|
||
| C1 | Webhook 触发 | （任意） | 由 task_type 决定 | webhook |
|
||
| C2 | Saga 链式任务 | data_etl | multi_step (saga) | manual / dependency |
|
||
| C3 | 并行协作 | parallel_collab | parallel | manual |
|
||
| C4 | 人机交互 | （任意 multi_step） | multi_step (interactive) | manual |
|
||
| C5 | 执行工具替换 | （架构层） | 不映射 | N/A |
|
||
| D1 | 隔夜编码 | overnight_coding | multi_step | cron |
|
||
| D2 | 持仓再平衡 | portfolio_rebalance | multi_step (interactive) | cron |
|
||
| D3 | 交易异常监控 | fraud_detect | single_step | event |
|
||
| D4 | 数据 ETL 管道 | data_etl | multi_step (saga) | cron / dependency |
|
||
| D5 | 合规审计追踪 | audit_trail | multi_step | event |
|
||
| D6 | 策略实验跟踪 | experiment_track | multi_step | manual |
|
||
| E1 | 三省六部分权 | edict_dispatch | multi_step (loop) | manual |
|
||
| E2 | 事件驱动响应 | （任意） | 由 task_type 决定 | event |
|
||
| E3 | 动态计划调整 | dynamic_plan | multi_step | manual |
|
||
| E4 | 自愈/故障恢复 | self_heal | multi_step (loop) | event |
|
||
| E5 | 审批链 | approval_chain | multi_step (interactive) | manual |
|
||
| E6 | 成本/配额控制 | quota_guard | single_step | event |
|
||
| E7 | 经验蒸馏 | experience_distill | single_step | dependency |
|
||
| F1 | 条件触发 | （任意） | 由 task_type 决定 | event (condition) |
|
||
| F2 | 依赖触发 | （任意） | 由 task_type 决定 | dependency |
|
||
| F3 | 人工触发 | （任意） | 由 task_type 决定 | manual |
|
||
|
||
---
|
||
|
||
## 6. 设计方案
|
||
|
||
### 6.1 设计模式选择
|
||
|
||
```
|
||
Registry + Template Method + Strategy
|
||
```
|
||
|
||
- **Registry**：Pipeline 注册中心，按 task_type 查找
|
||
- **Template Method**：Pipeline 基类定义 tick() 骨架，子类覆写差异步骤
|
||
- **Strategy**：触发方式、路由策略、验证策略作为可注入的策略对象
|
||
|
||
来源：LangGraph Routing Pattern（来源：web_search "LangGraph Routing"）、Argo WorkflowTemplate（来源：Argo docs）、Temporal Worker Framework（来源：Temporal docs）。
|
||
|
||
### 6.2 Pipeline 类体系
|
||
|
||
```
|
||
TaskPipeline (ABC) # Template Method 骨架
|
||
├── MailPipeline # Mail 专属（硬编码，不走 YAML）
|
||
├── SingleStepPipeline # 单步执行
|
||
├── MultiStepPipeline # 多步执行（含增强）
|
||
│ ├── 识别 interactive 声明 → approval gate
|
||
│ ├── 识别 loop 声明 → 循环 guard
|
||
│ └── 识别 saga 声明 → compensate chain
|
||
└── ParallelPipeline # 并行执行（fan-out + aggregate）
|
||
|
||
PipelineRouter # Registry，按 task_type 路由
|
||
```
|
||
|
||
**为什么只有 4 个子类**：interactive/loop/saga 不是独立子类，而是 MultiStepPipeline 通过 profile 声明启用的增强能力。
|
||
|
||
### 6.3 Pipeline 基类
|
||
|
||
```python
|
||
class TaskPipeline(ABC):
|
||
"""Pipeline 基类（Template Method）"""
|
||
|
||
def __init__(self, spawner, counter, router, config, profile=None):
|
||
self.spawner = spawner
|
||
self.counter = counter
|
||
self.router = router
|
||
self.config = config
|
||
self.profile = profile or {}
|
||
|
||
async def tick(self, db_path: Path, project_config: dict) -> TickResult:
|
||
"""每个 ticker 周期的入口"""
|
||
await self.pre_tick(db_path)
|
||
tasks = self.load_pending(db_path)
|
||
dispatched = 0
|
||
for task in tasks:
|
||
if not self.can_dispatch(task, db_path):
|
||
continue
|
||
result = await self.dispatch_one(task, db_path, project_config)
|
||
if result:
|
||
dispatched += 1
|
||
return TickResult(dispatched=dispatched, total=len(tasks))
|
||
|
||
# ── 钩子方法 ──
|
||
async def pre_tick(self, db_path):
|
||
self.check_timeouts(db_path)
|
||
|
||
@abstractmethod
|
||
def load_pending(self, db_path) -> list: ...
|
||
|
||
def can_dispatch(self, task, db_path) -> bool:
|
||
return True
|
||
|
||
@abstractmethod
|
||
async def dispatch_one(self, task, db_path, project_config) -> bool: ...
|
||
|
||
def check_timeouts(self, db_path): ...
|
||
```
|
||
|
||
### 6.4 MultiStepPipeline 增强
|
||
|
||
```python
|
||
class MultiStepPipeline(TaskPipeline):
|
||
"""多步执行（含 interactive/loop/saga 增强）"""
|
||
|
||
def __init__(self, *args, **kwargs):
|
||
super().__init__(*args, **kwargs)
|
||
# 从 profile 读取增强配置
|
||
self.loop_config = self.profile.get("loop") # { max_rounds, convergence_check }
|
||
self.saga_config = self.profile.get("saga") # { stages: [{compensate: ...}] }
|
||
self.interactive_stages = self._extract_approval_stages()
|
||
|
||
def _extract_approval_stages(self):
|
||
"""从 profile stages 中提取需要 approval 的 stage"""
|
||
return [s for s in self.profile.get("stages", [])
|
||
if s.get("approval") == "required"]
|
||
|
||
async def dispatch_one(self, task, db_path, project_config):
|
||
stage = self._get_current_stage(task)
|
||
|
||
# interactive: approval gate
|
||
if stage.get("approval") == "required" and not self._is_approved(task, stage):
|
||
return False # 等审批，不 spawn
|
||
|
||
# spawn agent
|
||
agent_id = self._resolve_agent(task, stage)
|
||
message = self._build_stage_prompt(task, stage)
|
||
return await self._spawn_and_track(agent_id, message, task, stage, db_path)
|
||
|
||
def _on_stage_complete(self, task, stage, outcome, db_path):
|
||
# saga: 记录 compensate 动作
|
||
if self.saga_config and stage.get("compensate"):
|
||
self._record_compensate(task, stage, db_path)
|
||
|
||
# loop: 检查收敛
|
||
if self.loop_config:
|
||
round_num = self._get_current_round(task)
|
||
if outcome == "rejected" and round_num < self.loop_config["max_rounds"]:
|
||
self._advance_to_next_round(task, db_path)
|
||
return
|
||
elif round_num >= self.loop_config["max_rounds"]:
|
||
self._escalate(task, db_path, reason="loop_max_rounds")
|
||
return
|
||
|
||
# 正常推进到下一个 stage
|
||
self._advance_stage(task, db_path)
|
||
```
|
||
|
||
### 6.5 ParallelPipeline
|
||
|
||
```python
|
||
class ParallelPipeline(TaskPipeline):
|
||
"""并行执行（fan-out + aggregate）"""
|
||
|
||
def __init__(self, *args, **kwargs):
|
||
super().__init__(*args, **kwargs)
|
||
self.failure_policy = self.profile.get("failure_policy", "best_effort")
|
||
self.aggregator = self.profile.get("aggregator", {})
|
||
|
||
async def dispatch_one(self, task, db_path, project_config):
|
||
# 1. 拆分子任务
|
||
sub_tasks = self._fan_out(task)
|
||
|
||
# 2. 并行 spawn（受 counter 约束）
|
||
futures = []
|
||
for sub in sub_tasks:
|
||
agent_id = self._resolve_agent(sub)
|
||
if not self.counter.can_acquire(agent_id, sub.id):
|
||
continue
|
||
self.counter.acquire(agent_id, sub.id)
|
||
futures.append(self._spawn_subtask(agent_id, sub, db_path))
|
||
|
||
# 3. 等待所有完成
|
||
results = await asyncio.gather(*futures, return_exceptions=True)
|
||
|
||
# 4. 处理部分失败
|
||
if self.failure_policy == "fail_fast":
|
||
if any(isinstance(r, Exception) for r in results):
|
||
self._cancel_remaining(futures)
|
||
self._mark_failed(task, db_path)
|
||
return True
|
||
# best_effort: 继续聚合
|
||
|
||
# 5. 聚合结果
|
||
if self.aggregator.get("type") == "agent":
|
||
await self._aggregate_with_agent(task, results, db_path)
|
||
else:
|
||
self._aggregate_simple(task, results, db_path)
|
||
|
||
return True
|
||
```
|
||
|
||
### 6.6 PipelineRouter
|
||
|
||
```python
|
||
class PipelineRouter:
|
||
def __init__(self):
|
||
self._pipelines: Dict[str, TaskPipeline] = {}
|
||
self._default: TaskPipeline = None
|
||
|
||
def register(self, task_type: str, pipeline: TaskPipeline):
|
||
self._pipelines[task_type] = pipeline
|
||
|
||
def route(self, task_type: str = None, is_mail: bool = False) -> TaskPipeline:
|
||
if is_mail:
|
||
return self._pipelines["_mail"]
|
||
return self._pipelines.get(task_type, self._default)
|
||
```
|
||
|
||
### 6.7 Pipeline Profile（YAML 声明）
|
||
|
||
```yaml
|
||
# config/pipelines/coding.yaml
|
||
task_type: coding
|
||
execution_pattern: multi_step
|
||
stages:
|
||
- id: plan
|
||
description: "分析需求，制定方案"
|
||
agent_selection: route_by_capability
|
||
capabilities_required: ["coding", "design"]
|
||
timeout_minutes: 10
|
||
- id: implement
|
||
description: "编码实现"
|
||
reuse_plan_agent: true
|
||
timeout_minutes: 30
|
||
depends_on: [plan]
|
||
- id: verify
|
||
description: "自动验证"
|
||
specific_agent: simayi-challenger
|
||
timeout_minutes: 15
|
||
depends_on: [implement]
|
||
completion:
|
||
status: done
|
||
require_verification: true
|
||
```
|
||
|
||
```yaml
|
||
# config/pipelines/review.yaml
|
||
task_type: review
|
||
execution_pattern: single_step
|
||
agent_selection: specific_agent
|
||
specific_agent: simayi-challenger
|
||
timeout_minutes: 20
|
||
completion:
|
||
status: done
|
||
```
|
||
|
||
```yaml
|
||
# config/pipelines/strategy_launch.yaml
|
||
task_type: strategy_launch
|
||
execution_pattern: multi_step
|
||
stages:
|
||
- id: backtest
|
||
description: "回测验证"
|
||
specific_agent: zhangfei-dev
|
||
timeout_minutes: 60
|
||
- id: simulate
|
||
description: "模拟盘运行"
|
||
specific_agent: zhangfei-dev
|
||
timeout_minutes: 120
|
||
depends_on: [backtest]
|
||
- id: approve
|
||
description: "上线审批"
|
||
approval: required # ← interactive 增强
|
||
timeout_hours: 24 # 审批超时
|
||
timeout_action: escalate # auto_reject / escalate / auto_approve
|
||
depends_on: [simulate]
|
||
- id: live
|
||
description: "实盘部署"
|
||
specific_agent: jiangwei-infra
|
||
timeout_minutes: 30
|
||
depends_on: [approve]
|
||
```
|
||
|
||
```yaml
|
||
# config/pipelines/data_etl.yaml
|
||
task_type: data_etl
|
||
execution_pattern: multi_step
|
||
stages:
|
||
- id: download
|
||
description: "数据下载"
|
||
specific_agent: zhaoyun-data
|
||
timeout_minutes: 60
|
||
compensate: # ← saga 增强
|
||
action: "删除已下载文件"
|
||
command: "rm -rf /tmp/download/{task_id}"
|
||
- id: clean
|
||
description: "数据清洗"
|
||
specific_agent: zhaoyun-data
|
||
timeout_minutes: 30
|
||
depends_on: [download]
|
||
compensate:
|
||
action: "删除已清洗文件"
|
||
command: "rm -rf /tmp/clean/{task_id}"
|
||
- id: validate
|
||
description: "数据验证"
|
||
specific_agent: zhaoyun-data
|
||
timeout_minutes: 15
|
||
depends_on: [clean]
|
||
```
|
||
|
||
```yaml
|
||
# config/pipelines/edict_dispatch.yaml
|
||
task_type: edict_dispatch
|
||
execution_pattern: multi_step
|
||
loop: # ← loop 增强
|
||
max_rounds: 3
|
||
convergence_check: "review_passed"
|
||
stages:
|
||
- id: plan
|
||
description: "中书省规划"
|
||
specific_agent: zhongshu-agent
|
||
timeout_minutes: 15
|
||
- id: review
|
||
description: "门下省审议"
|
||
specific_agent: menxia-agent
|
||
timeout_minutes: 10
|
||
depends_on: [plan]
|
||
# review 不通过 → loop 回到 plan（最多3轮）
|
||
- id: dispatch
|
||
description: "尚书省派发"
|
||
depends_on: [review]
|
||
```
|
||
|
||
```yaml
|
||
# config/pipelines/batch_backtest.yaml
|
||
task_type: batch_backtest
|
||
execution_pattern: parallel
|
||
failure_policy: best_effort # 部分失败不阻塞
|
||
aggregator:
|
||
type: agent # 用 agent 聚合结果
|
||
specific_agent: pangtong-fujunshi
|
||
fan_out:
|
||
source: task.params.param_sets # 从任务参数获取参数组列表
|
||
per_item:
|
||
specific_agent: zhangfei-dev
|
||
timeout_minutes: 30
|
||
```
|
||
|
||
---
|
||
|
||
## 7. Ticker 改造
|
||
|
||
```python
|
||
class Ticker:
|
||
def __init__(self, pipeline_router: PipelineRouter, ...):
|
||
self.pipeline_router = pipeline_router
|
||
|
||
async def _tick_project(self, project_id, project_config):
|
||
is_mail = project_id == "_mail"
|
||
db_path = self._get_db_path(project_id)
|
||
|
||
if is_mail:
|
||
pipeline = self.pipeline_router.route(is_mail=True)
|
||
return await pipeline.tick(db_path, project_config)
|
||
|
||
# 查所有活跃 task_type，每种走对应 pipeline
|
||
task_types = self._get_active_task_types(db_path)
|
||
results = []
|
||
for tt in task_types:
|
||
p = self.pipeline_router.route(tt)
|
||
r = await p.tick(db_path, project_config)
|
||
results.append(r)
|
||
return merge_results(results)
|
||
```
|
||
|
||
---
|
||
|
||
## 8. 实施范围
|
||
|
||
### 一次性全做
|
||
|
||
| # | 事项 | 预估行数 |
|
||
|---|------|---------|
|
||
| 1 | 新建 `pipeline/` 目录：base.py, mail.py, single_step.py, multi_step.py, parallel.py, router.py | ~500 行 |
|
||
| 2 | Pipeline Profile YAML（coding, review, data, deploy, research, discuss） | ~200 行 |
|
||
| 3 | Profile 加载器（扫描 config/pipelines/） | ~50 行 |
|
||
| 4 | Ticker 改造（删除 _mail 分支，改调 pipeline_router） | -150 行（标注废弃） |
|
||
| 5 | Dispatcher 标注废弃（逻辑迁移到各 Pipeline） | 标注 |
|
||
| 6 | Spawner 瘦身（mail prompt 搬到 MailPipeline） | 标注 |
|
||
| 7 | 前端：task_type 选择 + stage 进度显示 | 待评估 |
|
||
|
||
### MultiStepPipeline 增强实现优先级
|
||
|
||
| 增强 | 优先级 | 理由 |
|
||
|------|--------|------|
|
||
| 基础 multi_step | P0 | 当前主流程 |
|
||
| interactive (approval gate) | P1 | 有 Lobster 参考，实现简单 |
|
||
| loop (循环 guard) | P2 | 有 edict 参考，逻辑清晰 |
|
||
| saga (compensate) | P3 | 场景需求相对远期 |
|
||
| parallel (fan-out) | P3 | 需要 sub-task 并行调度，改动大 |
|
||
|
||
---
|
||
|
||
## 9. 来源引用
|
||
|
||
| 结论 | 来源 |
|
||
|------|------|
|
||
| parallel = fan-out/fan-in/scatter-gather/map-reduce | Azure Architecture Center（web_search）；AWS Prescriptive Guidance（web_search）；open-multi-agent `fan-out-aggregate.ts`（知识库） |
|
||
| Wave Execution（并行分组） | get-shit-done README（知识库） |
|
||
| loop = evaluator-reflect-refine | AWS Prescriptive Guidance（web_search） |
|
||
| 门下省封驳最多3轮 | edict `task-dispatch-architecture.md`（知识库） |
|
||
| saga + compensate for AI | SagaLLM arXiv:2503.11951（web_search）；SparkCo（web_search） |
|
||
| interactive = approval + resumeToken | OpenClaw Lobster docs（`lobster.md`） |
|
||
| interactive 超时处理 | Cloudflare Agents docs（web_search） |
|
||
| event + cron 统一 loop | Gobii / hermes-agent #491（web_search） |
|
||
| Event Bus + topic routing | Edict architecture（知识库） |
|
||
| TaskFlow 持久化多步 | OpenClaw TaskFlow docs（`taskflow.md`） |
|
||
| AgentPool.runParallel() | open-multi-agent `fan-out-aggregate.ts`（知识库） |
|
||
|
||
---
|
||
|
||
## 10. 待确认
|
||
|
||
1. **4 个 Pipeline 子类是否够**？还是 interactive/loop/saga 需要独立子类？
|
||
2. **parallel 是否现在实现**？还是只预留接口？
|
||
3. **discuss 业务类型**：走 single_step 还是 multi_step？
|
||
4. **Trigger 层是否纳入本次实现**？还是继续用 OpenClaw cron 做触发？
|
||
5. **前端 task_type 选择**：创建任务时的 UI 交互怎么设计？
|