Skill: liusaikang/blog-generation (version 1.0.0)

--- name: blog-writer-cn version: 3.0.0 description: 中文技术博客写作助手。基于 blog-writer 方法论，产出高质量、有个人风格的技术文章。不需要外部依赖，专注于内容创作。 --- # Blog Writer CN 中文技术博客写作助手，帮你写出像跟朋友聊天一样自然、有观点、有态度的技术文章。 **核心理念**： - 拒绝 AI 味，写出真人感 - 有观点、有态度、有真实经历 - 口语化表达，短段落，多小标题 --- ## 🎯 使用场景 当你需要写以下类型的文章时，使用本技能： - **技术教程**："如何搭建 XXX 环境" - **踩坑记录**："XXX 让我折腾了 3 小时的坑" - **观点输出**："为什么我放弃了 XXX" - **技术分析**："对比 A 和 B，我选哪个？" - **新闻资讯**：行业动态、技术趋势盘点 --- ## ✍️ 写作工作流 ``` 1. 用户提出写作需求 2. 【信息收集】确认主题、角度、素材、长度 3. 【风格校准】阅读 style-guide-cn.md 4. 【参考示例】查看 examples/ 中的示例文章 5. 【撰写初稿】按照风格指南产出内容 6. 【用户确认】展示初稿，收集反馈 7. 【迭代修改】根据反馈调整（可多次） 8. 【保存终稿】确认满意后保存为文件 ``` --- ## 📋 写作流程详解 ### Step 1: 信息收集 开始写作前，向用户确认以下信息： | 维度 | 问题 | 示例 | |------|------|------| | **主题** | 写什么？ | "Agent 的记忆机制" | | **角度** | 从什么视角切入？ | 教程 / 踩坑记录 / 观点输出 / 对比分析 | | **素材** | 有没有参考资料？ | 链接、笔记、代码片段、个人经历 | | **长度** | 需要多长？ | 简短(500-800) / 标准(800-1500) / 深度(1500-3000) | | **目标读者** | 写给谁看？ | 初学者 / 有基础者 / 技术专家 | **收集技巧**： - 如果用户只说"帮我写篇文章"，先问主题 - 如果用户给了主题，追问角度（想写成教程还是观点文？） - 如果用户给了链接，先阅读再开始写 --- ### Step 2: 风格校准 **必须阅读** `style-guide-cn.md`，确保理解以下核心原则： #### 🚫 不要 AI 味 AI 生成的文章有明显特征： - 过度使用连接词（首先、其次、最后） - 每段都有总结 - 语言过于正式和书面化 - 缺乏个人观点和情绪 **我们要的**：像跟朋友聊天一样写技术文章。 #### 💡 有观点、有态度 不要写"客观中立"的流水账。好的技术文章应该有： - 明确的立场（这个工具好用/不好用） - 个人判断（我推荐/不推荐） - 真实感受（踩坑的痛苦、解决后的爽感） #### 📝 具体胜过抽象 ❌ "这个工具可以提高开发效率" ✅ "用了这个工具后，我每天能省出 30 分钟摸鱼时间" --- ### Step 3: 参考示例 阅读 `examples/` 目录中的示例文章，感受目标风格： - 开头怎么写？ - 段落多长？ - 小标题怎么起？ - 代码示例怎么呈现？ - 结尾怎么收？ **示例文章列表**： （存放用户确认的终稿文章，用于校准写作风格） --- ### Step 4: 撰写初稿 按照以下结构模板撰写： ```markdown # [直接、有态度的标题] [开头：1-2句话抛出核心观点或问题] ### [小标题1：问题/背景] [2-3个短段落] ### [小标题2：过程/分析] [具体细节、代码、截图] ### [小标题3：解决方案/结论] [实操步骤或观点总结] ### 写在最后 [个人感想、行动号召、或前瞻性思考] ``` #### 标题技巧 好标题的特点： 1. **有数字** - "3 个坑让我搞了 2 小时" - "5 分钟搞定 XXX" 2. **有冲突/转折** - "XXX 官方文档没告诉你的事" - "为什么我放弃了 XXX" 3. **有态度** - "XXX 真的有必要吗？" - "XXX：被低估的神器" #### 开头模式 用强有力的观点或个人经历开场： ✅ **好的开头**： - "搞了两个小时，终于把这个坑填上了。" - "说实话，我一开始是拒绝用 XXX 的。" - "作为一个写了 5 年代码的人，我可以负责任地说：这玩意儿真的有用。" ❌ **避免的开头**： - "随着人工智能的快速发展..." - "在当今数字化时代..." - "本文将介绍..." #### 语言风格 **推荐用词**： | 场景 | 推荐 | 避免 | |------|------|------| | 表达观点 | "说实话"、"坦白讲" | "笔者认为" | | 遇到问题 | "踩了个坑"、"折腾了半天" | "遇到了一些困难" | | 解决问题 | "搞定了"、"终于跑通了" | "成功解决了该问题" | | 推荐 | "强烈推荐"、"真的好用" | "值得一试" | **避免的表达**： - ❌ "首先...其次...最后..." - ❌ "值得注意的是" - ❌ "综上所述" - ❌ "不难发现" - ❌ "众所周知" - ❌ "笔者"（直接用"我"） #### 段落和排版 - **每段 2-4 句话**，最多不超过 5 句 - **单句成段**用于强调重点 - **每 150-250 字**加一个小标题 - 用 `###` 作为主要小标题 - 用 `####` 作为次级小标题 - 小标题要**具体**，不要太抽象 #### 代码块规范 - 代码块前后要有说明 - 长代码要加注释 - 关键代码可以用 `行内代码` 高亮 --- ### Step 5: 用户确认 完成初稿后，展示给用户并询问： ``` 文章初稿已完成！请查收： --- [文章内容预览] --- 你觉得怎么样？需要我： - 📝 修改某些部分？ - 🔧 调整代码示例？ - 📐 改变文章长度？ - 🏷️ 补充特定内容？ - ✅ 直接定稿并保存？ ``` **确认要点**： - 是否符合预期？ - 有无事实性错误？ - 代码是否正确？ - 语气是否合适？ --- ### Step 6: 迭代修改 根据用户反馈进行修改： 1. **理解反馈**：明确用户具体想改什么 2. **针对性修改**：只改用户提到的部分，不要大改 3. **展示修改**：用 diff 或高亮展示改了什么 4. **再次确认**：改完后再次给用户确认 **可以多次迭代**，直到用户满意为止。 --- ### Step 7: 保存终稿 用户确认满意后，保存文章为 Markdown 文件： **文件命名**： ``` YYYY-MM-DD-标题关键词.md ``` **文件内容格式**： ```markdown --- title: 完整标题 date: YYYY-MM-DD tags: [标签1, 标签2, 标签3] category: 技术/观点/教程 --- # 完整标题 [文章内容] --- *文章由 AI 辅助创作，经人工审核确认* ``` **保存位置**： - 用户指定路径，或 - 当前工作目录，或 - `examples/` 目录（如果用户同意作为示例） --- ## 🎨 不同类型文章的写作要点 ### 1. 技术教程类 **结构**： 1. 开头：为什么需要这个？（痛点引入） 2. 环境准备：需要什么前置条件？ 3. 步骤详解：一步步操作，每步有代码 4. 验证结果：怎么确认成功了？ 5. 常见问题：可能遇到的坑 **特点**： - 步骤清晰，可复现 - 代码完整，能直接跑 - 每个关键步骤有说明 --- ### 2. 踩坑记录类 **结构**： 1. 开头：我遇到了什么问题？ 2. 复现过程：怎么触发这个问题的？ 3. 排查过程：我试了哪些方案？ 4. 解决方案：最后是怎么解决的？ 5. 总结：经验教训 **特点**： - 真实经历，有代入感 - 详细记录错误信息和日志 - 方案对比，说明为什么选这个 --- ### 3. 观点输出类 **结构**： 1. 开头：我的观点是什么？ 2. 背景：为什么有这个观点？ 3. 论证：事实、数据、案例支撑 4. 反驳：可能的反对意见及回应 5. 结论：总结观点 **特点**： - 立场明确，不模棱两可 - 有数据或案例支撑 - 承认局限性（不要绝对化） --- ### 4. 技术分析类（对比/选型） **结构**： 1. 开头：要对比什么？什么场景？ 2. 方案A：介绍、优点、缺点 3. 方案B：介绍、优点、缺点 4. 对比表格：关键维度对比 5. 结论：我的选择及理由 **特点**： - 公平客观（但可以有倾向性） - 维度清晰，对比明确 - 给出明确建议 --- ### 5. 新闻资讯类 **结构**： 1. 开头：本期主要内容概览 2. 新闻1：标题 + 摘要 + 原文链接 3. 新闻2：标题 + 摘要 + 原文链接 4. ... 5. 总结：趋势观察或个人观点 **特别要求**： - **必须附带原文链接** - 格式：`[新闻标题](原文URL)` 或 `👉 [查看原文](URL)` - 用自己的话概括，不要直接复制 - 加入简短点评 --- ## 📁 目录结构 ``` blog-writer-cn/ ├── SKILL.md # 本技能文档 ├── style-guide-cn.md # 中文写作风格指南（核心参考） └── examples/ # 示例文章库 └── YYYY-MM-DD-title.md # 示例文章 ``` --- ## 📝 风格指南速查 ### 核心原则 1. 不要 AI 味（像跟朋友聊天） 2. 有观点、有态度 3. 具体胜过抽象 ### 开头模板 - "搞了两个小时，终于把这个坑填上了。" - "说实话，我一开始是拒绝用 XXX 的。" - "作为一个写了 X 年 XX 的人，我可以负责任地说..." ### 结构模板 ```markdown # [直接、有态度的标题] [开头：1-2句话抛出核心观点或问题] ### [小标题1：问题/背景] [2-3个短段落] ### [小标题2：过程/分析] [具体细节、代码、截图] ### [小标题3：解决方案/结论] [实操步骤或观点总结] ### 写在最后 [个人感想、行动号召、或前瞻性思考] ``` ### 检查清单 写作完成后自查： - [ ] 标题是否有吸引力？ - [ ] 开头是否直接切入主题？ - [ ] 是否有"首先、其次、最后"等模板句式？ - [ ] 段落是否太长（超过 5 句）？ - [ ] 是否有个人观点和态度？ - [ ] 结尾是否自然？ - [ ] 通读一遍，像不像跟朋友聊天？ - [ ] **新闻类文章**：每条新闻是否都有原文链接？ --- ## 🔗 相关资源 - `style-guide-cn.md` - 完整的中文写作风格指南 - `examples/` - 示例文章库 - 参考博客：阮一峰的网络日志、酷壳、美团技术团队 --- ## 💡 使用技巧 ### 如何提出好的写作需求 **❌ 不好的需求**： - "帮我写篇文章" - "写一篇关于 Python 的" **✅ 好的需求**： - "帮我写一篇关于 Python 装饰器的教程，面向初学者，800字左右" - "我遇到个问题：用 Docker 部署 Flask 时端口映射不生效，帮我写个踩坑记录" - "对比一下 FastAPI 和 Flask，我从 Flask 迁移到 FastAPI 的真实体验" ### 如何提供素材 如果你有参考资料，可以这样提供： - 链接："参考这篇文章：[链接]" - 笔记："这是我整理的要点：..." - 代码："这是我的实现代码：..." - 经历："上周我遇到这样一个问题：..." ---

