1. 从一次踩坑说起为什么你需要重新认识AI Agent去年年底我帮一个做电商的朋友搭智能客服系统。当时我的想法很简单——不就是调个大模型API把用户问题塞进去拿回答返回去嘛。结果上线第一天就翻车了用户问“我上周买的鞋子能退吗”模型很自信地回答说“可以退7天内无理由”但实际上那款鞋属于特价清仓品类根本不支持退货。问题出在哪模型只拿到了用户这句话它不知道订单状态、不知道商品品类、更不知道退货政策——它只是在“编”。这件事让我彻底想明白一个道理LLM本身只是一个语言引擎它不等于Agent。你把LLM当Agent用就像把发动机当整车开——能跑但跑不远而且随时可能出事。这篇内容我想跟你聊的是AI Agent到底是个什么东西它和单纯的LLM调用有什么区别核心组件有哪些以及为什么现在大家都在谈Agent而不是只谈大模型。如果你刚开始接触这个方向或者已经用LLM API做过一些东西但觉得“差点意思”那这篇内容应该能帮你把思路理清楚。我会尽量少堆术语多用实际场景来解释毕竟我自己也是从“调个API就以为懂了”的阶段过来的。2. AI Agent到底是什么拆开来看就四件事2.1 一个生活化的类比从计算器到助理你可以把LLM想象成一个知识渊博但记性很差、而且没有手脚的顾问。你问他什么他都能聊但他不知道今天几号、不能帮你查快递、也没法帮你发邮件。每次你找他他都是“第一次见你”完全不记得上次聊了什么。AI Agent呢相当于你给这个顾问配了手机、配了日历、配了邮箱账号还给了他一个笔记本记事情。这时候他就不只是“回答问题”了而是能“帮你办事”。你告诉他“帮我看看上周那个客户的订单到哪了如果超过5天没到就发个道歉邮件并给一张优惠券”他能自己去查、自己判断、自己执行。这个差别看起来简单但背后的工程复杂度差了好几个量级。2.2 Agent的四个核心组件我把Agent拆成四个部分来看这样比较清晰第一大脑LLM。这是决策核心负责理解用户意图、拆解任务、决定下一步做什么。没有LLM就没有Agent但只有LLM也成不了Agent。第二记忆Memory。分短期和长期。短期记忆就是当前对话的上下文长期记忆可能是向量数据库里存的历史交互、用户偏好、业务知识。没有记忆的Agent每次都是“失忆状态”体验极差。第三工具Tools。这是Agent的手脚。查数据库、调API、发邮件、搜网页、执行代码——这些都是工具。LLM本身不能做这些事但通过function calling机制它可以“告诉”系统去调用某个工具然后拿到结果继续推理。第四规划Planning。复杂任务不是一步能完成的。Agent需要能把“帮我订一张明天去北京的机票”拆成查航班→比价格→选座位→填乘客信息→支付→确认。这个拆解和排序的能力就是规划。很多人把RAG也当成Agent的核心组件我觉得更准确的说法是RAG是记忆系统的一种实现方式它解决的是“知识从哪来”的问题而不是Agent的全部。2.3 Agent和普通LLM调用的本质区别我画个表对比一下这样更直观维度普通LLM调用AI Agent交互模式单轮问答多轮自主决策状态管理无状态有记忆、有状态任务复杂度单步多步、可拆解外部交互无可调用工具/API错误处理无法自纠可重试、可回退典型场景文本生成、翻译客服、自动化流程、数据分析普通LLM调用就像你问Siri“今天天气怎么样”它查一下告诉你。Agent更像你跟一个助理说“帮我安排下周的出差”它会自己去查航班、订酒店、排日程、发确认邮件。3. 为什么现在都在谈AgentLLM的能力边界到了3.1 LLM能做什么、不能做什么LLM很强强在语言理解、文本生成、知识问答、代码编写。但它有几个硬伤没有实时信息训练数据有截止日期今天发生的新闻它不知道不能执行动作它只能输出文本不能真的帮你发邮件、改数据库没有持久记忆每次对话都是独立的除非你手动把历史塞进去容易幻觉不知道的事情它会编而且编得很像真的不能保证一致性同样的输入两次输出可能不一样这些硬伤单靠“换个更大的模型”是解决不了的。你需要在外面套一层工程架构来补足——这层架构就是Agent。3.2 Function Calling让LLM从“说”到“做”的关键机制Function Calling是OpenAI在2023年6月推出的一个能力后来各家模型基本都跟进了。它的核心逻辑是你告诉模型“我有这几个函数可以用分别是干什么的、需要什么参数”模型在回答时如果觉得需要调用某个函数它不会直接回答用户而是输出一个结构化的调用请求。举个例子你定义了一个函数{ name: get_order_status, description: 查询订单状态, parameters: { order_id: {type: string, description: 订单编号} } }用户问“我的订单12345到哪了”模型会输出{ function_call: { name: get_order_status, arguments: {\order_id\: \12345\} } }你的系统拿到这个请求去查数据库把结果返回给模型模型再组织成自然语言回答用户。这个机制看起来简单但它是Agent从“聊天机器人”进化到“任务执行者”的关键一步。没有function callingAgent就只能“说”有了它Agent才能“做”。3.3 RAG解决知识时效性和准确性的工程方案RAGRetrieval-Augmented Generation这个词现在很火但很多人理解得比较窄。我觉得RAG本质上解决的是一个很朴素的问题模型不知道的东西你去查了再告诉它。流程大概是用户提问→把问题向量化→在知识库里检索最相关的文档片段→把问题和检索结果一起塞给LLM→LLM基于检索结果生成回答。这样做的好处是知识可以实时更新不用重新训练模型回答有据可查减少幻觉可以接入私有数据比如公司内部文档但RAG也有瓶颈。我踩过的坑包括检索不准导致答非所问、文档切分粒度不好导致上下文断裂、多跳问题需要多次检索但流程不支持。这些问题后面会展开讲。4. Agent的核心技术栈从LLM到完整系统4.1 LLM选型不是越大越好选LLM的时候很多人第一反应是“用最强的”。但实际做Agent你要考虑的是延迟Agent往往需要多次调用LLM单次延迟高的话整体体验会很差成本复杂任务可能调用几十次token消耗要算清楚function calling支持不是所有模型都支持或者支持得好上下文长度Agent需要塞入历史、工具定义、检索结果上下文不够用会很痛苦本地部署需求有些场景数据不能出内网就得考虑本地模型我自己的经验是简单任务用中等模型就够了复杂推理再用强模型。混合使用比全用最强模型划算得多。4.2 记忆系统短期和长期怎么配合短期记忆就是对话历史直接放在prompt里。但上下文长度有限不能无限塞。常见的做法是保留最近N轮对话对更早的对话做摘要关键信息抽取成结构化数据存起来长期记忆一般用向量数据库比如Milvus、Pinecone、Weaviate这些。把历史交互、业务知识、用户偏好向量化存进去需要的时候检索出来。这里有个容易忽略的点记忆不是越多越好。检索回来一堆不相关的记忆反而会干扰模型判断。检索的精度比数量重要得多。4.3 工具系统Agent的能力边界工具系统决定了Agent能做什么。常见的工具类型包括信息查询类查数据库、搜网页、读文件操作执行类发邮件、创建工单、修改数据计算类执行代码、调计算器通信类发消息、调API设计工具的时候有几个原则描述要清晰模型靠描述来判断什么时候用哪个工具描述模糊它就会乱用参数要简单参数太多太复杂模型容易填错错误要可读工具执行失败时返回的错误信息要能让模型理解这样它才能决定是重试还是换方案权限要控制不是所有工具都对所有用户开放要有权限校验4.4 规划能力复杂任务怎么拆规划是Agent最核心也最难的部分。简单任务一步就完了复杂任务需要拆解、排序、处理依赖关系。常见的规划模式有ReAct推理→行动→观察→再推理循环直到任务完成Plan-and-Execute先制定完整计划再逐步执行Tree of Thoughts探索多条路径选最优的实际用下来ReAct最适合大多数场景因为它灵活、容错好。Plan-and-Execute适合步骤明确的流程化任务。Tree of Thoughts成本高一般只在特别复杂的决策场景用。5. 动手搭一个最小可用Agent从零到跑通5.1 环境准备和依赖安装我用Python来演示因为生态最成熟。需要的东西不多pip install openai langchain chromadb如果你要用本地模型可以装ollama# macOS brew install ollama ollama pull qwen2.5:7b我选qwen2.5:7b是因为它在中文场景下表现不错而且7B参数在Mac上跑得动。如果你机器配置好可以上更大的模型。5.2 定义工具函数先定义两个简单工具查天气和查订单。import json def get_weather(city: str) - str: 查询指定城市的天气 # 实际项目里这里调天气API这里模拟返回 weather_data { 北京: 晴15-25度, 上海: 多云18-28度, 深圳: 阵雨22-30度 } return weather_data.get(city, f暂时查不到{city}的天气) def get_order_status(order_id: str) - str: 查询订单状态 # 模拟数据 orders { 12345: 已发货预计明天送达, 67890: 待付款, 11111: 已签收 } return orders.get(order_id, f订单{order_id}不存在)5.3 构建Agent主循环核心逻辑就是一个while循环调模型→看要不要调工具→调工具→把结果塞回去→再调模型。from openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } }, { type: function, function: { name: get_order_status, description: 查询订单状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单编号} }, required: [order_id] } } } ] def run_agent(user_input: str, max_turns: int 5): messages [ {role: system, content: 你是一个有帮助的助理可以查天气和订单状态。}, {role: user, content: user_input} ] for _ in range(max_turns): response client.chat.completions.create( modelqwen2.5:7b, messagesmessages, toolstools ) msg response.choices[0].message if msg.tool_calls: messages.append(msg) for tool_call in msg.tool_calls: func_name tool_call.function.name args json.loads(tool_call.function.arguments) if func_name get_weather: result get_weather(**args) elif func_name get_order_status: result get_order_status(**args) else: result 未知工具 messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) else: return msg.content return 任务未在限定轮次内完成5.4 跑起来看看效果print(run_agent(北京今天天气怎么样)) print(run_agent(帮我查一下订单12345的状态)) print(run_agent(北京天气好的话帮我看看订单12345到哪了))第三个问题会触发两次工具调用先查天气再查订单。这就是Agent和普通LLM调用的区别——它能根据中间结果决定下一步做什么。注意max_turns一定要设上限。我见过有人忘了设Agent陷入死循环一晚上烧了几百块token。6. 常见问题与排查技巧实录6.1 模型不调用工具怎么办这是最常见的问题。模型明明有工具可用但它就是直接回答不调工具。原因通常有几个工具描述不清楚模型不知道什么时候该用。解决方法是把description写得更具体加上使用场景说明。系统提示没引导在system prompt里明确说“需要查询实时信息时请调用相应工具”。模型能力不够有些小模型function calling能力很弱换个模型试试。6.2 工具调用参数填错模型把参数名写错、格式写错、或者漏填必填参数。排查思路检查parameters的schema定义是否清晰参数名用英文别用中文必填参数在required里列清楚给参数加description说明格式要求6.3 多轮调用后上下文爆炸Agent跑几轮之后messages越来越长token消耗飙升。解决办法设置max_turns限制对历史消息做摘要压缩工具返回结果太长的话截断或摘要后再塞回去6.4 RAG检索不准导致答非所问这是RAG最头疼的问题。我踩过的坑和对应的解法问题现象可能原因解决方向检索结果和问题无关向量模型不适合中文换中文优化的embedding模型答案不完整文档切分太碎调整chunk size增加重叠多跳问题答不了单次检索不够引入多轮检索或查询改写检索到旧版本知识库没更新建立定期更新机制6.5 Agent陷入死循环Agent反复调同一个工具或者在不同工具之间来回跳。排查检查工具返回的错误信息是否清晰模型能不能理解设置最大轮次硬限制在system prompt里加“如果连续两次得到相同结果请停止并告知用户”7. 几个容易踩的认知坑7.1 把Agent当万能药不是所有场景都需要Agent。简单的文本生成、翻译、摘要直接调LLM就够了。Agent适合的是多步骤、需要外部信息、需要执行动作的场景。硬套Agent只会增加复杂度和成本。7.2 忽视错误处理Demo跑通和线上可用是两回事。线上环境工具会超时、API会限流、模型会抽风。每个环节都要有降级方案和重试机制。7.3 过度依赖单次LLM输出Agent的每一步决策都依赖LLM但LLM输出不稳定。关键决策点要有校验逻辑不能全信模型。7.4 忽略成本控制Agent一次任务可能调十几次LLMtoken消耗是普通对话的几十倍。上线前一定要算清楚成本设置预算上限。8. 下一步可以怎么深入这篇内容把AI Agent的基本概念和最小实现讲清楚了。但真正要做好一个生产级Agent还有很多要深入的地方多Agent协作多个Agent分工配合比如一个负责检索、一个负责推理、一个负责执行评估体系怎么衡量Agent好不好用需要建立一套评估指标和测试集可观测性Agent的决策过程是黑盒需要日志、追踪、可视化来排查问题安全与权限Agent能执行操作就必须有权限控制和审计我自己在做的项目里最花时间的其实不是搭框架而是调prompt和做错误处理。框架搭起来可能就一两天但让它在各种边界情况下稳定运行需要反复测试和迭代。如果你刚开始学建议先从最小可用的例子跑通然后逐步加工具、加记忆、加规划。别一上来就追求大而全的架构那样很容易卡住。先把一个简单场景做稳定再扩展这个路径最踏实。