斯坦福 CS329A 自我改进 AI 智能体 · 第 1 讲：课程总览

斯坦福 CS329A 的开篇课将三个容易混淆的发展连在一起：规模更大的预训练语言模型、推理时更强的思考能力，以及能够在环境中行动的智能体。贯穿其中的问题是，系统如何取得有用反馈，并把反馈转化成更好的行为。

一个模型偶尔给出好答案，并不自动成为智能体。智能体需要目标、动作、观察、纠偏方式，以及何时停止或承认无法完成的判断。课程把这些能力作为研究对象，而不是给任何工作流贴上“自主”的标签。

导论的价值也在于保留难题：生成候选可能比认出正确候选容易，学习出来的评判器可能不可靠，而一个有希望的改进循环不等于无限进步的证明。课程正是围绕这些缺口安排研究议题。

讲者先回顾历史上的规模效应：在展示的语言模型研究中，增加计算、训练数据和参数量，会降低测试损失。更大的模型还表现出跨任务的有用行为，让人不必为每个任务单独微调，就能较快做出原型。

零样本提示提供任务指令，少样本提示则再加入期望输入输出形式的例子。课程用翻译作直观说明。这些例子位于提示中，本身并不会更新模型权重。

历史图表应放在课程的语境里理解。有些模型规模来自估计，讲者也明确说过一张幻灯片已有些过时。论点不需要把专有模型的参数估计写成官方披露，也不需要把过去的规模门槛当成当下所有模型的通则。

思维链示例问：Roger 原有五个网球，又买了两罐、每罐三个，现在共有多少？只展示答案的示例给出十一；展示过程的示例还写出中间关系：二乘三等于六，五加六等于十一。

重点在于，模型可以在解决另一个问题时利用示范的方法。讲者讨论了早期实验里效果如何随模型规模变化，再把这段历史与接受专门训练、能够分析、分解和重新审视问题的推理模型联系起来。

他们随后澄清，能力的发现与有意训练可以同时成立。早期提示暴露了有用的推理行为，后来的推理模型又被训练得更善于使用这些行为。但这不证明每段可见解释都忠实呈现内部计算，也不意味着要求“多想一想”就能保证正确。

课程区分了下一词元预训练，与之后塑造指令遵循和偏好表现的阶段。精选的微调数据、指令与答案配对，可以教给模型有用的回应模式；这些例子的质量和覆盖范围，会影响最终系统的能力。

RLHF 则构造另一种反馈。人对回答进行比较或评分，奖励模型从偏好中学习，再通过优化让语言模型倾向于得到更高奖励的回答。正确性、帮助程度、具体性和无害性，可以分别成为不同目标。

机制本身也暴露了局限：奖励是选定的信号，不是“所有人类价值已经解决”的宣告。讲者明确把对齐称为持续存在的问题。系统行为取决于收集了什么反馈、如何权衡各个维度，以及学到的奖励是否真正代表目标。

在 Large Language Monkeys 的例子中，固定的模型多次接收同一个问题，生成不同候选。接下来还需要验证器或选择机制，决定最终返回哪一个。代码测试是课程举出的反馈来源之一。

图中的覆盖率，指的是至少有一个采样答案正确的问题占比。即使单次采样表现不佳，增加采样次数也可能提高这一比例。讲者还指出，某道难题的几千个候选中，可能只有少数正确。

这个区分非常关键：知道一大堆候选里存在正确答案，与部署一个能可靠找到它的系统，是不同的事情。近似理想选择条件下的覆盖结果，描述的是好选择器可能利用的潜力，不能悄悄替换成真正交付给用户的答案准确率。

多个候选可以并行生成，但并行不会消除计算成本。课程区分了延迟与总资源消耗，并指出取舍会随问题类型和难度变化。

多样性也很重要。温度可以鼓励模型生成不同结果，但无限提高最终会产生无法使用的内容。讨论里提及的某个数值设置，只是当时语境下的例子，不是普适调参规则。

有学生问，采样数量能否依难度变化。讲者将奖励引导的继续采样作为一个研究方向讨论。问题不只是“还能负担多少次调用”，还包括新增计算是否有合理机会产生、并识别出更好的解答。

推理时扩展保持模型参数不变，将更多计算用于生成或改进回答。课程接着讨论：收集有用输出，依据反馈筛选，再将其作为后续微调的合成数据。

这样可以把搜索与学习连接起来，同时不把两种操作混为一谈。生成候选本身不会更新权重；独立的训练过程，则可能让模型之后更经常地给出好答案。

讲者将重复采样覆盖率，与推理模型展示的单次回答成功率提升作区分。他们也承认，强化学习是在释放既有能力，还是增加能力，两者各占多少，仍有争议。这个反馈循环是研究机会，不是无限递归改进的既定证明。

从聊天机器人走向智能体，需要加入面向目标的循环。系统规划动作，与工具或环境交互，观察反馈，再调整下一步。记忆则帮助它在多个步骤之间保留正在完成什么。

43:10查看原图

课程将其与静态的智能体工作流区分。人可以预先画好调用、评判器与汇总器构成的图；更开放的智能体则在执行中决定更多路径。两者都可能有用，但人工搭建的调用图不应被误写成不受限制的自主性。

停止也是设计的一部分。系统可能完成目标，也可能报告无法完成。因此，澄清用户意图、确定什么才算完成，并非可有可无的礼节：它们会影响检查哪些文件、采取哪些动作，以及什么反馈足以证明成功。

导论列出了一些反复出现的模式：提示链连接子任务，路由依据输入选择路径，并行工作在汇总前拆分或重复尝试，编排器则规划后续调用。评判器或批评器可以在多个位置提供反馈。

如果任务领域支持检查，验证器会承担更具体的角色。运行代码测试带来执行反馈，询问另一个语言模型则提供学习出来的评价。这两类信号不应被当成可以互换的保证。

即使代码测试，也只覆盖实际检查的行为。更好的生成测试可能加强编程循环，薄弱测试却可能无法缩小生成与验证之间的缺口。课程反复回到稳健验证这个瓶颈，尤其是人工判断昂贵、又没有简单规则定义正确性的领域。

课程以代码迁移、数据清理、客服辅助和研究报告为例，说明智能体可能帮助完成的工作。它们各自需要不同的完成信号：测试、相关记录、来源覆盖或人工评估。某一场景的能力，不能自动替另一场景背书。

科研头脑风暴尤其能说明边界。模型可能提出研究者平常不会想到的想法，也可能产生幻觉。生成更多想法，不等于验证实验，更不等于建立科学结论。

课程项目要求体现了同一标准：学生需要提出问题或假设，设计实验，分析改进或可靠性，而不仅是写一篇综述、拼出一个应用。归档中的教学安排属于录制时课程，不是当前选课建议。更持久的经验是，让所声称的改进足够可测，才能在失败时发现它。