前一段时间有个做产品经理的朋友跟我吐槽整天要花大把时间写PRD而且改来改去特别烦。当时我就琢磨能不能做一个自动生成PRD的工具。市面上虽然有不少大模型套壳应用但大多数就是单次对话让模型直接输出一版PRD痛点很明显文档结构不稳定、逻辑不连贯、缺少多维度审查只适合用来找灵感离能落地的标准差得远。直到后来我把通义千问Qwen和LangGraph组合起来做了一个多Agent协作的PRD自动生成系统才算是把这个问题真正解决了。这个项目的核心思路就是让几个不同角色的Agent一起协作来模拟一个完整产品团队的工作流。每个Agent负责一个环节有的负责梳理业务背景有的负责拆解功能需求有的负责画信息架构还有的负责评审挑毛病。通过LangGraph把这些Agent连接成有状态的工作流让上下文在各个Agent之间有序传递最终产出一份结构完整、逻辑自洽的PRD文档。这篇文章会完整拆解整个系统的设计与实现过程包括Agent的角色划分、LangGraph的图编排方案、提示词策略、结构化输出设计以及我在实际开发中踩过的坑和解决方案。如果你是AI应用开发者、产品经理或者正在研究多Agent协作方案这篇文章的内容应该能帮你在自己的场景里复现这套架构。1. 项目定位与整体设计思路先把这个项目到底在解决什么问题说清楚。市面上的AI写作PRD工具大多停留在你输入需求模型输出初稿这种单轮对话模式。试过的人都有体会第一次生成的内容通常会包含提纲挈领的部分但细节层次非常单薄往往缺少竞品分析、业务异常流、埋点规划这些产品经理真正在意的东西。我当时定下的设计目标是把PRD的生成过程改造成一条流水线不同环节由不同的Agent专门负责上一个Agent的输出作为下一个Agent的上下文输入。这样做的好处有三个第一是专业化分工。让一个模型同时扮演需求分析师和交互设计师的角色往往两头都不讨好。如果把角色拆开每个Agent只需要聚焦一个窄领域模型的输出质量会明显提升。这和人类团队的分工逻辑是一致的。第二是上下文的有序传递。PRD是一个长文档如果一次性让模型生成很容易写到后面忘了前面。多Agent流水线让每一段生成都有了明确的前置上下文比如功能拆解Agent必须基于业务背景Agent输出的产品定位来写就不会出现前后矛盾。第三是可插拔的评审机制。在关键节点插入评审Agent专门负责挑毛病被挑出的问题会以结构化意见的形式反馈给生成节点驱动修改。这个机制是单轮生成完全做不到的。选择通义千问作为大模型底座主要看中它两点一是中文语义理解能力在同类模型中处于第一梯队这直接关系到PRD中文表达的自然度二是它对函数调用和结构化输出的支持很完整方便我让Agent输出JSON来对接下游程序。而LangGraph负责的是编排层它把各个Agent看成图上的节点把Agent之间的信息传递看成边整个协作过程是一个有状态、可中断、可恢复的图流转这比简单的Chain链式调用要灵活得多也比较容易追踪和调试。LangGraph的另一个特性是内置了记忆持久化。PRD生成过程中业务背景、功能清单、评审意见这些中间状态都需要被保存LangGraph的State机制天然支持这种需求每个节点都可以读写共享状态。这样整个系统就不再是无状态地调API而是一个有记忆的协作系统。2. 多Agent协作架构拆解一个好的多Agent系统设计Agent角色时不能拍脑袋得先想清楚PRD生成到底需要哪些能力。我复盘了整个PRD写作流程最终确定了五个角色策划Agent、分析Agent、架构Agent、填充Agent和评审Agent。2.1 五个Agent的角色定位与职责边界策划Agent负责业务背景分析。它接收用户的原始输入比如一句话产品想法、目标用户描述、业务限制条件然后输出产品定位、目标用户画像和核心价值主张。这个Agent的输出质量非常关键因为后面所有环节都建立在这个既定方向上。分析Agent负责竞品分析和差异化。这里我会让它基于策划Agent输出的产品定位去输出竞品格局、核心竞品功能对比、以及这个产品可能的差异化切入点。它输出的内容不一定非常翔实重点是让后续的功能设计有参照系。架构Agent负责信息架构和功能模块拆解。它会输出产品的功能模块列表、每个模块下面的核心功能点以及模块之间的依赖关系。这是一个承上启下的环节相当于把PRD的骨架搭出来。填充Agent负责具体的PRD条目撰写。根据架构Agent输出的功能清单逐个功能写出完整的需求描述包括功能说明、业务规则、交互细节、异常处理。因为功能点比较多这个节点会循环执行多次每次处理一个功能模块。评审Agent负责质量评审。它会在关键节点介入按照我预设的PRD质量标准检查前面几个Agent的输出是否有遗漏、逻辑漏洞、需求模糊等问题然后输出结构化评审意见送回到对应节点进行修正。这里要特别说一下Agent不是越多越好。我最初设计过七个Agent多了一个数据模型Agent专门设计数据库表结构但跑了几轮之后发现这一块对普通PRD来说有点过度设计了只有纯后台系统类的产品才需要。后来我把这个Agent从主流程里摘除改为按需加入的旁路节点整体效率和结果质量都合理了。2.2 LangGraph中的图编排方案LangGraph的核心是有状态图。在代码层面我需要定义一个状态对象它贯穿整个图执行周期。状态对象的数据结构是典型的字典类型包含了原始需求、产品定位、竞品分析、架构拆解、PRD正文、评审意见这些元素。图本身的流转逻辑是这样的用户输入进入策划Agent节点产出产品定位写入状态状态流转到分析Agent节点产出竞品分析写入状态再流转到架构Agent节点产出功能模块清单写入状态进入填充Agent节点前需要做一个条件判断决定是继续填写下一个功能模块还是所有模块填写完毕填充完成后进入评审Agent节点如果评审通过则直接结束不通过则根据评审意见回到对应节点进行修正这段逻辑用文字描述比较抽象我用LangGraph代码来展示核心的图结构定义。实际开发中图的构建和使用并不复杂关键是把逻辑分支理清。以LangGraph的经典写法代码大致是这样的from langgraph.graph import StateGraph, END # 定义状态对象结构 class PRDState(TypedDict): user_input: str # 用户原始输入 product_position: str # 产品定位 competitor_analysis: str # 竞品分析 module_structure: str # 功能模块结构 prd_sections: list # 已生成的PRD段落列表 review_result: str # 评审结果 revision_round: int # 迭代轮次 # 构建状态图 graph StateGraph(PRDState) # 添加节点 graph.add_node(planner, planner_agent) graph.add_node(analyst, analyst_agent) graph.add_node(architect, architect_agent) graph.add_node(writer, writer_agent) graph.add_node(reviewer, reviewer_agent) # 添加边主线流程 graph.add_edge(planner, analyst) graph.add_edge(analyst, architect) graph.add_edge(architect, writer) graph.add_edge(writer, reviewer) # 条件路由评审通过则结束否则根据意见返回 graph.add_conditional_edges( reviewer, should_revise, { revise_planner: planner, revise_architect: architect, revise_writer: writer, end: END } ) graph.set_entry_point(planner) app graph.compile()这里的should_revise是一个路由函数它读取review_result字段中的评审意见判断本次需要返工的角色返回对应的keyLangGraph会根据这个key自动流转到适当节点。这种状态机式的编排方式让整个流程表现得非常可控也方便每轮人工介入。2.3 为什么用LangGraph而不是其他编排方式我团队之前也尝试过用简单的LangChain Sequential Chain来实现这种协作效果并不理想。原因在于Sequential Chain本质上是一条直线的调用序列很难表达条件分支和循环回流评审不通过要回炉这种需求需要在代码层级做很多额外的hack。如果是直接用裸代码编排本质上是写一堆if-else调用大模型代码会层层嵌套维护成本极高。LangGraph把这些编排逻辑提升为图结构节点之间是显式声明的边条件分支用路由函数来表达。图中任何一个节点都可以访问共享状态这意味着任何Agent都能看到前面所有Agent产出的内容。这种设计还有一个隐性的好处就是当图运行到某一步卡住时我可以非常直观地定位到是哪个节点的问题调试体验比看一堆链条日志要愉快很多。3. 通义千问模型选型与提示词策略3.1 模型选型的具体考量通义千问目前提供了多个尺寸和定位不同的模型。我在这套系统里主用qwen-plus作为生成模型原因有几个方面要展开说一下。第一是上下文窗口长度。一个PRD文档动辄上万字加上前面各环节的中间输出整张状态对象的内容会对上下文占用有要求。qwen-plus的上下文窗口足够容纳这轮协作过程中的完整信息这点在实际测试中表现稳定。第二是结构化输出的稳定性。我的Agent需要输出JSON格式的数据方便程序解析。之前试过一些开源模型让它们输出JSON很容易在生成中插入多余文字导致解析失败。qwen系列模型在系统提示里明确指定JSON输出时生成结果通常会保持JSON规范格式这对要跑自动化流程的场景来说很重要。第三是工具调用能力。LangGraph节点在实现时会有参数解析的需求Agent需要按照预定义的工具格式生成结构化调用请求。qwen系列对工具调用的支持属于成熟梯队返回的格式错误率比较低。如果你想要完全本地化部署也可以考虑用qwen系列开源模型比如通过量化和推理框架部署在单卡上。对于数据敏感的内部使用场景这是一个合理选项但模型的推理速度和输出质量会弱于云端API版本我建议在实际适用前做一轮针对PRD语料的质量评测。3.2 各Agent的提示词模板设计细节提示词是所有Agent行为的核心。我的提示词设计原则是给角色、给流程、给输出格式、给质量标准而不是只给一个笼统的任务描述。拿架构Agent的提示词举个例子。它的系统提示语大致是这样组织的你是一名资深产品架构师负责把产品定位和竞品分析转化为清晰的功能模块结构。 你输出的模块结构将直接作为后续PRD详细编写的依据。 请遵循以下要求 1. 划分功能模块时遵循MECE原则模块之间避免重叠 2. 每个模块用一句话说明核心职责 3. 每个功能点需要标注优先级P0必须/P1建议/P2可选 4. 功能描述必须完整包含主流程、分支流程和异常流说明 输出格式为JSON字段结构如下 { modules: [ { module_name: 模块名称, module_desc: 模块职责描述, features: [ { feature_name: 功能名称, feature_desc: 功能描述, priority: P0 } ] } ] }注意这里有一个很关键的细节每个Agent的提示词里都会明确写上你输出的内容会被哪个下游角色使用以及使用方式来指导生成重点。这种上下游感知能显著提升输出对最终目标的适配度。填充Agent的系统提示词里甚至嵌入了评审Agent的评分标准让它在写需求时就知道哪些点会被检查这也让你的整体流程多了一层内建质量约束。3.3 结构化输出的设计与解析方案PRD生成过程中需要频繁地和JSON打交道。为了让解析环节更省心我做了三件事。第一是统一输出协议。我在所有Agent提示词的输出格式部分约定了一套基础字段规范内容项文本、数据属性、修改标记、确定性等级。改动标记用来标注这个条目是新增内容还是修正内容确定性等级用来标记模型对这条内容的把握程度方便后期人工复核。第二是解析容错方案。尽管qwen的JSON输出很规范但在实际运行中偶尔还是会出现JSON被截断的情况。我的方案是在解析层做多层兜底第一层用严格的JSON解析器和schema校验如果解析失败就用正则提取代码块中的内容再二次尝试解析如果还是失败就把这个节点的输出标记为格式异常走人工修订流程而不是让整个图崩溃。第三是Schema校验。解析出的JSON会立即用预定义好的数据Schema做结构校验。这里我用了Pydantic模型来定义每个环节的输出结构。校验不通过同样会把问题返回给对应节点让它重新生成。这个机制极大程度上减少了结构化数据项内容的无效传输和后续处理时的类型错误。4. 实操过程与核心实现4.1 环境准备与依赖安装开发这套系统时我建议在一个干净的虚拟环境里操作。项目依赖相对简单主要包括几个Python库LangGraph作为编排框架通义千问的Python SDK用于模型调用以及用于结构化输出的Pydantic和相关工具库。依赖安装指令大致如下pip install langgraph qwen-api-sdk pydantic python-dotenv环境变量这里要单独设置一个API密钥我在项目根目录创建一个.env文件写入密钥配置信息。这里有个经验不要在代码里硬编码密钥因为一旦代码分享出去或者推到远端仓库密钥就暴露了实际项目里出过这种事教训比较深刻。4.2 搭建基础模型调用层模型调用层封装了所有通义千问的通信逻辑。核心是两个函数一个负责普通文本对话补全一个负责结构化输出解析。基础调用函数的实现思路是先读取模型名称、温度和最大Token数这几个核心参数然后调用API接口获取返回文本。结构化输出函数则是在普通调用基础上额外指定了系统提示中输出JSON格式的要求并加上了我在前面说的多层解析兜底。这个抽象层让后面每个Agent的实现变得干净Agent节点不需要关心底层的API差异。这里分享我当时调试中对温度参数的踩坑过程。最初我让填充Agent用默认温度值结果生成的PRD文本非常发散每轮跑出来的写法差异很大。后来经过多次调整我把大部分生成节点的温度调低到一个比较保守的档位而把评审Agent的温度维持在稍高一些让它能更有想象力地发现问题修改Agent的温度也调到较低档位避免大幅改写原有的语义表达。效果对比下来确实稳定了不少。温度参数的调优不是一个死参数而要根据Agent职责属性来定。4.3 构建状态对象的节点函数每个Agent在LangGraph里其实就是接收当前状态、返回更新状态的一个纯函数。我用填充Agent的实现来说明这种节点的写法因为它的逻辑涵盖了格式化组装、调用模型、解析结果的全过程。填充Agent的简化代码结构大致是这样的def writer_agent(state: PRDState): # 获取当前待处理的功能模块 remaining_modules state[module_structure][modules] current_module remaining_modules[state[current_module_index]] # 组装提示词包含业务背景、竞品分析、当前模块结构 prompt build_writer_prompt( state[product_position], state[competitor_analysis], current_module ) # 调用qwen模型获取该模块的PRD正文 response call_qwen_structured( system_promptprompt[system], user_promptprompt[user], schemaFeaturePRDSchema ) # 更新状态添加新生成的PRD段落推进模块索引 return { prd_sections: state[prd_sections] [response], current_module_index: state[current_module_index] 1 }这段代码的核心思路是每个Agent节点做的事情是从状态拿输入、组装提示词、调用模型、解析结果、更新状态。并且因为它是一个纯函数方便你单独把每个Agent拉出来做单元测试大大降低了调试复杂度。4.4 实现多轮修正流程多轮修正机制是系统的一个核心特色。这个能力让PRD生成过程具备了自我迭代的属性也是跟单轮Prompt生成拉开差距的地方。评审Agent的职责按照四个维度来验收PRD业务完整性、功能逻辑自洽性、异常流覆盖度、表达明确性。它输出一个结构化评审结果大体字段包括整体结论做过的验证项发现的关键问题清单每个问题关联的功能模块以及修改意见。这个结果会被路由函数读取决定流向哪个Agent进行修正。修正流程设计时我加了一个最大迭代轮次限制防止系统在极端情况陷入无限循环。我设置了评审通过条件如果关键问题数量为零或者连续两轮评审意见重复率过高都会结束流程避免不需要的重复调用。连续意见重复率检测这个细节逻辑也比较简单就是把上轮评审意见与当前轮做文本相似度对比超过一定阈值就认为进入了循环。4.5 主流程执行与运行监控系统主流程的执行入口我设计成接收两个参数产品名称和原始需求描述。入口函数创建一个初始状态字典然后调用编译好的LangGraph应用执行。执行过程中LangGraph提供了逐步日志回放的能力。我可以在开发模式下打开调试开关实时看到每个节点的执行顺序、耗时和状态变化。对于生产环境我把执行日志写入一个队列系统方便后续分析每个Agent的调用占比和响应耗间做性能优化时看数据会更有依据。系统的可观测性不仅对开发者有意义对产品验收也很有用。产品经理可以从执行日志里看到哪个Agent在哪个环节做了哪些决策这在评审PRD质量时提供了决策依据层面的透明性。5. 常见问题与排查技巧实录多Agent系统的调试经验和单Agent应用很不一样问题往往不是模型能力导致的而是出在流程编排、状态管理和输出格式这些环节。我实际运行过程中积累了一些典型问题可以整理成一份速查手册。5.1 输出信息在Agent之间传递时丢失这个问题在多轮修正流程中最常见。最初我把评审Agent的修改意见作为独立字段写入状态传给被修正节点但是被修正节点在重新生成时并没有把上一版内容作为上下文带入结果修改后输出反而丢失了原来正确的部分整体内容甚至没有原来那么完整。排查思路是检查状态对象中每个节点的输入依赖。修正节点重新运行时不能只依赖评审意见还需要把上一轮生成的内容原文作为一个信息源读取进来让模型在原有基础上做增量修改。修复后我在状态里保留了原始版本、修改意见和修改后版本三个字段一方面保证模型有足够上下文另一方面也方便做版本对比。5.2 结构化输出频繁出现解析失败Qwen模型在多数情况下能保持JSON输出格式规范但在输出较长内容时偶尔还是会出现截断或者JSON的末尾被中断。最初遇到这种情况整个流程会直接抛出解析异常让多轮协作终止。我的解决方案是双层容灾。第一层在调用结构化输出函数时把输出的Token上限留足余量。比如原本预计该条内容需要1000个token我会把上限设置为更宽裕的数值给模型足够的生成空间。第二层在解析失败时启动修复流程对返回文本做截断裁剪补全缺失的括号试图恢复成合法JSON只有修复失败才请求重生成。这套方案让系统的异常率从最初某个较高比例下降到了极低的零散水平。5.3 Agent之间上下文不一致在早期版本中我发现架构Agent输出的模块数量是六个但是填充Agent最终只生成了四个模块的PRD另外两个模块被静默跳过了。原因是填充Agent的循环退出条件没有对齐架构Agent的模块总数索引这个属于典型的逻辑边界问题。排查时我通过状态对象的可视化回放立刻看到了循环退出的定位逻辑不准确。修复方式是在路由函数里增加一个显式判断如果当前模块索引小于总模块数说明还有未完成的功能模块继续进入填充节点否则才进入评审节点。看似简单的边界修正背后涉及的是状态机Graph里数据结构在流转中的一致性维护这个思路值得留意。排查技巧梳理跨Agent信息流时先核对每个节点对下游节点做了何种假定再检查这个假定在流程中是否被遵守这类偏差在议程集成式Agent里尤为隐蔽。5.4 生成文本的迭代质量异常还有一种现象是经过多轮修正之后PRD的篇幅不增反降内容越来越浓缩重要的细节在修正过程中被裁剪掉了。这是因为修正节点面对大量上下文时模型会出现过度概括的倾向。我在修正节点的提示词中加了一条强制约束指示模型仅修正评审意见里有问题的部分未涉及到的内容必须逐字保留不得删改。这个方法让多轮修正从重写模式切换到精准补丁模式内容完整性的保持效果好多了。如果你想复现这套系统这个提示词细节值得直接引过去用。6. 效果评估与实际使用建议系统构建完成后我对它的实际效果做了一轮对比测试。我用同一份原始需求分别跑通了单轮直接生成和多Agent协作生成两种路径对比结果差异很明显。单轮直接生成的问题是结构基本完整但内容深度不足。比如某个核心功能的业务规则只写了一句话谈不上异常流描述竞品分析也只是泛泛的套话。这显然不够支撑开发排期用。多Agent协作生成的版本业务规则描述详细包含了完整的主流程和异常流评审Agent还真的挑出了一个逻辑矛盾前端展示的某个状态在后台数据流中没有对应的处理逻辑。这种问题是单轮生成难捕捉到的因为产生该问题的上下文分散在两个不同的Agent输出里只有评审Agent站在全局视角才能发现。结合这套项目经验我总结了几条使用建议。如果只是想快速产出PRD初稿单轮生成足够但如果你想产出接近人工编写质量、能直接拿给开发和测试阅读的PRD多Agent协作方案的价值就会体现得很明显。实际使用时不太建议直接全自动生成后不经过人工审核。最合理的流程是让系统自动产出完整草稿然后产品经理把精力集中在评审意见和关键决策环节的人工确认上生产效率会高不少。这套架构的可迁移性也很强换个提示词和状态字段就可以把同样的流程迁移到其他岗位角色的文档生成场景比如技术方案设计、运营活动策划、数据分析报告。多Agent协作本质上是把复杂任务拆解成多个专业视角的协作生产在文档生成这个大类下它的价值是有示范性的。我实际测试过程中多次看到评审Agent能发现一些容易忽略的需求漏洞这种全局质量兜底是这套架构给我留下最深印象的地方。