LangGraph多智能体实战：构建内容生产协作流水线

最近我把一个原本靠人工流转三四轮的内容生产流程，迁移到了LangGraph上：四个智能体角色——研究员、分析师、写作者、审核者，共同组成一条“研究-分析-写作-审核”的多智能体协作流水线。过去一篇深度长文从选题到成稿，前后需要讨论、查资料、改稿、返工，现在整套流程在LangGraph的状态图里自动流转，审核不通过还会自动回到写作节点返工，最多循环若干次才会放行。这篇文章把整个项目的设计思路、核心节点实现、路由策略和实际踩坑记录都拆开讲一遍。

如果你正在考虑“不做单个Agent，而是组一个多智能体团队”，或者已经在用LangChain但想进一步用LangGraph做有状态的复杂工作流，这篇文章能帮你省一大圈弯路。我会先解释为什么用LangGraph而不是普通Prompt链，再逐个拆解四个节点的实现细节，接着给出一份可直接复现的核心代码，最后把调试过程中遇到的典型问题整理成排查手册。

1. 为什么用LangGraph组“研究-分析-写作-审核”团队

1.1 多智能体协作的真正痛点

单个大模型Agent能做的事情很多，但内容生产这种任务，把它拆成“研究、分析、写作、审核”四个角色来协作，效果会比“一个Agent从头干到尾”稳定得多。原因很实际：不同阶段对模型能力的要求完全不同，研究阶段要会调用工具、容忍噪声，分析阶段要有结构化思维，写作阶段要讲连贯性和层次，审核阶段要用挑剔的眼光挑毛病。把四种风格塞进同一个Prompt里，模型很容易顾此失彼。

另一个痛点是“状态管理”。多智能体协作本质上不是四个独立的Agent各做各的，而是它们共享一份不断更新的工作底稿。研究员查到的资料要留给分析师用，分析师的结论要约束写作方向，审核员指出的问题则要回到写作环节去修正。如果不用专门的状态图工具，就得自己定义一堆中间变量和流程控制逻辑，代码很快会乱成一团。

LangGraph正好解决这两个问题。它把每个智能体定义成图中的一个节点，节点之间通过共享状态交互，同时支持条件路由。这意味着你可以很自然地把“审核-返工-再审”这种循环用一条条件边表达出来，而不是在代码里手写一堆if-else控制流。

1.2 四个角色的职责边界与整体工作流

这套系统里，四个节点是这样分工的：研究员节点负责信息检索，它会接收一个主题，调用搜索工具获取素材，并把有价值的片段整理成结构化的研究笔记；分析师节点读取研究笔记，提炼核心论点、找出信息缺口，输出一个写作大纲和关键素材索引；写作节点根据分析结果生成完整文章初稿；审核节点则从事实准确性、逻辑一致性、表达质量三个维度打分，给出通过或不通过的结论。

整体工作流是一个带反馈回路的流水线：研究员 -> 分析师 -> 写作者 -> 审核者，审核如果不通过，就把修改意见传回写作者，让写作者带着意见再写一版。这个循环由条件路由控制，会有最大重试次数上限，避免无休止地返工。

这样的架构还有一个额外的好处：每一步的结果都被持久化在状态里。写作者产出初稿后、审核者判定不通过的那一刻，并不是把前一步的研究和分析推倒重来，而是只重新进入写作节点，拿着上一版的草稿、审核意见和最初的研究笔记做“有依据的修改”。这种“局部重试”机制，比整个流程从头再跑一遍节省大量token和时间。

1.3 为什么不直接用普通Prompt链或单Agent

有人会问：既然四个角色有先后顺序和反馈循环，为什么不用普通Prompt链，在每步之间手动调用大模型接口并传参？答案是：普通Prompt链在“直线流程”下够用，但一旦出现条件分支和循环，代码维护成本就会爆炸。单Agent虽然天然具备循环能力，但所有工具调用、推理、生成都挤在同一个上下文中，上下文会越来越长、越来越杂，模型容易遗忘早期的结论，而且并行扩展能力很差。

