AI Agent从零到一：函数调用、ReAct与RAG实战路径解析

这次我们来看一个标题非常“卷”的AI Agent学习资料全748集、2026最新版、七天从小白到大神、学完即就业。B站上这类标题太多了但AI Agent这个方向本身确实值得认真跟一遍。它解决的问题已经从“怎么让大模型聊天”变成了“怎么让大模型变成一个能自己拆任务、调用工具、查资料、执行代码、最终交付结果的数字员工”。无论你是后端开发、前端工程师还是做数据分析、产品设计这套能力在未来两年都会直接影响你的自动化能走到多深。这篇文章不打算替任何课程做评价而是把AI Agent从零到一的学习路径拆开讲环境怎么准备、第一个Agent怎么跑起来、函数调用和ReAct循环到底怎么实现、RAG和多Agent协作应该接到哪一步、最常见的坑有哪些。全程以可运行的代码和可验证的结果为准。跟着文章写下来你会得到一个能真正执行的Agent雏形而不是停留在“看过教程但不会动手”的状态。先说我对“七天速成”这类标题的判断七天从零到能跑通一个带工具调用的Agent完全可以做到七天从小白变成“大神”大概率不现实。真正决定学习效果的不是你收藏了多少集视频而是第一天是否真的跑通了一次LLM调用第三天是否真的实现了函数调用第五天是否真的把RAG接进了知识库。所以下面所有章节都按“先跑通再深入”的顺序设计适合放在你动手写Agent的前七天反复对照。围绕这个目标本文会带你把以下内容完整过一遍大模型API调用与本地环境配置、Function Calling工具调用、ReAct模式手写实现、主流Agent框架对比、RAG检索增强和记忆机制、多Agent协作编排以及生产落地时的成本、并发、安全和排查思路。下面直接进入正文。1. AI Agent 学习路线核心内容速览先把整套知识体系拆成模块方便后面逐项对照自查。这里的顺序不是我随便排的它是从最简单到最接近生产环境的实际路径。学习阶段核心技能主要工具/框架对应产出第一阶段LLM API调用、messages结构、参数理解OpenAI SDK、DeepSeek、通义、智谱命令行对话小程序第二阶段Prompt结构设计、角色设定、Few-shot任意大模型API稳定可复用的Prompt模板第三阶段Function Calling、工具注册、参数JSON SchemaOpenAI SDK、各家兼容接口能查天气、算数、调数据库的Agent第四阶段ReAct循环、任务规划、状态管理手写循环、LangGraph能自主执行多步任务的Agent第五阶段RAG、向量检索、文本切片、EmbeddingFAISS、Chroma、pgvector、Embedding模型能回答私有文档问题的知识库Agent第六阶段多Agent协作、工作流编排、评审批量LangGraph、OpenAI Agents SDK、Dify/Coze多角色协作的Agent工作流1.1 第一阶段把大模型API当成最基础的能力不要一上来就碰LangChain或者任何复杂框架。第一周只需要把“用代码调用大模型”这件事跑通包括读取环境变量、构造messages列表、设置temperature、理解返回里的choices和usage字段。这个阶段80%的报错来自API Key配置错误、模型名写错、网络不通、messages格式不合法。先把这个最小链路打通后面所有Agent能力都是在这条链路上加东西。1.2 第二阶段Prompt工程不是玄学Prompt是Agent的“操作系统”同一个模型在不同System Prompt下表现差异巨大。学习重点包括结构化指令拆解、示例注入Few-shot、约束输出格式比如强制输出JSON以及如何通过迭代减少幻觉。评价Prompt好坏的标准很简单同一组输入在多轮测试下输出是否稳定而不是单次看起来“聪明”。1.3 第三阶段工具调用是Agent和聊天机器人的分水岭这是最关键的界限。没有工具调用大模型只能输出文本有工具调用模型才能执行动作比如查询数据库、调用HTTP接口、执行Python脚本。你写的函数仍然是普通函数但通过JSON Schema描述后模型会在合适的时机主动要求调用它你的代码执行完再把结果回传给模型。后面所有Agent能力都建立在“模型能触发外部动作”这一层上。1.4 第四阶段到第六阶段从单体到协作RAG解决“模型知识过时、不懂私有数据”的问题多Agent解决“单一大模型做不完的复杂任务”的问题。到这一步已经接近生产环境里的编排能力需要开始关注状态机、失败重试、Token成本和可观测性。下面逐章展开。2. AI Agent 适用人群与学习边界2.1 适合哪些人有Python基础会写函数、会pip安装依赖、能看懂常见报错用过ChatGPT、Kimi、DeepSeek等对话产品理解“输入提示词、得到输出”的基本过程。更具体地说后端开发想把LLM接入业务系统前端开发想快速搭建AI类应用数据分析师想用Agent完成报表提取和自动分析产品经理想理解AI自动化边界。这四类人都适合按这条路线学。2.2 不建议哪些人先学完全不会编程且不愿意动手查文档的人纯看视频会陷入“眼睛会了、手不会”的状态。想从零训练大模型的人Agent开发本质是应用工程不是模型训练。没有任何API预算的人学习过程需要少量调用费用但量级不大每天几块钱是正常的。这里先讲清楚可以避免后面学一半发现方向不对。2.3 学习边界与合规提醒Agent能自动化执行任务意味着它也可以被用来做批量注册、抢购、骚扰、绕过平台规则等事情。这些场景不要碰。涉及用户数据和私有文档时要注意脱敏与授权不能把敏感内容直接塞给外部API却不做评估。调用任何大模型API都要遵守服务商的使用条款发布商用Agent前也要对输出内容做人工复核。技术本身是中性的但落地场景必须合法、合规、尊重版权和隐私。3. AI Agent 本地开发环境准备与最小运行配置3.1 操作系统与Python版本Windows、macOS、Linux都可以跑。Python建议3.10及以上低版本在部分新SDK上会报依赖错误。强烈建议用虚拟环境不要往系统Python里直接装包否则后面改版本很容易互相污染。3.2 安装依赖先建一个项目目录和虚拟环境再安装核心依赖。这一步做完你的环境就干净了。mkdir ai-agent-practice cd ai-agent-practice python -m venv venv # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate pip install --upgrade pip pip install openai python-dotenvopenai这个SDK不只可以调OpenAI官方服务国内很多大模型服务商都提供了OpenAI兼容接口只需要改base_url和api_key所以下面的代码可以复用。3.3 获取API Key和环境变量以OpenAI兼容接口为例你需要一个API Key和一个Base URL。在服务商控制台创建Key后把信息写入项目根目录的.env文件不要写进代码里。# .env OPENAI_API_KEY你的key OPENAI_BASE_URLhttps://api.deepseek.com这里写的Base URL是示例实际以你选择的服务商文档为准。如果使用OpenAI官方服务base_url这一项可以去掉SDK默认会走官方地址。3.4 最小连通性测试先跑一段最简单的对话调用确认环境已经通了。这一步非常重要后面所有Agent实验都建立在这个最小连接之上。from openai import OpenAI import os from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 你好请回复一句话}] ) print(resp.choices[0].message.content)只要正常打印出回复就说明API Key、网络、模型名和依赖库都没问题。这里有个细节模型名必须写服务商实际提供的名称不要照抄我例子里的“deepseek-chat”如果你用的是通义、智谱或者OpenAI模型名都不一样。3.5 成本与性能观察LLM按Token计费。学习阶段建议用小模型、短上下文跑通再切到更强模型。每个测试脚本都打印usage能让你直观了解一次请求消耗多少Token避免月底账单惊吓。print(resp.usage)从这一步开始你就要建立“Token消耗钱”的意识。Agent和普通聊天不同一个带工具调用的任务可能要来回好几轮一次用户提问消耗的Token可能是直接聊天的3到5倍。4. 从零搭建第一个Agent代码实操4.1 从纯聊天到“能动手”最普通的对话调用模型只能输出文字。要让Agent“动手”需要三步定义一个真实函数、把函数描述传给模型、在返回tool_calls时执行函数。下面按这个顺序走一遍。4.2 定义一个工具查询天气先不接真实天气API用一个模拟函数演示。真实的Agent开发中这个函数可以换成查询数据库、调用公司内部HTTP接口、读写文件或者执行一个Python脚本。def get_weather(city: str) - str: weather_map { 北京: 晴25℃, 上海: 多云28℃, 广州: 小雨30℃, } return weather_map.get(city, f暂无{city}的天气数据)然后把函数描述信息以JSON Schema的形式传给模型。注意描述字段要写清楚模型靠它判断什么场景下调用这个函数。tools [ { type: function, function: { name: get_weather, description: 查询某个城市的天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } } } ]这就是Function Calling的核心模型不直接执行函数只负责根据用户问题输出一个结构化的调用请求。真正的执行永远由你的代码完成模型不碰真实系统。4.3 完整Agent主循环下面这段代码是Agent的最小骨架把用户消息发给模型模型返回tool_calls就执行函数执行结果作为tool消息回传模型再生成最终回答。加一个最大循环次数防止Agent陷入死循环。import json def run_agent(user_input: str): messages [{role: user, content: user_input}] for _ in range(5): resp client.chat.completions.create( modeldeepseek-chat, messagesmessages, toolstools, tool_choiceauto, ) msg resp.choices[0].message messages.append(msg) if msg.tool_calls: for call in msg.tool_calls: fn_name call.function.name args json.loads(call.function.arguments) print(f[Tool Call] {fn_name}({args})) result get_weather(args[city]) messages.append({ role: tool, tool_call_id: call.id, content: json.dumps({city: args[city], weather: result}, ensure_asciiFalse) }) else: return msg.content return 已到达最大循环次数 print(run_agent(北京现在天气怎么样))4.4 预期结果与失败排查运行后如果一切正常你会看到类似输出[Tool Call] get_weather({city: 北京}) 北京的天气是晴25℃如果模型直接回答而没有调用工具常见原因有三个模型名不支持function calling、tools参数没传全、System Prompt里没有引导。可以先把代码精简到上面这个最小状态跑通后再加Prompt。也可以显式加一句“如果需要天气请调用get_weather工具查询”来测试。5. Agent 核心机制函数调用与ReAct模式5.1 为什么ReAct是Agent的底层公式ReAct的全称是Reasoning Acting思想就一句话模型在“思考”、“行动”、“观察结果”之间循环直到得出最终答案。每一次循环模型先分析当前状态决定调用哪个工具工具返回结果后模型再继续分析。这个循环就是Agent最基本的智能来源。用Function Calling实现ReAct更稳定因为调用格式是结构化JSON模型不容易“乱说话”。也可以不用Function Calling而是让模型输出纯文本的“思考...行动...”格式再由代码解析。两种方式都值得实现一遍前者适合生产后者能帮你深刻理解机制。5.2 手动实现一个文本式ReAct循环下面这个版本不依赖Function Calling直接用提示词让模型输出思考过程和工具调用程序解析并执行。这段代码的价值是让你看到ReAct的本质不借助任何框架。from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) MODEL 你的模型名 def call_llm(prompt: str) - str: resp client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content def run_react(query: str, max_steps: int 5): prompt f你是一个能调用工具的智能体。请按以下格式输出 思考说明你当前的想法 行动get_weather(city) 观测工具返回的结果 根据观测继续思考直到得出最终答案输出最终答案... 可用工具get_weather(city) 用户问题{query} for step in range(max_steps): output call_llm(prompt) print(f--- Step {step 1} ---) print(output) if 最终答案 in output: return output if get_weather( in output: city output.split(get_weather()[1].split())[0].strip().strip(\) observation f天气观测{get_weather(city)} prompt f\n{output}\n观测{observation}\n return 达到最大步数运行这段代码时重点看模型的“思考”部分它会先说自己需要天气数据然后调用工具拿到观测结果后再生成回答。这个过程和Function Calling在原理上完全一致只是传输格式不同。5.3 从循环到图状态手写循环适合理解原理但社区生产环境中越来越多项目用LangGraph这类图状态框架。LangGraph把Agent的每一步建模成“节点”和“边”状态是显式的节点之间可以分支、循环、条件跳转。这样复杂Agent不再是写死在Python循环里的代码而是可以由开发者在图上设计和调试。from typing import TypedDict from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): input: str output: str def process_node(state: AgentState): return {output: f处理完成: {state[input]}} graph StateGraph(AgentState) graph.add_node(process, process_node) graph.add_edge(START, process) graph.add_edge(process, END) app graph.compile() result app.invoke({input: hello agent}) print(result)上面是最小的LangGraph示例代码本身没有业务意义只是帮你确认框架能跑通。实际项目中流程会复杂很多一个节点调用工具一个节点做判断一个节点失败重试再通过条件边把控制流转到正确的分支。6. 主流框架与平台怎么选框架选择在Agent学习中一直很纠结。我这里给一个务实结论不要一开始就锁死某个框架先用裸API跑通Small Demo再按项目阶段选工具。6.1 OpenAI Agents SDK轻量级Agent运行时OpenAI Agents SDK是官方维护的Agent运行时比LangChain轻很多API设计也更贴近普通Python开发。核心概念是Agent、Tool和Runner可以用装饰器直接把普通函数变成Agent工具。pip install openai-agentsfrom agents import Agent, Runner, function_tool function_tool def get_weather(city: str) - str: 查询指定城市的天气 return 晴25℃ agent Agent( nameweather_agent, instructions你是天气助手用户问天气时使用工具查询。, tools[get_weather], ) result Runner.run_sync(agent, 北京天气怎么样) print(result.final_output)这套SDK比较好的一点是多Agent切换和Handoff更自然。写一个能调工具的单体Agent代码量很小。适合刚入门、想把代码控制在自己手里的开发者。6.2 LangChain / LangGraph复杂流程编排LangChain的生态大组件多从Prompt管理到模型封装都有但也因为抽象层太厚很多初学者学了半天还是不会排查问题。LangGraph是LangChain团队后来主推的图编排框架设计比LangChain本身更工程化。如果你要做的流程包含多个分支、条件判断、并行任务和长期记忆LangGraph更值得投入时间。pip install langgraphLangGraph的中文资料越来越多建议直接看官方文档里的“Quick Start”把图状态、节点、边、编译执行这四个概念掌握后面都是在这四个概念上扩展。6.3 Dify / Coze可视化低代码平台如果你不想写大量代码或者需要一个能给业务同学直接用的后台Dify和Coze是很好的选择。Dify适合私有化部署支持工作流编排、知识库、API发布Coze适合快速做Bot对国内即时通讯渠道支持友好。这类平台的价值是“让Agent开发变成搭积木”但代价是灵活性受限。学习的时候我建议两件事都做低代码平台用来快速验证业务想法代码方式用来深度掌握原理。两者并不冲突。6.4 框架选型速查表框架/平台定位适合场景学习成本OpenAI Agents SDK轻量Agent运行时单体Agent、少量工具、快速开发低LangChain组件库需要大量模型/工具封装中LangGraph图状态编排复杂流程、多分支、多Agent协作中高Dify可视化平台私有化部署、业务后台、知识库应用低Coze可视化平台快速搭建对话Bot、多渠道发布低选型逻辑很简单项目流程固定、需要细粒度控制选代码方案业务同学要自己调Agent选可视化方案。不要因为某个框架“热门”就无脑引入先在代码层理解清楚Agent是怎么跑的再决定要不要用框架简化。7. RAG与记忆让Agent具备领域知识7.1 为什么需要RAG大模型训练数据有截止时间也不包含你的内部文档直接问“我们公司上个月的销售数据是多少”基本得不到正确结果。RAG检索增强生成的思路是先把文档切成小块每块转成向量存进向量库用户提问时先检索最相关的几个文本块再把这些文本块连同问题一起发给大模型生成回答。这样模型不用“记住”私有知识而是“查”到私有知识。RAG是Agent落地中最常用也最容易被低估的能力。没有RAG的Agent只能处理通用知识有了RAG才能回答和业务强相关的问题也才能在回答中附上引用来源减少幻觉。7.2 最小RAG实现这里用OpenAI兼容的Embedding接口和numpy做向量检索不引入重型向量数据库方便你先理解原理。正式项目推荐用FAISS、Chroma或pgvector。import numpy as np from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) def embed(texts): resp client.embeddings.create( modeltext-embedding-3-small, inputtexts ) return [item.embedding for item in resp.data] chunks [ AI Agent可以调用外部工具完成复杂任务。, ReAct模式让模型在思考与行动之间交替。, 通过RAG可以引入私有知识库。, ] vectors np.array(embed(chunks)) def normalize(v): return v / np.linalg.norm(v, axis-1, keepdimsTrue) vectors normalize(vectors) def search(query, top_k1): q_vec normalize(np.array(embed([query]))) scores vectors q_vec.T idx np.argsort(scores, axis0)[::-1][:top_k] return [chunks[i] for i in idx.flatten()] print(search(模型如何调用工具))运行后会看到它返回与“调用工具”最相关的文档块再把检索结果和大模型结合就完成了一次RAG问答。文本切片的大小、检索返回的块数、Embedding模型的质量都会影响最终效果这个在正式项目中需要反复调。7.3 记忆管理与上下文控制Agent的“记忆”分为几层。短期记忆就是当前对话的messages列表所有上下文都堆在这里但随着轮次增加Token消耗会很快变大。长期记忆一般存在外部存储里比如用户画像、历史偏好、向量库中的历史摘要需要时才检索出来注入Prompt。一个实用技巧是“摘要压缩”当对话太长时让模型把前面内容压缩成摘要只保留关键信息再与新问题一起继续生成。这能显著降低Token消耗也是很多生产级Agent会用的手段。学习阶段建议打印每次请求的usage你会看到上下文长度对成本的直接影响。8. 多Agent协作与工作流编排8.1 三种常见协作模式多Agent不是“Agent数量越多越好”而是“角色拆分得越清楚越有效”。最常见的三种模式一是主从模式一个Manager Agent负责拆解任务分发给多个Worker Agent执行最后汇总结果。适合“研究一个问题后出报告”这类场景。二是流水线模式A Agent生成内容B Agent润色C Agent检查格式每个角色只做一件事适合内容生产流程。三是评审模式一个Agent写一个Agent审审完打回重写适合代码生成、文案质量要求高的场景。设计多Agent工作流时要保证每个子Agent的职责边界清晰输入输出字段明确。否则你会在日志里看到两个Agent互相踢皮球谁也完成不了任务。8.2 一个简单的主从协作示例以OpenAI Agents SDK为例看一下两个Agent如何接力from agents import Agent, Runner writer Agent( namewriter, instructions你是文案写手输出200字以内的产品介绍。, ) reviewer Agent( namereviewer, instructions你是资深评审检查文案是否有错别字、逻辑是否清晰并给出修改建议。, ) draft Runner.run_sync(writer, 写一段关于智能手表的介绍) review Runner.run_sync( reviewer, f请评审以下文案\n{draft.final_output} ) print(review.final_output)这个例子虽然短但已经是多Agent协作的雏形。真实项目中会把draft结果传给后续节点也可能接入人的确认环节。多Agent的价值不在于“看起来高级”而是把复杂任务拆成多个可测试、可复用的子任务每个子任务单独优化。再往后就是给Agent加人工审批、Failover机制、可观测日志、超时控制。这里建议先跑通两个Agent的接力再逐步增加Agent数量尽量不要一次性设计超过五个Agent的系统复杂度会指数上升。9. AI Agent 常见问题与排查方法Agent开发和普通后端开发最大的区别是它的行为有一部分不可控。同样的Prompt两次运行结果可能不同。所以排查问题时要更加依赖日志和可复现的测试用例。下面这张表覆盖了入门阶段最常见的几类问题。问题现象可能原因排查方式解决方案API调用返回401API Key错误或过期检查环境变量是否加载打印Key后几位重新创建Key并更新.env返回404 model not found模型名不存在或未开通到服务商控制台确认模型名修改model参数工具调用不触发tools参数未传、模型不支持Function Calling打印完整请求参数确认tools已传入换支持工具调用的模型Agent循环到最大步数工具结果无法让模型收敛打印每轮输出定位卡在哪一步增加终止条件、减少工具数量中文乱码终端编码问题检查终端编码设置设置UTF-8编码Token消耗超预期上下文过长、模型过大、循环轮次过多打印usage字段用小模型、压缩上下文、限制轮次同样输入两次结果不同采样温度过高降低temperature或固定seed调到0.1-0.3再测试排查Agent问题的通用顺序是先看请求日志确认模型收到了什么再看工具调用结果确认函数返回了什么最后看模型最终回答确认它基于什么信息生成了结果。三段式日志能定位绝大多数问题。不要把Agent当成黑盒它每一步都会有输出输出就是排查线索。10. 学习计划与避坑建议10.1 七天入门计划这个计划是给有Python基础、每天能投入两小时的人准备的。完成标准不是“看完了”而是“跑通了”。时间任务完成标准Day1跑通LLM API调用命令行能输出模型回复Day2设计3个不同System Prompt并对比能说明输出差异的原因Day3实现一次Function Calling模型能根据问题调用工具Day4手写ReAct循环能处理至少3轮工具调用Day5接入向量检索完成RAGAgent能回答私有文档问题Day6两个Agent接力协作完成一次多Agent流程Day7做一个综合项目知识库问答Agent或工单分类Agent如果中间某天卡住不要急着往前赶。任何一个环节没跑通后面都会放大问题。比如Function Calling没理解清楚后面RAG做出来也只是“搜索聊天”不是一个真正的Agent。10.2 最值得避开的三个坑第一个坑是只收藏不实践。收藏748集教程不如自己跑通十个最小Demo。第二个坑是一上来就啃框架源码。框架只是工具核心是LLM API、Function Calling、Prompt、状态管理这四个概念先掌握这些框架