一、起点

1. 已经接触过什么

日常会使用 Codex app，也接触 API、号池这类东西。

  • 我知道模型可以被接入使用；
  • 我知道 API 是真实工作流的一部分；
  • 我也已经在用 AI 参与一些实际任务，而不是只停留在看概念。

2. 真正缺什么

缺的不是“再多用几个工具”，而是下面这些更底层的理解：

  • 为什么 Agent 不是简单的“聊天 + 调 API”；
  • Tool Use / Function Calling 到底解决什么问题；
  • 上下文、记忆、规划、多步执行之间是什么关系；
  • 为什么一个看起来能跑的 Demo，离真实产品还差很远；
  • 延迟、稳定性、成本、失败兜底为什么会在招聘里被反复强调。

3. 不适合的学习方式

基于这个起点，不适合直接走两条路：

不适合路线一：上来就刷框架

比如一上来就学：

  • LangChain n- LangGraph
  • Coze
  • 各种 workflow builder

框架会让我“看起来做了很多”，但不代表我真正理解了底层机制。

不适合路线二：上来就做重项目

我当然可以立刻做项目，但如果理论没有补起来，项目大概率会变成：

  • 能跑
  • 但解释不清楚
  • 换一个场景就不会做
  • 面试时说不明白为什么这样设计

二、往 Agent / AI 工程师方向转

如果我的目标只是“把 AI 用顺一点”，那我可能只需要继续熟悉工具、优化提示词、积累一些 workflow 使用经验。

但我现在更偏向的是：

尽快往 Agent / AI 工程师方向转。

要开始补：

  • 技术原理
  • 系统意识
  • 能力分层
  • 工程语境里的抽象能力

换句话说，我不是想成为“会用 AI 的人”，而是想成为：

能理解 Agent 为什么这样工作，并逐步有能力把它做成产品的人。

三、为什么把学习重点放在理论上

1. 现在最需要的是概念地图

需要先把这些词真正分清：

  • LLM
  • Prompt
  • Context
  • Memory
  • Tool Use
  • Function Calling
  • Agent
  • Workflow
  • Planning
  • RAG
  • Multi-agent

2. 需要的是“工程语境中的理论”

不是去读纯学术课，也不是要从 Transformer 数学推导开始。

真正要补的是：

  • 这个概念在实际系统里解决什么问题；
  • 它和别的模块怎么连接；
  • 为什么招聘里会看重它；
  • 它的边界在哪里；
  • 它出问题时通常会表现成什么样。

理论优先，但每个理论都必须带着工程问题一起理解。

四、学习主线怎么排：先学什么，后学什么

第一阶段： Agent 的基础骨架

第一组：LLM 基础机制

要搞清楚：

  • 模型的输入输出到底是什么；
  • system / user / assistant 为什么这样分；
  • 上下文为什么会影响结果；
  • token、窗口长度、成本、延迟之间是什么关系；
  • 为什么模型并不真正“理解”，却仍然能完成很多任务。

第二组：Prompt / 上下文 / 输出约束

  • Prompt 到底在控制什么；
  • 为什么有时约束写了但模型不听；
  • 为什么多轮对话会越来越乱；
  • 如何让输出更稳定；
  • 什么时候应该让模型自由回答，什么时候应该强结构化。

第三组：Function Calling / Tool Use

  • 能不能调用工具；
  • 能不能基于工具结果继续执行；
  • 能不能把用户问题变成一串可执行动作。

第二阶段：理解 Agent 为什么能多步执行

1. 任务拆解

  • 一个复杂任务为什么要拆成多个步骤；
  • 拆得太粗和拆得太细分别会出什么问题；
  • 哪些步骤该交给模型，哪些步骤该交给规则或工具。

2. 工作流与规划

  • 什么叫 planning；
  • 什么只是顺序执行，什么才算真正的规划；
  • 一个 Agent 的“思考”本质上是不是状态流转。

3. 多步执行中的状态

  • 当前步骤是什么；
  • 上一步结果如何影响下一步；
  • 中间状态应该保存什么；
  • 失败时怎么继续而不是从零重来。

第三阶段：再补更热、更容易被误学的词

1. RAG

我现在工作里其实还没有明显的知识库 / 检索增强场景，所以 RAG 不是第一优先级。

但它是招聘里的高频加分项，所以后面必须补。

只是顺序上要放在 Agent 核心机制之后。

2. LangChain / LangGraph

我现在看到这些词很多次，但我不准备把它们当成起点。

原因很简单：

  • 先学框架，容易学成“会拼积木”；
  • 后面一旦脱离框架，就不知道系统为什么这样跑。

所以我对它们的定位是：

等底层结构稍微稳了之后，再把它们当作加速器。

五、学习任务应该怎么拆

1. 主任务：理论理解

这是每天都要推进的主线。

  • LLM 输出为什么会漂？
  • 上下文到底怎么影响模型？
  • Function Calling 和普通对话的本质区别是什么？
  • Agent 为什么不是“多问模型几次”那么简单？
  • 为什么真实产品里稳定性和成本会压过 Demo 效果？

2. 副任务：最小验证

  • 用最小脚本观察不同 Prompt 对结构化输出的影响；
  • 看一次 function calling 的完整请求与返回；
  • 把一个任务手工拆成多步，再和 Agent 框架的方式对照；
  • 观察一次多轮上下文过长导致回答变差的现象。