path: style-guide-cn.md
content: # 中文技术博客写作风格指南

> 本指南基于 blog-writer skill 的写作方法论，针对中文技术博客进行本地化。

---

## 核心原则

### 1. 不要 AI 味

AI 生成的文章有明显的"味道"：
- 过度使用连接词（首先、其次、最后）
- 每段都有总结
- 语言过于正式和书面化
- 缺乏个人观点和情绪

**我们要的是**：像跟朋友聊天一样写技术文章。

### 2. 有观点、有态度

不要写"客观中立"的流水账。好的技术文章应该有：
- 明确的立场（这个工具好用/不好用）
- 个人判断（我推荐/不推荐）
- 真实感受（踩坑的痛苦、解决后的爽感）

### 3. 具体胜过抽象

❌ "这个工具可以提高开发效率"
✅ "用了这个工具后，我每天能省出 30 分钟摸鱼时间"

---

## 开头模式

### 好的开头示例

**个人经历型：**
- "搞了两个小时，终于把这个坑填上了。记录一下，免得下次又踩。"
- "说实话，我一开始是拒绝用 Docker 的。直到上周部署炸了..."
- "作为一个写了 5 年 Python 的人，我可以负责任地说：这个库真的香。"

**观点输出型：**
- "我知道这个观点可能有争议，但我还是要说：XXX 被高估了。"
- "用了三个月 XXX 之后，我想聊聊它的真实体验。"
- "很多教程都没告诉你的一件事是..."

