AI Agent入门：先手写循环再学LangChain，别搞反顺序-北京尧图网络

1. 为什么我不建议新手一上来就啃 LangChain1.1 一个让我印象深刻的翻车现场去年秋天有个做 Java 后端的兄弟找我喝茶说想转行做 AI Agent 开发问我第一步该学什么。我问他现在什么进度他说已经把 LangChain 的官方文档啃了一大半Chain、Agent、Memory、Tool 这些概念都能说上几句还照着教程跑通了一个“能查天气的机器人”。听起来挺唬人结果我让他现场给我加一个功能——把查询结果存到本地文件里他卡了整整四十分钟最后写出来的代码是把整个 Chain 的输出硬塞进一个open()里连异常处理都没有。这个场景我见过太多次了。新手和转行者最大的误区就是把“学框架”当成了“入门”。LangChain、Spring AI、CrewAI、Dify 这些框架确实是好东西但它们本质上是封装层是别人把已经跑通的模式打包给你用。你连底下发生了什么都不知道上来就调 API遇到问题只能靠猜猜不出来就换框架换完还是不会。所以这篇文章我想聊的核心就一句话AI Agent 入门先学“Agent 是什么、怎么运转”再学“用哪个框架把它搭起来”。顺序反了你会一直在“能跑但不懂”的状态里打转。1.2 先搞清楚Agent 和普通程序到底差在哪很多人对 Agent 的理解停留在“会调用工具的聊天机器人”这个理解不算错但太浅了。我用一个生活化的类比来说明。普通程序像自动售货机你投币、按键它出货流程是固定的输入决定输出中间没有“思考”环节。你写一个 Python 脚本去读 CSV、算平均值、写回文件这就是自动售货机。Agent 更像一个刚入职的助理你给他一个模糊的任务比如“帮我看看这个月销售数据有没有异常”他不会立刻动手而是先想——数据在哪用什么工具读异常怎么定义要不要先看看历史同期想清楚之后才一步步去做做的过程中发现数据格式不对还会调整策略。这个“想—做—看结果—再想”的循环才是 Agent 的灵魂。用稍微专业一点的话说Agent 的核心是一个由大模型驱动的决策循环观察当前状态决定下一步动作执行动作拿到反馈再决定下一步直到任务完成或达到终止条件。这个循环在业界常被称为 ReAct 模式Reasoning Acting是目前绝大多数 Agent 框架的底层骨架。理解了这一点你就明白为什么“直接学 LangChain”是低效的——LangChain 帮你封装的就是这个循环但如果你不知道循环长什么样你调AgentExecutor的时候根本不知道它在背后替你做了什么决策。1.3 新手该有的学习路径长什么样我把这条路径拆成四层从下往上走每一层都能独立跑通再往上层级学什么大概耗时判断是否掌握的标准第一层Python 基础 HTTP 请求 JSON 处理2-4 周能独立写脚本调一个公开 API 并解析返回第二层大模型 API 直接调用不套框架3-5 天能手写多轮对话、函数调用Function Calling第三层手写一个最小 Agent 循环1-2 周不依赖任何框架实现“思考-调工具-再思考”第四层引入框架LangChain / Spring AI 等按需能看懂框架源码里对应自己手写的那部分这个路径的关键在于第三层。很多人跳过它直接进第四层结果就是永远在“调包”层面打转。你手写过一个 200 行的 Agent 循环之后再去看 LangChain 的AgentExecutor会有一种“哦原来你就是把我写的东西工程化了”的顿悟感这时候学框架才是事半功倍。2. 第一层地基Python 和基础工程能力不能省2.1 Python 要学到什么程度才够用每次有人问我“学 AI Agent 要不要先学 Python”我都回答要但不需要学到能写爬虫框架的程度。你需要的是够用的 Python具体来说变量、列表、字典、循环、条件判断——这些是基本功不熟的话后面全是坑函数定义和调用理解参数传递类的概念能看懂class和self——因为框架里到处都是类异常处理try/except——Agent 调工具失败是常态不会处理异常寸步难行虚拟环境venv或conda——隔离依赖别把系统环境搞乱包管理pip install会看requirements.txt这些内容一个零基础的人认真学两到四周能掌握。网上免费教程很多Python 官网的文档也足够清晰不需要买课。我个人的建议是边学边写小脚本比如写一个读取本地文本文件、统计词频、输出到新文件的程序这种小任务能把基础语法全串一遍。注意不要在这个阶段追求“精通”。我见过有人花三个月啃完《流畅的 Python》结果一行 Agent 代码没写过。基础够用就往前走剩下的在实战中补。2.2 那些看起来不起眼但极其重要的基础技能除了语法有几项技能新手往往忽略但实际开发中天天用到第一是 HTTP 请求和 JSON 处理。大模型的 API 本质就是 HTTP 接口你发一个 POST 请求带上 JSON 格式的消息服务器返回 JSON 格式的结果。如果你不理解 HTTP 状态码200、401、429、500 分别代表什么不知道怎么用requests或httpx发请求不知道json.loads()和json.dumps()的区别那你调 API 的时候会非常痛苦。第二是环境变量管理。API Key 绝对不能硬编码在代码里这是安全底线。用.env文件配合python-dotenv库或者直接设置系统环境变量这是行业惯例。第三是日志和调试。Agent 的运行过程是黑盒你必须靠日志才能知道它每一步在想什么、调了什么工具、拿到了什么结果。学会用logging模块比学会任何框架都重要。我列一个最小可用的技能清单你可以对照自查# 这些操作你应该能闭着眼睛写出来 import os import json import requests from dotenv import load_dotenv load_dotenv() api_key os.getenv(API_KEY) response requests.post( https://api.example.com/v1/chat, headers{Authorization: fBearer {api_key}}, json{message: 你好} ) data response.json() print(data[reply])如果你看这段代码没有障碍第一层就算过了。2.3 关于“免费 Python 源码大全”这类资源的正确用法热搜里经常出现“免费 Python 源码大全”这类词我理解新手想找现成代码抄的心情。但我要泼一盆冷水在 Agent 这个领域抄源码的收益极低。原因很简单Agent 的代码高度依赖具体的模型、工具和业务场景别人的源码换个环境就跑不起来你抄过来只会得到一堆报错。正确的用法是把别人的源码当阅读理解材料而不是复制粘贴的模板。看的时候问自己三个问题——这段代码解决了什么问题它为什么这么写而不是那么写如果换成我的场景哪里需要改带着问题看代码比无脑复制有价值一百倍。3. 第二层核心直接调用大模型 API别急着套框架3.1 从一次最简单的 API 调用开始这一层的目标很明确不借助任何框架用最原始的方式和大模型对话。为什么这一步不能跳因为框架帮你隐藏的恰恰是最关键的东西——消息是怎么组织的、上下文是怎么传的、工具调用是怎么表达的。一次最基础的对话调用核心就是构造一个消息列表import os import requests from dotenv import load_dotenv load_dotenv() def chat(messages): response requests.post( https://api.openai.com/v1/chat/completions, headers{ Authorization: fBearer {os.getenv(OPENAI_API_KEY)}, Content-Type: application/json }, json{ model: gpt-4o-mini, messages: messages } ) return response.json()[choices][0][message][content] messages [ {role: system, content: 你是一个简洁的助手}, {role: user, content: 用一句话解释什么是 Agent} ] print(chat(messages))这段代码看起来简单但里面藏着几个关键概念role有 system、user、assistant 三种分别代表系统设定、用户输入、模型回复messages是一个列表多轮对话就是把历史消息不断追加进去。这些概念是所有框架的公共语言你在这里搞懂了后面看任何框架的文档都不会懵。3.2 多轮对话和上下文管理Agent 的记忆基础单轮对话没意思Agent 的核心能力之一是记住之前发生了什么。但大模型本身是无状态的它不记得你上一句说了什么所谓的“记忆”全靠你把历史消息重新发一遍。history [{role: system, content: 你是一个助手}] def chat_with_memory(user_input): history.append({role: user, content: user_input}) reply chat(history) history.append({role: assistant, content: reply}) return reply print(chat_with_memory(我叫小明)) print(chat_with_memory(我叫什么名字)) # 它会回答小明这就是最朴素的记忆机制。但问题马上来了对话轮数一多history会越来越长token 消耗暴涨而且超出模型上下文窗口后直接报错。这就引出了 Agent 开发中一个绕不开的话题——上下文管理策略。常见的做法有几种滑动窗口只保留最近 N 轮、摘要压缩把早期对话总结成一段话、向量检索把历史存进向量库需要时再捞出来。这些策略在 LangChain 里都有现成的组件但你必须先理解它们要解决什么问题用的时候才知道该选哪个。实操心得新手阶段先用最简单的滑动窗口保留最近 10 轮对话就够了。别一上来就上向量数据库那是给自己找麻烦。3.3 Function CallingAgent 能“动手”的关键如果说多轮对话是 Agent 的“记忆”那 Function Calling函数调用就是 Agent 的“手脚”。这是从“聊天机器人”到“Agent”的分水岭。原理其实不复杂你在调用 API 的时候除了发消息还额外告诉模型“我这儿有几个函数分别是干什么的、需要什么参数”。模型在回复时如果判断需要调用某个函数它不会直接给你文字而是返回一个结构化的调用请求告诉你“我要调这个函数参数是这些”。你的代码拿到这个请求后真正去执行函数再把结果发回给模型模型基于结果继续回复。tools [{ type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } }] # 调用时把 tools 一起传进去 # 模型返回的 message 里会有 tool_calls 字段 # 你解析这个字段执行对应函数把结果作为 roletool 的消息追加回去这个流程走通一遍你就理解了 Agent 最核心的机制。LangChain 的 Tool 抽象、Spring AI 的 Function 抽象本质上都是对这套流程的封装。你手写过一遍再看框架文档会发现那些概念你全都认识。3.4 手写一个最小 Agent 循环现在把前面几块拼起来我们就能手写一个不依赖任何框架的最小 Agentdef run_agent(user_input, max_steps5): messages [ {role: system, content: 你是一个助手可以调用工具完成任务}, {role: user, content: user_input} ] for step in range(max_steps): response call_llm(messages, toolstools) msg response[choices][0][message] messages.append(msg) # 如果没有工具调用说明任务完成 if not msg.get(tool_calls): return msg[content] # 执行所有工具调用 for tool_call in msg[tool_calls]: result execute_tool(tool_call) messages.append({ role: tool, tool_call_id: tool_call[id], content: result }) return 达到最大步数限制这大概 20 行代码就是一个完整的 Agent 循环。max_steps是防止死循环的保护机制这个细节非常重要——我见过太多新手写的 Agent 因为模型反复调用同一个工具而陷入无限循环烧掉一堆 token。写到这里你应该能体会到Agent 的本质不复杂复杂的是工程化。框架解决的是并发、重试、日志、状态持久化、多 Agent 协作这些工程问题而不是“让模型会调工具”这个核心逻辑。4. 第三层进阶理解 Agent 的主流架构模式4.1 ReAct最基础也最常用的模式ReAct 是 Reasoning Acting 的缩写核心思想是让模型在每一步都先“想”再“做”。它的提示词模板大致是这样的你可以使用以下工具{tools} 使用以下格式 Thought: 我需要思考下一步做什么 Action: 工具名称 Action Input: 工具参数 Observation: 工具返回的结果 ...重复 Thought/Action/Observation Thought: 我现在知道最终答案了 Final Answer: 最终答案这个模式的好处是可解释性强你能从日志里清楚看到模型每一步的推理过程。缺点是 token 消耗大因为每一轮都要把完整的思考历史带上。我个人的经验是ReAct 适合任务步骤不确定、需要灵活调整的场景比如“帮我调研一下某个话题并写份报告”。如果任务流程固定用不着 ReAct直接写死流程更省钱。4.2 Plan-and-Execute先规划再执行这个模式把 Agent 分成两个角色规划者先制定一个完整的步骤清单执行者再一步步去完成。相比 ReAct 的“走一步看一步”它更适合复杂的长任务。举个例子任务是“帮我搭建一个个人博客”。规划者会拆成选技术栈、初始化项目、写首页、写文章页、部署。执行者再逐个完成。这种模式的优势是全局视野清晰不容易跑偏劣势是规划一旦出错后面全错而且中途遇到意外不好调整。4.3 多 Agent 协作什么时候需要什么时候是过度设计CrewAI、AutoGen 这类框架主打多 Agent 协作让几个 Agent 分别扮演不同角色比如研究员、写手、审核员协同完成任务。听起来很酷但我要提醒一句大多数场景用不上多 Agent。多 Agent 的代价是复杂度指数级上升——通信成本、状态同步、角色冲突、调试困难。我见过有人用三个 Agent 去做一个单 Agent 就能搞定的事结果调试了两周还没跑通。判断标准很简单如果任务能清晰拆成几个独立子任务且子任务之间需要“讨论”和“审核”才考虑多 Agent否则老老实实用单 Agent 加多个工具。4.4 关于 MCP它解决的是什么问题热搜里 MCP 出现频率很高很多人搞不清它是什么。我用一句话解释MCPModel Context Protocol是一套让模型和外部工具、数据源之间标准化通信的协议。在没有 MCP 之前你每接一个工具就要写一套适配代码工具 A 的接口和工具 B 的接口完全不一样。MCP 想做的是统一这件事——工具方按照 MCP 标准暴露自己的能力Agent 方按照 MCP 标准去调用双方解耦。你可以把它类比成 USB 接口以前每个设备一个专用接口现在统一成 USB-C。对新手来说MCP 现在还不是必须掌握的但理解它的设计思想很有价值——标准化是工程化的必经之路。等你手写过几个工具调用之后再回头看 MCP 的设计会有更深的体会。5. 第四层什么时候该引入框架怎么选5.1 引入框架的正确时机我的判断标准是当你手写的 Agent 循环开始出现重复代码且这些重复代码和业务逻辑无关时就该考虑框架了。具体来说当你发现自己反复在写这些东西重试逻辑、超时处理、日志记录、token 计数、对话历史持久化、多个工具的注册和分发——这些就是框架存在的意义。它们不是帮你“实现 Agent”而是帮你“把 Agent 工程化”。反过来说如果你连一个手写循环都没跑通过直接上框架你会把框架的抽象当成魔法出了问题完全无从下手。5.2 LangChain、Spring AI、CrewAI、Dify 怎么选这几个是热搜里出现最多的我按适用场景给你梳理一下框架语言适合谁优势注意点LangChainPython/JSPython 开发者、快速原型生态最全组件最多抽象层多版本变动快容易踩坑Spring AIJavaJava 后端、企业项目和 Spring 生态无缝集成相对年轻社区资料少CrewAIPython多 Agent 协作场景角色定义直观上手快单 Agent 场景属于杀鸡用牛刀Dify低代码平台非程序员、快速验证可视化编排无需写代码复杂逻辑受限深度定制困难选型的核心不是“哪个最好”而是“哪个最匹配你的现状”。你是 Java 背景就优先看 Spring AI你要快速验证一个想法Dify 拖拖拽拽就能出原型你要做深度定制LangChain 的灵活性更高。踩坑提醒LangChain 的版本迭代非常快网上很多教程是半年前的代码直接跑会报错。看文档一定要看对应版本的别拿旧教程硬套。5.3 从手写到框架的迁移思路当你决定用 LangChain 时不要推倒重来而是把你手写的每个部分对应到框架的组件上你手写的messages列表 → LangChain 的ChatPromptTemplate和MessagesPlaceholder你手写的工具定义 → LangChain 的tool装饰器你手写的 Agent 循环 → LangChain 的AgentExecutor你手写的记忆管理 → LangChain 的ConversationBufferMemory这样迁移你不是在“学一个新东西”而是在“把手写的东西换成更工程化的实现”。心态完全不一样学习效率也完全不同。6. 新手最容易踩的五个坑6.1 坑一把框架当语言来学有人问我“学 LangChain 要多久”我说这问题问错了。LangChain 不是一门语言它是一堆工具的组合你不需要“学完”它只需要在用到某个功能时去查对应文档。把它当成字典而不是教科书。6.2 坑二忽视 token 成本Agent 的 token 消耗远超普通对话因为每一轮都要带上完整历史。我见过一个新手写的 Agent因为没设max_steps模型陷入循环一晚上烧掉几十美元。上线前一定要设步数上限、超时时间、单次任务 token 预算这是血的教训。6.3 坑三工具设计得太粗或太细工具太粗模型不知道怎么用工具太细模型要调很多次。好的工具设计是一个工具做一件明确的事参数清晰描述准确。比如“查询订单”比“数据库操作”好“按订单号查订单”比“查询订单”更明确。6.4 坑四不做错误处理工具调用失败是常态——网络超时、API 限流、参数错误。如果你的 Agent 遇到错误就崩溃那它根本不能用。正确做法是把错误信息作为工具结果返回给模型让模型自己决定是重试、换工具还是放弃。6.5 坑五过早追求“智能”新手总想让 Agent 无所不能结果什么都做不好。我的建议是从一个极窄的场景切入比如“自动整理下载文件夹”把它做到 90% 可靠再逐步扩展。窄场景能让你快速看到效果、积累经验比一上来就搞通用 Agent 靠谱得多。7. 一个可以照着做的四周入门计划7.1 第一周Python 基础和 API 调用目标是能独立调用一个大模型 API 并处理返回。每天花两小时前两天补 Python 基础如果已有基础就跳过后五天专注 API 调用——单轮、多轮、异常处理、日志记录。周末写一个小脚本命令行输入问题输出模型回答支持多轮对话。7.2 第二周Function Calling 和工具调用目标是理解并手写工具调用流程。先照着文档跑通一个官方示例然后自己定义两三个工具比如查时间、算数学、读文件让模型根据问题自动选择。周末写一个能查天气、能算数的命令行助手。7.3 第三周手写完整 Agent 循环目标是把前两周的东西整合成一个完整的 Agent。加上max_steps保护、错误处理、日志输出。周末做一个实用的小项目比如“自动整理桌面文件”——Agent 扫描桌面根据文件类型分类移动到对应文件夹。7.4 第四周引入框架并对比目标是用 LangChain 重写第三周的项目对比手写版和框架版的差异。重点看框架帮你省了哪些代码、引入了哪些新概念。这一周的核心不是“学会 LangChain”而是“理解框架的价值边界”。走完这四周你对 Agent 的理解会超过 80% 只会调框架的人。因为你知道每一层在做什么遇到问题能定位到具体环节而不是对着报错干瞪眼。8. 关于转行者的一些额外建议8.1 你的旧经验不是包袱是资产转行者常有的焦虑是“我之前的经验用不上”。恰恰相反Agent 开发是工程能力和领域知识的结合。你是做后端的对并发、状态管理、接口设计的理解直接能用你是做产品的对用户需求的理解能帮你设计更好的 Agent 交互你是做数据分析的对数据处理流程的熟悉能让你设计出更实用的工具。框架谁都能学但领域经验是稀缺的。别把自己当零基础把旧经验当跳板。8.2 别被“AI 焦虑”推着走这个领域变化确实快今天流行 LangChain明天可能就换别的。但底层的东西变化很慢——消息怎么组织、工具怎么调用、上下文怎么管理、错误怎么处理这些核心问题几年内不会变。把精力放在这些不变的东西上你就不会被各种新框架牵着鼻子走。8.3 动手永远比看教程重要我最后想说的是这个领域最不缺的就是教程最缺的是动手写代码的人。你看一百篇 LangChain 入门教程不如自己手写一个 Agent 循环。看教程是被动接收写代码是主动建构两者的学习效果差着数量级。找一个小需求哪怕再简单把它做出来。做的过程中你会遇到各种教程里不会讲的问题解决这些问题的过程才是真正长本事的时候。

AI Agent入门：先手写循环再学LangChain，别搞反顺序

相关推荐

OpenMontage实战复盘：用CLI编排AI视频生成与自动化剪辑

无监督学习赋能纳米材料3D表征：绕过标注瓶颈的物理驱动重建

Spring Boot汉服租赁系统：档期冲突与押金结算全链路设计

更多资讯

E2E测试实战：用Playwright打造稳定可靠的全链路自动化测试

e2e测试：端到端验证的本质与工程落地实践

CMS拖拽生成页面：从拖拽克隆到页面Schema闭环

营销技能全景拆解：从用户洞察到转化优化的实战指南

营销技能核心逻辑与五大关键能力：从用户洞察到私域运营

YOLOv11-RepNCSPELAN在服装质检中的实战应用

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？