LangGraph给了我们一个折中：把智能体当作图的节点来看待，节点之间通过边连接，边可以是普通边，也可以是有条件的边。审核节点完成后，走“通过”边就进入最终输出，走“不通过”边就返回写作节点。这套心智模型特别适合多智能体协作场景，因为团队协作本来就是一个工作流问题，而不是一个单纯Prompt工程问题。

2. 状态图设计与核心节点拆解

2.1 共享状态：让四个智能体“用同一本笔记本”

LangGraph的核心抽象是状态图。状态就是一个可被所有节点读写的数据结构，典型情况下是一个TypedDict或Pydantic模型。整个多智能体系统能高效运转，关键在于把这个状态设计得既清晰又灵活。我的做法是定义一个AgentState，里面包含主题、研究笔记、分析报告、当前草稿、审核反馈、是否通过、返工次数等字段。

这里有个很重要的经验：不要只想着“下游要什么，我只传什么”。因为审核不通过时会返工，返工的写作节点需要同时看到旧草稿、审核意见和研究笔记，所以状态里必须把这些历史信息都保留下来。同理，分析节点生成的观点性结论可能在多轮返工中保持不变，就没必要每次重新生成，直接从状态里读取就行。

这种设计的另一个好处是便于观测和调试。每个节点的输入输出都对应状态的增删改，一旦发现结果质量不如预期，可以直接查看某个节点修改了哪个字段，定位问题非常方便。

2.2 研究节点：检索外部知识并过滤噪声

研究节点的核心任务是把“一个主题”变成“一组来源可靠、内容相关的素材”。我给它挂了一个搜索引擎工具，让它根据主题做多次检索，然后对结果做摘要和去重。这个节点看起来简单，但实践中有三个关键点需要处理周全。

第一个关键是“检索策略”。一轮搜索往往不够，需要让模型先理解主题，然后拆成3到5个子角度分别检索。比如主题是“城市噪音治理”，可以先搜“噪音标准法规”“居民投诉数据”“降噪技术方案”“国内外城市案例”，再把结果合并。如果不拆角度，最后得到的素材会高度同质化，分析阶段很难形成多元视角。

第二个关键是“去重和筛选”。搜索接口返回的原始内容夹杂大量广告、相关性低的链接和重复信息，必须让模型做一轮过滤。我会在Prompt中要求它输出一个数据结构化的研究笔记，每条笔记包含原文链接、来源、核心观点、与主题的相关性评分。这个结构化输出不仅方便后续分析师读取，还能在返工流程里帮写作节点快速定位引用来源。

第三个关键是“容错”。搜索工具偶尔会超时，或返回空结果，所以研究节点内要处理异常。我会设置单次检索超时时间，并在失败时做两次重试，重试仍失败则跳过该角度继续流程，不让单个工具故障导致整个团队停摆。

2.3 分析节点：把素材变成结构化洞察

分析节点是整个团队中最容易被低估的一环。很多项目直接把研究笔记丢给写作模型去写文章，结果写出来的东西像素材的堆砌，缺乏主线。分析节点的价值在于是从松散素材里提炼出一个“可写的大纲”。

我的实现是把分析任务拆成两步：第一步，让模型从研究笔记中归纳主要矛盾、核心受众关注点、已有素材的覆盖情况和信息缺口；第二步，基于归纳结果生成文章大纲，大纲层级包含标题、分论点、每个分论点建议使用的素材编号和论据要点。

分析节点还要做一件重要的事：给写作节点提供“关键约束”。这里的约束可以是要突出某个角度、要回避某个有争议的说法，也可以是必须保持某种口语化的表达基调。这些约束如果靠自然语言写在研究笔记里，写作模型很容易忽略，但放进结构化的analysis字段后，下游节点可以像查配置一样准确读取。

