1. 先别碰框架，搞清楚 AI Agent 到底是个什么

1.1 一层层拆掉概念的外衣

“AI Agent”这个词最近被聊得太多了，社群里的讨论、公司的立项文档、技术大会的演讲主题，到处都能看到它的身影。但如果你去问十个想入行的人“Agent 到底是什么”，可能七八个都只能说个大概。这很正常，因为这个词本身承载了太多层含义：从学术界的 autonomous agent，到工业界的 LLM-based agent，再到产品层面的“数字员工”“智能助手”，每层语境里的 Agent 长得都不太一样。

我个人的理解比较朴素：AI Agent 就是一套能把大模型接进真实业务流程的自动化系统。它跟传统函数的区别在于，传统函数是你写死逻辑、输入什么就吐什么，而 Agent 内部有一个“决策大脑”（通常是 LLM），它看着用户的目标，自己决定下一步该调用什么工具、拿什么参数、生成什么内容，然后基于反馈调整行动。

打个比方：传统代码就像外卖小哥按固定路线送餐，而 Agent 像出租车司机——客户说去哪，司机自己规划路线、判断堵不堵车、决定换不换道，最后把客人送到地方。整个过程有环、有反馈、有自主决策。

把这个概念拆开看，其实就四件事：

• 感知：接收用户输入、读取系统状态、获取工具返回的结果。
• 决策：由 LLM 进行推理，判断当前该做什么、下一步策略是什么。
• 行动：调用外部工具（搜索引擎、代码执行器、数据库、API）或生成回复。
• 反馈：把行动结果重新喂给模型，循环直到达成目标。

如果你连这四步的流转逻辑都不清楚，就贸然去啃 LangChain 源码或者把 Dify 的工作流节点拖来拖去，你只会在“好用”或者“不好用”的表层感受里打转，完全不知道哪里出了问题、为什么出了问题、应该怎么修。这也是我这篇文章想说的第一句话：先把底层的骨架子搭明白，再去盖框架的房子。

1.2 Agent 和传统程序的区别，不在技术栈，在思维方式

很多从传统开发转过来的朋友，最容易犯的一个错是：拿写 CRUD 的思路去写 Agent。

传统程序讲究的是确定性，if-else 分支清清楚楚，状态流转全靠代码枚举，一个变量是什么值，程序跑完必然是什么结果。Agent 世界不一样，核心是概率性的——同一个 Prompt，温度调到 0.7，问两次可能给你两个不同的回复；调用同一个工具，传参的格式可能时对时错；甚至模型“决定”要调哪个工具这件事，本身也是一个概率分布。

这意味着你写 Agent 的时候，必须接受“不确定性”作为系统的一部分。你不光是写业务逻辑，你还在设计一个带决策能力的闭环控制系统。你没法保证模型永远做对，所以你要加校验、加重试、加日志、加监控，要知道模型在哪个环节拐错了弯。

我在带新人时经常用一个类比：写传统代码是在修一条笔直的马路，你可以提前把每个路口的红绿灯时间调好；写 Agent 是在训练一个驾驶员，你没法保证他次次都选对路，但你可以给他装好导航（工具调用规范）、贴好路标（Prompt 约束）、配上副驾驶（巡检校验逻辑），让他即便走错了也能及时发现、及时掉头。

所以如果你是一个完全不懂这些思维差别的转行新人，一上来就钻进框架里，很可能学了两个星期仍然只会照葫芦画瓢地搭 demo：拖进去一个模型节点，连一个搜索工具，跑通了一句话问答，就以为自己会了。真到生产环境里，用户多问两句、工具返回一个异常格式、模型抽风给了一个错误参数，你立刻傻眼。不是框架不行，是你心里没有那张“闭环控制”的图。

1.3 为什么框架会是新手最大的陷阱

