前言

在售前工作中，一份完整方案书往往需要多个角色的紧密配合：需求分析师梳理痛点，方案架构师设计技术方案，技术评审员把关风险。但现实中，这个流程常常因为沟通成本高、人员协调难而效率低下。于是我想：能否用 AI 模拟一个真实的售前团队？

在上一篇文章中，我分享了如何从零搭建一个多文档 RAG 问答系统。这次我更进一步：用 LangGraph 编排三个 AI Agent，让它们像一个微型售前团队那样协作，输入一句话客户需求，自动输出一份包含需求分析、技术方案和技术评审的完整方案书。更有趣的是，我加入了一个循环评审机制——评审不通过就自动修改，直到满意为止。

项目代码已开源，文末有 GitHub 链接和演示 GIF。

为什么需要多 Agent 协作

真实售前工作中，方案产出至少要经历三个角色：

1. 需求分析师：把客户的模糊描述转化为结构化的需求分析，明确行业背景、核心痛点和关键功能。
2. 方案架构师：基于需求设计技术方案，包括总体架构、功能模块、技术栈选型、部署建议和实施路径。
3. 技术评审员：以“挑刺儿”的视角评估方案可行性，指出风险并给出改进建议。

每个角色都有自己的专业视角和思维框架。如果让一个通用大模型“一锅端”地输出方案，往往缺乏深度，也容易遗漏关键细节。而多 Agent 协作可以模拟真实的专业分工，让每个 Agent 只聚焦自己的任务，再通过编排让它们高效配合，最终产出的方案书质量会高出一截。

技术选型：为什么选 LangGraph

在 LangChain 生态里，简单链式调用用 LCEL 很方便，但一遇到条件分支和循环就吃力了。LangGraph 则是专门为多 Agent 状态管理而生的框架，它用三个核心概念构建工作流：

• State：一个共享的数据字典，在 Agent 之间传递，相当于团队公用的“黑板”。
• Node：一个处理函数，接收 State，返回更新后的 State，对应一个 Agent 或处理步骤。
• Edge：连接节点的有向边，决定执行顺序。特别的是，**Conditional Edge（条件边）**可以根据上一个节点的输出动态选择下一个节点——这正是实现循环评审的关键。

LangGraph 让复杂协作流程变得直观可控，非常适合做“有决策逻辑的 Agent 编排”。

系统架构

三个 Agent 的协作流程设计如下：

用户需求（一句话）
    ↓
[Agent 1] 需求分析师 → 六维需求分析报告
    ↓
[Agent 2] 方案架构师 → 技术方案（含架构/模块/技术栈/实施路径）
    ↓
[Agent 3] 技术评审员 → 评审报告（含风险评估和改进建议）
    ↓
评审是否通过？
    ├─ 是 → 整合生成完整方案书
    └─ 否 → 返回 Agent 2 修改方案（最多迭代 3 轮）

这是一个带有反馈环的线性流程，模拟了真实团队“写方案→评审→修改→再评审”的迭代过程。

关键实现细节

1. 三个 Agent 的角色定义

每个 Agent 都有独立的 System Prompt，严格约束输出格式。例如需求分析师会按照“客户背景与行业”、“核心痛点与业务目标”、“关键功能需求”等六个维度输出结构化分析。方案架构师则需要输出总体架构、核心功能模块、推荐技术栈、部署建议、实施路径和成本估算六个部分。技术评审员同样有明确的评审维度：总体评价、可行性评估、风险点识别、改进建议、是否通过。

这种模板化的输出约束，一方面保证了下游 Agent 能接收到结构化信息，另一方面也让最终方案书具备专业文档的规范性。

2. 循环评审机制

这是整个系统最有特色的设计。技术评审员不仅给出评审意见，还会在自然语言中表达“通过/不通过”的结论。LangGraph 的条件边会根据这个结论决定下一步：

• 通过 → 进入方案书整合节点。
• 不通过 → 方案架构师收到上一轮的评审意见，重新设计并再次提交评审。

同时设置最大迭代次数（3 轮），防止无限循环。这个机制让系统具备了“自我修正”的能力，产出的方案会经过一轮或多轮打磨，质量更有保障。

3. 方案书自动整合

三个 Agent 的输出最终会流经一个整合节点，自动拼接为一份包含封面、目录、各章节的 Markdown 方案书。封面提取了项目名称和生成时间，目录支持锚点跳转，末尾还附上“仅供参考，需人工复核”的免责声明，体现专业度。

我踩过的坑

1. 条件边的返回值必须精确匹配映射表：LangGraph 的 add_conditional_edges 要求条件函数返回的字符串必须存在于映射字典中，否则直接报错。这一点在官方文档中不够醒目，调试时花了不少时间。
2. 手动编排优于编译执行：最初我用 graph.compile().invoke() 运行，但遇到 State 字段丢失问题。后来改用手动调用节点 + dict.update() 累积状态，反而更灵活可控，也方便在 Streamlit 中传递状态回调。
3. 评审结论的解析：评审员输出的是自然语言，判断“通过/不通过”需要简单的规则匹配。实际生产环境中，最好要求评审员输出 JSON 格式，可以避免误判。

成果展示

• 🖥️ Web 界面：Streamlit 构建，输入需求 → 一键生成方案书，生成过程中展示各 Agent 的执行状态。

• 🔄 循环评审：评审不通过时自动迭代修改，提高方案质量。

• 🎬 演示 GIF：https://github.com/Chris2ai/sales-architect/blob/main/demo.gif

• 📂 GitHub 仓库：https://github.com/Chris2ai/sales-architect

写在最后

这个项目从定义第一个 System Prompt 到完整的多 Agent 协作系统跑通，我最大的感受是：多 Agent 的难点不在于单个 Agent 的能力有多强，而在于如何设计它们之间的协作规则。LangGraph 用一张有向图把这个复杂问题变得直观可控，非常值得每一位 AI 应用开发者尝试。

如果这个项目对你有启发，欢迎 Star ⭐，一起交流！