1. LangGraph 多智能体协作框架概述先聊点实在的。我接触 LangGraph 已经有一段时间了从最开始的单智能体简单对话到后来尝试各种复杂的多智能体编排实话实说LangGraph 确实是我用过的所有 Agent 框架里对可控性和状态管理支持得最舒服的一个。今天要分享的这个项目是拿 LangGraph 搭一个研究-分析-写作-审核的智能体写作团队说白了就是四个不同职责的 Agent 协同完成一篇高质量长文从选题到成稿的全流程。这篇文章我会把我踩过的坑、调过的参、改过的架构全盘托出帮想入坑多智能体的朋友少走弯路。我们先把话说明白这个项目到底解决什么问题日常我们做一个稍微有点深度的内容流程通常是查资料、理逻辑、搭框架、写初稿、反复修改。单靠一个 AGENT 一条 prompt 走到底你会发现它要么顾此失彼——查资料的时候忘了文章结构要么写出来的东西空泛无物。但如果把任务拆解给四个角色让它们像真人团队一样各司其职再通过 LangGraph 的状态图把流程编排起来效果会完全不一样。项目核心就是构建一个ResearchAgent研究员、AnalysisAgent分析师、WriterAgent写作者、ReviewAgent审核员四位一体的协作闭环每个智能体都有自己的系统提示词、工具集和判定逻辑上一个节点的输出作为下一个节点的输入最终产出带引用、结构清晰、经过校验的成品文章。适合谁来参考如果你已经会用 LangChain 或 LangGraph 做基本的 Agent 开发想更进一步理解多智能体系统到底怎么设计或者你正在做一个内容生成类的产品需要更高质量的文本产出再或者你就是单纯想看看 Graph 状态流如何管理复杂的任务依赖这个项目的拆解思路都非常值得你参考。代码工程量不算大核心部分其实就几百行但背后涉及的设计取舍、状态设计、异常回流策略才是真正的价值所在。2. 核心架构与四个智能体的职责拆解2.1 为什么用 LangGraph 而不是手写状态机先回答一个很多人会问的问题多智能体流程我直接用 Python 写个状态机不就行了吗为什么要引入 LangGraph我一开始也这么想过甚至用字典加一堆 if-else 搭过一个轮子。结果随着节点变多状态流转的代码变得又臭又长而且流程一旦需要回退、跳转、并行手写状态机的复杂度会指数级上升。LangGraph 的核心抽象是你把整个流程定义成一个图Graph节点就是函数边就是流转条件。它替你管好了状态存储、节点调度、条件路由、断点续跑这些脏活你要做的只是专注于每个节点内部的逻辑。这就好比你自己手写一个前端的虚拟 DOM 和直接用框架的区别——框架帮你省掉的是最容易被写错的那部分。另一个关键优势是持久化和人机回环。LangGraph 的 State 是显式的你可以在任何节点之间传递和存储数据而且天然支持 checkpoint如果某个节点跑挂了或者你想从中间某个环节重新恢复调试它可以接着继续而不是全部重跑。这对多智能体协作太重要了。因为四个 Agent 之间通常是串行依赖关系前面跑三分钟出的研究结果因为后面写作节点临时崩掉就要全部重跑那是噩梦。有了 checkpoint你只需要修好问题从失败的节点重新触发即可。2.2 四个角色的职责边界与协作接口我把四个 Agent 的职责切得非常清晰边界划分是这套系统设计中最关键的一环。如果两个 Agent 的职责重叠协作时就会出现互相推诿或者重复劳动的情况。具体设计如下Research Agent研究员只负责搜集资料并输出结构化的研究摘要。它的输出格式是固定的 JSON包含几个部分核心论据列表、关键数据点、参考来源、矛盾信息提示。它需要联网工具或本地检索工具我实际用的是 Tavily 搜索 API 和本地向量库混合检索的方式。研究员的任务是找到足够多足够权威的信息但它不负责判断这些信息之间的逻辑关联那个是分析师的事。Analysis Agent分析师负责对研究摘要进行深度加工。它的输入是研究员的 JSON 输出输出是分析框架包括文章的核心论点、逻辑主线、各章节主要观点、论证链路上存在的薄弱环节、可替换的反方视角。分析师是一个中间承上启下的角色它不直接写文章但它的输出直接决定文章的骨架质量。我做了一个非常明确的约束分析师输出的章节结构必须是带层级编号的大纲树每一个叶子节点要有该章节的写作意图说明和关键素材映射。Writer Agent写作者负责按照分析框架扩写成初稿。它拿到分析师的完整大纲后逐章节生成文字。这个角色我允许它调用一些写作增强的 Prompt 模板比如不同风格的改写、过渡句的生成但核心原则是只做扩写不做创新。什么叫不做创新就是它不能擅自抛出分析框架中没有的新观点。如果写作过程中发现某个章节内容撑不起来它要把内容缺口记录下来回流给分析师或研究员而不是自己硬编。Review Agent审核员最后一个把关角色。它的输入是文章的完整初稿和分析师的框架输出是一份审校报告包括事实性错误清单、逻辑跳跃位置、与大纲偏离的段落、引用缺失、格式问题。审核员不直接修改原文而是把问题点都标出来再决定是由哪位角色去修正。这个回环机制后面会细说。角色之间的协作接口全部用 Pydantic 模型定义好这样传到下一个 Agent 的时候结构不会乱。我在实践中发现如果接口定义得不够严格Role A 的输出稍微有些格式漂移Role B 接到之后解析就会出错。所以从一开始就要用类型约束宁可开发时多写几行 schema也不要让自由文本在节点之间裸奔。2.3 状态图设计与节点流转逻辑LangGraph 里每个节点是一个可调用的函数接收状态并返回状态更新。整个图我是这样设计的研究节点 → 分析节点 → 写作节点 → 审核节点 ↑ ↓ └──── 内容缺口/审核问题 ──┘这个图在 LangGraph 里实现的时候可以通过一个StateGraph来构建。我把 State 定义为from typing import TypedDict, List from pydantic import BaseModel class ResearchData(BaseModel): topic: str evidence_points: List[str] data_points: List[str] sources: List[str] contradictions: List[str] class AnalysisFramework(BaseModel): thesis: str logic_line: List[str] chapter_outline: List[dict] # 每章标题、要点、素材映射 weaknesses: List[str] class ArticleState(TypedDict, totalFalse): topic: str research_data: ResearchData analysis: AnalysisFramework draft: str review_report: str revision_round: int routes: strState 中的routes是关键的控制字段决定图下一步往哪走。比如审核节点会根据是否存在需要修改的问题返回needs_revision或approved条件边根据这个结果决定是流向写作节点还是结束。revision_round记录修改轮数防止出现死循环——我会在代码里设置一个最大轮数比如 3 轮超过后强制通过并输出说明。3. 环境准备与前期配置3.1 依赖安装与环境变量这块我默认你已经有了一个 Python 3.9 以上的环境建议用poetry或uv管理依赖省得以后版本冲突想哭。项目核心依赖如下langgraph0.2.0 langchain-openai langchain-core tavily-python pydantic2.0 python-dotenv如果你打算让 Researcher 用本地检索增强还需要chromadb或者faiss-cpu我测试用的向量库是 Chroma因为配置更简单开箱即用。安装全部依赖后创建一个.env文件配置你的 API KeyOPENAI_API_KEYsk-xxx TAVILY_API_KEYtvly-xxx如果你用的是国内模型供应商LangChain 都有对应的封装只需修改 LLM 的初始化部分即可接口逻辑完全不变。我的经验是先把核心链路用 GPT 系列跑通再换其他模型验证兼容性这样可以最快隔离问题。3.2 LLM 模型选择的经验与不同模型的实测差异多智能体系统对模型的依赖其实比想象中大。我做了横向的简单对比在同样的 prompt 和输入数据下跑同一个项目流程模型研究摘要准确度大纲结构性写作流畅度审核查错率单轮耗时某商用闭源旗舰高高高中较快某开源大参数模型中中中低慢某轻量商用模型低低中低快实测下来四个角色里分析环节对模型能力最敏感。研究员写摘要即使能用普通的模型因为它是把检索到的信息结构化不需要太多推理写作虽然要求文字质量但 LLM 本身文字生成能力普遍在线真正的瓶颈在分析师这里它需要从大量材料中提炼逻辑主线、找出论证漏洞、设计章节结构这些是典型的慢思考小模型的输出往往会绕来绕去甚至开始编造主线。审核员也挑模型它需要一边读长文一边对照原始框架对长上下文的理解能力要求较高。所以我最后的选型方案是分析节点用最强的模型其他三个节点用均衡型模型。如果你预算有限宁可让研究节点用更弱的模型也别让分析节点掉链子。这是我在实际调优中最有价值的结论之一。4. Agent 节点的 Prompt 设计与输出约束4.1 四个角色的 System Prompt 设计思路Prompt 设计是多智能体项目里不可忽视的一环。每个 Agent 的 System Prompt 需要把角色目标、工作范围、输入格式、输出约束、禁止事项都交代清楚。我直接给你看我的模板框架你可以在此基础上调整细节。研究员的 System Prompt 核心段落你是一名资深研究助理你的任务是对给定主题进行信息搜集与整理。 你必须严格遵守以下规则 1. 只报告可验证的事实与数据不进行主观评价。 2. 每个论点必须附带参考来源来源需包含出版方和发布时间。 3. 如果发现不同来源之间存在矛盾在 contradictions 字段中列出。 4. 输出必须为 JSON格式为 {evidence_points: [...], data_points: [...], sources: [...], contradictions: [...]} 5. 禁止编造来源无法确认的信息标记为 unverified。注意我要求它把无法确认的信息显式标记出来这对后面的分析师和审核员特别有用。否则模型很容易一本正经地胡说八道。分析师的 System Prompt 核心段落你是一名严谨的逻辑分析师。你将收到研究员的调研结果 JSON。 你的工作是把这些素材组织成一篇有说服力、结构严谨的长文框架。 你必须 1. 先提炼核心论点 thesis论点应覆盖所有关键素材并回应矛盾信息。 2. 形成清晰的逻辑主线 logic_line确保主线连贯不跳跃。 3. design 章节大纲 outline每个章节须包含写作要点和对应素材。 4. 主动指出论证链中可能被质疑的薄弱环节 weaknesses。 输出 JSON 格式禁止在框架中加入研究素材中不存在的观点。这里专门强调了禁止加入素材中不存在的观点是为了防止分析节点自由发挥出一些没有依据的断言后面写作节点就会拿着这些断言去编造内容污染整篇文章。写作者的 System Prompt较简单但同样有讲究你是一名中文科技写作专家。你将收到一份完整的大纲和素材映射。 你的任务是把每个大纲节点扩写成自然连贯的段落文字。 要求 1. 严格遵循大纲结构不得自行新增或删除章节。 2. 使用客观中性的语言避免过度夸张和主观臆断。 3. 如果某一部分素材不足不要编造填补而是在段落末尾标记 {{CONTENT_GAP: 描述缺口}}。 4. 输出整篇文章的 Markdown 格式正文。审核员的 System Prompt你是一名严谨的审稿人。你收到文章全文和最初的分析提纲。 请逐段检查 1. 逻辑连贯性段落之间是否有明显跳跃或矛盾 2. 事实准确性文中的数字、引用是否与给定素材一致 3. 大纲一致性是否遗漏了分析提纲中的关键论点 4. 语法与格式是否存在明显语病或 Markdown 格式错误 输出审核报告 JSON包含 errors 数组每项包含位置、类型、修改建议。值得强调的是系统提示词里最好都包含你在一个团队中你需要和其他同事配合这种协作上下文。我发现加入团队协作描述后Agent 会更主动地遵循输出格式也更不会多管闲事。有点像是给每个 agent 一个心理暗示。4.2 结构化输出的强制方案Pydantic with_structured_output早期我在这个项目里让每个 Agent 输出纯文本再用json.loads去解析结果经常因为模型输出里混了多余的文字导致解析失败。后来我用了 LangChain 的with_structured_output方法直接把 Pydantic 模型传给 LLM让模型原生输出 JSON效果好了不少。from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate class ResearchOutput(BaseModel): evidence_points: List[str] data_points: List[str] sources: List[str] contradictions: List[str] llm ChatOpenAI(modelgpt-4o-mini, temperature0.2) structured_llm llm.with_structured_output(ResearchOutput) prompt ChatPromptTemplate.from_messages([ (system, SYSTEM_RESEARCH_PROMPT), (human, 研究主题{topic}\n检索到的素材{raw_material}) ]) chain prompt | structured_llm result chain.invoke({topic: topic, raw_material: material_joined})这里的result直接就是一个ResearchOutput实例不需要任何手动解析代码干净很多。temperature我调到了 0.2 左右目的是给模型一点灵活性又不至于输出太飘。如果要求严格的事实输出我会直接设为 0但对研究摘要来说完全 0 会让表达过于呆板且不利于后续分析经过测试 0.2 是一个好的平衡点。with_structured_output在底层其实是利用了模型的工具调用或函数调用能力比单纯的 JSON prompt 稳定太多。如果你的模型不支持结构化输出某些开源模型不支持那就需要写一个自定义的 parser 并在 prompt 中配合 few-shot 示例但会增加不少兼容性工作。所以我建议你在项目初期直接选择支持函数调用的模型来降低成本。4.3 工具定义与检索增强研究员要真正研究不能只靠模型内部知识因为内部知识有截止日期且容易产生幻觉。这个项目里研究员实际调用了两大检索工具Tavily Web Search和本地知识库检索。Tavily 是一个专门为 LLM Agent 优化的搜索 API返回的结果比普通搜索引擎 API 更干净自带摘要和内容过滤。我用它来做实时资讯的检索。像这样from langchain_community.tools import TavilySearchResults tavily_tool TavilySearchResults( api_key..., max_results5, search_depthadvanced ) res tavily_tool.invoke({query: topic})返回的结果我通常会把标题、链接、内容摘要合并成一个文本块塞给研究员。本地知识库我用 Chroma 存了一些常用的行业报告和技术文档查询时做向量相似度检索拿到 TOP-K 片段拼进上下文中。这一块有个很关键的细节工具返回的结果不能直接丢给模型。原始搜索结果是高度冗余的往往包含重复内容、广告链接、低质量页面。如果不加处理模型的注意力会被无关信息吸引导致研究摘要质量下降。我写了一个简单但有效的后处理函数过滤掉来源域名黑名单中的结果、去重、裁剪过长摘要、统一成 markdown 引用块格式。实测这个步骤能把后续分析节点的效果提升一个档次。5. 完整流程实现让四个智能体真正跑起来5.1 构建 LangGraph 状态图节点注册与连接下面是我简化后可以直接跑的状态图代码。这里我省略了节点内部的详细 prompt 构造聚焦于图的编排。from langgraph.graph import StateGraph, END from typing import TypedDict, Optional class AgentState(TypedDict, totalFalse): topic: str raw_material: str research_data: Optional[dict] analysis: Optional[dict] draft: str review_report: str revision_round: int next_action: str # 节点函数定义 def research_node(state: AgentState) - AgentState: # 调用搜索工具获取原始材料 search_results run_tavily_search(state[topic]) raw enrich_with_local_kb(state[topic]) # merged_material merge_search_result(search_results, raw) res research_chain.invoke({ topic: state[topic], raw_material: merged_material }) return {research_data: res.dict(), raw_material: merged_material} def analysis_node(state: AgentState) - AgentState: research state[research_data] analysis analysis_chain.invoke({research_json: json.dumps(research, ensure_asciiFalse)}) return {analysis: analysis.dict()} def writing_node(state: AgentState) - AgentState: draft writing_chain.invoke({ framework: json.dumps(state[analysis], ensure_asciiFalse), previous_feedback: state.get(review_report, ) }) return {draft: draft} def review_node(state: AgentState) - AgentState: report review_chain.invoke({ draft: state[draft], framework: json.dumps(state[analysis], ensure_asciiFalse) }) return {review_report: report, next_action: report.get(needs_revision, approve)} def decide_next(state: AgentState) - str: # 如果审核不过且修改轮数小于3则回到写作否则结束 if state[next_action] revision and state[revision_round] 3: return revision return end # 构建图 graph StateGraph(AgentState) graph.add_node(research, research_node) graph.add_node(analysis, analysis_node) graph.add_node(writing, writing_node) graph.add_node(review, review_node) graph.set_entry_point(research) graph.add_edge(research, analysis) graph.add_edge(analysis, writing) graph.add_edge(writing, review) graph.add_conditional_edges(review, decide_next, { revision: writing, end: END }) app graph.compile()这个图的核心在decide_next这个条件路由。审核节点输出review_report里面包含一个布尔字段needs_revision同时我维护了revision_round计数。每次审核不过状态里的revision_round自动加一我实际是在review_node里 1 的可以在返回 state 时更新。当轮数来到 3 还是不过强制结束。实际使用中你还可以给每个节点加interrupt_before或interrupt_after这需要在与用户交互的场景中使用。如果你的业务是半自动希望审核员审完后等人工确认再决定是否回退给写作者那用 LangGraph 的 human-in-the-loop 机制就非常合适——在review节点后加一个等待点人工在 Web UI 上确认后调用update_state继续执行。我最初的原型就是这么干的后续才改成全自动。5.2 关键实现细节上下文拼接与状态传递的坑在多个 Agent 串联时最容易被忽视的问题是上下文的累计膨胀。比如研究者输出的素材已经很长分析师输出的大纲也不短写作过程要把两者全部喂给 LLM加上写作过程的中间输出Token 消耗会非常大而且模型的处理效果也会随上下文变长而下降。我的解决方案是分阶段做上下文压缩。研究者输出给分析师前先做一次信息蒸馏把原始搜索文本片段压缩成每个论点到两三句话分析师的输出本来就已经是结构化精简内容写作节点只需要看分析师的框架不需要再看原始素材素材已经映射进了分析框架中。这样每个节点的输入都不会超过窗口的 70%。万一遇到超长分析报告我还会先让一个轻量模型做摘要压缩再送给写作者。另一个坑是状态字段的传递。如果不小心把某个大字段塞进每次返回的 state 里LangGraph 的存储和网络传输开销会让你觉得怎么这么慢。解决办法是在每个节点里只返回需要更新的字段不要返回你拿到的全量 state。比如writing_node不一定在输出里附带原始 research_data这个我在代码里没有返回后台其实只更新了draft字段。StateGraph 默认会做字段合并返回部分字段没问题。5.3 运行效果与输出对比我拿一个例子跑了完整流程主题是低空经济下游产业链分析。研究员检索了 6 条网页数据、从本地知识库摘取了 3 篇行业报告片段。分析师生成的主线是政策-基础设施-应用场景-商业模式的递进结构共 5 个章节。写作者生成了一篇约 3000 字的长文。审核员最终提出了 3 个逻辑衔接问题和 1 个数据来源缺失点系统自动回退给写作者修改了一轮第二轮通过。对比我把同一主题直接丢给单 Agent 写出的文章最大的不同是多智能体产物的结构明显更清晰论据更扎实且能明显看出上下文的一致性更好。单独 Agent 容易在一开始的 part 强调某事后面又出现矛盾表述。审核环节能抓住这类问题说明回环价值确实存在这是单轮生成很难做到的。6. 异常处理与调优实战记录6.1 常见的坑JSON 解析失败、循环过深、上下文溢出我把项目运行过程中遇到的高频问题整理成了一张速查表方便你对照排查问题现象根因解决方案研究员输出 JSON 解析失败模型输出了多余文字或 JSON 语法错误启用with_structured_output或加 few-shot 示例或设 temperature0系统陷入无意义的重写循环审核节点每次都能挑出新问题修改后又有新问题限制 revision_round 最大为 3审核节点要求优先报告阻断级问题次要问题合并上下文超长报错素材过大且未压缩在节点间传递摘要而非全文引入 Map-Reduce 方式对长文本分块处理子 Agent 输出符合格式但内涵空洞模型能力不足或 prompt 缺少具体约束在 prompt 中增加每个论点需包含具体数字或引用的要求提升到更强模型研究摘要中包含大量过期信息搜索引擎结果过旧未按时间过滤Tavily 搜索时设置days30参数本地数据源建立更新时间优先级循环过深的问题我这边实际踩过一次。因为审核员过于勤快把一些非常微小的措辞问题也报成 error写作者每次都要去改改了之后审核员又觉得新措辞有问题来回三四次还没完。后来我在审核员的 prompt 里明确要求它区分阻断问题和建议问题只有阻断问题才触发回退建议问题可以累积到最终报告中人工参考。这之后循环次数大幅降低。上下文溢出是另一个高频问题。研究阶段如果主题太宽泛搜索结果可能塞进去一大堆文本。超出窗口时最直接的解决手段是用一个小模型把原始素材按主题聚类并提取每个簇的 3 条要点把要点传给研究者。这样相当于在管线前段加了一个预处理器。虽然多了一步调用但能保证主链路的稳定性。如果你希望更省成本也可以采用文本分割策略只抽取与主题强相关的段落这一点和 RAG 的 chunk 策略类似。6.2 日志追踪与可视化调试LangGraph 自带一些调试工具我强烈建议你在开发阶段开启。最简单的用法是在编译后的图上调用app.get_graph().print_ast()它会打印出节点的拓扑结构方便确认条件边有没有连错。如果你需要细粒度观察每个节点的输入输出可以自定义一个简单的回调函数把每次节点调用的耗时、token 数、返回的状态片段打印到终端。这个我通常直接封装成一个装饰器def trace_node(name): def decorator(func): def wrapper(state): start time.time() result func(state) elapsed time.time() - start print(f[Trace] {name} 耗时 {elapsed:.2f}s) return result return wrapper return decorator有了 trace你可以快速定位是哪个节点最慢、哪次输出走了意外分支。我在调试审核回环的时候靠这个日志发现是next_action没有正确更新导致走了多次 end。还有一个非常实用的技巧把每个节点的中间结果保存到本地 JSON 文件。流程跑完后你把四个节点的输出打开对比马上就能看出是哪个角色没有正确理解上下文。这种“过程可视化”比只看最终结果要能更快暴露问题。6.3 成本控制与延迟优化建议多智能体跑一轮就是好几次大模型调用加在一起成本和延迟都不低。我实测完一轮四角色流程消耗约 2 万到 3 万 token耗时 1 到 2 分钟取决于模型。如果你想压成本可以从这几个角度动刀小的用轻量重的用强模型研究员可以用mini档位的模型审核员首次审核可以用中档模型如果出现疑似问题需要二次复核才用强模型确认。缓存研究结果同一主题如果之前跑过直接把研究数据缓存到本地磁盘或数据库不用每次重新搜索。我用的是简单的 JSON 文件缓存以主题 hash 为 key。并行化研究检索Tavily 搜索可以和本地向量库检索并行执行在异步环境里可以用asyncio.gather让两者同时进行而不是串行。这适合用 LangGraph 的异步节点版本延迟能显著降低。限制审核轮次最长只允许一次修订把 more strict 的责任放在第一次写作时。我后来在生产版本中把revision_round上限设为 1文章质量依然达标延迟却缩短了 30%。成本优化永远是个取舍游戏。关键是你需要定义可接受的质量下限。我的经验是只要分析师框架足够扎实写作者不太会跑偏审核压力也不大所以与其在审核上烧钱不如把分析节点做深做透。7. 经验总结与下一步扩展思路先说说我在这个项目上的整体心得。多智能体的系统思考方式与你写单 Agent 完全不同单 Agent 是在一个巨大的 prompt 里塞满所有指令而多智能体是把复杂任务拆成多个小而明确的子任务每个子任务由专门的智能体完成通过状态接口协作。这种设计带来的是更高的可控性和可解释性——你可以知道文章是哪个环节出问题了甚至可以单独替换某个智能体的实现。LangGraph 作为编排层真正发挥了图即流程的威力让之前手写状态机的复杂度被彻底降维。如果你准备把这个项目往下扩展我建议优先考虑这三条路都是我实际验证过或正在尝试的方向一是引入人的反馈作为节点。在分析节点和写作节点之间加一个人工评审接口。人类专家可以修改大纲或添加约束然后图继续往写作节点跑。LangGraph 的interrupt机制可以完美支持这个需求这样整个系统就不再是黑乎乎的全自动流水线而是人机协作的智能编审系统。二是把审核节点做成一个子图。单个审核员也许能力有限你可以把审核拆成事实核查员、逻辑检查员、风格检查员三个小 Agent每个专注一个方向通过子图并行执行汇总成审核报告。这相当于让审核节点也变成一个小型多智能体团队效果会更强。三是引入外部素材库做持续记忆。现在研究节点每次都要重新搜索如果有一个长期记忆模块把历次研究的关键结论沉淀下来下次研究同一主题时就能站在已有知识之上减少搜索成本也能让文章的前后连续性更强。老实说多智能体应用现在还在一个快速演进的阶段框架也在不断升级。但底层的思想——把任务拆解、让专业角色各自负责、通过状态流转协同——这些是不变的。希望这个项目的拆解能给你带来一些启发如果你也在搞类似的 Agent 团队遇到问题可以按我上面这些思路去排查大概率能帮你省下不少折腾的时间。最后留一个小建议先在单条链路上把每个节点的输入输出调通再考虑加搜索和缓存这些高级功能。别一上来就追求完备跑起来比跑完美重要得多。 
长河君 · 2026/10/20 15:04:19 · 阅读 1.2k LangGraph多智能体协作框架实战：研究-分析-写作-审核全流程
1. LangGraph 多智能体协作框架概述先聊点实在的。我接触 LangGraph 已经有一段时间了从最开始的单智能体简单对话到后来尝试各种复杂的多智能体编排实话实说LangGraph 确实是我用过的所有 Agent 框架里对可控性和状态管理支持得最舒服的一个。今天要分享的这个项目是拿 LangGraph 搭一个研究-分析-写作-审核的智能体写作团队说白了就是四个不同职责的 Agent 协同完成一篇高质量长文从选题到成稿的全流程。这篇文章我会把我踩过的坑、调过的参、改过的架构全盘托出帮想入坑多智能体的朋友少走弯路。我们先把话说明白这个项目到底解决什么问题日常我们做一个稍微有点深度的内容流程通常是查资料、理逻辑、搭框架、写初稿、反复修改。单靠一个 AGENT 一条 prompt 走到底你会发现它要么顾此失彼——查资料的时候忘了文章结构要么写出来的东西空泛无物。但如果把任务拆解给四个角色让它们像真人团队一样各司其职再通过 LangGraph 的状态图把流程编排起来效果会完全不一样。项目核心就是构建一个ResearchAgent研究员、AnalysisAgent分析师、WriterAgent写作者、ReviewAgent审核员四位一体的协作闭环每个智能体都有自己的系统提示词、工具集和判定逻辑上一个节点的输出作为下一个节点的输入最终产出带引用、结构清晰、经过校验的成品文章。适合谁来参考如果你已经会用 LangChain 或 LangGraph 做基本的 Agent 开发想更进一步理解多智能体系统到底怎么设计或者你正在做一个内容生成类的产品需要更高质量的文本产出再或者你就是单纯想看看 Graph 状态流如何管理复杂的任务依赖这个项目的拆解思路都非常值得你参考。代码工程量不算大核心部分其实就几百行但背后涉及的设计取舍、状态设计、异常回流策略才是真正的价值所在。2. 核心架构与四个智能体的职责拆解2.1 为什么用 LangGraph 而不是手写状态机先回答一个很多人会问的问题多智能体流程我直接用 Python 写个状态机不就行了吗为什么要引入 LangGraph我一开始也这么想过甚至用字典加一堆 if-else 搭过一个轮子。结果随着节点变多状态流转的代码变得又臭又长而且流程一旦需要回退、跳转、并行手写状态机的复杂度会指数级上升。LangGraph 的核心抽象是你把整个流程定义成一个图Graph节点就是函数边就是流转条件。它替你管好了状态存储、节点调度、条件路由、断点续跑这些脏活你要做的只是专注于每个节点内部的逻辑。这就好比你自己手写一个前端的虚拟 DOM 和直接用框架的区别——框架帮你省掉的是最容易被写错的那部分。另一个关键优势是持久化和人机回环。LangGraph 的 State 是显式的你可以在任何节点之间传递和存储数据而且天然支持 checkpoint如果某个节点跑挂了或者你想从中间某个环节重新恢复调试它可以接着继续而不是全部重跑。这对多智能体协作太重要了。因为四个 Agent 之间通常是串行依赖关系前面跑三分钟出的研究结果因为后面写作节点临时崩掉就要全部重跑那是噩梦。有了 checkpoint你只需要修好问题从失败的节点重新触发即可。2.2 四个角色的职责边界与协作接口我把四个 Agent 的职责切得非常清晰边界划分是这套系统设计中最关键的一环。如果两个 Agent 的职责重叠协作时就会出现互相推诿或者重复劳动的情况。具体设计如下Research Agent研究员只负责搜集资料并输出结构化的研究摘要。它的输出格式是固定的 JSON包含几个部分核心论据列表、关键数据点、参考来源、矛盾信息提示。它需要联网工具或本地检索工具我实际用的是 Tavily 搜索 API 和本地向量库混合检索的方式。研究员的任务是找到足够多足够权威的信息但它不负责判断这些信息之间的逻辑关联那个是分析师的事。Analysis Agent分析师负责对研究摘要进行深度加工。它的输入是研究员的 JSON 输出输出是分析框架包括文章的核心论点、逻辑主线、各章节主要观点、论证链路上存在的薄弱环节、可替换的反方视角。分析师是一个中间承上启下的角色它不直接写文章但它的输出直接决定文章的骨架质量。我做了一个非常明确的约束分析师输出的章节结构必须是带层级编号的大纲树每一个叶子节点要有该章节的写作意图说明和关键素材映射。Writer Agent写作者负责按照分析框架扩写成初稿。它拿到分析师的完整大纲后逐章节生成文字。这个角色我允许它调用一些写作增强的 Prompt 模板比如不同风格的改写、过渡句的生成但核心原则是只做扩写不做创新。什么叫不做创新就是它不能擅自抛出分析框架中没有的新观点。如果写作过程中发现某个章节内容撑不起来它要把内容缺口记录下来回流给分析师或研究员而不是自己硬编。Review Agent审核员最后一个把关角色。它的输入是文章的完整初稿和分析师的框架输出是一份审校报告包括事实性错误清单、逻辑跳跃位置、与大纲偏离的段落、引用缺失、格式问题。审核员不直接修改原文而是把问题点都标出来再决定是由哪位角色去修正。这个回环机制后面会细说。角色之间的协作接口全部用 Pydantic 模型定义好这样传到下一个 Agent 的时候结构不会乱。我在实践中发现如果接口定义得不够严格Role A 的输出稍微有些格式漂移Role B 接到之后解析就会出错。所以从一开始就要用类型约束宁可开发时多写几行 schema也不要让自由文本在节点之间裸奔。2.3 状态图设计与节点流转逻辑LangGraph 里每个节点是一个可调用的函数接收状态并返回状态更新。整个图我是这样设计的研究节点 → 分析节点 → 写作节点 → 审核节点 ↑ ↓ └──── 内容缺口/审核问题 ──┘这个图在 LangGraph 里实现的时候可以通过一个StateGraph来构建。我把 State 定义为from typing import TypedDict, List from pydantic import BaseModel class ResearchData(BaseModel): topic: str evidence_points: List[str] data_points: List[str] sources: List[str] contradictions: List[str] class AnalysisFramework(BaseModel): thesis: str logic_line: List[str] chapter_outline: List[dict] # 每章标题、要点、素材映射 weaknesses: List[str] class ArticleState(TypedDict, totalFalse): topic: str research_data: ResearchData analysis: AnalysisFramework draft: str review_report: str revision_round: int routes: strState 中的routes是关键的控制字段决定图下一步往哪走。比如审核节点会根据是否存在需要修改的问题返回needs_revision或approved条件边根据这个结果决定是流向写作节点还是结束。revision_round记录修改轮数防止出现死循环——我会在代码里设置一个最大轮数比如 3 轮超过后强制通过并输出说明。3. 环境准备与前期配置3.1 依赖安装与环境变量这块我默认你已经有了一个 Python 3.9 以上的环境建议用poetry或uv管理依赖省得以后版本冲突想哭。项目核心依赖如下langgraph0.2.0 langchain-openai langchain-core tavily-python pydantic2.0 python-dotenv如果你打算让 Researcher 用本地检索增强还需要chromadb或者faiss-cpu我测试用的向量库是 Chroma因为配置更简单开箱即用。安装全部依赖后创建一个.env文件配置你的 API KeyOPENAI_API_KEYsk-xxx TAVILY_API_KEYtvly-xxx如果你用的是国内模型供应商LangChain 都有对应的封装只需修改 LLM 的初始化部分即可接口逻辑完全不变。我的经验是先把核心链路用 GPT 系列跑通再换其他模型验证兼容性这样可以最快隔离问题。3.2 LLM 模型选择的经验与不同模型的实测差异多智能体系统对模型的依赖其实比想象中大。我做了横向的简单对比在同样的 prompt 和输入数据下跑同一个项目流程模型研究摘要准确度大纲结构性写作流畅度审核查错率单轮耗时某商用闭源旗舰高高高中较快某开源大参数模型中中中低慢某轻量商用模型低低中低快实测下来四个角色里分析环节对模型能力最敏感。研究员写摘要即使能用普通的模型因为它是把检索到的信息结构化不需要太多推理写作虽然要求文字质量但 LLM 本身文字生成能力普遍在线真正的瓶颈在分析师这里它需要从大量材料中提炼逻辑主线、找出论证漏洞、设计章节结构这些是典型的慢思考小模型的输出往往会绕来绕去甚至开始编造主线。审核员也挑模型它需要一边读长文一边对照原始框架对长上下文的理解能力要求较高。所以我最后的选型方案是分析节点用最强的模型其他三个节点用均衡型模型。如果你预算有限宁可让研究节点用更弱的模型也别让分析节点掉链子。这是我在实际调优中最有价值的结论之一。4. Agent 节点的 Prompt 设计与输出约束4.1 四个角色的 System Prompt 设计思路Prompt 设计是多智能体项目里不可忽视的一环。每个 Agent 的 System Prompt 需要把角色目标、工作范围、输入格式、输出约束、禁止事项都交代清楚。我直接给你看我的模板框架你可以在此基础上调整细节。研究员的 System Prompt 核心段落你是一名资深研究助理你的任务是对给定主题进行信息搜集与整理。 你必须严格遵守以下规则 1. 只报告可验证的事实与数据不进行主观评价。 2. 每个论点必须附带参考来源来源需包含出版方和发布时间。 3. 如果发现不同来源之间存在矛盾在 contradictions 字段中列出。 4. 输出必须为 JSON格式为 {evidence_points: [...], data_points: [...], sources: [...], contradictions: [...]} 5. 禁止编造来源无法确认的信息标记为 unverified。注意我要求它把无法确认的信息显式标记出来这对后面的分析师和审核员特别有用。否则模型很容易一本正经地胡说八道。分析师的 System Prompt 核心段落你是一名严谨的逻辑分析师。你将收到研究员的调研结果 JSON。 你的工作是把这些素材组织成一篇有说服力、结构严谨的长文框架。 你必须 1. 先提炼核心论点 thesis论点应覆盖所有关键素材并回应矛盾信息。 2. 形成清晰的逻辑主线 logic_line确保主线连贯不跳跃。 3. design 章节大纲 outline每个章节须包含写作要点和对应素材。 4. 主动指出论证链中可能被质疑的薄弱环节 weaknesses。 输出 JSON 格式禁止在框架中加入研究素材中不存在的观点。这里专门强调了禁止加入素材中不存在的观点是为了防止分析节点自由发挥出一些没有依据的断言后面写作节点就会拿着这些断言去编造内容污染整篇文章。写作者的 System Prompt较简单但同样有讲究你是一名中文科技写作专家。你将收到一份完整的大纲和素材映射。 你的任务是把每个大纲节点扩写成自然连贯的段落文字。 要求 1. 严格遵循大纲结构不得自行新增或删除章节。 2. 使用客观中性的语言避免过度夸张和主观臆断。 3. 如果某一部分素材不足不要编造填补而是在段落末尾标记 {{CONTENT_GAP: 描述缺口}}。 4. 输出整篇文章的 Markdown 格式正文。审核员的 System Prompt你是一名严谨的审稿人。你收到文章全文和最初的分析提纲。 请逐段检查 1. 逻辑连贯性段落之间是否有明显跳跃或矛盾 2. 事实准确性文中的数字、引用是否与给定素材一致 3. 大纲一致性是否遗漏了分析提纲中的关键论点 4. 语法与格式是否存在明显语病或 Markdown 格式错误 输出审核报告 JSON包含 errors 数组每项包含位置、类型、修改建议。值得强调的是系统提示词里最好都包含你在一个团队中你需要和其他同事配合这种协作上下文。我发现加入团队协作描述后Agent 会更主动地遵循输出格式也更不会多管闲事。有点像是给每个 agent 一个心理暗示。4.2 结构化输出的强制方案Pydantic with_structured_output早期我在这个项目里让每个 Agent 输出纯文本再用json.loads去解析结果经常因为模型输出里混了多余的文字导致解析失败。后来我用了 LangChain 的with_structured_output方法直接把 Pydantic 模型传给 LLM让模型原生输出 JSON效果好了不少。from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate class ResearchOutput(BaseModel): evidence_points: List[str] data_points: List[str] sources: List[str] contradictions: List[str] llm ChatOpenAI(modelgpt-4o-mini, temperature0.2) structured_llm llm.with_structured_output(ResearchOutput) prompt ChatPromptTemplate.from_messages([ (system, SYSTEM_RESEARCH_PROMPT), (human, 研究主题{topic}\n检索到的素材{raw_material}) ]) chain prompt | structured_llm result chain.invoke({topic: topic, raw_material: material_joined})这里的result直接就是一个ResearchOutput实例不需要任何手动解析代码干净很多。temperature我调到了 0.2 左右目的是给模型一点灵活性又不至于输出太飘。如果要求严格的事实输出我会直接设为 0但对研究摘要来说完全 0 会让表达过于呆板且不利于后续分析经过测试 0.2 是一个好的平衡点。with_structured_output在底层其实是利用了模型的工具调用或函数调用能力比单纯的 JSON prompt 稳定太多。如果你的模型不支持结构化输出某些开源模型不支持那就需要写一个自定义的 parser 并在 prompt 中配合 few-shot 示例但会增加不少兼容性工作。所以我建议你在项目初期直接选择支持函数调用的模型来降低成本。4.3 工具定义与检索增强研究员要真正研究不能只靠模型内部知识因为内部知识有截止日期且容易产生幻觉。这个项目里研究员实际调用了两大检索工具Tavily Web Search和本地知识库检索。Tavily 是一个专门为 LLM Agent 优化的搜索 API返回的结果比普通搜索引擎 API 更干净自带摘要和内容过滤。我用它来做实时资讯的检索。像这样from langchain_community.tools import TavilySearchResults tavily_tool TavilySearchResults( api_key..., max_results5, search_depthadvanced ) res tavily_tool.invoke({query: topic})返回的结果我通常会把标题、链接、内容摘要合并成一个文本块塞给研究员。本地知识库我用 Chroma 存了一些常用的行业报告和技术文档查询时做向量相似度检索拿到 TOP-K 片段拼进上下文中。这一块有个很关键的细节工具返回的结果不能直接丢给模型。原始搜索结果是高度冗余的往往包含重复内容、广告链接、低质量页面。如果不加处理模型的注意力会被无关信息吸引导致研究摘要质量下降。我写了一个简单但有效的后处理函数过滤掉来源域名黑名单中的结果、去重、裁剪过长摘要、统一成 markdown 引用块格式。实测这个步骤能把后续分析节点的效果提升一个档次。5. 完整流程实现让四个智能体真正跑起来5.1 构建 LangGraph 状态图节点注册与连接下面是我简化后可以直接跑的状态图代码。这里我省略了节点内部的详细 prompt 构造聚焦于图的编排。from langgraph.graph import StateGraph, END from typing import TypedDict, Optional class AgentState(TypedDict, totalFalse): topic: str raw_material: str research_data: Optional[dict] analysis: Optional[dict] draft: str review_report: str revision_round: int next_action: str # 节点函数定义 def research_node(state: AgentState) - AgentState: # 调用搜索工具获取原始材料 search_results run_tavily_search(state[topic]) raw enrich_with_local_kb(state[topic]) # merged_material merge_search_result(search_results, raw) res research_chain.invoke({ topic: state[topic], raw_material: merged_material }) return {research_data: res.dict(), raw_material: merged_material} def analysis_node(state: AgentState) - AgentState: research state[research_data] analysis analysis_chain.invoke({research_json: json.dumps(research, ensure_asciiFalse)}) return {analysis: analysis.dict()} def writing_node(state: AgentState) - AgentState: draft writing_chain.invoke({ framework: json.dumps(state[analysis], ensure_asciiFalse), previous_feedback: state.get(review_report, ) }) return {draft: draft} def review_node(state: AgentState) - AgentState: report review_chain.invoke({ draft: state[draft], framework: json.dumps(state[analysis], ensure_asciiFalse) }) return {review_report: report, next_action: report.get(needs_revision, approve)} def decide_next(state: AgentState) - str: # 如果审核不过且修改轮数小于3则回到写作否则结束 if state[next_action] revision and state[revision_round] 3: return revision return end # 构建图 graph StateGraph(AgentState) graph.add_node(research, research_node) graph.add_node(analysis, analysis_node) graph.add_node(writing, writing_node) graph.add_node(review, review_node) graph.set_entry_point(research) graph.add_edge(research, analysis) graph.add_edge(analysis, writing) graph.add_edge(writing, review) graph.add_conditional_edges(review, decide_next, { revision: writing, end: END }) app graph.compile()这个图的核心在decide_next这个条件路由。审核节点输出review_report里面包含一个布尔字段needs_revision同时我维护了revision_round计数。每次审核不过状态里的revision_round自动加一我实际是在review_node里 1 的可以在返回 state 时更新。当轮数来到 3 还是不过强制结束。实际使用中你还可以给每个节点加interrupt_before或interrupt_after这需要在与用户交互的场景中使用。如果你的业务是半自动希望审核员审完后等人工确认再决定是否回退给写作者那用 LangGraph 的 human-in-the-loop 机制就非常合适——在review节点后加一个等待点人工在 Web UI 上确认后调用update_state继续执行。我最初的原型就是这么干的后续才改成全自动。5.2 关键实现细节上下文拼接与状态传递的坑在多个 Agent 串联时最容易被忽视的问题是上下文的累计膨胀。比如研究者输出的素材已经很长分析师输出的大纲也不短写作过程要把两者全部喂给 LLM加上写作过程的中间输出Token 消耗会非常大而且模型的处理效果也会随上下文变长而下降。我的解决方案是分阶段做上下文压缩。研究者输出给分析师前先做一次信息蒸馏把原始搜索文本片段压缩成每个论点到两三句话分析师的输出本来就已经是结构化精简内容写作节点只需要看分析师的框架不需要再看原始素材素材已经映射进了分析框架中。这样每个节点的输入都不会超过窗口的 70%。万一遇到超长分析报告我还会先让一个轻量模型做摘要压缩再送给写作者。另一个坑是状态字段的传递。如果不小心把某个大字段塞进每次返回的 state 里LangGraph 的存储和网络传输开销会让你觉得怎么这么慢。解决办法是在每个节点里只返回需要更新的字段不要返回你拿到的全量 state。比如writing_node不一定在输出里附带原始 research_data这个我在代码里没有返回后台其实只更新了draft字段。StateGraph 默认会做字段合并返回部分字段没问题。5.3 运行效果与输出对比我拿一个例子跑了完整流程主题是低空经济下游产业链分析。研究员检索了 6 条网页数据、从本地知识库摘取了 3 篇行业报告片段。分析师生成的主线是政策-基础设施-应用场景-商业模式的递进结构共 5 个章节。写作者生成了一篇约 3000 字的长文。审核员最终提出了 3 个逻辑衔接问题和 1 个数据来源缺失点系统自动回退给写作者修改了一轮第二轮通过。对比我把同一主题直接丢给单 Agent 写出的文章最大的不同是多智能体产物的结构明显更清晰论据更扎实且能明显看出上下文的一致性更好。单独 Agent 容易在一开始的 part 强调某事后面又出现矛盾表述。审核环节能抓住这类问题说明回环价值确实存在这是单轮生成很难做到的。6. 异常处理与调优实战记录6.1 常见的坑JSON 解析失败、循环过深、上下文溢出我把项目运行过程中遇到的高频问题整理成了一张速查表方便你对照排查问题现象根因解决方案研究员输出 JSON 解析失败模型输出了多余文字或 JSON 语法错误启用with_structured_output或加 few-shot 示例或设 temperature0系统陷入无意义的重写循环审核节点每次都能挑出新问题修改后又有新问题限制 revision_round 最大为 3审核节点要求优先报告阻断级问题次要问题合并上下文超长报错素材过大且未压缩在节点间传递摘要而非全文引入 Map-Reduce 方式对长文本分块处理子 Agent 输出符合格式但内涵空洞模型能力不足或 prompt 缺少具体约束在 prompt 中增加每个论点需包含具体数字或引用的要求提升到更强模型研究摘要中包含大量过期信息搜索引擎结果过旧未按时间过滤Tavily 搜索时设置days30参数本地数据源建立更新时间优先级循环过深的问题我这边实际踩过一次。因为审核员过于勤快把一些非常微小的措辞问题也报成 error写作者每次都要去改改了之后审核员又觉得新措辞有问题来回三四次还没完。后来我在审核员的 prompt 里明确要求它区分阻断问题和建议问题只有阻断问题才触发回退建议问题可以累积到最终报告中人工参考。这之后循环次数大幅降低。上下文溢出是另一个高频问题。研究阶段如果主题太宽泛搜索结果可能塞进去一大堆文本。超出窗口时最直接的解决手段是用一个小模型把原始素材按主题聚类并提取每个簇的 3 条要点把要点传给研究者。这样相当于在管线前段加了一个预处理器。虽然多了一步调用但能保证主链路的稳定性。如果你希望更省成本也可以采用文本分割策略只抽取与主题强相关的段落这一点和 RAG 的 chunk 策略类似。6.2 日志追踪与可视化调试LangGraph 自带一些调试工具我强烈建议你在开发阶段开启。最简单的用法是在编译后的图上调用app.get_graph().print_ast()它会打印出节点的拓扑结构方便确认条件边有没有连错。如果你需要细粒度观察每个节点的输入输出可以自定义一个简单的回调函数把每次节点调用的耗时、token 数、返回的状态片段打印到终端。这个我通常直接封装成一个装饰器def trace_node(name): def decorator(func): def wrapper(state): start time.time() result func(state) elapsed time.time() - start print(f[Trace] {name} 耗时 {elapsed:.2f}s) return result return wrapper return decorator有了 trace你可以快速定位是哪个节点最慢、哪次输出走了意外分支。我在调试审核回环的时候靠这个日志发现是next_action没有正确更新导致走了多次 end。还有一个非常实用的技巧把每个节点的中间结果保存到本地 JSON 文件。流程跑完后你把四个节点的输出打开对比马上就能看出是哪个角色没有正确理解上下文。这种“过程可视化”比只看最终结果要能更快暴露问题。6.3 成本控制与延迟优化建议多智能体跑一轮就是好几次大模型调用加在一起成本和延迟都不低。我实测完一轮四角色流程消耗约 2 万到 3 万 token耗时 1 到 2 分钟取决于模型。如果你想压成本可以从这几个角度动刀小的用轻量重的用强模型研究员可以用mini档位的模型审核员首次审核可以用中档模型如果出现疑似问题需要二次复核才用强模型确认。缓存研究结果同一主题如果之前跑过直接把研究数据缓存到本地磁盘或数据库不用每次重新搜索。我用的是简单的 JSON 文件缓存以主题 hash 为 key。并行化研究检索Tavily 搜索可以和本地向量库检索并行执行在异步环境里可以用asyncio.gather让两者同时进行而不是串行。这适合用 LangGraph 的异步节点版本延迟能显著降低。限制审核轮次最长只允许一次修订把 more strict 的责任放在第一次写作时。我后来在生产版本中把revision_round上限设为 1文章质量依然达标延迟却缩短了 30%。成本优化永远是个取舍游戏。关键是你需要定义可接受的质量下限。我的经验是只要分析师框架足够扎实写作者不太会跑偏审核压力也不大所以与其在审核上烧钱不如把分析节点做深做透。7. 经验总结与下一步扩展思路先说说我在这个项目上的整体心得。多智能体的系统思考方式与你写单 Agent 完全不同单 Agent 是在一个巨大的 prompt 里塞满所有指令而多智能体是把复杂任务拆成多个小而明确的子任务每个子任务由专门的智能体完成通过状态接口协作。这种设计带来的是更高的可控性和可解释性——你可以知道文章是哪个环节出问题了甚至可以单独替换某个智能体的实现。LangGraph 作为编排层真正发挥了图即流程的威力让之前手写状态机的复杂度被彻底降维。如果你准备把这个项目往下扩展我建议优先考虑这三条路都是我实际验证过或正在尝试的方向一是引入人的反馈作为节点。在分析节点和写作节点之间加一个人工评审接口。人类专家可以修改大纲或添加约束然后图继续往写作节点跑。LangGraph 的interrupt机制可以完美支持这个需求这样整个系统就不再是黑乎乎的全自动流水线而是人机协作的智能编审系统。二是把审核节点做成一个子图。单个审核员也许能力有限你可以把审核拆成事实核查员、逻辑检查员、风格检查员三个小 Agent每个专注一个方向通过子图并行执行汇总成审核报告。这相当于让审核节点也变成一个小型多智能体团队效果会更强。三是引入外部素材库做持续记忆。现在研究节点每次都要重新搜索如果有一个长期记忆模块把历次研究的关键结论沉淀下来下次研究同一主题时就能站在已有知识之上减少搜索成本也能让文章的前后连续性更强。老实说多智能体应用现在还在一个快速演进的阶段框架也在不断升级。但底层的思想——把任务拆解、让专业角色各自负责、通过状态流转协同——这些是不变的。希望这个项目的拆解能给你带来一些启发如果你也在搞类似的 Agent 团队遇到问题可以按我上面这些思路去排查大概率能帮你省下不少折腾的时间。最后留一个小建议先在单条链路上把每个节点的输入输出调通再考虑加搜索和缓存这些高级功能。别一上来就追求完备跑起来比跑完美重要得多。