**问题驱动型：**
- "你有没有遇到过这种情况：XXX？我有，而且被折腾得够呛。"
- "如果你也在纠结 A 和 B 怎么选，这篇文章可能对你有帮助。"

### 避免的开头

❌ "随着人工智能的快速发展..."
❌ "在当今数字化时代..."
❌ "众所周知，XXX 是一个重要的技术..."
❌ "本文将介绍..."

---

## 结构模板

```markdown
# [直接、有态度的标题]

[开头：1-2句话，抛出核心观点或问题，吸引读者继续看]

### 背景 / 问题是什么

[简短说明遇到了什么问题，或者为什么要写这篇文章]
[2-3个短段落即可]

### 过程 / 怎么解决的

[具体的操作步骤、代码、截图]
[这部分可以长一些，但要分小节]

#### 小节1
[具体内容]

#### 小节2
[具体内容]

### 踩坑记录 / 注意事项

[遇到的问题和解决方案]
[这部分读者最爱看]

### 写在最后

[个人感想、总结、或者对读者的建议]
[不要写"综上所述"，写点真实的想法]
```

---

## 标题技巧

### 好标题的特点

1. **有数字**
   - "3 个坑让我搞了 2 小时"
   - "5 分钟搞定 XXX"
   - "我用 XXX 的 100 天"

