2025年 Agent 开发框架选型&实战笔记

不二小段

发布于 2026-04-09 16:37:27

2410

今年的 AI 领域，Agent 已经成为了绝对的主角，大家言必谈智能体，行必做工作流。我最近花了亿点时间，把自己学习、使用过的 Agent 开发框架整理为这篇笔记，大体上分为「代码开发框架」和「低代码工作流平台」两大类。并详细记述了我的一个实战案例，综合使用 RAG、text2SQL 实现了对影视飓风创作内容、数据的问答，希望能给大家提供参考，带来帮助。

吴恩达老师最近有个观点，说开发 AI 应用就像搭积木一样，生成式 AI 应用工程师手中掌握的技术栈越丰富，就好比拥有了不同形状各异、功能独特的积木块。只有手里的积木足够多，才能组合、搭建出更精巧的设计。

AI Agent 开发可以说是生成式 AI 应用开发的终极目标，其技术工具箱几乎涵盖了所有方面，比如模型训练、微调、部署、调用，比如综合运用 Prompt/Context 工程、RAG 技术实现规划、知识库、记忆机制，以及 Function call、MCP、Computer use 等工具使用。

作为开发者，我们当然想要掌控所有这些「积木块」，但说实话，想要既懂理论（know-why），又懂实践（know-how）太难了，一方面每个领域都有艰深的技术细节，另一方面学习的速度赶不上技术迭代。在实际工作中，一个好用的开发者框架，就像一套「乐高套装」，将复杂的底层逻辑封装成简洁易用的模块，通过标准化的流程和接口，简化开发工作，降低学习成本，让我们能够专注于业务，而非具体的工程细节。

接下来记录一下我了解过的 Agent 开发框架和低代码平台，然后从零到一实操一个完整的案例。

主流 Agent 框架/平台综述

现在主流的 Agent 开发工具大体分为两类，一类是面向程序员的开源开发框架，为专业开发者提供丰富的 AI 工具箱，对底层细节有更多控制，可以开发复杂 AI 应用；另一类则是低代码/无代码平台，通过可视化界面、拖拉拽组件的方式赋予业务人员快速搭建工作流能力。

这些框架大都是 2023 年 ChatGPT 火起来之后出现的，现在仍然有源源不断的新框架、新平台在出现，在此列举一些比较主流的选择。

开源开发框架

这类框架秉持代码优先原则，面向追求高度定制化和灵活性的专业开发者，通过编写代码来定义和构建 Agent 的核心逻辑。

LangChain / LangGraph

LangChain 以其「链」的概念，将 LLM 应用的各个组件（模型、提示词、数据）模块化地串联起来，降低了早期开发的门槛。LangChain 可以说是 Agent 领域的「瑞士军刀」，功能全面，生态成熟，拥有庞大的社区和丰富的集成。

但是，LangChain 也存在功能臃肿和过度抽象的问题，在生产环境中进行深度定制和调试十分复杂。而且其线性、无状态链式结构在处理需要循环、条件判断和多智能体协作的复杂任务时显得力不从心。

因此 LangChain 团队之后推出了 LangGraph，转向了更灵活的状态图模型，将应用工作流构建为有状态的图来解决链式结构的局限性。

LlamaIndex

LlamaIndex 和 Langchain 的功能重叠度比较高，早期的 LlamaIndex 相对专注于数据，在数据摄取、索引、复杂文档解析和检索策略方面表现优秀，所以也有人选择把 LlamaIndex 和其他框架组合使用。

AutoGen

由微软研究院推出，主打 Multi-Agent 协作。通过让智能体之间灵活的对话来协同解决问题。AutoGen 在动态交互和强大的代码执行能力上具有优势，更适合解决方案路径未知、需要通过探索和涌现来找到答案，偏向于研究型或复杂问题场景。

CrewAI

专注于多 Agent 协作，核心理念是将智能体组织成一个有明确角色、目标和工具的「团队」（Crew），通过结构化的角色扮演模式，自动化已知或流程相对可控的业务任务。

Pydantic AI

