WriteHERE 深度测评：当 AI 学会「边写边想」，长文本生成的游戏规则变了

Q: WriteHERE 和 STORM 有什么区别？

STORM 采用「先生成大纲、再逐段写作」的固定工作流，大纲一旦生成就不再修改。WriteHERE 使用异构递归规划（HRP），允许在写作过程中动态调整计划，中途可以插入检索和推理子任务。实验数据显示，WriteHERE 在报告深度上比 STORM 高出 0.49 分（5 分制）。

Q: WriteHERE 需要哪些 API Key？

WriteHERE 需要三个 API Key：OpenAI（用于 GPT-4o）、Anthropic（用于 Claude）和 SerpAPI（用于搜索检索功能）。报告生成模式硬性依赖 SerpAPI，纯故事生成模式可以不用搜索功能。

Q: WriteHERE 适合写小说吗？

WriteHERE 支持虚构写作，实验中在 Tell Me A Story 数据集上的表现远超 Agent's Room。但如果是长篇网文（10 万字以上），推荐使用专门的 InkOS（10 Agent 流水线 + 33 维度审计）。WriteHERE 更适合短中篇故事和技术报告。

Q: WriteHERE 是免费的吗？

WriteHERE 本身完全免费开源（MIT 许可证），但运行时需要 LLM API Key，会产生 token 费用。用 GPT-4o 生成一篇 3000 字技术报告，API 费用约 $2-5。

Q: WriteHERE 的论文在哪里看？

论文标题为「Beyond Outlining: Heterogeneous Recursive Planning for Adaptive Long-form Writing with Language Models」，发表于 EMNLP 2025（苏州），arXiv 编号 2503.08275，ACL Anthology 编号 2025.emnlp-main.1254。

一句话说清楚

WriteHERE 是一个开源的 AI 长文本写作框架，来自 KAUST（沙特阿卜杜拉国王科技大学），论文被 EMNLP 2025 接收为 Oral 报告。核心思路只有一句话：别先写大纲，边写边规划。 但这一句话背后，是对整个 AI 写作范式的重新定义。

为什么你需要关心这个项目

你用 ChatGPT 写过超过 3000 字的内容吗？

如果有，你大概率遇到过这个问题：写着写着，前后矛盾了。前面说主角性格内向，后面突然变成社交达人。或者写技术报告，第一段的数据和第五段的结论对不上。

这不是 LLM 笨。是指挥 LLM 的方式有问题。

目前主流的 AI 写作工具——不管是 Notion AI、Jasper 还是开源的 STORM——都遵循同一个逻辑：先生成大纲，再逐段填充。 大纲一旦定下来，就像浇了水泥的模具，后面不管发生什么，都得按这个形状往里灌。

WriteHERE 说：这不对。人写东西不是这样的。

你写一篇深度文章，写到第三段发现第二段的论点有问题，你会怎么做？划掉重写，甚至推翻整个结构。你不会说”算了，大纲已经定了，硬着头皮往下写吧”。

WriteHERE 就是让 AI 学会了这种”中途变卦”的能力。

它到底怎么工作的：三类任务，一棵树

WriteHERE 的技术核心叫异构递归规划（Heterogeneous Recursive Planning, HRP）。名字唬人，原理其实很直觉。

它把”写作”这件事拆成三种基本动作：

任务类型	做什么	例子
检索（Retrieval）	找信息	搜索某个技术的最新数据、查证一个事实
推理（Reasoning）	想清楚	这个论点站得住脚吗？两个矛盾的数据怎么调和？
写作（Composition）	写出来	根据已有信息，产出一段连贯的文字

关键来了——这三种任务不是按顺序排排坐，而是递归嵌套的。

举个例子：你让它写一篇关于 AI 伦理的技术报告。

顶层任务：写报告（Composition）
它先拆解 → 第一章需要”AI 伦理的历史背景”（Retrieval）+ “核心争议分析”（Reasoning）
检索任务执行中发现，有个关键数据互相矛盾 → 触发一个新的推理子任务
推理子任务需要更多证据 → 又触发一个检索子任务
检索完成，推理得出结论，回到写作任务继续

