课程开篇就直接点破了这轮 AI 浪潮里一个很多人没绕过来的弯我们这些做应用、做产品的人跟大模型打交道的方式跟学术界研究大模型的方式完全是两码事。CS329Z 这门课取名 “LLMs for Builders”态度已经摆得很明确了——它不教你怎么训练一个模型也不推公式推导它教的是怎么把 LLM 当成一个趁手的、有脾气的、偶尔会犯糊涂的“新同事”来协作。第二讲全程在讲一件事怎么用好模型而不是怎么造好模型。我把这一讲的要点、踩过的坑、还有课后自己补的功课整理成这份笔记希望能帮你少走点弯路。1. 这堂课到底在讲什么面向构建者的大模型使用哲学先说一个很多人刚接触这课时会产生的困惑CS329Z 跟市面上那些讲 LLM 的课到底有什么不一样大部分公开课的重心放在模型本身——注意力机制怎么算、训练流程怎么设计、参数怎么调。这些内容对做研究的人很有用但作为一个要落地智能体的开发者坦白说这些知识跟你的日常工作是脱节的。你调 Prompt 的时候不需要知道 Flash Attention 的底层实现你设计 Agent 工作流的时候也不需要去推导 RLHF 的损失函数。你真正需要的是另一套知识模型的能力边界在哪里、怎么把任务切成模型擅长的小块、怎么让模型的输出稳定可靠、怎么在模型犯错的时候兜住底。CS329Z 的定位恰好就在这个位置。它对标的是吴恩达那类“LLM 工程最佳实践”课程但比那更成体系也更贴近当前智能体开发的前沿状态。第二讲作为整门课的地基把“作为构建者你应该怎么理解和使用 LLM”这件事讲透了。我个人看完这一讲的最大感受是它把“Prompt 工程师”这个词从一个玄学变成了工程学。课程里反复强调一个观点——模型不是一个参数化的知识库而是一个概率性的推理引擎。你要做的不是“问它问题”而是“给它搭一个能稳定发挥的工作环境”。这个视角的转换是后续所有智能体开发技巧的出发点。1.1 GPT 类模型日用指南从“问问题”到“下指令”这一讲前半部分花了不少篇幅讲 GPT 类模型也就是我们常说的 decoder-only 架构模型的正确打开方式。它的核心论点其实可以用一句话概括模型对你的意图一无所知它只知道怎么续写最合理的下文。这个特性决定了你必须用一种特定的方式跟它沟通。课程里提到了几个很关键的使用原则结合我的实际经验展开说第一上下文比模型参数更重要。很多人都没意识到你每一次调用模型实际上是在给它设置一个“工作状态”。同样的模型权重你给它的上下文不同它的表现可以判若两人。一个空上下文直接问“给我写一个 Python 函数”跟你在上下文里详细描述了函数用途、输入输出格式、边界条件之后再说“请实现”模型的输出质量完全不在一个量级。后者甚至不需要你多用多少 token但输出的可用性会翻倍。第二模型是在做“续写”不是在做“检索”。你问它“什么是 NaN”它不是在记忆库里找到一个标准定义念给你听它是在计算所有可能的续写中最可能被你接受的那一个。所以当你问一个问题时模型的回答其实是在猜测“一个问了这个问题的人最想看到什么样的答案”。这就解释了为什么同样一个问题你加上“我是一个深度学习初学者”和“我是一个有十年经验的算法工程师”得到的答案会完全不同——因为模型对“续写目标”的判断变了。第三指令要像给实习生派活不能像跟朋友聊天。课程里用了一组对比实验来说明这一点直接要求“总结这段文本”和结构化要求“你是文本分析助手请提取这段文本中的三个核心论点每个论点用不超过 20 个字概括并附上原文中的依据句”后者的输出质量高得多。不是因为模型“听懂了”更复杂的指令而是因为你的指令给它的续写圈定了一个更窄、更清晰的分布空间。1.2 从“需要什么”倒推“该怎么做”构建者的逆向思维这堂课给我印象最深的是它提出了一套倒推式的思考框架。普通用户使用 LLM 是正向思维我有一个问题 → 我把问题发给模型 → 模型给我答案。而构建者的思维是逆向的我的应用需要什么样的输出格式、结构、稳定性要求为了得到这种输出我需要给模型提供什么上下文、示例、约束条件如果模型做不到问题出在哪一环是理解了但表达不行还是信息不足还是任务的认知负荷太高这套框架在智能体开发中尤其适用。你设计一个 Agent 的工作流时每个环节的输入输出都是确定的用户 query 进来经过意图识别转成结构化参数调用工具拿到结果组织成回答。这里面的每一步其实都是“给模型设定一个特定的续写目标”然后通过 Prompt、示例、格式约束等手段把模型的行为扭到你要的轨道上。第二讲把“作为构建者你应该怎么理解和使用 LLM”这件事讲透了。它把 Prompt 从一个玄学变成了工程学模型不是一个参数化的知识库而是一个概率性的推理引擎。你要做的不是“问它问题”而是“给它搭一个能稳定发挥的工作环境”。这个视角的转换是后续所有智能体开发技巧的出发点。2. 提示工程的核心要素不只是“说清楚话”很多人对 Prompt Engineering 有个误解觉得它就是一门“把话说明白”的手艺。这话对了一半。说话清楚当然重要但工程意义上的 Prompt 设计讲究的是一套有章法可循的组件化结构。CS329Z 第二讲把 Prompt 拆解成几个核心要素这一套拆法比我见过的大多数博客文章都要系统。我结合自己的使用经验逐个展开讲。2.1 系统提示词、工具调用与上下文窗口的管理先说说系统提示词System Prompt。很多人以为系统提示词只是给模型“设定一个人设”其实它的核心作用是在模型的续写空间中注入恒定约束。模型在每条消息生成时都会把整段对话作为上下文来预测下一个 token。系统提示词是这段上下文中永远摆在最前面的部分它对模型行为的影响是全局性的、持续性的。这就意味着你的系统提示词里应该放三类东西第一类是角色的边界。不光是“你是一个客服助手”这种简单人设更重要的是“你能做什么、不能做什么”。比如“你是智能客服 Agent只能回答关于产品使用的问题涉及售后退换货请引导用户联系人工客服”。这种边界设定不是为了让模型“入戏”而是为了把它的续写分布朝着“合规范围”内挤压。第二类是工作流程的固定步骤。如果你的 Agent 在收到用户消息后必须先做意图识别、再抽取参数、然后决定是否调用工具这个过程应该写进系统提示词。模型天然是按顺序续写的你把这个流程摆在它面前它就会顺着这个流程往下走。第三类是输出的通用规范。包括语言风格、字数限制、禁忌词表等。这些约束对模型续写的引导作用比你想象的要强得多。工具调用Function Calling / Tool Use本质上也是 Prompt 工程的一部分。你把工具的描述、参数结构、调用规则作为上下文的一部分提供给模型模型的任务就变成了根据用户输入决定是否调用某个工具、传入什么参数。这个机制之所以重要是因为它把模型从“只能输出文本”变成了“可以操纵外部系统”。上下文窗口管理则是另一个容易被忽略的工程点。模型对上下文的利用不是一视同仁的——距离当前位置越近的内容对当前生成的影响越大这个效应在长对话中尤其明显。课程里给出的实操建议是把最重要的约束放在系统提示词里永远在最前把最新的对话放在最末尾中间的历史消息如果太长要么截断、要么摘要、要么向量化检索后按需注入。原生支持超长上下文的模型也不能完全免除这个问题——能力不是线性的超长上下文中模型仍然会弱化对早期内容的记忆。2.2 few-shot 与思维链给模型的“拐杖”与“脚手架”Few-shot少样本示例和 Chain-of-Thought思维链是 Prompt 工程里两个最常用也最容易被误用的工具。先聊 few-shot。它的本质不是给模型提供“知识”而是给模型提供“格式锚点”。模型本身可能已经知道怎么回答这个问题但它不确定你要什么格式的回答。你给了三五个示例其实是在告诉它我要的输出长这样结构如此细节密度如此。所以 few-shot 的选例策略很有讲究——示例的首要标准不是“内容正确”而是“格式典型且边界清晰”你要故意选一些覆盖不同输入情况的样例让模型能从中归纳出“什么输入对应什么输出”的映射规律。思维链则是另一套机制。它利用的是模型的一个特性逐步推理能够显著降低单步推理的错误率。你不让模型直接输出答案而是要求它先输出推理过程再给出结论。这听上去像是在“鼓励模型思考”实际上是在把一个高难度的单步预测拆分成多个低难度的连续预测。每一步的预测难度降低了总体的成功率反而会上升。但思维链有个工程上必须注意的点推理过程要短、要结构化。课程里推荐的模板是“Let‘s think step by step but keep it concise”我在实践中进一步总结为给思维链限定步骤数例如“先判断用户意图再提取关键参数最后决定是否调用工具”每一步只做一件事。不然模型很容易在一个开放式思维链里越绕越远输出大量无关内容既浪费 token 又拖慢响应时间。在实际工程中思维链做得短这件事比做得长更重要。2.3 编写高质量 Prompt 的实操套路模板化、版本化、可测试Prompt 的工程化不能停留在“写一段好文本”的层面你还需要一套管理机制。我自己在项目里的做法是首先Prompt 必须模板化。把固定不变的约束、规则和动态插入的内容用户 query、检索结果、工具输出分开。不要用手工拼接的方式去组装 Prompt最好能落成代码里的渲染模板。这样你更新 Prompt 规则时只需要改模板而不需要动业务代码任何一次修改都可以放进 git 里做版本管理。其次Prompt 必须版本化。大模型应用的迭代核心就是 Prompt 的迭代。你改了一个措辞用户看到的行为就会变。如果不对 Prompt 做版本管理出了问题都不知道是代码改坏了还是 Prompt 改坏了。至少要用 git 管理模板文件、用环境变量或配置中心切换不同环境的 Prompt 版本有条件的话学一下 Prompt 评测的思维把不同版本的 Prompt 挂在一批固定用例上跑一遍对比输出质量和格式符合率再决定是否上线。最后Prompt 必须可测试。这里的“测试”不是指用肉眼看看输出对不对而是建立一套自动化校验输出是否符合 JSON 格式关键字段是否齐全调用工具的参数是否合法这些校验逻辑虽然挂在模型输出之后但设计的时候要倒推到 Prompt 里——如果模型经常输出不合规你要去改 Prompt 的约束而不是一味地在代码里写好几种兼容逻辑去“接住”它的一堆烂摊子。我在真实项目里实测把 Prompt 模板化 版本化 自动化测试这套组合做起来之后模型的输出质量在两周内就能看到系统性提升。3. 从 Prompt 到上下文工程RAG、记忆与外部知识这堂课讲到这里其实已经把所有“把话说明白”的技巧讲完了。但光有这些还不够——因为你的智能体在真实场景里要面对的问题是动态的、未知的知识不可能全部装进模型权重里更不可能全部塞进 Prompt 里。第二讲的进阶部分是“上下文工程”。这名字起得比“Prompt 工程”更准确——因为我们做的事情本质上是决定“哪些信息出现在模型面前”。3.1 上下文工程的价值所在让模型按需获取知识模型经过预训练之后它的“知识”就被冻结在权重里了。但你的业务知识是活的实时变化的新品信息、库存状态、用户订单记录、系统日志……这些都发生在模型训练完成之后。你不可能为了每一条业务数据去微调一次模型所以必须找到一种方法让模型在推理时能按需获取外部知识。这就是 RAG检索增强生成做的事情。它的核心逻辑非常朴素用户提问 → 从外部知识库检索相关内容 → 把检索结果作为上下文的一部分提供给模型 → 模型基于“上下文 自身推理能力”生成回答。注意这个流程中模型扮演的角色——它仍然是一个“续写机器”但它现在不是基于自己脑子里那些可能过时的参数来续写而是基于你提供的最新知识来续写。RAG 的本质不是增强模型的“记忆”而是增强模型在生成时能看到的“视野”。第二讲里有一个比喻我印象很深模型的知识是“长期记忆”上下文是“工作记忆”RAG 就是把你需要的档案从资料室调到桌面上来。这个比喻虽然简单但非常准确地揭示了三者的分工关系。3.2 检索效果的关键环节切块、向量化与排序算法做 RAG 的人都知道检索效果的好坏很多时候不取决于模型而取决于你的索引质量。课程里没有展开讲太多检索细节但给出了一个重要的原则检索是 RAG 的上限生成只是把检索结果用起来。这些原则落到实操层面就变成了几个具体的决策点第一个是切块策略。你把知识文档切成多长的片段来做索引切得太短每个片段的信息不完整切得太长向量检索的精确度下降而且容易把不相关的噪声带进上下文。我的经验是切块长度没有放之四海皆准的标准它依赖于你的文档类型和用户提问粒度。产品说明书按章节切FAQ 按条目切技术文档按小节切。一个比较通用的起手式是 300-500 字一块带 50-100 字的重叠然后再根据实际的检索命中效果去调。第二个是向量化模型的选择。这里有一个常见的认知误区embedding 模型不是越强越好而是越匹配越好。你的检索需求其实只是“找出语义相近的文本片段”而不同场景下“语义相近”的定义不一样。问“怎么退货”和“退款流程是什么”在电商客服场景里应该被算作同一个问题但在法律咨询场景里可能根本不是一个概念。所以如果你的预算允许最好在自己的业务数据上微调或至少评测几个不同的 embedding 模型而不是想当然地选一个“大家都说好”的。第三个是重排。纯向量检索的结果在粗糙的语义匹配上是够用的但如果你对检索精度要求高需要在召回之后加一层重排Rerank。简单的做法是用一个交叉编码器模型对召回的 top-k 条结果逐一打分再按新的分数排序。这层操作的计算成本比向量检索高但能显著提升“最终进入上下文的内容质量”。3.3 长对话下的记忆管理缓存、摘要与分层存储上下文工程的另一个重要战场是多轮对话记忆。你的智能体跟用户聊了二十轮不可能每一轮的内容都喂给模型——不仅 token 费用扛不住模型的注意力也会被稀释。我在实际项目里总结出一套分层记忆方案在这里一并分享短期记忆保持最近 2-3 轮对话的原文直接放在上下文里。这些信息是最相关的不需要额外处理。中期记忆更早的对话内容太大不能全量保留。一个有效的做法是“边聊边摘要”——每轮对话结束后让模型用一两句话概括本轮的核心信息然后只保留这些摘要。这个方案我在智能客服项目里实测过效果很好模型对“用户之前提到过某某需求”的记忆准确率能保持在九成以上。长期记忆用户的长期偏好、历史订单、跨会话信息这些不能依赖摘要因为摘要只覆盖当次会话需要存到数据库里在合适的时候检索出来作为上下文注入。这套分层方案的成本可控、可扩展性也好而且每一层都可以单独调优。课程里虽然没有整套说出来但它的思路——在不同环节控制“哪些信息进入上下文”——就是这套方案的骨架。4. 推理时扩展、结构化输出与智能体能力边界CS329Z 讲到这里开始触及这一讲最有分量的内容如何让模型在推理时“想得更久一点”、输出“更规整一点”以及这些手段如何构成智能体的核心能力。4.1 扩展思维链让模型“想得更久”的收益与代价前面聊过思维链但那是“指令级的引导”。第二讲更进一步讲的是“推理时扩展”——不改变模型权重而是在生成时给模型更多机会去推理。核心做法有几种。最简单的是多次采样后自洽性投票同一个问题让模型用不同的温度参数采样多次比如 5 次然后把多次结果做一个投票或加权选最一致的答案。这能在不改变任何模型参数的情况下提升准确率原理也很朴素——随机错误是分散的正确答案是收敛的。更进阶的是显式的多步推理循环让模型“先写出已知条件→再列出可能的解题方向→选择一个方向→执行步骤→回头检查”。这本质上就是把人的解题流程复制给模型。课程里提到这类方法在数学、逻辑任务上的收益非常显著。但“推理时扩展”是有代价的——第一个代价是延迟模型要想得更久你的用户就要等更久第二个代价是成本更多的输出 token 更多的钱。所以在智能体的工程实践中我们不能在所有请求上都加扩展推理而是要识别哪些任务真的需要“深思熟虑”哪些任务是反射性的、直接回答即可。一个简单的分流规则是需要调用工具、需要多步逻辑的任务开启扩展思维链知识问答、闲聊寒暄直接快速回答。这个“分流”的思路其实也是智能体设计中最重要的判断力之一——不是所有请求都值得花大代价去仔细推理知道何时该快、何时该慢是做工程的成熟表现。4.2 结构化输出的工程方案从 JSON 模式到函数调用智能体跟用户最直观的差别是什么是它会“做事”而做事的第一步是把自然语言翻译成结构化指令。你的 Agent 要调用天气 API就得先把“北京明天会下雨吗”翻译成{city: 北京, date: 明天}。这一整套翻译过程就是结构化输出要解决的问题。实现结构化输出的方案按推荐顺序排列首选方案是模型原生的函数调用Function Calling能力。新一代模型在被微调时就已经被训练成当上下文表明“该调用工具”时输出一个结构化的工具调用 JSON。你只需要在请求里声明可用的工具列表名字、参数 schema、描述模型自己会判断要不要调用以及传入什么参数。这个方案最稳、最省事。次选方案是输出约束 校验重试。如果你的模型不支持原生函数调用可以要求模型以 JSON 格式输出同时在代码里做严格的格式校验和重试。这里有个实操经验要在 Prompt 里给出“目标 JSON 的完整 schema 示例和字段含义说明”并且明确告诉它“只输出 JSON不要输出任何解释文字”。模型输出后程序侧做好防御性解析失败就让它重来重试两三次基本都能得到合规结果。通用兜底方案是语法约束解码。一些推理框架支持在解码阶段按语法约束进行受限生成从根上保证输出一定是合法 JSON 或满足某种格式。这个方案的缺点是它对底层框架有要求灵活性不够高一般用于对结构要求极端严苛的场景。我个人建议始终把函数调用作为首选只有在模型不支持时再退回到输出约束 校验这一档。4.3 Agent 的构建模式从单轮调用到 ReAct 循环第二讲的最后一部分把目光拉高从“怎么让模型输出更好”转向“怎么让模型组成的智能体能完成一个完整任务”。这里课程抛出了一个构建 Agent 的基础模式也是当前智能体开发被讨论得最多的框架——ReAct。ReAct 的核心可以用一个词概括环。一次推理不够那就“推理→行动→观察→再推理”直到任务完成。Agent 首先根据用户请求和当前情景进行推理决定下一步行动然后调用工具、执行行动接着观察工具返回的结果把新的信息纳入推理然后继续循环直到得出最终答案或确认任务无法完成。这套模式看起来简单但工程落地的细节非常多。最关键的三个点一是循环的终止条件。如果 Agent 没有一个明确的“我该停了”的判断机制它会在工具调用和推理之间无限循环。工程上必须在每一轮之后做一个终止判断任务目标是否已达成如果达成进入总结输出阶段如果未达成但步数已超上限比如 5 步强制终止并输出中间结果或转人工。二是工具的抽象与描述。模型只能通过你的工具描述来理解“这个工具能做什么、什么时候用”。所以工具描述必须写清楚功能边界、输入参数含义、典型使用场景。我在项目里吃过亏当时是工具描述里没写清“该工具只接受标准格式的日期参数”导致模型连续几次把错误格式的日期传给工具。后来我认真重写了工具描述把这些约束全部写进去误调用率直接降了一半。三是可观测性。Agent 的思维链和行动链是黑盒一旦出错很难排查。工程上要做日志记录——每轮的推理内容、调用的工具、传入的参数、返回的结果全部落日志。我做智能体项目时几乎每一次线上故障排查都依赖这些日志它比任何测试都真实。5. 构建可靠 AI 系统的工程实践容错与评估听完了第二讲的前半程你可能已经摩拳擦掌准备搭自己的 Agent 了。但作为在智能体开发一线摸爬滚打过的人我必须提醒你模型能力决定的是你的系统的上限工程能力决定的是你的系统的下限。一个模型再强如果你的系统在它出错时直接崩溃或给出一个完全离谱的答案用户不会觉得“模型好厉害”只会觉得“这个产品不行”。课程里在这一部分讲的可靠性工程在我看来是这堂课最值钱的内容之一。5.1 可靠的智能体 工程兜底 自主容错智能体跟传统软件的本质区别是传统软件的输入输出是可枚举的你可以用穷举法保证正确性但智能体的输入是自然语言输出是生成式的你永远无法穷举它的错误模式。所以“可靠性”不是指望模型永不犯错而是在模型犯错时系统能不能兜得住。这就引出了容错设计的核心思路我把它总结成三层防线第一层输入侧拦截。在请求进入模型之前做规则性的预处理。敏感词过滤、超长输入截断、非法格式拒绝、明显不在业务范围内的 query 直接给兜底回复——这些不需要大模型几行规则就能完成但能挡掉大量低质量请求。第二层输出侧校验。模型输出的东西在返回给用户之前必须经过一道“质检”格式是否合规关键字段是否存在内容是否包含敏感信息是否在业务允许的范围内校验不通过就触发自动重试或降级逻辑。第三层行为侧约束。对于需要调用外部工具的 Agent必须给它的工具调用加白名单、加参数合法性校验、加调用频率限制。模型如果试图调用不在白名单内的工具直接拒绝并提示“我没有这个能力”。这个动作在传统软件工程里叫权限校验但在智能体系统里它就是“自主容错”的基石——系统不允许模型做超出授权范围的事。5.2 LLM 系统的评测方法建立评估集、指标与回归机制评测这件事是很多人做 LLM 应用时最容易忽略的一环。原因很能理解功能都还没调通谁有空写评测但你可能低估了它的价值——没有评测你的系统就永远只能停留在“感觉还行”的状态无法迭代。课程里给出了 LLM 系统评测的最小可行方案我觉得非常接地气第一步建立评估集。哪怕先搞 30-50 条从真实的用户日志里挑典型问题覆盖主流程、边界情况超长输入、语义不明的请求、包含歧义的 query和已知失败案例。每条用例要有标准答案或评分标准。第二步拆指标。两个最核心的指标格式合规率输出是否符合结构要求和执行成功率Agent 是否在有限的步数内完成目标。这两个都是可自动化计算的硬指标。在此基础上如果要评测回答内容本身的质量可以用“LLM as Judge”——让一个强模型给输出打分。第三步回归机制。每次改动Prompt 调整、工具更新、模型版本切换之后都要把评估集完整跑一遍对比新旧版本的分差。我的经验是删除一个在旧版上表现异常优异的评估用例要谨慎很多时候它压着的恰恰是一个你没注意到的回归风险。有了这套评测机制你的智能体迭代就从一个“拍脑袋的过程”变成了一个“有数可看的过程”。5.3 平台搭建与代码搭建的本质差异选择你的战场最近这个行业里有个非常热门的话题用平台Coze、Dify 这类搭智能体和用代码Python LangChain / LlamaIndex 这类搭智能体到底怎么选这堂课的内容恰好是回答这个问题的最佳参照。用平台搭和用代码搭表面上看只是工具不同本质上是你选择把哪部分工程能力交给谁。平台方案的核心优势是快。内置了 Prompt 管理、知识库、工具编排、可视化调试界面拖拖拽拽就能出一个原型。但它的代价是自由度低——平台的编排粒度、上下文管理细节、定制化校验逻辑都受制于平台提供的抽象层级。你可能想写一条平台不支持的校验规则或者想调一个平台不暴露的参数这时候就撞墙了。代码方案的核心优势是可控。你能完全掌控 Prompt 的组装逻辑、上下文的管理策略、工具调用的边界、容错的每一个细节。但代价是慢——你需要自己搭一套除了业务逻辑之外的基础设施记忆管理、日志系统、评测框架、模型切换逻辑等等。我自己的建议是看你的目标做验证、做原型、做简单内部工具直接用平台把时间花在业务逻辑上做面向真实用户的多轮对话系统、做复杂工具链的 Agent、做需要深度定制可靠性逻辑的系统毫不犹豫选择代码方案。第二讲里那些上下文工程、容错机制、评测方案在代码方案里你能一条一条落地在平台方案里大概率只能用到一半甚至更少。6. 实操心得与工具选型建议这一讲的内容信息量很大最后这部分我想结合自己的开发经验把一些课程里点到为止的细节展开聊一下同时分享一套我在智能体项目里验证过的基础工具栈选型供你参考。6.1 模型选型从 Claude 到国产模型的分层策略模型选型一直是智能体项目的热门问题。这两年各家模型的能力不断拉近但各自的脾性、速度、成本、合规条件还是有明显差异选型不能只看“最强”要看“匹配”。我当前的通用思路是分层使用复杂推理和关键工具调用使用 Claude 系列尤其是思维链和 Agent 场景虽然贵但正确率高值得在关键路径上花这个钱。日常对话和知识问答使用 GPT-4o 系列或国产头部模型资深的几款在中文场景下表现已经不输闭源成本可控速度也快。摘要、信息抽取、打标签使用小参数模型或降配方案量大但任务简单跑得快、成本几乎可以忽略。这里有一个需要特别强调的经验不要被“最强模型”绑架。很多团队一上来就全链路用一个最强最贵的模型结果成本翻了数倍用户体验却没有显著提升。正确做法是为不同的任务选择不同档位的模型配合路由策略自动分流。6.2 工程栈推荐与落地顺序建议如果你准备从零开始搭一个智能体系统下面是我验证过的推荐技术栈基本覆盖了这一讲里提到的所有工程点模型接入与路由OpenAI SDK / Anthropic SDK配合自研路由层Agent 框架LangChain / LiteLLM更轻量后续可逐步替换为自研编排框架向量库Milvus数据量大有高可用需求/ Chroma轻量起步记忆层Redis短期会话缓存 PostgreSQL长期用户画像可观测性LangSmith 或自研日志中间件关键指标落表评测框架自建评估集 LLM as Judge 脚本部署与上线FastAPI Docker 云函数网关层做限流关于落地顺序强烈建议按这条链路推进先做端到端 MVP单模型 手工 Prompt 少量固定工具验证打通业务可行性再逐步增加上下文工程RAG、记忆分层然后加容错机制输出校验、工具权限最后上评测和灰度。这对应了“先跑通再调优再加固再放量”的节奏能让你在最短的时间内看到效果、发现问题、扎实推进。6.3 本讲内容在真实项目中的应用案例教育领域智能体的落地细节为了把第二讲的抽象内容落到一个具体语境里我结合之前参与的教育情感智能体项目来复盘一下。这个项目要做的是一个面向低年级学生的陪伴式问答 Agent需要识别学生的情绪状态给出贴合情绪反应的回应同时能在知识问答场景里调用课程库检索内容。在这个项目里第二讲的很多理念都派上了用场Prompt 的结构化拆分我们把系统提示词设计成了三段——情绪识别规范怎么从语气、用词判断情绪、知识问答规范何时触发检索、何时直接回答、安全边界规范涉及危险话题或敏感内容时一律不展开回答而是引导至老师。这个三段式设计让模型在不同场景下的表现非常稳定。上下文工程的记忆分层短期记忆保留最近两轮对话用于保证语气连贯中期记忆用摘要方式保留整场对话的要点供情绪趋势分析长期记忆存学生的性格偏好和学习习惯下一次会话时按需注入。这套方案上线后学生对“它还记得我喜欢数学”这种反馈的热情远超我们的预期。容错机制的兜底因为面向的是学生出错的代价很高。我们在输出侧强制加了内容安全校验模型生成的内容先过关键词过滤和敏感话题检测命中高风险规则直接触发标准话术“这个问题我需要请教老师/家长”绝不给模型任何自由发挥的空间。同时因为模型偶尔会误判情绪我们对“高风险情绪识别”的结果做了二次确认让模型给出判断依据并在判定“学生有明显负面情绪”时限制工具调用权限仅允许安慰话术和求助转接。这个项目的经历让我对第二讲里的很多理论有了切身体会智能体可靠性的本质不是把模型调教成一个万能超人而是把系统的每一层都设计得足够清晰让模型的能力和系统的边界各司其职。7. 写在最后智能体的下一站是工程能力说实话CS329Z 第二讲没有什么惊天动地的“独家秘笈”它讲的每一件事——Prompt 要结构化、上下文要管理、输出要校验、系统要评测——都是这个行业里已经在做并且被反复验证过的工程实践。但它的价值在于把这些散落的实践系统性地整合成了一个完整框架让你从“东一榔头西一棒子”的零散摸索进入到“有章法地构建”的状态。回到这一讲的标题LLMs for Builders。Builders 不是被动使用模型的人而是主动设计“模型工作环境”的人。你在系统提示词里写的每一条规则你在上下文里注入的每一段知识你在输出链路里加的每一道校验都是在为模型搭建一个更适合发挥的工作台。这个“工作台”的搭建能力才是从“会用 LLM”到“能做产品”之间最需要补齐的能力。我个人在实际操作中的体会是第二讲内容消化得越早后面在智能体开发中走的弯路就越少。如果你已经具备基础的模型调用经验现在正纠结“怎么让我的 Agent 更可靠一点”这门课值得你认真过一遍。下一步可以去看它的实践课把这里的思路真正跑成一个属于你自己的项目。 
长河君 · 2026/10/9 17:40:43 · 阅读 1.2k 面向构建者的LLM实战：从Prompt工程到上下文工程的智能体开发指南
课程开篇就直接点破了这轮 AI 浪潮里一个很多人没绕过来的弯我们这些做应用、做产品的人跟大模型打交道的方式跟学术界研究大模型的方式完全是两码事。CS329Z 这门课取名 “LLMs for Builders”态度已经摆得很明确了——它不教你怎么训练一个模型也不推公式推导它教的是怎么把 LLM 当成一个趁手的、有脾气的、偶尔会犯糊涂的“新同事”来协作。第二讲全程在讲一件事怎么用好模型而不是怎么造好模型。我把这一讲的要点、踩过的坑、还有课后自己补的功课整理成这份笔记希望能帮你少走点弯路。1. 这堂课到底在讲什么面向构建者的大模型使用哲学先说一个很多人刚接触这课时会产生的困惑CS329Z 跟市面上那些讲 LLM 的课到底有什么不一样大部分公开课的重心放在模型本身——注意力机制怎么算、训练流程怎么设计、参数怎么调。这些内容对做研究的人很有用但作为一个要落地智能体的开发者坦白说这些知识跟你的日常工作是脱节的。你调 Prompt 的时候不需要知道 Flash Attention 的底层实现你设计 Agent 工作流的时候也不需要去推导 RLHF 的损失函数。你真正需要的是另一套知识模型的能力边界在哪里、怎么把任务切成模型擅长的小块、怎么让模型的输出稳定可靠、怎么在模型犯错的时候兜住底。CS329Z 的定位恰好就在这个位置。它对标的是吴恩达那类“LLM 工程最佳实践”课程但比那更成体系也更贴近当前智能体开发的前沿状态。第二讲作为整门课的地基把“作为构建者你应该怎么理解和使用 LLM”这件事讲透了。我个人看完这一讲的最大感受是它把“Prompt 工程师”这个词从一个玄学变成了工程学。课程里反复强调一个观点——模型不是一个参数化的知识库而是一个概率性的推理引擎。你要做的不是“问它问题”而是“给它搭一个能稳定发挥的工作环境”。这个视角的转换是后续所有智能体开发技巧的出发点。1.1 GPT 类模型日用指南从“问问题”到“下指令”这一讲前半部分花了不少篇幅讲 GPT 类模型也就是我们常说的 decoder-only 架构模型的正确打开方式。它的核心论点其实可以用一句话概括模型对你的意图一无所知它只知道怎么续写最合理的下文。这个特性决定了你必须用一种特定的方式跟它沟通。课程里提到了几个很关键的使用原则结合我的实际经验展开说第一上下文比模型参数更重要。很多人都没意识到你每一次调用模型实际上是在给它设置一个“工作状态”。同样的模型权重你给它的上下文不同它的表现可以判若两人。一个空上下文直接问“给我写一个 Python 函数”跟你在上下文里详细描述了函数用途、输入输出格式、边界条件之后再说“请实现”模型的输出质量完全不在一个量级。后者甚至不需要你多用多少 token但输出的可用性会翻倍。第二模型是在做“续写”不是在做“检索”。你问它“什么是 NaN”它不是在记忆库里找到一个标准定义念给你听它是在计算所有可能的续写中最可能被你接受的那一个。所以当你问一个问题时模型的回答其实是在猜测“一个问了这个问题的人最想看到什么样的答案”。这就解释了为什么同样一个问题你加上“我是一个深度学习初学者”和“我是一个有十年经验的算法工程师”得到的答案会完全不同——因为模型对“续写目标”的判断变了。第三指令要像给实习生派活不能像跟朋友聊天。课程里用了一组对比实验来说明这一点直接要求“总结这段文本”和结构化要求“你是文本分析助手请提取这段文本中的三个核心论点每个论点用不超过 20 个字概括并附上原文中的依据句”后者的输出质量高得多。不是因为模型“听懂了”更复杂的指令而是因为你的指令给它的续写圈定了一个更窄、更清晰的分布空间。1.2 从“需要什么”倒推“该怎么做”构建者的逆向思维这堂课给我印象最深的是它提出了一套倒推式的思考框架。普通用户使用 LLM 是正向思维我有一个问题 → 我把问题发给模型 → 模型给我答案。而构建者的思维是逆向的我的应用需要什么样的输出格式、结构、稳定性要求为了得到这种输出我需要给模型提供什么上下文、示例、约束条件如果模型做不到问题出在哪一环是理解了但表达不行还是信息不足还是任务的认知负荷太高这套框架在智能体开发中尤其适用。你设计一个 Agent 的工作流时每个环节的输入输出都是确定的用户 query 进来经过意图识别转成结构化参数调用工具拿到结果组织成回答。这里面的每一步其实都是“给模型设定一个特定的续写目标”然后通过 Prompt、示例、格式约束等手段把模型的行为扭到你要的轨道上。第二讲把“作为构建者你应该怎么理解和使用 LLM”这件事讲透了。它把 Prompt 从一个玄学变成了工程学模型不是一个参数化的知识库而是一个概率性的推理引擎。你要做的不是“问它问题”而是“给它搭一个能稳定发挥的工作环境”。这个视角的转换是后续所有智能体开发技巧的出发点。2. 提示工程的核心要素不只是“说清楚话”很多人对 Prompt Engineering 有个误解觉得它就是一门“把话说明白”的手艺。这话对了一半。说话清楚当然重要但工程意义上的 Prompt 设计讲究的是一套有章法可循的组件化结构。CS329Z 第二讲把 Prompt 拆解成几个核心要素这一套拆法比我见过的大多数博客文章都要系统。我结合自己的使用经验逐个展开讲。2.1 系统提示词、工具调用与上下文窗口的管理先说说系统提示词System Prompt。很多人以为系统提示词只是给模型“设定一个人设”其实它的核心作用是在模型的续写空间中注入恒定约束。模型在每条消息生成时都会把整段对话作为上下文来预测下一个 token。系统提示词是这段上下文中永远摆在最前面的部分它对模型行为的影响是全局性的、持续性的。这就意味着你的系统提示词里应该放三类东西第一类是角色的边界。不光是“你是一个客服助手”这种简单人设更重要的是“你能做什么、不能做什么”。比如“你是智能客服 Agent只能回答关于产品使用的问题涉及售后退换货请引导用户联系人工客服”。这种边界设定不是为了让模型“入戏”而是为了把它的续写分布朝着“合规范围”内挤压。第二类是工作流程的固定步骤。如果你的 Agent 在收到用户消息后必须先做意图识别、再抽取参数、然后决定是否调用工具这个过程应该写进系统提示词。模型天然是按顺序续写的你把这个流程摆在它面前它就会顺着这个流程往下走。第三类是输出的通用规范。包括语言风格、字数限制、禁忌词表等。这些约束对模型续写的引导作用比你想象的要强得多。工具调用Function Calling / Tool Use本质上也是 Prompt 工程的一部分。你把工具的描述、参数结构、调用规则作为上下文的一部分提供给模型模型的任务就变成了根据用户输入决定是否调用某个工具、传入什么参数。这个机制之所以重要是因为它把模型从“只能输出文本”变成了“可以操纵外部系统”。上下文窗口管理则是另一个容易被忽略的工程点。模型对上下文的利用不是一视同仁的——距离当前位置越近的内容对当前生成的影响越大这个效应在长对话中尤其明显。课程里给出的实操建议是把最重要的约束放在系统提示词里永远在最前把最新的对话放在最末尾中间的历史消息如果太长要么截断、要么摘要、要么向量化检索后按需注入。原生支持超长上下文的模型也不能完全免除这个问题——能力不是线性的超长上下文中模型仍然会弱化对早期内容的记忆。2.2 few-shot 与思维链给模型的“拐杖”与“脚手架”Few-shot少样本示例和 Chain-of-Thought思维链是 Prompt 工程里两个最常用也最容易被误用的工具。先聊 few-shot。它的本质不是给模型提供“知识”而是给模型提供“格式锚点”。模型本身可能已经知道怎么回答这个问题但它不确定你要什么格式的回答。你给了三五个示例其实是在告诉它我要的输出长这样结构如此细节密度如此。所以 few-shot 的选例策略很有讲究——示例的首要标准不是“内容正确”而是“格式典型且边界清晰”你要故意选一些覆盖不同输入情况的样例让模型能从中归纳出“什么输入对应什么输出”的映射规律。思维链则是另一套机制。它利用的是模型的一个特性逐步推理能够显著降低单步推理的错误率。你不让模型直接输出答案而是要求它先输出推理过程再给出结论。这听上去像是在“鼓励模型思考”实际上是在把一个高难度的单步预测拆分成多个低难度的连续预测。每一步的预测难度降低了总体的成功率反而会上升。但思维链有个工程上必须注意的点推理过程要短、要结构化。课程里推荐的模板是“Let‘s think step by step but keep it concise”我在实践中进一步总结为给思维链限定步骤数例如“先判断用户意图再提取关键参数最后决定是否调用工具”每一步只做一件事。不然模型很容易在一个开放式思维链里越绕越远输出大量无关内容既浪费 token 又拖慢响应时间。在实际工程中思维链做得短这件事比做得长更重要。2.3 编写高质量 Prompt 的实操套路模板化、版本化、可测试Prompt 的工程化不能停留在“写一段好文本”的层面你还需要一套管理机制。我自己在项目里的做法是首先Prompt 必须模板化。把固定不变的约束、规则和动态插入的内容用户 query、检索结果、工具输出分开。不要用手工拼接的方式去组装 Prompt最好能落成代码里的渲染模板。这样你更新 Prompt 规则时只需要改模板而不需要动业务代码任何一次修改都可以放进 git 里做版本管理。其次Prompt 必须版本化。大模型应用的迭代核心就是 Prompt 的迭代。你改了一个措辞用户看到的行为就会变。如果不对 Prompt 做版本管理出了问题都不知道是代码改坏了还是 Prompt 改坏了。至少要用 git 管理模板文件、用环境变量或配置中心切换不同环境的 Prompt 版本有条件的话学一下 Prompt 评测的思维把不同版本的 Prompt 挂在一批固定用例上跑一遍对比输出质量和格式符合率再决定是否上线。最后Prompt 必须可测试。这里的“测试”不是指用肉眼看看输出对不对而是建立一套自动化校验输出是否符合 JSON 格式关键字段是否齐全调用工具的参数是否合法这些校验逻辑虽然挂在模型输出之后但设计的时候要倒推到 Prompt 里——如果模型经常输出不合规你要去改 Prompt 的约束而不是一味地在代码里写好几种兼容逻辑去“接住”它的一堆烂摊子。我在真实项目里实测把 Prompt 模板化 版本化 自动化测试这套组合做起来之后模型的输出质量在两周内就能看到系统性提升。3. 从 Prompt 到上下文工程RAG、记忆与外部知识这堂课讲到这里其实已经把所有“把话说明白”的技巧讲完了。但光有这些还不够——因为你的智能体在真实场景里要面对的问题是动态的、未知的知识不可能全部装进模型权重里更不可能全部塞进 Prompt 里。第二讲的进阶部分是“上下文工程”。这名字起得比“Prompt 工程”更准确——因为我们做的事情本质上是决定“哪些信息出现在模型面前”。3.1 上下文工程的价值所在让模型按需获取知识模型经过预训练之后它的“知识”就被冻结在权重里了。但你的业务知识是活的实时变化的新品信息、库存状态、用户订单记录、系统日志……这些都发生在模型训练完成之后。你不可能为了每一条业务数据去微调一次模型所以必须找到一种方法让模型在推理时能按需获取外部知识。这就是 RAG检索增强生成做的事情。它的核心逻辑非常朴素用户提问 → 从外部知识库检索相关内容 → 把检索结果作为上下文的一部分提供给模型 → 模型基于“上下文 自身推理能力”生成回答。注意这个流程中模型扮演的角色——它仍然是一个“续写机器”但它现在不是基于自己脑子里那些可能过时的参数来续写而是基于你提供的最新知识来续写。RAG 的本质不是增强模型的“记忆”而是增强模型在生成时能看到的“视野”。第二讲里有一个比喻我印象很深模型的知识是“长期记忆”上下文是“工作记忆”RAG 就是把你需要的档案从资料室调到桌面上来。这个比喻虽然简单但非常准确地揭示了三者的分工关系。3.2 检索效果的关键环节切块、向量化与排序算法做 RAG 的人都知道检索效果的好坏很多时候不取决于模型而取决于你的索引质量。课程里没有展开讲太多检索细节但给出了一个重要的原则检索是 RAG 的上限生成只是把检索结果用起来。这些原则落到实操层面就变成了几个具体的决策点第一个是切块策略。你把知识文档切成多长的片段来做索引切得太短每个片段的信息不完整切得太长向量检索的精确度下降而且容易把不相关的噪声带进上下文。我的经验是切块长度没有放之四海皆准的标准它依赖于你的文档类型和用户提问粒度。产品说明书按章节切FAQ 按条目切技术文档按小节切。一个比较通用的起手式是 300-500 字一块带 50-100 字的重叠然后再根据实际的检索命中效果去调。第二个是向量化模型的选择。这里有一个常见的认知误区embedding 模型不是越强越好而是越匹配越好。你的检索需求其实只是“找出语义相近的文本片段”而不同场景下“语义相近”的定义不一样。问“怎么退货”和“退款流程是什么”在电商客服场景里应该被算作同一个问题但在法律咨询场景里可能根本不是一个概念。所以如果你的预算允许最好在自己的业务数据上微调或至少评测几个不同的 embedding 模型而不是想当然地选一个“大家都说好”的。第三个是重排。纯向量检索的结果在粗糙的语义匹配上是够用的但如果你对检索精度要求高需要在召回之后加一层重排Rerank。简单的做法是用一个交叉编码器模型对召回的 top-k 条结果逐一打分再按新的分数排序。这层操作的计算成本比向量检索高但能显著提升“最终进入上下文的内容质量”。3.3 长对话下的记忆管理缓存、摘要与分层存储上下文工程的另一个重要战场是多轮对话记忆。你的智能体跟用户聊了二十轮不可能每一轮的内容都喂给模型——不仅 token 费用扛不住模型的注意力也会被稀释。我在实际项目里总结出一套分层记忆方案在这里一并分享短期记忆保持最近 2-3 轮对话的原文直接放在上下文里。这些信息是最相关的不需要额外处理。中期记忆更早的对话内容太大不能全量保留。一个有效的做法是“边聊边摘要”——每轮对话结束后让模型用一两句话概括本轮的核心信息然后只保留这些摘要。这个方案我在智能客服项目里实测过效果很好模型对“用户之前提到过某某需求”的记忆准确率能保持在九成以上。长期记忆用户的长期偏好、历史订单、跨会话信息这些不能依赖摘要因为摘要只覆盖当次会话需要存到数据库里在合适的时候检索出来作为上下文注入。这套分层方案的成本可控、可扩展性也好而且每一层都可以单独调优。课程里虽然没有整套说出来但它的思路——在不同环节控制“哪些信息进入上下文”——就是这套方案的骨架。4. 推理时扩展、结构化输出与智能体能力边界CS329Z 讲到这里开始触及这一讲最有分量的内容如何让模型在推理时“想得更久一点”、输出“更规整一点”以及这些手段如何构成智能体的核心能力。4.1 扩展思维链让模型“想得更久”的收益与代价前面聊过思维链但那是“指令级的引导”。第二讲更进一步讲的是“推理时扩展”——不改变模型权重而是在生成时给模型更多机会去推理。核心做法有几种。最简单的是多次采样后自洽性投票同一个问题让模型用不同的温度参数采样多次比如 5 次然后把多次结果做一个投票或加权选最一致的答案。这能在不改变任何模型参数的情况下提升准确率原理也很朴素——随机错误是分散的正确答案是收敛的。更进阶的是显式的多步推理循环让模型“先写出已知条件→再列出可能的解题方向→选择一个方向→执行步骤→回头检查”。这本质上就是把人的解题流程复制给模型。课程里提到这类方法在数学、逻辑任务上的收益非常显著。但“推理时扩展”是有代价的——第一个代价是延迟模型要想得更久你的用户就要等更久第二个代价是成本更多的输出 token 更多的钱。所以在智能体的工程实践中我们不能在所有请求上都加扩展推理而是要识别哪些任务真的需要“深思熟虑”哪些任务是反射性的、直接回答即可。一个简单的分流规则是需要调用工具、需要多步逻辑的任务开启扩展思维链知识问答、闲聊寒暄直接快速回答。这个“分流”的思路其实也是智能体设计中最重要的判断力之一——不是所有请求都值得花大代价去仔细推理知道何时该快、何时该慢是做工程的成熟表现。4.2 结构化输出的工程方案从 JSON 模式到函数调用智能体跟用户最直观的差别是什么是它会“做事”而做事的第一步是把自然语言翻译成结构化指令。你的 Agent 要调用天气 API就得先把“北京明天会下雨吗”翻译成{city: 北京, date: 明天}。这一整套翻译过程就是结构化输出要解决的问题。实现结构化输出的方案按推荐顺序排列首选方案是模型原生的函数调用Function Calling能力。新一代模型在被微调时就已经被训练成当上下文表明“该调用工具”时输出一个结构化的工具调用 JSON。你只需要在请求里声明可用的工具列表名字、参数 schema、描述模型自己会判断要不要调用以及传入什么参数。这个方案最稳、最省事。次选方案是输出约束 校验重试。如果你的模型不支持原生函数调用可以要求模型以 JSON 格式输出同时在代码里做严格的格式校验和重试。这里有个实操经验要在 Prompt 里给出“目标 JSON 的完整 schema 示例和字段含义说明”并且明确告诉它“只输出 JSON不要输出任何解释文字”。模型输出后程序侧做好防御性解析失败就让它重来重试两三次基本都能得到合规结果。通用兜底方案是语法约束解码。一些推理框架支持在解码阶段按语法约束进行受限生成从根上保证输出一定是合法 JSON 或满足某种格式。这个方案的缺点是它对底层框架有要求灵活性不够高一般用于对结构要求极端严苛的场景。我个人建议始终把函数调用作为首选只有在模型不支持时再退回到输出约束 校验这一档。4.3 Agent 的构建模式从单轮调用到 ReAct 循环第二讲的最后一部分把目光拉高从“怎么让模型输出更好”转向“怎么让模型组成的智能体能完成一个完整任务”。这里课程抛出了一个构建 Agent 的基础模式也是当前智能体开发被讨论得最多的框架——ReAct。ReAct 的核心可以用一个词概括环。一次推理不够那就“推理→行动→观察→再推理”直到任务完成。Agent 首先根据用户请求和当前情景进行推理决定下一步行动然后调用工具、执行行动接着观察工具返回的结果把新的信息纳入推理然后继续循环直到得出最终答案或确认任务无法完成。这套模式看起来简单但工程落地的细节非常多。最关键的三个点一是循环的终止条件。如果 Agent 没有一个明确的“我该停了”的判断机制它会在工具调用和推理之间无限循环。工程上必须在每一轮之后做一个终止判断任务目标是否已达成如果达成进入总结输出阶段如果未达成但步数已超上限比如 5 步强制终止并输出中间结果或转人工。二是工具的抽象与描述。模型只能通过你的工具描述来理解“这个工具能做什么、什么时候用”。所以工具描述必须写清楚功能边界、输入参数含义、典型使用场景。我在项目里吃过亏当时是工具描述里没写清“该工具只接受标准格式的日期参数”导致模型连续几次把错误格式的日期传给工具。后来我认真重写了工具描述把这些约束全部写进去误调用率直接降了一半。三是可观测性。Agent 的思维链和行动链是黑盒一旦出错很难排查。工程上要做日志记录——每轮的推理内容、调用的工具、传入的参数、返回的结果全部落日志。我做智能体项目时几乎每一次线上故障排查都依赖这些日志它比任何测试都真实。5. 构建可靠 AI 系统的工程实践容错与评估听完了第二讲的前半程你可能已经摩拳擦掌准备搭自己的 Agent 了。但作为在智能体开发一线摸爬滚打过的人我必须提醒你模型能力决定的是你的系统的上限工程能力决定的是你的系统的下限。一个模型再强如果你的系统在它出错时直接崩溃或给出一个完全离谱的答案用户不会觉得“模型好厉害”只会觉得“这个产品不行”。课程里在这一部分讲的可靠性工程在我看来是这堂课最值钱的内容之一。5.1 可靠的智能体 工程兜底 自主容错智能体跟传统软件的本质区别是传统软件的输入输出是可枚举的你可以用穷举法保证正确性但智能体的输入是自然语言输出是生成式的你永远无法穷举它的错误模式。所以“可靠性”不是指望模型永不犯错而是在模型犯错时系统能不能兜得住。这就引出了容错设计的核心思路我把它总结成三层防线第一层输入侧拦截。在请求进入模型之前做规则性的预处理。敏感词过滤、超长输入截断、非法格式拒绝、明显不在业务范围内的 query 直接给兜底回复——这些不需要大模型几行规则就能完成但能挡掉大量低质量请求。第二层输出侧校验。模型输出的东西在返回给用户之前必须经过一道“质检”格式是否合规关键字段是否存在内容是否包含敏感信息是否在业务允许的范围内校验不通过就触发自动重试或降级逻辑。第三层行为侧约束。对于需要调用外部工具的 Agent必须给它的工具调用加白名单、加参数合法性校验、加调用频率限制。模型如果试图调用不在白名单内的工具直接拒绝并提示“我没有这个能力”。这个动作在传统软件工程里叫权限校验但在智能体系统里它就是“自主容错”的基石——系统不允许模型做超出授权范围的事。5.2 LLM 系统的评测方法建立评估集、指标与回归机制评测这件事是很多人做 LLM 应用时最容易忽略的一环。原因很能理解功能都还没调通谁有空写评测但你可能低估了它的价值——没有评测你的系统就永远只能停留在“感觉还行”的状态无法迭代。课程里给出了 LLM 系统评测的最小可行方案我觉得非常接地气第一步建立评估集。哪怕先搞 30-50 条从真实的用户日志里挑典型问题覆盖主流程、边界情况超长输入、语义不明的请求、包含歧义的 query和已知失败案例。每条用例要有标准答案或评分标准。第二步拆指标。两个最核心的指标格式合规率输出是否符合结构要求和执行成功率Agent 是否在有限的步数内完成目标。这两个都是可自动化计算的硬指标。在此基础上如果要评测回答内容本身的质量可以用“LLM as Judge”——让一个强模型给输出打分。第三步回归机制。每次改动Prompt 调整、工具更新、模型版本切换之后都要把评估集完整跑一遍对比新旧版本的分差。我的经验是删除一个在旧版上表现异常优异的评估用例要谨慎很多时候它压着的恰恰是一个你没注意到的回归风险。有了这套评测机制你的智能体迭代就从一个“拍脑袋的过程”变成了一个“有数可看的过程”。5.3 平台搭建与代码搭建的本质差异选择你的战场最近这个行业里有个非常热门的话题用平台Coze、Dify 这类搭智能体和用代码Python LangChain / LlamaIndex 这类搭智能体到底怎么选这堂课的内容恰好是回答这个问题的最佳参照。用平台搭和用代码搭表面上看只是工具不同本质上是你选择把哪部分工程能力交给谁。平台方案的核心优势是快。内置了 Prompt 管理、知识库、工具编排、可视化调试界面拖拖拽拽就能出一个原型。但它的代价是自由度低——平台的编排粒度、上下文管理细节、定制化校验逻辑都受制于平台提供的抽象层级。你可能想写一条平台不支持的校验规则或者想调一个平台不暴露的参数这时候就撞墙了。代码方案的核心优势是可控。你能完全掌控 Prompt 的组装逻辑、上下文的管理策略、工具调用的边界、容错的每一个细节。但代价是慢——你需要自己搭一套除了业务逻辑之外的基础设施记忆管理、日志系统、评测框架、模型切换逻辑等等。我自己的建议是看你的目标做验证、做原型、做简单内部工具直接用平台把时间花在业务逻辑上做面向真实用户的多轮对话系统、做复杂工具链的 Agent、做需要深度定制可靠性逻辑的系统毫不犹豫选择代码方案。第二讲里那些上下文工程、容错机制、评测方案在代码方案里你能一条一条落地在平台方案里大概率只能用到一半甚至更少。6. 实操心得与工具选型建议这一讲的内容信息量很大最后这部分我想结合自己的开发经验把一些课程里点到为止的细节展开聊一下同时分享一套我在智能体项目里验证过的基础工具栈选型供你参考。6.1 模型选型从 Claude 到国产模型的分层策略模型选型一直是智能体项目的热门问题。这两年各家模型的能力不断拉近但各自的脾性、速度、成本、合规条件还是有明显差异选型不能只看“最强”要看“匹配”。我当前的通用思路是分层使用复杂推理和关键工具调用使用 Claude 系列尤其是思维链和 Agent 场景虽然贵但正确率高值得在关键路径上花这个钱。日常对话和知识问答使用 GPT-4o 系列或国产头部模型资深的几款在中文场景下表现已经不输闭源成本可控速度也快。摘要、信息抽取、打标签使用小参数模型或降配方案量大但任务简单跑得快、成本几乎可以忽略。这里有一个需要特别强调的经验不要被“最强模型”绑架。很多团队一上来就全链路用一个最强最贵的模型结果成本翻了数倍用户体验却没有显著提升。正确做法是为不同的任务选择不同档位的模型配合路由策略自动分流。6.2 工程栈推荐与落地顺序建议如果你准备从零开始搭一个智能体系统下面是我验证过的推荐技术栈基本覆盖了这一讲里提到的所有工程点模型接入与路由OpenAI SDK / Anthropic SDK配合自研路由层Agent 框架LangChain / LiteLLM更轻量后续可逐步替换为自研编排框架向量库Milvus数据量大有高可用需求/ Chroma轻量起步记忆层Redis短期会话缓存 PostgreSQL长期用户画像可观测性LangSmith 或自研日志中间件关键指标落表评测框架自建评估集 LLM as Judge 脚本部署与上线FastAPI Docker 云函数网关层做限流关于落地顺序强烈建议按这条链路推进先做端到端 MVP单模型 手工 Prompt 少量固定工具验证打通业务可行性再逐步增加上下文工程RAG、记忆分层然后加容错机制输出校验、工具权限最后上评测和灰度。这对应了“先跑通再调优再加固再放量”的节奏能让你在最短的时间内看到效果、发现问题、扎实推进。6.3 本讲内容在真实项目中的应用案例教育领域智能体的落地细节为了把第二讲的抽象内容落到一个具体语境里我结合之前参与的教育情感智能体项目来复盘一下。这个项目要做的是一个面向低年级学生的陪伴式问答 Agent需要识别学生的情绪状态给出贴合情绪反应的回应同时能在知识问答场景里调用课程库检索内容。在这个项目里第二讲的很多理念都派上了用场Prompt 的结构化拆分我们把系统提示词设计成了三段——情绪识别规范怎么从语气、用词判断情绪、知识问答规范何时触发检索、何时直接回答、安全边界规范涉及危险话题或敏感内容时一律不展开回答而是引导至老师。这个三段式设计让模型在不同场景下的表现非常稳定。上下文工程的记忆分层短期记忆保留最近两轮对话用于保证语气连贯中期记忆用摘要方式保留整场对话的要点供情绪趋势分析长期记忆存学生的性格偏好和学习习惯下一次会话时按需注入。这套方案上线后学生对“它还记得我喜欢数学”这种反馈的热情远超我们的预期。容错机制的兜底因为面向的是学生出错的代价很高。我们在输出侧强制加了内容安全校验模型生成的内容先过关键词过滤和敏感话题检测命中高风险规则直接触发标准话术“这个问题我需要请教老师/家长”绝不给模型任何自由发挥的空间。同时因为模型偶尔会误判情绪我们对“高风险情绪识别”的结果做了二次确认让模型给出判断依据并在判定“学生有明显负面情绪”时限制工具调用权限仅允许安慰话术和求助转接。这个项目的经历让我对第二讲里的很多理论有了切身体会智能体可靠性的本质不是把模型调教成一个万能超人而是把系统的每一层都设计得足够清晰让模型的能力和系统的边界各司其职。7. 写在最后智能体的下一站是工程能力说实话CS329Z 第二讲没有什么惊天动地的“独家秘笈”它讲的每一件事——Prompt 要结构化、上下文要管理、输出要校验、系统要评测——都是这个行业里已经在做并且被反复验证过的工程实践。但它的价值在于把这些散落的实践系统性地整合成了一个完整框架让你从“东一榔头西一棒子”的零散摸索进入到“有章法地构建”的状态。回到这一讲的标题LLMs for Builders。Builders 不是被动使用模型的人而是主动设计“模型工作环境”的人。你在系统提示词里写的每一条规则你在上下文里注入的每一段知识你在输出链路里加的每一道校验都是在为模型搭建一个更适合发挥的工作台。这个“工作台”的搭建能力才是从“会用 LLM”到“能做产品”之间最需要补齐的能力。我个人在实际操作中的体会是第二讲内容消化得越早后面在智能体开发中走的弯路就越少。如果你已经具备基础的模型调用经验现在正纠结“怎么让我的 Agent 更可靠一点”这门课值得你认真过一遍。下一步可以去看它的实践课把这里的思路真正跑成一个属于你自己的项目。