AI Agent实战指南:从框架选型到RAG应用构建

张开发
2026/4/26 3:42:58 15 分钟阅读

分享文章

AI Agent实战指南:从框架选型到RAG应用构建
1. 从Awesome列表到实战指南如何高效利用AI Agent开源生态如果你最近在琢磨怎么用大语言模型LLM搞点自动化的事情比如让AI帮你写代码、分析数据或者管理知识库那你大概率会搜到各种眼花缭乱的“AI Agent”框架和工具。GitHub上有个叫“Awesome Agents”的列表汇总了上百个相关项目从Meta、微软这样的大厂出品到个人开发者的精巧工具应有尽有。我第一次看到这个列表时感觉就像走进了一个巨大的五金超市工具琳琅满目但完全不知道从哪把螺丝刀开始用起。这份列表是个极好的资源地图但它本身不负责教你盖房子。经过一段时间的摸索和实际项目踩坑我逐渐理清了头绪如何不被海量信息淹没而是从中快速找到适合自己场景的“趁手兵器”并组合起来解决实际问题。这篇文章我就结合自己的经验带你拆解这份Awesome列表分享一套从选型、评估到落地的实战思路目标是让你看完后能立刻动手搭建属于自己的第一个AI Agent应用。这份列表的价值在于其“广度”它几乎囊括了AI Agent生态的所有关键节点。但它的挑战也在于“深度”的缺失。列表里的项目被分成了“框架”、“测试评估”、“软件开发”、“研究”等近十个大类每个类别下又有几十个项目每个项目通常只有一行简介和一个GitHub星星数。对于新手来说这很容易导致“选择困难症”或者更糟——盲目选择最火的那个结果发现根本不适合自己的需求。我的核心观点是不要试图去理解或比较列表里的每一个项目那是不可能的也是没必要的。你应该做的是先明确自己的“问题域”然后像查字典一样去列表中寻找对应领域的成熟解决方案和关键组件。举个例子假设你想做一个能自动处理客服工单的AI助手。你的需求可能包括理解用户自然语言、查询知识库、执行某些API操作比如创建订单、查询物流。对应到Awesome列表里你需要的可能是一个对话框架如LangChain、CrewAI来编排流程一个知识管理工具如LlamaIndex、PrivateGPT来处理内部文档以及一些自动化工具来连接外部系统。你的选型路径应该是“由场景驱动”而非“由技术驱动”。接下来我会按照从宏观到微观的顺序带你走一遍这个决策和实操流程。2. 核心框架选型找到你的“操作系统”当你决定要构建一个AI Agent时第一个也是最关键的决定就是选择底层框架。你可以把框架理解为Agent的“操作系统”它定义了Agent如何思考规划、如何行动执行工具、如何记忆存储和回忆以及多个Agent之间如何协作。Awesome列表的“Frameworks”类别下项目最多竞争也最激烈这里我根据其设计哲学和适用场景把它们分成几个主要的流派方便你快速定位。2.1 全能型重型框架LangChain与AutoGen这类框架功能全面生态繁荣适合构建复杂、企业级的应用。它们是列表中的“老兵”经历了大量实战检验。LangChain无疑是这个领域的开创者和事实标准。它的核心思想是“链”Chain将调用LLM、使用工具、访问记忆等操作链接起来形成一个可预测的工作流。它的优势在于模块化程度高提供了大量现成的、可组合的“链”、“代理”和“工具”比如专门用于问答的RetrievalQA链用于与SQL数据库交互的SQLDatabaseChain。生态极其丰富拥有最全的集成列表支持几乎所有主流LLM APIOpenAI、Anthropic、Cohere等和向量数据库Chroma、Pinecone、Weaviate等。社区贡献了大量的工具和模板。灵活性好你可以从高级别的链快速开始也可以深入到低级API进行完全自定义。但是LangChain的缺点也很明显学习曲线陡峭。其概念较多Model, Prompt, Chain, Agent, Memory, Index初期容易混淆。另外由于其抽象层次高在调试复杂链时有时不容易定位问题所在。实操心得对于刚入门的新手我建议从LangChain的“表达式语言”LCEL开始学起。LCEL提供了一种更声明式、更Pythonic的方式来构建链比旧的“Chain”类更直观也更容易调试。例如用Runnable接口将各个环节串联起来代码会清晰很多。AutoGen由微软推出其核心理念是多智能体对话。它允许你定义多个具有不同角色如程序员、测试员、产品经理的Agent让它们通过相互对话来协作解决任务。AutoGen的强大之处在于对话驱动的问题解决特别适合需要多角度讨论、辩论或评审的场景比如代码审查、方案设计。内置的对话管理自动处理对话回合、支持自定义回复过滤器、允许人类随时介入Human-in-the-loop。与LangChain互补你完全可以在AutoGen的Agent中使用LangChain的工具和链强强联合。AutoGen的挑战在于设计一个高效的多Agent对话流程本身就是一个复杂任务。你需要精心设计每个Agent的“系统提示词”System Prompt并规划好它们交互的协议否则容易陷入低效的循环对话。2.2 新兴的轻量级与专项框架如果你觉得LangChain太重或者你的场景比较特定那么列表里一大批新兴框架值得关注。它们往往在易用性、性能或特定功能上做了深度优化。CrewAI是近期非常受关注的一个框架。它采用了“角色扮演”Role-Playing的隐喻让你像组建一个团队一样定义Agent成员、Task任务和Process工作流程如顺序执行或协同讨论。它的API设计非常直观对于业务人员或项目经理来说更容易理解。例如定义一个“市场分析师”Agent去完成“撰写竞品报告”Task逻辑非常清晰。CrewAI在任务分解、结果传递和上下文管理上做了很多封装让你能更专注于业务逻辑。AgentScope和Lagent是国内团队推出的优秀框架。AgentScope来自ModelScope强调分布式和多模态Agent的易用性。Lagent来自上海人工智能实验室则主打轻量级和高效代码简洁适合快速原型验证和学术研究。如果你的团队或项目主要在国内考虑中文社区支持和文档的完备性这两个框架是很好的选择。MetaGPT是一个极具特色的框架它模拟了一个软件公司的组织架构。你给它一个需求如“开发一个贪吃蛇游戏”它会自动生成产品需求文档PRD、设计、任务列表、甚至代码仓库。它本质上是一个多Agent协作的代码生成框架非常适合探索AI在软件开发生命周期自动化方面的潜力。虽然生成的代码不一定能直接运行但其展现的规划和协作能力令人印象深刻。对于特定场景列表里也有精专的解决方案语音/多模态对话Pipecat专门为构建语音和视频对话Agent设计处理音频流、视频流和实时交互。生产级部署AgentDock、AgentField这类框架更关注如何将Agent安全、可靠地部署到生产环境提供了身份认证、资源隔离、监控等企业级功能。极致性能与通信AVPAgent Vector Protocol尝试让Agent之间直接通过模型内部的“隐藏状态”通信而非文本号称能提升2倍速度并减少56%的Token消耗适合对延迟和成本极度敏感的场景。框架选型决策树面对这么多选择你可以通过回答下面几个问题来快速缩小范围你的应用复杂度如何简单任务脚本 - 考虑轻量级框架Lagent, CrewAI或不用框架复杂工作流 - LangChain, AutoGen。是否需要多个Agent协作是 - AutoGen, CrewAI, MetaGPT否 - 其他。是否涉及特定模态语音、视频是 - Pipecat否 - 通用框架。是否要求快速上线和易用性是 - CrewAI, AgentScope愿意接受学习成本 - LangChain。是否有生产环境部署要求是 - 考察AgentDock, AgentField或基于LangChain/AutoGen自建管控层。3. 能力扩展为你的Agent装上“眼睛”和“手脚”选好了框架相当于给Agent搭好了大脑和神经系统。但一个能干的Agent还需要感知世界获取信息和改造世界执行操作的能力。这就是“工具”Tools和“记忆”Memory系统的作用。Awesome列表的其他类别很大程度上就是在为你提供这些现成的“器官”。3.1 知识管理与检索增强生成RAG这是让Agent变得“博学”的关键。几乎所有需要处理私有、非公开信息的场景客服、内部知识库问答、研究分析都离不开它。列表中的“Knowledge Management”类别和部分“Frameworks”里的项目如LlamaIndex就是干这个的。核心流程与工具选型一个标准的RAG流程包括文档加载 - 文本分割 - 向量化嵌入 - 存储到向量数据库 - 查询时检索 - 组合上下文提示LLM生成答案。文档处理与检索框架LlamaIndex在这方面是专家。它提供了极其丰富的“数据连接器”能从PDF、PPT、数据库、API等上百种数据源加载数据。它的“索引”抽象如向量索引、关键词索引、摘要索引和“查询引擎”让你能轻松实现复杂检索逻辑比如先进行摘要过滤再进行精确向量查找。它和LangChain是黄金搭档常被一起使用。本地化与隐私方案PrivateGPT、LocalGPT这类项目提供了一个开箱即用的完整解决方案强调所有流程包括使用LLM都在本地运行保证数据不出私域。它们通常集成了Llama.cpp、GPT4All等本地LLM运行库和Chroma等本地向量数据库。如果你的需求就是简单的本地文档问答直接用它们可能比从零搭建更快。前沿探索Hindsight等项目在探索更先进的“长期记忆”机制不仅仅是存储和检索文本片段而是试图让Agent拥有更结构化、更关联的记忆网络。避坑指南RAG听起来简单但效果好坏天差地别。最常见的坑是“检索质量差”。文本分割的大小很关键太大检索出的信息不精准太小丢失上下文。通常需要根据文档类型技术手册、小说、会议记录进行试验。另一个坑是“幻觉”即使提供了上下文LLM也可能生成与原文不符的答案。除了优化提示词如要求“严格依据原文回答”还可以在检索后增加一个“重排序”步骤用更小的模型对检索结果进行相关性排序提升Top结果的精度。3.2 软件研发与自动化如果你想打造一个“AI程序员”或自动化工作流那么“Software Development”和“Automation”类别是你的宝藏。这里的工具让Agent能直接操作代码和环境。AI辅助编程Aider是一个在终端中运行的AI结对编程工具。它直接集成到你的编辑器中可以基于对话来修改代码支持整个项目级别的上下文非常受开发者欢迎。OpenHands原OpenDevin和Devika则更进了一步目标是成为全功能的“AI软件工程师”能理解高级需求、拆解任务、搜索网络、编写代码。它们更适合探索性的项目生成或自动化脚本编写。浏览器与桌面自动化这是Agent与真实世界交互的重要途径。虽然列表没有单独的“浏览器自动化”大类但许多框架如LangChain都集成了类似PlayWright或Selenium的工具。你需要为Agent提供打开网页、点击、输入、读取内容等能力。注意安全赋予Agent浏览器自动化权限是高风险操作务必在沙箱或严格受限的环境中运行。API与工作流自动化RestGPT展示了如何让LLM理解并调用RESTful API来完成复杂任务如订机票、查天气。这需要为Agent提供API的文档描述如OpenAPI Spec。更进一步的像n8n、Zapier这样的传统自动化平台也开始集成AI能力你可以将它们视为Agent的“执行手臂”。3.3 测试、评估与可观测性这是Agent项目从玩具走向生产的关键一步。一个不可预测、不可观测的Agent是可怕的。Awesome列表中的“Testing and Evaluation”类别虽然项目不多但个个重要。评估框架Arize-Phoenix是一个功能强大的开源可观测性平台。它不仅能跟踪传统ML模型的指标更能深入LLM和Agent的内部追踪每次调用的Prompt、Completion、Token使用量、延迟、成本还能对检索RAG过程进行可视化帮你分析是检索环节还是生成环节出了问题。成本与性能监控Manifest专注于实时成本观测。当你使用多个模型、多个Agent时账单可能快速增长。这类工具帮你按项目、按模型细分开销。合规与安全扫描AIR Blackbox针对的是日益重要的合规性需求如欧盟AI法案。它能检测Prompt注入攻击、个人身份信息PII泄露风险等为生产部署提供安全层。我的实践建议在项目早期就引入可观测性。不要等到出了问题才去查日志。在最简单的原型阶段就至少要把每次Agent交互的输入输出记录下来。随着复杂度提升再逐步接入Phoenix这样的专业工具。你会感谢这个决定的。4. 实战构建从零搭建一个客服工单处理Agent理论说了这么多我们动手搭一个。假设我们要为一个电商公司构建一个初级客服工单处理Agent它能理解用户通过聊天窗口发来的自然语言问题。从公司内部的FAQ文档和产品手册中查找相关信息。如果能从知识库中找到答案就直接回复。如果涉及需要查询用户订单状态它能调用内部订单查询API。如果问题复杂无法自动解决则生成摘要并转接给人工客服。我们将使用LangChain生态丰富 LlamaIndex文档处理能力强 OpenAI GPT-4能力均衡的技术栈。下面是核心步骤和代码片段。4.1 环境准备与知识库构建首先准备你的文档。假设我们把所有FAQ和产品手册的PDF放在./data目录下。# 安装核心库 # pip install langchain langchain-openai llama-index python-dotenv import os from dotenv import load_dotenv from llama_index.core import SimpleDirectoryReader, VectorStoreIndex, StorageContext from llama_index.vector_stores.chroma import ChromaVectorStore from llama_index.embeddings.openai import OpenAIEmbedding import chromadb # 加载环境变量设置OpenAI API Key load_dotenv() os.environ[OPENAI_API_KEY] os.getenv(OPENAI_API_KEY) # 1. 加载文档 documents SimpleDirectoryReader(./data).load_data() # 2. 初始化向量数据库Chroma和嵌入模型 chroma_client chromadb.PersistentClient(path./chroma_db) chroma_collection chroma_client.get_or_create_collection(customer_service_kb) vector_store ChromaVectorStore(chroma_collectionchroma_collection) storage_context StorageContext.from_defaults(vector_storevector_store) embed_model OpenAIEmbedding(modeltext-embedding-3-small) # 3. 创建索引并持久化 index VectorStoreIndex.from_documents( documents, storage_contextstorage_context, embed_modelembed_model ) # 索引会自动保存到指定的Chroma路径这一步完成后你的知识库就建好了。Chroma会在本地./chroma_db目录存储所有向量数据。4.2 定义工具与创建Agent接下来我们定义两个工具一个用于知识库问答一个用于查询订单API。from langchain.agents import Tool, AgentExecutor, create_openai_tools_agent from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.agents.format_scratchpad.openai_tools import format_to_openai_tool_messages from langchain.agents.output_parsers.openai_tools import OpenAIToolsAgentOutputParser from llama_index.core import Settings from llama_index.core.query_engine import RetrieverQueryEngine # 0. 全局设置LLM (LlamaIndex和LangChain共用) llm ChatOpenAI(modelgpt-4-turbo-preview, temperature0) Settings.llm llm Settings.embed_model embed_model # 1. 构建知识库查询引擎 (作为Tool) # 从持久化的存储中加载索引 loaded_index VectorStoreIndex.from_vector_store(vector_store, embed_modelembed_model) query_engine loaded_index.as_query_engine(similarity_top_k3) # 检索最相关的3个片段 def knowledge_base_query(input_text: str) - str: 查询内部知识库来回答客户问题。 response query_engine.query(input_text) return str(response) # 2. 定义订单查询工具 (模拟) def order_lookup_api(order_id: str) - str: 根据订单ID查询订单状态。输入必须是订单ID字符串。 # 这里应该是调用真实API我们模拟一下 import random statuses [已付款待发货, 已发货运输中, 已签收, 退货处理中] return f订单 {order_id} 的状态是{random.choice(statuses)}。最后更新时间为2024-05-20。 # 3. 将函数封装成LangChain Tool tools [ Tool( nameKnowledgeBaseSearch, funcknowledge_base_query, description当用户询问关于产品功能、使用方法、退换货政策、物流时效等通用问题时使用此工具。输入应该是用户的完整问题。 ), Tool( nameOrderStatusLookup, funcorder_lookup_api, description当用户提供订单号并询问订单状态、物流信息时使用此工具。输入必须是一个明确的订单ID字符串。 ) ] # 4. 构建Agent提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的电商客服助手。请遵循以下规则 1. 首先礼貌问候用户。 2. 仔细分析用户问题决定使用哪个工具或者是否需要直接回答。 3. 如果使用工具请确保输入格式符合工具描述的要求。 4. 根据工具返回的结果组织成友好、清晰、专业的回复给用户。 5. 如果知识库和订单查询都无法解决用户问题例如投诉具体客服人员、复杂的售后纠纷请向用户说明情况并告知将转接人工客服同时生成一个问题摘要。 6. 不要编造信息。如果工具返回的信息不明确请如实告知用户。), MessagesPlaceholder(variable_namechat_history), (user, {input}), MessagesPlaceholder(variable_nameagent_scratchpad), ]) # 5. 创建Agent链 agent create_openai_tools_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 6. 运行测试 def run_agent_with_memory(user_input, chat_history[]): 运行Agent并管理简单的对话历史。 # 将历史记录格式化为LangChain消息 from langchain_core.messages import HumanMessage, AIMessage formatted_history [] for msg in chat_history: if msg[type] human: formatted_history.append(HumanMessage(contentmsg[content])) else: formatted_history.append(AIMessage(contentmsg[content])) # 准备输入 inputs { input: user_input, chat_history: formatted_history } # 执行 response agent_executor.invoke(inputs) # 更新历史记录简单示例生产环境需持久化 chat_history.append({type: human, content: user_input}) chat_history.append({type: ai, content: response[output]}) return response[output], chat_history # 模拟对话 history [] response1, history run_agent_with_memory(你好我想问一下手机一般多久能收到货, history) print(f用户: 你好我想问一下手机一般多久能收到货) print(fAgent: {response1}\n) response2, history run_agent_with_memory(我的订单号是ORD123456现在到哪了, history) print(f用户: 我的订单号是ORD123456现在到哪了) print(fAgent: {response2}\n) response3, history run_agent_with_memory(我收到的手机屏幕有划痕我要投诉你们的质检部门, history) print(f用户: 我收到的手机屏幕有划痕我要投诉你们的质检部门) print(fAgent: {response3})4.3 关键配置解析与经验上面的代码是一个高度简化的原型但包含了核心要素。在实际部署前有几个关键点需要深入处理1. 提示词工程是灵魂系统提示词System Prompt定义了Agent的“性格”和“行为准则”。我们的示例中包含了规则但还可以更精细比如“优先使用知识库工具”、“调用订单查询工具前必须确认用户已提供订单号若未提供应主动询问”。好的提示词能大幅减少Agent的“胡言乱语”和错误工具调用。2. 工具描述的精确性Tool的description字段是引导Agent正确选择工具的关键。描述必须清晰说明工具的用途和输入格式。例如订单查询工具强调“输入必须是一个明确的订单ID字符串”这能有效防止Agent把“我的订单怎么样了”这样的模糊语句直接传给API。3. 记忆Memory管理示例中使用了一个简单的列表来存储对话轮次这只适用于短期会话。对于长对话你需要更健壮的记忆系统。LangChain提供了多种记忆后端如ConversationBufferMemory保存所有历史对话简单但可能超出Token限制。ConversationSummaryMemory让LLM定期总结对话历史节省空间但可能丢失细节。ConversationKGMemory将对话内容存储为知识图谱便于基于实体和关系的查询。 生产环境中通常需要将会话记忆持久化到数据库如Redis并设计合理的过期和清理策略。4. 错误处理与稳定性AgentExecutor的handle_parsing_errorsTrue参数很重要它能在Agent输出无法解析为工具调用时尝试让LLM自我纠正。此外你还需要为每个工具调用添加try...except包装处理网络超时、API限流、无效输入等情况并给用户友好的反馈。5. 检索质量优化这是RAG应用成败的瓶颈。除了调整文本分割大小还可以混合检索结合向量检索语义相似度和关键词检索如BM25取长补短。重排序先用向量检索出N个比如20个相关片段再用一个更小、更快的重排序模型如BAAI/bge-reranker对它们进行精排选出最相关的Top K个比如3个送给LLM。元数据过滤在存储时为每个文本块添加元数据如所属文档章节、产品类型、更新时间。查询时可以先让LLM提取查询中的过滤条件如“查询iPhone 15的电池续航”再用元数据过滤能大幅提升精度。5. 避坑指南与进阶思考在实际开发和运营AI Agent的过程中你会遇到一些共性的挑战。这里分享我踩过的一些坑和对应的解决方案。5.1 常见问题与排查清单问题现象可能原因排查步骤与解决方案Agent总是回答“我不知道”或拒绝回答1. 检索结果为空或相关性极低。2. 系统提示词过于保守限制了Agent发挥。3. LLM温度temperature设置过低创造性不足。1. 检查检索环节打印出每次查询检索到的原始文本片段看是否相关。调整分割策略或尝试混合检索。2. 优化提示词加入“请基于已知信息尽力回答”等鼓励性语句。3. 适当调高temperature如从0调到0.2但需注意可能增加幻觉。Agent“幻觉”严重编造信息1. 检索到的上下文信息不足或噪声大。2. 提示词未强调“严格依据上下文”。3. 使用的LLM本身幻觉率较高。1. 提升检索质量见上一节优化方法。2. 在提示词中明确指令“你的回答必须严格且仅依据提供的上下文信息。如果上下文信息不足以回答问题请直接说‘根据现有信息无法回答’。”3. 考虑换用幻觉率较低的模型或在最终答案前增加一个“事实核查”步骤让另一个Agent或规则校验关键事实。工具调用错误或格式不对1. 工具描述不清晰。2. LLM未能正确理解用户意图并映射到工具。3. 工具函数本身对输入格式要求严格。1. 重写工具描述使其更精确包含输入输出示例。2. 在调用工具前可以增加一个“意图识别”或“参数提取”的步骤先用LLM解析出结构化信息。3. 在工具函数内部增加输入验证和类型转换提高容错性。对话上下文丢失或混乱1. 记忆管理策略不当历史记录过长或过短。2. 未正确处理多轮对话中的指代消解如“它”、“这个”。1. 采用ConversationSummaryMemory或滑动窗口记忆控制上下文长度。2. 在将用户当前输入送入Agent前可以先用一个简单的LLM调用对其进行“上下文重写”将指代替换为具体内容。例如将“它多少钱”在历史有“我看中了iPhone 15”的情况下重写为“iPhone 15多少钱”。系统响应速度慢1. 检索或工具调用网络延迟高。2. LLM生成速度慢特别是大模型。3. 未使用流式响应用户感知延迟长。1. 对知识库索引进行优化使用更快的向量数据库如PGVector的HNSW索引。对工具调用设置超时和重试。2. 考虑使用更快的模型如GPT-3.5-Turbo处理简单任务或用小模型做预处理如意图识别。3. 实现流式输出Streaming让用户先看到部分结果提升体验。5.2 从原型到生产必须考虑的工程问题当你验证了想法的可行性准备将Agent投入生产时以下几个方面的考量至关重要1. 成本控制LLM API调用是按Token计费的Agent的多次思考、工具调用和长上下文都会显著增加成本。策略设置预算和速率限制对非关键路径使用更便宜的模型缓存频繁出现的查询结果精心设计提示词以减少不必要的Token消耗。2. 可观测性与监控你需要知道Agent每天都在做什么、表现如何。必须监控的指标请求量、响应延迟、Token消耗与成本、各工具调用成功率、用户满意度可通过后续评分或分析对话情感。工具推荐如前所述Arize-Phoenix可以很好地集成进来记录每一次LLM调用和工具使用的详细信息便于事后分析和调试。3. 安全与合规数据泄露确保Agent不会在回复中泄露知识库中的敏感信息如用户数据、内部代码。可以通过在输出前添加一个“敏感信息过滤”层来实现。Prompt注入防止用户通过精心设计的输入让Agent执行非预期操作或泄露系统提示词。对用户输入进行清洗和校验使用AIR Blackbox这类工具进行运行时防护。工具权限对Agent可调用的工具进行最小权限管控。例如订单查询工具只能查询绝不能有修改或删除权限。浏览器自动化工具必须在严格的沙箱中运行。4. 评估与迭代如何衡量Agent做得好不好定义评估集收集一批真实或模拟的用户问题并准备好标准答案或评分标准。自动化评估可以使用LLM本身作为裁判LLM-as-a-Judge让一个更强的模型如GPT-4根据标准评估Agent的回答在准确性、有用性、安全性等方面的表现。列表中的ai-evaluation项目就提供了这样的框架。持续迭代根据评估结果和真实用户反馈不断优化提示词、工具集和检索策略。构建一个真正有用、可靠的AI Agent是一个持续迭代的工程过程而不是一蹴而就的魔法。Awesome Agents列表为你提供了丰富的“乐高积木”但最终搭建出什么取决于你对业务问题的深刻理解和对这些工具组合运用的匠心。我的建议是从小处着手选择一个最痛点的场景用最简单的架构比如LangChain 一个工具快速做出原型获得反馈然后沿着上述的路径逐步深化和扩展。这个领域变化飞快保持学习勇于实践才是最重要的。

更多文章