从工程实现的角度，分析阶段不需要把大模型上下文开得特别大，重点是多输出几个结构化的中间字段。我自己习惯让模型输出JSON格式的分析结果，然后用Pydantic做校验，字段不对就回退重试一次，保证进入写作节点的数据一定是能直接用的。

2.4 写作节点：长文生成与返工处理

写作节点接收分析师产出的结构化大纲和素材索引，按要求生成长文。这个节点最考验工程细节的地方是“如何让长文不生硬”。一次性让模型生成上万字会面临严重的逻辑断裂和重复表述，所以我通常采用分段生成的方法：先根据大纲的第一个大节生成开头和该节内容，然后让模型基于“已生成的前文摘要”继续生成下一节，直到完成全文。

这种分段生成策略我已经在多个内容项目中验证过，效果比一次性生成整篇长文稳定很多，尤其适合教程、行业分析这类结构性较强的文章。代价是调用次数变多，所以必须设计一个“前文摘要”字段，每次传给模型的不再是全部历史文本，而是经过压缩的关键信息，既省token又能保持逻辑连贯。

返工处理是写作节点区别于普通文本生成的地方。当审核节点返回不通过时，写作节点会带着审核意见重新生成。这时候如果只是简单地把“请修改”拼接在原始Prompt后面，模型往往会大改结构、改动语气，甚至把本来写得不错的地方也推翻。我踩过这个坑后，会在返工Prompt里加一条硬性约束：除非审核意见明确要求调整某一部分，否则保留原文结构和内容，只针对问题点做局部修改。这样返工的效率高得多，也不会出现“越改越糟”的局面。

2.5 审核节点：质量闸门与条件路由

审核节点是这套多智能体团队中的人工质检员角色。它读取当前草稿、原始大纲、审核意见，输出一个结构化结论。我在实际项目中用三个维度评估：事实准确性、逻辑一致性、表达质量。每个维度打分并附带具体修改建议，最终用一个布尔字段判断是否通过。

关键点在于：审核意见必须足够具体，才能让返工有效率。如果审核节点只说“语言不够好”或“内容需要充实”，写作节点拿到这种反馈根本不知道怎么改。我的解决方法是要求审核节点输出“问题定位 + 修改建议 + 参考原文片段”三元组。例如给出“第3段关于政策背景的表述与研究笔记中的法规条目不符，建议核对第2条资料后再改写”，而不是含糊的“第3段有问题”。

条件路由在LangGraph里是通过定义conditional edge实现的。图中有一个路由函数，读取state中的review_result，如果passed字段为真，就沿着“end”边走出图；否则，走“revise”边回到写作节点，同时把revision_count加1。在路由函数里还要叠加一个最大返工次数判断：如果次数达到上限，即使审核结果为不通过，也要强制走出图，把生成的草稿和审核意见一并返回给人工，避免死循环拖垮整个流程。

3. 实操过程：从零搭建这套多智能体流水线

3.1 环境准备与依赖安装

开始之前，先把基础依赖配好。Python环境建议用3.10以上版本，核心依赖是LangGraph库，以及对应的LangChain生态。如果你用的是Anthropic或OpenAI等主流模型接口，需要安装相应的LangChain集成包。我的基础环境大致是这样：

pip install langgraph langchain langchain-openai langchain-anthropic pip install tavily-python # 如果你用的搜索引擎工具支持该SDK pip install python-dotenv

这里有一个版本工作流层面的建议：LangGraph的接口更新比较快，一定要锁版本。我一度遇到问题，后来发现是最新版偷偷改了API签名，导致线上流程意外中断。建议在requirements.txt里固定大版本号，例如langgraph>=0.2,<1.0，升级前先跑回归测试。

