本文基于作者真实项目开发经验分享AI Agent开发的核心知识体系。文章指出AI Agent工程师并非独立工种而是“XAI Agent”的复合角色转行门槛不高。文章详细阐述了AI Agent的核心机制包括Agent Loop、Tool Use、RAG、Memory和Multi-Agent协作并强调了工程化能力的重要性如上下文管理、权限安全、评测和成本控制。最后文章提出了一个推荐的学习路径帮助程序员从零开始构建自己的AI Agent项目。前言从 2023 年 ChatGPT 爆发至今大语言模型Large Language Model, LLM已经不再是“能聊天的工具”那么简单。短短三年多时间LLM 从对话助手演变成了能编写代码、操作文件系统、执行 Shell 命令、甚至自主分解任务并逐步完成的“智能体”——也就是业界所说的 AI Agent。随之而来的是越来越多的公司开始将 AI Agent 融入产品和工作流AI Agent 工程师的岗位需求也快速增长。我最初是一名前端工程师从 2022 年开始逐渐使用 Node.js 做后端开发并从此开始了我的全栈之路。再后来机缘巧合之下进了一家做 AI Agent 产品的公司并先后参与开发了多个不同形态的 AI Agent 产品。例如有 Web 网页端应用也有桌面端的应用担任的也是全栈角色前后端、AI Agent 都做。另外在工作之余我还出于兴趣写了一个开源的 AI Agent CLI 项目来帮助我更好地理解 AI Agent 的知识。说了这么多主要是想表达一点下面分享的内容来自真实的项目开发经验并非只看过几篇教程、翻阅过几份文档就凭空总结出来的。这篇文章算是对这段经历的一个总结打算分享给想进入 AI Agent 开发领域的人。AI Agent 是一个还在快速变化的领域这里的内容更多是提供一个参考方向而不是标准答案。AI Agent 工程师不是一个独立工种我对这个角色的理解是AI Agent 工程师不是一个独立的工种而是“X AI Agent”的复合角色。这里的 X 可以是前端、后端、全栈甚至产品经理但单独的“AI Agent 工程师”几乎不存在。AI Agent 做的事情是用代码去编排 LLM 的能力——让 LLM 调用工具、管理上下文、处理报错、跟外部系统对接。这些工作本身就是软件工程只是操作的对象从数据库和 API 变成了 LLM。所以如果你已经是一个有几年开发经验的前端、后端或者全栈工程师转 AI Agent 方向的门槛其实并不高。需要额外学的新知识不多后面「核心知识体系」一节会展开但是工程实现上的问题例如怎么管理上下文、怎么做错误恢复、怎么控制成本等等这些都是需要真正花时间去做好的而这恰好是有开发经验的人擅长的部分。从求职角度看有 AI Agent 开发经验的前端/后端工程师比没有这方面经验的同行工作机会更多。越来越多的岗位要求候选人有 AI Agent 相关的开发经验掌握这部分能力相当于拓宽了自己的选择面。大家有兴趣的话可以去各大招聘平台搜一下“AI Agent”看看实际的招聘信息下面列举了一些搜到的职位信息阿里云「AI Agent 研发工程师AI Coding 方向」——20-50K·16 薪要求有完整的研发经验深度理解 LLM/Agent/Prompt Engineering实质是全栈 AI大疆「高级后端开发工程师AI Agent 方向」——精通 Python/Go 后端熟悉智能体设计、工具调用、多 Agent 协作还要有分布式系统经验Boss 直聘上的「AI 智能体工程师」——15-55K 不等Python 必备要求熟悉 LangChain/LlamaIndex/Dify 等框架同时要有 Docker/K8s 部署能力心态调整知识量不大但做好不容易AI Agent 要学的概念不多例如 Tool Use、Agent Loop、RAG、Memory、Prompt Engineering 等等花几周时间就能大致理解。比起前端/后端开发要学习的 API、框架、浏览器兼容性问题AI Agent 的知识量算少的。但是把原理概念都弄懂不等于动手就能做出实际能用的产品。以我的经验来看真正耗时间的是下面这些工程问题上下文爆炸Agent 执行复杂任务时工具调用结果和文件内容会快速撑满上下文窗口导致模型遗漏早期指令或重复执行已完成的步骤幻觉Hallucination模型会自信地给出错误答案而且每次错的方式不一样无法用固定的规则去拦截成本失控一个复杂任务可能触发数十次 API 调用缺乏控制策略的话费用会远超预期评测困难Agent 的输出是非确定性的同样的输入跑两次可能得到不同结果传统的断言式测试不完全适用这些问题单靠理论知识无法彻底解决只能在实际项目中不断地试错、迭代打磨。拥抱不确定性在传统的开发工作中大家可能会有一个隐含的心理预期代码写对了就应该得到正确的结果。但是 AI Agent 开发不是这样的。同样的 Prompt模型可能这次给出完美的方案下次就给出有 bug 的方案。同样的工具调用序列模型可能这次用 3 步就能完成下次就得用 10 步才能完成。这种不确定性在初期会让人非常不适应需要调整心态。调整的方式是把心态从“写对代码”转变为“设计约束”。不需要让模型每次都做对而是设计足够好的护栏Guard Rails让模型在犯错时能被检测到并纠正。权限系统、循环检测Loop Guard、输出校验——这些“围栏”才是 Agent 工程师日常花时间最多的地方。边做边学学习科学里有一个被广泛引用的模型叫“学习金字塔”Learning Pyramid来源于 Edgar Dale 的经验之塔Cone of Experience理论。它的核心观点是光听讲或者读书知识的留存率很低而通过实践练习可以大幅提高知识的留存率。这背后的原理和艾宾浩斯遗忘曲线Ebbinghaus Forgetting Curve相通——新学的信息如果不主动回忆遗忘速度会非常快而动手实践本身就是一种主动回忆能加深对知识的理解理解得越深就越不容易忘。AI Agent 开发尤其适合这种方式。AI Agent 的知识本身不多但很多工程问题——比如模型在什么情况下会反复调同一个工具停不下来上下文压缩到什么程度才不会丢失关键信息——光看文档是预想不到的只有动手做了才会碰到这些问题。碰到问题并且解决它这个知识点就真正变成你自己的了。一次真实的教训我参与开发的一个 AI Agent 产品上线初期遇到过一次印象很深的故障——Agent 死循环。事情是这样的一个用户让 Agent 抓取某个网页的内容Agent 调用了 WebFetch 工具但目标 URL 返回了错误。正常预期是模型发现失败后换一种方式处理但实际情况恰恰相反——模型认为“刚才没成功再试一次应该可以”于是用完全相同的参数再次调用了 WebFetch。第二次当然也失败了然后第三次、第四次……连续 5 次调用完全相同的工具、传入完全相同的参数、得到完全相同的错误。这 5 轮无效调用本身的开销并不大但每一轮失败都会往消息历史里追加一组请求和响应几轮下来上下文就膨胀了不少。后来我们在另一位用户那里见到了同样的模式只不过这次 Agent 是在 Bash 命令调用上陷入了循环而且持续时间更长——上下文一路膨胀到超出了模型 262K token 的上限实际请求达到了 294KAPI 直接拒绝了请求导致用户的整个会话随之中断。这两个案例的背后其实是同一个问题Agent 在工具调用失败时陷入重试循环而每次重试又会撑大上下文最终导致上下文溢出。要解决这个问题的思路并不难——“检测到循环就停下来”“上下文接近上限就压缩”——但在上线之前我们根本没预料到模型会用完全相同的参数反复调用同一个工具因为测试环境里从没出现过这种行为。真正动手修的时候才发现也不只是加一个 if 判断那么简单循环检测需要对比最近几次工具调用的参数来判断是否重复上下文压缩需要在接近上限时及时触发把旧消息替换成摘要的同时还要保留关键信息。这次经历让我意识到AI Agent 开发中最难的部分不是理解概念而是应对模型在生产环境中的各种非预期行为。一个需要警惕的误区现在市面上有很多“零代码搭建 AI Agent”的工具——Dify、Coze、n8n 等等。这些工具降低了入门门槛让不会编程的人也能拖拽出一个 Agent 工作流。对于快速验证想法来说它们没有问题。但如果你的目标是成为一名 AI Agent 工程师只接触预构建的组件而不理解它们的构造原理会严重限制你解决新问题的能力。举个例子假如我们用 Dify 搭了一个 Agent 工作流在做单轮问答或者简单的信息查询时效果不错。但上线之后可能会碰到这样的情况——Agent 在某类任务上反复调用同一个工具停不下来也就是死循环或者对话变长之后开始“忘记”前面的指令。Dify 提供了最大迭代次数和记忆窗口大小这类配置项可以做一些粗粒度的调整。但如果需要更精细的控制比如通过对比前后几次工具调用的内容来检测死循环或者在上下文过长时让 LLM 先把早期对话生成一份摘要、再用摘要替换掉原始消息而不是直接丢弃早期消息导致关键信息丢失这些就超出平台能提供的范围了。理解底层机制的人可以自己写代码实现这些策略不理解的话就只能在平台给的几个参数里来回调试。所以我的建议是可以用框架或低代码工具来加速开发但至少自己从零实现一次最小的 Agent——哪怕只是一个 50 行的 while 循环加一两个工具理解消息传递、工具调用和循环控制的基本机制。有了这层理解之后再去学习任何框架或工具都不会觉得是黑盒。后面的「推荐学习路径」一节会给出具体的参考项目和资源。AI Agent 核心知识体系AI Agent 的知识可以分成三层来理解。第一层是地基LLM 基础第二层是核心机制Agent 区别于普通 LLM 调用的关键能力第三层是工程化怎么让 Agent 在生产环境里稳定运行。第一层LLM 基础/n能力边界 · API 调用 · 提示词工程 第二层Agent 核心机制/nAgent Loop · Tool Use · RAG · Memory · Multi-Agent 第三层工程化能力/n上下文管理 · 权限安全 · 评测 · 成本控制第一层LLM 基础不需要你理解 Transformer 的数学细节或者训练流程但需要理解 LLM 作为一个“接口”能做什么、不能做什么。LLM 的能力边界。 LLM 本质上是一个文本续写器——给它一段文本Prompt它生成后续文本Completion。它擅长自然语言理解与生成、代码编写、信息提取与总结、推理。但它不擅长实时信息获取、与外部系统交互、确定性逻辑判断、回答超出训练数据范围的问题。理解这个边界非常重要因为 AI Agent 的核心设计思路就是用工具弥补 LLM 的短板。需要实时信息就给它提供搜索工具需要操作文件系统就给它提供文件读写工具需要执行代码就给它提供 Shell 工具。Agent 的工程工作量大部分都花在“怎么让 LLM 正确地使用这些工具”上。API 调用。 所有 Agent 的起点都是调用 LLM 的 API。以主流的 Messages API 为例核心概念只有几个消息列表Messages一组按时间排列的对话消息每条消息有角色system/user/assistant/tool和内容、流式输出Streaming模型逐个生成 token客户端实时接收、以及 Token 与计费输入和输出都按 token 计费中文一个字大约 1-2 个 token。这些概念不复杂下面推荐材料里的 Datawhale《动手学大模型》教程就是从 API 调用开始讲起的跟着做一遍就能理解。提示词工程Prompt Engineering。 写好提示词是 Agent 开发的基本功之一。常用的技巧包括用系统提示词System Prompt定义 Agent 的角色、能力边界和行为规则用少样本学习Few-shot Learning在 Prompt 中给出示例引导模型按特定格式响应用思维链Chain of Thought引导模型先推理再回答以提高准确率。提示词工程涉及的内容很多但 Agent 工程师不需要掌握所有技巧。在实际开发中最常打交道的就三件事system prompt 怎么写能让模型行为更稳定、工具描述怎么写能减少误调用、以及哪些常见写法容易导致模型输出偏离预期。这一层的推荐材料 Datawhale《动手学大模型》是国内开源社区出品的中文教程从 API 调用到 RAG 应用开发都有覆盖适合零基础入门。Prompt Engineering 方面吴恩达与 OpenAI 合作的《ChatGPT Prompt Engineering for Developers》是英文授课B 站上有社区翻译的中文字幕版一两个小时就能看完。如果英文阅读没有障碍Anthropic 的 Prompt Engineering 指南是目前写得最系统的参考资料。第二层Agent 核心机制这一层是 AI Agent 区别于普通 LLM 对话的关键。Agent Loop智能体循环。 Agent 的核心运作模式可以用一句话概括思考 → 行动 → 观察 → 再思考。这个循环在代码层面是一个 while 循环。下面是 x-code-cli 中的简化版本while (turn maxTurns) { // 1. 调用 LLM传入消息历史和可用工具列表 const outcome await runTurn(state, model, tools) // 2. 模型返回 tool_calls → 执行工具把结果追加到消息历史 if (outcome.finishReason tool-calls) { await processToolCalls(outcome.toolCalls, state) continue // 回到循环顶部让模型看到工具结果后继续思考 } // 3. 模型返回 stop → 任务完成退出循环 if (outcome.finishReason stop) break }这段代码虽然只有十几行但它是所有 Agent 产品的骨架。不管是 Claude Code、Cursor还是 x-code-cli内核都是这个循环——区别只在于工具集有多丰富、错误处理有多完善、以及上下文管理策略有多精细。用流程图来表示tool_call stop 用户输入 调用 LLM/n(messages tools) 模型返回 执行工具 结果追加到 messages 输出最终回答工具调用Tool Use / Function Calling。 工具调用是让 LLM 从“只会说话”变成“能做事”的桥梁。一个工具的定义包含两部分输入参数的 Schema告诉模型“这个工具接受什么参数”以及一段自然语言描述告诉模型“这个工具能做什么、什么时候该用”。以 x-code-cli 中的 Shell 工具定义为例export const shell tool({ description: Execute a shell command and return stdout/stderr..., inputSchema: z.object({ command: z.string().describe(The command to execute), timeout: z.number().optional().describe(Timeout in milliseconds), }), })模型看到这个工具定义后在需要执行系统命令时就会调用它并按照 schema 生成正确的 JSON 参数。工具的实际执行逻辑是在 Agent 引擎侧完成的模型本身不执行任何代码——它能看到的只有工具的描述和参数定义。所以工具描述写得好不好直接决定了模型能不能在正确的时机调用正确的工具。描述太模糊模型就容易在不该用的时候误用或者在该用的时候漏掉。在实际开发时反复调整工具描述的措辞是非常常见的花在这上面的时间往往比写工具本身的代码还多。检索增强生成RAG。 LLM 的知识有截止日期也无法访问企业内部的私有数据。RAGRetrieval-Augmented Generation就是为了弥补这两个短板把企业内部文档、产品手册、最新资讯等内容预先存入一个知识库用户提问时先从知识库中检索出相关片段再把这些片段连同问题一起发给模型让模型基于这些补充材料来回答。一个典型的 RAG 流程包含文档分块 → 向量化Embedding→ 存入向量数据库 → 检索时做相似度搜索 → 取回相关文档块 → 拼入 Prompt。RAG 在概念上不复杂但工程细节很多分块策略怎么选、chunk 多大合适、向量模型用哪个、检索召回率怎么评估——这些问题没有标准答案需要根据具体场景调试。记忆Memory。 Agent 的记忆分两种。短期记忆就是当前对话的消息历史随着对话进行消息历史不断增长最终会触及上下文窗口的限制需要压缩或截断来管理具体策略在后面第三层「上下文管理」部分会讨论。长期记忆是跨会话持久化的信息——用户偏好、项目上下文、之前对话中达成的约定。没有长期记忆的 Agent 每次对话都从零开始昨天你告诉它项目用 ESM 模块规范今天它可能又会按 CommonJS 模块规范来写。长期记忆的难点在于筛选一轮对话可能有几十条消息真正值得长期记住的也许只有一两条事实需要一套机制来自动完成这个提取。x-code-cli 的做法是在每轮对话结束后后台用 LLM 从对话中提炼出值得记住的事实以结构化格式写入磁盘const MemoryItemSchema z.object({ category: z.enum([user, feedback, project, reference]), scope: z.enum([project, user]), key: z.string().describe(Short slug. Same key overwrites the previous fact.), fact: z.string().describe(The fact itself.), })下次会话启动时这些记忆被加载到系统提示词中让 Agent “记住”之前的上下文。主 Agent 本身没有写入记忆的工具——所有记忆写入都通过这个静默的后台提取器完成以避免模型在对话过程中分心去“管理自己的记忆”。多 Agent 协作Multi-Agent。 当任务足够复杂时单个 Agent 容易遇到瓶颈上下文被大量中间步骤占满模型同时追踪多个不同的关注点输出质量也会随之下降。Multi-Agent 的思路是把任务分解给多个专职 Agent——比如一个负责探索代码库、一个负责编码、一个负责审查。x-code-cli 内置了 4 种子 Agentexplore、general-purpose、plan、code-reviewer每个子 Agent 在独立的上下文中运行完成后只返回结论给主 Agent保持主对话的简洁。Multi-Agent 的挑战在于协调怎么合理分配任务、怎么传递上下文、怎么处理子 Agent 之间的冲突。这是目前行业还在积极探索的方向没有现成的标准答案。这一层的推荐材料 Andrew Ng《Agentic AI》覆盖四大 Agent 设计模式Reflection、Tool Use、Planning、Multi-Agent Collaboration免费B 站上有社区翻译的中文字幕版是目前最好的 Agent 入门课程。文档方面Anthropic 的《Building Effective Agents》是业界公认的 Agent 设计方法论经典文档同系列的《Writing Effective Tools for AI Agents》专门讲工具设计两篇都不长英文阅读没有障碍的话建议通读。第三层工程化能力有了前两层的知识做基础搭出一个能跑通基本流程的 Agent 原型不是问题。但要部署到线上跑真实的业务还有一系列的工程问题需要处理。上下文管理。 虽然现在模型的上下文窗口已经很大了200K 到 1M token但“窗口大”不等于“不用管”。更长的上下文意味着更高的 API 成本和更慢的响应速度而且模型对超长上下文中间部分的信息检索能力会下降即”Lost in the Middle”现象。举个具体的例子一个代码修改任务涉及读取多个文件、多次工具调用几轮对话下来上下文可能已经累积了数万 token。如果不做处理模型可能会”忘记”最初的需求描述或者重复执行已经完成的步骤。因此需要一套策略在对话过程中主动管理上下文的大小。x-code-cli 的做法是当上下文使用率超过阈值时保留最近的几轮消息不动把更早的消息交给 LLM 生成一份摘要替代async function compressMessages(messages, model) { const recent messages.slice(-KEEP_RECENT) // 保留最近几条 const old messages.slice(0, -KEEP_RECENT) const { text: summary } await generateText({ model, system: Summarize the conversation, preserving key decisions..., messages: old, }) return [{ role: user, content: [Summary]/n${summary} }, ...recent] }这是上下文管理最基本的策略。更精细的做法还包括prompt cache复用前缀降低重复输入成本、选择性加载只把与当前任务相关的文件内容放进上下文、分层知识库长期不变的知识放 system prompt短期上下文放消息历史。权限与安全。 Agent 和普通 LLM 对话有一个本质区别它能真正执行操作——shell 命令、文件读写、网络请求。这意味着模型一旦产生幻觉后果不再只是一段错误的回答。比如模型在清理项目时误判了目录范围直接执行了删除命令或者在调试配置时把生产环境的文件覆盖掉。在普通对话中产生幻觉最多让用户看到一段错误的文本但在 Agent 场景下一次幻觉就可能造成文件丢失或系统损坏。因此每个准备上线的 Agent 都需要一套权限机制来约束模型能做什么、不能做什么。x-code-cli 实现了三级权限模型默认模式下所有写操作需要用户确认信任模式可跳过确认计划模式Plan Mode下 Agent 只能读取和探索不能执行任何写操作。评测与可观测性。 评估 Agent 质量不能只依赖传统单元测试需要一套不同的方法——基于 LLM 的自动评分、A/B 对比、成功率统计、以及人工抽查。但光知道结果好不好还不够出了问题还需要能定位原因这就依赖可观测性。Agent 执行过程中的每一步——模型推理、工具调用、上下文变化——都需要被记录下来方便回溯排查。成本控制。 AI Agent 的运行成本直接和 API 调用次数、token 消耗挂钩。一个不做优化的 Agent跑一个复杂的任务可能消耗十几块甚至上百块。一个十人团队每天跑几十个任务一个月的 API 费用就可能得上万块。成本控制常见的优化策略包括选择合适的模型不是所有任务都需要最贵的模型、prompt cache 复用前缀、减少不必要的工具调用轮次、以及在合适的时机压缩上下文。这一层的推荐材料 工程化方面最好的学习方式是读成熟 Agent 产品的源码——看别人怎么做上下文压缩、怎么设计权限模型、怎么处理工具调用失败这比只看教程讲概念要有效得多。目前开源的 AI Agent CLI 项目不少比如 OpenAI 的 Codex CLI、社区驱动的 opencode 等都值得参考。我自己写的 x-code-cli 也是其中之一相比之下它的优势在于有一本配套的掘金小册《从零打造一个 AI Agent CLI》对上面提到的上下文管理、权限控制、循环检测、成本优化等工程问题都有专门的章节讲解每章先讲设计思路再给出代码实现适合想系统理解这些机制的读者。学习路线与实践AI 时代的学习方式变革在传统编程学习中最好的方式是找到一门经过验证的好课程一边学习理论一边做配套实验。Nand2Tetris、MIT 6.828、SICP——这些课程之所以被反复推荐就是因为它们在理论和实践之间达到了很好的平衡。到了 AI 时代学习方式本身也在发生变化。现在你完全可以和 AI 说“我想学习如何从零构建一个 AI Agent我的目标是做一个能帮我自动化日常开发任务的 CLI 工具我有 TypeScript 和 Node.js 基础”然后让 AI 为你规划一条学习路线同时生成配套的练习代码和实验。这种学习方式的个性化程度远超传统课程——AI 可以根据你的基础、目标和进度实时调整内容。不过要注意让 AI 定制学习路线本身也需要投入大量时间而且 AI 生成的代码和解释不一定正确你需要自己去验证每一步的输出这个验证成本不低。所以如果网上已经有经过验证的优质课程应该优先使用AI 定制学习更适合作为补充手段用来填补现有课程没有覆盖到的部分。推荐学习路径第一步跑通一个最小 Agent。 不要上来就装 LangChain。先用你熟悉的语言Python、TypeScript 都可以用最原始的方式调用 LLM API写一个 50 行以内的 while 循环——就是前面展示的 Agent Loop。让它能接收用户输入、调用一两个简单工具比如计算器、文件读取然后把结果返回。这一步的目的不是做出有用的东西而是让你搞清楚 Agent 每个环节是怎么工作的消息格式长什么样、工具怎么定义、循环怎么控制、什么时候循环该停止。想直接看代码的话可以参考我写的 hello-agent56 行 TypeScript一个 readFile 工具clone 下来就能跑。中文教程方面Datawhale《从零开始构建智能体》是国内开源社区出品的免费教程从最小 Agent 讲起兼顾理论与实战。第二步理解提示词工程。 跑通最小 Agent 之后开始系统学习 Prompt Engineering。重点不是记忆”100 个 Prompt 技巧”而是理解前面提示词工程小节提到的三件事system prompt 的写法、工具描述的措辞、以及 few-shot 示例的使用场景。第三步完善工具集。 在第一步的最小 Agent 基础上逐步增加工具文件读写、Shell 执行、代码搜索、网页抓取。每加一个工具观察模型的行为变化——什么时候用对了、什么时候用错了、为什么用错。多试几轮你就能搞清楚工具的 schema 和描述该怎么写才能让模型正确调用。第四步加入记忆与 RAG。 到这一步你的 Agent 已经能在单次对话中完成任务了但每次开新对话就什么都不记得了——上一轮对话里的某些约定、你的项目文档它都无法访问。解决这个问题需要两种机制配合。长期记忆负责保存对话中的关键信息把值得记住的事实存到本地文件下次启动时加载到 system prompt。RAG 负责接入外部文档把一组文档做分块和向量化后存入向量数据库提问时检索相关片段拼入 Prompt。前面记忆小节展示了 x-code-cli 的后台提取方案你可以参考那个思路来实现自己的筛选逻辑。做 RAG 需要理解向量嵌入Embedding和相似度搜索的基本概念其中分块粒度和检索质量之间的平衡是最需要反复调试的部分。第五步做一个完整的项目。 到这一步你应该能做出一个相对完整的 Agent 项目了。如果还没想好做什么可以试试看这几个方向的任务做一个 CLI Agent最纯粹的 Agent 形态不需要前端专注于 Agent 核心逻辑做一个 RAG 问答机器人把你的笔记、文档做成知识库做一个自动化工作流 Agent把日常重复性的开发任务交给 Agent。前面第三层推荐材料里提到了几个开源的 CLI Agent 项目到这一步可以选一个感兴趣的对照其源码来检验前四步积累的理解。结语这篇文章的核心观点是AI Agent 工程师不是一个需要从零学起的新职业而是现有开发经验加上一组特定知识的组合。需要学的概念不多难的是把概念变成能上线的工程实现。如果你还在犹豫要不要投入时间学 AI Agent 开发我的建议是先花一两个小时跑通一个最小 Agent——前面学习路径的第一步就够了。hello-agent 是为这个目的写的56 行代码clone 下来就能跑。跑通之后你会对 Agent 的运作方式有一个基本的认识接下来再决定要不要继续深入。AI Agent 工程还处于快速演进的阶段半年前的做法现在可能已经有了更好的替代方案。与其追求一次学完不如保持动手的节奏在实际项目中持续积累经验。这个领域变化快但核心原理——消息传递、工具调用、上下文管理——不会轻易过时。掌握这些基础在面对新的框架和模型能力时就不会无从下手。大模型的知识又多又杂到底怎么学做这行久了被问最多的问题就一个大模型的知识又多又杂我到底先学啥翻了一堆资料看啥都像重点结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍零基础、应届生、转行的都适用。跟着走至少方向不乱、不瞎忙学完拿得出手。第一阶段10天初阶应用这一阶段就一个目标把大模型真正玩明白不是只会聊天那种而是能调教它、能用代码把大模型和业务接起来。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用这阶段正式进实战目标很实在做出两个能拿出手的东西——一个私有知识库一个 agent 对话机器人。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…走完这 30 天Python 或 JavaScript 背景的基本能独立做一套 RAG 应用简历上也敢写大模型应用开发了。第三阶段约20天动手微调学到这你已经开始 “造” 模型了 —— 通过微调搞出垂直领域的专用小模型。为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料第四阶段20天商业闭环部署落地技术学完落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…想要入坑大模型的朋友给大家准备了一份2026 年最新 AI 大模型全套学习资料1、大模型系统化学习路线2、大模型学习视频教程3、大模型学习书籍电子文档4、AI大模型最新行业报告5、大模型项目实战配套源码6、2026大模型大厂面试真题7、为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。8、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。9、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料好了就写到这。路线是死的人是活的卡住了随时来问我。觉得有用就点个收藏别让它进收藏夹吃灰——动起来比啥都强。
