斯坦福公开自我改进智能体课程：为什么你的 Agent 仍会崩溃

编者说明：本文根据 Addepalle Nikhil Varma 的文章 The $800k AI Skill Stanford Just Open-Sourced And Why Your Agents Still Crash 整理并扩展，并参考 Stanford CS329A 官方课程页与课程说明核对。需要澄清的是：Stanford 公开的是《Self‑Improving AI Agents》课程与讲座视频，不是一个标价 80 万美元的单独“AI 技能”；薪资数字是原文用于讨论高级 Agent 工程岗位价值的标题化表达。

Stanford 的 CS329A《自我改进 AI 智能体》课程公开视频上线后，科技社区很快把注意力放在了授课者背景、高薪岗位和“自我改进”这个极具吸引力的词上。

但看完一门免费课程，并不会自动修好你的生产系统。许多开发者回到 IDE 后，仍然在写同一种脆弱的 AI 包装器：用户输入一个提示词，模型生成一次答案，应用立刻把它交付出去。中间没有执行、检查、反馈、重试，也没有清楚的失败状态。

真正值得学习的不是某一句更聪明的提示词，而是如何把非确定性的模型，放进一个可验证、可恢复、有预算约束的软件系统里。

“80 万美元技能”的幻觉

高薪数字很容易让人误以为，构建自我改进系统需要某种只有顶尖实验室掌握的秘密能力。事实上，Stanford 官方课程介绍的主题都可以公开学习：constitutional AI、领域验证器、测试时计算、搜索与 LLM 结合、工具调用、检索、多步规划，以及 Agent 的评估与编排。

难点不在于概念是否公开，而在于能不能把这些概念实现成稳定系统。会调用一个大模型 API，和能设计一个在失败后诊断、修复并安全退出的 Agent，中间隔着传统软件工程的全部细节。

因此，高级 Agent 工程岗位真正购买的通常不是“提示词技巧”，而是状态机、评估系统、沙箱、可观测性、内存管理、路由与成本控制能力。薪资标题可以很夸张，工程要求却非常具体。

平铺式执行为什么注定会失败

设想你让一个编码 Agent 完成任务：“写一个 Python 脚本，抓取金融数据并保存为 CSV。”十秒后，它交付了两百行看起来很漂亮的代码。你一运行，程序立刻因为一个不存在的依赖而报错。

接下来，你复制错误信息、粘贴回聊天窗口，再要求模型修复。这个过程中，Agent 并不自主。你才是测试运行器、错误解析器和反馈循环。

这就是平铺式执行：

用户输入 → 模型生成 → 立即交付

它的问题不是提示词不够礼貌，也不是没有写“请逐步思考”。只要系统把第一次随机生成当成最终结果，任务越长、依赖越多、环境越复杂，失败概率就越会累积。

从训练时计算转向测试时计算

过去，行业主要通过更大的数据集、更多训练计算和更大的模型来提高能力。现在，另一条重要路线是测试时计算：模型在给出最终答案之前，获得更多时间、token、工具调用和反馈机会。

这并不意味着让模型无限“自言自语”。有效的测试时计算需要外部结构，例如生成多个候选、调用验证器、运行代码、搜索证据、比较结果，并根据可观察反馈决定下一步。

Stanford CS329A 的官方课程范围比一个简单反思循环更广，涵盖自我改进技术、验证器、搜索、工具使用、检索和编排。原文提出的“reflection circuit”可以看作这些思想在工程系统中的一种直观实现，而不是课程唯一指定的架构。

反思循环的三个核心节点

一个最小可用的反思循环通常包含三个职责分离的节点。

1. 生成器（Generator）

生成器接收任务、当前状态和已知约束，产出第一版方案。它可以写代码、拟定计划、生成查询，或者提出下一步工具调用。它的职责是推进任务，而不是证明自己已经正确。

2. 评估器（Evaluator）

评估器检查候选结果。对代码任务而言，最有价值的第一层评估往往不是另一次 LLM 调用，而是确定性工具：编译器、类型检查、单元测试、静态分析、安全扫描和实际运行。

代码应在隔离环境中执行，捕获退出码、标准输出、错误栈和资源使用。只有通过基础检查后，才需要让专门的 LLM 评估器审查边缘情况、需求遗漏、架构问题和安全风险。评估器最好只负责批评和打分，不同时承担重写，以减少角色混乱。

3. 路由器（Router）

路由器读取评估结果并选择状态转移：通过则交付；可修复则把结构化反馈送回生成器；缺少信息则向用户提问；风险过高则暂停并请求人工接管；超出预算则以明确失败状态结束。