配置好环境变量，在代码里初始化模型客户端。实践中我会为四个节点分别创建模型实例，而不是共用一个。原因是四个节点的Prompt方式不同，所需温度和输出格式也不同。研究节点和分析节点需要较低温度来保证可靠输出，写作节点我会设到0.6左右，让表达更自由；审核节点则要严格要求高确定性，温度设到0.1附近。

3.2 定义状态与图结构

这段是最核心的骨架。先看状态定义和数据类的写法：

from typing import TypedDict, Annotated, List, Optional from langgraph.graph import StateGraph, END class ResearchNote(TypedDict): url: str source: str insight: str relevance: float class AnalysisResult(TypedDict): outline: str key_points: List[str] constraints: List[str] material_references: List[int] class ReviewResult(TypedDict): passed: bool scores: dict issues: List[str] suggestions: List[str] class AgentState(TypedDict): topic: str research_notes: Annotated[List[ResearchNote], "accumulate"] analysis: Optional[AnalysisResult] draft: Optional[str] review_result: Optional[ReviewResult] revision_count: int

请注意research_notes字段的注释里有“accumulate”——这是LangGraph的状态归约器写法。归约器的意思是，当研究节点每一轮检索补充新的笔记时，不是覆盖原来的列表，而是把新笔记追加到已有列表后面。这个设计对多轮检索合并相当实用，我第一次做的时候没有加这个标注，用了一个认为会追加的普通列表，结果每次写入最新结果覆盖了旧结果，研究笔记只剩下最后一轮检索的素材。

接下来是图结构：

graph = StateGraph(AgentState) graph.add_node("research", research_node) graph.add_node("analyze", analyze_node) graph.add_node("write", write_node) graph.add_node("review", review_node) graph.set_entry_point("research") graph.add_edge("research", "analyze") graph.add_edge("analyze", "write") graph.add_edge("write", "review") graph.add_conditional_edge( "review", route_after_review, {"accepted": END, "revise": "write"} ) app = graph.compile()

这个图结构极其直观。四段式直线流程，加上审核节点的一个条件出口，需要返工就回“write”，通过就进入END。整个图只有5个节点、5条边，但已经能表达复杂的多智能体协作逻辑。这就是LangGraph的优势：图结构本身就在表达业务流程。

3.3 实现四个节点的核心逻辑

研究节点的实现要点是：根据主题拆检索子问题，循环执行工具调用，把结果整理成结构化ResearchNote列表。为了简洁，下面给出核心思路：

from langchain_core.messages import HumanMessage, SystemMessage def research_node(state: AgentState) -> dict: topic = state["topic"] sub_angles = topic_splitting_llm.invoke( f"请把主题「{topic}」拆成3-5个检索子问题，直接返回JSON列表" ) notes = [] for angle in sub_angles: raw_articles = search_tool.invoke(f"{topic} {angle}", max_results=4) for item in raw_articles: # 简单去重：只保留不同URL if any(n["url"] == item["url"] for n in notes): continue note_content = filtering_llm.invoke([ SystemMessage(content="请从以下网页内容中提炼与主题相关的核心观点，并评估相关性评分0到1。输出JSON。"), HumanMessage(content=item["snippet"]) ]) parsed_note = json.loads(note_content) parsed_note["url"] = item["url"] parsed_note["source"] = item.get("title", "") notes.append(parsed_note) return {"research_notes": notes}

这里有一个很容易被忽视但实际很关键的细节：搜索工具返回的snippet通常只有一两句话，信息量有限，如果跟模型说“提炼观点”会得到很泛的笼统结论。我的做法是让研究节点在检索到候选URL后，再用一个抓取正文的能力把完整页面内容取下来给模型读。这个“先检索、后精读”的两段式设计，比单纯基于snippet做笔记要有效得多，代价是耗时变长，需要在高密度素材场景下权衡。

分析节点和写作节点的代码模式类似，重点在于Prompt结构化。分析节点直接把研究笔记和写作模型链起来太粗暴，中间的中间结构不能少。我在实际项目里让分析节点产出一个JSON，包含outline字符串、key_points列表、constraints列表、material_references列表，把研究笔记的编号和文章的大纲对应起来。这样写作节点在扩展段落时，可以直接根据material_references找到对应素材，既有依据又避免跑题。