整个过程形成一棵任务树（DAG，有向无环图），每个节点有三种状态：

Active：准备好了，可以执行
Suspended：前置条件没满足，等着
Silent：做完了，静默

调度算法用 BFS（广度优先搜索）从根节点往下找最近的 Active 任务，执行它或者继续拆解它。直到所有节点都变成 Silent，文章写完。

这个设计的精妙之处在于：它没有固定的工作流。 不是”第一步检索、第二步推理、第三步写作”。而是根据当前状态，动态决定下一步做什么。写到一半发现需要查资料，就去查。查完了发现推理有漏洞，就回来重新推理。

论文里有一张图（Figure 1）把整个过程画成了一个任务 DAG，非常直观。推荐阅读原论文。

实验数据：不是”略好”，是碾压

空谈架构没意义。论文在两个完全不同的写作任务上做了严格测试。

测试一：虚构写作（Tell Me A Story 数据集）

230 个故事生成提示，平均每个提示 113 个 token，目标产出约 1500 token 的完整故事。

对比对象：

E2E（端到端）：直接给 LLM 提示词，不做任何规划
Agent’s Room：多智能体协作框架，4 个规划 Agent + 5 个写作 Agent，先规划再写

评估方式：用 Gemini 2.0-Flash 做 LLM 评估器，14 次双盲对比（正反序各 7 次），多数投票定结果。评估器与人类判断的相关系数 ρ = 0.62（p < 0.01），可信度不错。

结果（Davidson 模型得分，越高越好）：

方法	情节	创意	人物发展	语言	综合
E2E（GPT-4o）	0.34	0.22	0.29	0.20	0.27
Agent’s Room（GPT-4o）	1.04	0.71	0.95	0.68	0.87
WriteHERE（GPT-4o）	1.47	2.01	1.97	2.23	2.14
Agent’s Room（Claude-3.5）	1.03	0.48	0.78	0.48	0.69
WriteHERE（Claude-3.5）	2.02	2.63	2.96	2.26	2.85

没看错。WriteHERE 的综合得分是 Agent’s Room 的 2.5 到 4 倍。不是 5%、10% 的改进，是量级上的碾压。

测试二：技术报告（WildSeek 数据集）

对比对象是更强的选手：STORM（斯坦福的检索增强写作系统）和 Co-STORM（STORM 的用户交互增强版）。

评估方式：用 o1-preview 打分，1-5 分制，维度包括相关性、广度、深度、新颖性。

结果：

方法	相关性	广度	深度	新颖性
STORM（GPT-4o）	4.76	4.58	4.30	4.32
Co-STORM（GPT-4o）	4.36	4.22	4.02	4.17
WriteHERE（GPT-4o）	4.93	4.86	4.79	4.51
WriteHERE（DeepSeek-R1）	4.97	4.94	4.95	4.88

WriteHERE 在所有维度上全面领先。特别值得注意的是深度指标：WriteHERE 4.79 vs STORM 4.30，差距 0.49 分——在 5 分制里，这个差距相当大。

更狠的是：用 DeepSeek-R1 作为 backbone 的 WriteHERE，在 12 个主题的对比中以 7:5 的票数击败了 Gemini Deep Research——Google 自己的深度研究产品。

消融实验：哪部分起了作用？

论文做了两个关键消融实验：

去掉递归规划（w/o Recursive）：变成一次性生成所有子任务的线性工作流。结果——综合得分从 2.14 跌到 1.10（GPT-4o），从 2.85 跌到 0.92（Claude-3.5）。创意和人物发展维度跌得最狠。

去掉任务类型标注（w/o Type）：子任务不再区分检索/推理/写作。结果——综合得分跌到 0.72（GPT-4o）和 0.51（Claude-3.5）。

两个模块都不可或缺。递归规划贡献了”动态调整”的能力，类型标注贡献了”异构执行”的能力。去掉任何一个，WriteHERE 都会退化成普通框架。

