斯坦福CS329A实战：构建自改进AI Agents的评估闭环与工程方法

斯坦福 CS329A 2026 版本这次把核心命题放在了“自改进 AI Agents”。对正在做 Agent 工程的团队来说这门课真正值得关心的不是又多了一个概念而是一套可执行的闭环方法Agent 在完成生成之后如何评价自己的结果如何根据错误修正输出又如何靠评测集保证每一次改动不倒退。这篇文章会把课程里最容易被忽视的工程点拆开讲自改进 Agent 的能力边界、本地开发环境怎么搭、最小自改进循环怎么写、如何用接口 API 和批量任务做效果回归以及跑实验时最常见的坑。如果你正在设计 AI Agent 的评估体系或者准备把 Agent 从一个演示 Demo 推进到可复用流程这篇文章可以直接收藏。课程材料本身采用中英双语注释对中文开发者比较友好。读的时候建议不要停留在“看懂了”而是跟着“环境准备—最小实现—评测集回归—批量验证”的顺序真正跑一遍。下文会先给核心能力速览再逐步展开部署、代码、接口、性能和排错整体按可落地的工程路径组织。1. 核心能力速览在写具体操作之前先对这门课做一个整体画像。它不像普通的模型部署教程那样只教你怎么调一个 API而是把 AI Agent 当成一个需要持续迭代的工程系统来设计。项目/课程【中英双语】2026版首发斯坦福CS329A自改进AI Agents主题方向AI Agents、自改进闭环、工程化评估、工具调用教学特点中英双语标注强调可复现实验与工程化方法前置知识Python 基础、机器学习基础、大模型 API 或本地推理的基本使用关键知识点Agent 架构、工具调用、记忆管理、自我评估、反思重写、评测集回归硬件门槛不强制要求本地 GPU可调用云端 API本地部署时可灵活选择 CPU/GPU是否支持本地部署支持课程实验可以在本机用 Ollama 等推理服务跑通是否涉及 API涉及模型调用、批量评测、外部工具接口都会覆盖是否支持批量任务课程实验建议用批量评测来验证 Agent 效果本文会给出批量脚本思路适合人群AI 应用开发、算法工程师、Agent 产品负责人、机器学习爱好者从能力速览可以得出一个结论这门课的核心不是某一个模型有多强而是教你如何把 Agent 的“行为质量”纳入可控的迭代流程。这也是“自改进”真正的落点。所谓自改进并不是指模型权重在本地自动训练而是指 Agent 系统能够在一次任务结束后通过对结果进行评分、错误定位和改写让下一次输出更接近目标。这种能力必须建立在两件事上一个是可靠的评估标准另一个是稳定的执行循环。没有评估标准所谓改进只是随机重试没有执行循环改进也无从谈起。2. 适用场景与使用边界先确认这门课适合谁。如果你正在做 AI 客服、代码生成助手、数据分析 Agent、文档处理流水线或者任何需要“模型多次调用 外部工具”的任务课程里的自改进思路可以直接迁移。算法工程师可以用它来设计评测集后端工程师可以用它来规范 Agent 服务的接口结构产品经理也能借此理解 Agent 的能力边界和退化风险。它不适合什么人如果你只是想要一行代码调通用的聊天接口不需要复杂工具调用也不需要多轮评测这门课的学习成本可能偏高。课程更偏工程方法而不是单纯的 Prompt 技巧集锦。如果用一句话总结它不是教你把模型调出“更漂亮的回答”而是教你让一套 Agent 系统在多次任务中都保持稳定、可靠、可回归。使用边界必须说清楚。自改进 Agent 往往涉及自动执行代码、访问外部数据、调用第三方工具这会带来隐私、版权和操作风险。实验中如果使用真实业务数据要先确认数据脱敏和授权如果让 Agent 自动调用外部 API要控制调用频率和数据外发范围如果 Agent 涉及人脸、声音、身份信息等敏感内容必须严格遵守合规要求。课程实验建议在隔离的测试环境中进行不要在未经授权的情况下让 Agent 访问生产系统或他人数据。另外要区分“自改进”和“自主失控”。大多数课程实验中的自改进是有边界的最大执行轮数、评分阈值、人工确认机制、日志回放这些约束是系统安全的一部分。设计 Agent 时要给每一步改进留出终止条件而不是让它在失败后无限循环。3. 学习前置条件与环境准备开始课程实验之前建议先准备一套干净的环境。下面给出的是一套通用检查清单不依赖具体操作系统但路径和命令需要根据本机情况调整。3.1 环境检查清单检查项建议要求说明操作系统Windows 10/11、macOS、Linux 均可课程代码以 Python 为主跨平台问题较少Python3.10 或更高新版本对类型注解和异步支持更好包管理pip、venv 或 conda建议创建独立虚拟环境模型访问云端 API 或本地推理服务本地可用 Ollama、llama.cpp 等密钥管理不要硬编码到代码里使用.env文件或环境变量代码版本管理Git每次提示词或代码改动都要留记录磁盘空间本地模型按需预留量化模型一般几 GB 到十几 GB3.2 创建虚拟环境并安装依赖课程实验通常会用到 OpenAI SDK、Anthropic SDK、Pydantic、dotenv 这类基础库。如果是本地推理可以直接把 Ollama 暴露成 OpenAI 兼容接口这样上层代码不用区分云端还是本机。# 创建并激活虚拟环境 python -m venv .venv source .venv/bin/activate # Windows PowerShell 下使用: .venv\Scripts\Activate.ps1 # 升级 pip 并安装基础依赖 pip install --upgrade pip pip install openai anthropic python-dotenv pydantic3.3 配置模型访问如果需要使用云端模型在项目根目录创建.env文件填入 API 密钥。注意.env文件一定不要提交到 Git 仓库。OPENAI_API_KEYsk-xxxx ANTHROPIC_API_KEYsk-ant-xxxx BASE_URLhttps://api.openai.com/v1 MODEL_NAMEgpt-4o-mini如果没有云端密钥也可以用本机推理服务来跑通实验。以 Ollama 为例# 安装 ollama 后拉取一个 7B 量级模型具体模型名以官方仓库为准 ollama pull qwen2.5:7b ollama serveOllama 默认监听11434端口且提供兼容 OpenAI 的/v1/chat/completions接口。代码里只需要指定base_urlhttp://127.0.0.1:11434/v1和api_keyollama即可。这里要留意端口是否被占用如果11434被其他服务占用需要修改 Ollama 的监听端口。环境建议单独准备一个requirements.txt把已安装的依赖固定下来。课程实验迭代频繁依赖版本不一致往往会导致奇怪的问题。4. 自改进 Agent 的核心概念拆解要真正读懂课程先理解自改进 Agent 和普通 Prompt 调用的区别。普通 LLM 应用是“输入一段文本返回一段文本”Agent 则是在模型之外叠加了工具、记忆和循环控制。自改进又在 Agent 之上增加了一个评测与修正层。4.1 从工具调用到能力闭环一个基础 Agent 最少包含四个部分模型、工具、执行循环、记忆。模型负责理解和生成工具负责完成模型无法直接完成的操作执行循环负责调度多轮调用记忆负责保存与任务相关的中间状态。自改进 Agent 在这个基础上多了一个“评估器”。评估器不是简单判断回答好不好而是根据任务目标给出可量化的分数例如答案是否包含关键字段、代码能否通过测试、检索结果与问题是否相关。得分会反馈给生成器让它在下一轮改写时更明确地修正错误。4.2 最小自改进循环执行、评估、反思、重写课程里反复出现的一个流程可以用一段伪代码表示用户请求 - 规划 - 工具调用 - 观察结果 - 生成输出 ↑ | | v 日志记录 ------ 反思重写 ------ 评估打分每次运行都会产生一条轨迹包括模型思考、工具返回、评估得分和最终输出。自改进的关键在于这些轨迹不是用完即弃而是下一次迭代的输入。实际工程中最小实现通常是这样第 1 轮模型根据用户请求生成答案。评估根据答案质量和完整性打分。判断如果分数低于阈值进入反思阶段。反思让模型分析自己上一步哪里不满足要求。重写基于反思结果重新生成答案。再次评估直到分数达标或达到最大轮数。这种设计很像软件工程里的“测试驱动开发”。没有测试你无法判断重构是否引入了回归没有评估你也无法判断 Agent 的改动是否带来了真实提升。4.3 记忆与上下文管理自改进 Agent 对上下文管理的要求比普通聊天应用更高。每一轮反思都会把新信息追加到对话中如果长期不清理上下文很快会被历史消息塞满。常见的做法是滑动窗口加摘要压缩保留最近的 N 条消息把更早的对话压缩成摘要。对工具返回结果也要做截断避免超长 JSON 挤占上下文空间。4.4 评测集是自改进的回归测试课程里最值得借鉴的工程思维是把评测集当作 Agent 项目的“回归测试”。一组稳定的、覆盖典型任务的测试用例在每次修改 Prompt、系统提示或工具逻辑后都完整跑一遍用分数对比判断改动是正向还是负向。评测集不需要一开始就很大先准备 10 到 30 个代表性样本覆盖正常场景、边界场景和已知失败场景。每发现一个新问题就把它加入评测集。经过一段时间积累这套评测集会比任何人工主观评估都更有效地指导 Agent 迭代。5. 本地动手实验跑一个最小自改进 Agent下面给出一套可以直接复制运行的最小实验脚本。这里不依赖具体云端模型假设你已经在本地启动 Ollama 并暴露了 OpenAI 兼容接口。如果使用云端 API只需要修改base_url、api_key和model。5.1 定义模型调用和简单评估器from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama ) MODEL qwen2.5:7b MAX_ROUNDS 3 def call_llm(messages): response client.chat.completions.create( modelMODEL, messagesmessages, temperature0.3 ) return response.choices[0].message.content def evaluate(answer): # 演示用简单规则实际课程实验会换成更细致的评分模型 score 0 if len(answer) 80: score 1 if python in answer: score 1 if 缺失值 in answer: score 1 return score这里把评估器设计成规则判断只是为了快速跑通流程。真实实验中评估器完全可以用另一个模型、一套单元测试或是外部服务返回的结果。关键是让分数稳定、可复现。5.2 实现反思与重写反思阶段不是简单说“再试一次”而是让模型对比目标与当前回答指出具体差距。下面这条提示词展示了如何把错误信息反馈给模型。def reflect(question, current_answer, score, max_score): prompt f 你正在改进一个回答。任务要求已经给出。 当前回答得分是 {score}/{max_score}说明没有完全满足要求。 任务问题 {question} 当前回答 {current_answer} 请分析当前回答缺少了什么输出一个更完整、更可执行的版本。 回答中要包含关键步骤和可直接运行的 Python 代码。 return call_llm([{role: user, content: prompt}])5.3 执行自改进主循环question 用 Python 读取 CSV 文件并统计每一列的缺失值数量给出可运行的代码。 max_score 3 history [{role: user, content: question}] best_answer final_score 0 for step in range(MAX_ROUNDS): answer call_llm(history) score evaluate(answer) print(fround{step 1} score{score}/{max_score}) if score max_score: best_answer answer final_score score break # 未达标时把反思结果作为新一轮的输入 reflexion reflect(question, answer, score, max_score) history.append({role: user, content: reflexion}) final_score score print(best_score:, final_score) print(best_answer:) print(best_answer)运行这个脚本后你大概率会看到第一轮得分较低之后某一轮达到满分。这个现象就是“自改进”最直观的体现。要注意这里的“改进”不是模型权重变化而是通过外部评估反馈引导生成过程重新选择更合适的答案路径。这个实验的价值在于它展示了一个可解释、可控制的改进机制。你可以把规则评估器替换成代码测试、数据校验、人工反馈收集等任意外部信号Agent 就会朝着那个方向修正。本地验证时显存占用需以本机模型大小为准7B 量级模型的量化版本通常可以通过 Ollama 在普通消费级显卡上运行具体占用要观察nvidia-smi或 Ollama 的日志。6. 接口 API 与批量任务当 Agent 从单轮实验走向工程实践批量评测是必须做的一步。批量任务的核心不是简单地循环调用 API而是把输入、输出、得分、日志全部记录下来方便横向对比。课程实验里建议把测试集保存成 JSONL 文件每行一个样本。6.1 准备批量测试集{id: case_001, question: 用 Python 读取 CSV 文件并统计每一列的缺失值数量。, required: [缺失值]} {id: case_002, question: 把一行逗号分隔的文本解析成字典。, required: [split, dict]} {id: case_003, question: 写一个函数检查字符串是否为有效的电子邮件地址。, required: [, re]}这里用required字段记录答案中必须出现的关键词作为简单的评分依据。工程中可以替换为更复杂的校验函数。6.2 批量任务脚本模板批量脚本要处理三件事限制并发、记录结果、失败重试。下面这段示例用ThreadPoolExecutor控制并发避免一下子把本地显存或云端配额打满。import csv import json import time from concurrent.futures import ThreadPoolExecutor, as_completed def process_case(case): question case[question] history [{role: user, content: question}] answer call_llm(history) required case.get(required, []) score sum(1 for keyword in required if keyword in answer) return { id: case[id], question: question, answer: answer, score: score, status: success } def run_batch(input_path, output_path, max_workers4, retry2): with open(input_path, r, encodingutf-8) as f: cases [json.loads(line) for line in f if line.strip()] results [] for attempt in range(retry 1): pending [case for case in cases if case[id] not in {r[id] for r in results}] if not pending: break with ThreadPoolExecutor(max_workersmax_workers) as executor: future_map {executor.submit(process_case, case): case for case in pending} for future in as_completed(future_map): try: results.append(future.result()) except Exception as exc: print(fcase error: {exc}) with open(output_path, w, encodingutf-8) as f: for result in results: f.write(json.dumps(result, ensure_asciiFalse) \n) print(fbatch done: {len(results)} results)retry参数用于失败重试max_workers用于控制并发。本地 GPU 推理时并发数不宜过高否则会触发显存不足。这里建议第一次先设max_workers1跑通后再逐步提高。6.3 批量结果分析与回归批量任务跑完后要输出一份对比报告。最简单的方式是计算平均得分和失败率再按case_id对比上一次运行结果。如果某次 Prompt 改动让平均分上涨但某个核心用例分数下降这就是一次行为回归需要单独检查。python run_batch.py --input test_set.jsonl --output result_20260201.jsonl接口服务方面Agent 项目通常不会把批量脚本直接暴露给外部调用而是封装成一个独立服务。接口层负责接收任务、将任务写入队列、异步执行并回调查询结果。这种设计可以避免用户请求长时间阻塞。课程中提到的 Agent 接口能力在工程上可以理解为三个层次同步调用适合短任务异步任务队列适合长任务Webhook 回调适合需要结果推送的场景。7. 资源占用与性能观察自改进 Agent 的资源开销比单次模型调用高得多因为一次完整任务可能包含多轮生成、反思和工具调用。在跑课程实验时重点观察四个指标每轮模型调用的 Token 数、单次任务总延迟、并发状态下显存或 API 配额占用、失败重试次数。7.1 本地推理与云端 API 的取舍维度本地推理云端 API启动成本需要下载模型、准备 GPU只需要 API 密钥数据私密性数据不出本机数据会发送到服务方延迟受本机 GPU 性能影响受网络和排队影响显存限制模型规模受限大模型无本地显存压力成本主要是硬件电费按 Token 计费本地部署时显存占用需要按模型参数量和量化方式估算。以常见的 7B 量级模型为例FP16 精度加载权重大约需要 14GB 左右Q4 量化后大约在 4GB 到 6GB 之间这与模型实现、上下文长度和算子优化都有关系。判断显存是否够用最直接的办法是在推理过程中执行nvidia-smi -l 1观察显存变化。如果同时运行多个并发任务显存占用会成倍增加。这种情况下可以降低max_workers或者把模型换成更小的量化版本。云端 API 方面主要限制是每分钟请求数和 Token 配额需要根据响应头或错误信息动态调整并发。7.2 哪些参数会影响任务性能自改进 Agent 的性能消耗来自几个方向MAX_ROUNDS越大任务耗时越长Token 成本越高。工具返回的 JSON 越长上下文占用越大。并发数越高显存或 API 配额消耗越快。评估器越复杂单次任务额外增加的开销越高。降低资源占用最有效的方法不是换更小的模型而是减少无效轮次。设计自改进循环时要给每次反思设置明确目标避免模型在失败后反复生成近似答案。另一个优化思路是在评估阶段使用简单规则先行筛选规则判定明确不达标时才调用更昂贵的评估模型。8. 常见问题与排查方法下面是一份实际工程中容易出现的问题排查表课程实验里同样适用。问题现象可能原因排查方式解决方案自改进循环不收敛反思提示词没有给出明确差距打印每轮反思内容让反思输出具体缺失点增加示例API 调用返回 429并发过高或配额不足查看响应头中的 Retry-After指数退避重试降低 max_workers上下文超长历史消息和工具返回未截断统计 messages 总 Token 数滑动窗口摘要压缩限制工具字段本地模型显存不足模型文件过大或并发过高nvidia-smi 观察显存换量化模型降低并发减少 max_tokens批量任务卡住某条样本触发无限循环打印当前执行 case_id设置单样本超时和最大轮数输出质量不稳定评测集覆盖不足对比失败样本分布扩充边界用例加入人工抽检工具调用报错工具参数不符合接口规范打印工具入参和返回用 JSON Schema 校验参数同一个问题多次结果不一致温度设置过高重复运行同一输入降低 temperature固定 seed从表格中可以看出大多数问题都跟工程控制不足有关而不是模型能力不足。自改进 Agent 必须在循环边界、输入长度、工具调用格式等方面设置硬约束否则很容易出现不可控行为。这里再单独说一个常见误区很多人会把“自改进”理解为模型自动调整 Prompt。实际工程中更稳妥的做法是“离线反思、人工合并”。先让 Agent 在评测集上产生多轮结果再由人审阅哪些反思方向有效最后把有效的反思策略固化到系统提示词或 Agent 决策逻辑中。不要让 Agent 在每次线上请求里都无监督地改写自己的行为这种改动如果缺少日志和回滚机制风险很高。9. 最佳实践与使用建议从课程实验过渡到团队级项目有几个工程实践值得沉淀。第一把提示词、评测集和代码放在同一个 Git 仓库里。每次改动 Agent 行为都必须能追溯前后结果。提示词不是“写一次就完事”的文本它和代码一样需要版本管理。第二建立一套最小可运行配置。课程实验里建议保存一个不依赖云端密钥、可以用本地小模型跑通的配置文件例如使用 Ollama 加 7B 量化模型。这样新成员加入、环境迁移或 CI 回归时不需要申请云端额度就能验证改动。第三模型文件、输入素材、输出结果分目录管理。批量实验每天可能产生大量 JSONL 和日志文件命名里要包含日期、模型名、评测集版本防止后来分不清哪份结果对应哪次 Prompt。第四接口服务要限制访问范围。如果 Agent 需要对外提供 API建议用 Token 鉴权、IP 白名单或内网部署避免开放到公网后被滥用。对涉及敏感数据的请求要在输入侧做脱敏在输出侧做合规过滤。第五涉及人脸、声音、版权素材、私有数据等内容时必须确认授权边界。自改进 Agent 会自动生成大量输出这并不意味着这些输出可以随意传播。批量生成内容在发布或商用前必须做人工复核尤其是代码、法律意见、医疗建议等高风险领域。第六给 Agent 的自改进行为增加人工确认环节。并不是每一轮反思都适合自动采纳最好保留一个“提议 - 评审 - 合并 - 回归”的流程。对一个有实际用户的 Agent 系统来说稳定比单次惊艳更重要。10. 总结与下一步对学习者来说最先要验证的能力不是多复杂的多 Agent 协作而是把一个最小自改进循环跑通选择一个任务、构造 5 到 10 个评测样本、让 Agent 在评测集上迭代三轮、记录分数变化。这个闭环打通之后再逐步加入工具调用、记忆管理和批量任务就能比较清楚地理解 CS329A 课程的工程主线。最容易踩的坑有两个一是把评估器做得过于主观导致每次得分都不稳定二是让自改进循环自由运行缺少最大轮数和人工确认。规避这两个坑课程里的自改进方法就能安全落地到实际项目。下一步可以沿着两个方向扩展把评估器从规则升级成模型评分或单元测试让反馈信号更贴近真实任务把批量评测接入 CI 流程让每次提示词或代码变更都自动跑回归。这门课的价值不在于告诉你某个模型很厉害而在于提供一套让 Agent 越用越可靠的系统方法。看完文章之后建议先动手把最小循环跑通再回头对照课程材料理解细节。