很多人对 Agent 的理解还停留在「会调工具的聊天机器人」：给个函数清单，让模型自己挑一个调用，跑通一次 demo 就算完。可一旦要上真实业务，问题立刻冒出来——多轮任务跑到一半状态丢了、工具报错后模型开始编结果、几个 Agent 协作时谁该说话说不清、评测时挑不出是提示词的问题还是流程设计的问题。这门课面向的正是这段从「能跑」到「能交付」的落差。

先确认自己缺的是哪一块

如果你已经能写提示词、调用过模型 API，但对下面几件事心里没底，那这门课的实战场景对得上：任务该怎么拆成可回滚的步骤；记忆和上下文该放在哪一层；工具调用失败、返回空结果、参数不合法时怎么让流程继续走而不是崩掉或胡说；多个角色分工时如何定义交接条件；上线前用什么方式判断改动是变好了还是变差了。

反过来，如果你还没写过一次完整的模型调用，或者对函数调用、结构化输出这些机制完全陌生，建议先把基础接口跑通再来，否则场景案例里大部分时间会花在补前置知识上，效率不高。

20+ 场景的价值在于「约束不一样」

场景数量本身不说明什么，关键在场景之间的差异。检索类任务考的是引用与出处是否可追溯；流程类任务考的是长链路中的状态保持和中断恢复；多智能体协作考的是角色边界与信息传递，而不是让几个模型互相客套；带工具的自动化任务考的是权限、幂等和失败重试。把这些放在一起做，你会被迫处理那些单点 demo 里被绕过去的问题，比如同一句话在不同阶段该被解读成指令还是数据，比如什么时候该让模型自己决策、什么时候该用代码把路径写死。

建议的练法是：每做完一个场景，先不看参考实现，自己回答三个问题——这个任务的最小状态是什么、哪一步最可能失败、失败后如何判断该重试还是该上报。答不上来就说明这个场景还没吃透，重做一遍比往后赶进度有用。

看完应能回答的问题

一个 Agent 的循环里，规划、执行、观察、终止分别由谁负责，终止条件写在哪里？
短期对话历史、长期记忆、外部知识库三者的边界在哪，什么内容不该塞进提示词？
工具返回异常时，是让模型自行改写参数重试，还是由外层代码拦截？判断依据是什么？
多智能体场景中，如何避免角色重复劳动和互相等待？
改动提示词或流程后，用什么指标判断效果变好，而不是只看几个样例的手感？
哪些环节可以用确定性代码替代模型决策，从而降低成本和不稳定性？

怎么用这份材料

不建议顺序刷完。先按自己项目里最接近的场景切入，把它完整跑通，再横向对比同类场景的实现差异，最后回头补架构和算法部分——那时你已经有具体问题，看概念会比空读有效得多。每个场景至少留一次「故意改坏」的练习：把工具超时、把返回结果置空、把输入改成边界值，看流程在哪里断。能定位断点，才算真的掌握了这个场景。

这门课不能替你决定业务里该不该用 Agent，但能让你在做决定之前，清楚代价落在哪几个环节。