斯坦福CS329A 2026版：自改进AI Agents系统化工程实践

斯坦福 CS329A 在很多工程同学里是“机器学习系统”的代名词。这次 2026 版首发把主线切到自改进 AI Agents，准确说是 Self-Improving AI Agents。这个转向比想象中更值得研究：它把 Agent 从“每次调用模型拿一个结果”升级成“一个能根据结果反馈自动修正自身策略的闭环系统”。对做工程的人来说，这才是大模型应用能稳定落地的关键。

课程核心不是某个魔法提示词，而是一套可验证的闭环：生成（Generate）→ 执行（Execute）→ 评估（Evaluate）→ 优化（Improve）。Agent 不再是一次性调 API，而是自己看结果、找错误、改策略、再跑一轮。整个课程会涉及模型推理、工具调用、记忆管理、评测集设计、微调、部署和成本控制，本质上是在教你怎么把 Agent 当作软件系统来做。

这篇文章会做三件事：第一，把 2026 版 CS329A 围绕自改进 Agent 的核心模块拆开；第二，给出一套可以在本地环境跑起来的 Agent 实验模板，包括批量任务和 API 封装；第三，整理常见坑和工程规范，方便你直接迁移到自己的项目。为了照顾中英双语阅读习惯，文中会保留关键英文术语，并在后面附一张对照表。适合正在做 Agent 开发的工程师、需要给团队设计 Agent 评测体系的算法同学，以及想补机器学习系统知识的同学。

1. 核心能力速览

对一门课程来说，所谓核心能力不是“能生成多好看的效果”，而是实验结束后你能带走什么。2026 版 CS329A 的核心能力可以拆成三块：系统视角的 Agent 设计、可量化评估的自改进循环、以及部署运维工程化能力。下面用一个表格快速对齐。

从这套能力边界能看出来，这门课对动手能力有硬性要求。你能写 Python、能调接口、能用 Git 管理配置，学习体验会顺畅很多。如果只是想了解概念，读公开讲义就够了；但如果要真正吸收课程内容，必须把“自改进循环”在本地跑一遍。

2. 课程拆解：自改进 Agent 系统涉及哪些模块

2.1 自改进 Agent 的最小闭环

先明确一个容易混淆的点：自改进（Self-Improving）不等于让模型无限次重试。它指的是 Agent 在完成任务的过程中，能够根据执行结果、评测指标或外部反馈，主动调整自己的输出策略、提示词、记忆内容，甚至工具选择方式。

一套最小的自改进闭环包含四个环节：

• Generate：Agent 根据当前任务和上下文调用大模型，生成回答或候选动作。
• Execute：在需要真实反馈的场景中执行代码、查询数据库、调用工具，或者至少在沙箱里跑一次验证。
• Evaluate：用规则、测试用例、小型评测模型或人工反馈判断输出质量。
• Improve：把评估结果写回提示词、记忆库或配置项，然后进入下一轮。

这个闭环可以发生在单次任务内，也可以跨任务沉淀。短周期改进是“这轮代码报错了，下轮修正”；长周期改进是“这批任务里，包含边界条件的代码更容易通过测试，以后遇到类似任务要优先补充边界条件”。2026 版 CS329A 更强调后者：把 Agent 当成一个可观测、可测试、可迭代的系统，而不是黑盒调用。

2.2 中英术语对照表

由于课程材料和论文多为英文，我把高频术语整理成一张表，方便后续阅读时对照。

建议把这张表存到自己的笔记里。后续看讲义、看论文、找开源代码时，按这组术语去检索，效率会高很多。

2.3 适用场景与使用边界

从自改进 Agent 的特性看，比较适合这几类场景：

• 代码生成：能通过编译、单测、静态检查得到明确反馈，天然适合自动迭代。
• 数据处理：清洗、抽取、格式转换等任务，可以用规则做校验，让 Agent 反复修正。
• 客服问答：根据用户反馈和知识库命中情况，持续优化回答口径。
• 研究助手：帮研究者读论文、整理综述时，人工反馈可以作为评估信号。
• 自动化报告：生成初稿后，由人工审核并给出修改意见，Agent 再更新内容。

需要明确的是，自改进机制并不适合所有场景。医疗、法律、金融等高风险决策，如果 Agent 自动改进后直接对外输出，会造成不可控影响。生产系统变更、资金操作、账号相关操作也不应该让 Agent 无审批执行。另外，涉及用户数据、声音、人脸、版权素材的场景，必须在获得授权、符合隐私规范的范围内使用，不能为了“改进效果”随意采集数据。

3. 学习环境与前置条件

3.1 环境清单

