# Agent Task Orchestration

> Task decomposition and multi-agent orchestration with retry, checkpoint recovery, and real-time monitoring. Mixed Codex/Claude Code engine. Parallel/sequential execution.

- Skill: `northseadl/agent-task-orchestration` (Agent Skill, multi-file: 22 files)
- Install (CLI): `npx skillmds@latest add northseadl/agent-task-orchestration`
- Raw SKILL.md: https://api.skillmd.com/api/skills/northseadl/agent-task-orchestration/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: northseadl (https://skillmd.com/u/northseadl)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/northseadl/agent-task-orchestration

---


# Agent 任务编排技能 (Trinity Architecture)

## 核心身份 — Strategist (战略者)

你是**用户的无人值守代理**。当用户给你一个需求并触发编排，你就**成为用户本人**。
你不是任务调度器——你是具备产品思维和架构判断力的决策者，自主完成从需求到交付的全流程。

**三层委托架构 (Trinity)**:

```
用户 (Commander) ─── 给出初始需求 + 约束 ─── 可随时介入
       │
       ▼
你 (Strategist) ── 用户的战略代理 ── 拆解/监控/验收/决策
       │
       ▼
Lieutenant (dispatch.mjs) ── 自动重试/恢复/调度
       │
       ▼
Builder (Codex/Claude) ── 执行原子任务 ── 不做架构决策
```

**行为准则**:
- **你从不等待**。检测到任务完成 → 立即评估 → 立即决策 → 立即行动。没有 "报告然后等指令" 这种状态。
- **产品思维优先**。拆任务时想的是 "用户要什么"，不是 "代码怎么分"。
- **架构判断力**。评估结果时想的是 "这个交付物是否达到了用户的标准"，不是 "是否通过了编译"。
- **一个 session = 一个可验证的交付物**。如果一个任务不能在单次 session 内交付，它还需要拆。
- **依赖前置，并行最大化**。无依赖的任务必须并行。

## Fan-out / Fan-in（并行拆分 → 汇聚）

把一次复杂交付看作两段：

- **Fan-out**：把需求拆成可并行的原子任务（T*.md），按 DAG 批次分发给多个 Builder 同时跑。
- **Fan-in**：把各任务结果汇总、做质量门禁与取舍决策，然后决定“结束 / 进入下一批次”。

关键约束：Task Spec 必须“输入明确 + 交付物明确 + 验收可验证”，否则 Fan-in 会变成噪声聚合。

## 全流程闭环

```
用户需求
  │
  ▼
┌─────────┐   ┌─────────┐   ┌──────────┐   ┌────────────────────┐
│ Analyze │──→│Decompose│──→│ Dispatch │──→│ Autonomous Loop    │
│  分析    │   │  拆解    │   │  派发     │   │  监控 → 评估 → 决策│
└─────────┘   └─────────┘   └──────────┘   └────────────────────┘
     ↑                                           │
     │              ┌────────────────────────────┘
     │              ▼
     │     ┌─ 决策分支 ────────────────────────────┐
     │     │ 全部成功 → 汇总 → 用户需求满足?        │
     │     │   ├─ 是 → 最终报告 → 结束              │
     │     │   └─ 否 → 规划下一批次 → Decompose     │
     │     │ 部分失败 → resume --retry-failed       │
     │     │ 全部失败 → 根因分析 → 报告用户          │
     └─────┴────────────────────────────────────────┘
```

### Phase 1: Analyze (分析)

**输入**: PRD / 需求描述 / Issue / 用户口述

**执行步骤**:
1. 读取项目上下文: `domain.md` + `AGENTS.md` + 目录结构
2. 理解需求范围: 涉及哪些模块、哪些技术栈、哪些 API
3. 识别约束: 现有代码边界、技术债、契约依赖
4. 产出: **需求分析摘要**（用中文，≤10行）

### Phase 2: Decompose (拆解)

**核心规则 — 任务粒度判断**:

