最近Claude code，openclaw这种Agent热度居高不下，越来越多的人开始加入Agent的开发队伍，无论是个人SOP自动化还是企业内部自用Agent，都需要你掌握一定的Agent基础知识。
纯靠Vibe coding，你或许会得到一个勉强能用的Agent，但是上下文一多，当上下文腐败（Context Rot）现象出现以后vibe coding出的策略不能够有效解决，多轮对话后发现记忆缺失时又该怎么办？如果从0开始学习Agent，应该学哪些内容？
这些问题最终归结为一个问题——怎么系统性地学 Agent 开发？
一、Agent 和普通 LLM 应用，差在哪里
对于小白来说，很多人可能遇到问题会去Chatgpt，豆包之类的官网去寻求答案，这就是LLM最经典的应用场景，根据内置的训练数据，回答用户的问题，但是如果你想让它帮你自动下载文件，自动查看某个网站的内容，甚至是自动帮你写代码执行并测试呢？网页版的能力就难以达到用户的需求。
而Agent则不同，Agent的核心在于自主行动。
如果说普通的LLM是一个博学的顾问，坐在办公室里等你来问问题，那Agent就是一个能走出去亲自动手的执行者——它不仅能告诉你"这个文件应该这样下载"，它会直接打开浏览器，找到链接，下载下来，检查内容，再告诉你"好了，我已经帮你处理完了"。
实现这一切的关键，是Agent拥有了**工具调用（Tool Use）**的能力。你可以把工具理解成Agent的"手脚"，常见的工具包括：
- 搜索引擎：让Agent能实时获取网络上的最新信息，而不局限于训练数据的截止日期
- 代码执行器：让Agent能写出代码之后直接运行，看到报错，再修改，再运行，完成完整的开发闭环
- 文件系统：读取、写入、移动你电脑里的文件
- 浏览器控制：自动打开网页，点击按钮，填写表单，抓取内容
- 外部API：发邮件、查天气、下订单……几乎任何你平时在手机上点点点能做到的事
除了工具，Agent还有另一个普通LLM不具备的特质——规划与反思能力。面对一个复杂任务，Agent不会一股脑地给你一个答案，而是会把大目标拆解成一步一步的子任务，执行一步，观察结果，再决定下一步怎么走。如果中途出了问题，它能自己发现、自己纠错，而不是等你来告诉它"你做错了"。
这个"执行→观察→思考→再执行"的循环，在业内通常被称为ReAct 循环，是Agent区别于普通对话模型的本质所在。
所以简单来说：LLM负责"想"，Agent负责"做"。对于普通用户而言，这意味着你终于可以把一件事情完整地交给AI，而不只是得到一份"参考答案"。
二、打基础：你真正需要哪些前置知识
做Agent应用开发，我们不需要关注LLM过于底层的知识，诸如机器学习、深度学习、微调、Transformer等大模型层面的知识，我们只需要了解一些Agent开发绕不开的概念，一些细节性的内容可以在开发过程中随时询问AI去补充。
LLM 基础概念
不需要手推 Attention 公式，但这几个概念必须清楚：
- Context Window：决定你能往 Prompt 里塞多少内容，直接影响 Agent 的记忆设计
- Token 计费逻辑：影响成本控制策略，生产环境绕不开
- Temperature：控制输出的随机性，Agent 场景通常要低温度，要稳定
- 幻觉的成因：知道模型为什么会瞎编，才能设计防御机制
Prompt Engineering
Prompt Engineering这个词相信很多人都不陌生，但它是一个被严重低估的领域。很多人觉得，不就是跟模型对话吗？随便说说不就行了，系统性地去学感觉没什么必要。但现实是：同一个模型，不同的人用，效果可以天差地别。模型的能力上限是固定的，而你能召唤出多少，完全取决于你给的Prompt质量。
举个最直接的例子——同样是让模型帮你写一封催款邮件：❌ 坏的Prompt：
"帮我写封催款邮件"
模型不知道你的身份、对方是谁、欠了多少钱、关系是否敏感、语气要强硬还是委婉……它只能瞎猜，给你一封放之四海而皆准的模板，你收到之后大概率还要大改。✅ 好的Prompt：
"我是一家设计公司的负责人，客户王总已经拖欠了3万元设计费超过60天。我们合作关系一直不错，我不想撕破脸，但必须让对方重视这件事。请帮我写一封措辞礼貌但态度明确的催款邮件，字数控制在200字以内。"
同样的模型，第二个Prompt给出的结果可以直接发出去，第一个可能需要你改半小时。
这背后的逻辑其实很简单：模型本质上是在做"补全"——你给的上下文越清晰，它脑补的空间就越小，跑偏的概率就越低。一个好的Prompt，通常会明确以下几件事：角色：你是谁，模型应该扮演什么角色任务：你到底要什么，目标是什么约束：格式、长度、语气、不能做什么背景：让模型理解你所处的具体情境Prompt Engineering研究的，正是如何系统性地把这些要素组合好，从而稳定地从模型中拿到高质量的输出。它不是玄学，是一套可以学习、可以复用的方法论——而掌握它的人，使用的明明是同一个模型，却像在用一个完全不同的工具。
三、核心架构：Agent 的四块积木
Agent 系统不管看起来多复杂，底层都由四个模块组成。搞懂这四块，任何 Agent 框架你都能快速上手——因为万变不离其宗，换汤不换药。
- Profile（角色定义）——Agent 的身份证在你启动一个 Agent 之前，你得先告诉它"你是谁、能做什么、不能做什么"。这件事的载体，就是我们常说的 System Prompt。你可以把 Profile 理解成给新员工入职时的那份岗位说明书——写得清楚，它就知道自己的职责边界，不该管的事不乱插手；写得模糊，它就容易在不该自作主张的地方乱跑，出了问题你都不知道从哪查起。
- Memory（记忆系统） ——Agent 的大脑存储Agent 的记忆不是一个整体，而是分层的。理解这四层，你才能明白为什么有些 Agent "记性好"，有些对话两轮就忘了前面说过什么。
| 类型 | 实现方式 | 说明 |
|---|---|---|
| 感知记忆 | 当前上下文 | 正在处理的输入，相当于"眼前的事" |
| 短期记忆 | 对话历史 | 多轮对话的上下文保留 |
| 长期记忆 | 向量数据库（RAG） | 跨会话的知识存储，"下次还记得你" |
| 情景记忆 | 历史经验存储 | 过去任务的成功/失败经验积累 |
大多数 Agent 项目的核心工作，都在短期 + 长期记忆上做文章。这里有一个始终绕不开的物理限制——Context Window 的容量是有限的，你塞进去的内容越多，成本越高，模型也越容易"注意力涣散"。怎么管理好这个窗口，是每个 Agent 工程师的必修课。
- Planning（规划） ——Agent 的大脑如果说工具是 Agent 的手脚，那 Planning 就是它的大脑，负责回答一个核心问题：拿到一个复杂任务，怎么一步一步把它做完？目前主流的规划策略有三种：Task Decomposition：把大任务拆成小任务，逐个击破。就像你写论文，不会上来就开始打字，而是先列大纲ReAct Loop：思考 → 行动 → 观察结果 → 再思考，循环推进。这是目前最主流的范式，后面会单独展开讲Plan-and-Execute：先制定完整计划，再逐步执行。适合任务边界清晰、不需要中途动态调整的场景
- Action / Tool Use（工具调用） ——Agent 的手脚一个 Agent 能做到什么，上限完全取决于它手里有什么工具。常见的工具类型大概分这几类：信息获取：搜索引擎、数据库查询、读本地文件代码执行：Python 解释器、Terminal，让 Agent 真正能"动手算"外部服务：发邮件、写日历、调第三方 API子 Agent：把另一个 Agent 当作工具来调用——这是多 Agent 系统的基础，后面会细讲这里有一个容易被忽视的细节：工具的描述写得好不好，直接影响模型能不能正确选择和调用它。工具再强，描述写得一团糟，模型也不知道该在什么时候用它——这跟招了一个能力很强的员工，但从来不告诉他什么情况该做什么，本质上是一回事。
四、框架选型：各有分工，别一口气全学
刚入门 Agent 开发，很多人容易犯一个错误——看到市面上一堆框架，LangChain、LlamaIndex、LangGraph、AutoGen、CrewAI……恨不得全部学一遍，结果每个都会一点，每个都没搞透，真正要做项目的时候反而不知道该用哪个。正确的姿势是：先搞清楚每个框架是为了解决什么问题而生的，再按需取用。
LangChain——入门首选，生态天花板
如果你什么都不懂，就从 LangChain 开始。它是目前生态最完整、社区最活跃的 Agent 框架，几乎你能想到的功能——接模型、调工具、管记忆、做 RAG——它都有现成的组件，拿来即用。它的价值不在于"它做得最好"，而在于它覆盖面最广，试错成本最低。做原型验证、跑通一个最小可用的 Demo，LangChain 是效率最高的选择。但它的问题也很明显：封装太重，抽象层太多，出了 bug 你可能不知道错在哪；灵活性上也有限制，一旦你的需求稍微复杂，就会开始跟框架"搏斗"。所以 LangChain 适合用来入门和快速验证想法，不建议在生产级的复杂系统里过度依赖它。
LlamaIndex——专心把 RAG 这件事做到极致
如果你的需求是让 Agent 能够读懂你的文档、检索你的知识库、回答基于私有数据的问题，那 LlamaIndex 就是为你量身定制的。它的核心专长是 RAG（检索增强生成）——怎么把文档切块、怎么做向量化、怎么建索引、怎么在检索时提高准确率。这些事情 LangChain 也能做，但 LlamaIndex 做得更精细、更深入。典型使用场景：公司内部知识库问答、合同文档分析、技术文档检索助手。只要你的项目核心是"让模型读懂你的数据"，LlamaIndex 优先。
LangGraph——当你需要真正"可控"的 Agent
LangChain 做复杂任务时有个根本性的问题：流程不透明，你很难精确控制 Agent 在每一步该做什么、不该做什么，出了问题也难以调试。LangGraph 解决的就是这个问题。它把 Agent 的执行流程建模成一张状态机图——每个节点是一个执行步骤，边是流转条件，整个执行过程清晰可见、可以精确干预。这意味着什么？你可以做到：某一步失败了自动走备用分支、人工审核通过再继续执行、复杂的多步任务中途暂停再恢复……这些在 LangChain 里很难优雅实现的需求，LangGraph 天生就支持。适合场景：流程复杂、需要精确控制每个节点、对稳定性要求高的生产级 Agent。上手曲线比 LangChain 陡，但一旦理解了状态机的思维方式，你会发现它才是做严肃 Agent 项目的正确姿势。
AutoGen & CrewAI——多个 Agent 协作的世界
前面三个框架本质上都是在做单 Agent的事，而 AutoGen 和 CrewAI 进入的是另一个维度：让多个 Agent 彼此通信、相互协作，共同完成一个任务。两者的侧重点略有不同：AutoGen更底层，核心是解决"Agent 之间怎么对话"的问题。你可以定义多个角色，让它们在一个对话环境里互相提问、互相纠错、共同推进。适合需要高度定制化多 Agent 通信逻辑的场景。CrewAI则更上层，思路更接近"模拟一个团队"——你定义一个研究员、一个写手、一个审核员，给他们分配任务，让他们像真实团队一样分工协作。上手更快，适合快速搭建角色分工明确的多 Agent 流水线。这两个框架相对小众，不建议一开始就学，等你把前面三个玩熟了、真正遇到"单个 Agent 搞不定"的需求时，再来研究不迟。
五、实战路径：学一个模块，做一个 Demo
理论学完不动手，两周之后你会发现自己什么都记得，但什么都做不出来。最高效的学习方式只有一个：每学完一个模块，立刻用一个真实的项目把它跑通。做出来的东西，才是真正属于你的东西。
阶段 1：Prompt Engineering——让模型老老实实按格式输出
很多人学完 Prompt Engineering，验证方式是"感觉模型回答得好多了"。这太虚了。这个阶段的 Demo，要有一个硬指标来检验你学没学到位。目标：做一个能稳定输出结构化 JSON 的 Agent。输入一段自然语言，比如"帮我记录一下，明天下午三点跟张总有个会议，地点在公司三楼"，Agent 输出的不是一段话，而是一个格式规范、字段完整的 JSON：
{ "title": "与张总会议", "date": "2025-03-27", "time": "15:00", "location": "公司三楼"}
听起来简单，但要做到稳定输出——换一百种说法，格式都不乱、字段都不丢——你才会真正理解 Prompt 的约束设计、Few-shot 示例的作用，以及为什么输出格式的描述要写得那么死板。
阶段 2：Tool Use——让 Agent 真正能"查"能"算"
光靠训练数据，模型回答不了"苹果今天的股价是多少"，也算不准"我的持仓现在值多少钱"。这个阶段要做的，就是给 Agent 装上手脚。目标：给 Agent 接入搜索工具 + 计算器，让它能回答需要实时数据 + 计算的复合问题。比如用户问："苹果最新股价乘以我持有的 200 股，现在总市值是多少？"一个装好工具的 Agent 会这样处理：先调用搜索工具拿到实时股价，再调用计算器把结果算出来，最后把完整答案返回给用户——全程不需要你介入。做完这个 Demo，你会理解工具描述怎么写模型才能正确选用、多工具并存时的调用逻辑是怎么跑的，以及 ReAct Loop 在实际代码里长什么样。这些东西看文档永远是抽象的，自己跑一遍就全清楚了。
阶段 3：Memory + RAG——让 Agent 有记忆，有知识
到了这个阶段，你要解决的是两个相关但不同的问题：Agent 怎么记住用户说过的话，以及怎么读懂你给它的文档。目标：接入向量数据库，上传一份产品文档，做一个有长期记忆的问答 Agent。具体来说，你要实现的效果是：用户上一个会话里问过"我们的产品支持哪些支付方式"，这一个会话里接着问"刚才那个问题，能展开说说微信支付的接入流程吗"——Agent 能接得上，不会一脸茫然地说"请问您指的是哪个问题"。同时，它回答产品相关问题时，依据的是你上传的真实文档，而不是模型自己编出来的内容。这个 Demo 做下来，RAG 的完整链路、向量数据库的基本用法、短期记忆和长期记忆怎么协同——这些概念会从纸面上的名词，变成你真正理解的东西。
阶段 4：Multi-Agent——让一群 Agent 协作干一件大事
前三个阶段都是单个 Agent 在工作，这个阶段要上一个量级：多个 Agent 各司其职，协作完成一个单靠一个 Agent 搞不定的复杂任务。目标：用 LangGraph 实现 Supervisor + Worker 架构，做一个自动搜集资料、分析、输出报告的多 Agent 系统。架构大概是这样的：一个 Supervisor Agent 负责拆解任务、分配工作、汇总结果；底下挂着几个 Worker Agent，一个专门负责联网搜集资料，一个负责对资料做分析和提炼，一个负责把结论整理成结构化报告。用户只需要输入一个主题，比如"帮我调研一下国内 AI 编程工具的市场现状"，整个流水线自动跑完，最后给你一份可以直接用的报告。做完这个 Demo，你对 Multi-Agent 的理解就不再停留在"多个 Agent 互相说话"这个层面，而是真正清楚任务怎么拆、状态怎么流转、Agent 之间的边界怎么划——这也是目前业界最主流的复杂 Agent 工程架构。
四个阶段，四个 Demo，每一个都能独立运行、独立展示。学完之后你会发现，你不只是"懂了 Agent"，而是手里有四个真实做过的东西——这才是跟只看过视频和文章的人之间，真正的差距所在。
最后说一句
Agent 开发现在还是一个"早期市场"——框架在快速迭代，最佳实践还没完全沉淀，大量工程问题等待被解决。
这意味着：现在入场，成本低，红利高。
不需要等"学完所有理论"再动手。跑起来一个 Demo，遇到真实问题，带着问题回来学——这才是这个领域最快的学习路径。