虽然 CS329A 是课程而不是商业软件，但要做实验，环境仍然要提前准备好。下面给出一套比较稳妥的本地实验环境配置。

这里不写死某个驱动版本或 CUDA 版本，因为不同显卡、不同模型对版本要求不一样。更稳妥的做法是，先装好 PyTorch 或对应的推理框架，再用nvidia-smi看驱动支持的 CUDA 版本，最后按官方文档选择安装命令。

3.2 要掌握的 Python 与系统知识

课程并不是从零教 Python，所以前置基础要提前补。建议至少具备这些能力：

• Python 基础语法、虚拟环境、装饰器、异常处理。
• JSON / YAML 配置文件的读写。
• HTTP API 调用，理解请求头、超时、状态码。
• 基本的 Git 操作，包括分支、提交、回滚。
• Linux 常用命令，比如查看进程、端口、日志。
• 对机器学习基础概念有了解，包括训练集、测试集、过拟合、评估指标。

如果之前没写过 Agent，先跑通一个最简单的 OpenAI 兼容接口调用即可。不需要一开始就啃复杂的 Agent 框架。

3.3 模型选择：API 还是本地部署

做自改进 Agent 实验，有两种模型接入方式。

第一种是调用云端 API。优点是上手快、显存门槛低、模型能力强；缺点是有成本，而且批量任务和长上下文会明显增加 token 消耗。第二种是本地部署模型，比如用 Ollama、vLLM 或 llama.cpp 加载开源模型。优点是数据不出本机、单次调用成本低；缺点是需要显卡资源，模型效果和显存占用需要实测。

我的建议是：课程前期以 API 为主，先把闭环跑通；到了批量评测、成本敏感或需要私有数据处理的阶段，再切本地部署。如果本机只有 8G 左右显存，可以优先尝试 7B 到 14B 规模的量化模型，实际显存占用要以你下载的模型版本和推理参数量为准。

4. 本地实验：把课程自改进思路跑起来

课程讲义里的很多 idea，只有在代码里跑一遍才能变成手感。下面给一个最小 Agent 实验室模板。它不绑定某一家云厂商，可以接本地模型，也可以接任何 OpenAI 兼容接口。

4.1 项目结构

建议先建一个干净的项目目录，方便后续扩展。

agent_lab/ ├── config.yaml ├── prompts/ │ └── system.md ├── src/ │ ├── agent.py │ ├── evaluate.py │ └── serve.py ├── data/ │ ├── tasks.json │ └── results/ └── requirements.txt

config.yaml放模型地址、模型名称、最大轮数等配置；prompts/system.md放系统提示词；src/agent.py写 Agent 主逻辑；src/evaluate.py写评估函数；src/serve.py用 FastAPI 暴露接口；data/tasks.json放批量任务。

4.2 环境准备

在项目根目录创建虚拟环境，并安装依赖。

python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install openai fastapi uvicorn requests pyyaml

这里用openai库主要是因为它支持 OpenAI 兼容接口，可以同时接云端服务和本地推理服务。先不引入太重型的 Agent 框架，方便把自改进循环的逻辑看明白。

4.3 本地模型服务启动

如果要用本地模型，先启动本地推理服务。这里以 Ollama 为例：

ollama serve ollama run qwen2.5:7b

如果 Ollama 已经跑在 11434 端口，src/agent.py里可以直接连http://127.0.0.1:11434/v1。换成 vLLM 或其他兼容服务也同理，只需要改base_url和model。如果直接用云端 API，跳过这一步。

4.4 最小调用脚本

创建一个src/agent.py，先只做单轮生成，确保接口通了再往上加逻辑。

import os from openai import OpenAI BASE_URL = os.getenv("LLM_BASE_URL", "http://127.0.0.1:11434/v1") MODEL_NAME = os.getenv("LLM_MODEL", "qwen2.5:7b") client = OpenAI(base_url=BASE_URL, api_key="local") def generate(prompt: str, feedback: str = "") -> str: messages = [ {"role": "system", "content": "你是一名严谨的 AI 工程师 Agent。"}, {"role": "user", "content": prompt}, ] if feedback: messages.append( {"role": "user", "content": f"上一轮给出的改进建议：{feedback}。请根据建议重写输出。"} ) resp = client.chat.completions.create( model=MODEL_NAME, messages=messages, temperature=0.7, ) return resp.choices[0].message.content if __name__ == "__main__": text = generate("用 Python 写一个快速排序函数") print(text)

先运行这一步，确认模型能返回结果。如果报连接错误，优先检查本地服务端口和MODEL_NAME。

5. 功能测试与效果验证

启动脚本只是起点。要验证自改进是否有效，必须有输出、有评估、有迭代。