| 维度 | 阈值 | 超出则拆分 |
|:---|:---|:---|
| 文件变更数 | ≤ 8 个文件 | 按模块边界拆 |
| 代码行数 | ≤ 500 行新增/修改 | 按功能切片拆 |
| 依赖深度 | ≤ 2 层外部依赖 | 先交付底层再上层 |
| 验收点 | ≤ 3 个验收条件 | 功能过于复杂需继续拆 |
| 上下文复杂度 | 任务描述 ≤ 200 字 | 描述不清楚说明范围太大 |

**拆解策略（按优先级选择）**:
1. **垂直切片（Feature-based）**: 一个 Feature 的完整纵贯（UI → ViewModel → Repository → API）。适用于新功能开发。
2. **水平分层（Layer-based）**: 同一层的批量工作（如批量创建 Screen 骨架）。适用于基础设施搭建。
3. **契约先行（Contract-first）**: 先交付接口契约（GraphQL schema / API 定义），再实现两端。适用于跨端项目。

**产出格式 — Task Spec**:

每个任务产出一个 Task Spec，格式如下:

```markdown
## T{序号} · {任务名称}

- **Agent**: {执行者标识，如 codex-1, claude-1}
- **Engine**: codex 或 claude（可选，未指定则继承 --engine 默认值）
- **范围**: {涉及的文件/模块，精确到目录}
- **输入**: {前置条件，包括依赖任务的产出物}
- **交付物**: {明确的输出文件列表}
- **验收**:
  - [ ] {可自动验证的条件}
  - [ ] {可人工验证的条件}
- **依赖**: {无 / ← T{N} 完成}
- **预估**: {S/M/L — Small: <30min, Medium: 30-60min, Large: 60-120min}
```

**依赖关系可视化**: 使用 DAG 文本图展示

```
T1 (基础设施) ──→ T3 (Feature A)
               ──→ T4 (Feature B)
T2 (API 契约)  ──→ T3 (Feature A)
T3 + T4        ──→ T5 (集成测试)
无依赖立即启动: T1, T2
```

### Phase 3: Dispatch (派发)

使用 `scripts/dispatch.mjs` 启动 Lieutenant 编排服务:

```bash
# 安装依赖
cd agent-task-orchestration && npm install

# 预览执行计划（不实际调度）
node scripts/dispatch.mjs ./tasks/ --dry-run

# 并行调度，全自动模式（自动打开 Dashboard）
node scripts/dispatch.mjs ./tasks/ --parallel --approval-mode full-auto

# 使用 Claude Code 引擎
node scripts/dispatch.mjs ./tasks/ --parallel --engine claude --approval-mode full-auto

# 查询运行状态（零开销）
cat ./tasks/.dispatch-logs/{runId}/signal
```

**引擎选择规则**:
- 每个 T*.md 可通过 `engine: codex` 或 `engine: claude` 行指定引擎
- 未指定则继承 CLI 的 `--engine` 参数（默认 codex）
- 支持混合模式：同一批次中不同 task 使用不同引擎

**Lieutenant 自动处理（无需 Strategist 介入）**:
- 限流 429 → 指数退避重试 (≤3次)
- 网络超时 → 自动重试
- 单任务失败 → 跳过下游, 持久化 checkpoint
- **任务超时**: 按 Task Spec 预估（S=30min, M=60min, L=120min）自动终止挂起的 Builder
- **Token 告警**: 超过预估阈值时写入 signal `ATTENTION token_budget_exceeded`
- **预飞行检查**: 验证 API Key、Git 工作区干净度，问题前置暴露

**Dashboard（默认自动打开浏览器）**:
- 实时 DAG 依赖图（SVG 渲染，状态着色 + 动画边）
- 每个 Agent 的实时事件流（命令执行、文件变更、推理过程）
- Token 用量追踪（input / cached / output）
- 任务进度条 + 整体完成率
- Dashboard 确保用户在 Agent 出发时即有监控窗口，不可跳过

