同样一个 LLM有人拿它做了一个只会聊天的漂亮外壳有人却用它搭出了能自主调研、自动写码、甚至自己给自己修 bug 的 Agent。差距不在模型大小而在“系统”。斯坦福 CS329Z 这门课讲的就是 Agentic Systems——智能体系统——从概念到工程的完整框架。这篇笔记是我对第一讲导论的学习复盘也是把课程观点和我自己项目经验揉在一起后的浓缩版目标读者是正在做 LLM 应用开发、想从 Chatbot 迈向下一个阶段的工程师朋友。需要先说清楚一件事CS329Z 不是“提示词进阶教程”。它把 LLM 当成一个被放进复杂环境里的“行动体”讨论怎么让它调用工具、拆分任务、记住关键信息、从错误中恢复以及最后怎么评估和上线。第一讲本身内容量不大但它像一张地图把整门课的家底都铺开了。看完第一讲你真正能带走的是一个思维转换从“我写一段好 prompt 让它回答得好”到“我设计一个系统让它在没人盯着的情况下也能把事情办成”。1. CS329Z 这门课到底在讲什么1.1 第一讲里最基础的一个转向从“生成器”到“行动体”第一讲抛出的核心命题我理解下来是这样的传统 LLM 应用的本质是“单次生成”。你给我输入我给你输出一段文字结束调用就结束了。但真实任务几乎都不是一次性文本生成——比如“帮我调研这三个竞品的定价策略生成一份对比表”这个任务需要搜索、打开页面、提取数据、比对口径、整理结构最后才形成报告。任何一个环节失败都必须有下一步决策换个站点搜、换个关键词、或者先问用户优先级。这就是 Agent 和 Chatbot 的本质差异。课程把 LLM 重新定位成“处于环境中的行动体”它不再只是吐出 token而是在一个目标约束下连续地观察环境、做出动作、承担后果。这个定位一换所有工程问题都变了你要考虑工具怎么暴露、状态怎么保存、权限怎么控制、失败怎么恢复。CS329Z 第一讲就是在给你换这个脑子。1.2 为什么 Agent 在最近两年才真正开始爆发Agent 这个概念其实很老2016 年前后就有游戏智能体、机器人控制这类方向。但那时候做一个能自主决策的 Agent需要自己训练策略网络、自己调奖励函数、自己准备海量样本成本高得离谱普通团队根本玩不动。LLM 出现之后门槛一下被削平了你不需要训练决策模型你只需要给一个预训练模型提供“推理提示 工具清单 输出格式”决策由模型本身来做。所以课程里反复出现一个词脚手架scaffolding。大多数智能体能力不是模型天赋出来的而是外面套了一层壳——任务分解策略、自我纠错流程、工具调用规范、记忆管理机制。这层壳是工程问题不是模型问题。这也是 CS329Z 存在的理由它不教你怎么训模型教你给模型盖这层壳。1.3 课程整体框架与第一讲的位置从公开的课程目录来看主线大体是这样的先讲 Agent 基础与典型应用场景然后深入工具调用和函数接口接着是规划与推理、记忆管理、多智能体协作再往后是评估、对齐最后落到生产级可靠性。第一讲就是一张地图告诉你后面每一节课解决的是整张图里的哪一块。我学完第一讲之后的最大感受是这不是“教你写 prompt”的课而是“教你像设计分布式系统一样设计 Agent”。如果你要做的是一个 production 级智能体而不是演示 Demo这门课的方向非常对口。哪怕只是看第一讲你也能立刻意识到自己之前做的 Agent 到底缺了哪几块没有状态管理、没有评估闭环、没有退化预案。2. 智能体的骨架控制循环、工具调用与记忆管理2.1 把控制循环画在纸上Think → Act → Observe第一讲会反复出现一个基本运行循环。无论你用 LangGraph、AutoGen、CrewAI 还是纯手写Agent 的内核其实是同一个模式Think模型根据当前状态和目标做推理或计划Act调用一个工具或执行一个具体动作Observe观察动作返回的结果回到 Think决定下一步这个过程通常会不断重复直到任务完成、步数耗尽、或者触发停止条件。建议把循环画在纸上再写代码。做第一个 Agent 时我直接对着循环图把每个节点拆成一个函数plan(state)、act(state)、observe(state)调试的时候就能精确定位是“模型的计划错了”还是“工具的执行错了”还是“我解析结果错了”。相比之下把逻辑塞进一个巨大 prompt 里出了问题你会完全无从下手。2.2 工具调用的成败往往藏在“描述”里工具调用是智能体跟世界交互的接口。很多人以为把函数列出来模型就会乖乖用实际根本不是这样。我总结过一条规律一个工具的 description 写得越像“给人看的使用手册”被正确调用的概率就越高。什么叫给人看的使用手册至少要包含三件事这个工具是干什么的、在什么场景下使用、常见的坑和报错是什么。举一个函数声明的例子tools [ { type: function, function: { name: search_products, description: ( 按关键词搜索商品列表。 当用户想查找某个商品时使用。 示例找一下200元以内的蓝牙耳机应传入 price_max200。 若结果为空建议提示用户更换关键词或放宽价格区间。 ), parameters: { type: object, properties: { keyword: {type: string, description: 商品关键词}, price_max: {type: number, description: 最高价格可选}, }, required: [keyword], }, }, } ]第一讲虽然不细抠 API 格式但一定会强调一个原则工具是智能体“可控行动的边界”。模型只可能调用你暴露出来的工具也只可能按你写的描述去理解工具的作用。你给的工具边界有多大模型的行动边界就有多大。这是个安全话题也是可靠性话题。工具描述写不好后面所有环节都会跟着出错。2.3 记忆不是越长越好而是分层管理第一讲里关于记忆的内容印象最深的观点是上下文窗口不是记忆它只是工作台。你可以把窗口想象成一张桌子桌子再大堆满东西之后你反而找不到需要的工具。真正的长期记忆应该放到外部用向量库或结构化存储保存历史事实与用户偏好定期对老对话做摘要压缩明确设计“什么信息写入记忆、什么信息只留在当前对话”这样做的原因很简单。Agent 任务一长把所有原始信息都塞进上下文模型注意力会被稀释回复质量反而下降。把已经处理过的信息归档到外部模型才能保持焦点。实际项目里我通常会在每轮循环结束时让 Agent 判断一下“当前这轮有没有值得长期保存的信息”命中就写入外部存储而不是每轮无条件往里堆。3. 构建可靠 Agent 的工程防线容错、评估与可观测性第一讲导论严格来说没有专门讲工程可靠性但整个课程都在为这个问题做铺垫。现在圈子里聊得最多的“LLM 智能体自主容错控制”和“构建可靠 AI 系统的工程实践”其实就是这个方向。这是智能体从 Demo 到生产最难跨过的一道坎值得用一整节说透。3.1 失败是默认状态单点错误会滚成累积错误先算一笔简单的账。假设智能体每一步执行的成功率是 95%看起来不低但一个需要 5 步的任务整体成功率是 0.95^5约等于 77%10 步任务直接掉到 60% 左右。也就是说只要 Agent 需要多步行动失败就不是“偶发事件”而是默认状态。第一讲给你的正是这种系统思维单独看模型每次回答都像模像样但串成一个长任务之后任何一步偏一点最终结果可能面目全非。所以生产级 Agent 必须把“每一步都可能失败”当前提来设计而不是当异常来容忍。谁先把心态从“让它别出错”调成“出错之后怎么办”谁就能在工程化上领先一步。3.2 我实战中真正用上的容错手段下面这些手段不是课程原话都是我基于第一讲的思路、在真实项目里反复试出来的按优先级排列重试加指数退避。面对限流、网络抖动不能只重试一次。tenacity这类库可以直接用或者手写一个循环首次失败等 1 秒第二次 2 秒第三次 4 秒最多 5 次。这里的关键不是“多试几次”而是“别把限流试成熔断”。为每个动作要“凭据”。Agent 说“我已经发送了邮件”不算数要让它返回邮件 API 的 message_id说“文件已生成”不算数要让它返回文件大小或哈希值。下一步决策必须建立在可验证的凭据上而不是模型的自我陈述。检查点持久化。把任务状态存到数据库或本地文件标记当前执行到第几步。一旦中途崩溃可以从失败步骤恢复而不是整个任务重来。我做过一个数据搬运 Agent在第 3 步拉取第三方 API 时超时有检查点的版本只重试了第 3 步没有检查点的版本把所有接口又重新请求了一遍成本和耗时直接翻了三倍。步数与预算上限。每轮循环递增step_index超过max_steps就强制终止并输出“当前已完成的部分 剩余未完成的原因”。防止 Agent 在一个分叉里无限打转。自动降级路径。主工具挂了切备用工具。比如主搜索 API 限流就切到备用的搜索接口再不行就退化成“直接给用户几个建议关键词让用户自己确认方向”。降级的核心原则是宁可交出一个不完美但明确的中间结果也不要让用户对着一个卡死的对话等半天。人工确认闸门。对“删除数据、发送对外消息、执行支付”这类不可逆或高风险动作必须暂停循环把动作内容和后果展示给用户等确认再继续。这一点在课程后面的对齐和可靠章节会被反复强调但从第一讲开始就应该刻在脑子里。3.3 可观测性把 Agent 的过程变成可回放的录像很多 Agent 项目失败后很难排查就是因为只记录了最终结果没记录过程。我强烈建议无论项目多小都要把“轨迹日志”当作第一优先级。至少每个动作记录以下字段时间戳与执行顺序模型的输入消息与输出内容被调用的工具名称、参数、原始返回token 消耗和延迟任何告警或异常信息有条件的话把完整循环过程落成结构化数据相当于每一步都留存了“录像”。有了这套数据定位错误会快很多。比如用户反馈“结果不对”你可以回放轨迹看到第 2 步模型选错了工具还是第 3 步工具返回了脏数据。没有轨迹这一切只能靠猜。3.4 评估没有评测集可靠性无从谈起第一讲虽然没有展开评估但整个课程都渗透着同一个理念可靠工程离不开可量化的评估。我们现在开发 Agent不是“调好一个 prompt 就行”而是要在迭代中持续确认“改动到底是变好了还是变差了”。建议维护三类测试集单步工具选择测试给一个用户请求预期调用哪个工具、传什么参数端到端任务测试给一个完整任务校验最终产物是否满足要求回归测试把历史上失败过的 case 全部收进来每次改系统都要重新跑一遍。模型一更新Agent 的行为很可能大变。没有回归测试兜底你根本不知道一次升级是把工具调用准确率提高了还是把某个隐蔽路径搞崩了。这就像给智能体装了一个刹车系统平时看不出作用关键时候能救你一命。4. 第一讲里值得反复咀嚼的设计思想4.1 系统提示词不是“生活指南”而是“操作手册”第一讲没有直接教怎么写系统提示词但给出的智能体范例都不是“你是一个友好的助手”这种风格。真正有效的系统提示词写的是判断标准和默认行为。举几个例子“如果搜索结果为空主动询问用户是否放宽关键词而不是编造结果。”“任何涉及删除数据的操作必须先执行 dry-run并等待用户明确确认。”“当用户说‘查找物流’时先调用 get_order 获取订单号再调用 track_package。”这就是把提示词从“价值观宣言”改成“操作手册”。操作手册的每一句话都应该能指导模型在某个具体岔路口做出选择。你给它写的例外情况越多它在真实边界上的表现就越稳。这个认知会贯穿整门课。4.2 多智能体的本质是分工不是人多后来课程会展开多智能体但第一讲已经在为这个主题铺路。多智能体架构为什么有效不是因为“多个模型一起想更聪明”而是因为它让你能拆分职责、隔离权限、独立测试。比如 planner-executor 模式里planner 只负责任务分解executor 只负责执行具体调用supervisor 负责汇总和验收。每个角色手里的工具都是最小集executor 拿不到最终审批权supervisor 拿不到执行细节。这本质上是一种权限分割跟“人多力量大”完全是两码事。设计多智能体系统时要反复问自己一个问题这个决策到底应该由哪个角色负责如果谁都能写文件、谁都能发请求那系统就退化成一堆互相竞争的工具箱。边界越清晰系统越可靠。4.3 越昂贵、越危险的动作越要有闸门还有一个思想贯穿第一讲让 LLM 自主不等于把所有权力交给它。你可以让 Agent 自己规划路径、自己试探性执行但涉及发送对外消息、修改生产数据、消耗大量预算的动作都要设置人为或半自动的闸门。更直白地说可控的自主才是最有价值的自主。我在项目里实际采用的做法是给每个工具分配一个“自主等级”只读类工具可以直接执行写入类工具需要业务规则校验不可逆类操作必须经过人工确认通道。这样既保留了 Agent 的自主性又把风险锁在可控范围内。第一讲反复暗示的一件事就是这样真正优秀的智能体系统设计一定是对用户负责的系统设计。5. 从第一讲出发给入门者的实操路线5.1 最小复现先搭一个会犯错、可追踪的 Agent听完第一讲不要急着上复杂框架。先花三天搭一个最小闭环选一个简单的真实任务比如“让 Agent 从某个公开 API 拉数据汇总成 Markdown 文件”。你需要的东西很少一个 LLM 接口、一个工具函数、一个循环逻辑、一套轨迹日志。我用过的手写骨架大概是这个意思state {step: 0, messages: [system_prompt], result: None} while state[step] max_steps: state[step] 1 response llm_call(state[messages], tools) log_trace(state[step], response) if response.finish_reason stop: state[result] parse_result(response) break tool_name, tool_args parse_tool_call(response) tool_result execute_tool(tool_name, tool_args) state[messages].append(tool_result)这段代码没有用什么高级框架但已经具备了 Agent 的三要素循环、工具调用、状态累积。先跑通这个最小闭环再用 LangGraph 或 AutoGen 去重构你会发现自己对每个抽象层的理解都完全不同。5.2 最容易踩的几个坑把精力全花在 prompt 上不搭日志。等到出了问题没有任何痕迹能帮你复盘。一上来就配多智能体。两个 Agent 之间消息格式没对齐调试成本能让你崩溃。先做单 Agent跑通再加入角色。不设步数上限。曾经有个 Agent 在“确认文件是否已存在”这个判断上循环了二十几次最后账单比预期贵了十倍。忽略工具返回的异常信息。工具报错不是终点而是下一轮决策的输入。把报错透传给模型让它自己决定是换方案还是问用户。5.3 后续学习建议看完第一讲之后可以有两条线继续走一条是理论线把规划的几种模式、记忆的具体实现、评估体系的设计逐个吃透另一条是工程线选一个端到端项目持续迭代。比如从一个数据整理 Agent 开始加上评估集再加检查点再加人工确认闸门你会亲眼看到系统可靠性是怎么一层层堆起来的。我之前在实战中最大的体会是智能体系统的难点从不在“让模型听话”而在“让模型在没听到指令的时候也知道该怎么办”。第一讲最值钱的地方就是让你提前看到这个问题并且告诉你后面几周会一个个拆解它。现在回头看能把这一步想清楚后面的路都会顺很多。