2. **有冲突/转折**
   - "XXX 官方文档没告诉你的事"
   - "为什么我放弃了 XXX"
   - "从入门到放弃，再到真香"

3. **有悬念**
   - "没想到最后是这样解决的"
   - "一个让我困惑了三天的 Bug"
   - "这个功能藏得太深了"

4. **有态度**
   - "XXX 真的有必要吗？"
   - "别再用 XXX 了"
   - "XXX：被低估的神器"

### 避免的标题

❌ "浅谈 XXX"
❌ "XXX 技术详解"
❌ "关于 XXX 的一些思考"
❌ "XXX 入门教程"（太普通）

---

## 语言风格

### 推荐用词

| 场景 | 推荐 | 避免 |
|------|------|------|
| 表达观点 | "说实话"、"坦白讲"、"我觉得" | "笔者认为"、"不难发现" |
| 遇到问题 | "踩了个坑"、"折腾了半天"、"卡住了" | "遇到了一些困难" |
| 解决问题 | "搞定了"、"终于跑通了"、"真香" | "成功解决了该问题" |
| 推荐 | "强烈推荐"、"真的好用"、"谁用谁知道" | "值得一试" |
| 不推荐 | "别用"、"坑太多"、"不值得" | "不太建议使用" |
| 转折 | "但是"、"不过"、"话说回来" | "然而"、"但值得注意的是" |

### 避免的表达

❌ "首先...其次...最后..."
❌ "值得注意的是"
❌ "综上所述"
❌ "不难发现"
❌ "众所周知"
❌ "笔者"（直接用"我"）

### 可以用的口语化表达

- "说白了就是..."
- "简单来说..."
- "划重点："
- "敲黑板："
- "血泪教训："
- "真香警告："

---

## 段落和排版

### 段落长度

- **每段 2-4 句话**，最多不超过 5 句
- **单句成段**用于强调重点
- **每 150-250 字**加一个小标题

### 小标题使用

- 用 `###` 作为主要小标题
- 用 `####` 作为次级小标题
- 小标题要**具体**，不要太抽象

✅ "### 安装 Docker"
❌ "### 第一步"

✅ "### 为什么选择 FastAPI"
❌ "### 技术选型"

### 代码块

- 代码块前后要有说明
- 长代码要加注释
- 关键代码可以用 `行内代码` 高亮

### 列表使用

- 列表用于**真正的列举**，不要用于正文
- 3-7 项最佳，太长就分组
- 每项保持简短

---

## 个人经历融入

### 什么时候用

- 说明为什么要研究这个话题
- 分享踩坑经历
- 给出推荐/不推荐的理由

### 怎么写

**包含具体细节：**
- 时间："上周"、"用了三个月"
- 数字："试了 5 种方案"、"花了 2 小时"
- 场景："在部署到生产环境时"

**连接到主题：**
个人经历要服务于文章主题，不要跑题。

### 示例

> 上周部署一个 Python 项目，死活跑不起来。查了两个小时，最后发现是 Python 版本的问题。这件事让我意识到，环境管理真的太重要了。所以今天想聊聊 pyenv 这个工具。

---