写作节点的分段策略，我用一个内部循环实现。先把分析大纲的第一个大节作为初始目标，生成第一段；之后每次迭代，把已生成的前文做一次压缩摘要，连同下一节大纲一起给写作模型，让它续写。因为LangGraph图节点本身是一个整体函数，内部循环并不会有额外的图跳转，代码上很直接。要注意的是，内部循环也消耗模型调用次数，所以对生成超长文章的场景，一定要在节点内处理好前文压缩的粒度，否则上下文越滚越大，后面每轮续写的延迟会明显增加。

3.4 条件路由与最大重试循环

路由函数是整个团队流程的“指挥”。它判断审核结果，同时控制返工次数上线。核心逻辑如下：

def route_after_review(state: AgentState) -> str: passed = state.get("review_result", {}).get("passed", False) current_round = state.get("revision_count", 0) if passed: return "accepted" if current_round >= MAX_REVISION: # 超出最大次数，强制结束，但把审核意见留给人工 return "accepted" return "revise"

这个函数的逻辑看起来简单，但有几个深层考量。首先是“返回列表还是返回单一值”：LangGraph的conditional edge路由函数返回一个字符串，这个字符串对应你在add_conditional_edge里配置的映射键。我上面的写法里，超过最大次数后返回“accepted”其实表示的是一种“有条件的放行”：模型生成的终稿并没有完全通过审核，但流程不能无限卡住，于是把这份“未通过但已达上限”的结果交给状态里的review_result字段，由人工在最终检查环节来做决定。

这个设计给我带来了很大启发：不要觉得“审核多次不合格”就一定要返工，在实际业务中，返工不是免费的，它消耗token和时间，还可能越改越差。设定上限不是偷懒，而是一种对资源有效性的理性管理。项目中我常常把MAX_REVISION设为2，最多返工两轮，如果三轮之后模型仍然无法修正，说明问题的根源要么在分析阶段或研究阶段，要么是主题本身超出了模型的能力范围，继续在这个节点上浪费资源没有意义。

还可以做一个增强：在超过最大次数时，将路由指向一个“人工接管”节点，而不是直接结束。这个节点可以把状态里的草稿、审核意见、所有中间产物打包成一条消息发到某个任务队列接口，让真人对工作流进行“救援”。我虽然没有在第一个版本里实现这个功能，但如果你的业务对质量要求很高、对错误零容忍，这个“失败逃生舱”节点值得认真考虑。

3.5 编译、测试与流式输出

写完了节点，compile就得到可运行的图应用。编译时我通常会加一个检查点器，让每一步状态都能持久化。LangGraph自带的SqliteSaver和RedisSaver都是不错的选择，本地测试用sqlite最方便：

from langgraph.checkpoint.sqlite import SqliteSaver with SqliteSaver.from_conn_string(":memory:") as saver: app = graph.compile(checkpointer=saver) config = {"configurable": {"thread_id": "article-task-001"}}

checkpointer的价值在于，当流程在某一步失败，或者你想人工暂停调整状态，都可以基于这条线程的历史记录恢复执行，不用从头跑。这在多智能体场景里尤其重要：假如写作节点第三轮返工时模型接口临时超时，checkpointer能让你修复配置后从“review”节点继续，而不是重新执行已经完成的两轮返工。

测试时，我习惯写一个小小的驱动函数，把topic传进去，然后用stream模式观察每一步进展。LangGraph的stream接口很直观：

inputs = {"topic": "城市噪音治理策略分析", "revision_count": 0} for event in app.stream(inputs, config=config): for node_name, node_output in event.items(): if node_name == "research": print("研究节点完成，素材数量：", len(node_output["research_notes"])) elif node_name == "analyze": print("分析节点完成，大纲：", node_output["analysis"]["outline"][:50]) elif node_name == "write": print("写作节点完成，字数：", len(node_output["draft"])) elif node_name == "review": print("审核节点完成，通过：", node_output["review_result"]["passed"])