Pydantic 是一个常用的数据验证库，Pydantic AI 则将 Pydantic 强大的数据验证和类型安全能力引入 AI Agnet 开发，强制LLM的输入输出遵循可靠的结构化格式，并支持将验证错误反馈给 LLM 进行自我修正，提升AI 应用的稳定性和可维护性。

LazyLLM

上面提到的框架都是国外的，我也一直在找国内有没有好用的框架，偶然发现了这么一款非常好用的应用开发框架。LazyLLM 是商汤开源的 AI 开发框架，主打「懒人友好」，以数据流为核心，目标是让 Agent 搭建更加便捷、灵活，一站式实现生产级开发。LazyLLM 整合了已有开发框架的功能和优势，同时解决了嵌套过深、过度臃肿的问题，让开发者从繁杂的工程细节中解脱出来，专注于算法和数据本身。

低代码工作流平台

低代码工作流编排平台以效率优先，通过可视化的图形界面、拖放式的操作和预构建的模块，加速应用搭建，主要服务于业务人员，或者快速验证产品想法。类似的平台有很多，这里主要介绍两组。

Dify vs Coze：Dify 和 Coze 都是 AI 原生的，核心架构和设计理念都围绕大模型展开。

• Dify 是一个开源的、一体化的 LLMOps 平台。以 LLM 为核心，将可视化的提示词编排、RAG 引擎、智能体框架和后续的可观测性工具进行集成。
• Coze（扣子）是闭源的商业化产品，对于没有代码能力的运营人员来说，扣子可以以中低复杂度搭建并部署出可用的 AI 产品。

n8n vs make：最近 n8n 很火，但实际上，n8n 和 make 早在大模型浪潮前就已经广泛使用，它们并不是 AI 原生应用，而是在工作流自动化平台的基础上，加入了 AI 节点和能力，侧重于将 AI 嵌入到广泛、复杂的业务流程中。

• Make 是企业级无代码平台，核心优势在于积累了大量应用连接器，能够实现跨 SaaS 应用的复杂自动化。
• n8n 是开源平台，将可视化的节点式界面与执行自定义代码的能力相结合，提供拖拽搭建和代码执行的混合模式。

顺便一提，我偶然发现上面介绍的 LazyLLM 也有配套的低代码平台，继承底层框架的设计思想，对 RAG 流程的可视化搭建十分友好。可惜平台还没有开源。于是我尝试联系 LazyLLM 的作者，简单试用了一下，它相比于 dify，最大的改进在于它的知识库可以灵活配置离线解析和在线召回的策略。我将会在文章尾部简单介绍一下。

实战案例：从零构建一个综合问答 Agent

这一部分我将用演示如何构建「影视飓风百晓生 Agent」，通过提供影视飓风视频的视频信息及文字稿，回答关于视频的内容，同时支持复杂数据的查询并生成统计图表。

互联网的文本数据已经被使用得差不多了，但视频和播客中依然蕴藏着大量的高价值信息，现在虽然有一些能够和单个视频 Chat 的工具，但缺少对某个 UP 主所有视频内容综合对话的 Agent，已有的低代码工具想要实现类似功能也比较繁琐。

这其中既涉及到结构化的数据查询（text2SQL），也涉及到非结构化的内容理解（RAG）。

基于我的需求，我选择了 LazyLLM，主要原因有三：

1. Pipeline 逻辑设计直观清晰：LazyLLM 以「数据流」为核心范式，开发者能够像绘制流程图一样，用代码清晰地描述整个复杂流程（查询 -> 意图识别 -> [RAG分支 / SQL分支] -> 生成）。每个模块都是一个可插拔的组件，调试、替换和扩展都极为方便。与其他框架基于Runnable的链式调用相比，LazyLLM 逻辑更直观，更符合人的思维习惯。
2. 开箱即用且高度统一的组件：针对大模型调用、RAG（embedding、向量数据库、召回、重排）、Agent 工具调用等环节，LazyLLM 提供了丰富且接口高度一致的组件。切换模型或数据库，往往只需要修改一两个参数，而无需重写大量代码，便于快速实验、迭代开发。
3. 对开发者友好，学习成本低：相比一些高度抽象的框架，LazyLLM 的代码更易于理解和掌控。它的设计哲学是「简单和灵活」，不强迫开发者继承复杂的基类，任意一个Python函数都可以被无缝地接入其数据流。