## 结尾模式

### 好的结尾

**行动号召型：**
- "如果你也遇到类似的问题，不妨试试这个方案。"
- "有问题欢迎评论区交流。"

**个人感想型：**
- "折腾了这么久，总算搞明白了。希望这篇文章能帮到你。"
- "虽然过程很痛苦，但学到了不少东西。"

**前瞻型：**
- "下一篇打算写 XXX，感兴趣的可以关注一下。"
- "这个领域还有很多值得探索的地方。"

### 避免的结尾

❌ "综上所述，本文介绍了..."
❌ "希望本文对读者有所帮助。"
❌ "以上就是本文的全部内容。"

---

## 新闻资讯类文章

写新闻汇总、行业日报、资讯盘点等文章时，有额外要求：

### 必须附带原文链接

每条新闻都要有跳转链接，方便读者查看原文详情。

**格式选择：**

1. **标题即链接**（推荐）
   ```markdown
   ### [特斯拉宣布停产 Model S/X](https://example.com/news/123)
   ```

2. **末尾标注**
   ```markdown
   ### 特斯拉宣布停产 Model S/X
   
   新闻内容...
   
   👉 [查看原文](https://example.com/news/123)
   ```

3. **来源标注**（链接不可用时）
   ```markdown
   ### 特斯拉宣布停产 Model S/X
   
   新闻内容...（来源：36氪）
   ```

### 新闻摘要写法

- 用自己的话概括，不要直接复制原文
- 加入简短点评，体现个人观点
- 保持每条新闻 50-150 字

---

## 检查清单

发布前检查：

- [ ] 标题是否有吸引力？
- [ ] 开头是否直接切入主题？
- [ ] 是否有"首先、其次、最后"等模板句式？
- [ ] 段落是否太长（超过 5 句）？
- [ ] 是否有个人观点和态度？
- [ ] 结尾是否自然？
- [ ] 通读一遍，像不像跟朋友聊天？
- [ ] **新闻类文章**：每条新闻是否都有原文链接？

---

## 参考资源

- `examples/` 目录中的示例文章
- `skills/blog-writer/` 中的英文风格指南（可参考结构）
- 优秀的中文技术博客：阮一峰、酷壳、美团技术博客

---

*最后更新：2025-02-02*


path: examples/2025-04-07-react-vs-plan-execute.md
content: # ReAct vs Plan-and-Execute：我试了两种Agent架构后，发现选择比努力更重要

说实话，我刚做 Agent 的时候，根本不知道还有这么多架构流派。拿着 LangChain 的 ReAct 模板就往上怼，结果在生产环境栽了个大跟头——一个复杂的任务，Agent 在那儿反复思考、调用工具、再思考、再调用，循环了 20 多次还没搞定。用户直接放弃了。

后来我才明白：**Agent 架构选错了，后面的优化都是徒劳。**

这篇文章聊聊我踩过的坑，以及 ReAct 和 Plan-and-Execute 到底该怎么选。

---

## 什么是 ReAct？

ReAct（Reasoning + Acting）大概是现在最流行的 Agent 架构了。它的核心思想很简单：

**思考 → 行动 → 观察 → 再思考 → 再行动...**

就像一个边想边做的人，每做一步都要停下来看看结果，然后决定下一步怎么做。

**典型的工作流程：**

```
用户：查询北京今天的天气，然后发邮件给张三

Agent:
1. 思考：用户要我查天气，我需要调用天气查询工具
2. 行动：调用 get_weather(city="北京")
3. 观察：天气 API 返回"晴，25度"
4. 思考：现在知道天气了，接下来要发邮件。我需要张三的邮箱地址
5. 行动：调用 get_contact(name="张三")
6. 观察：返回邮箱 [REDACTED_SECRET]
7. 思考：现在可以发邮件了
8. 行动：调用 send_email(to="[REDACTED_SECRET]", content="北京今天晴，25度")
9. 观察：邮件发送成功
10. 思考：任务完成
```

**代码示例（简化版）：**

