大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



拒绝各种宣传文，请大家谈谈自己的实际开发体验、选择和推荐。以及推荐的理由。

网上对于选择纯代码框架，还是低代码框架，经常会有激烈的讨论。

我尝试过的代码框架包括langchain、google adk，也简单学习过llamaindex和agno；我也尝试过的低代码框架，主要是n8n，dify，coze。想针对代码还是低代码的问题，谈谈我的看法。

代码框架具备更强的灵活性，方便结合AI编程工具进行辅助编程，理论上更适合程序员，我也看到绝大部分的开发者都推荐大家直接用python搭建智能体，认为低代码工作流只是过度阶段的工具，迟早会被淘汰。

但我的实践经验，会让我仍倾向于推荐大家入门优先使用低代码平台(重点推荐n8n)，主要是因为它的可视化调试，可以让你更直观的理解理解Agent和工具交互原理，以及数据流的变化。

我入门一开始选择了Google adk，我很快借助AI就搭建好了主体代码，但是我花了非常多的时间去调试代码里面的各种问题，并且要不断的运行、debug、打log，并在终端输出大量log中寻找解决问题的蛛丝马迹。而且我刚入门Agent开发时，对于Agent中大模型、工具等之间的交互和上下文的存储和传递的内部逻辑并不清楚。所以总是充满疑惑，晕头转向。

当我切换到n8n，这种一知半解，晕头转向的感觉立马消失了，因为n8n会把你的每一个节点的输入输出都可视化出来，而且你可以每增加一个节点，可以非常便捷的对当前节点的快速测试（不用像写代码，需要不断的运行、调试、查看变脸、中断、打log….）。

下面这个截图中，展示了Agent的输入节点的所有输入参数，以及Agent的输出：

如果Agent进行了多次动作，n8n会保留整个交互过程数据可视化，可以看下面这个案例：

1. 接收到用户指令，先调用大模型进行响应和决策；
2. 然后根据大模型的决策调用工具；
3. 最后基于工具返回的结果进行汇总回答问题。

下面这个视频展示了这三个步骤大模型所接收的输入和输出数据结构：

n8n支持整个Agent内部交互过程数据可视化https://www.zhihu.com/video/1907208172466341262

至于选什么框架，我现在给也不出答案，对于我自己，我觉得我很长一段时间都会先去使用n8n。coze不能私有化部署基本不考虑。dify自带RAG引擎，做知识库应用使用dify可以更快入手，但其灵活性和节点数量比不过n8n，而且RAG引擎也导致其部署成本更高。

我放一张几大热门Agent框架的github star的增长图，可能能给大家一些参考（截至2025.5.17）：

人在AI，刚下训练场。

先亮个底牌：鄙人，研究方向大语言模型及其智能体，已经开发了电子表格、生物信息等方向的Agent，核心开发语言Python。

没错，就是那个被戏称为“除了不会生孩子，其他都会”的Python。

为啥是Python？先明确一下，现在构建AI智能体，主要有两大流派：无代码平台和代码框架。

---

一、无代码平台：拖拉拽拽，AI智能体就来了？
这类平台的代表，就像字节跳动的“扣子（Coze）”。

• 优势：
  
  
  
• 门槛极低： 不需要你会写代码，点点鼠标，拖拖拽拽，配置一下，就能快速搭建一个AI智能体。对产品经理、运营或者想快速验证想法的个人开发者非常友好。
• 上手快，出活快： 对于一些逻辑相对简单、需求明确的场景，比如做一个能回答特定领域知识的客服机器人，用无代码平台效率非常高。
• 集成度高： 通常会内置很多常用的API、插件和服务，省去了自己去对接的麻烦。

• 劣势：
  
  
  
• 灵活性的天花板： “成也萧何败萧何”，低门槛往往也意味着自由度的受限。当你的需求稍微复杂一点，想要精细化控制AI的行为、逻辑流转，或者引入一些特别定制化的功能时，无代码平台可能就显得力不从心了。
• “黑箱”感： 底层很多东西是封装好的，你很难深入了解和修改其核心机制。对于追求极致性能和深度定制的开发者来说，这可能是个硬伤。
• 平台依赖： 你构建的智能体强依赖于平台，迁移成本高，万一平台政策调整或者停止服务，就比较被动了。

---

二、有代码框架：手握代码，掌控一切！
这派的代表就多了，比如Langchain、LlamaIndex，以及metaGPT等ICLR大作。这些框架，绝大部分都是基于Python生态的。

• 优势：
  
  
  