5.1 单轮生成测试

测试目的：确认 Agent 在没有反馈的情况下，具备基础任务完成能力。

操作步骤：

1. 运行src/agent.py。
2. 输入任务提示词，例如“用 Python 写一个快速排序函数”。
3. 检查返回内容是否包含完整代码。
4. 如果输出为空，排查模型名称、接口地址和温度参数；如果输出过短，调整系统提示词。

单轮通过只能说明模型本身能力还行，不能说明 Agent 有自改进能力。下一步需要加上评估和迭代。

5.2 增加评估与改进循环

先写一个简单的评估函数，判断输出是否符合任务要求。

def check_output(text: str) -> str: if "def quicksort" in text: return "通过" if "def " not in text: return "缺少函数定义，需要补全代码" return "已有函数定义但不符合要求，请检查边界条件"

再把生成和评估组合成循环。

def run_agent(prompt: str, max_rounds: int = 3): feedback = "" text = "" for i in range(max_rounds): text = generate(prompt, feedback) feedback = check_output(text) print(f"第 {i + 1} 轮: {feedback}") if feedback == "通过": return {"round": i + 1, "text": text, "status": "ok"} return {"round": max_rounds, "text": text, "status": "max_rounds"} if __name__ == "__main__": result = run_agent("用 Python 写一个快速排序函数", max_rounds=3) print(result["status"], result["round"])

这样做的重点不是让模型“多试几次”，而是把上一轮的评估结果作为下一轮的输入。实际课程项目里，评估器会比这复杂得多，可能是单元测试、代码覆盖率、用户打分或者一个专用评测模型。但循环结构是类似的。

5.3 测试矩阵与成功标准

建议用一张测试矩阵来管理验证过程，避免只靠一两个例子判断效果。

判断标准要尽量客观。比如代码生成任务，以“是否能通过预置单元测试”为准，而不是“看起来像不像”。评估信号稳定，自改进循环才有意义。

6. 接口 API 与批量任务

课程项目做到后期，Agent 通常要以服务形式被使用。这里用 FastAPI 包一层轻量接口，然后写批量调用脚本。

6.1 FastAPI 服务

在src/serve.py中写一个 POST 接口。

from fastapi import FastAPI from pydantic import BaseModel from agent import run_agent app = FastAPI() class AgentReq(BaseModel): prompt: str max_rounds: int = 3 @app.post("/agent/generate") def agent_generate(req: AgentReq): result = run_agent(req.prompt, req.max_rounds) return result

启动服务：

uvicorn src.serve:app --host 127.0.0.1 --port 8000

注意from agent import run_agent需要保证src目录在 Python 路径中，或者把serve.py放到和agent.py同级目录。

6.2 curl 调用示例

服务启动后，用 curl 验证接口。

curl -X POST http://127.0.0.1:8000/agent/generate \ -H "Content-Type: application/json" \ -d '{"prompt": "写一个 Python 快速排序函数", "max_rounds": 3}'

返回结果会包含round、text、status三个字段。status为ok表示在限定轮数内通过了评估，max_rounds表示达到最大轮数但未通过。

6.3 批量任务脚本

批量任务的核心诉求是：输入一批任务，逐个调用 Agent，把结果保存下来。下面给出一个带失败捕获的脚本。

import json import time import requests def load_tasks(path: str): with open(path, "r", encoding="utf-8") as f: return json.load(f) def run_batch(tasks_path: str, output_dir: str): tasks = load_tasks(tasks_path) for idx, task in enumerate(tasks): try: resp = requests.post( "http://127.0.0.1:8000/agent/generate", json={"prompt": task["prompt"], "max_rounds": 3}, timeout=180, ) resp.raise_for_status() result = resp.json() output_path = f"{output_dir}/task_{idx}.json" with open(output_path, "w", encoding="utf-8") as f: json.dump(result, f, ensure_ascii=False, indent=2) print(f"task {idx} ok") except Exception as e: print(f"task {idx} failed: {e}") time.sleep(1) if __name__ == "__main__": run_batch("data/tasks.json", "data/results")

批量任务设计上要注意三点：

• 失败重试：调用接口可能因为限流、超时失败，建议对单条任务加最多 3 次重试，重试间隔递增。
• 结果落盘：每个任务单独一个 JSON 文件，避免一个任务失败导致整批结果丢失。
• 日志记录：记录每个任务的开始时间、轮数、状态和耗时，方便后续分析。

7. 资源占用与性能观察

在 B 站技术视频里，大家最关心显存占用和能不能跑得动。在 CSDN 博客上，我会把这个问题拆成可操作方法。

7.1 本地模型的资源观察