```python
class ReActAgent:
    def __init__(self, llm, tools):
        self.llm = llm
        self.tools = {t.name: t for t in tools}
    
    def run(self, query, max_iterations=10):
        context = f"用户请求：{query}\n\n"
        
        for i in range(max_iterations):
            # 1. 思考
            thought = self.llm.predict(
                f"{context}\n基于以上信息，你需要：\n1. 分析当前状态\n2. 决定下一步行动\n\n思考："
            )
            context += f"思考：{thought}\n"
            
            # 2. 决定行动
            action_json = self.llm.predict(
                f"{context}\n根据你的思考，选择一个工具行动（JSON格式）："
            )
            action = parse_json(action_json)
            
            if action["tool"] == "finish":
                return action["answer"]
            
            # 3. 执行行动
            tool_result = self.tools[action["tool"]].run(**action["params"])
            context += f"行动：使用 {action['tool']}\n观察：{tool_result}\n\n"
        
        return "达到最大迭代次数，任务未完成"
```

**ReAct 的优点：**
- 灵活性强，适合处理不确定性高的任务
- 每一步都可以根据最新观察调整策略
- 思路清晰，容易调试

**但缺点也很明显：**
- **Token 消耗大**：每步都要 LLM 参与
- **延迟高**：串行执行，工具调用次数多
- **容易陷入循环**：遇到边界情况会一直反复尝试
- **不适合复杂任务**：步骤一多，上下文就爆炸

---

## 什么是 Plan-and-Execute？

Plan-and-Execute（计划与执行）走的是另一条路：**先想好了再做**。

它把任务分成两个阶段：
1. **Planning（计划阶段）**：LLM 一次性生成完整的执行计划
2. **Execution（执行阶段）**：按照计划逐步执行，必要时可以重新规划

**典型的工作流程：**

```
用户：查询北京今天的天气，然后发邮件给张三

阶段1 - 制定计划：
Agent 思考后生成计划：
[
  {"step": 1, "action": "查询北京天气", "tool": "get_weather", "params": {"city": "北京"}},
  {"step": 2, "action": "获取张三邮箱", "tool": "get_contact", "params": {"name": "张三"}},
  {"step": 3, "action": "发送邮件", "tool": "send_email", "depends_on": [1, 2]}
]

阶段2 - 执行计划：
- 并行执行 step 1 和 step 2（因为无依赖）
- 获取结果后执行 step 3
- 完成
```

**代码示例（简化版）：**

```python
class PlanAndExecuteAgent:
    def __init__(self, llm, tools):
        self.llm = llm
        self.tools = {t.name: t for t in tools}
    
    def create_plan(self, query):
        """第一步：制定计划"""
        prompt = f"""
        用户请求：{query}
        
        可用工具：{list(self.tools.keys())}
        
        请制定一个详细的执行计划，以 JSON 数组格式返回：
        [
          {{"step": 1, "action": "描述", "tool": "工具名", "params": {{}}, "depends_on": []}},
          ...
        ]
        """
        plan_json = self.llm.predict(prompt)
        return parse_json(plan_json)
    
    def execute_plan(self, plan):
        """第二步：执行计划"""
        results = {}
        
        for step in sorted(plan, key=lambda x: x["step"]):
            # 等待依赖完成
            for dep in step.get("depends_on", []):
                if dep not in results:
                    raise Exception(f"步骤 {step['step']} 依赖的步骤 {dep} 尚未完成")
            
            # 执行当前步骤
            tool = self.tools[step["tool"]]
            
            # 替换参数中的变量引用
            params = resolve_params(step["params"], results)
            
            result = tool.run(**params)
            results[step["step"]] = result
            
            # 如果执行失败，可以重新规划
            if is_failure(result):
                return self.replan(plan, step, result)
        
        return results
    
    def run(self, query):
        plan = self.create_plan(query)
        print(f"生成的计划：{json.dumps(plan, ensure_ascii=False, indent=2)}")
        return self.execute_plan(plan)
```

**Plan-and-Execute 的优点：**
- **效率高**：可以并行执行独立步骤
- **Token 消耗低**：计划阶段只用一次 LLM
- **结构清晰**：任务分解明确，便于监控
- **适合复杂任务**：多步骤任务也能很好处理

**缺点：**
- **不够灵活**：计划一旦制定，中途调整成本高
- **需要重规划机制**：遇到意外情况要能重新生成计划
- **对 LLM 规划能力要求高**：计划不合理会导致执行失败

---

## 两种架构的详细对比

