做AI Agent开发的人，基本都逃不开和“长文本生成”死磕。这次把我最近一直在调的一个东西拿出来聊聊——用LangChain的MapReduce模式做一个爆文生成器，核心卖点是能“可续写”：不是一次性吐完一篇就拉倒，而是生成完第一节还能接着写第二节，主题不跑偏、风格不飘移、前后文能接上。这个工具做出来之后，我身边好几个做内容的朋友都在用，用来出初稿、搭提纲、批量生成选题角度，确实省了不少事。如果你正在学LangChain，或者你是自媒体作者想用AI辅助写作，这篇内容应该能帮你把“拆任务-并行处理-汇总拼接”这套思路真正落到代码上。
这期的代码量不大，但架构上很值得玩，因为LangChain在这个场景里有两层作用：一层是它自带的文档处理链（把大文本切碎、分别处理、最后聚合），另一层是我们自己重新编排的MapReduce生成流程。前者是框架给的工具，后者是借鉴思路做的应用，两者我会一起讲透。另外，“可续写”看起来只是加个记忆功能，实际做起来有很多细节，比如上下文窗口怎么控制、章节之间的信息怎么传递、生成到一半怎么从断点继续，这些我都会用实操代码和踩坑记录讲清楚。
1. 先从需求说起：为什么需要“可续写”的爆文生成器
1.1 单次生成的长度瓶颈和内容创作者的续写痛点
先说一个现实问题：现在主流的大模型单次输出长度是有限制的，常见的商用接口在两千到四千个token左右，折算成中文就是两三千字的量。做技术问答或者短文完全够用，但内容创作不一样，一篇像样的公众号长文、知乎回答或者小红书深度笔记，动辄四五千字起。硬让模型一次性输出，很容易出现后半段开始缩写、凑字、甚至直接断掉的情况。我实际测过，让模型硬憋一篇6000字的文章，结尾经常变成“由此可见”“综上所述”这种典型的烂尾话术，根本达不到出版级的内容密度。
所以“可续写”不是锦上添花，而是长文生成的刚需。真正的做法是：先生成一个完整大纲，再一段一段地写。每一段控制在模型擅长的长度范围内，写完之后把这一段的内容作为下一段的参考信息传进去，从头到尾保持同一个主题和风格。这个思路听起来简单，真实现的时候却有很多决策要做，比如大纲拆到多细、段落之间的信息冗余留多少、上下文怎么压缩，这些都会直接影响最终成品质量。
1.2 MapReduce模式：把一篇长文拆成“写得出、拼得齐”的颗粒度
MapReduce这个名词最早来自分布式计算领域，核心思想是“Map（映射）+ Reduce（归约）”：先分头处理一堆子任务，再把结果汇总成最终答案。在文本生成场景下，这个思想天然适合长文生产。我们可以把“写一篇5000字的文章”拆成“写8个600字的段落”，每一段的上下文都只有它自己和大纲，模型的状态压力小，命中的质量自然就高。生成完之后，再有一个Reduce步骤把段落拼起来，加上过渡句、调整语气、统一措辞。
拿我做的一个模拟项目X来举例：主题是“中年人为什么需要重学一门手艺”。大纲拆了六小节，其中第三小节是“手艺学习如何对抗认知衰退”。这一小节单独作为一次生成任务，输入只有三样东西：文章总主题、第三小节标题、以及前两小节的摘要。模型只需要专注写好这一块，不会被其他五小节的细节干扰。处理完之后，六小节的初稿全部汇到一个纯文本文件里，再跑一次润色和串联，生成一篇完整的长文。
这种拆拼模式最大的优势是可控。每个步骤的输入输出都看得见，出问题能定位到具体某个小节；同时也方便并行，六个章节可以同时跑，速度比按顺序生成快得多。代价是如果你拆分逻辑设计得粗糙，拼接痕迹会非常重，读者一眼就能看出来“这两段不是一路人写的”。这个坑我在后面“常见问题”部分会单独讲。
1.3 技术选型：为什么落到LangChain上
其实不用LangChain也能写这个生成器，直接调模型API，自己维护上下文列表，写几十行代码也能跑通。但我最后还是选择了LangChain，原因有三点。第一，它把Prompt模板、模型调用、输出解析这些重复劳动给封装好了，我可以花更多精力在业务流程上，而不是写一堆样板代码。第二，它内置了多种文档处理链，尤其是MapReduce和Refine的抽象，和我想要的分段生成架构几乎一一对应。第三，后续想扩展Agent能力，比如让生成器能去检索资料、调用外部工具，LangChain生态里现成的组件很多，不需要我推翻重来。
当然，选择LangChain不等于必须套用它的高阶抽象。我见过很多人一上来就用load_summarize_chain，然后发现跟自己的业务场景对不上，就以为这个框架不行。实际上，它只是一个工具箱，你可以用里面的Prompt和Parser，也可以只用它的消息接口。我这个项目里其实混合了两套用法：摘要汇总的部分直接用了现成的MapReduce链，章节生成的部分则是自己写逻辑。想用好框架，首先要明确哪些部分是框架帮你省事，哪些部分你必须自己来控制。
2. LangChain里的MapReduce：三种处理链路的差异和取舍
2.1 Stuff、MapReduce、Refine：先搞清楚混用的三个概念
LangChain的文档处理链里，最常用的有三种模式：Stuff、MapReduce、Refine。很多人把MapReduce只是当成“摘要专用选项”，这是理解偏了。它其实是一种通用策略，摘要只是它最典型的应用场景。
Stuff最简单，把所有内容一次性全部塞给模型。它的优点是信息不丢失，模型能看到全貌，缺点也很明显：内容稍微多就超过token上限，代价极高。适合几百字的短文本。Refine则是逐块处理：先处理第一块得到结果，然后带着这个结果去处理第二块，像滚雪球一样一路推进。优点是连贯性好，跨块逻辑不会丢，缺点是生成慢、调用次数多，而且越往后模型越容易被之前的结论带偏。MapReduce是中间态，每个块独立处理得到中间结果，最后统一汇总，最适合“每块信息够用且相互独立”的场景。
举一个直观的例子。你有一堆用户的评论，要提炼出共同槽点。用Stuff就是把所有评论扔给模型，常见的结果是读不完；用Refine就是一条一条读评论，每读完一条更新一次“槽点汇总”，适合评论数少且前后关联强的情况；用MapReduce则是把评论按天切块，每块先独立提炼，最后把所有提炼结果合并成一份总报告。我的爆文生成器采用的是MapReduce思想，但在“可续写”的上下文传递上又参考了Refine的思路。后面会细讲。
2.2 爆文生成器的整体架构：大纲先行、章节并行、末尾拼接
整个生成器分四层，我把每一层逐步拆开说。
第一层是主题扩展。输入一个主题词，比如“城市青年的睡眠焦虑”，先生成文章的目标人群、核心观点、大致结构。这一层属于Reduce阶段，因为需要模型从全局视角规划架构，不允许只见树木不见森林。
第二层是大纲生成。把主题扩展过后的描述转换成结构化的章节列表，每章包含编号、小标题、核心论点和参考素材方向。这一步很关键，因为大纲的质量直接决定了后续Map阶段能跑多顺。我一般要求模型输出JSON数组，然后用LangChain的输出解析器把它转成Python对象，规范又省心。
第三层是章节生成，也就是Map阶段。对大纲里的每一个章节，独立生成600到900字的正文。这一层的输入需要精心设计：总主题、章节标题、该章节在整篇文章中的位置、前面章节的一句话摘要。某些信息依赖前序结果的情况，我会把上一章的完整末尾段落也带进去，确保叙事连贯。
第四层是全文组装，也就是Reduce阶段。把生成的章节拼成一篇完整文章，加开头导语、章节间的过渡句、结尾总结。这一层可以跑两次，第一次是机械拼接，第二次是让模型通读全文做统一润色，包括语气调整和术语一致性。
2.3 可续写机制：上下文窗口与记忆管理的设计
“可续写”听起来只是把生成结果存下来，实际上真正的难题是上下文管理。如果每写一章都把前面所有章节全文塞进去，那写第十章的时候，几千字的旧文就占掉了大量token，模型反而记不住这一章的重点。我试过几种方案，最终采取的是“全局摘要+最近段落”的双层记忆。
具体来说，每次续写之前，先用一个MapReduce摘要任务把已生成的章节压缩成一份两三百字的全局摘要，这份摘要强调主线逻辑和已覆盖的观点；然后再拼上最近一个章节的完整文本，保留文风和细节。模型拿到这两块信息之后，既知道整篇文章已经写到哪里，又能在文字风格上有迹可循，续写出来的部分不会显得像另一个人写的。
另外我还会保存一份结构化的metadata，记录每个章节的“信息增量”。续写时，模型可以根据这个metadata判断哪些观点已经提过，避免重复。这个设计越到长尾文章越重要，比如写到8000字的时候，如果不用metadata做去重，模型很可能会把前面已经写过的例子再讲一遍，读起来会有强烈的注水感。
3. 实操记录：从零搭建可续写的爆文生成器
3.1 环境准备：依赖安装与模型配置
先说环境。这个项目对Python版本要求不高，3.10以上就行。核心依赖是LangChain全家桶，我用的是langchain、langchain-core、langchain-community这三个包，先装好它们再装一个tiktoken用来估算token数量，方便做输入裁剪。
pip install langchain langchain-core langchain-community tiktoken模型方面，我建议选“长上下文、中速、性价比高”的商用接口，不一定必须是最强模型。因为我们的架构已经把单次任务拆得很小了，每次生成一章也就一千多个token，很多轻量级模型也能跑得很好。真正重要的是模型的“指令跟随能力”，尤其是输出JSON大纲、遵守“不得少于600字”这类细节约束，能力不足的模型很容易糊弄。
下面是模型的初始化占位函数，不同模型服务商的封装类不一样，你只需要保证返回一个“能接收消息列表、返回文本”的LLM对象就行。
def get_llm(): # 这里替换成你实际使用的模型封装类 # 例如 langchain_community.chat_models 下某个 ChatXxx # 要求支持 temperature、max_tokens、top_p 参数即可 raise NotImplementedError("请替换为你自己的LLM实例") # 使用示例 llm = get_llm()如果你用的是兼容消息接口的服务，常见做法是在封装类里填model、api_key、base_url三个字段。换一家服务商，通常只需要替换get_llm内部实现，其他业务代码完全不用动。
3.2 核心代码：大纲生成与章节MapReduce
大纲生成这一步，我用了LangChain的ChatPromptTemplate配合输出解析器。Prompt里明确告诉模型：输出一个JSON数组，每个元素包含title、point、keywords三个字段。解析器帮忙把模型返回的字符串变成真正的Python对象，省去了手动json.loads的容错麻烦。
import json from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import JsonOutputParser outline_prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个资深内容策划。请根据用户给出的主题，规划一篇爆款长文的章节大纲。"), ("user", "主题：{topic}\n要求：输出JSON数组，每个元素包含 title, point, keywords。章节数量6到8个。") ]) def generate_outline(topic: str): parser = JsonOutputParser() messages = outline_prompt.format_messages(topic=topic) resp = llm.invoke(messages) return parser.parse(resp.content)到章节生成这里，才是真正的Map阶段。我的做法是写一个generate_section函数，它接收章节信息和前情摘要，返回单章正文。这里有两个细节要留意：第一，章节长度约束要放到System层，而不是User层，模型对系统指令的遵循度更高；第二，一定要把“不要重复之前章节已经讲过的观点”写进提示词，否则Map阶段各写各的，最后拼出来的文章会有大量重叠内容。
section_prompt = ChatPromptTemplate.from_messages([ ("system", "你是一位文风利落的长文作者。每次只写一个章节。要求：\n" "1. 章节正文不少于600字，不多于900字。\n" "2. 不要重复前情摘要中已经写过的观点。\n" "3. 结尾留一个自然的过渡，方便下一章续写。"), ("user", "总主题：{topic}\n当前章节标题：{title}\n核心论点：{point}\n前情摘要：{summary}\n" "请只输出本章正文，不要输出标题。") ]) def generate_section(topic: str, section: dict, summary: str): messages = section_prompt.format_messages( topic=topic, title=section["title"], point=section.get("point", ""), summary=summary ) resp = llm.invoke(messages) return resp.content.strip()到这里还没有真正体现“MapReduce”，因为我们是按顺序调用的。想要并行，最简单的方式是线程池。每个独立章节扔到线程池里跑，跑完再汇总。注意：如果章节之间有强依赖，比如第二章必须引用第一章的例子，那就不要强行并行，改成按序生成，否则花了资源还容易逻辑断裂。
from concurrent.futures import ThreadPoolExecutor def map_generate_all(topic: str, outline: list[dict], summaries: dict): results = {} with ThreadPoolExecutor(max_workers=3) as pool: future_map = {} for sec in outline: sec_id = sec["title"] summary = summaries.get(sec_id, "") fut = pool.submit(generate_section, topic, sec, summary) future_map[fut] = sec_id for fut in future_map: sec_id = future_map[fut] results[sec_id] = fut.result() return results最后是Reduce阶段。把各章节按顺序拼接后，再做一次全文润色，重点处理三个地方：章节接缝处的过渡、重复的观点删除、结尾的收束。这一步我是让模型读完整篇做改写，但只准改衔接和冗余，不允许动核心观点，否则容易把原本犀利的表达改得平庸。
polish_prompt = ChatPromptTemplate.from_messages([ ("system", "你是终审编辑。请将下面的文章初稿改写成一篇连贯的长文。\n" "规则：只调整过渡句、删掉重复表述、统一语气，不得修改事实和核心观点。"), ("user", "文章初稿：\n{draft}") ]) def reduce_and_polish(draft: str): messages = polish_prompt.format_messages(draft=draft) resp = llm.invoke(messages) return resp.content.strip()这套流程跑下来，输出的一篇文章基本达到了“结构清晰、衔接自然、单段质量稳定”的水平。实际使用中，大纲生成和段落生成的token消耗比大约是1比8，大头还是在章节生成上。这也是为什么MapReduce划算：如果不拆，直接让模型一次写全文，经常返工；拆了之后每段都能打中，一次过的概率高很多。
3.3 续写实现：三种断点续写的具体方案
“续写”这个功能，我前后做过三版方案，最终都保留了下来，因为适用场景不同。
第一版叫“全文重绘+局部重写”。如果用户对已生成的前三章不满意，想换风格续写后面四章，就先把前三章压缩成摘要，然后带着新风格说明，重新生成后续章节。这个方案能解决“写到一半想换文风”的痛点，代价是要重跑后续所有章节，成本稍高。
第二版叫“滚雪球续写”。系统维护一个已生成的章节列表，每次续写新章节时，把“全局摘要+上一章全文+本章大纲”拼在一起作为输入。这个方案生成质量最稳，因为它同时给了模型大局观和最近细节。缺点是每次都要先算全局摘要，多一次调用。
第三版是“短记忆续写”。只把最近一章的全文塞进上下文，不再计算全局摘要。优点是非常快、省token，适合文字密度低、章节相对独立的博客文章；缺点很明显，写到后面可能忘记前面的伏笔，或者推翻前面已经立下的结论。
我个人推荐的组合是：开篇几章用短记忆续写，从第三章开始切到滚雪球续写。原因是前几章通常都在做铺垫，信息量小，不需要全局摘要；中后期开始出现案例、数据、观点分层，这时候必须让模型知道全文已经写到了什么程度，否则很容易重复或者跑偏。
def continue_writing(topic: str, next_title: str, full_summary: str, last_section: str): messages = section_prompt.format_messages( topic=topic, title=next_title, point="继续展开，承接上文", summary=f"全局摘要：{full_summary}\n上一章结尾：{last_section[-500:]}" ) resp = llm.invoke(messages) return resp.content.strip()注意最后一行的last_section[-500:]，我截取了上一章末尾五百字而不是全文。这是实操中测试出来的平衡点：对续写来说，最近章节的核心信息通常集中在结尾部分，截取末尾反而能减少无效token，让模型更聚焦“接下来要说的事”。
3.4 参数调优：温度、token上限和并发节奏
参数这东西，不能一套配置走天下。我分别针对不同环节做了调优，实际效果差异很明显。
大纲生成环节，温度设为0.3左右。大纲是结构性输出，创造性太强会导致章节之间逻辑跳跃，所以让它保守一点。章节生成环节，温度放到0.7到0.8，这一步需要语言表达有活力，太保守写出来的东西干巴巴的。全文润色环节，温度又降到0.3到0.4，润色是精修，不是创意写作，稳定优先。
token上限方面，我把每次输出的max_tokens设为3000，但要求模型每章只写600到900字。多出来的空间是给模型“思考”和可能的续写缓冲。如果你把上限卡得过死，比如刚好900字，模型经常会写了700多字就草草收尾，因为它要把结尾预算预留出来。
并发节奏上，线程池的并发数我控制在3到5。很多人一开始就上10个并发，结果遇到限流、超时、重试风暴。商用模型接口的并发能力有限，尤其是单账号调用频控很严格。做生成器不是做压测，不需要疯狂抢资源，稳定输出比瞬时速度更重要。多跑几轮之后你会形成体感：并发数*单次调用时长，只要小于接口的每分钟限制，基本不会出事。
4. 我踩过的坑：常见问题与排查实录
4.1 长内容被截断：让“后半段”消失的元凶
有一次生成一篇七章的长文，前三章都正常，第四章开始每段结尾越来越突兀，到第六章直接只有三句话。一开始我以为模型能力不行，后来一查日志，发现是章节长度提示词里写的“不少于600字”和max_tokens设置的互补关系出了问题。模型每章实际产出token大概2000到2500，而我当时把max_tokens设成了1500，结果第四章开始频繁触顶，模型只能草草收尾。
排查方法很简单：在调用返回的response.usage里看每个请求的finish_reason，如果大量是length而不是stop，那说明token预算不够。解决办法有两个方向：要么把max_tokens提到3000以上，要么把每章的字数要求从600到900改成500到700。我后来把这两个都做了，截断问题基本绝迹。还有一个保险措施：在系统提示词里加一句“如果内容超过长度限制，请先给出本章核心结论，再在结尾标记[待续]”，这样即使触顶也不会留下半句废话。
4.2 章节间风格漂移：拼出来的文章像两个人的手笔
这是我第一次跑通整个流程后最崩溃的问题。第一章犀利冷峻，第二章突然变成鸡汤调，第三章又开始堆数据，读起来完全不像同一个作者。原因很简单：每章生成都是独立的调用，模型在前一章积累的语言习惯在下一章开始时已经丢了。解决这个问题花了很长时间，最后确认了三个有效手段。
第一个手段是在系统提示词里固定“风格说明书”，例如“句式短促有力、少用形容词、每段不超过三行”。第二个手段是在前情摘要里追加一段“前文风格示例”，取自上一章的中间段落，让模型有明确的模仿对象。第三个手段是终审润色环节多跑一次，专门处理语气一致性。这三个手段叠加之后，风格漂移的情况减少了八成以上。还有一个小技巧：把风格说明放在System层，把风格示例放在User层的末尾，模型对不同位置的注意力权重不同，实测这个摆放方式是效果最好的。
4.3 并发调用被限流：Map模式的费用与速度平衡
Map阶段的并行确实快，但超融合的很惨。有一次我把一个十章的提纲直接丢到线程池里跑，并发数开到8，结果跑了不到一分钟就收到接口的限流报错，重试机制触发后又把请求风暴放大了一轮，最后整个任务用了比顺序执行还长的时间才跑完。这次教训让我明白：并行度不是越高越好，要配合接口的频控和重试策略一起设计。
我现在的策略是：并发数固定为3，用信号量控制；重试用指数退避，初始等待1秒，最多等10秒；任务整体设一个超时时间，超时的章节单独重跑而不是整个任务重跑。这样虽然速度不是最快，但稳定性和费用都可控。如果你用的是按token计费的接口，并行虽然省时间，但并发请求突增会瞬间拉高账户用量，还是建议加一个每日预算限制，防止调试时一个死循环烧掉整月额度。
4.4 内容质量控制：爆文的“爆”不能靠编造
说到爆文，很多人第一反应是标题党、夸张、编故事。我在做这个工具时反复定下一条规矩：爆文生成器的目标是帮作者快速出高质量初稿，而不是批量制造虚假低俗内容。实际使用中，我会在生成器里加一个可选的“事实核查占位步骤”，主题涉及数据、案例、政策时，生成的大纲里会明确标注“待人工验证”，然后我把这些标注过的内容单独提取出来，交给检索工具查证。这不是一个很复杂的功能，但在内容合规和可信度上非常关键。
另外，我在提示词里会尽量避开“引导对立”“贩卖焦虑”这类表达。做内容创作的都清楚，短期焦虑流量来得快，但账号信任消耗得更快。我们做AI工具的人，更不该把“毒流量”变成一键生成的产品。这个主张算是我个人的一点坚持，也是我会继续加强的一个环节。
5. 让Demo变成能用的产品：进阶玩法与后续扩展
5.1 命令行交互与Web界面的轻量接入
生成器跑通之后，我先做了一个命令行版，接受一个关键词，输出完整文章。命令行的好处是调试便利，但给非技术朋友用就不太友好。后来我用gradio包了一层界面，代码量不到三十行，就能实现一个“输入主题→点击生成→流式展示各章节”的单页应用。如果你也更熟悉streamlit，用那个也完全可以，关键是把上面说的generate_outline、map_generate_all、reduce_and_polish三个函数暴露成界面按钮，逻辑完全复用。
界面版对我来说还有一个额外价值：可以实时看到每个章节的生成耗时和token消耗，方便做成本估算。给朋友试用时，他们往往对“生成快”没概念，但对“每篇大概烧多少额度”非常敏感。所以我做了一个简单的统计条，展示“本文累计调用12次，消耗约15000 token”，效果比我费口舌解释好很多。
5.2 从“单次生成”到“带知识库的持续创作”
现在的版本已经能处理单篇长文，但如果你有专栏或系列文章的需求，更进阶的方向是接入知识库。比如一个人做情感成长类账号，积累了上百篇历史文章，与其让模型每次都凭空生成，不如先把历史文章做成向量索引，生成每一章之前先检索相关段落，把检索结果作为参考资料拼到Prompt里。这样生成的章节不仅风格统一，内容上还能覆盖之前已经写过的观点、案例，形成真正有累积感的系列创作。
我在模拟项目X里试过这条路：导入半年左右的文章集合，标题和正文都切成几百字的块，用embedding模型向量化，存到本地向量库。生成新文章时，每章先用“章节标题+核心论点”去检索最相近的一到两篇旧文，把检索到的结论摘要塞进上下文。效果非常明显，系列文章的连贯性和知识密度都比纯Prompt生成高出一个档次。如果你做的是资讯评论类账号，还可以进一步接入实时搜索接口，让生成器在生成前抓取当天的相关热点作为素材来源。
5.3 个人心得：这个项目最值得玩透的三个细节
做这个项目大半个月，最值得反复琢磨的不是MapReduce的模式本身，而是三个细节。第一个细节是“信息增量”的显式跟踪。我后来给每个章节加了一个info_gain字段，记录这一章新增了什么观点、案例、数据。生成新章节时把它显式传给模型，能大幅减少前后文重复。这个设计是我从新闻写作的“倒金字塔”结构里借鉴来的，实际效果比单纯的“不要重复前文”强得多。
第二个细节是“双遍汇总”的收益。我的Reduce阶段不是一遍完成，而是先机械拼接，再让模型通读全文做改写。原因很简单：机械拼接阶段模型没有改写压力，能独立判断哪些地方重复了；如果直接让它边拼边改，它往往选择保守策略，保留更多冗余，导致文章又长又松。先拼后改，每一遍任务单一，输出质量反而更稳。
第三个细节是成本可视化。每次调用打印出token消耗和费用估算，这个习惯帮我避过好几次失控烧钱的坑。我记得有一版提示词写得非常冗长，每次调用都带几千token的固定前缀，整体成本比正常的版本高了近一倍。没有成本可视化，这种问题根本不会被注意到。
现在这个生成器已经在我本地跑成了一个小工具库，输入一个主题就能出完整长文，也能在任意章节处续写、重写、换风格。核心始终是MapReduce那套拆解-并行-汇总的思路：先把任务拆到模型擅长处理的程度，再用清晰的上下文管理保证拼起来不断裂。如果你也在做长文生成、Agent写作或内容自动化类项目，这套骨架可以直接拿过去改，我在“常见问题”里记录的那些坑，你可能也会遇到，希望这些经验能帮你少走一段弯路。