横向对比：和其他写作框架到底差在哪

维度	STORM	Co-STORM	Agent’s Room	Plan-Write	WriteHERE
核心思路	先大纲后写作	STORM + 用户交互	多 Agent 协作	长度扩展	异构递归规划
工作流	固定（outline → write）	固定 + 交互优化	固定（plan → write）	固定	动态
中途调整	不支持	有限	不支持	不支持	原生支持
适用场景	百科类文章	百科类文章	虚构故事	长文本扩展	通用
可视化	无	无	无	无	有（Web UI）
开源	是	是	是	否	是（MIT）
论文	ACL 2024	ACL 2024	EMNLP 2024	—	EMNLP 2025 Oral

WriteHERE 的独特之处不是某一个单项指标领先，而是架构层面的不同。其他框架都是”流水线”——阶段之间有明确的边界，信息单向流动。WriteHERE 是”任务树”——任何节点都可以触发任何类型的子任务，信息双向流动。

和 InkOS 怎么选？

这两个经常被放在一起比较，但定位完全不同：

维度	WriteHERE	InkOS
定位	通用长文本写作框架	网文/小说自动写作 CLI
GitHub Stars	860	6,800
学术背景	EMNLP 2025 Oral	无正式论文
核心能力	异构递归规划	10 Agent 流水线 + 33 维度审计
适用内容	技术报告、研究综述、百科文章	网文小说（玄幻、仙侠、都市、科幻）
人类介入	全自动	有人工审核门控
可视化	有 Web UI	Studio 全功能工作台
去 AI 味	无专门机制	内置 AI-tell 检测

写研究报告用 WriteHERE，写小说用 InkOS。 两个没有竞争关系，是互补的。如果你对 InkOS 感兴趣，可以看我们之前的 InkOS 深度测评。

实际使用体验

安装与启动

WriteHERE 提供两种运行方式。

命令行模式，适合批处理和 API 集成：

# 克隆仓库
git clone https://github.com/principia-ai/WriteHERE.git
cd WriteHERE

# 环境配置
python -m venv venv
source venv/bin/activate
pip install -v -e .

# 配置 API Key
cp recursive/api_key.env.example recursive/api_key.env
# 编辑填入 OpenAI / Anthropic / SerpAPI 的 key

# 生成故事
cd recursive
python engine.py \
  --filename ../test_data/meta_fiction.jsonl \
  --output-filename ./project/story/output.jsonl \
  --done-flag-file ./project/story/done.txt \
  --model gpt-4o \
  --mode story

Web 可视化界面，推荐第一次使用的人选这个：

./setup_env.sh  # 一次性环境配置
./start.sh      # 启动服务

自动启动后端（端口 5001）和前端（端口 3000），浏览器打开 http://localhost:3000 就能看到任务树的实时构建过程。

依赖要求

Python 3.6+
Node.js 14+
API Key：OpenAI（GPT-4o）、Anthropic（Claude）、SerpAPI（搜索功能）

可视化界面体验

Web UI 是 WriteHERE 的一大亮点。你能看到任务树从一个根节点开始，逐步分裂、执行、合并的全过程。每个节点标注了任务类型（检索 / 推理 / 写作）和状态（Active / Suspended / Silent）。

看着一棵复杂的写作任务树逐渐收敛为全 Silent 状态，有一种看算法可视化的爽感。对于想理解 HRP 机制的人来说，这个界面本身就是最好的教材。

适合谁？不适合谁？

适合的场景

研究者：需要生成高质量技术报告或文献综述，且希望过程透明可控
内容团队：需要批量产出深度文章，WriteHERE 的批处理模式适合流水线化
AI 工程师：想理解 Agentic Writing 的最新学术前沿，这是一个绝佳的学习项目
技术博主：写深度测评、行业分析类内容，WriteHERE 的检索 + 推理能力能显著提升文章质量

不适合的场景