我绝对不是在说框架不好。恰恰相反，LangChain、LlamaIndex、Dify、CrewAI 这些项目都是工程效率神器，对生产落地帮助非常大。但框架之于新手，就像自动挡之于刚学车的人——它会让你很舒服，却会掩盖你对车辆机械原理的理解。自动挡当然好开，但一个只知道踩油门和刹车、连挡位都不认识的人，哪天自动变速箱出了故障，他连问题出在哪都说不出来。

框架的本质，是把 Agent 开发里的常见模式抽象成现成的组件：内存管理、工具调用协议、多步编排逻辑、模型接口封装，全都给你包好了。你用框架时，调用一个AgentExecutor或者拉一条工作流连线，背后几百行逻辑就自动跑起来了。你确实省下了写样板代码的时间，但你同时也把“理解为什么要这样设计”的机会给跳过了。

更麻烦的是，框架的抽象层把细节藏得太深了。当你封装一个工具后，你不需要关心模型是怎么决定调用它的；当工作流跑飞的时候，你也不容易看出是哪一步的哪个输出把后面的提示词给污染了。可实际排障时，这些你“不需要关心”的细节恰恰是问题的根源。

所以我的建议非常清晰：前一个月，不要碰任何框架。用裸的模型 API（OpenAI、Claude、国产模型都行）亲自搭一遍带工具调用闭环的小项目。笨办法走一遍，你对整个系统的理解深度，顶得上在框架里折腾三个月。等你能用自己的代码实现“让模型决定要不要查天气、怎么查、拿到结果怎么回复”哪怕只有五十行的逻辑之后，再回头去用框架，你会发现框架里的每个概念你都认得——哦，这是工具注册，哦，这是会话记忆，哦，这是 Agent 循环。到那个阶段，框架才是帮你提效的工具，而不是替你遮住眼睛的黑箱。

2. 新手和转行者应该先学什么，三条主线缺一不可

2.1 第一条主线：把 Prompt 工程和模型行为摸透

有些朋友学 Agent，一上来就钻进“多角色编排”“记忆机制”“工具调度”这类进阶概念里，结果发现啥都学不踏实。其实 Agent 的地基只有一块，就是你清不清楚模型是怎么根据输入决定输出的。

在传统开发里，函数的行为靠代码约束；在 Agent 开发里，模型的行为靠文字约束。所谓 Prompt 工程，本质上就是用自然语言（以及系统指令、上下文格式、示例样本）去约束一个概率模型的输出空间。这个能力是 Agent 一切高级功能的基础：工具调用，本质是让模型输出一个符合 JSON Schema 的函数调用指令；多步推理，本质是让模型在回答中构建思维链；记忆控制，本质是通过上下文拼接来决定模型能“看到”哪些历史信息。

所以我建议先花一到两周，专心做以下几件事：

• 把系统提示词（system prompt）和用户提示词（user prompt）的区别吃透，搞清楚哪些约束应该放在系统侧，哪些任务描述应该放在用户侧。
• 研究结构化输出：怎么让模型稳定返回 JSON、怎么定义 JSON Schema、怎么做强校验和自动纠错。
• 理解 temperature、top_p、max_tokens 这些采样参数对输出的影响，知道“要创意”和“要稳定”分别应该怎么调。
• 搭建几个 Prompt 模板库，把常见任务的提示词沉淀成可复用模块，顺便练一练变量替换和渲染逻辑。

这一阶段不需要写太多代码，重点是建立“跟模型交流”的感觉。把模型当成一个能力很强、但偶尔犯糊涂的新同事，你需要学会把需求讲清楚、把边界划明白、把格式给定死。这套沟通能力，比任何框架知识都值钱。

2.2 第二条主线：最低限度的代码能力——API 调用与数据流转

转行的朋友对代码往往有两极化的心态：一种是畏难，觉得“我不懂编程怎么搞 AI Agent”；另一种是轻视，觉得“写代码嘛，我又不是没写过”。其实 Agent 开发对代码能力的要求不算高，但有一条底线：你必须能自己把数据从 A 端接到 B 端，并且处理过程中可能出现的各种异常。