感兴趣的可以到 LazyLLM 开源项目中了解更多技术细节：https://github.com/LazyAGI/LazyLLM

本次项目的整体框架如图：

我把代码和部分数据开源到 Github 上，供大家参考：https://github.com/loveQt/chatBilibiliUp

接下来一起看一下具体的实现过程和核心代码。

前置工作：数据准备

这一步主要是通过爬虫抓取 B 站频道下所有视频的链接、标题、数据以及文本内容。

B 站爬虫的具体代码略，请参照 bilibili-API-collect 项目选择需要的 API，唯一的难点是需要逆向接口中的 sign 参数，可以参照 Wbi 签名，实测可以直接使用。

这一步完成后，将数据保存为一个 sqlite 数据库：

至于文本内容，有两个思路，一是抓取视频字幕并处理，二是下载音频后批量转文字。

抓取字幕文件的前提是，该视频有后台自动生成或用户上传的字幕，且实测接口失败率较高。再加上直接使用字幕文件还有个问题，就是无法区分发言人，在访谈或多人对话场景下容易混淆。

所以我选择了第二种方法。

实现起来也不复杂：

1. 安装yt-dlp库；
2. 使用命令 yt-dlp -x --audio-format mp3 "https://www.bilibili.com/video/BV1yjg6zFEFa/" 即可下载到 mp3 格式的音频文件；
3. 使用subprocess循环下载，然后调用 STT 接口或使用其他语音转文字软件得到转换后的文本内容。

大体上就是这样，因为这篇毕竟是写 Agent 的，所以数据这块就不展开写太多细节了。大家可以根据自己的情况，准备论文数据库，或者业务知识库，用于之后的 Agent 搭建。

第二步，构建知识问答 RAG 系统

RAG 系统是实现知识问答的核心，一个典型的 RAG 系统通过构建向量数据库 -> 召回 -> 重排 -> 生成，构建起流水线，如下图所示：

LazyLLM 通过 Document 类来统一管理所有数据源，我将处理完成的转录文件都保存为 txt 格式，所以并不需要额外的 Reader() 处理其他格式文件。

这次，我选择使用 milvus 作为向量数据库，只需要少量代码就能完成构建：

documents = lazyllm.Document(
    dataset_path="./rag_data/video_content/stt",  # 视频转录文本目录
    embed=OnlineEmbeddingModule(
        source="qwen",
        embed_model_name="text-embedding-v3",  # 自定义embedding模型
        api_key=os.environ.get("LAZYLLM_QWEN_API_KEY"),
    ),
    manager=False,
    store_conf=milvus_store_conf,  # 使用Milvus向量数据库
)

有了向量数据库后，就可以开始配置召回、重排、生成的 pipeline：

with lazyllm.pipeline() as rag_ppl:
# 检索
    rag_ppl.retriever = lazyllm.Retriever(
        documents, 
        group_name="CoarseChunk", 
        topk=10
    )

# 重排序
    rag_ppl.reranker = lazyllm.Reranker(
        name='ModuleReranker',
        model=OnlineEmbeddingModule(
type='rerank',
            source="qwen",
            api_key=os.environ.get("LAZYLLM_QWEN_API_KEY"),
        ),
        topk=5,
        output_format='content',
        join=True
    ) | bind(query=rag_ppl.input)

# 格式化
    rag_ppl.formatter = (
lambda nodes, query: dict(context_str=nodes, query=query)
    ) | bind(query=rag_ppl.input)

# LLM
    rag_ppl.llm = lazyllm.OnlineChatModule().prompt(
        lazzyllm.ChatPrompter(instruction=prompt, extra_keys=['context_str'])
    )

return rag_ppl

这里的 pipeline 代码就像一张流程图，数据从 rag_ppl.input（用户问题）开始，流经retriever（召回）、ranker（重排），最终汇入formatter拼接为 Prompt，交由大模型生成最终答案。这种声明式的、以数据流为核心的写法，让复杂的逻辑一目了然。

看一下生成的效果：

而且，在这个工作流中，每一个组件（Retriever、Ranker、LLM）都是独立的模块。如果需要优化某个模块，只需修改少量代码，而无需改动整个流程的结构。