只需要快速出短文的人：WriteHERE 的优势在长文本。写个朋友圈或者 500 字的笔记，杀鸡用牛刀。
不想配置 API Key 的人：需要 OpenAI + SerpAPI 的 key，有一定门槛。
需要中文原生支持的人：目前提示词和文档以英文为主，中文写作需要自行调优 prompt。

值得留意的局限

API 成本不低。 一次完整的长文本生成涉及多次 LLM 调用（检索 Agent、推理 Agent、写作 Agent 各自独立调用），token 消耗是普通对话的 5-10 倍。用 GPT-4o 跑一篇 3000 字的技术报告，API 费用大约在 $2-5。

SerpAPI 是硬依赖。 报告生成模式需要搜索功能，SerpAPI 免费额度有限（每月 100 次），超出需要付费。完全离线使用写不了报告。

社区活跃度一般。 860 星，4 个贡献者，18 个 open issues。相比 STORM（18K+ 星）和 InkOS（6.7K 星），社区规模小。遇到问题可能需要自己读源码解决。

评估指标以 LLM 评估为主。 虽然用了 o1-preview 和 Gemini 做评估器，与人类判断的相关系数达到了 0.62，但 LLM 评估器本身的偏见（如偏好更长的文本、偏好特定风格）仍然是一个公开问题。

项目信息速查

项目	详情
GitHub	principia-ai/WriteHERE
论文	arXiv:2503.08275
ACL Anthology	2025.emnlp-main.1254
发表	EMNLP 2025 Oral（苏州），pp. 24678-24714
团队	KAUST 卓越生成式 AI 中心
许可证	MIT
主要语言	Python (68%) + JavaScript (30%)
Star 数	860+
官网	writehere.site

5 步快速上手

# 1. 克隆并配置环境
git clone https://github.com/principia-ai/WriteHERE.git && cd WriteHERE
./setup_env.sh

# 2. 填入 API Key
cp recursive/api_key.env.example recursive/api_key.env
nano recursive/api_key.env  # 填入 OpenAI / Anthropic / SerpAPI key

# 3. 启动 Web UI
./start.sh

# 4. 浏览器打开 http://localhost:3000
# 5. 在界面中输入写作需求，观察任务树实时构建

先用自带的 test_data 跑一遍，确认环境没问题，再换自己的 prompt 试试。论文数据显示 Claude-3.5-Sonnet 在虚构写作上比 GPT-4o 更强，可以两个都试试看效果差异。

常见问题

WriteHERE 和 STORM 有什么区别？

STORM 采用”先生成大纲、再逐段写作”的固定工作流，大纲一旦生成就不再修改。WriteHERE 使用异构递归规划（HRP），允许在写作过程中动态调整计划，中途可以插入检索和推理子任务。实验数据显示，WriteHERE 在报告深度上比 STORM 高出 0.49 分（5 分制）。

WriteHERE 需要哪些 API Key？

WriteHERE 需要三个 API Key：OpenAI（用于 GPT-4o）、Anthropic（用于 Claude）和 SerpAPI（用于搜索检索功能）。报告生成模式硬性依赖 SerpAPI，纯故事生成模式可以不用搜索功能。

WriteHERE 适合写小说吗？

WriteHERE 支持虚构写作，实验中在 Tell Me A Story 数据集上的表现远超 Agent’s Room。但如果是长篇网文（10 万字以上），推荐使用专门的 InkOS（10 Agent 流水线 + 33 维度审计）。WriteHERE 更适合短中篇故事和技术报告。

WriteHERE 是免费的吗？

WriteHERE 本身完全免费开源（MIT 许可证），但运行时需要 LLM API Key，会产生 token 费用。用 GPT-4o 生成一篇 3000 字技术报告，API 费用约 $2-5。

WriteHERE 的论文在哪里看？

论文标题为「Beyond Outlining: Heterogeneous Recursive Planning for Adaptive Long-form Writing with Language Models」，发表于 EMNLP 2025（苏州），arXiv 编号 2503.08275，ACL Anthology 链接。