draft = generate(task, state)
result = run_in_sandbox(draft)
review = evaluate(task, draft, result)

if review.passed:
    return verified_output(draft)
elif review.needs_user:
    return request_clarification(review.questions)
elif state.attempts >= MAX_ATTEMPTS:
    return controlled_failure(review)
else:
    return retry_with_feedback(review)

这里的关键不是循环本身，而是退出条件。没有最大尝试次数、时间限制、token 预算和人工升级路径的循环，只是把一次失败改造成更昂贵的无限失败。

确定性反馈比“再想一次”更有价值

让同一个模型评价自己的答案，有时能发现错误，但也可能重复同一种盲点。更可靠的做法是先寻找环境中可验证的信号。

模型最擅长处理模糊判断，程序最擅长检查明确规则。把两者放在正确的位置，通常比单纯更换更大的模型更有效。

上下文崩溃：循环越多，Agent 可能越糊涂

如果每次失败都把旧代码、完整错误日志、评审意见和新尝试继续追加到上下文，循环十次后，模型会被自己的历史错误淹没。窗口即使还没有达到硬性上限，有效注意力也可能已经下降。

原文建议使用动态记忆压缩：当尝试次数超过阈值，暂停执行，把历史浓缩成一份高密度状态摘要，例如：

尝试 A 因内存限制失败；尝试 B 依赖了环境中不存在的库；当前保留的有效发现是 X 和 Y；下一轮不得重复 A/B，应验证方案 C。

然后移除冗余轨迹，只保留任务目标、不可违反的约束、已验证事实、失败原因和下一步假设。这样能减少噪声，但压缩本身也可能丢失信息，所以关键状态最好使用结构化字段保存，而不是全部依赖自然语言摘要。

此外，“永远不会卡住”并不现实。生产系统必须承认三种结果：成功、可解释失败、等待人类输入。能够停止，是可靠性的组成部分。

一套更完整的生产反思回路

1. 定义验收标准：在生成之前明确什么算完成，哪些约束不可违反。
2. 建立状态机：把规划、执行、评估、修复、等待和终止设计为显式状态。
3. 隔离工具执行：代码和浏览器操作放进权限受限的沙箱，限制网络、文件和凭据。
4. 先跑确定性检查：能用测试和规则判断的内容，不浪费第二次模型调用。
5. 结构化错误：把失败归类成可重试、需要新信息、违反策略或不可恢复。
6. 控制重试预算：设置最大轮数、总时间、token、费用和工具调用上限。
7. 压缩长期记忆：保留事实与决策，删除重复日志和已经否定的草稿。
8. 提供人工接管：涉及登录、付款、删除、发布或高风险判断时让人确认。
9. 记录完整轨迹：为每次状态转移、工具调用、错误和费用留下可审计记录。
10. 用真实任务评估：统计成功率、人工介入次数、成本和失败分布，而不是只看演示。

为什么这种工程能力越来越值钱

如果一个工程师能通过评估、搜索、反馈和路由，让更便宜、更快的模型从低成功率提升到可用水平，价值不仅来自性能提升，还来自减少人工复核和失败返工。

但“从 40% 提升到 95%”这类数字必须针对具体任务、数据集和验收标准测量，不能作为通用承诺。不同任务的可验证性差异很大：有测试套件的代码任务容易形成闭环，开放式战略建议则很难自动判断“正确”。

Agent 工程正在回归软件工程的基本功：明确接口、管理状态、处理异常、隔离权限、监控成本、记录日志，并为不确定组件建立护栏。漂亮界面包住一次 API 调用，只能做演示；可靠系统必须为失败而设计。

结语

Stanford CS329A 值得关注，并不是因为它出售一项价值 80 万美元的秘密技能，而是因为它系统讨论了下一阶段 AI Agent 的关键问题：模型如何利用验证器、搜索、工具和环境反馈，在执行过程中改进自己。

如果你的 Agent 仍然经常崩溃，第一步通常不是继续润色提示词，而是画出完整执行图：结果在哪里被验证？失败如何分类？谁决定重试？上下文何时压缩？预算何时耗尽？什么情况必须交给人？

这些问题一旦有了明确答案，Agent 才从一次性生成器变成真正的工程系统。

延伸学习：Stanford CS329A 官方课程页；课程概览公开视频；测试时计算公开视频。

原文作者：Addepalle Nikhil Varma。阅读英文原文。本文为中文整理与扩展版本，并根据 Stanford 官方课程资料修正了标题性表述。