这里不需要你去啃红黑树、背算法题，但你得熟练掌握：

• HTTP 调用和 REST API 的基本姿势（POST、GET、请求头、JSON body）。
• 至少一个 Python（或 Node.js）的常规异步用法，知道怎么并发请求、怎么设置超时。
• JSON 的序列化、反序列化、嵌套字段提取，以及 JSON Schema 的校验。
• 基本的错误处理：try/except、重试机制、日志打印。
• 环境变量的管理和 API Key 的安全存放。

随便举个最简代码示例，你能立刻看懂并知道怎么改，就算是过关了：

import json import httpx # 这里只是模型 API 调用的一个最小范例 # 真实场景里你还需要加超时、重试、限流和错误处理 def call_llm(messages): resp = httpx.post( "https://your-model-api-endpoint/v1/chat/completions", headers={"Authorization": "Bearer YOUR_API_KEY"}, json={"model": "your-model", "messages": messages, "temperature": 0.7}, timeout=30, ) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"] conversation = [ {"role": "system", "content": "你是一个乐于助人的助手。"}, {"role": "user", "content": "你好，请介绍一下你自己。"}, ] reply = call_llm(conversation) print(reply)

别小看这种代码，很多新手卡在“能跑通 demo 但不会联调”的尴尬期，就是因为这些基础数据处理能力没过关。你后边写 Agent 的时候，大量时间都在处理工具的返回结果、清理模型的输出、拼接下一轮 Prompt。这些琐碎的事，恰恰是决定 Agent 能不能真正稳定工作的地方。

2.3 第三条主线：工程化基础，从 demo 到能用是有距离的

很多教程教 Agent 都止步于“跑通 demo”。跑通 demo 确实很有成就感，但离“能用”还有十万八千里。真要在生产环境里放一个 Agent，你还要面对一堆工程问题：

• 状态管理：一次多轮对话里，哪些信息需要记住、哪些该忘掉？记忆是放上下文里、向量库里还是外部数据库里？
• 错误恢复：模型返回了非法 JSON，工具超时了，API 触发了限流，下一步怎么办？
• 日志与可观测性：Agent 每个步骤的输入输出你都得有记录，不然排障时两眼一抹黑。
• 成本控制：一个多步 Agent 跑一轮可能调用好几次模型，Token 用量得心里有数。你去搜一搜“AI Agent token 是什么意思”，就会看到 Token 不光是计费单位，还直接影响上下文管理策略——你塞多少历史记录、模型能记住多少信息、Prompt 会不会超长，全是 Token 说了算。
• 评测体系：你改了一版 Prompt，怎么知道是变好了还是变差了？没有评测集、没有基准对比，你就是在盲调。

这一阶段的练习，我建议直接奔着一个“能给自己用的小产品”去。比如做一个带联网搜索能力的周报助手：你用裸 API 写工具调用逻辑、自己维护多轮对话状态、自己把搜索结果格式化后塞进 Prompt、再自己设计一个“用户说满意才算成功”的简单评测。做完这个项目，你对工程化基础的理解，会比做十个 demo 都扎实。

3. 到了什么阶段才该碰框架，框架到底怎么选

3.1 框架帮你解决了什么问题

等你亲手用裸代码实现过一遍 Agent 闭环之后，你心里就会有“痛点清单”：消息循环写了太多次，每个新 Agent 要重复堆样板代码；工具调用的 JSON Schema 解析容易出错，希望有人帮你封装好；会话记忆存哪、怎么轮转、怎么摘要，想做通用但每次都重新造轮子；多步骤编排代码一复杂，读起来跟意大利面似的。

这些痛点，就是框架存在的意义。框架不是魔法，它只是把行业里已经踩过无数坑的通用模式沉淀成了现成组件。LangChain 的create_agent、Dify 里的工作流编辑器、CrewAI 的角色分工体系，都只是“别人帮你踩完坑之后的较高效率封装”而已。

