3eb089b163
- 01-Agent工作循环与多Agent协调:Agent基础循环、多Agent架构、信息流协调 - 02-Claude Multi-Agent Systems深度分析:三个洞见、三个前提假设、三个缺陷 - 03-Hook Fights一句话提炼:极简化的核心观点、洞见、假设、缺陷 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
175 lines
5.6 KiB
Markdown
175 lines
5.6 KiB
Markdown
---
|
||
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能用的信息密度高 → 链式放大。
|