串行接力式多智能体协作系统：完整设计方案
串行接力式多智能体协作系统：完整设计方案
这是一套可控、可预测、能产出的多智能体协作系统，模拟人类团队的流水线作业方式。
一、核心理念：从"对话"到"接力"
1.1 并联的局限
当前主流多智能体系统（AutoGen、LangChain Agents、Claude Code）采用并联模式：
用户消息 ──┬──> Agent A ──> 响应（竞争）
├──> Agent B ──> 响应（竞争）
├──> Agent C ──> 响应（竞争）
└──> Agent D ──> 响应（竞争）
问题： - 多Agent同时响应，谁先回复用谁 → 不可控 - 适合快速头脑风暴 → 不适合工程产出 - 质量依赖"运气" → 无法保证交付标准
1.2 串行接力的本质
串行接力模拟的是人类团队的流水线作业：
需求 ──> 架构设计 ──> 验收标准 ──> 开发实现 ──> 交付
↓ ↓ ↓
[质量门] [质量门] [质量门]
核心思想： - 每个角色是流水线上的一个工位 - 每个工位有明确的输入标准和输出标准 - 质量不依赖运气，而依赖流程把关
这才是工程团队的正确姿势。
二、系统架构：文件接力机制
2.1 通信协议：单一信箱制
原则：
1. 每个Agent有且只有一个"信箱文件"
2. 谁读取文件，谁负责处理
3. 处理完毕后必须：
- 归档日志（保留记录）
- 清空信箱（表示"已完成"）
- 写入下一个信箱（传递接力棒）
2.2 目录结构
/project_root/
├── channels/ # 通信信道（核心！）
│ ├── to_architect.md # 人类 -> 架构师
│ ├── to_qa.md # 架构师 -> 质量标准制定
│ ├── to_developer.md # 质量标准 -> 开发
│ └── to_human.md # 架构师/开发 -> 人类
│
├── tasks/ # 任务清单
│ ├── task_001.md
│ └── ...
│
├── history_logs/ # 历史归档
│ └── ...
│
└── workspace/ # 代码工作区
2.3 轮询思想
每个Agent是一个独立进程，循环检测自己的信箱： - 信箱空 → 等待 - 信箱有内容 → 读取、处理、归档、清空、传递
三、任务依赖与智能跳过机制
3.1 为什么需要任务依赖
问题：传统串行流程中，人类成为绝对瓶颈
需求 → 架构师 → [人类决策] → QA → 开发 → 交付
↑
卡住不动
现实：真实项目中，任务之间往往不是强依赖的
举例：开发"用户系统"
├── 任务A: 用户注册（依赖: 无） → 可以先做
├── 任务B: 用户登录（依赖: A） → 可以先做
├── 任务C: 微信登录（依赖: B, 需要人类决策）→ 等待
└── 任务D: 忘记密码（依赖: 无） → 可以先做
3.2 任务依赖标记
--- TASK START ---
ID: 003
DESC: 实现微信扫码登录
依赖: 002
需要人类决策: 是
决策项:
- 微信扫码回调地址
- 扫码超时时间
--- TASK END ---
3.3 智能跳过逻辑
当任务T需要人类决策时：
1. 检查下一个任务T+1
2. 如果T+1的"依赖"不包含T → 跳过T+1，继续检查T+2
3. 如果T+1依赖T → 等待人类决策
4. 重复直到找到可执行的任务
四、角色定义与协作流程
4.1 三大角色（精简版）
| 角色 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 架构师 | 需求分析、任务拆解、技术决策、安全要求 | 人类需求 | 任务清单+安全要求 |
| 质量标准制定者 | 验收标准制定、安全测试 | 任务清单 | 验收标准+安全测试 |
| 开发者 | 代码实现、技术攻关 | 任务+验收标准 | 可运行代码 |
设计亮点：移除Reviewer，安全左移到Designer和QA，流程更精简。
4.2 为什么移除Reviewer？
原问题： - 可维护性在快速迭代阶段不重要，功能优先 - 安全问题应该左移，而非最后审查 - 流程过长（4个角色），效率低
解决思路： - 可维护性：事后一次性重构，不在开发过程中纠结 - 安全左移：Designer和QA在源头控制 - 流程精简：Designer → QA → Developer → 完成
4.3 角色关系图
┌─────────────────────┐
│ 人类 (Human) │
│ - 下发需求 │
│ - 接收汇报 │
│ - 批量决策 │
└─────────┬───────────┘
│
to_architect │ to_human
▼
┌─────────────────────┐
│ 架构师 (Architect) │
│ - 需求分析 │
│ - 任务拆解 │
│ - 安全要求 │
└─────────┬───────────┘
│
to_qa │ to_qa
▼
┌─────────────────────┐
│ 质量标准 (QA) │
│ - 验收标准制定 │
│ - 安全测试策略 │
└─────────┬───────────┘
│
to_developer │ to_human
▼
┌─────────────────────┐
│ 开发 (Developer) │
│ - 代码实现 │
│ - 功能优先 │
└─────────────────────┘
4.4 详细协作流程
阶段一：需求澄清（Human ↔ Architect）
步骤1: 人类下发需求
to_architect.md:
需求：实现用户登录系统
- 用户名密码登录
- 微信扫码登录
步骤2: 架构师分析
- 识别模糊点 → 向人类提问
- **明确安全要求**
步骤3: 任务拆解（含安全要求）
to_qa.md:
TASK_001: 用户名密码注册
技术要求:
- 用户名密码注册
- bcrypt加密存储
- JWT Token返回
安全要求:
- 使用参数化查询防止SQL注入
- 密码强度验证（至少8位）
阶段二：验收标准对齐（Architect → QA）
步骤4: 质量标准制定者接收任务
- 阅读架构师的任务拆解
- **制定验收标准**
- **制定安全测试策略**
步骤5: 制定验收标准
to_developer.md:
TASK_001: 用户名密码注册
验收标准:
1. 用户名4-20位字母数字
2. 密码至少8位，含数字和字母
3. 用户名已存在返回400
4. 注册成功返回200+token
安全测试:
- SQL注入测试：尝试 ' OR '1'='1
- XSS测试：尝试 <script>alert(1)</script>
阶段三：开发执行（Developer）
步骤6: 开发者接收任务+验收标准
- 理解任务要求
- 理解"什么是完成"
- **功能优先，快速实现**
步骤7: 智能跳过
- 当前任务需要等待人类决策？
- 检查后续任务是否依赖当前任务
- 不依赖 → 跳过执行
步骤8: 开发完成
to_human.md:
TASK_001: 用户名密码注册
状态: ✅ 已完成
改动:
- models/user.py
- routes/register.py
五、SKILL.md 设计要点
5.1 架构师 SKILL.md
# Role: 架构师
## 职责
- 需求分析、任务拆解
- 技术选型
- **安全要求明确**
## 安全要求模板
安全要求:
- 使用参数化查询防止SQL注入
- 密码使用bcrypt/argon2加密
- 敏感配置通过环境变量管理
- 验证码/限流防止暴力攻击
## 输出格式
--- TASK START ---
ID: 001
DESC: 实现用户注册接口
技术要求:
- 用户名密码注册
- bcrypt加密存储
安全要求:
- 参数化查询
- 密码强度验证
依赖: 无
需要人类决策: 否
--- TASK END ---
5.2 质量标准制定者 SKILL.md
# Role: 质量标准制定者 (QA)
## 职责
- 验收标准制定
- **安全测试策略**
## 安全测试模板
安全测试:
- SQL注入: ' OR '1'='1
- XSS: <script>alert(1)</script>
- 密码强度: 不足8位应拒绝
- 用户名重复: 返回400错误
## 输出格式
--- TASK START ---
ID: 001
DESC: 实现用户注册接口
验收标准:
1. 用户名4-20位字母数字
2. 密码至少8位
安全测试:
- SQL注入测试
- XSS测试
- 密码强度测试
--- TASK END ---
5.3 开发者 SKILL.md
# Role: 开发工程师
## 核心理念
- **功能优先，快速实现**
- 可维护性不是首要考虑
- 重构可以事后一次性做
## 工作流程
1. 理解任务和验收标准
2. 快速实现功能
3. 确保通过基本的安全测试（参数化查询等）
4. 完成后输出到 to_human.md
## 输出格式
--- COMPLETE ---
TASK_ID: 001
状态: ✅ 已完成
改动文件:
- models/user.py
- routes/register.py
---
六、与现有系统的整合
6.1 模式选择
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 快速问答 | 并联 | 多角度即时响应 |
| 头脑风暴 | 并联 | 发散思维 |
| 功能开发 | 串行 | 质量可控+高效 |
6.2 启动串行模式
用户输入: "/workflow 开发一个用户登录系统"
→ 进入串行流程（支持任务依赖+智能跳过）
七、独特优势
7.1 绝对可观测性
$ ls -la channels/
-rw-r--r-- 1 root root 120 Mar 22 09:35 to_developer.md # 接力棒在开发
-rw-r--r-- 1 root root 0 Mar 22 09:30 to_architect.md # 空
-rw-r--r-- 1 root root 0 Mar 22 09:25 to_qa.md # 空
7.2 天然串行化 + 智能跳过
T001(完成) → T002(等待人类) → T003(不依赖T002) → 执行T003
↓
人类决策后恢复执行T002
7.3 完整的审计日志
history_logs/
├── 2026-03-22-093000_to_architect.md # 人类需求
├── 2026-03-22-093010_to_qa.md # 架构师任务
├── 2026-03-22-093020_to_developer.md # QA验收标准
├── 2026-03-22-093100_to_architect.md # 开发者提问
├── 2026-03-22-093200_to_human.md # 完成报告
7.4 极简实现
不需要： - ❌ 消息队列 - ❌ WebSocket长连接 - ❌ 分布式锁 - ❌ 评审角色
只需要： - ✅ 文件系统 - ✅ 定时轮询 - ✅ LLM API调用
八、设计哲学：可控 >自治
8.1 安全左移
传统流程：开发 → 评审（审查安全）→ 发现问题 → 返工 我们的流程：Designer（安全要求）→ QA（安全测试）→ 开发（直接通过）
好处： - 安全问题在源头控制 - 减少返工 - 开发只需遵循既定要求
8.2 功能优先
核心理念： - 快速实现功能是第一优先级 - 可维护性可以事后重构 - 不在开发过程中纠结架构
重构时机： - 功能稳定后 - 一次性重构 - 借助专门的重构Agent
8.3 业界参考
借鉴业界五大编排模式（Microsoft Azure定义）：
| 模式 | 描述 | 适用场景 |
|---|---|---|
| Sequential | 线性串行 | 多阶段流程 |
| Handoff | 控制权交接 | 任务路由 |
| Magnetic | 动态邀请 | 开放任务 |
我们的选择：Sequential + Handoff + 智能跳过。
8.4 核心原则
工程产出 = 流程 × 规范 × 质量门 × 智能调度
我们追求的： - 功能快速产出 - 安全源头控制 - 质量靠流程保证
九、局限性与演进
9.1 当前局限
- 轮询延迟：5秒轮询间隔
- 单lane执行：同时只执行一个任务
- 无断点续传：进程重启后状态丢失
9.2 演进路线
v1.0 (当前)
✅ 三大角色（架构师+QA+开发）
✅ 任务依赖+智能跳过
✅ 安全左移
✅ 功能优先
v2.0
🔄 事件驱动（替代轮询）
🔄 多lane并行
v3.0
📋 可视化监控
📋 智能调度优化
十、总结
串行接力式多智能体协作系统，是对人类工程团队协作方式的数字化模拟：
- 架构师 = 项目经理 + 技术负责人 + 安全要求制定
- 质量标准制定者 = QA分析师 + 测试策略 + 安全测试
- 开发者 = 功能实现者（快速优先，可维护性可后处理）
核心价值：
- 可控：流程由工作流定义
- 可观测：文件状态即系统状态
- 可追溯：每个决策都有完整记录
- 更高效：三大角色，流程精简
- 安全左移：Designer和QA源头控制
- 功能优先：快速产出，可维护性可后处理
在AI时代，我们需要的是可控的协作流程，而非完全自治的黑盒系统。
本文是《串行接力式多智能体协作规范》的深度扩展，形成了一套完整的设计方案。