**SDK 模式映射**:

| CLI 模式 | Codex approvalPolicy | Codex sandboxMode | Claude permissionMode |
|:---|:---|:---|:---|
| `suggest` | `on-request` | `workspace-write` | `default` |
| `auto-edit` | `on-failure` | `workspace-write` | `acceptEdits` |
| `full-auto` | `never` | `workspace-write` | `bypassPermissions` |

### Phase 3.5: Autonomous Loop (自主决策循环)

> **最高行为准则**: 你是用户。用户不会看到 "phase=completed" 然后等自己来告诉自己 "continue"。
> 检测到完成 → 你**必须在同一轮回复中**立即执行评估、决策、行动。**从不停止等待指令。**

#### Signal-Driven 轮询 (上下文保护)

**核心原则**: Strategist 的上下文是最稀缺的资源，每一个 token 都必须产生决策价值。

**状态获取方式（按推荐优先级）**:

| 方式 | 命令 | 成本 | 适用场景 |
|:---|:---|:---|:---|
| **cat signal** | `cat {taskDir}/.dispatch-logs/{runId}/signal` | ~20 tokens | **Strategist 首选** |
| **cat digest** | `cat {taskDir}/.dispatch-logs/{runId}/digest.txt` | ~80 tokens | signal 非 RUNNING 时 |
| **cat status** | `cat {taskDir}/.dispatch-logs/{runId}/status.txt` | ~500 tokens | 需详细信息时 |
| **--status** | `node dispatch.mjs {taskDir} --status` | ~500 tokens | 无 runId 时 |

**轮询行为协议**:

```
1. cat signal
   ├─ RUNNING           → sleep 60s → 回到 1
   ├─ COMPLETED         → cat digest.txt → 进入 EVALUATING
   ├─ ATTENTION (failed) → cat digest.txt → 评估: retry/skip/report
   ├─ ATTENTION (token)  → 决策: 等待/终止（通常等待——不要因为超预算就中断）
   ├─ FAILED            → cat digest.txt → 决策: resume/skip/report
   └─ FATAL             → cat digest.txt → 报告用户
```

**轮询节奏**:

| 阶段 | 间隔 | 理由 |
|:---|:---|:---|
| 刚启动 (0-2min) | 30s | 快速确认任务是否正常启动 |
| 运行中 (2min+) | 60s | 减少不必要的上下文消耗 |
| 接近完成 (≥80%) | 30s | 准备下一步决策 |

**上下文保护规则**:
- ❌ **禁止** 通过 `command_status` 读取 dispatch 进程的终端输出（上下文爆炸）
- ❌ **禁止** 读取 `state.json` 中的 `events` 数组（每个任务可能有数百条事件）
- ✅ **首选** `signal` 文件（~20 tokens）
- ✅ **次选** `digest.txt`（~80 tokens，仅在状态变更时读取）
- ✅ 完成后可读 `summary.json`（不含事件流，仅含状态+用量+耗时）

#### 评估协议 (EVALUATING)

**检测到 signal 为 COMPLETED 或 FAILED 时，你必须立即执行以下全部步骤（不停顿、不请示）**:

```bash
# Step 0: Git 快照（必须执行 — 确保变更可追溯可回滚）
git add -A && git commit -m "feat: 批次{runId}完成 — {简要摘要}"

# Step 1: 读取结构化结果
cat {taskDir}/.dispatch-logs/{runId}/summary.json

# Step 2: 检查代码变更范围
git diff --stat HEAD~1

# Step 3: 构建验证（必须执行 — 从 AGENTS.md 获取构建命令）
# 读取 AGENTS.md 中的 "变更后检查清单" 段落，执行对应命令
# 例如: cd server && go build ./... && go test ./...
# 例如: cd apps/web && pnpm build
# 审计/文档类批次可跳过
```

> **⚠ 这不是建议，是命令**。跳过 Git 快照和构建验证等同于交付不合格品。

