从零手写Agent到框架选型：大模型自主决策与工具调用实战路线

1. 先搞清楚从零学 Agent到底在学什么很多人一上来就问“该先学 LangChain 还是先学 AutoGPT”这个问题本身就问错了。Agent 不是一个框架也不是一个库它是一套让大模型自主决策、调用工具、循环执行直到完成任务的系统设计模式。框架只是这套模式的某一种实现载体换一个框架底层逻辑是不变的。我见过太多人花了两个月把某个框架的 API 背得滚瓜烂熟结果面试官问一句“你的 Agent 怎么做错误恢复的”直接卡住。原因很简单他学的是框架的使用方法不是 Agent 的设计方法。所以这篇文章的核心思路是先建立 Agent 的思维模型再动手写最小可运行系统然后逐步叠加记忆、规划、多工具编排、安全防护等能力最后才去对比和选型框架。这个顺序不能反。反过来学你会被框架的抽象层遮住眼睛永远看不清里面到底发生了什么。这篇文章适合谁看如果你是大模型应用开发者、后端工程师想转型 AI 方向、或者产品经理需要理解 Agent 的能力边界都可以按这个路线走。不需要你先精通深度学习但需要你能写 Python理解 HTTP 请求和 JSON 的基本概念。整个学习周期如果每天投入两小时大概六到八周可以从零到能独立搭建一个可用的 Agent 项目。下面我把整个学习路径拆成五个阶段每个阶段说清楚学什么、为什么这么学、怎么验证自己学会了、以及最容易踩的坑在哪里。2. 第一阶段建立 Agent 的思维模型第 1 周2.1 先理解 Agent 和普通 LLM 调用的本质区别普通 LLM 调用是什么你给它一段 prompt它给你一段回复结束。一次输入一次输出没有循环没有工具没有状态。Agent 是什么你给它一个目标它自己决定下一步做什么执行一个动作观察结果再决定下一步直到它认为任务完成或者触发终止条件。核心区别就三个字循环体。用伪代码表示一个最原始的 Agent 循环长这样while not done: thought llm.think(context) # 思考下一步 action llm.decide(thought) # 决定用什么工具 result execute(action) # 执行工具 context.append(result) # 把结果放回上下文 done llm.check(goal, context) # 判断是否完成这个循环就是 Agent 的心脏。后面你要学的所有东西——记忆管理、多工具编排、错误恢复、并发控制——都是在给这个循环加装备。所以第一周的任务不是写代码是把这张图刻在脑子里。2.2 必读的几份材料按顺序来市面上的教程很多但质量参差不齐。我建议按这个顺序读吴恩达的 Agent 系列教程他的讲法最大的好处是把 Agent 拆成了四个模块——规划、工具、记忆、执行。这个四分法不一定完美但作为入门框架非常好用能让你快速建立分类意识。ReAct 论文Reasoning Acting 的原始论文不用全读重点看它怎么把“思考”和“行动”交替进行的。手写 ReAct Agent 是检验你是否理解 Agent 循环的最好方式。一篇关于 Agent 架构的综述找一篇 2024 年之后的综述文章快速扫一遍知道学术界把 Agent 分成了哪些类型、有哪些开放问题。这一步的目的是建立全局视野不是深入细节。注意不要在这一周就去碰 LangChain 或任何框架的文档。框架文档会给你大量“怎么做”的细节但你还没有“为什么”的判断力很容易被带偏。2.3 这一周的验证标准学完第一周你应该能回答这几个问题Agent 的循环体包含哪几个基本步骤ReAct 和普通 Chain 的区别是什么为什么 Agent 需要工具调用不用工具行不行一个 Agent 如果没有终止条件会发生什么如果你能用自己的话把前三个问题讲清楚第四题能说出“会无限循环、消耗 token、可能产生副作用”那这一周就过关了。讲不清楚就回去重读不要急着往下走。3. 第二阶段手写一个最小可运行 Agent第 2-3 周3.1 为什么必须手写不能直接上框架这是整个学习路线里最关键的一个决定。我强烈建议你至少手写一个完整的 ReAct Agent不依赖任何 Agent 框架只用最基础的 LLM API 和 Python 标准库。原因有三个。第一框架帮你隐藏了 prompt 拼接、输出解析、循环控制这些细节但这些细节恰恰是 Agent 最容易出问题的地方。第二手写一遍之后你再看框架的源码会有“原来它就是这么干的”的顿悟感学习效率反而更高。第三面试和实际工作中遇到 Agent 行为异常时你需要有能力从底层排查而不是只会调框架参数。3.2 最小 Agent 的四个组成部分一个能跑的最小 Agent需要这四个东西第一一个 LLM 调用接口。用你熟悉的任何一家 API 都行关键是封装成一个函数输入 messages 列表输出文本。第二一套工具定义。从最简单的开始比如一个计算器工具、一个获取当前时间的工具。工具的定义要包含名称、描述、参数 schema。描述非常重要LLM 就是靠描述来决定什么时候调用哪个工具的。第三一个输出解析器。LLM 输出的文本需要被解析成结构化的“思考”和“行动”。最简单的做法是约定输出格式比如用Thought:和Action:作为标记然后用正则提取。第四一个循环控制器。控制最大迭代次数、处理工具执行异常、判断终止条件。3.3 实操手写 ReAct Agent 的关键代码结构下面是我自己手写时用的结构你可以参考import re import json def react_agent(goal, tools, max_steps10): context f目标{goal}\n for step in range(max_steps): # 1. 让 LLM 思考并决定行动 prompt build_react_prompt(context, tools) output call_llm(prompt) # 2. 解析输出 thought extract_thought(output) action, action_input extract_action(output) # 3. 判断是否终止 if action finish: return action_input # 4. 执行工具 try: result tools[action](**action_input) except Exception as e: result f工具执行失败{e} # 5. 把结果追加到上下文 context fThought: {thought}\nAction: {action}\nObservation: {result}\n return 达到最大步数任务未完成这段代码不到三十行但它包含了 Agent 的所有核心要素。你把它跑通改一改 prompt加几个工具观察 LLM 的行为变化比看十篇教程都有用。3.4 这一阶段的常见坑坑一输出格式不稳定。LLM 有时候不按你约定的格式输出导致解析失败。解决办法是在 prompt 里给 few-shot 示例并且在解析失败时做一次重试。坑二工具描述写得太模糊。比如你写“计算器工具”LLM 不知道它能算什么、参数是什么格式。要写成“计算数学表达式输入是一个字符串形式的算式如 23*4”。坑三没有最大步数限制。我早期写的一个 Agent 因为工具一直返回错误LLM 一直重试跑了四十多步才停烧了不少 token。永远要设 max_steps。实操心得手写阶段不要追求功能完整追求的是“我能解释每一行代码为什么这么写”。这个阶段慢就是快。4. 第三阶段给 Agent 加上记忆和规划能力第 3-4 周4.1 短期记忆和长期记忆解决的是不同问题手写的 Agent 有一个明显缺陷上下文窗口有限对话一长就装不下了。这就引出了记忆系统。短期记忆解决的是“当前任务执行过程中的信息保留”。最简单的做法就是维护一个 messages 列表但要做窗口管理——超出 token 限制时要么截断最早的要么做摘要压缩。长期记忆解决的是“跨会话的信息保留”。比如用户上周告诉过 Agent 他的偏好这周再对话时 Agent 应该记得。这就需要一个外部存储通常是向量数据库把历史信息做 embedding 存进去需要时检索出来。这里有个容易混淆的点很多人把 RAG 和 Agent 记忆混为一谈。RAG 是检索外部知识记忆是保留交互历史两者技术上有重叠但目的不同。做 Agent 记忆时你要考虑的是存什么、什么时候存、什么时候取、取了怎么用。4.2 规划能力的三个层次规划是 Agent 从“被动响应”到“主动执行”的关键。我把它分成三个层次第一层隐式规划。就是 ReAct 那种LLM 在每一步的 Thought 里自己想做啥没有显式的计划。优点是简单缺点是长任务容易跑偏。第二层显式计划。先让 LLM 生成一个任务分解列表然后逐步执行。比如 Plan-and-Execute 模式先规划再执行执行过程中可以根据结果调整计划。第三层层次化规划。大任务拆成子任务子任务再拆形成树状结构。这个复杂度最高一般项目用不到但你要知道有这个东西。我的建议是先把第一层做扎实再尝试第二层。很多实际项目用 ReAct 加一个好的 prompt 就够了不需要上来就搞复杂的规划器。4.3 记忆系统的实操要点如果你要做一个带记忆的 Agent这几个设计决策要想清楚决策点选项建议存储介质内存 / Redis / 向量库原型用内存生产用向量库Redis写入时机每轮写 / 任务结束写任务结束写避免噪音检索方式相似度 / 时间衰减 / 混合混合检索效果最好压缩策略截断 / 摘要 / 分层摘要分层保留关键信息注意记忆系统最容易出的问题是“存了太多没用的东西检索时反而干扰判断”。宁可少存精存不要什么都往里塞。5. 第四阶段多工具编排与工程化第 4-6 周5.1 从单工具到多工具难点在哪里单工具 Agent 很简单LLM 只需要判断“用不用这个工具”。多工具就不一样了LLM 要判断“用哪个工具、按什么顺序用、工具之间怎么传递数据”。工具数量超过十个之后你会发现 LLM 的选择准确率明显下降。这时候需要做几件事工具分组把相关工具归到一类先让 LLM 选类别再选具体工具。工具描述优化描述要包含“什么时候用”和“什么时候不用”负向描述往往比正向描述更有用。动态工具加载不是所有工具都一次性给 LLM根据当前上下文只加载相关的几个。5.2 错误处理和重试机制Agent 执行过程中出错是常态不是异常。工具可能超时、可能返回格式不对、可能参数传错。一个健壮的 Agent 必须有错误处理。我的做法是三层防护工具层每个工具内部做参数校验和异常捕获返回结构化的错误信息而不是抛异常。Agent 层LLM 看到错误信息后决定是重试、换工具还是放弃。prompt 里要明确告诉它“遇到错误时可以重试但同一工具连续失败三次就换方案”。系统层设置全局的最大步数和超时时间防止失控。5.3 并发场景下的 Agent 设计这是很多人忽略的一块。当你的 Agent 要同时服务多个用户请求时问题就来了上下文怎么隔离工具调用怎么限流状态怎么管理基本思路是每个请求一个独立的 Agent 实例共享底层 LLM 客户端和工具注册表但上下文和状态完全隔离。如果工具调用有外部依赖比如数据库需要加连接池和限流。至于“AI Agent 怎么扛并发”这个问题核心不在 Agent 本身在于你的 LLM 调用层和工具执行层能不能水平扩展。Agent 的逻辑层通常是无状态的把状态外置到 Redis 或数据库就可以横向扩展。5.4 安全防护不能等到最后才做Agent 安全是一个独立的话题但你在工程化阶段就要开始考虑。主要风险包括Prompt 注入用户输入里藏指令让 Agent 执行非预期操作。工具滥用Agent 调用了不该调用的工具或者传了危险参数。数据泄露Agent 把敏感信息写到了日志或外部存储。防护手段包括输入过滤、工具权限分级、敏感操作二次确认、输出审查。这些不是可选项是必选项。6. 第五阶段框架选型与项目实战第 6-8 周6.1 主流 Agent 框架的定位差异到了这个阶段你已经有了足够的手写经验可以去看框架了。这时候你看框架的视角会完全不同——你不再是被框架牵着走而是带着判断力去评估。目前主流的几类框架框架类型代表适合场景学习成本通用编排LangChain / LlamaIndex快速原型、多工具编排中多智能体AutoGen / CrewAI角色协作、复杂任务分解中高轻量级各厂商 SDK 自带 Agent单一场景、快速集成低企业级各云厂商 Agent 平台生产部署、监控运维高选型的核心原则是先看你的场景需要什么再看框架能提供什么。不要因为某个框架火就用它也不要因为某个框架简单就轻视它。6.2 一个完整的 Agent 项目应该包含什么如果你要做一个能拿得出手的 Agent 项目至少包含这些模块Agent 核心循环控制、prompt 管理、输出解析工具系统工具注册、参数校验、执行隔离记忆系统短期上下文管理、长期存储检索可观测性日志、追踪、token 消耗统计评测体系任务成功率、工具调用准确率、响应时间安全层输入过滤、权限控制、输出审查6.3 评测怎么知道你的 Agent 好不好Agent 评测比普通 LLM 评测难得多因为它是多步的、有状态的。我常用的几个指标任务完成率给定一组任务Agent 能独立完成的比例。平均步数完成同类任务平均需要多少步越少越好。工具调用准确率选对工具、传对参数的比例。错误恢复率遇到错误后能自行恢复的比例。做评测时要注意测试集要覆盖正常路径和异常路径只测正常情况没有意义。6.4 面试中常被问到的 Agent 问题如果你是为了面试准备这几个问题出现频率极高ReAct 的原理是什么和 Function Calling 有什么区别Agent 的记忆系统怎么设计短期和长期怎么配合多工具场景下怎么提高工具选择准确率Agent 陷入循环怎么办怎么检测和打断怎么评测一个 Agent 的好坏Prompt 注入怎么防这些问题的答案如果你按前面的路线手写过、踩过坑都能用自己的实践经验回答而不是背八股。7. 几个我踩过的坑和对应的解法7.1 不要过早追求多智能体我刚开始学的时候看到 AutoGen 的多智能体演示觉得很酷花了两周去搭一个“产品经理程序员测试”的多 Agent 系统。结果发现大部分任务单 Agent 加好工具就能做多智能体反而引入了通信开销和协调复杂度。多智能体是解决特定问题的工具不是 Agent 的终极形态。先把单 Agent 做扎实。7.2 上下文管理比你想的重要Agent 跑长任务时上下文会迅速膨胀。我遇到过一个任务跑了十五步上下文到了八千 tokenLLM 开始“忘记”前面的关键信息。后来加了摘要压缩和关键信息提取才稳定下来。上下文不是越多越好是要让 LLM 在每一步都能看到它真正需要的信息。7.3 工具设计要“防呆”我写过一个数据库查询工具参数是 SQL 语句。结果 LLM 生成了一条 DELETE 语句差点出事。后来改成只允许 SELECT并且在工具层做了 SQL 解析校验。永远不要相信 LLM 会按你期望的方式使用工具要在工具层做硬约束。7.4 日志和追踪要提前做Agent 出问题时如果没有详细的执行日志排查起来非常痛苦。我现在的习惯是每一步的输入、输出、工具调用、耗时、token 消耗全部记录。这样出问题时能快速定位是哪一步、哪个环节出的错。8. 学习路线速查表把上面的内容压缩成一张表方便你对照执行阶段时间核心任务验证标准建立思维模型第 1 周读教程和论文理解 Agent 循环能讲清 ReAct 原理手写最小 Agent第 2-3 周不依赖框架写 ReAct Agent能跑通并解释每行代码记忆与规划第 3-4 周加短期记忆、尝试显式规划长任务不丢关键信息多工具与工程化第 4-6 周多工具编排、错误处理、并发能处理工具失败和并发请求框架与实战第 6-8 周选型、做完整项目、评测有可演示的项目和评测数据这个路线不是死的你可以根据自己的基础调整节奏。但顺序不要变先懂原理再手写再加能力最后用框架。反过来走你会花更多时间在调试框架的抽象泄漏上而不是在理解 Agent 本身。最后分享一个我自己的判断标准当你看到一个 Agent 框架的文档时如果能在脑子里把它翻译成“哦这就是在循环体里加了个记忆检索”说明你真的学明白了。如果还是觉得它很神秘那就回去再手写一遍。