Agent 开源项目全景解析（下）：LlamaIndex、Dify、FastGPT 与真实工程选型

上篇讨论的项目主要提供编程框架和 Agent Runtime。实际开发中还有另一类非常重要的开源项目，它们把知识库、RAG、工作流、工具、模型管理和应用发布进一步封装。LlamaIndex仍然保持较强的代码框架属性，Dify 与 FastGPT 已经形成可以直接部署和使用的 Agent 应用平台。

[一、LlamaIndex：从 RAG 走向数据驱动的 Agent](#一、LlamaIndex：从 RAG 走向数据驱动的 Agent)

[1. 数据仍然是 LlamaIndex 最鲜明的主线](#1. 数据仍然是 LlamaIndex 最鲜明的主线)

[2. AgentWorkflow 已经进入核心包](#2. AgentWorkflow 已经进入核心包)

[二、Dify：把 Agent 工程封装成可运行的平台](#二、Dify：把 Agent 工程封装成可运行的平台)

[1. Dify 的核心价值在于应用层封装](#1. Dify 的核心价值在于应用层封装)

[2. Dify 适合快速形成一个完整应用](#2. Dify 适合快速形成一个完整应用)

三、FastGPT：知识库与可视化工作流路线

[1. FastGPT 当前已经形成完整 Agent 构建平台](#1. FastGPT 当前已经形成完整 Agent 构建平台)

[2. Plugin 已经从主仓库进一步拆出](#2. Plugin 已经从主仓库进一步拆出)

四、八个项目到底应该怎么选

五、如果目的是学习源码，阅读顺序应该怎么安排

一、LlamaIndex：从 RAG 走向数据驱动的 Agent

1. 数据仍然是 LlamaIndex 最鲜明的主线

LlamaIndex 当前官方仓库把自身定位为面向 Agentic Application 的开源框架，同时长期保持文档解析、索引、Retriever、Reranker、Vector Store 和数据连接器方面的较强生态。当前正式 Release 为 0.14.23。该版本仍持续更新 Ingestion、Retriever、Multimodal Query Engine、Tool Calling 与 Workflow 等核心能力。

因此，当一个项目的核心复杂度来自企业文档、PDF、知识库、多数据源、复杂检索和回答引用时，LlamaIndex通常具有较高的研究价值。它把数据进入模型之前的过程拆得更细，开发者可以分别控制 Chunk、Metadata、Embedding、Retriever、Reranker、Query Engine 和 Agent。

2. AgentWorkflow 已经进入核心包

当前核心源码中存在：

复制代码

llama-index-core/
└── llama_index/core/agent/workflow/multi_agent_workflow.py

该文件直接包含 FunctionAgent、ReActAgent、Workflow、Context、Tool Call、Agent Handoff 等实现。源码中的 handoff() 会从 Context Store读取当前 Agent 和允许切换的 Agent，再决定控制权是否可以转交。

因此，LlamaIndex 今天已经具备完整的 Agent Workflow 能力 。它仍然特别适合数据密集型 Agent，例如文献研究、企业文档问答、知识分析和多数据源检索。

值得优先阅读：

复制代码

llama-index-core/llama_index/core/indices/base.py

llama-index-core/llama_index/core/agent/workflow/multi_agent_workflow.py

llama-index-core/llama_index/core/tools/tool_spec/base.py

官方来源：

复制代码

https://github.com/run-llama/llama_index
https://developers.llamaindex.ai/
https://github.com/run-llama/llama_index/releases

二、Dify：把 Agent 工程封装成可运行的平台

1. Dify 的核心价值在于应用层封装

Dify 当前已经把 Workflow、Agent、RAG、模型管理、Tool、插件、应用发布和运行日志放在统一平台内。对于需要快速搭建企业知识助手、内部工作流 Agent 或产品原型的团队，它可以大幅减少自己开发管理后台、工作流编辑器和模型配置系统的工作量。当前最新正式版本为 1.16.1，于 2026 年 7 月 28 日发布。

Dify 后端主体采用 Python，API 模块位于 api/。当前 Agent Workflow 源码已经组织在：

复制代码

api/core/workflow/nodes/agent/

知识检索节点位于：

复制代码

api/core/workflow/nodes/knowledge_retrieval/

实际打开 knowledge_retrieval_node.py 可以看到，节点会调用 Dataset Retrieval、Reranking，并通过 Graph Runtime 中的 Node 抽象参与工作流执行；Agent 目录中的 runtime_support.py 则负责模型实例、Memory、Tool Manager 和插件模型运行环境等支持逻辑。

2. Dify 适合快速形成一个完整应用

假设需要建设一个内部制度问答 Agent。自行开发时通常需要处理文件上传、解析、Embedding、Vector Store、检索、Prompt、模型配置、会话、用户界面、运行日志以及应用发布。Dify已经封装了其中相当一部分能力，开发工作可以更集中于业务知识和工作流设计。

Dify 当前 1.16.1 还加入 Knowledge Tracing，增强知识与 RAG 文档处理过程的可观测性，同时继续完善工作流运行和 Agent DSL 导出。

因此，Dify 很适合产品验证、内部 AI 应用平台和低代码 Agent 场景。需要深度定制 Runtime、状态调度或业务事务时，仍然需要进入其 Python 服务源码，或者把核心业务能力作为外部 Tool 提供给 Dify 调用。

官方来源：

复制代码

https://github.com/langgenius/dify
https://github.com/langgenius/dify/releases
https://github.com/langgenius/dify/tree/main/api/core/workflow
https://docs.dify.ai/

三、FastGPT：知识库与可视化工作流路线

1. FastGPT 当前已经形成完整 Agent 构建平台

FastGPT 官方将项目定义为 AI Agent 构建平台，提供数据处理、模型调用和 Flow 可视化工作流。当前 README 已明确列出 Agent Skill、对话工作流、插件工作流、双向 MCP、调用链日志、应用评测、知识库混合检索与重排，以及 Agent Loop 热更新等能力。最新稳定版本为 4.15.7，于 2026 年 8 月 7 日发布；4.16.0-beta1 当前仍属于预发布版本。

FastGPT 的主要代码采用 TypeScript。Workflow Runtime 的核心实现主要位于：

复制代码

packages/service/core/workflow/dispatch/

Agent 相关实现进一步位于：

复制代码

packages/service/core/workflow/dispatch/ai/agent/

Tool、HTTP、MCP、文件读取和代码执行也会继续沿 Workflow Dispatch 体系进入运行时。官方安全公告和 Issue 中可以直接看到这些真实源码路径，例如 packages/service/core/workflow/dispatch/tools/http468.ts 和 packages/service/core/workflow/dispatch/ai/agent/sub/tool/index.ts。

2. Plugin 已经从主仓库进一步拆出

FastGPT 还维护独立的 fastgpt-plugin 仓库，官方说明系统工具已经迁移到该仓库，扩展模块包括 System Tools、App Templates、RAG Algorithm、Agent Strategy 和 Third-party Integration。插件支持独立执行、热更新、版本管理和流式响应。

这种结构很适合需要自托管知识库、工作流和企业工具集成的项目。FastGPT 的 License 需要额外注意：官方允许作为其他应用的后台服务进行商业使用，但相似的多租户 SaaS 服务需要获得商业授权，控制台 Logo 和版权信息也有额外条件。涉及商业产品选型时应提前核对授权边界。

官方来源：

复制代码

https://github.com/labring/FastGPT
https://github.com/labring/FastGPT/releases
https://github.com/labring/fastgpt-plugin
https://doc.fastgpt.io/

四、项目选型

如果把前后两篇放到同一个工程视角中，可以得到一张比较实用的选型表。

需求	优先研究项目	原因
Spring Boot 接入 LLM	Spring AI	Java API、Tool、RAG、MCP 与 Spring 集成成熟
Java 状态工作流	Spring AI Alibaba	Graph、Checkpoint、HITL、Agent Framework
Python Agent 快速开发	LangChain	Agent 与 Tool 抽象完整，集成丰富
长任务与状态恢复	LangGraph	State、Checkpoint、Interrupt 是核心设计
学习 Agent Runtime	OpenAI Agents SDK	Runner、Session、Handoff、Guardrail 结构集中
文档与复杂 RAG	LlamaIndex	数据、索引、Retriever、Reranker 生态丰富
快速搭建 AI 产品	Dify	Workflow、Agent、RAG、UI 和发布平台完整
自托管知识库与工作流	FastGPT	知识库、Flow、插件和中文生态完整

这张表强调"哪个项目最适合研究某一类问题"。实际生产系统完全可能组合使用。例如 Java 后端继续使用 Spring Boot 和 Spring AI，复杂 Agent Workflow 使用 Spring AI Alibaba；独立文档处理服务采用 Python 与 LlamaIndex；运营人员再通过 Dify 或 FastGPT 配置部分业务工作流。框架的边界应由业务职责和维护成本决定。

五、如果目的是学习源码，阅读顺序应该怎么安排

源码学习不适合从八个仓库同时开始。更高效的路线是先掌握一个很小的 Agent Loop，然后逐步增加状态、Tool、Memory 和工作流。

第一阶段可以阅读 OpenAI Agents SDK 的 Agent 和 Runner，理解模型为什么会反复调用工具。第二阶段阅读 LangGraph StateGraph，理解任务为什么需要 State、Node、Edge 和 Checkpoint。Java 方向可以同步阅读 Spring AI 的 ChatClient 与 ToolCallingAdvisor，再进入 Spring AI Alibaba 的 StateGraph 和 ReactAgent。完成这些以后，再去看 Dify 或 FastGPT，会更容易理解可视化画布背后实际运行的节点、工具和状态。