流式接口不仅是调试利器，在真实产品里也可以用来给前端推送进度，比如显示“当前研究阶段”“当前写作阶段”。用户的等待体验会好很多，因为大家都能看到多智能体团队在一步步推进工作。

4. 踩坑记录与调优技巧实录

4.1 智能体之间的状态污染与字段隔离

刚开始运行时，我发现一个诡异的问题：写作节点生成的文章中，偶尔会整体出现研究阶段的措辞方式，甚至直接出现“搜索到的第几条资料”这种表述。查了很久才发现，问题出现在状态定义上。我在TypedDict里把research_notes写成了普通list，而没有指定归约器，导致某个节点异常时把整个列表重置成了单条记录。这并不是最严重的问题，真正的状态污染来自Prompts——我让写作模型看了太多原始检索语料，它无法分辨哪些是“资料”哪些是“要生成的正文”，于是在正文里出现了“资料引用”式的表述。

解决方法是双管齐下。一是状态字段尽量精细化，每个节点只读所需字段，写操作也只涉及自己的字段，不轻易覆盖别人写过的状态字段。二是给写作模型的输入做一次“信息包装”，在研究笔记和写作Prompt之间加一个“信息编译”层，把素材转为写作模型容易理解的一二三要点，而不是直接扔原始JSON。

我特别想指出的是：多智能体协作中的“状态污染”，很多不是来自LangGraph本身的机制，而是Prompt设计上的歧义。模型分不清哪些是对话历史、哪些是待办任务、哪些是不能写进正文的事实材料。明确区分“材料”和“指示”是每个节点Prompt设计的基本原则，建议在每个节点的System Prompt里加上一句“以下内容是背景资料，不是正文，请勿直接引用其表达方式”。

4.2 工具调用失败和超时

研究节点是整条流水线中唯一重度依赖外部服务的节点，因此也是最容易出故障的地方。搜索API偶尔有频控、超时、返回空结果等问题，如果不对这些异常做防护，一次工具调用的失败就会中断整个团队流程。

我在项目中引入了两层容错机制。第一层是“工具内部重试”：封装一个带重试和退避的搜索函数，遇到超时先休息两秒再试，最多重试两次；两次都失败就返回一个空列表，而不是直接抛异常。第二层是“节点级兜底”：即使所有子问题检索都失败，研究节点也要能返回一个带有缺省提示的结果，例如说明“未检索到有效素材，建议人工确认主题或检查搜索API配额”，从而让流程继续走到分析阶段，并在最终结果中保留这些警告。

延迟问题同样不能忽视。一次研究阶段如果拆出5个子问题，每个子问题又检索4条结果然后精读，整体耗时可能超过两分钟，这会拖慢整条流水线的响应时间。我最后的做法是给整个研究节点设定一个总超时，并在子问题之间用并行方式检索。LangGraph允许在节点内部创建并行分支，也可以直接用Python的线程池并发调用搜索API，实测下来并发度控制在3到5比较合适，既能显著缩短总体耗时，又不至于触发API频控。

4.3 审核循环死循环

最大返工次数我没设好的时候，遇到过一个经典问题：审核节点对某一篇文章连续五次给出“不通过”，而且每次意见都不一样。写作模型拿到不同的修改意见，左改右改，结果每次越改越偏离原本的结构，而审核模型又开始挑新毛病，形成一个恶性循环。这个现象远比“单纯的重复意见”更难处理，因为它看起来好像是“改好了”但始终无法通过。

