用 LangGraph 的 StateGraph 搭建一个多 Agent 文档分析流水线：
用户问题
↓
Supervisor（拆解 → 路由 → 聚合）
├── Retriever: 检索文档（条件边：不充分→改写重查）
├── Analyst: 分析整理（条件边：缺数据→回Retriever）
└── Quality: 验证质量（条件边：不通过→回Analyst）
↓
最终回答
为什么选这个场景： RAG + 多步推理是 Agent 落地最通用的模式，覆盖 80% 的企业需求。同时有明确的条件判断点，适合验证 StateGraph 的条件边能力。
技术栈： LangGraph + LangChain + ChromaDB（本地向量库，不需外部 API）
方案设计
4 节点 StateGraph：Supervisor 入口 → Retriever（带条件边重查）→ Analyst（带条件边回查）→ Quality（验证）→ 输出。完整图结构：
supervisor → retriever → analyst → quality
↑ ↓
└────── retry ─────────────┘环境搭建
已安装 LangGraph 1.2.8 + LangChain + ChromaDB。源码位于 /root/langgraph-demo/main.py。
运行验证
[Supervisor] 收到问题: LangGraph 和 LangChain 有什么区别？
[Supervisor] 拆解任务：需要检索文档、分析内容、验证结果
[Retriever] 检索到 2 篇文档 (第 1 次)
[Analyst] 分析完成
[Quality] ✅ 验证通过
最终结果: 基于 2 篇文档的综合分析图结构完整，Supervisor → Retriever → Analyst → Quality 一条线走通，Quality 验证通过后正常结束。注意当前还没接真实 LLM，用的是模拟数据——明天 Day 2 把 ChromaDB 和真实检索接上。
向量化引擎
自行实现基于 ONNX + HuggingFace tokenizer 的嵌入引擎，384 维向量，mean pooling + L2 归一化，纯本地推理无需外部 API。
ChromaDB 集成与替代
尝试集成 ChromaDB 但 API 大版本不兼容，改为纯 NumPy 内存向量检索。对 Demo 阶段效率更高，生产环境继续用 Chroma 或 Milvus。
流水线完成
5 个节点的 StateGraph 全部跑通：Supervisor → Retriever（带条件边 Rewrite）→ Analyst → Quality（带重试循环）→ END。10 篇知识库文档的索引和检索功能正常。
待优化： 检索质量需要微调——当前 embedding 对短文本的区分度不够，所有查询返回结果趋同。计划优化 chunk 策略或在对比文章里作为对比项讨论。
已发布对比文章：LangGraph 实战总结——图编排 vs 手工调度
核心结论：不是替代关系，是互补关系。对话/交互场景用 delegate_task，管道/批处理场景用 LangGraph StateGraph。
完整项目代码：/root/langgraph-demo/（阿里云服务器本地）
输入一个问题，观察 LangGraph 多 Agent 流水线一步步执行 →
打开体验台| 时间 | 更新内容 |
|---|---|
| 2026.07.08 | 创建文章框架，开始 Day 1 环境搭建 |
💬 评论