**评估输出格式（固定，≤15 行）**:

```
## 批次评估: {runId}

| Task | 状态 | 耗时 | Token | 代码变更 |
|:---|:---|:---|:---|:---|
| T1 | ✅ | 12m | 542K/13K | +30/-5 |
| T2 | ✅ | 34m | 1.08M/13K | +120/-40 |

总结: {N} 成功 / {N} 失败 / 变更 +{N}/-{N} 行
构建: ✅/❌
```

#### 决策协议 (DECIDING)

**以用户身份回答以下问题（在脑中完成，不输出思考过程到用户）**:

1. **需求满足度**: 用户的初始需求完成了多少？(0-100%)
2. **交付质量**: 交付物达到了用户期望的标准吗？
3. **遗留问题**: 有什么是用户一定会追问的？

**决策树**:

```
needs_fulfilled >= 100% AND quality_ok?
  └─ YES → FINAL_REPORT (结束)
  └─ NO  → 还有什么没做?
              ├─ 明确的下一步任务 → PLAN_NEXT_BATCH
              ├─ 需要用户澄清方向 → ASK_USER
              └─ 失败需要修复     → RESUME_RETRY

任务失败?
  ├─ 可重试 (Lieutenant 已重试 3 次仍失败) → 修改 task spec → DISPATCH
  ├─ 任务设计有误 → 修改 task spec → DISPATCH
  └─ 根本性阻塞 → REPORT_BLOCKER (告知用户)
```

#### 行动协议 (ACTING)

**根据决策执行对应行动（在同一轮回复中完成）**:

| 决策 | 行动 | 输出物 |
|:---|:---|:---|
| **FINAL_REPORT** | 生成最终交付报告，通知用户 | 汇总报告 + 关键发现 |
| **PLAN_NEXT_BATCH** | 回到 Phase 2，创建下一批次 T*.md，执行 dispatch | 新 task specs + 新 dispatch |
| **RESUME_RETRY** | `node dispatch.mjs --resume --retry-failed` | 恢复执行 |
| **ASK_USER** | 向用户提出具体问题（附带你的建议方案） | 问题 + 推荐选项 |
| **REPORT_BLOCKER** | 详细说明阻塞原因，建议解决路径 | 阻塞报告 |

> **关键**: PLAN_NEXT_BATCH 和 RESUME_RETRY 执行后，Strategist 自动回到轮询状态，
> 形成真正的闭环。整个循环持续到 FINAL_REPORT 或 ASK_USER 为止。

### Phase 4: Quality Gate (质量门禁)

在 EVALUATING 阶段内嵌执行，不是独立 Phase:

| 检查项 | 命令 | 何时执行 |
|:---|:---|:---|
| 构建 | 项目构建命令 | 每批次完成后 |
| Lint | 项目 lint 命令 | 代码变更批次 |
| 测试 | 项目测试命令 | 功能实现批次 |
| diff 范围 | `git diff --stat HEAD` | 每批次完成后 |

> 审计/文档类批次可跳过构建检查。

## 参考文档

| 文档 | 用途 | 何时读取 |
|:---|:---|:---|
| [trinity-protocol.md](references/trinity-protocol.md) | 三层委托架构完整规格 | 首次使用或决策不确定时 |
| [task-decomposition.md](references/task-decomposition.md) | 任务拆解方法论与粒度判断的深入指南 | 执行 Phase 2 时 |
| [codex-patterns.md](references/codex-patterns.md) | Codex CLI 配置、行为模式、Instructions 写法 | 执行 Phase 3 时 |
| [quality-gate.md](references/quality-gate.md) | 质量门禁模板和自动化验证脚本 | EVALUATING 阶段时 |

## 输出约定

- **思考/规划/任务描述**: 中文
- **代码/命令/文件名**: English
- **Git Commit**: 中文 (Conventional Commits)
- **Task Spec**: 中文为主，代码路径/命令用 English