添加学习笔记：Agent系统深度分析

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

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

学习笔记/01-Agent工作循环与多Agent协调.md

@@ -0,0 +1,174 @@
+---
+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能用的信息密度高 → 链式放大。