这门课的名字里有「大模型」，也有「Agent」，但真正决定它对你有没有用的，不是这两个热词，而是你手上正在做或准备做的东西，卡在哪一层。有人卡在调用 API 之后不知道怎么让模型稳定输出结构化结果，有人卡在单轮对话能跑、多步任务一上就散架，也有人只是想把 RAG 之外的工具调用、记忆、规划这几块补上。下面按能力缺口说，不按章节顺序说。

先确认你缺的是哪一块

如果模型输出的 JSON 时不时多一句解释、少一个字段，你缺的是约束与校验层面的东西——结构化输出、函数调用协议、失败重试，而不是「提示词技巧」。这门课在这部分会落到具体接口形态和解析逻辑上，属于看完能立刻改自己代码的那类内容。

如果你的 Agent 在单步任务上表现正常，一旦需要连续调用多个工具、根据中间结果调整下一步就乱，那你缺的是控制流：谁来决定下一步、状态存在哪、循环什么时候终止、出错怎么回退。这是 Agent 与「套壳聊天」的分界线，也是这门课区别于纯大模型原理课的地方。

如果你压根还没跑通过一次完整的工具调用，那先别急着看架构图，把一次最小可用的调用链路走通更重要。

Agent 部分该怎么看

Agent 架构最容易讲成概念图：感知、规划、记忆、执行，四个框一画，看着都懂，动手全废。看这部分时建议带着三个问题：

规划是模型一次性给出，还是边执行边修正？两种做法的失败模式完全不同。
记忆存什么、存多久、怎么检索？全量塞进上下文和做摘要压缩，成本和效果差很多。
工具调用的边界在哪？哪些判断交给模型，哪些必须用代码写死？

能回答这三个问题，说明你不是在背架构名词，而是在做工程决策。

案例部分不要只看结论

案例驱动的好处是省去你自己搭场景的时间，坏处是容易变成「照着跑一遍，跑通了就过」。建议在每个案例里停一下：如果换一个工具、换一种输入格式、把步数上限调低，会发生什么？这类改动最能暴露你对状态流转的理解是不是真的到位。案例的价值不在结果，在于它替你预设了一组约束，让你被迫处理真实工程里那些不体面的边界情况。

大模型原理要看到什么程度

不需要推导注意力公式，但有几件事值得弄清楚：上下文长度为什么直接影响 Agent 的可行步数；temperature 之类的采样参数在需要确定性输出时该怎么设；为什么同样的提示词换个模型就失效。这些不是理论兴趣，是调参和排错时的直接依据。原理讲得浅不是问题，讲得浅还用不上才是问题。

学完之后你应该能回答

给定一个任务，你能判断它该用单次调用、固定流程，还是需要 Agent 自主决策吗？
模型输出不合规时，你的兜底是在提示词层、解析层还是重试层？
你的 Agent 跑偏时，你能定位到是规划错、记忆污染，还是工具返回被误读吗？
这套东西的 token 成本和延迟，你心里有量级吗？

这四个问题答不上来，说明还停在「跑通 demo」的阶段；答得上来，这门课对你就是查漏，不是入门。缺什么补什么，别假装什么都会。