但你要清楚地知道：框架给出的是一种约定俗成的解法，不是唯一解法，也不一定是最适合你的解法。它提供了抽象，但你永远要回得来——出问题时，你得能扒开抽象层，看到里面实际在做的事情。

3.2 主流框架照妖镜：适合自己的才是好的

现在市面上框架确实多，你去搜相关热词，LangChain、LlamaIndex、Dify、CrewAI、Coze 各种项目满天飞，社区里每天都在争哪个最好。我直接说我的态度：没有最好的框架，只有当前阶段最不折腾的框架。我给一个对照表供大家参考：

这里要说一个很现实的点：如果你看中的是尽快“让一个 Agent 跑起来”，Dify 这类可视化工具确实香，拖拖拽拽就能搭一个带知识库、带工具链的聊天机器人。但如果你是转行求职，想在面试里展示真正的理解和工程能力，只会在 Dify 里拖节点是远远不够的。面试官大概率会问：“如果不借助框架，你会怎么设计一个 Agent 系统？”这句话能直接筛掉一批只玩过可视化编排的人。

3.3 我推荐的循序渐进路径：先临摹，再解构，后创造

当你确信自己已经完成了上一节说的三条主线学习之后，我来给你一条框架学习的“三步走”路线：

第一步，临摹。挑一个目前社区里口碑最好、文档最全的入门项目（比如用 LangGraph 搭一个带工具调用和记忆的客服机器人），照着官方教程原封不动跑通。跑通了别急着欢呼，打开生成的代码看一眼，每一行都试着理解它在干什么，遇到不懂的函数就回去翻源码文档。这一步的目标不是“会复制”，而是“见过猪跑”。

第二步，解构。把框架代码拿掉一半，改成裸 API 实现。比如 LangGraph 里的 StateGraph 帮你做了状态管理，那你就自己实现一个简单的状态类；CrewAI 帮你把多 Agent 的协作封装好了，那你就自己定义两个while循环来模拟角色切换和消息传递。这个阶段你会开始真正产生“原来框架里这个设计是这个意思啊”的感觉。

第三步，创造。带着一个真实的问题，选一个框架从零开始搭应用。注意，这个应用必须是你自己的需求，而不是教程里的示例。只有你自己想要一个东西，你才会主动去调 Prompt、主动做评测、主动改流程。也只有在这种动机驱动下，框架的各种概念才能真正内化成你自己的技能。

我自己带过的转行学生里，凡是走完这三步的人，面试时对框架的讨论都能说出干货；光刷教程不做项目的人，一问就露馅。

4. 避坑实录：新手最常见的几个误区

4.1 误区一：以为“能调通 API”就等于“会做 Agent”

我见过不少人，在 Notebook 里跑通了 GPT 的 API，然后就说自己是搞 AI Agent 的。这里得泼一盆冷水：调通一个 LLM API，只是你拿到了引擎，离“造出一辆能上路的车”还有八条街。真实的 Agent 是个“设备齐全的小车”，你得给它装上方向盘（规划逻辑）、挂上倒挡（纠错机制）、配上仪表盘（日志和评测）、摊开导航地图（工具和上下文）。一些 Agent 之所以在生产环境里翻车，不是模型不够聪明，而是围绕模型的这套“基础设施”根本没搭好。

所以请务必逼自己做一个有“闭环感”的小项目——不只是“问一句答一句”，而是“用户给一个目标 → Agent 自主拆解 → 调工具 → 拿到结果 → 继续决策 → 给出最终答案”。哪怕这个 Agent 只干一件事、代码只有两百行，它也比你调一万次 API 更能帮你理解什么是 Agent。检验标准就一条：去掉人工干预，它能不能自己把整件事跑完？

4.2 误区二：盲目追新框架，被版本更新带着跑

框架圈有个很有意思的现象：LangChain 的 API 迭代速度快到离谱，社区天天有人发帖说“昨天能跑的代码今天不行了”。很多新手极易陷入“追版本”的泥潭，两天不刷更新就焦虑。其实你想一想就会明白——框架是工具，它是为你的业务服务的，不该成为你的学习主线。

