Files

T

- 01-Agent工作循环与多Agent协调：Agent基础循环、多Agent架构、信息流协调
- 02-Claude Multi-Agent Systems深度分析：三个洞见、三个前提假设、三个缺陷
- 03-Hook Fights一句话提炼：极简化的核心观点、洞见、假设、缺陷

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

2026-05-12 21:25:38 +08:00

5.6 KiB

Raw Permalink Blame History

name, description

name	description
agent-workflow-loop	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
  │
  └─ 如果超时或失败 → 回退处理

关键特性

责任边界明确
- Orchestrator 不做研究、写作、审核、发布
- 它只做路由和监控
故障隔离
- Quality Agent 返回 REVISION → 只需重新启动 Production Agent
- 不会影响 Research Agent 的成果

反馈循环

如果 Quality Agent 返回 REVISION：
Orchestrator 识别 → "回退到 Production Agent"
传入 revision brief → Production Agent 重新运行

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

与单 Agent 模型的对比

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

成长曲线

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

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

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

核心洞察

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

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

5.6 KiB Raw Permalink Blame History Unescape Escape