| 维度 | ReAct | Plan-and-Execute |
|------|-------|------------------|
| **执行方式** | 串行，一步一思考 | 先计划，后执行（可并行） |
| **灵活性** | 高，随时调整策略 | 中，需要重规划机制 |
| **Token 消耗** | 高（每步都调用 LLM） | 低（计划阶段只用一次） |
| **延迟** | 高（串行+多次 LLM 调用） | 低（可并行执行） |
| **适用任务** | 简单、不确定性高 | 复杂、步骤明确 |
| **调试难度** | 低（步骤清晰） | 中（需要追踪计划执行） |
| **容错性** | 高（随时可调整） | 中（需要重规划） |

---

## 我是怎么选择的？

经过几个项目的折腾，我总结了一个简单的决策树：

```
任务分析：
│
├─► 步骤是否明确可预测？
│   ├─ 是 → Plan-and-Execute
│   └─ 否 → ReAct
│
├─► 是否需要频繁根据反馈调整？
│   ├─ 是 → ReAct
│   └─ 否 → Plan-and-Execute
│
├─► 步骤数量？
│   ├─ ≤ 3步 → ReAct（简单直接）
│   └─ > 3步 → Plan-and-Execute（避免上下文爆炸）
│
└─► 是否需要并行执行？
    ├─ 是 → Plan-and-Execute
    └─ 否 → 都可以
```

**我的实战经验：**

| 场景 | 推荐架构 | 原因 |
|------|----------|------|
| 客服问答 | ReAct | 用户问题不确定，需要灵活应对 |
| 数据分析报告生成 | Plan-and-Execute | 步骤明确：获取数据→清洗→分析→可视化→生成报告 |
| 代码审查 | ReAct | 需要逐行分析，不确定哪里有问题 |
| 自动化工作流 | Plan-and-Execute | 步骤固定，追求效率 |
| 研究助手 | 混合 | 先 Plan 粗粒度步骤，每个步骤内部用 ReAct |

---

## 混合架构：取长补短

其实现在越来越多的框架采用**混合策略**：

```python
class HybridAgent:
    """混合架构：顶层 Plan-and-Execute，底层 ReAct"""
    
    def run(self, query):
        # 1. 先做高层规划
        high_level_plan = self.create_high_level_plan(query)
        
        results = []
        for step in high_level_plan:
            # 2. 每个复杂步骤内部用 ReAct 执行
            if step["complexity"] == "high":
                result = self.react_agent.run(step["task"])
            else:
                # 简单步骤直接执行
                result = self.execute_simple(step)
            
            results.append(result)
            
            # 3. 检查是否需要重规划
            if should_replan(results):
                high_level_plan = self.replan(query, results)
        
        return self.synthesize_results(results)
```

这样既保证了整体效率，又保留了应对不确定性的能力。

---

## 踩坑记录

**坑 1：ReAct 的无限循环**

有一次做网页爬虫 Agent，遇到反爬机制返回了验证码页面。Agent 一直在"观察页面→尝试点击→失败→再观察"的循环里出不来。

**解决方案：**
- 设置最大迭代次数
- 加入异常检测机制
- 连续失败 3 次就触发人工介入或重规划

**坑 2：Plan-and-Execute 的计划过于乐观**

LLM 制定的计划经常假设一切顺利，但现实中工具调用会失败、API 会超时、数据会缺失。

**解决方案：**
- 每个步骤都要有错误处理
- 计划里预留备选方案
- 执行失败时触发局部重试或全局重规划

**坑 3：两种架构的上下文管理**

ReAct 的上下文会线性增长，Plan-and-Execute 在执行阶段如果不注意，也会累积大量中间结果。

**解决方案：**
- ReAct：定期总结历史，保留关键信息
- Plan-and-Execute：每个步骤只传递必要的结果，不要传递整个执行历史

---

## 写在最后

选架构不是选边站，而是**根据任务特点做权衡**。

我的建议是：

1. **从 ReAct 开始**：实现简单，容易调试，适合快速验证想法
2. **遇到性能瓶颈时**：如果 Token 消耗太大或响应太慢，考虑 Plan-and-Execute
3. **复杂任务用混合**：别纠结非此即彼，取长补短才是王道
4. **监控和优化**：不管选哪种，都要加日志、加监控，数据说话

最后说句掏心窝的话：架构只是工具，**理解你的任务和用户才是核心**。别为了追求"先进"的架构，把简单问题复杂化了。

你目前在用哪种架构？遇到了什么问题？欢迎在评论区聊聊。

---

*这篇文章整理自我在实际项目中的架构选型经验。技术变化快，但选择的原则相对恒定。希望能帮你少走点弯路。*


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)