# Blog-Writing-Agent：一个基于 LangGraph 的智能博客写作代理

> 探索 Blog-Writing-Agent 的架构设计，这是一个使用 LangGraph 构建的多步骤博客写作代理，能够自动进行网络研究、构建语义大纲并生成基于事实的高质量技术博客。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-30T03:14:26.000Z
- 最近活动: 2026-05-30T03:21:27.703Z
- 热度: 150.9
- 关键词: LangGraph, AI Agent, Blog Writing, LangChain, Tavily, LLM, Structured Output, Multi-step Workflow
- 页面链接: https://www.zingnex.cn/forum/thread/blog-writing-agent-langgraph
- Canonical: https://www.zingnex.cn/forum/thread/blog-writing-agent-langgraph
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：Darsh-Nandu
- 来源平台：GitHub
- 原始标题：Blog-Writing-Agent
- 原始链接：https://github.com/Darsh-Nandu/Blog-Writing-Agent
- 来源发布时间/更新时间：2026-05-30T03:14:26Z

## 项目背景与动机

在生成式 AI 时代，大型语言模型（LLM）已经能够生成看似流畅的文本，但一个普遍存在的问题是：这些文本往往缺乏事实依据，充斥着"AI 腔"的套话和空洞的营销辞令。许多自动生成的博客文章虽然语法正确，但内容浮于表面，无法为读者提供真正有价值的技术洞察。

Blog-Writing-Agent 正是为了解决这一痛点而诞生的。它的核心理念很简单：不要只让 AI "写作"，而要让它 "思考"。通过引入多步骤工作流、实时网络研究和结构化规划，这个代理能够生成扎根于事实、具有技术深度的博客内容，而非仅仅是语言的堆砌。

## 架构概览：基于 LangGraph 的工作流编排

Blog-Writing-Agent 采用 LangGraph 作为其核心编排框架。LangGraph 是 LangChain 的扩展，专门用于构建具有循环、条件分支和状态管理的复杂代理工作流。与简单的线性链式调用不同，LangGraph 允许开发者定义具有复杂控制流的图结构，非常适合需要多步骤决策的博客写作任务。

整个系统由五个核心节点组成，形成一个有向图：

1. **Router（路由节点）**：决定是否需要网络研究，以及采用何种模式（closed_book/hybrid/open_book）
2. **Research（研究节点）**：使用 Tavily 搜索 API 执行实时网络查询，收集证据
3. **Orchestrator（编排节点）**：基于主题和证据生成结构化的博客大纲（Plan）
4. **Worker（工作节点）**：并行执行各个章节的写作任务
5. **Reducer（归约节点）**：将各个章节合并为最终的完整博客文章

这种设计充分利用了 LangGraph 的 `Send` 原语，实现了工作节点的动态扇出（fanout），使得多个章节可以并行撰写，显著提高了生成效率。

## 智能路由：三种写作模式的自适应选择

项目的一个亮点是其智能路由系统。Router 节点会根据用户输入的主题，自动判断最合适的写作策略：

### Closed Book 模式（无需研究）

适用于 evergreen 主题——那些不依赖于最新事实的基础概念和技术原理。例如"什么是 Transformer 架构"、"RAG 的基本原理"等。在这种模式下，代理完全依赖内部知识，跳过网络研究步骤，直接进行内容规划。

### Hybrid 模式（混合研究）

适用于大部分需要更新示例和工具信息的主题。代理会搜索最新的模型、工具版本或行业实践，但核心概念解释仍基于内部知识。研究结果的时效性窗口设置为 45 天，确保示例不过时。

### Open Book 模式（实时新闻综述）

专为时效性强的主题设计，如"本周 AI 领域的重要发布"。代理会强制生成新闻综述类型的博客，研究窗口缩短至 7 天，确保内容反映最新的行业动态。

路由决策通过结构化输出实现，使用 Pydantic 模型定义 `RouterDecision`，包含研究需求、模式选择、查询生成和结果数量等字段。这种设计使得路由逻辑清晰、可扩展，并且易于调试。

## 研究层：Tavily 搜索与证据结构化

当路由节点决定需要研究时，Research 节点会接管工作。它使用 Tavily 搜索 API 执行多个并行查询，每个查询最多返回 6 条结果。Tavily 是一个专门为 AI 应用设计的搜索引擎，返回的结果包含标题、URL、摘要和发布日期等结构化信息。

研究节点的一个关键功能是证据的结构化处理。原始搜索结果会被传递给 LLM，使用 `with_structured_output` 提取器将其转换为 `EvidenceItem` 对象列表。每个证据项包含标题、URL、发布日期、来源和摘要。

为了去重，系统使用 URL 作为唯一键，确保同一条信息不会被重复计算。对于 Open Book 模式，还会执行严格的时效性过滤：只保留在指定时间窗口内（默认 7 天）发布的证据，确保新闻综述的时效性。

这种设计体现了"证据驱动写作"的理念：博客中的每一个事实性主张都应该有可追溯的来源，而非模型的幻觉。

## 编排层：结构化大纲生成

Orchestrator 节点是系统的"大脑"。它接收主题、写作模式和证据列表，输出一个结构化的 `Plan` 对象。这个计划定义了博客的标题、目标读者、语气、类型（解释性/教程/新闻综述/对比/系统设计）以及详细的章节任务列表。

每个章节任务（Task）包含以下要素：

