---
name: agent-workflow-loop
description: Agent的标准工作循环和多Agent系统中的协调机制
---

# Agent 工作循环与多 Agent 协调

## Agent 的基础工作循环

```
输入任务 
  ↓
大模型推理 → 确定第一步（tool_use）
  ↓
调用工具 A
  ↓
检查输出是否符合需求
  ├─ ✓ 符合要求 → 添加到 Message History
  │   ↓
  │   继续输入大模型推理
  │   ↓
  │   确定下一步（继续 tool_use 或输出）
  │
  └─ ✗ 不符合要求 → 可能需要调用其他工具或重试
      ↓
      继续循环

最终输出成果 → Agent 停止
```

## 单 Agent 的问题

当一个 Agent 被要求完成"研究→写作→审核→发布"的完整流程时：

| 阶段 | Agent 的目标冲突 |
|------|-----------------|
| 研究 | 最大化信息覆盖度、多源验证 |
| 写作 | 追求流畅表达、字数控制、语态一致 |
| 审核 | 严格质量标准（8/10+）、格式合规 |
| 发布 | 平台适配、SEO、投放优化 |

**问题**：大模型在同一 Message History 中处理这些冲突目标时会产生**上下文漂移**：
- 研究阶段的发现被生产阶段的表达需求压低
- 审核的严格标准与生产的时间压力冲突
- 没有一个清晰的"检查点"确保质量

## 多 Agent 系统的解决方案

通过**分离职责**，每个 Agent 有单一、明确的目标：

### 研究 Agent
```
输入：topic（话题）
大模型目标：找到非显而易见的洞察 + 3+ 源验证
工具链：WebSearch / WebFetch / 文献查询
输出格式：结构化研究简报
  - CORE_INSIGHT
  - SUPPORTING_EVIDENCE（3个例子+源）
  - COUNTERINTUITIVE_ANGLE
  - KEY_DATA
  - CONTENT_ANGLES（3个排序选项）
```

**关键**：大模型只需优化**"研究质量"**这一维度。Message History 中只有研究相关的工具调用。

### 生产 Agent
```
输入：research-brief（来自研究Agent的输出）
大模型目标：按照voice profile 生成高吸引力的初稿
工具链：写文件、检查长度、格式验证
输出格式：drafted content
  - 包含源brief引用
  - 包含选择的角度说明
```

**关键**：大模型不再思考"这个观点对不对"（研究Agent已做），只思考"怎么写得更符合这个作者的风格"。

### 质量 Agent
```
输入：draft（来自生产Agent的输出）
大模型目标：用5维度rubric评分，通过则approve，失败则写revision brief
工具链：评分 → 批准或返回修订
输出格式：要么 APPROVED header，要么 REVISION brief
```

**关键**：大模型不写内容，只做**质量决策**。Message History 中只有评分逻辑。

### 分发 Agent
```
输入：approved-content（来自质量Agent的输出）
大模型目标：将内容适配到各平台格式，部署
工具链：平台适配 → 部署工具（Typefully/Buffer等）
输出格式：部署日志 + 平台特定版本
```

**关键**：大模型不问"内容好不好"，只问"怎么在X平台发"。

## 多 Agent 间的协调机制

文章中的"Orchestrator"本质上是一个**Master Agent**，它的工作循环：

```
Orchestrator 的循环：

输入：任务
  ↓
推理 → "这个任务应该交给谁？"
  ↓
调用工具 = 启动 Research Agent
  ↓
监听文件系统或状态 → Research Agent 完成了吗？
  ├─ Research brief 出现在 research-briefs/ 文件夹
  │   ↓
  │   推理 → "现在交给 Production Agent"
  │   ↓
  │   调用工具 = 启动 Production Agent
  │
  └─ 如果超时或失败 → 回退处理

```

### 关键特性

1. **责任边界明确**  
   - Orchestrator 不做研究、写作、审核、发布
   - 它只做**路由和监控**

2. **故障隔离**  
   - Quality Agent 返回 REVISION → 只需重新启动 Production Agent
   - 不会影响 Research Agent 的成果

3. **反馈循环**  
   ```
   如果 Quality Agent 返回 REVISION：
   Orchestrator 识别 → "回退到 Production Agent"
   传入 revision brief → Production Agent 重新运行
   ```

4. **并行性**（当流程允许时）  
   - 多个任务可以并行处理（Task 1 在研究，Task 2 在生产）
   - 单个任务的各阶段仍是串行（必须先研究再生产）

## 与单 Agent 模型的对比

| 维度 | 单 Agent | 多 Agent 系统 |
|------|---------|-------------|
| 目标一致性 | 混合→上下文漂移 | 单一→稳定 |
| 输出质量 | 不一致（好坏日子有差异） | 一致（有质量门槛） |
| 失败排查 | 难（在哪个阶段失败不清楚） | 易（失败Agent隔离） |
| 反馈积累 | 全局（不清楚是哪部分好） | 局部（知道哪个Agent学到了什么） |
| 执行时间 | T₁ + T₂ + T₃ + T₄（串行） | max(T₁, T₂, T₃, T₄)（可部分并行） |

## 成长曲线

文章提到"10次运行后感觉自然，50次后不可或缺"，对应：

1. **前10次**：Agent能力基线稳定（每个Agent的工具链确定了）
2. **10-50次**：在 CLAUDE.md 中积累性能观察
   - 研究Agent学到哪些源最有用
   - 生产Agent学到哪个角度最吸引受众
   - 质量Agent校准了"8/10"的真实含义
   - 分发Agent知道了各平台的表现差异
3. **50+ 次**：每轮运行都基于前50次的学到的启发，质量螺旋上升

这就是**"系统复利"**：不是单个Agent变更聪明，而是通过结构化反馈，每个Agent的输入质量逐次提高。

---

## 核心洞察

**多Agent系统的威力不在于"更多计算"，而在于"清晰的信息流"**。

单Agent被迫在同一context中权衡多个目标 → 出现冲突 → 产出平庸。
多Agent各自追求单一目标 → 输出高度结构化 → 下一个Agent能用的信息密度高 → 链式放大。