先聊个现象。我见过不少刚接触AI Agent的人一上来就打开某个流行框架的文档跟着教程把环境配好、跑通一个demo然后就卡住了。问他接下来该学什么他自己也说不清楚。这个状态非常典型——工具会用一点但不知道背后的设计逻辑换个场景就无从下手。我自己也经历过这个阶段折腾了一圈之后才意识到AI Agent入门的核心短板通常不在框架而在底层能力。这篇文章就围绕“新手和转行者到底应该先学什么”这件事展开把我自己走过的弯路、验证过的方法、还有踩过的坑都整理出来。1. 先搞明白Agent到底是什么别急着动手很多人对AI Agent的理解就是“能自动干活的AI”。这话没错但太模糊。如果你打算认真学一开始就得建立一个稍微精确一点的心智模型否则后边学什么都会觉得隔了一层。1.1 Agent和普通AI应用的本质区别普通的大模型应用比如一个聊天机器人、一个内容生成工具它的工作方式是“你问一句我答一句”。模型本身是无状态的每次回答只依赖当前输入的上下文。你让它写一段文案它写完了这个任务就结束了。Agent不一样。Agent是一个能够自主完成多步骤任务的系统它的核心特征有三个有目标不是回答一个问题而是完成一个相对复杂的任务。能决策在执行过程中根据当前的状态判断下一步该做什么。会使用工具调用外部API、数据库、搜索引擎、代码执行环境等来弥补大模型自身能力的不足。我举个生活化的例子。你用大模型写一篇行业分析报告这是普通应用。但你给模型布置一个任务“调研一下这个行业的市场规模、头部玩家、技术趋势整理成一份带数据来源的报告然后发到我的邮箱”——这个过程需要搜索、阅读多个网页、汇总数据、调用邮件API中间任何一个环节出现异常还得自己决定怎么处理。这才是Agent的典型工作方式。1.2 “别一上来就啃框架”的真正原因现在市面上的Agent框架很多各有各的设计理念和配置方式。问题在于框架把复杂性封装得太好了。你按文档操作十分钟就能跑起来一个看起来非常像样的Agent。但这就像你刚学开车有人给了你一辆自动挡的车你踩油门就能走但你对发动机原理、路况判断、刹车距离这些真正影响安全的因素毫无概念。一旦遇到点特殊情况比如工具调用失败、上下文溢出、模型答非所问你根本不知道从哪排查。框架文档里写的都是“怎么用”很少有框架文档会告诉你“为什么这么设计”。而新手恰恰需要先理解“为什么”为什么Agent要循环调用模型为什么需要单独设计工具描述为什么要把历史信息塞进上下文为什么有时候模型会陷入死循环这些问题不是框架能替你回答的。你带着这些问题去学框架才能看懂它每个模块存在的价值。反过来如果你先啃框架你大概率只能停留在“能跑通demo”的水准。1.3 转行者最容易犯的一个认知错误我接触过一些从传统软件开发转过来的朋友他们有一个很常见的倾向把Agent当成传统程序来理解试图找到“确定的执行逻辑”。但Agent是概率系统不是确定性的。同一个任务同一个模型跑两次可能给不同的方案。传统开发思维里“代码跑出不同结果”是bug但在Agent里这就是常态。转行的人如果接受不了这个不确定性会在调试上耗尽精力。你得先建立这个认知Agent的设计目标不是消除不确定性而是在不确定性中达成目标。你做的所有工程工作——工具设计、prompt编排、容错机制——都是在提高成功率而不是追求100%确定性。这个心态转过来后面学什么都顺了。2. 四项底层能力比框架重要得多根据我个人的经验新手入门AI Agent有四件事值得花大力气先练扎实。这四件事和具体框架无关但不管以后你用什么框架、做什么类型的Agent它们都是基本功。2.1 提示词工程和模型说话的准确度提示词工程是Agent开发的“语感”。你可能觉得提示词谁不会写但真正写好的没几个。在Agent场景下提示词的质量直接影响整个系统的成败因为你写的不是一次性对话的开场白而是模型的运行说明书。Agent的system prompt至少承担三个职责定义角色与目标模型要以什么身份工作最终要达成什么结果。约束行为边界什么事能做什么事不能做不确定的时候怎么办。设定输出格式模型的中间输出会被你的代码解析格式一乱整个链路就断了。实操中我最常给新手的建议是写提示词要遵循“具体、可验证、有边界”这三个原则。别说“仔细分析用户的需求”要说“从用户的输入中提取商品名称、价格区间、购买渠道这3个字段无法提取时返回UNKNOWN”。两者看着都是中文但前者模型无从下手后者模型才知道怎么执行。另一个值得专门练的是输出格式控制。在Agent开发里你至少会遇到两种场景需要格式约束工具调用时的JSON格式以及步骤执行过程中的状态描述。JSON格式的稳定性是Agent工程里最磨人的问题之一模型偶尔会输出多余的逗号、漏掉结束括号、把布尔值写成字符串。应对方法通常是两条腿走路提示词里给严格的格式示例代码里做容错解析。2.2 API调用能力任何Agent都离不开的“手”Agent要干活得靠API。大模型厂商的API第三方服务的API你自己的后端API都是Agent的“手”。这块能力不完全属于Agent领域但它决定了你的Agent能做什么。新手至少要把这些API相关技能练熟HTTP请求的基本概念GET、POST、鉴权方式、请求头、状态码含义。如何处理API返回的非预期结果比如限流、超时、格式错误。大模型API的特殊机制上下文窗口、token计算、参数temperature、top_p等对输出的影响。其中token计算是新手比较容易忽略的。Agent每执行一步都要把历史信息、工具结果、用户需求拼进上下文然后发送给模型。如果你的Agent频繁调用工具上下文会膨胀得非常快。等token超了各种问题接踵而来费用飙升、响应变慢、模型“忘记”前面的信息。提前学会估算token消耗是控制Agent成本的关键能力。我个人的习惯是在开发阶段就在日志里记录每次请求的token数这样能直观看到上下文增长的趋势也能在系统还没上线时就发现隐患。2.3 工具调用的思维把能力拆成原子操作这里说的是Agent的工具调用能力具体来讲就是让大模型根据你的描述决定要不要调用某个工具、传什么参数。传统编程里是我们程序员调用函数Agent开发里则是我们把函数描述给模型让模型来调用。这个反转非常关键。有人把Agent的工具调用类比成给一个实习生分配任务。你手里有一些已经封装好的基础能力发邮件、查数据库、算数学题然后你把这些能力的说明书告诉实习生实习生根据具体情况决定用哪个能力来干活。但和实习生不同的是大模型可能产生幻觉、理解偏差、参数乱填所以工具设计本质上是一个人机协作的接口设计问题。设计工具时有几个经验可以分享工具的描述要明确参数的含义、类型、取值范围必要时给示例。工具粒度要做合理拆分。太大比如“处理这个订单”模型难以掌握输入输出太小比如“把字符串转成大写”用起来又太繁琐还会占用上下文token。需要在这两者之间找一个平衡点。工具返回的内容会被模型再读一遍所以要控制返回体的大小。只返回关键字段过滤掉无关信息这样既省token也能减少干扰。2.4 记忆管理让Agent“记得住”的工程手段很多新手以为Agent自带记忆其实不是。大模型本身是一个“用完即忘”的系统所谓的记忆全靠开发者手动管理。Agent开发里的记忆可以分为短期和长期短期是当前任务上下文里的对话历史长期是跨会话存储的向量数据库、结构化知识库等。新手阶段需要理解的核心问题是什么东西该放进记忆什么东西不该放。放少了模型信息不足决策质量差放多了上下文膨胀成本上升。这里有一个比较实用的思路直接关系当前决策的信息放入上下文。历史任务中提炼出的结论性知识存入长期记忆。原始日志、过程数据存到外部存储里按需检索。这个取舍思路没有标准答案需要在实践中自己摸索。你做几个Agent项目后慢慢就会形成一套适合自己场景的记忆策略。3. 理解Agent的核心运转机制才能看得懂框架如果用一个词概括Agent的内部运转方式那就是“循环”。框架里那些看不见的逻辑核心就是一个循环模型推理决定行动执行行动观察结果再推理。3.1 ReAct模式推理和行动的交替循环Agent领域最基础也是最经典的模式叫ReAct——Reason and Act。含义是让模型交替进行“推理”和“行动”推理Reason模型分析当前状态说出自己的想法决定下一步要做什么。行动Act模型选择一个工具生成调用参数发起执行。观察Observe把工具执行结果放回上下文。这个循环一直持续直到模型判断任务完成或者触发了中止条件。现在市面上的Agent框架不管宣传得多花哨底层基本都能看到这个循环的影子。区别只在细节循环的终止条件怎么设定、工具结果如何反馈、推理过程要不要对用户可见、异常情况怎么处理等等。新手理解ReAct模式之后再去看框架代码会发现很多困扰你的问题迎刃而解为什么Agent会停下来返回最终答案因为循环到达了终止条件。为什么Agent有时候会“疯狂调用工具”因为模型从观察中没得到足够信息又在循环里不断尝试。为什么中间推理过程有时代码里能看见但你前端没展示因为框架把推理日志单独输出了。3.2 上下文窗口是Agent的“工作台”上下文窗口可以类比成Agent的“工作台”所有它正在处理的信息都摊在这张桌子上。问题是这张桌子有限东西堆太多就会放不下。Agent每次与模型交互实际发送的内容包括系统提示词、任务目标、历史对话可能经过截断或摘要、工具调用记录、工具返回结果。这些全都在上下文窗口里。而上下文窗口一旦被占满模型就会“遗忘”较早的内容影响判断。实操中有几种常见的上下文管理手段截断只保留最近的N条对话丢掉的不管。摘要把较早的对话用一段话概括节省空间。关键信息提取只保留最核心的字段如用户ID、任务类型、当前状态。这些手段不是框架帮你做的而是需要你自己设计。这也是我之前说“别急着学框架”的原因——你理解了上下文管理的必要性和方法再看框架提供的工具时会思路清晰很多。3.3 模型的“工具选择”本质是分类任务还有一个比较容易理解偏差的地方模型决定调用哪个工具本质上是一个分类任务。模型接收到当前状态根据工具描述判断“现在需要哪个工具”这个能力被称为Function Calling。它和我们传统编程里的函数分发机制差不多只不过决策者从程序员变成了模型。在这个机制下工具描述的质量就变得特别重要了。描述写得太模糊模型可能选错工具描述写得太复杂模型反而被干扰。我见过一个反面例子某开发者给了一个查询天气的工具描述里详细写了“支持摄氏度和华氏度切换”但没写“该工具用于查询当前城市天气”结果模型在用户问“今天冷不冷”时竟然调用了这个工具去查“冷”的定义。好的工具描述应该像快递面单收件人是谁工具用途、要寄什么参数、有什么忌讳限制条件。写得越精确模型选对的概率越高。4. 框架什么时候学我建议你按这个节奏来聊到这里你可能要问既然框架别急着学那什么时候学我的建议是先完成几个小项目理解上面提到的这些底层概念之后再碰框架。而且碰框架的第一步建议是从读源码开始而不是跑demo。4.1 框架到底帮你解决了什么问题框架的初衷是帮你省去重复的胶水工作。比如你不必自己写一个工具调用的解析器不必自己设计循环控制逻辑不必自己实现上下文管理。这些都替你封装好了。但封装是有代价的——你不知道底层发生了什么。用框架写Agent就像开了自动驾驶但完全不看路。等框架出问题你只能干瞪眼。新手的正确姿势是先用“裸写”的方式用模型API配合代码实现一个最简Agent循环。这个循环可能只有几十行但它会逼你理解每个环节的细节。自己写过一遍之后再去用框架你会发现自己能看懂框架的日志能根据报错判断是框架问题还是模型问题能自己修改参数。4.2 如何挑选一个适合自己的框架等你要选框架时不要只看star数量重点看这几个维度是否支持你熟悉的编程语言如果你只会Python就别选一个以JS为主的框架。是否支持你需要的模型API有的框架只适配特定厂商的模型。是否支持工具调用Function Calling的标准方式是否允许自定义工具。是否支持流式输出、回调、日志查看等开发便利功能。社区活跃度、issue响应速度、文档质量。如果你是转行者我建议一开始选一个文档齐全、社区活跃度中上的主流框架即可。不必追新Agent框架迭代很快今天的先进特性明天可能就是历史包袱。4.3 用“最小复现”的方式边用框架边学用框架的阶段有一个方法特别好用——最小复现。不要一上来就搭一个复杂的Agent应用而是先拿框架实现一个最简单的循环然后逐步往里面加功能。加一个功能就测一个功能这样能精确判断每个特性是干什么用的。把框架当黑盒使用的坏处是出了问题你根本不知道是配置问题、模型问题还是代码问题。而最小复现的方式能让你快速定位问题。有一次我在一个项目里Agent在特定条件下总是重复调用一个查询工具排查很久才发现是工具描述里一个歧义词导致的。如果一开始就用最小复现的方式测试每个工具的调用效果这个问题可能早早就暴露了。5. 零基础到入门一条能落地的学习路线说了这么多理论来点实际的。下面这条路线是我带过几位转行者验证过比较顺的路径每一步都对应一个可完成的练习练完就能看到进步。5.1 阶段一练API调用1-2周这个阶段的目标是熟悉大模型API的使用方式。不用管Agent概念就是实现简单的对话。练习任务用模型API实现一个带流式输出的聊天机器人。给聊天机器人加上多个角色设定观察不同设定对输出风格的影响。实现一个“总结历史对话”的函数把多轮聊天内容压缩成关键词列表。这个阶段你要特别注意的三个点token消耗的观察、输出格式控制、参数调节。这三个点后面全部会用得上。5.2 阶段二徒手实现Agent循环2-3周这个阶段不依赖任何框架用API加Python代码实现一个最简Agent。练习任务实现一个“查天气Agent”用户输入城市Agent调用天气API然后根据返回结果给出出行建议。给Agent加一个规则如果API调用失败自动重试。重试两次失败后告知用户系统暂时不可用。实现一个简单的大小写不敏感命令解析模拟工具选择的场景。徒手实现一次循环比看十篇框架教程更有用。这样你才能真正知道每一步的输入、输出、处理逻辑是什么。5.3 阶段三加入记忆和工具设计3-4周这个阶段开始做“像样”的Agent。引入记忆管理和更复杂的工具调用。练习任务做一个“多轮需求收集Agent”它需要记住用户在对话前面提到的信息预算、偏好、时间最后汇总输出。设计三个工具比如搜索、计算、存储让模型自己选择调用顺序来完成一个综合任务。在日志里记录每次模型调用的输入上下文大小尝试限制上下文长度观察对Agent效果的影响。这个阶段你会开始体会到“记忆”和“工具”设计的精妙之处——同样一个需求工具描述写法不同模型的行为差异很大。5.4 阶段四引入框架做工程化4-6周有前面的基础再引入框架。这个阶段重点是“对比学习”把之前徒手实现的功能用框架重写一遍。练习任务选一个主流框架把你阶段二写的“查天气Agent”用框架实现。为框架项目配置日志系统记录每一步的模型输入、输出、工具调用情况。用框架的能力改造阶段三的项目加入更完善的上下文管理、错误处理。这个阶段完成后你基本就有了独立开发Agent项目的基础能力。剩下的就是做真实项目在实战中打磨。6. 常见问题排查与避坑实录在学习过程中有几类问题非常高频。我整理了一份速查你大概率会在某一天碰到其中1-2个。6.1 上下文无限膨胀现象Agent跑几轮后响应越来越慢或者提示token超限。原因每一轮的完整上下文都发给模型越积越多。排查与处理检查日志中每轮的token数确认增长率。在上下文中只保留最近几轮对话或用摘要替代历史全文。工具返回的结果要精简避免塞入大段无关信息。6.2 工具调用参数格式崩坏现象模型返回的JSON不合法导致代码解析失败。原因模型幻觉或者提示词里格式约束不够强。排查与处理提示词里给出严格示例而不是模糊要求。写一个容错解析函数尝试修复常见JSON错误缺少引号、多余逗号等。解析失败时让模型重新生成而不是直接崩溃。6.3 Agent反复调用同一个工具现象Agent卡在一个工具调用循环里出不来。原因可能是工具返回的信息不足以让模型做出下一步判断也可能是终止条件没设好。排查与处理设一个最大迭代次数超出就强制终止。检查工具的返回内容质量是否满足模型决策所需的信息。改善工具描述让模型更容易判断何时该停止使用该工具。6.4 模型选择性忽略部分工具现象明明定义了三个工具模型只用其中一个其他工具从不触发。原因工具描述与用户需求匹配度不够或者模型的处理习惯更偏好某种工具。排查与处理重新检查工具描述确保每个工具的使用场景都足够清晰。在提示词里强调“你有多个工具可用根据任务选择合适的工具”。给工具加一些“触发关键词”提示帮助模型理解使用时机。6.5 框架版本变更导致项目代码失效现象升级框架版本后之前能跑的项目报错。原因框架API变动或功能废弃。排查与处理生产项目锁定依赖版本不要随意升级框架。升级前先看框架的变更日志和迁移文档。不同项目之间建议使用独立的依赖环境比如各建一个虚拟环境。6.6 模型回答“让我确认一下”但没有任何后续动作现象Agent输出“好的我先查一下”但实际没有调用任何工具也没有后续输出。原因这是典型的现象模型“假装”在干活其实没有触发工具调用。排查与处理在提示词里明确要求“如果你要查询信息必须调用工具不允许直接告知用户你要查询但实际不调用”。在代码逻辑里检查工具调用标记如果模型没有生成工具调用不允许输出“已查询”之类的话术。设置一个强制规则所有对外输出必须对应一次实际发生的工具调用结果除非是最终答复。这些问题看着琐碎但每一个都能卡住新手半天甚至一天。提前知道有个心理准备遇到时不会慌。写在最后我自己带过几个转行的朋友走这条学习路最大的体会就是AI Agent这个领域入门并不难难的是把底层的概念摸透。你花两三周徒手写一个最简单的Agent循环收获比啃两个月框架文档大得多。等到你理解了模型调用的本质、工具调用的机制、上下文管理的必要性再去看框架就像看着别人写好的代码库反而能欣赏它的设计精妙而不是手足无措。给新手的最后一个建议是学Agent的过程中别贪多把一个东西弄明白比把十个东西弄明白一半要强。先徒手实现一次最简循环再慢慢加功能熟悉之后再加框架这个节奏是最稳的也是我目前最推荐给转行者的一条路。