后来我把“审核意见一致性”纳入判断逻辑：审核节点每次输出意见时，会先简单比较当前草稿和上一版草稿，标注哪些是新增问题、哪些是历史遗留问题。如果模型发现返工之后虽然解决了上一轮指出的问题，但又引入了新的问题，审核意见就会更加具体地指出这个趋势，而不是只说“还是不行”。

更简单的防范措施是：设置最大重试轮数为2，并把每轮审核意见累积保存。即便最终未通过自动审核，人工拿到的是“研究笔记 + 分析大纲 + 初稿 + 两轮修改稿 + 两轮审核意见”，可以很清楚地判断问题到底出在哪个环节。这也体现了状态设计的优势：每个阶段的信息都在状态里留痕，方便追责和复盘。

4.4 成本与延迟控制

多智能体协作系统的资源消耗是单个Agent的数倍，这是不争的事实。我这套流程跑一个主题，研究节点可能调用8到10次模型，分析节点2到3次，写作节点分段生成大概4到6次，审核节点每轮2次，启动一次完整流程的总模型调用大约在20次到30次之间。如果使用高端模型，成本会相当可观。

控制成本的首要手段是“模型分级”。研究节点里的过滤和提炼工作不一定要用最高端的模型，用性价比更高的模型即可；分析节点和要求严格判断的审核节点才需要使用更强的模型。实际测试下来，这个组合在保持质量的同时能把成本压到原来的三分之一左右。

第二招是“压缩传递内容”。写作节点分段续写时，前文摘要的粒度要控制好，不要去重每轮全部正文。我在摘录策略上做了一个折中：对已生成的前文段落，只保留每段的主题句和结论句，细节尽量不要在续写里重复描述。这样模型在续写时不会把前面已经讲过的内容再展开一遍，也避免了生成内容重复膨胀。

第三招是“缓存研究结果”。同一个主题可能在不同时间反复被用于生成不同版本的文章，研究笔记和分析结果完全可以缓存。我的做法是把研究节点和分析节点的输出，按照主题的规范化hash存到共享缓存里，下次遇到相同主题时，直接将缓存写入状态，跳过耗时耗钱的检索和分析环节，只重新执行写作和审核。在内容更新频繁的行业里，这个优化非常实用。

4.5 持久化与断点续跑

最后聊一下在生产环境中遇到的“流程中断恢复”问题。之前没有接checkpointer时，一次模型服务异常会导致整条流水线从头跑，研究阶段的token完全浪费。接入SqliteSaver之后，进程可以恢复，但Sqlite在本机进程挂了以后还能不能读，取决于你用的是内存模式还是文件模式。生产环境建议直接用文件模式或RedisSaver，把检查点放到一个独立的存储中。

恢复执行并不是凭空恢复，而是通过thread_id找到该次任务的检查点。如果你开发时用的是每次不同的thread_id，等于没有做持久化。在业务中要把thread_id和任务号绑定，比如我代码里用的"article-task-001"这种业务化标识，这样即使后端重启，也能通过任务号恢复对应流程。

还有一个更实际的小技巧：写完一个供人工干预的接口，让运营人员可以修改状态里某个字段后重新执行某个节点。例如运营看完研究和分析阶段的内容后，可以删掉某个不合适的约束条件，再让流程从写作节点重新开始。这种“人工在回路中”的用法，将LangGraph的灵活状态机制发挥得淋漓尽致，也弥补了纯自动化审查的盲点。

我在实际使用中最深的一点体会是：多智能体协作系统的骨架并不是“智能体”，而是“状态图”。四个节点本身都很简单，好用的地方在于用一个清晰的状态模型把四个人的工作串起来了。把状态字段整理清楚、把条件路由设计到位、把失败恢复机制补好，这套团队就真正可以稳定输出。如果你也想把一套多角色协作流程落地，建议从这篇文章里的最小状态图开始，先把“研究-分析-写作-审核”四个节点跑起来，再加入你业务特有的反馈和人工干预机制，折腾几次，你就会发现LangGraph这个工具把你的流程思路表达得非常顺畅。