• 高度灵活性和可定制性： 这是最大的优点。你可以像搭积木一样，自由组合不同的模块（大语言模型、向量数据库、记忆模块、工具调用等），实现非常复杂的逻辑和功能。想怎么调校，就怎么调校。
• 掌控力强： 从数据处理、模型选择、提示工程到业务逻辑，每一个环节你都可以深入介入和优化。知其然，更知其所以然。
• 生态丰富： 尤其是Python生态，拥有海量的AI/ML库（如TensorFlow, PyTorch, Transformers, scikit-learn）、数据处理工具（Pandas, NumPy）和社区支持。遇到问题，很容易找到解决方案。
• 开源为主： 很多优秀的框架都是开源的，这意味着你可以免费使用，甚至参与贡献，不用担心被“卡脖子”。
• 可移植性与可扩展性： 基于代码的实现更容易部署到不同的环境，也更容易随着业务发展进行扩展。

• 劣势：
  
  
  
• 门槛较高： 需要具备编程能力，特别是Python编程能力。对于没有编程基础的同学来说，上手曲线会比较陡峭。
• 开发周期相对较长： 相比无代码平台的“立竿见影”，用代码从零开始构建或者基于框架进行深度开发，需要投入更多的时间和精力。
• “轮子”的选择与维护： 框架和库的选择很多，有时也会面临“选择困难症”，并且需要自己处理版本兼容、依赖管理等问题。

---

三、为啥偏偏是Python？
虽然无代码平台在特定场景下有其价值，但要构建真正强大、灵活、可控的AI智能体，尤其是需要处理复杂任务、不断学习和进化的存在，代码框架，特别是基于Python的框架，是目前的主流和更优选择。

总结一下：

构建AI智能体，选择无代码平台还是有代码框架，取决于你的具体需求、技术背景和对灵活性的要求。

• 如果你想快速验证一个简单的想法，或者你不懂代码，那么“扣子”这类无代码平台是个不错的起点。
• 但如果你追求的是更强大的功能、更精细的控制、更深度的定制，那么以Langchain、metaGPT为代表的Python代码框架可能更合适。
• 甚至是，Python手搓，毕竟代码框架自身，也有不灵活性，也有学习成本，也有很多实现上的限制。

所以我，人生苦短，我用Python。

在讨论开发框架前，这里简单给大家罗列下AI智能体常用技术栈，然后结合自己的使用习惯介绍下Langchain系列框架的使用。

图中的AI智能体技术栈，分为三个关键层次：智能体托管/服务、智能体框架以及LLM模型和存储。注:图片是引用参考，每个部分内容不是最新，但是已经可以说明问题。

与基础LLM聊天机器人相比，智能体是一项更具挑战性的工程任务，因为它们需要状态管理（保留消息/事件历史、存储长期记忆、在智能体循环中执行多个LLM调用）和工具执行（安全执行LLM输出的行动并返回结果）。

因此，AI智能体技术栈与标准LLM技术栈看起来非常不同。从底层的模型服务层开始，分解当今的AI智能体技术栈：

AI智能体的核心是LLM。要使用LLM，模型需要通过推理引擎提供服务，这通常通过付费API服务实现。OpenAI和Anthropic在封闭式API模型推理提供商中处于领先地位，拥有私有前沿模型。Together.AI、Fireworks和Groq是流行的选择，它们在付费API后提供开放权重模型（如Llama 3）。在本地模型推理提供商中，最常见的是vLLM，它在生产级GPU服务负载中处于领先地位。SGLang是一个具有类似开发者受众的新兴项目。Ollama和LM Studio是在自己计算机上运行模型的两个流行选项（例如M系列Apple Macbook）。

存储是具有状态的智能体的基本构建块——智能体由持久化状态定义，如其对话历史、记忆和用于RAG的外部数据源。向量数据库如Chroma、Weaviate、Pinecone、Qdrant和Milvus在存储智能体的“外部记忆”方面很受欢迎，使智能体能够利用太大而无法放入上下文窗口的数据源和对话历史。Postgres作为一个自80年代以来就存在的传统数据库，现在也通过pgvector扩展支持向量搜索。基于Postgres的公司如Neon（无服务器Postgres）和Supabase也为智能体提供基于嵌入的搜索和存储。

标准AI聊天机器人和AI智能体之间的主要区别之一是智能体调用“工具”（或“函数”）的能力。在大多数情况下，这一行动的机制是LLM生成结构化输出（例如，JSON对象），指定要调用的函数和要提供的参数。关于智能体工具执行的一个常见混淆点是，工具执行不是由LLM提供商本身完成的——LLM只选择调用什么工具以及提供什么参数。支持任意工具或向工具传入任意参数的智能体服务必须使用沙箱（例如Modal、E2B）以确保安全执行。

