我用 LangGraph、Celery 和 MCP 构建了一个容器化的多智能体研究管线 [P]

我想分享一个最近开源项目的架构：Multi-Agent Research & Report Generator（多智能体研究与报告生成器）。我的目标是构建一个生产级系统，它能够接收复杂的用户提示，将其拆解为结构化的子主题，自主收集文献，对自身发现进行批判性评估，并最终编排出一份精美的 Markdown 报告。将 agentic LLM 工作流从线性 Python 脚本迁移到健壮的分布式 Web 应用，需要大量工作。下面是对该架构的解析，以及仓库中各组件如何协同工作。 ## AI 引擎与 Agent 图 应用的核心是基于 LangGraph 构建的四阶段状态机： * **Planner（规划器）**：将核心问题拆解为 3–5 个具体的子主题。 * **Researcher（研究员）**：使用外部工具为每个子主题采集数据。 * **Critic（评审器）**：从覆盖面、准确性和深度三个维度评估草稿（打分 0–5 分）。如果得分低于 3 分，则触发条件循环，将明确的反馈注入提示中，回退到 Researcher（最多重试 3 次）。 * **Writer（撰写器）**：将通过审核的研究笔记转化为格式化的执行摘要。 ## 协议隔离的工具调用（MCP） 为了保持 Agent 的模块化，我没有将 API 爬虫硬编码到 Agent 逻辑中。相反，我实现了一个自定义的 Model Context Protocol（MCP）服务器，通过 stdio 运行。它以标准化的工具调用接口，安全地向 Researcher Agent 暴露了 web_search（DuckDuckGo）、arxiv_search 和 semantic_scholar_search 等工具。 ## 分布式微服务架构 同步运行高延迟的 LLM 循环是导致 HTTP 超时的典型做法。我将任务接收与后台执行完全解耦： * **FastAPI 网关**：接收用户提示后立即返回 task_id 和 202 Accepted 状态，不占用 HTTP 连接。 * **Redis Broker 与 Celery Worker**：FastAPI 网关将任务推入 Redis 队列。通过水平扩展的 Celery Worker 集群（`--scale worker=4`）持续从 broker 拉取任务，在后台启动隔离的 LangGraph 执行循环。 ## 持久化状态检查点 对于分布式管线来说，内存中的状态管理过于脆弱。我使用 LangGraph 的 AsyncPostgresSaver（基于 PostgreSQL）异步配置了状态快照和线程恢复。这确保了多轮对话上下文和工具输出能够在服务重启后存活，并支持细粒度的任务恢复。 ## 前端与遥测 在用户界面方面，我构建了一个简洁的 Streamlit 前端。当 Celery Worker 完成 LangGraph 管线的处理后，前端从后端解析最终的 JSON 负载，渲染格式化的 Markdown 报告，并展示 Agent 的遥测指标（例如经历的迭代循环次数和最终评审得分），然后提供 .md 文件下载。 ## TL;DR 我使用 LangGraph、FastAPI、Celery、Redis、PostgreSQL 和 Streamlit 构建了一个异步、容器化的多智能体研究平台。它利用评审器把关的重试循环来减少幻觉，通过 MCP 执行工具调用，并借助分布式 Celery 队列处理高并发。所有组件都已通过 Docker Compose 完容器化。 仓库链接：https://github.com/theallkeeeymist/multi-agent-researcher-report-generator 期待你的反馈！这是我在扩展 AI 工作流方面一次巨大的学习经历，但我知道永远有改进的空间。为了让这个架构更加健壮以适应生产环境，我还能做什么？处理队列是否有其他替代模式？在多个 Worker 之间管理 LangGraph 状态是否有更好的方式？是否有我应该提前规划的特定故障模式？很想听听你的想法！