- **目标（Goal）**：一句话描述读者在本章结束后应该理解或能够做什么
- **要点（Bullets）**：3-6 个具体、不重叠的子要点，指导章节内容
- **目标字数（Target Words）**：120-550 字，用于控制整体篇幅
- **标签（Tags）**：可选的分类标签
- **研究需求标记**：`requires_research` 和 `requires_citations` 标记是否需要引用证据
- **代码需求标记**：`requires_code` 标记是否需要包含代码示例

编排器使用精心设计的系统提示词（ORCH_SYSTEM），要求 LLM 遵循开发者视角、使用正确的术语、确保要点可执行（构建/比较/测量/验证/调试），并且必须包含至少两项：最小代码示例、边缘案例/失败模式、性能/成本考量、安全/隐私考量、调试/可观测性技巧。

对于 Open Book 模式，编排器会强制设置 `blog_kind=news_roundup`，并确保计划聚焦于事件总结和影响分析，而非教程式的操作指南。

## 工作层：并行章节生成

Worker 节点是真正执行写作任务的地方。得益于 LangGraph 的 `Send` 原语，系统可以为 Plan 中的每个章节任务创建一个独立的 Worker 调用，这些调用可以并行执行。

每个 Worker 接收完整的上下文信息：博客标题、目标读者、语气、章节任务详情，以及相关的证据列表。Worker 使用 WORKER_SYSTEM 提示词指导 LLM 生成章节内容。

Worker 层的提示词设计体现了对质量的严格控制：

- 必须遵循目标并覆盖所有要点，不能跳过或合并
- 字数必须接近目标值（±15%）
- 仅输出章节内容（Markdown），不包含博客标题等额外内容
- 必须以 `## <章节标题>` 开头
- 对于 Open Book 模式，每个事实性主张必须有证据支持，使用 Markdown 链接格式引用来源
- 如果 `requires_code` 为真，必须包含相关代码片段

这种设计确保了每个章节的质量和一致性，同时通过并行化显著提高了生成速度。

## 归约层：内容整合与输出

Reducer 节点负责将并行生成的章节整合为最终的博客文章。它按照章节 ID 排序，将各个 Markdown 片段用换行符连接，并在开头添加博客标题作为 H1 标题。

最终的文章以 `{blog_title}.md` 的文件名写入本地文件系统。这种简单的归约策略确保了章节顺序正确，同时保留了每个 Worker 生成的原始格式。

## 状态管理与数据流

整个系统使用 LangGraph 的 `State` 机制进行状态管理。State 是一个 TypedDict，定义了整个工作流中传递的数据结构：

```python
class State(TypedDict):
    topic: str
    mode: str
    needs_research: bool
    queries: List[str]
    evidence: List[EvidenceItem]
    plan: Optional[Plan]
    as_of: str          # ISO 日期
    recency_days: int   # 时效性窗口
    sections: Annotated[List[tuple[int, str]], operator.add]
    final: str
```

值得注意的是 `sections` 字段使用了 `Annotated` 和 `operator.add`，这告诉 LangGraph 这是一个"归约通道"——多个 Worker 的输出会被自动收集到一个列表中。这种设计使得并行 Worker 的结果收集变得透明和自动。

## 技术选型与依赖

项目的技术栈体现了对现代 LLM 开发工具的熟练运用：

- **LangChain / LangGraph**：核心框架，提供模型抽象、工具集成和图编排能力
- **ChatOllama**：本地 LLM 接口，默认使用 llama3.1 模型，支持低成本本地部署
- **Tavily**：研究层搜索 API，专为 AI 应用优化
- **Pydantic**：结构化数据验证，用于定义 Plan、Task、EvidenceItem 等数据模型
- **Python 3.10+**：类型注解、TypedDict、Annotated 等新特性

这种技术选型使得项目既可以在本地低成本运行（使用 Ollama），也可以轻松迁移到云端 API（如 OpenAI、Anthropic），具有良好的灵活性。

## 版本演进与迭代思路

从代码结构可以看出，项目经历了至少三个版本的迭代：

- **BWA_1.0**：早期原型
- **BWA_2.0**：功能完善版本
- **BWA_3.0**：当前稳定版本，包含完整的五节点工作流

这种迭代方式体现了渐进式开发的理念：先实现核心功能，再逐步添加复杂性（路由决策、证据过滤、并行生成等）。每个版本目录独立，便于回溯和对比。

## 实践启示与应用场景

Blog-Writing-Agent 的设计为构建生产级的 AI 写作工具提供了有价值的参考：

1. **事实性优先**：通过强制证据引用和时效性过滤，解决了 LLM 幻觉问题
2. **模块化设计**：每个节点职责单一，便于测试、调试和独立优化
3. **自适应策略**：三种写作模式覆盖了从基础概念到实时新闻的不同场景
4. **并行优化**：利用 LangGraph 的扇出能力，显著提升长文生成效率
5. **结构化输出**：使用 Pydantic 模型确保数据一致性，便于下游处理

这个项目适合需要生成技术博客、新闻综述或研究摘要的场景，特别是那些对事实准确性有严格要求的应用。开发者可以基于这个框架进行扩展，例如添加图片生成、多语言翻译、SEO 优化等功能。

## 结语

Blog-Writing-Agent 展示了如何将 LLM 从"文本生成器"升级为"研究-写作助手"。通过引入网络研究、结构化规划和证据引用，它解决了纯 LLM 写作中的事实性不足和"AI 腔"问题。这种"思考+写作"的双轮驱动模式，代表了 AI 辅助内容创作的一个有前景的方向。