所有智能体都通过OpenAI定义的JSON模式调用工具——这意味着智能体和工具实际上可以在不同框架之间兼容。Letta智能体可以调用LangChain、CrewAI和Composio工具，因为它们都由相同的模式定义。因此，针对常用工具的工具提供商生态系统正在不断发展。Composio是一个流行的通用工具库，还管理授权。Browserbase是专门用于网页浏览的工具示例，Exa提供专门用于搜索网络的工具。随着更多智能体的构建，预计工具生态系统将继续发展，并为智能体提供新功能，如身份验证和访问控制。

智能体框架编排LLM调用并管理智能体状态。不同框架在以下方面会有不同的设计：

智能体状态管理：大多数框架引入了某种状态“序列化”概念，通过将序列化状态（如JSON、字节）保存到文件中，允许智能体在稍后加载回同一脚本——这包括对话历史、智能体记忆和执行阶段等状态。在Letta中，所有状态都由数据库支持（例如消息表、智能体状态表、记忆块表），没有“序列化”的概念，因为智能体状态始终是持久化的。这允许轻松查询智能体状态（例如，按日期查找过去的消息）。状态的表示和管理方式决定了智能体应用如何随着更长的对话历史或更多数量的智能体而扩展，以及状态如何灵活地被访问或修改。

智能体上下文窗口的结构：每次调用LLM时，框架都会将智能体的状态“编译”到上下文窗口中。不同的框架会以不同方式将数据放入上下文窗口（如指令、消息缓冲区等），这可能会改变性能。建议选择使上下文窗口透明的框架，因为这最终是控制智能体行为的方式。

跨智能体通信（即多智能体）：Llama Index通过消息队列让智能体通信，而CrewAI和AutoGen则为多智能体提供明确的抽象器。Letta和LangGraph都支持智能体直接相互调用，这允许通过监督智能体进行集中式通信和跨智能体的分布式通信。大多数框架现在都支持多智能体和单智能体，因为设计良好的单智能体系统应该使跨智能体协作容易实现。

记忆管理方法：LLM的一个基本限制是其有限的上下文窗口，这就需要技术来随时间管理记忆。记忆管理内置于一些框架中，而其他框架则期望开发者自己管理记忆。CrewAI和AutoGen仅依赖基于RAG的记忆，而phidata和Letta使用额外的技术，如自编辑记忆（来自MemGPT）和递归摘要。Letta智能体自动配备一套记忆管理工具，允许智能体按文本或数据搜索以前的消息、写入记忆并编辑智能体自己的上下文窗口（你可以在这里阅读更多内容）。

对开放模型的支持：模型提供商实际上在幕后做了很多技巧，使LLM以正确的格式生成文本（例如工具调用）——例如，当它们没有生成适当的工具参数时重新采样LLM输出，或在提示中添加提示（例如“请输出JSON”）。支持开放模型需要框架处理这些挑战，因此一些框架限制了对主要模型提供商的支持。

在今天构建智能体时，正确的框架选择取决于你的应用，例如你是构建对话智能体还是工作流，你是希望在笔记本中运行智能体还是作为服务，以及你对开放权重模型支持的要求。预计在部署工作流中，框架之间的主要差异将会出现，届时状态/记忆管理和工具执行的设计选择将变得更加重要。

今天大多数智能体框架都是为那些不存在于它们编写的Python脚本或Jupyter笔记本之外的智能体设计的。

将智能体部署为服务比部署LLM为服务要复杂得多，这是由于状态管理和安全工具执行的问题。工具及其所需的依赖项和环境需要明确存储在数据库中，因为运行它们的环境需要由服务重新创建。应用可能需要运行数百万个智能体，每个智能体都积累着不断增长的对话历史。从原型设计到生产阶段，智能体状态必然要经历数据规范化过程，而智能体交互必须由REST API定义。今天，这个过程通常由开发人员编写自己的FastAPI和数据库代码完成，但预计随着智能体的成熟，这种功能将更多地嵌入到框架中。

鉴于智能体在实际业务场景中的构建复杂性，需要对细节部分进行更多的控制，我个人是从LangChain系列入手，LangChain生态系统内的协同性与互操作性，提供进退的空间。下面简要介绍下LangChain生态。感兴趣的可以继续。

LangChain生态系统为整个AI应用开发生命周期提供了全面且集成的技术栈。这种全栈方法包括：

• 构建： 核心LangChain框架提供可组合的组件和抽象。
• 编排： LangGraph促进复杂、有状态智能体的创建，具备迭代推理能力。
• 管理、调试、评估和监控： LangSmith确保LLM应用在其整个生命周期中的可靠性和性能。
• 可视化原型设计： LangFlow提供无代码/低代码可视化IDE，用于快速开发和实验。
• 部署： LangServe可用于部署简单链，而LangGraph平台则专为有状态智能体的稳健部署和扩展而设计。

该生态系统内的互操作性是其设计的基石。组件暴露标准接口，使开发者能够轻松在不同提供商或实现之间切换。至关重要的是，这些产品既可以独立使用，也可以组合在一起以获得倍增效益。