第三步，构建数据查询分析工作流

数据查询分析工作流比上面的 RAG 工作流要复杂一些，原因有二：

1. 大模型可以完成从自然语言到 SQL 语句的文本转换，也可以完成从数据到图表代码的编写，但想要实现与数据库的查询交互，以及图表的绘制保存，需要实现run_sql_query和run_code两个工具。
2. 不同于 RAG 问答的固定流程，数据分析工作流需要具备自主规划、迭代执行能力。

不过 LazyLLM 中内置了React、PlanAndSolve、ReWOO等常用的 Agent 范式，我们只需要根据需求选择合适的 Agent 即可。在 LazyLLM 中，只需要极少代码就可以实现 text2SQL 功能：

from lazyllm.tools import SqlManager, SqlCall

table_info = {
"tables": [{
"name": "vlist",
"comment": "视频列表数据",
"columns": [
            {
"name": "id",
"data_type": "Int",
"comment": "该条记录自增id",
"is_primary_key": True,
            },
            {
"name": "title",
"data_type": "String",
"comment": "视频标题",
"is_primary_key": False,
            },
            {
"name": "play",
"data_type": "Integer",
"comment": "播放量",
"is_primary_key": False,
            },
            {
"name": "sect",
"data_type": "Text",
"comment": "视频归属分区",
"is_primary_key": False,
            },
        ],
    }]
}

sql_manager = SqlManager("sqlite", None, None, None, None, db_name="mediastorm1.db", tables_info_dict=table_info)
sql_llm = lazyllm.OnlineChatModule()
sql_call = SqlCall(sql_llm, sql_manager, use_llm_for_sql_result=False)
result = sql_call("统计不同分区的视频数量")
print(result)

得到结果如下：

这里的核心组件是SqlManager 和 SqlCall，前者用于统一管理各类数据库连接，在实例sql_manager时，需要传入表结构；后者用于实现自然语言到 SQL 语句的转换，执行 SQL 查询并返回结果。

run_code工具主要是通过threading实现代码执行，这里的关键在于通过fc_register("tool")装饰器将 Python 函数注册为 Agent 可用的工具，并提供该工具实现的功能和参数描述：

@fc_register("tool")
defrun_code(code: str):
"""
    Run the given code in a separate thread and return the result.

    Args:
        code (str): code to run.

    Returns:
        dict: {
            "text": str,
            "error": str or None,
        }
    """
# 略，详见开源代码

准备好所需工具之后，构建 ReACT 工具即可：

BI_PROMPT = """
你是一位资深数据科学家，需要基于给定的问题进行必要的统计分析和绘图，来回答用户提出的统计问题。你的工作流程如下：

1. 理解问题并进行数据查询
    - 你需要先拆解用户问题中需要查询数据库的步骤，调用对应工具得到数据。

2. 判断根据数据是否可直接得出统计问题的答案
    - 如果数据可以直接回答统计问题，则直接输出结果，必要时补充绘制图表。
    - 如果不足以回答，则先进行必要的数据分析，再根据需要绘制图表。

3. 实现数据分析和绘图的方式是编写完整可执行的 Python 代码并调用相关工具执行并获取结果
    - 包含所有必要的 import、数据加载、分析逻辑、绘图代码、结果输出。
    - 使用常见数据科学工具包（如 pandas、numpy、scikit-learn 等）进行数据分析。
    - 使用可视化工具（如 matplotlib、seaborn）进行图表绘制。
    - 对所有需要查看的结果（如统计分析结果、图片路径等），需显式使用 print 函数输出。

4. 图像保存
    - 所有生成的图像必须保存到以下路径：
      {image_path}
    - 保存成功后，使用以下格式将图片展示在最终回答中（Answer部分）（image_name为保存的文件名，image_path为完整路径）：
      ![image_name](image_path)

5. 错误处理
    - 如果代码执行失败，请根据报错信息自动修改代码并重新执行，直到成功。

问题：
{query}
"""