六、进度规划：按 6 周推进

第 1 周

目标

先把高频词的关系理顺。

重点任务

  • LLM 是什么，不是什么；
  • Prompt / Context / Token / Window 的关系；
  • Function Calling / Tool Use 的区别与联系；
  • Agent、Workflow、Planning 的关系；
  • RAG、Memory、Multi-agent 各自放在哪个层级。

本周产出

  • 一份自己的术语关系图；
  • 每个核心概念写出一句“工程语境下的定义”；
  • 明确哪些词是现在优先学，哪些词先压后。

第 2 周： LLM 调用与上下文机制

目标

把“我会接 API”升级成“我知道它为什么这么工作”。

重点任务

  • 理解消息结构；
  • 理解 system prompt 的作用边界；
  • 理解上下文污染与上下文裁剪；
  • 理解结构化输出为什么容易出问题。

本周产出

  • 一份“LLM 调用最常见问题清单”；
  • 几个最小实验记录；
  • 一篇自己的总结：为什么调用模型不等于理解模型。

第 3 周：集中补 Function Calling / Tool Use

目标

能说清楚为什么重要。

重点任务

  • 什么情况下模型应该调用工具；
  • 为什么函数参数要结构化；
  • 工具返回结果如何回流给模型；
  • 工具失败时为什么会让 Agent 整体变脆。

本周产出

  • 一份 Tool Use 流程图；
  • 一份 Function Calling 的关键问题笔记；
  • 最小脚本实验：一次完整调用链路。

第 4 周： Agent 工作流与多步执行

目标

“一个 Agent 为什么能持续工作”。

重点任务

  • 任务拆解
  • 步骤状态
  • 中间结果保存
  • 停止条件
  • 错误恢复

本周产出

  • 一张多步执行流程图；
  • 一篇笔记：Agent 和普通对话系统的差别；
  • 一个最小工作流原型或伪代码设计。

第 5 周：系统设计视角

目标

让自己开始从“功能”转到“系统”。

重点任务

  • 延迟为什么重要；
  • 成本为什么会影响方案设计；
  • 为什么要做失败兜底；
  • 为什么可控性比 Demo 效果更重要；
  • “能力 ≠ 体验”在产品里意味着什么。

本周产出

  • 一篇“如果我要做一个可上线 Agent，我最怕什么”总结；
  • 一份系统风险清单。

第 6 周：进入 RAG / 框架

目标

这时才开始碰那些高频热词。

重点任务

  • RAG 解决什么问题；
  • LangChain / LangGraph 在系统里解决什么问题；
  • 为什么它们是加速器，而不是理解起点。

本周产出

  • 一份“我现在适合学哪些框架、不适合学哪些”的判断；
  • 一份下一阶段的实践计划草案。

七、每天 2~4 小时，怎么安排更现实

模式 A：2 小时版本

  • 1 小时：理论阅读 / 概念整理
  • 30 分钟：笔记归纳
  • 30 分钟：最小验证 / 回顾

模式 B：4 小时版本

  • 1.5 小时：理论主任务
  • 1 小时：对照示例 / 官方文档 / 关键资料
  • 1 小时：最小实验或结构图整理
  • 30 分钟：写结论与问题清单

每天最低要求

即使很忙，我也希望自己做到：

  • 至少推进一个概念；
  • 至少写下一条清晰结论；
  • 不让学习只停在“今天看了很多”。

八、什么算我真的在进步

对我来说，进步不应该用“今天看了几个教程”来算。

我更应该用下面这些标准判断：

1. 我能不能解释清楚

比如：

  • 什么是 Function Calling；
  • 为什么 Agent 需要状态；
  • 为什么 RAG 不是万能增强；
  • 为什么多 Agent 不是越早学越好。

2. 我能不能区分边界

比如：

  • 哪些是模型问题；
  • 哪些是系统问题；
  • 哪些是产品问题；
  • 哪些是工程实现问题。

3. 我能不能把一个词放回系统位置里

这才是最重要的。

如果我看到一个词，不再只是“我见过”，而是知道：

  • 它解决什么问题；
  • 它和什么配合；
  • 它什么时候该用；
  • 它为什么会失败；

那我才算真正开始往 Agent / AI 工程师方向走了。

九、我暂时不做什么

为了保证路线不跑偏，我也要明确写下来：

暂时不优先做的事

  • 不把 LangChain 当起点；
  • 不一上来沉迷 multi-agent；
  • 不为了“看起来厉害”去堆概念；
  • 不把做项目当成掩盖理解不足的手段；
  • 不因为焦虑而同时开 10 条学习线。

暂时不追求的结果

  • 不是马上做出最炫的 Demo；
  • 不是一下子补齐所有工程能力；
  • 不是一周变成岗位匹配度很高的人。

我现在更务实的目标是：

先把理论骨架搭起来，再让后面的每一步都踩在结构上。

十、小结

先从“会用 AI 工具的人”，变成“理解 Agent 系统是怎么工作的那种人”，再继续向 Agent / AI 工程师靠近。

  • 一套稳定的概念骨架；
  • 一条不被热词带跑的学习顺序；
  • 一种能持续积累的节奏感；
  • 一种从使用者走向工程视角的转变。