考虑一个典型的开发工作流程：开发者可能首先使用LangFlow可视化地原型设计一个检索增强生成（RAG）智能体，利用其拖放界面进行快速迭代。随后，可以使用LangGraph定义智能体的复杂、有状态的推理循环，使其能够进行多步决策和自我纠正。该智能体随后会与各种LangChain组件无缝集成，如特定的LLM集成或自定义工具。随着应用的成熟，LangSmith对于调试、测试和持续监控其在生产中的性能变得不可或缺，提供对其行为的深入可见性。最后，对于大规模部署，LangGraph平台将被用于确保智能体的稳健性、可扩展性和安全性。

这种全面性，涵盖开发、编排、可观察性和部署，揭示了为整个LLM应用生命周期提供端到端解决方案的战略愿景。这种集成方法最小化了开发者的摩擦和上下文切换，使他们能够专注于核心业务逻辑，而不是花费精力拼凑不同的工具。这标志着LLM开发空间的成熟，从分散的工具转向更具凝聚力、企业级的生态系统。这种集成套件对于加速在复杂的生产环境中采用LLM至关重要。

LangChain生态系统核心工具对比

工具	主要角色	关键特性	开发阶段重点	目标用户	与LangChain的关系
LangChain	用于构建LLM应用的开源框架。	模块化组件（链、智能体、LLM接口、记忆）；广泛的集成。	构建、原型设计	核心开发者、AI工程师	核心框架；提供构建模块和抽象。
LangSmith	LLM应用的可观察性、测试、评估和监控平台。	追踪与调试；数据集驱动测试；自动化与人工评估；生产监控。	调试、测试、评估、监控	AI工程师、数据科学家、产品经理、QA	由LangChain团队创建；无缝集成；框架无关。
LangFlow	用于快速原型设计和部署AI智能体的可视化IDE。	图形化工作流界面（拖放式）；Python自定义；测试平台。	原型设计、构建、部署	开发者、数据科学家、非技术用户	LangChain的可视化抽象层；简化流程创建。
LangGraph	使用循环图构建稳健、有状态的多角色LLM智能体的框架。	用于迭代推理的循环图；有状态记忆；人在环中；流式处理。	编排、构建复杂智能体	AI工程师、研究人员	LangChain的扩展；推荐用于高级智能体工作流和持久性。
LangGraph Studio	专门用于可视化、交互和调试LangGraph智能体的IDE。	图模式可视化；测试的聊天模式；时间旅行调试；LangSmith集成。	调试、测试、迭代	AI工程师、智能体开发者	LangGraph的可视化界面；与LangSmith集成实现深度分析。
LangServe	将LangChain链部署为REST API的包。	简单可运行组件的简易API部署。	部署	开发者	LangChain链的部署组件。
LangGraph Platform	专为部署和扩展LangGraph智能体而构建的平台。	企业级部署；长期运行的工作流；人在环中；智能体共享。	部署、管理、扩展	DevOps、企业团队	LangGraph智能体的部署基础设施；对智能体框架无关。

LangChain生态系统提供了一条连贯的路径，引导开发者完成整个LLM应用开发生命周期，从最初的构思和原型设计到稳健的生产部署和持续监控。

在原型设计阶段，LangFlow提供了一个强大的环境用于快速视觉开发，允许想法快速转化为功能流。同时，LangSmith可以从一开始就集成进来提供可观察性，通过提供对应用行为的即时洞察来加速迭代过程。对于核心构建阶段，基础的LangChain框架提供必要的组件和抽象，而LangGraph使复杂、有状态的智能体逻辑构建成为可能，这对高级AI应用至关重要。

随着开发的进展，测试和评估变得至关重要。LangSmith为这一阶段提供了强大的功能，包括数据集驱动的测试和“LLM作为评判者”的评估器，可自动评估质量。对于调试，LangSmith提供详细的追踪和可视化工具，阐明LLM应用通常复杂的行为。特别是对于智能体，LangGraph Studio通过允许开发者通过“时间旅行”调试智能体状态来增强这一点，提供执行的历史视图。最后，对于部署和监控，LangServe促进更简单链的部署，而LangGraph平台则专为有状态智能体的更高要求而设计。LangSmith通过提供持续监控和警报功能，确保持续的性能和可靠性。

换句话讲，该有的都有了，从生产到部署都打通了，所以也就入langchain生态的坑。其它的工具如dify、coze、n8n有下载试用过但体验不深，有点类似低代码平台，没有做过度探索。

大家有好的建议、提升开发效率的经验做法，欢迎留言讨论交流。

参考：

https://www.langflow.org/

LangSmith

https://www.letta.com/blog/introducing-the-agent-development-environment