并行执行与数据反馈

并行执行提升 Agent 的效率上限，数据反馈循环则让 Agent 系统持续进化。两者结合，构成 Agent 系统的性能引擎和学习引擎。

---

1. 并行执行

1.1 Worktree 隔离

Git Worktree 是实现多 Agent 并行开发的关键基础设施：

什么是 Worktree？

Git Worktree 允许在同一个 Git 仓库上创建多个独立的工作目录，每个目录可以切换到不同的分支，彼此互不干扰。

主仓库：/project (main 分支)
  ├── worktree-1: /project-wt1 (feature-auth 分支)  ← Coder A 工作区
  ├── worktree-2: /project-wt2 (feature-api 分支)   ← Coder B 工作区
  └── worktree-3: /project-wt3 (fix-bug-123 分支)   ← Coder C 工作区

为什么 Worktree 适合多 Agent 场景？

• 物理隔离：每个 Agent 操作完全独立的文件目录，零冲突风险
• 共享历史：所有 Worktree 共享 Git 对象库，无需重复克隆
• 轻量高效：创建 Worktree 比 git clone 快得多，占用空间小
• 合并简便：各 Agent 完成后通过 Git merge 整合结果

典型操作流程：

1. Leader 收到复杂任务，拆分为 N 个子任务
2. 为每个子任务创建独立的 Worktree 和分支
3. 分派给不同的 Coder Agent，各自在隔离环境中开发
4. 各 Agent 完成后提交到各自分支
5. Leader 协调合并，解决可能的冲突

1.2 异步执行

Agent 系统中的异步执行模式：

非阻塞任务调度：

• Leader 发派任务后立即返回，不等待 Worker 完成
• 使用异步邮箱（Mailbox）机制跟踪任务状态
• Leader 可以在等待期间处理其他事务

后台进程管理：

• 长时间运行的任务（如编译、测试）放入后台执行
• 通过 terminal_id 异步检查任务进度
• 超时处理：设定最大等待时间，超时后自动中断或升级

状态机模型：

任务状态流转：
PENDING → DISPATCHED → IN_PROGRESS → COMPLETED
                ↓                        ↓
            TIMEOUT → RETRY          FAILED → RETRY
                         ↓                      ↓
                    MAX_RETRIES → ESCALATE (上报 Leader)

1.3 并行度控制

并行不是越多越好，需要合理控制：

资源限制：

• 每个 Agent 消耗 API 调用配额和计算资源
• 设定最大并行 Agent 数量（如：同时最多 5 个 Worker）
• 资源紧张时自动降级为串行执行

冲突检测：

• 分派前检查子任务之间是否有文件依赖
• 依赖图分析：只有无依赖关系的任务才能并行
• 实时监控：发现冲突时自动暂停并通知 Leader

并行策略选择：

策略	适用场景	说明
完全并行	子任务完全独立	所有任务同时执行
流水线	任务有先后依赖	上游完成后触发下游
分批并行	任务量大、资源有限	分批次执行，每批内并行
投机执行	不确定最优方案	多个方案并行尝试，选最优

---

2. 数据反馈循环

2.1 任务轨迹收集（Trace Collection）

每次 Agent 执行任务都会产生宝贵的数据——执行轨迹（Trace）：

轨迹的组成要素：

一条完整的 Trace：
┌─────────────────────────────────────────┐
│ 感知（Perception）                        │
│  ├── 用户输入："修复登录页面的 Bug"        │
│  ├── 环境观察：读取了哪些文件             │
│  └── 工具输出：grep/search 结果           │
├─────────────────────────────────────────┤
│ 推理（Reasoning）                        │
│  ├── 思考过程：分析了哪些可能性           │
│  ├── 决策依据：为什么选择这个方案          │
│  └── 计划制定：执行步骤规划               │
├─────────────────────────────────────────┤
│ 行动（Action）                           │
│  ├── 工具调用：调用了哪些工具、参数        │
│  ├── 执行结果：成功/失败                  │
│  └── 最终产出：代码变更、测试结果          │
└─────────────────────────────────────────┘

收集的关键数据：

• 成功轨迹：任务成功完成的完整执行路径（正样本）
• 失败轨迹：任务失败的执行路径及失败原因（负样本）
• 效率数据：每个步骤的耗时、工具调用次数、重试次数
• 用户反馈：用户对结果的满意度评价

2.2 模型微调（Model Finetuning）

从收集的轨迹数据中提炼知识，改进 Agent 的核心模型：

数据处理流程：

1. 轨迹清洗：过滤噪声数据、标准化格式
2. 质量筛选：优先选择高质量的成功轨迹
3. 对比学习：对比成功与失败轨迹，学习什么有效、什么无效
4. 训练数据构造：将轨迹转化为模型训练所需的格式

微调目标：

• 更好的工具选择：在给定场景下选择最合适的工具
• 更精准的参数生成：生成更准确的工具调用参数
• 更高效的推理路径：减少不必要的探索步骤
• 更好的错误恢复：从失败中学习恢复策略

2.3 反馈闭环

完整的数据反馈循环构成 Agent 系统的持续改进引擎：

反馈闭环：

  ┌───────────┐
  │   执行     │  Agent 在真实任务中运行
  └─────┬─────┘
        ↓
  ┌───────────┐
  │   收集     │  记录完整的执行轨迹
  └─────┬─────┘
        ↓
  ┌───────────┐
  │   分析     │  评估任务成功率、效率指标、常见失败模式
  └─────┬─────┘
        ↓
  ┌───────────┐
  │   优化     │  模型微调、Prompt 优化、工具改进
  └─────┬─────┘
        ↓
  ┌───────────┐
  │   再执行   │  用改进后的系统处理新任务
  └─────┬─────┘
        │
        └──────→ 回到「执行」，循环往复

闭环的关键指标：

指标	说明	优化方向
任务成功率	首次尝试成功完成的比例	提升推理和规划能力
平均步骤数	完成任务所需的平均工具调用次数	减少冗余操作
错误恢复率	遇到错误后成功恢复的比例	增强异常处理能力
用户满意度	用户对最终结果的评分	提升输出质量

---

我的理解与思考