“AI Agent 入门先学什么”这是我被问得最多的问题之一。很多新手和准备转行的朋友一上来就抱着某大模型的框架源码看结果看了一周除了把官网文档的目录背下来什么都没学会。我特别能理解这种焦虑因为Agent这个概念听起来太高级了仿佛不啃框架就落后了。但以我实际做过几个项目的经验来看AI Agent 入门最忌讳的恰恰是一上来就啃框架。框架只是把你已有的能力包装成更高级的工具如果你连底层原理都不懂框架里任何一个报错都能拦住你半天。这篇文章的目标很简单帮你把AI Agent从“听起来很神”拆解成“其实就这四件事”然后告诉你一条清晰的、不靠框架也能上手的路径顺便把我踩过的坑和总结出来的排查方法都抖出来。适合两类人看一是完全没写过代码但想了解Agent到底怎么运作的纯新手二是会一些Python、想转行做AI应用开发的程序员。看完你至少能自己手写一个最简的Agent循环也知道接下来该学什么、不学什么。1. 先别碰框架AI Agent到底是什么很多人被“Agent”这个词唬住了觉得它一定是某种神秘的黑科技。我习惯把它比喻成一个“新来的实习生”你交给他一个目标他自己琢磨需要做哪几步遇到不懂的会去查资料需要人帮忙会去问办公系统做完一部分还会回来跟你汇报最后把结果交给你。这个实习生内部干的事情拆开就是四个能力感知、推理、行动、记忆。感知就是他能接收你的指令和理解上下文推理就是他调用大模型根据信息决定下一步动作行动就是他通过某种方式改变周围的环境比如调API、写文件记忆就是他把之前的结果和状态存下来供后续决策使用。一个最简单的AI Agent其实就是一个循环模型思考当前该做什么然后调用工具拿到结果后继续思考直到任务完成。可大多数框架把这四件事全给你封装好了你看到的是一个巨大的“Agent”类里面方法几百个。你以为你创建了一个Agent并运行成功其实你只是按了一个按钮看着它动你并不明白它为什么动、在哪一步可能出错。所以新手要学的是先能手写这个循环。把骨架理解了再去看框架你一眼就知道它做了什么、自己需要覆盖哪些部分。转行的朋友更要注意面试时别人问“你做过Agent吗”你要是说“我用某框架做过”对方大概率追问“那你说说它的Message是怎么在模型和工具间流转的”。你要是能从循环、任务分解、工具注册角度讲清楚哪怕你没有用过那个框架面试官也觉得你真懂。这就是先学原理、后学框架的复利。2. 新手和转行者第一课先把语言模型调用摸熟2.1 提示词不是玄学是Agent的第一门基本功很多新手跳过提示词直接学框架觉得提示词太“文科生”了。但恰恰相反提示词是Agent的地基。Agent的“推理”能力全靠你给模型的提示词和上下文。一个Agent如果行为怪异大概率不是代码写错了而是你让模型干活的“话术”没说清楚。我建议新手做的第一件事找一个你熟悉的国产或国外大模型用它的在线Demo反复调一片提示词。不要一上来就写几千字的系统提示词应该从一句话目标开始。比如“你是一个订餐助手根据用户需求推荐餐厅并输出推荐理由。”这就算一个SuperMini Agent的核心脑。然后逐层加上限制输出格式、不能问用户哪些问题、遇到不确定怎么道歉。你会慢慢体会到模型行为是被你的提示词“压”出来的。转行的人往往把提示词理解成“写一段漂亮的文案”其实不是。在Agent里提示词是一段可执行的指令协议。你得像给API写文档一样把输入格式、输出格式、可用工具列表、处理规则写清楚。你用框架写Agent时框架会把你的Prompt帮你去组织Message但你仍然需要懂那些字段的语义。不懂提示词就去调框架你只会陷入“为什么它不按我说的做”的迷思。关于提示词的学习路径我推荐先学会写“结构化提示词”。所谓结构化就是分节角色、目标、步骤、输出格式、注意事项。不一定要用复杂的模板语言直接Markdown加分段也很有效。你可以拿一个每日天气助手来练手让模型根据天气数据生成穿衣建议并要求必须输出JSON。等这个练熟了Agent的很多基础概念你已经有了。2.2 理解API调用的基本盘请求、响应、流式输出Agent的本质是反复调用模型API。所以新手必须彻底搞懂一次API调用是怎么回事。很多教程会教你用封装好的SDK但你至少要自己用Python的requests或者httpx发一次原始请求看看请求长什么样、响应里有什么字段。我给你一张表帮你看懂最关键的字段字段/概念作用Agent中的意义system message设定模型角色和行为规则相当于Agent的性格和规则手册user message用户的最新输入每次循环里给模型的新信息assistant message模型的回复可能是文本也可能是工具调用请求tool calling模型主动要求调用某个工具Agent执行动作的入口temperature控制回答随机性低温度适合决策型Agent高温度适合创意max_tokens控制最大输出长度避免Agent回复失控stream流式输出让用户看到实时反馈但Agent内部一般不需要流式有一次项目里我们的Agent一直在重复调用同一个工具排查了半天最后发现是assistant message没有回传给模型。模型不知道它已经调用过这个工具了于是重复决策。这个细节在框架里是封装好的你手写一遍就能刻进肌肉记忆。学习API调用时不要只跑通官方示例你最好自己造一个“假工具”写一个Python函数get_weather(city)返回一段模拟JSON。然后你写代码调用模型把用户问题、这个假工具的结果拼起来再丢给模型生成最终回答。这一步会让你迅速理解Agent的“工具调用结果回填”模式比任何框架都直观。2.3 别急着学框架先手写一个“伪Agent”我的建议是在你碰LangChain这类框架之前先花一天时间手写一个“伪Agent”。这个伪Agent不需要真的调用工具而是用规则模拟一个工作流。比如写一个函数agent(user_intent)先判断意图是“查天气”还是“算数学”然后去调用对应的Python函数最后把结果格式化输出。这个过程虽然没有大模型参与但你已经实现了Agent的骨架意图理解、分工、执行、返回。之后再把“意图判断”替换成大模型调用你的伪Agent就立刻变成“半真Agent”了。你可以在里面加一个简单的循环如果模型发现某个条件不满足就继续调用下一个函数。这一步做出来后你再看框架文档会发现它的核心就是把你这个循环规范化、工程化。你有了这个底子学框架的速度至少快一倍。3. 真正的分水岭掌握 Tool Calling 和结构化输出3.1 为什么工具调用是Agent的灵魂如果你只会让模型生成文本那它只是一个聊天机器人。Agent和聊天机器人的本质区别在于Agent可以调用外部工具去获取信息或者修改状态。所以Tool Calling工具调用是所有Agent课程里最不该跳过的部分。现在的模型大部分都支持类似“function calling”的能力也就是模型在回答之前可以输出一个结构化的请求“我要调用get_weather函数参数是city北京date2025-01-01。”然后你的代码解析这个请求真的去执行函数把结果返回给模型。这个过程中模型自己没有联网能力它只是“提议”去调用工具真正的执行是在你的代码里完成的。很多新手会误解以为模型会自动联网、自动执行代码其实不是。你手动实现一次工具调用之后会彻底明白几条铁律第一工具的确定性是靠代码保证的模型不负责执行它只负责根据上下文决定调什么工具第二模型是否能正确选择工具取决于你的工具描述写得是否清楚第三工具调用的结果必须回填到对话历史里否则模型不知道自己的动作是否成功。为了让你有直观感受我举个例子。你给模型两把“工具”get_weather(city)和calculator(expression)。用户说“今天上海冷不冷如果温度乘以2是多少度”理想情况下模型会先调用get_weather(上海)拿到比如“15度”的结果再调用calculator(15*2)最后综合回答。这个过程就是一次多工具协同的Agent行为。你手写一次就会理解为什么工具的命名、参数说明、返回值格式那么重要。3.2 如何自己实现一个最小工具调用这里我给出一个极简的、用Python实现工具调用的思路。假设你已经从模型拿到响应响应里包含一个字段叫tool_calls里面是这个结构tool_call { id: call_123, function: { name: get_weather, arguments: {city: 上海} } }你写一个函数execute_tool(call)用一个字典把工具名字映射到对应函数def get_weather(city): # 这里假装调真实天气API return {city: city, temperature: 15, weather: 多云} def calculator(expression): return {result: eval(expression)} # 实际生产环境别用eval此处仅示意 TOOLS { get_weather: get_weather, calculator: calculator, } def execute_tool_call(tool_call): func_name tool_call[function][name] args tool_call[function][arguments] if func_name in TOOLS: result TOOLS[func_name](**args) return {tool_call_id: tool_call[id], result: result} return {error: unknown tool}拿到结果后你把这个结果作为一条tool消息追加到对话里再次调用模型。这个“模型提议工具 → 代码执行工具 → 结果回填 → 模型继续思考”的循环就是所有Agent框架的核心。你不用框架也能跑通而且你完全清楚每一行代码在做什么。我特别想提醒新手一件事工具参数一定要严格校验。模型有时候会输出类型错误的参数比如把字符串传入温度字段。如果你不校验程序就会崩溃。常见做法是使用JSON Schema在工具描述里定义好每个参数的格式代码侧再手动转类型。真实生产环境里工具调用十次有两次可能参数不完美你必须有容错机制。3.3 记忆机制从上下文窗口到外部存储新手学Agent最容易被“记忆”这个概念搞晕。很多框架提供Memory类、向量数据库、对话历史存储看名字就觉得深不可测。其实Agent记忆分两层短期记忆就是上下文窗口长期记忆就是外部存储。短期记忆的处理很简单把每轮对话的user消息、assistant消息、tool调用和tool结果全部按顺序存进列表再作为历史传给模型。但上下文窗口是有限的所以你必须做“记忆压缩”或“裁剪”。我的建议是新手先别碰向量数据库。你只需要做一版最简单的记忆裁剪维护一个消息列表当总tokens超过阈值时把最老的对话记录删掉只保留最近几轮加上一段系统提示词里的“历史摘要”。你先跑通这个极简版再考虑要不要引入向量检索。不然你学完一堆工具最后发现自己的业务根本不需要那么重的记忆白费功夫。长期记忆要解决的是“Agent下次启动时还能记得用户偏好”的问题。这个可以直接用一个SQLite表存用户ID、偏好键、偏好值。你每次让模型生成结构化输出把关键偏好提取到表里。下次用户来你把他偏好的内容拼进系统提示词。这个方案简单可靠比动不动上向量库实用得多。框架里那些复杂的记忆模块很多都是为了处理销售客服这类高频场景新手阶段真的不需要。先学会把数据存下来、取出来、拼到提示词里这已经能覆盖80%的Agent项目需求。4. 用循环而非框架来理解Agent的运转逻辑4.1 手写一个Agent循环ReAct风格Agent的运转本质是一个循环业界常见的模式叫ReActReasoning Acting。翻译成人话就是思考一步、行动一步、观察结果、再思考。你可以用最朴素的Python写这个循环messages [{role: system, content: 你是客服助手必要时使用工具。}] while True: response call_model(messages) assistant_msg response.choices[0].message if not assistant_msg.tool_calls: # 不需要调用工具直接回答 print(assistant_msg.content) break # 把模型的建议追加到历史里 messages.append(assistant_msg.model_dump()) for tool_call in assistant_msg.tool_calls: tool_result execute_tool_call(tool_call) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(tool_result, ensure_asciiFalse) })这个循环最长可以跑几十轮直到模型认为任务完成。但实际工作中你一定会给这个循环加两个保险最大轮次限制比如最多10次还有最大token预算防的就是模型在某个问题上反复横跳不收敛。我做过一个Demo不给限制时模型会为了一个“谢谢”的回复重复查了八次天气真是够了。如果我让你自己实现这其实就是全部了。没有复杂的图状态管理没有超长链式调用只有“while循环 消息列表”。你把这个循环理解透之后LangChain里的AgentExecutor、LangGraph里的StateGraph在你眼里都只是这个循环的工程化变体。你再看它的文档时会有一种“原来如此”的舒服感而不是恐惧。4.2 什么时候才需要LangChain之类我说“别一上来就啃框架”但也不是说框架永远不需要学。当你开始考虑这些问题时就是时候引入框架了需要支持多种不同模型供应商的统一调用需要处理大量的工具注册与鉴定需要支持复杂的Agent状态机比如暂停、人工审核、分叉需要团队协作对代码规范度和可维护性有要求想要快速接入现成的记忆管理、重试机制、监控方案。早期个人Demo我建议你完全手写。等到两个瓶颈出现再考虑框架一是工具数量超过十个你发现自己写的调度函数开始变得臃肿你希望有一个声明式的方式去注册工具二是你需要在不同模型服务间切换不想每次都改代码。这时候你把LangChain当作一个工具库来用而不是学习目标。很多教程会推荐你学它的“链”或者“代理”但你只要会注册Tool、初始化Agent、运行就已经够用了。深入的花哨功能等你确实需要时再去学别提前消耗精力。4.3 学习路径建议从0到1的时间规划我给新手和转行者一条实践过的时间路线不需要按月排按“能完成的事情”来排阶段任务达成标志第1周学会调用大模型API掌握聊天补全接口能用API做一个命令行问答机器人第2周学结构化输出让模型返回JSON能写一个自动生成请假条的脚本第3周手写工具调用搭一个ReAct循环能让模型调用天气API和计算器第4周加入简单记忆与多工具完成一个“能记住用户偏好的商品推荐助手”第5周挑一个框架把之前的Agent重构一遍能用框架实现同一功能并说出两者差异注意第5周才碰框架。这五周里前两周会让你觉得“没什么高级的”但那是你后面所有信心的来源。真想转行的人这五周足够你做一个像样的项目去面试了。你可以把那个“商品推荐助手”包装成一个小产品做点前端界面写一份README这比你啃一个月框架的博客笔记有说服力得多。5. 实操中常见的坑与排查思路5.1 上下文被塞爆我在跑Agent循环时最常遇到的问题就是消息列表越来越长最后直接报“context length exceeded”。这种情况多半是工具调用结果太大。比如某个工具返回了一个一万行的列表模型并不需要全部数据但你把整个列表塞进了上下文下一次调用模型时它就爆了。解决办法有几种第一工具返回前做摘要只返回topN条第二把大段数据存到文件或数据库里工具只返回一条“数据已存条数为”的提示第三在循环里加入上下文清理当接近上限时把历史中早期的工具结果替换成“[先前的工具结果已省略]”。实战中我推荐第二种因为它最不影响模型判断。比如search_documents返回完整文档列表你可以把它写进临时文件再返回给模型一句“已搜索到5篇文档内容见/tmp/materials_123.txt请告知用户”模型就知道下一步怎么回复了。5.2 模型不懂工具参数有时候你把工具描述写得很详细模型还是乱传参。比如工具声明需要city和date两个参数模型只传city或者直接把用户原话里的“上海”和“明天”拼接成一个字符串传进来。这种情况多半不是模型笨而是你的工具描述不够清楚。建议每个工具参数都加上明确的格式说明和示例。比如{ name: get_weather, description: 根据城市和日期查询天气日期格式为YYYY-MM-DD, parameters: { type: object, properties: { city: {type: string, description: 目标城市名例如上海}, date: {type: string, description: 目标日期例如2025-06-01} }, required: [city, date] } }描述越清楚模型传参越准。还有一个小技巧如果你给模型提供多个类似的工具光靠名称区分容易混乱不如在描述里写明“当用户想查天气时用这个当用户想查空气质量时用那个”。很多框架里可以把这些描述打印出来看看检查是不是有歧义。5.3 无限循环与预算失控新手最容易忽略的是外部API费用。一个没有 max_iterations 的循环在遇到模型反复横跳时可能跑几十次才退出你的钱包会哭。所以给Agent循环加硬性限制是必须的。我一般会在循环里维护一个iteration_count达到上限后不再循环而是让模型基于已有信息给出一个“尽力而为”的答案或者回复用户“需要更多步骤但已超限请稍后再试”。预算控制还可以从token层面做记录每次调用的tokens如果累计超过预设阈值强制终止。我甚至会在外部包一层超时装饰器超过30秒直接kill整个进程。这些在框架里都有现成配置但你手写时如果不做很可能会踩坑。这也是为什么我不建议新手拿框架当第一课因为框架默认帮你做了很多保护你就不会意识到这些边界条件有多重要。5.4 如何选模型/API不同模型在工具调用上的表现差异很大。我做过一个小实验同一个工具定义某模型能准确选择工具另一个模型却总是忘记调用。所以选型不能只看“跑分”或参数量一定要用一个带工具调用的Benchmark数据集去实测。实测方法也很简单准备十个人工构造的任务每个都要用到不同的工具比如查天气、搜索文档、计算价格。然后你对每个模型跑一遍相同代码看成功率。注意不要只看最终回答是否满意而要看你定义的那几个工具是否被正确调用。如果一个模型在工具调用上总是不稳定建议换一个专门调优过的API别去硬调提示词效果有限。成本也是一个要素如果用免费或低价的API跑得好完全没必要上更贵的模型。Agent项目里大多数token都消耗在循环往复的调用上模型单价低一分成本差异巨大。还有一些细节在循环里建议关掉流式输出streamFalse因为内部Agent不需要逐字动画减少解析复杂度把temperature调低到0.2左右Agent的决策要稳不需要天马行空。这些参数对Agent的稳定性影响远超很多人的预估。6. 学完这些下一步可以怎么走当你能手写一个带工具调用、记忆裁剪和循环限制的Agent之后你的能力其实已经超过了很多只会调框架的“API 搬运工”。你接下来可以尝试往三个方向扩展每个方向都能让你的项目上一个台阶。第一个方向是多Agent协作。不要把它想得太复杂其实就是多个Agent循环组在一起一个负责拆解任务一个负责执行子任务另一个负责汇总。你可以先做一个主Agent调用三个子Agent的小Demo让它们分别处理资料收集、计算、文案生成。你会发现难度并不在于Agent本身而在于消息的路由与同步。另一个方向是接入更丰富的工具生态比如浏览器自动化、数据库查询、办公文档处理让你的Agent真的能完成一个人一天的活儿。最后一个方向是做基于反馈的自我修正在工具调用失败后不要直接退出而是把错误信息返回给模型让模型重新调整参数再试一次。这个能力在工业界特别值钱因为真实环境里工具不可靠是常态。我个人很推荐你把这些尝试记录下来整理成一个“Agent学习笔记”系列。你会发现教别人本身就是最好的学习方式。每次你觉得“我应该算懂了”一输出成文立刻暴露出一堆没想明白的细节。最后说点实在的。我带过几个从传统开发转AI应用开发的朋友发现一个规律凡是先花两周自己手写Agent循环的人后面学框架、学LangGraph、做项目都顺得很因为他眼睛不是被文档蒙住的他心里有一杆秤能判断框架的设计哪里好用哪里坑。反而是那些一开始就背框架API的人面试时问深入一点就答不上来遇到报错只会查issue完全不知道怎么调试。所以只要你愿意暂时放下“别人都用框架我不学是不是不行”的焦虑先静下心来手写一个最小循环你的Agent学习就已经赢了一半。