defbuild_statistical_agent():
with pipeline() as sql_ppl:
        LOG.info("初始化统计分析pipeline")
        sql_ppl.formarter = lambda query: BI_PROMPT.format(query=query, image_path="./images")
        sql_ppl.agent = ReactAgent(
            llm=lazzyllm.OnlineChatModule(),
            tools=['run_code', 'run_sql_query'],
            return_trace=True,
            max_retries=3)
        sql_ppl.clean = lazyllm.ifs(lambda x: "Answer:"in x, lambda x: x.split("Answer:")[-1], lambda x: x)

测试一下：

在左下角的日志中，也可以看到工具执行过程中的参数，成功完成了查库、绘图和展示。

第四步，构建主 Agent，使用意图识别组合多个工作流

上面已经分别实现了知识问答和数据分析两个工作流，但是对于前端用户来说，最终的交互入口应该是统一的。

解决办法也很简单，就是增加一个主 Agent，让智能体自主进行意图识别，然后根据用户需求导向不同的工作流即可。

LazyLLM 中也封装了意图分类器，只需要调用主工作流的classifier方法，然后将子工作流 switch-case 到不同的分支上即可：

from statistical_agent import build_statistical_agent
from rag_agent import build_rag_agent

statistical_ppl = build_statistical_agent()
sql_ppl = build_statistical_agent()

llm = OnlineChatModule()

intent_list = [
"统计分析",  # 对应数据库查询和统计图表生成
"咨询内容",  # 对应RAG知识库问答
]

with pipeline() as main_ppl:
# 意图分类器
    main_ppl.classifier = IntentClassifier(llm, intent_list=intent_list)
with lazyllm.switch(judge_on_full_input=False).bind(_0, main_ppl.input) as main_ppl.sw:
        main_ppl.sw.case[intent_list[0], statistical_ppl]  # 统计分析
        main_ppl.sw.case[intent_list[1], rag_ppl]          # 咨询内容

最终呈现的效果如下：

这样我们就初步实现了一个「影视飓风百晓生」，它可以在同一个对话中查询数据库并生成图表，并跨多个视频检索文案，给出更可靠的知识问答。

我统计了一下，在 LazyLLM 的帮助下，除去设计 Prompt、提供表结构这些需要定义的变量，只考虑最核心的业务代码，我用大约 30 行代码就实现了 RAG，10 行代码实现了 text2SQL 工具，10 行代码实现了 React Agent 的统计分析，再也 10 行代码实现了意图分类。

可以说，真正的核心代码也就 100 多行。可以看出，只要在 AI 的帮助下花时间学习 LazyLLM 并实践一下代码，其开发效率是极高的，而且能控制很多实现细节。

LazyLLM 平台体验

LazyLLM 的应用编排平台，相比于 Dify 最大的优势，就是可以灵活配置自己的知识库，我很喜欢这种让准确率把控在自己手中的感觉。

如图所示，我可以自己搭建一个两路召回的知识库，来提升召回的准确率。相比于 Dify 等框架一成不变的固定知识库策略，至少我能尽我所能的提高我自己知识库的准确率。

接下来我们看一下知识库有哪些配置可以玩。

如下图所示，在离线解析阶段，我可以定义使用哪些节点组，节点组的概念也是我从 LazyLLM 的课程中学到的，表征所有文档在某个特定的切分方式下，获得的节点的合集，比如我通过段落、句子检索、关键词、摘要检索。LazyLLM 的编排平台内置了一些节点组，我可以通过打钩去激活他，激活后可以选择是否做向量化，选了向量模型就可以做向量化了。

除了预置的节点组，我还可以自定义节点组。如下图所示，我可以定义节点的切分或者转换方式，包括文本信息提取和文本切分，分别如下图左右所示，我都可以为每个节点组配置向量模型，如果不配置就表示不使用向量。

回到在线检索阶段，我们也可以配置被检索的节点组，这里我选择了摘要，我通过摘要进行检索。进一步的，我认为把摘要给到大模型，可能生成效果不是很好，于是我利用了 LazyLLM 课程第6讲中提到的「小块检索，大块生成」思想，把目标节点组设置为「粗粒度」，这样就相当于我用摘要进行检索，然后把找到的摘要通过倒排索引找到对应的「粗粒度」的原文，再把原文做重排给到大模型。