如果 Agent 走本地模型，观察资源最直接的方法是：

nvidia-smi -l 2

这条命令每 2 秒刷新一次 GPU 状态，可以看到显存占用、利用率、温度和功耗。如果不想一直刷屏，也可以只执行一次：

nvidia-smi

要注意观察两个时间点：Agent 请求发起时和 Agent 生成回复时。有的框架会在请求前加载模型，导致显存突然上涨；有的框架会把模型常驻显存，占用从头到尾不变。

7.2 影响资源占用的关键因素

自改进 Agent 的资源占用，不只是模型大小决定的，下面这些因素同样重要：

• 模型参数量和量化精度：7B 模型和 70B 模型显存差距巨大。
• 上下文长度：每轮反思都会把历史信息放进上下文，上下文越长，KV Cache 占用越高。
• 最大轮数：轮数越多，token 消耗越高，生成时间越长。
• 批量并发数：多个请求同时打进来，显存和内存占用会叠加。
• 是否保存中间结果：如果每轮都记录完整输出，磁盘和内存占用也会上升。

如果发现显存不够，常见的降载方法包括：换更小的模型、减少最大轮数、限制历史反馈只保留最近一轮、降低并发数、使用更短的提示词。对 API 模式而言，重点则要从显存转移到 token 消耗和接口延迟上。

7.3 API 模式的成本观察

云端 API 模式下，每一次自改进循环都会产生多轮调用。假设一个任务最多 3 轮，每轮平均 500 个输入 token 和 300 个输出 token，那么一次任务大约消耗 2400 个 token。批量任务跑 100 条，就是 24 万 token。所以建议把每次调用的usage字段记到日志里，按任务统计成本。

用一个最简单的办法：在generate函数里打印 token 使用量。

resp = client.chat.completions.create( model=MODEL_NAME, messages=messages, temperature=0.7, ) print(resp.usage)

观察几个任务后，你就能估算出批量任务的成本曲线。这样比事后再看账单要可控得多。

8. 常见问题与排查方法

下面把自改进 Agent 实验里最常见的坑整理成一张表，方便快速定位。

排查问题要记住一个原则：先把“评估器”和“模型生成”分开。如果评估器不稳定，Agent 再怎么改进，都只是在追逐一个错误目标。先用手工样本验证评估规则，再跑自改进循环。

9. 最佳实践与使用建议

9.1 先把评测集建好

自改进 Agent 最容易犯的错误，是没有评测集就开始调提示词。没有评测集，你无法判断改动是变好还是变坏。建议维护一份至少 20 到 50 条任务的评测集，任务难度要有区分，覆盖正常场景、边界条件、异常输入。每次改动后，在评测集上跑一遍再决定是否保留。

9.2 配置、提示词和结果都要版本化

自改进会频繁修改提示词、记忆内容和参数。如果不用 Git 管理，很容易出现“效果变好了但不知道改了什么”的情况。建议把系统提示词、评估规则、任务列表、结果文件都纳入版本管理。每次实验记录一条 commit，描述改动点和观测结果。

9.3 自改进也要有护栏

“自改进”不代表让 Agent 无限制修改自身系统。在工程落地时，要明确 Agent 能改什么、不能改什么。

• 提示词和记忆库可以自动更新，但要保留历史版本。
• 核心系统配置不允许 Agent 直接修改。
• 对外发布内容必须有人工审核环节。
• 涉及用户数据、版权素材、人脸、声音的，必须先确认授权范围和合规要求。

这些边界不是限制 Agent 能力，而是保证系统在出问题时可以回滚、可以追责。

9.4 从最小闭环开始扩展

第一次实验不要做太复杂。先让 Agent 在代码生成或文本改写任务上跑通“生成 → 评估 → 修正”循环，再逐步加记忆、工具调用、微调。每一步都留观测点，比如显存、token 消耗、轮数、通过率。这样定位问题会容易很多。

10. 总结与下一步

2026 版 CS329A 真正值得学的，不是某个具体模型，而是给 Agent 装上反馈闭环的系统方法。你要是想试，最建议先跑一个 3 轮反思的代码生成任务：第一轮看基础能力，第二轮看反馈是否被正确吸收，第三轮看输出是否稳定。

最容易踩的坑有两个：一是没有评测标准就开始调提示词，二是让自改进逻辑直接改生产配置，完全不设审批。前者会让改进方向失真，后者会带来安全风险。

下一步可以尝试：把人工反馈汇入记忆，增加工具调用，把评测集做成回归测试，最后把接口服务接到团队内部系统。建议先把这篇文章里的实验模板跑通，再回到课程讲义补系统知识，效率会比顺着视频顺序刷高很多。