我见到过更夸张的例子：有人花了三周时间，就为了把一个项目的 LangChain 版本从 0.1 升到 0.3，业务价值没增加一点，人就累得半死。这不叫学习，这叫被工具PUA。你真正应该锚定的是一些不容易变的底层概念：模型调用的基本原理、工具调用的协议设计、上下文记忆的管理策略、评测体系怎么搭。这些底层逻辑不管换什么框架都一样。当你把底层逻辑吃透了，版本更新对你来说也就是“换个 API 写法”的事，而不是“推倒重来”。

建议你给自己定一条规矩：新框架出来，看一眼它在解决什么问题就好，不要轻易把主力项目迁过去。等技术生态稳定了、社区踩坑的帖子多了，再动也不迟。

4.3 误区三：忽略评测，全凭感觉瞎调

新手做 Agent 的时候，最常见的操作是：改几行 Prompt，跑一个用例，感觉好一点就上线，感觉差一点就回滚。一句话：全凭玄学调参，没有评测体系。这是开发 Agent 跟开发传统程序最大的思维差异之一——传统程序有断言、有测试用例、有明确的正确/错误判定；Agent 这种概率系统，你必须用统计学思维来看待它。

你得给自己建一套最简评测方案：

• 准备一批覆盖常见场景的测试问题（20~50个起步，不要太多，别把自己吓到）。
• 定义清楚判定标准：回答是否准确？格式是否合规？工具调用是否正确？用户意图理解是否到位？
• 每次改动 Prompt 或流程，就整批跑一遍测试，记录通过率、失败原因。
• 把失败样例收集起来，反向去修 Prompt 或逻辑。

这套流程坚持两周，你就不会再“凭感觉”开发了。你会在数据面前看到哪些 Prompt 改动真正有效，哪些只是你的心理作用。这个思路放到生产里，就是 Agent 评测与回归测试的雏形。等你想进阶的时候，再去研究更专业的评估框架和数据集设计。

4.4 给转行者的具体建议：时间表与节奏

后台经常有转行的朋友问我：零基础转 AI Agent，到底需要多长时间？这个问题没有标准答案，但我可以给一个现实的时间预期：假设你每天能投入 2~3 小时，基础的 Python 语法（面向对象、列表字典、流程控制）差不多一两个月能扫盲；再花一个月做 Prompt 工程和裸 API 的小项目；然后再用两个月走完框架三步走、完成一个带记忆带工具的真实应用。前前后后大概四到六个月，你能达到“能独立开发一个小型 Agent 应用并说清楚设计思路”的水平——这个水平已经足够入行做初级开发或应用工程师了。

面试时，你不用堆砌“我学过 LangChain、Dify、CrewAI”，那没有信息量。真正有竞争力的说法是：“我理解 Agent 作为一个闭环系统包含感知、决策、行动与反馈几个环节；我能用裸 API 实现底层的工具调用循环；我也能用框架提效，并且知道框架抽象了哪些问题、出了故障去哪里排查。”这一段话一说出来，面试官心里就有底了。

不要被热搜里那些花里胡哨的框架名词晃花了眼。Agent 世界的门槛从来不是某个框架的 API，而是你有没有建立起“闭环、不确定性、评测驱动、工程化落地”这套完整思维。框架只是最后一公里代步的工具而已。

我以前带过两个转行的人，一个上来就猛啃框架，啃了两个月，demo 跑了不少，但一被问到“如果模型返回了非法 JSON 你怎么办”就卡壳；另一个老老实实从裸 API 开始学，用一个月把工具调用循环写明白，再回头看框架时简直一目了然，后来面试一次就过了。我常常觉得，Agent 入门这件事，慢就是快。你先舍得花时间看懂底层逻辑，后面所有框架知识都会变得顺理成章；你要是贪快，迟早会把省下的时间加倍还给踩坑。