1. 从会聊天的模型到能办事的Agent认知分水岭在哪很多人第一次接触 AI Agent脑子里浮现的画面是一个更聪明的聊天机器人。这个理解不算错但差得远。聊天机器人解决的是信息问答而 Agent 解决的是任务闭环。这两者之间的差距就像会背菜谱和能下厨做出一桌菜的差距——前者只需要语言能力后者需要理解目标、拆解步骤、调用工具、处理意外、验证结果。我刚开始接触这个概念时也走过弯路。当时觉得给大模型加个系统提示词让它扮演一个助手这不就是 Agent 了吗后来在实际项目里踩了坑才明白Agent 的核心不在于扮演而在于自主行动。一个真正的 Agent你给它一个目标它会自己决定先做什么、后做什么、用什么工具、遇到问题怎么调整最后把结果交给你。整个过程不需要你一步步喂指令。这里有个关键区分点值得先说清楚。普通的大模型调用是一问一答的单轮或有限多轮交互模型只负责生成文本至于这段文本对不对、能不能用、下一步该干嘛全靠人来判断和推进。而 Agent 是一个带反馈回路的系统它生成行动方案执行观察执行结果根据结果修正方案再执行直到达成目标或判定无法达成。这个生成-执行-观察-修正的循环才是 Agent 的灵魂。那为什么现在 Agent 突然火起来了因为三个条件同时成熟了。第一大模型的推理能力到了能支撑多步规划的阈值尤其是 function calling 能力的标准化让模型可以直接输出结构化的工具调用指令。第二工具生态丰富了搜索、代码执行、数据库查询、API 调用这些能力都能被封装成模型可调用的函数。第三工程框架成熟了像 LangChain、Dify、CrewAI 这类框架把编排、记忆、工具管理这些脏活累活都做了封装开发者不用从零造轮子。所以这篇内容适合谁看如果你是刚听说 AI Agent 这个词、想搞清楚它到底和普通大模型应用有什么区别的开发者这篇能帮你建立正确的认知框架。如果你已经在用大模型做产品但发现只能聊天、办不了事这篇能帮你理解差在哪、该补什么。如果你只是想了解这个技术方向值不值得投入学习我也会在最后给出我的判断。提示本文是 AI Agent 系列的第一篇定位是建立认知地图不涉及具体代码实现。后续会逐步展开工具调用、记忆机制、多 Agent 协作等实操内容。先把概念理清楚后面动手才不会迷路。2. Agent 的四大核心组件拆开看它到底由什么构成要理解 Agent最好的办法是把它拆开。不管框架怎么变、叫法怎么花哨一个完整的 Agent 系统基本都由四个核心组件构成大脑LLM、工具Tools、记忆Memory、规划Planning。这四个东西各司其职缺一个都会导致 Agent 残疾。2.1 大脑LLM 在 Agent 里扮演什么角色LLM 是 Agent 的推理引擎负责理解目标、做决策、生成行动指令。但要注意Agent 里的 LLM 和聊天场景里的 LLM 用法完全不同。聊天场景下你希望模型输出好听的话Agent 场景下你希望模型输出可执行的决策。这就带来一个关键差异Agent 对 LLM 的要求不是知识渊博而是指令遵循和结构化输出。模型需要能稳定地输出 JSON 格式的工具调用请求需要能理解我现在有哪些工具可用需要能根据历史步骤判断下一步该做什么。这些能力里指令遵循比知识储备重要得多。我实测下来的感受是选 Agent 的底层模型时不要只看跑分排行榜。有些模型在知识问答上表现很好但一到结构化输出就胡言乱语JSON 格式老是出错这种模型做 Agent 会很痛苦。反而是一些专门优化过 function calling 的模型虽然通用知识稍弱但做 Agent 的稳定性高出一大截。选型时一定要拿真实的工具调用场景去测别只看通用评测。另外模型的上下文窗口大小在 Agent 场景下格外重要。因为 Agent 执行多步任务时每一步的输入输出都要塞进上下文步数一多上下文消耗非常快。一个需要十步才能完成的任务如果每步平均消耗两千 token那就是两万 token 打底。上下文窗口不够大Agent 跑到一半就失忆了。2.2 工具Agent 的手和脚如果说 LLM 是大脑那工具就是 Agent 的手和脚。没有工具的 Agent只能动嘴皮子什么实事都办不了。工具的本质是把外部能力封装成模型可以调用的函数模型输出一个调用请求系统执行这个函数把结果返回给模型。常见的工具类型包括搜索工具让 Agent 能获取实时信息、代码执行工具让 Agent 能计算和验证、数据库查询工具让 Agent 能读取业务数据、API 调用工具让 Agent 能操作外部系统。function calling 就是实现这套机制的标准方式——模型不是直接执行函数而是输出我想调用哪个函数、传什么参数由外部系统真正执行。这里有个新手最容易踩的坑工具描述写得太随意。模型决定用不用某个工具、怎么传参数完全依赖你给的函数描述。描述写得含糊模型就会用错工具或者传错参数。我见过太多案例Agent 表现不好不是因为模型笨而是因为工具描述没写好。工具描述要像写给一个新员工看的操作手册说清楚这个工具干什么、什么时候用、每个参数什么含义、有什么限制。2.3 记忆Agent 为什么需要记住事情记忆解决的是Agent 在执行任务过程中如何记住已经发生的事。没有记忆的 Agent每一步都是失忆状态会重复劳动、会忘记目标、会前后矛盾。记忆通常分两层。短期记忆是当前任务的执行历史比如我已经查了 A 数据、算了 B 结果、现在该做 C这些信息放在上下文里让模型知道任务进行到哪了。长期记忆是跨任务的知识沉淀比如这个用户偏好什么风格上次类似任务是怎么解决的这些信息存在外部存储里需要时检索出来注入上下文。RAG检索增强生成在这里扮演了重要角色。当 Agent 需要调用大量外部知识时不可能把所有知识都塞进上下文这时候就用 RAG 从知识库里检索相关内容。但 RAG 不是万能的后面我会专门讲它的瓶颈。2.4 规划Agent 怎么把大目标拆成小步骤规划能力决定了 Agent 能不能处理复杂任务。简单任务不需要规划一步就能搞定。但复杂任务比如帮我分析这份销售数据并生成报告就需要拆解成读取数据、清洗数据、计算指标、生成图表、撰写报告文字、整合输出。这个拆解过程就是规划。规划有两种常见模式。一种是静态规划Agent 先一次性把完整步骤列出来然后按顺序执行。这种方式适合步骤明确、不太会变的任务。另一种是动态规划Agent 每执行一步就根据当前结果决定下一步边做边调整。这种方式更灵活能应对意外情况但更消耗 token也更容易跑偏。实际项目里我倾向于混合使用先做一个粗粒度的静态规划确定大方向执行过程中允许动态调整细节。纯静态太死板纯动态太发散混合模式在稳定性和灵活性之间取得平衡。组件核心作用缺失后果常见实现方式大脑LLM推理决策、生成指令无法理解目标GPT、Claude、DeepSeek 等工具Tools执行外部操作只能空谈不能办事function calling、API 封装记忆Memory保存执行历史与知识重复劳动、前后矛盾上下文窗口、向量数据库规划Planning拆解复杂任务无法处理多步任务任务分解、ReAct 模式3. Agent 的工作循环一次任务从接收到完成经历了什么理解了组件还要理解这些组件是怎么协同工作的。Agent 执行任务的过程本质上是一个循环。我用一个具体例子来拆解假设你让 Agent 帮我查一下北京今天的天气如果下雨就提醒我带伞。3.1 第一步目标理解与任务分解Agent 首先用 LLM 理解这个目标。它会识别出几个关键信息需要查询天气、地点是北京、时间是今天、有一个条件判断下雨则提醒。然后它把任务分解成步骤调用天气查询工具获取北京天气、判断是否下雨、根据判断结果决定是否输出提醒。这一步的关键在于模型能不能准确提取约束条件。如果下雨就提醒这个条件判断如果模型没理解到位可能就直接查完天气把结果丢给你忘了做判断。所以目标理解阶段提示词的设计很重要要引导模型把隐含条件也识别出来。3.2 第二步工具选择与参数构造接下来 Agent 要决定用哪个工具。假设它有一个天气查询工具参数是城市名和日期。模型需要输出一个结构化的调用请求类似{tool: get_weather, params: {city: 北京, date: today}}。这一步最容易出问题的地方是参数格式。日期是传 today 还是 2024-01-15城市名是传 北京 还是 北京市这些细节取决于你的工具怎么定义。如果工具要求标准日期格式而模型传了 today调用就会失败。所以工具的参数定义要尽可能明确最好在描述里给出示例。3.3 第三步执行与结果观察系统接收到模型的调用请求后真正执行天气查询拿到结果比如北京今天小雨气温 8-15 度。这个结果被返回给模型模型观察到这个结果然后进入下一步判断。这里有个工程上的细节工具返回的结果要尽量结构化、简洁。如果工具返回一大坨原始数据模型可能抓不住重点。最好在工具层面就把结果处理成模型容易理解的形式比如直接返回是否下雨是这样的明确字段而不是让模型自己去解析原始 JSON。3.4 第四步条件判断与最终输出模型看到下雨是结合最初的目标下雨就提醒带伞生成最终输出北京今天有小雨记得带伞。任务完成。如果结果是下雨否模型就应该输出北京今天不下雨不用带伞。这个条件分支的处理考验的是模型的推理能力。有些模型会机械地执行查天气然后就结束忘记后面的条件判断这就需要通过提示词或者流程设计来强化。整个循环可以用一个简化的伪代码来表示def run_agent(goal, tools, max_steps10): context [{role: user, content: goal}] for step in range(max_steps): # 大脑决策下一步做什么 response llm.generate(context, tools) # 如果模型认为任务完成返回结果 if response.is_final: return response.content # 否则执行工具调用 tool_result execute_tool(response.tool_call) # 把结果加入上下文进入下一轮 context.append(response.tool_call) context.append(tool_result) return 达到最大步数限制任务未完成这个循环里max_steps是个重要的安全阀。没有这个限制Agent 可能陷入死循环反复调用同一个工具却解决不了问题。设置合理的步数上限既能给 Agent 足够的空间又能防止它卡死。注意Agent 的循环不是越多越好。步数越多token 消耗越大出错概率也越高。实际项目里我一般把简单任务的步数限制设在 5 步以内复杂任务不超过 15 步。超过这个范围往往说明任务拆解有问题应该重新设计而不是硬跑。4. RAG、Function Calling 与 Agent 的关系别把它们混为一谈这三个词经常被放在一起讨论导致很多人搞不清它们的关系。我见过不少初学者以为 RAG 就是 Agent或者以为有了 function calling 就等于有了 Agent。这里必须掰扯清楚。4.1 RAG 解决的是知识从哪来的问题RAG 的全称是检索增强生成。它的核心思路是模型本身的知识有限且可能过时那就外挂一个知识库需要的时候检索相关内容塞进上下文让模型参考。RAG 解决的是模型不知道某件事的问题。但 RAG 有明显的瓶颈。第一检索质量依赖切分和向量化切得不好、向量化不准检索出来的内容就是垃圾模型再聪明也救不回来。第二RAG 只能读不能做它能帮你找到信息但不能帮你执行操作。第三多跳推理是 RAG 的软肋如果答案需要综合多个文档的信息才能得出简单的向量检索往往力不从心。这就引出了 RAG 和知识库的区分。现在常说的知识库有三类向量 RAG 知识库适合非结构化文本的语义检索**KG 知识库知识图谱**适合处理实体关系和结构化推理结构化知识库比如数据库、表格适合精确查询和统计。选哪种取决于你的数据形态和查询需求。很多项目一上来就上向量 RAG结果发现查询需要精确匹配和关系推理向量检索根本搞不定这就是选型没想清楚。4.2 Function Calling 解决的是模型怎么调用外部能力的问题Function calling 是一套标准机制让模型能输出结构化的函数调用请求。它解决的是模型想用某个工具怎么把意图准确传达给系统的问题。没有 function calling 之前大家靠提示词让模型输出特定格式的文本然后正则解析又脆弱又难维护。有了 function calling模型直接输出标准 JSON系统解析起来稳定多了。但 function calling 本身不是 Agent。它只是一个接口协议让模型和工具之间能对话。一个只有 function calling 没有规划、没有记忆、没有循环的系统只是一个能调用工具的问答机器人还不是 Agent。4.3 Agent 是知识 工具 规划 记忆的整合体Agent 是把 RAG、function calling 这些能力整合起来再加上规划循环和记忆机制形成一个能自主完成任务的系统。RAG 是 Agent 获取知识的一种手段function calling 是 Agent 调用工具的一种方式但它们都只是 Agent 的组成部分不是 Agent 本身。打个比方RAG 像是给 Agent 配了一个图书馆function calling 像是给 Agent 配了一双手但只有图书馆和手还不够还需要一个会规划、会记忆、会随机应变的大脑来统筹这一切这个整体才是 Agent。概念解决的问题在 Agent 中的角色单独使用够不够RAG知识从哪来知识检索组件不够只能读不能做Function Calling怎么调用工具工具调用协议不够没有规划和循环Agent如何自主完成任务完整系统是整合体理解了这层关系你就不会再把它们混为一谈。实际做项目时也是先判断任务需要哪些能力再决定用哪些组件而不是一股脑全上。5. 新手最容易踩的五个认知坑概念讲完了说点实在的。我在带新人和做项目的过程中发现大家对 Agent 的误解高度集中在几个点上。这些坑不避开后面动手会走很多弯路。5.1 坑一以为 Agent 越自主越好很多人觉得 Agent 就应该完全自主人不要干预。这个想法很危险。自主性越高不可控性越强。一个完全自主的 Agent可能做出你意想不到的操作调用你不希望它调用的工具甚至产生安全风险。实际项目里我建议采用有限自主的设计在关键决策点设置人工确认在危险操作前设置拦截在预算和步数上设置硬限制。Agent 的价值在于提效不在于完全替代人的判断。尤其是涉及资金、数据修改、对外发送这类操作一定要有人工确认环节。5.2 坑二忽视 token 成本跑起来才发现烧钱Agent 的多步循环意味着 token 消耗是普通问答的几倍甚至几十倍。一个普通问答可能消耗几百 token一个十步的 Agent 任务可能消耗几万 token。如果不做成本控制跑起来账单会很难看。控制成本的手段有几个一是精简上下文不要把无关信息塞进去二是合理设置步数上限防止无意义的循环三是工具返回结果要精简别返回一大堆模型用不上的数据四是根据任务复杂度选择不同档位的模型简单任务用便宜的小模型复杂任务才上大模型。5.3 坑三工具给得越多越好新手常犯的错是恨不得把所有能想到的工具都给 Agent 配上。结果工具一多模型选择困难经常用错工具或者在不该用工具的时候硬用。工具不是越多越好而是越精准越好。我的经验是针对具体场景只给必要的工具并且把每个工具的描述写清楚。如果工具数量确实多可以考虑分组或者用路由机制先让模型判断任务类型再加载对应的工具集。工具太多还会撑大提示词增加 token 消耗得不偿失。5.4 坑四不做错误处理一出错就崩Agent 执行过程中出错是常态不是例外。工具调用可能失败、模型可能输出格式错误、外部 API 可能超时。如果不做错误处理Agent 一遇到问题就卡死或者输出一堆乱码。错误处理要分层做。工具层面要有重试机制和超时控制模型层面要有输出格式校验和纠错重试系统层面要有兜底逻辑实在搞不定就优雅地告诉用户我遇到了问题需要你介入。一个健壮的 Agent不是不出错而是出错后能自己恢复或者体面地求助。5.5 坑五把 Agent 当成万能药最后一个坑最隐蔽觉得 Agent 能解决所有问题什么场景都想上 Agent。实际上很多任务用简单的规则引擎或者单次模型调用就能解决上 Agent 反而是过度设计增加了复杂度和成本。判断要不要用 Agent我的标准是任务是否需要多步、是否需要调用外部工具、是否需要根据中间结果动态调整。三个都满足才值得上 Agent。如果只是简单的信息查询或者文本生成普通的大模型调用就够了。提示这五个坑我在不同项目里都踩过。最惨的一次是没做成本控制一个测试任务跑了半小时token 消耗远超预期。从那以后我养成了先估算 token 预算、再设置硬限制的习惯。6. 从零开始的学习路径先建立框架再深入细节最后聊聊学习路径。AI Agent 这个方向知识点很多容易让人不知从哪下手。我根据自己的学习经历和带人经验梳理一条相对合理的路径。6.1 第一阶段建立概念框架先搞清楚基本概念也就是这篇内容讲的东西Agent 是什么、由哪些组件构成、和普通大模型应用有什么区别、RAG 和 function calling 在其中扮演什么角色。这个阶段不需要写代码重点是建立正确的认知地图。概念不清后面学得越多越乱。这个阶段可以多看一些综述性的内容了解 Agent 的主流架构和典型应用场景。同时动手体验一些现成的 Agent 产品感受一下它和普通聊天机器人的区别建立直观认知。6.2 第二阶段掌握核心机制概念清楚后开始深入核心机制。重点是三块function calling 的具体用法、提示词如何设计才能让模型稳定输出结构化决策、记忆机制怎么实现。这三块是 Agent 的技术底座绕不过去。这个阶段要开始动手了。可以先从最简单的单工具 Agent 做起比如一个能查天气的 Agent跑通理解目标-调用工具-返回结果的完整流程。跑通之后再逐步增加工具、增加步骤、增加条件判断复杂度一点点往上加。6.3 第三阶段熟悉框架与工程实践单打独斗跑通 demo 之后就该了解框架了。LangChain、Dify、CrewAI 这些框架各有侧重LangChain 生态最全、组件最丰富Dify 偏向低代码和可视化编排CrewAI 专注多 Agent 协作。选哪个取决于你的需求但建议至少深入用熟一个。框架能帮你省掉很多重复劳动但也别过度依赖。理解框架底层的实现原理遇到问题才能自己排查。我见过不少人只会调框架的 API框架一报错就懵了这就是没理解底层机制的结果。6.4 第四阶段在真实场景中打磨最后一步是找真实场景练手。demo 和真实项目的差距主要在异常处理、成本控制、稳定性这些工程细节上。只有真正做一个有人用的 Agent才会遇到各种边界情况才能真正理解前面讲的那些坑。我的建议是从自己工作或生活中的一个小痛点入手做一个真正能用的 Agent。哪怕很简单比如自动整理会议纪要、自动回复常见问题只要真实用起来收获就比跑十个 demo 大。关于学习节奏我的体会是不要贪快。Agent 这个领域变化很快新框架新概念层出不穷但底层的东西是相对稳定的。把底层机制吃透上层的东西学起来就快。反过来如果底层不扎实追新只会越追越焦虑。这个系列后续会逐步展开工具调用、记忆实现、多 Agent 协作、RAG 优化这些具体话题。先把这篇的认知框架建立起来后面动手时你会发现自己少走很多弯路。我个人在实际项目里最深的体会是Agent 的难点从来不在能不能跑起来而在能不能稳定可靠地跑下去而后者靠的正是对底层机制的透彻理解。
