AI Agent 是当前以大模型为核心的工程热点而斯坦福 CS329A 这门课更进一步把目标从“会调用工具”提升到“能从自身经验中改进能力”。自改进不是给模型多调几次 prompt而是让 Agent 在完成任务的循环里记录轨迹、检验结果、修正策略最终让同样的任务做得更好。本文围绕 CS329A 的课程主线先讲清楚自改进 Agent 与传统程序的区别再给出可复现的最小实现思路最后补充排查路径和实战建议。这门课适合三类人已经在做 RAG、工具调用或自动化流程的工程师想从“调接口”升级到“设计闭环系统”的研究者以及准备系统学习 Agent 工程化的学生。读完本文你会得到一张完整的自改进 Agent 技术地图包括模块划分、代码骨架、评估方法、常见坑和可落地的检查清单。1. 先理解“自改进 AI Agent”到底在解决什么问题1.1 自改进 Agent 和普通程序有什么不同普通程序是“输入 - 固定逻辑 - 输出”。无论运行多少次只要输入相同输出就几乎不变。Agent 的本质区别在于它会根据当前环境状态选择动作而自改进 Agent 还会在动作结束之后反思这次为什么做对了为什么做错了下次怎样更少走弯路。CS329A 这门课程把“自改进”拆成了三层第一层是记忆。Agent 需要保存历史轨迹而不是每次任务都从零开始。第二层是反思。Agent 需要根据结果反馈生成经验总结。第三层是策略更新。Agent 把反思后的经验变成新的 prompt、参数、或工具选择规则用于下一次任务。这三层缺一不可。只有记忆没有反思数据会堆积但不会变成能力只有反思没有策略更新总结只是一堆文本只有策略更新没有验证机制模型会越改越偏。1.2 为什么“自改进”不能靠堆 Prompt 实现很多人会问自改进是不是把错误案例写进 system prompt 就行这种做法有效但不可持续。Prompt 长度有限错误案例会越来越多而且不同任务之间的经验可能互相冲突。更系统的做法是把自改进看成一个闭环采样轨迹用评估器打分从高分和低分轨迹中提炼规则再通过微调或外部知识库更新策略。CS329A 强调的正是这个闭环。它要求开发者先定义“好”和“坏”再让 Agent 在试错中逐步靠近“好”的标准。1.3 CS329A 的课程主线从能力边界到自我强化从课程主题看CS329A 讨论的不只是“怎么让 Agent 能写代码”或“怎么让 Agent 能查文档”而是“如何让 Agent 在多次执行中自动发现自己的能力边界并针对短板进行强化”。一个典型路径是给出一个目标函数例如任务成功率。Agent 执行一组任务收集日志和结果。评估器判断哪些步骤失败并给出失败标签。Agent 根据失败标签调整工具使用顺序、prompt 描述或模型参数。再次执行同样任务对比成功率。这条路径和机器学习训练流程很像区别在于 Agent 的状态空间、动作空间和反馈信号都更复杂。这也是为什么学 CS329A 之前最好已经掌握 Python、基础机器学习和大模型 API 调用。2. 围绕课程主题搭建可复现的学习环境2.1 环境准备和依赖版本建议学习 CS329A 不需要一开始就上生产级分布式系统。一个能在本地跑通的最小环境足够理解核心逻辑。建议使用 Python 3.10 以上版本并安装以下依赖transformers用于加载本地或远程大模型。torch或tensorflow作为模型后端。openai或类似 SDK用于调用云端模型服务。pydantic用于定义结构化输出和评估结果。pytest用于测试 Agent 的每个模块。如果原始课程环境没有明确给出版本落地前需要确认依赖版本兼容性。示例操作如下python -m venv venv source venv/bin/activate pip install --upgrade pip pip install transformers torch openai pydantic pytest这里把transformers和openai同时安装是因为学习时可能需要在本地小模型和云端大模型之间切换。pydantic用来约束 Agent 返回的数据结构评估器依靠它判断结果是否有缺失字段。2.2 最小 Agent 框架模型、工具、循环下面用一个非常小的示例说明 Agent 的基本组成。这里假设call_llm是封装好的模型调用函数get_weather是工具实际使用时可以换成自己的 API。# agent_base.py from typing import Callable, Dict, List def call_llm(messages: List[Dict[str, str]]) - str: # 这里实现模型调用返回文本 raise NotImplementedError def get_weather(city: str) - str: # 模拟天气查询工具 return f{city} 晴25 度 class MinimalAgent: def __init__(self, tools: Dict[str, Callable]): self.tools tools self.history [] def run(self, user_input: str) - str: messages [ {role: system, content: 你是一个智能助理可以调用工具获取实时信息。}, {role: user, content: user_input}, ] response call_llm(messages) self.history.append({input: user_input, output: response}) return response这个 Agent 只有“调用模型”和“记录历史”两个能力还没有自改进。自改进要在这个基础上增加评估和优化模块。先跑通这个最小闭环再逐步扩展是 CS329A 推荐的实践顺序。2.3 为什么需要评估器而不是只看“模型回答好不好”普通聊天场景中人可以主观判断回答质量。自改进 Agent 面对的是批量任务不可能每次都人工打分需要使用评估器自动计算指标。评估器可以很简单也可以很复杂。简单评估器检查结构化输出是否包含关键字段复杂评估器会把答案和标准答案做语义相似度计算或者用另一个模型做裁判。CS329A 关注的重点之一是“评估信号的质量”因为自改进算法最终要优化评估器给出的分数如果分数不可靠策略更新就会跑偏。以下是评估器的最小实现# evaluator.py from typing import Dict class SimpleEvaluator: def __init__(self, required_fields: list): self.required_fields required_fields def evaluate(self, output: Dict) - Dict: missing [f for f in self.required_fields if f not in output] score 1.0 if not missing else 0.0 return { score: score, missing_fields: missing, passed: score 1.0, }这个评估器只检查字段是否完整适合学习阶段。真实项目还需要检查字段值是否合法、是否和上下文一致、计算过程是否正确等。3. 自改进 Agent 的三个核心模块记忆、反思、策略更新3.1 记忆模块从“每次从头开始”到“带着经验工作”自改进 Agent 的记忆可以分为两类。短期记忆指当前任务执行过程中的上下文例如已经调用过的工具、已经得到的中间结果。长期记忆指跨任务的经验例如某个任务类型常见的失败模式、某类 prompt 的改进记录。实现时建议用统一的Trajectory结构保存记忆。每一次任务执行都记录输入意图Agent 的每一步动作工具返回结果最终答案评估器打分和错误标签保存到 JSON 或 SQLite 都可以。CS329A 里强调“轨迹是自改进的燃料”因为后续所有反思和策略更新都基于轨迹而不是基于零散印象。3.2 反思模块把轨迹变成可执行的修改建议反思不是让 Agent 写一句“我错了”而是从错误轨迹中找出可以复用的规律。例如一个 Agent 在查询天气时总是先问用户城市名再调用工具。如果轨迹显示用户已经说了“北京天气如何”那 Agent 还反问就显得多余。反思模块要做的是从失败轨迹中定位关键步骤。对比成功轨迹和失败轨迹的差异。输出一条可执行规则例如“当用户输入包含城市名时不要反问直接调用天气工具”。如果用大模型做反思通常需要把轨迹摘要和失败原因拼接成 prompt。这里要注意不能让反思结果变成空话例如“下次要更细心”这种提示没有价值。规则必须落到具体动作。3.3 策略更新模块把反思结果应用到下一次决策策略更新有两条路径。一条是外部策略。反思生成的新规则写入知识库Agent 在下一次任务开始时把相关规则注入 system prompt。这条路径成本低适合快速实验。另一条是内部策略。把反思后的经验整理成训练数据对模型进行微调。这条路径更接近课程讨论的“自改进”终极目标但成本高而且需要防止过拟合。下面用一个表格比较两种策略更新方式维度外部知识库模型微调更新速度快写入即生效慢需要训练和评估流程成本低只需要注意 prompt 长度高需要算力和数据准备可解释性可以直接看到注入的规则较弱行为变化分散在参数中适用场景实验期、工具规则变化频繁能力已经稳定需要举一反三失败回滚简单删除规则即可需要保留旧权重或做版本控制学习 CS329A 时建议先实现外部知识库方式跑通“反思 - 写入规则 - 再执行”的闭环再考虑微调。否则很难判断能力提升来自数据质量还是模型参数变化。4. 构建一个“最小自改进 Agent”的完整流程4.1 任务定义和数据结构设计为了演示我们定义一个简单任务根据用户描述输出一个包含city和weather两个字段的 JSON。Agent 使用的工具是天气查询函数评估器检查输出 JSON 是否合法且字段完整。数据结构如下# schema.py from pydantic import BaseModel class TaskInput(BaseModel): user_input: str class TaskOutput(BaseModel): city: str weather: str这样做的好处是评估器可以直接使用 pydantic 的字段定义。如果 Agent 返回的 JSON 缺少字段pydantic 会抛出验证错误评估器捕获后标记为失败。4.2 实现 Agent 的执行、评估、反思、更新循环下面给出一个完整的自改进闭环代码框架。为了清晰模型调用部分保持抽象实际项目中可以替换为任何大模型服务。# self_improving_agent.py import json from typing import Callable, Dict, List, Optional from agent_base import MinimalAgent from evaluator import SimpleEvaluator from schema import TaskInput, TaskOutput class SelfImprovingAgent: def __init__( self, model_fn: Callable[[List[Dict[str, str]]], str], tools: Dict[str, Callable], evaluator: SimpleEvaluator, rules: Optional[List[str]] None, ): self.model_fn model_fn self.tools tools self.evaluator evaluator self.rules rules or [] self.trajectories [] def _build_messages(self, user_input: str) - List[Dict[str, str]]: system_content 你是一个天气查询助手。请严格输出 JSON 格式。 if self.rules: system_content 以下规则来自历史经验 system_content .join(self.rules) return [ {role: system, content: system_content}, {role: user, content: user_input}, ] def run(self, user_input: str) - Dict: messages self._build_messages(user_input) raw_output self.model_fn(messages) try: output json.loads(raw_output) except json.JSONDecodeError: output {} eval_result self.evaluator.evaluate(output) trajectory { input: user_input, raw_output: raw_output, parsed_output: output, eval: eval_result, } self.trajectories.append(trajectory) return { output: output, evaluation: eval_result, } def improve(self): # 从失败轨迹中生成规则 failed_trajectories [ t for t in self.trajectories if not t[eval][passed] ] if not failed_trajectories: return examples json.dumps(failed_trajectories[:3], ensure_asciiFalse) rule_prompt ( 分析以下 Agent 执行轨迹找出失败原因 并用一句话输出可执行的改进规则。\n轨迹 examples ) rule self.model_fn( [ {role: user, content: rule_prompt}, ] ).strip() self.rules.append(rule)这个类的工作流程是运行任务 - 记录轨迹 - 评估失败 - 从失败轨迹中生成新规则 - 写回规则列表 - 下次任务使用新规则。4.3 运行和验证这个闭环为了让示例可运行我们写一个模拟的模型函数。它第一次返回缺少字段的 JSON第二次在规则指导下返回正确结果。# demo.py from self_improving_agent import SelfImprovingAgent from evaluator import SimpleEvaluator fake_messages [] def fake_model(messages): global fake_messages fake_messages messages if len(fake_messages[0][content]) 50: # 模拟带规则时输出正确 JSON return {city: 北京, weather: 晴} else: # 模拟初始输出缺失字段 return {city: 北京} evaluator SimpleEvaluator(required_fields[city, weather]) agent SelfImprovingAgent(model_fnfake_model, tools{}, evaluatorevaluator) result1 agent.run(北京天气怎么样) print(第一次结果, result1) agent.improve() print(生成的规则, agent.rules[0]) result2 agent.run(北京天气怎么样) print(第二次结果, result2)这个例子非常简化但展示了自改进循环的关键失败 - 反思 - 规则注入 - 行为变化。真实项目中模型函数要换成真实 API 调用反思 prompt 也要更精细。4.4 从学习用例走向真实项目时要注意什么上面示例只适合学习和理解概念。真实项目还需要补充以下内容评估器不能只检查字段存在还要检查值是否合理。规则库需要版本管理和冲突检测不能无限制追加。每次策略更新后需要跑回归测试确认旧任务没有被破坏。模型调用成本需要记录自改进不能以无限增加调用次数为代价。需要区分训练环境和生产环境避免生产环境直接自动更新规则。5. 学习与实战中的常见坑和排查路径5.1 模型生成结果不稳定导致评估结果忽高忽低现象是同一个 Agent 使用同样输入多次执行结果不同今天成功明天失败。可能原因包括模型采样参数中的 temperature 设置过高、prompt 中规则互相冲突、工具返回结果存在随机性。排查先看日志中记录的温度参数和 prompt 版本。然后固定一组测试用例在相同参数下运行 10 次统计成功率。如果成功率波动大可以先把 temperature 调到 0 或一个较低值排除随机性后再逐步调整。5.2 自改进导致“越改越差”出现能力退化加入反思规则后简单任务成功率提升但复杂任务成功率下降。这通常是规则过拟合造成的新的规则只适用于少数失败案例却干扰了正常路径。检查方式是把历史轨迹按难度分组分别统计成功率。如果某一组显著下降说明新规则可能过于激进。解决方法是给规则增加生效条件例如“当输入包含城市名时才注入天气工具规则”并建立规则回滚机制。CS329A 里也强调自改进不等于盲目叠加规则先验证后上线。5.3 评估指标和真实目标不一致一个常见误区是评估器只检查 JSON 是否合法但用户真正的需求是“回答得足够详细”或“找到准确信息”。如果 Agent 学会了用合法但不相关的内容绕过评估器自改进就会优化一个错误的指标。排查时要把评估指标和真实业务目标写在一张表里逐项对照。例如评估指标真实目标是否一致输出包含 city 和 weather 字段用户能知道今天能不能出门部分一致缺少温度范围判断回答包含“注意安全”风险提示指标未覆盖真实风险场景调用工具次数少于 3 次降低延迟不一定可能减少必要探索发现不一致后要修改评估指标而不是让 Agent 更努力地迎合旧指标。5.4 成本膨胀自改进调用链越来越长自改进 Agent 每次任务都需要执行主模型、评估器、反思模型可能导致成本成倍增长。排查方法是记录每次任务的 token 消耗和 API 调用次数。可以在代码中增加一个计数器把日志输出到表格或时序数据库。阶段平均调用次数平均输入 token平均输出 token主 Agent 执行32000500评估器1800200反思生成0.21000300如果反思模型调用成本过高可以改为只在批量离线流程中触发反思不在每次在线请求中触发。这是学习环境和生产环境的关键差异之一。6. 从课程到项目实践建议和扩展方向6.1 先把基线跑通再谈自改进很多人学习自改进 Agent 时会犯同一个错误直接设计复杂框架结果第一版就出现大量 Bug。更好的做法是先实现一个没有自改进功能的普通 Agent固定测试集记录基线的成功率和平均成本。然后再逐步添加记忆、反思、规则注入。每添加一个模块都重新跑同一组测试。这样能清楚知道哪个改动真正带来提升。建议把测试集保存为 JSONL 文件每个样例包含输入、标准输出、评估字段。{input: 北京天气怎么样, expected: {city: 北京, weather: 晴}} {input: 上海天气怎么样, expected: {city: 上海, weather: 多云}}测试集规模不用大但必须覆盖正常情况、边界情况和错误输入。6.2 自改进 Agent 生产化的六个关键步骤配置外置化规则、prompt、模型版本不要写死在代码里使用配置文件或配置中心管理。日志结构化每一条轨迹都保存为 JSON方便后续离线分析。评估自动化把评估器接入 CI每次规则变更后自动跑回归。策略回滚规则和模型权重都要有版本记录发现问题可以迅速回退。监控指标至少监控任务成功率、平均成本、平均延迟、规则命中率。安全护栏对 Agent 的工具调用权限做最小化限制防止错误动作影响外部系统。6.3 可作为课程作业或项目扩展的方向如果正在跟学 CS329A可以从小任务开始扩展。推荐几个方向自动代码修复 Agent根据编译器报错信息修改代码并用单测通过率作为评估指标。信息检索 Agent根据用户问题选择搜索词再根据文档相关性优化搜索策略。表格问答 Agent让 Agent 学会写 SQL 查询并用查询结果正确率评估。多工具协作 Agent让 Agent 自行决定先调用哪个工具通过任务成功率评估工具调度策略。每个方向都可以套用“执行 - 评估 - 反思 - 策略更新”的闭环框架。关键不是框架本身而是你能否为任务定义出可靠的评估器和可执行的反思规则。6.4 可复用的自改进 Agent 检查清单发布自改进 Agent 前对照以下清单逐项检查明确任务边界Agent 可以做什么不能做什么。固定测试集至少 30 个典型样例包含成功和失败场景。评估器可解释每个评估分数都能对应到具体错误原因。反思规则可执行规则不是“下次要细心”而是“当输入包含城市名时直接调用天气工具”。有回归测试机制策略更新后旧任务成功率不下降。记录轨迹和版本每个输出都能追溯模型版本、规则版本、工具版本。控制成本和延迟有 token 用量和调用次数上限。保留人工审核入口关键任务或高风险任务不允许完全自动更新策略。这份清单既适用于课程作业也适用于生产项目。自改进 Agent 的价值不在于让模型“自己变聪明”而在于让开发者有能力把每一次失败都转化为下一次执行的指导信号。学习 CS329A 时最重要的练习不是背诵概念而是亲手把一个没有记忆的 Agent 改造成一个能感知失败、生成规则、并验证规则有效性的系统。跑通一次完整的自改进循环之后你会对评估信号、轨迹质量和策略更新的关系有更实际的理解。这个理解可以直接迁移到 RAG 调优、自动化测试、数据分析助手和代码生成等多个场景中。 
长河君 · 2026/9/2 16:38:00 · 阅读 1.2k 自改进AI Agent的三大核心模块：记忆、反思与策略更新
AI Agent 是当前以大模型为核心的工程热点而斯坦福 CS329A 这门课更进一步把目标从“会调用工具”提升到“能从自身经验中改进能力”。自改进不是给模型多调几次 prompt而是让 Agent 在完成任务的循环里记录轨迹、检验结果、修正策略最终让同样的任务做得更好。本文围绕 CS329A 的课程主线先讲清楚自改进 Agent 与传统程序的区别再给出可复现的最小实现思路最后补充排查路径和实战建议。这门课适合三类人已经在做 RAG、工具调用或自动化流程的工程师想从“调接口”升级到“设计闭环系统”的研究者以及准备系统学习 Agent 工程化的学生。读完本文你会得到一张完整的自改进 Agent 技术地图包括模块划分、代码骨架、评估方法、常见坑和可落地的检查清单。1. 先理解“自改进 AI Agent”到底在解决什么问题1.1 自改进 Agent 和普通程序有什么不同普通程序是“输入 - 固定逻辑 - 输出”。无论运行多少次只要输入相同输出就几乎不变。Agent 的本质区别在于它会根据当前环境状态选择动作而自改进 Agent 还会在动作结束之后反思这次为什么做对了为什么做错了下次怎样更少走弯路。CS329A 这门课程把“自改进”拆成了三层第一层是记忆。Agent 需要保存历史轨迹而不是每次任务都从零开始。第二层是反思。Agent 需要根据结果反馈生成经验总结。第三层是策略更新。Agent 把反思后的经验变成新的 prompt、参数、或工具选择规则用于下一次任务。这三层缺一不可。只有记忆没有反思数据会堆积但不会变成能力只有反思没有策略更新总结只是一堆文本只有策略更新没有验证机制模型会越改越偏。1.2 为什么“自改进”不能靠堆 Prompt 实现很多人会问自改进是不是把错误案例写进 system prompt 就行这种做法有效但不可持续。Prompt 长度有限错误案例会越来越多而且不同任务之间的经验可能互相冲突。更系统的做法是把自改进看成一个闭环采样轨迹用评估器打分从高分和低分轨迹中提炼规则再通过微调或外部知识库更新策略。CS329A 强调的正是这个闭环。它要求开发者先定义“好”和“坏”再让 Agent 在试错中逐步靠近“好”的标准。1.3 CS329A 的课程主线从能力边界到自我强化从课程主题看CS329A 讨论的不只是“怎么让 Agent 能写代码”或“怎么让 Agent 能查文档”而是“如何让 Agent 在多次执行中自动发现自己的能力边界并针对短板进行强化”。一个典型路径是给出一个目标函数例如任务成功率。Agent 执行一组任务收集日志和结果。评估器判断哪些步骤失败并给出失败标签。Agent 根据失败标签调整工具使用顺序、prompt 描述或模型参数。再次执行同样任务对比成功率。这条路径和机器学习训练流程很像区别在于 Agent 的状态空间、动作空间和反馈信号都更复杂。这也是为什么学 CS329A 之前最好已经掌握 Python、基础机器学习和大模型 API 调用。2. 围绕课程主题搭建可复现的学习环境2.1 环境准备和依赖版本建议学习 CS329A 不需要一开始就上生产级分布式系统。一个能在本地跑通的最小环境足够理解核心逻辑。建议使用 Python 3.10 以上版本并安装以下依赖transformers用于加载本地或远程大模型。torch或tensorflow作为模型后端。openai或类似 SDK用于调用云端模型服务。pydantic用于定义结构化输出和评估结果。pytest用于测试 Agent 的每个模块。如果原始课程环境没有明确给出版本落地前需要确认依赖版本兼容性。示例操作如下python -m venv venv source venv/bin/activate pip install --upgrade pip pip install transformers torch openai pydantic pytest这里把transformers和openai同时安装是因为学习时可能需要在本地小模型和云端大模型之间切换。pydantic用来约束 Agent 返回的数据结构评估器依靠它判断结果是否有缺失字段。2.2 最小 Agent 框架模型、工具、循环下面用一个非常小的示例说明 Agent 的基本组成。这里假设call_llm是封装好的模型调用函数get_weather是工具实际使用时可以换成自己的 API。# agent_base.py from typing import Callable, Dict, List def call_llm(messages: List[Dict[str, str]]) - str: # 这里实现模型调用返回文本 raise NotImplementedError def get_weather(city: str) - str: # 模拟天气查询工具 return f{city} 晴25 度 class MinimalAgent: def __init__(self, tools: Dict[str, Callable]): self.tools tools self.history [] def run(self, user_input: str) - str: messages [ {role: system, content: 你是一个智能助理可以调用工具获取实时信息。}, {role: user, content: user_input}, ] response call_llm(messages) self.history.append({input: user_input, output: response}) return response这个 Agent 只有“调用模型”和“记录历史”两个能力还没有自改进。自改进要在这个基础上增加评估和优化模块。先跑通这个最小闭环再逐步扩展是 CS329A 推荐的实践顺序。2.3 为什么需要评估器而不是只看“模型回答好不好”普通聊天场景中人可以主观判断回答质量。自改进 Agent 面对的是批量任务不可能每次都人工打分需要使用评估器自动计算指标。评估器可以很简单也可以很复杂。简单评估器检查结构化输出是否包含关键字段复杂评估器会把答案和标准答案做语义相似度计算或者用另一个模型做裁判。CS329A 关注的重点之一是“评估信号的质量”因为自改进算法最终要优化评估器给出的分数如果分数不可靠策略更新就会跑偏。以下是评估器的最小实现# evaluator.py from typing import Dict class SimpleEvaluator: def __init__(self, required_fields: list): self.required_fields required_fields def evaluate(self, output: Dict) - Dict: missing [f for f in self.required_fields if f not in output] score 1.0 if not missing else 0.0 return { score: score, missing_fields: missing, passed: score 1.0, }这个评估器只检查字段是否完整适合学习阶段。真实项目还需要检查字段值是否合法、是否和上下文一致、计算过程是否正确等。3. 自改进 Agent 的三个核心模块记忆、反思、策略更新3.1 记忆模块从“每次从头开始”到“带着经验工作”自改进 Agent 的记忆可以分为两类。短期记忆指当前任务执行过程中的上下文例如已经调用过的工具、已经得到的中间结果。长期记忆指跨任务的经验例如某个任务类型常见的失败模式、某类 prompt 的改进记录。实现时建议用统一的Trajectory结构保存记忆。每一次任务执行都记录输入意图Agent 的每一步动作工具返回结果最终答案评估器打分和错误标签保存到 JSON 或 SQLite 都可以。CS329A 里强调“轨迹是自改进的燃料”因为后续所有反思和策略更新都基于轨迹而不是基于零散印象。3.2 反思模块把轨迹变成可执行的修改建议反思不是让 Agent 写一句“我错了”而是从错误轨迹中找出可以复用的规律。例如一个 Agent 在查询天气时总是先问用户城市名再调用工具。如果轨迹显示用户已经说了“北京天气如何”那 Agent 还反问就显得多余。反思模块要做的是从失败轨迹中定位关键步骤。对比成功轨迹和失败轨迹的差异。输出一条可执行规则例如“当用户输入包含城市名时不要反问直接调用天气工具”。如果用大模型做反思通常需要把轨迹摘要和失败原因拼接成 prompt。这里要注意不能让反思结果变成空话例如“下次要更细心”这种提示没有价值。规则必须落到具体动作。3.3 策略更新模块把反思结果应用到下一次决策策略更新有两条路径。一条是外部策略。反思生成的新规则写入知识库Agent 在下一次任务开始时把相关规则注入 system prompt。这条路径成本低适合快速实验。另一条是内部策略。把反思后的经验整理成训练数据对模型进行微调。这条路径更接近课程讨论的“自改进”终极目标但成本高而且需要防止过拟合。下面用一个表格比较两种策略更新方式维度外部知识库模型微调更新速度快写入即生效慢需要训练和评估流程成本低只需要注意 prompt 长度高需要算力和数据准备可解释性可以直接看到注入的规则较弱行为变化分散在参数中适用场景实验期、工具规则变化频繁能力已经稳定需要举一反三失败回滚简单删除规则即可需要保留旧权重或做版本控制学习 CS329A 时建议先实现外部知识库方式跑通“反思 - 写入规则 - 再执行”的闭环再考虑微调。否则很难判断能力提升来自数据质量还是模型参数变化。4. 构建一个“最小自改进 Agent”的完整流程4.1 任务定义和数据结构设计为了演示我们定义一个简单任务根据用户描述输出一个包含city和weather两个字段的 JSON。Agent 使用的工具是天气查询函数评估器检查输出 JSON 是否合法且字段完整。数据结构如下# schema.py from pydantic import BaseModel class TaskInput(BaseModel): user_input: str class TaskOutput(BaseModel): city: str weather: str这样做的好处是评估器可以直接使用 pydantic 的字段定义。如果 Agent 返回的 JSON 缺少字段pydantic 会抛出验证错误评估器捕获后标记为失败。4.2 实现 Agent 的执行、评估、反思、更新循环下面给出一个完整的自改进闭环代码框架。为了清晰模型调用部分保持抽象实际项目中可以替换为任何大模型服务。# self_improving_agent.py import json from typing import Callable, Dict, List, Optional from agent_base import MinimalAgent from evaluator import SimpleEvaluator from schema import TaskInput, TaskOutput class SelfImprovingAgent: def __init__( self, model_fn: Callable[[List[Dict[str, str]]], str], tools: Dict[str, Callable], evaluator: SimpleEvaluator, rules: Optional[List[str]] None, ): self.model_fn model_fn self.tools tools self.evaluator evaluator self.rules rules or [] self.trajectories [] def _build_messages(self, user_input: str) - List[Dict[str, str]]: system_content 你是一个天气查询助手。请严格输出 JSON 格式。 if self.rules: system_content 以下规则来自历史经验 system_content .join(self.rules) return [ {role: system, content: system_content}, {role: user, content: user_input}, ] def run(self, user_input: str) - Dict: messages self._build_messages(user_input) raw_output self.model_fn(messages) try: output json.loads(raw_output) except json.JSONDecodeError: output {} eval_result self.evaluator.evaluate(output) trajectory { input: user_input, raw_output: raw_output, parsed_output: output, eval: eval_result, } self.trajectories.append(trajectory) return { output: output, evaluation: eval_result, } def improve(self): # 从失败轨迹中生成规则 failed_trajectories [ t for t in self.trajectories if not t[eval][passed] ] if not failed_trajectories: return examples json.dumps(failed_trajectories[:3], ensure_asciiFalse) rule_prompt ( 分析以下 Agent 执行轨迹找出失败原因 并用一句话输出可执行的改进规则。\n轨迹 examples ) rule self.model_fn( [ {role: user, content: rule_prompt}, ] ).strip() self.rules.append(rule)这个类的工作流程是运行任务 - 记录轨迹 - 评估失败 - 从失败轨迹中生成新规则 - 写回规则列表 - 下次任务使用新规则。4.3 运行和验证这个闭环为了让示例可运行我们写一个模拟的模型函数。它第一次返回缺少字段的 JSON第二次在规则指导下返回正确结果。# demo.py from self_improving_agent import SelfImprovingAgent from evaluator import SimpleEvaluator fake_messages [] def fake_model(messages): global fake_messages fake_messages messages if len(fake_messages[0][content]) 50: # 模拟带规则时输出正确 JSON return {city: 北京, weather: 晴} else: # 模拟初始输出缺失字段 return {city: 北京} evaluator SimpleEvaluator(required_fields[city, weather]) agent SelfImprovingAgent(model_fnfake_model, tools{}, evaluatorevaluator) result1 agent.run(北京天气怎么样) print(第一次结果, result1) agent.improve() print(生成的规则, agent.rules[0]) result2 agent.run(北京天气怎么样) print(第二次结果, result2)这个例子非常简化但展示了自改进循环的关键失败 - 反思 - 规则注入 - 行为变化。真实项目中模型函数要换成真实 API 调用反思 prompt 也要更精细。4.4 从学习用例走向真实项目时要注意什么上面示例只适合学习和理解概念。真实项目还需要补充以下内容评估器不能只检查字段存在还要检查值是否合理。规则库需要版本管理和冲突检测不能无限制追加。每次策略更新后需要跑回归测试确认旧任务没有被破坏。模型调用成本需要记录自改进不能以无限增加调用次数为代价。需要区分训练环境和生产环境避免生产环境直接自动更新规则。5. 学习与实战中的常见坑和排查路径5.1 模型生成结果不稳定导致评估结果忽高忽低现象是同一个 Agent 使用同样输入多次执行结果不同今天成功明天失败。可能原因包括模型采样参数中的 temperature 设置过高、prompt 中规则互相冲突、工具返回结果存在随机性。排查先看日志中记录的温度参数和 prompt 版本。然后固定一组测试用例在相同参数下运行 10 次统计成功率。如果成功率波动大可以先把 temperature 调到 0 或一个较低值排除随机性后再逐步调整。5.2 自改进导致“越改越差”出现能力退化加入反思规则后简单任务成功率提升但复杂任务成功率下降。这通常是规则过拟合造成的新的规则只适用于少数失败案例却干扰了正常路径。检查方式是把历史轨迹按难度分组分别统计成功率。如果某一组显著下降说明新规则可能过于激进。解决方法是给规则增加生效条件例如“当输入包含城市名时才注入天气工具规则”并建立规则回滚机制。CS329A 里也强调自改进不等于盲目叠加规则先验证后上线。5.3 评估指标和真实目标不一致一个常见误区是评估器只检查 JSON 是否合法但用户真正的需求是“回答得足够详细”或“找到准确信息”。如果 Agent 学会了用合法但不相关的内容绕过评估器自改进就会优化一个错误的指标。排查时要把评估指标和真实业务目标写在一张表里逐项对照。例如评估指标真实目标是否一致输出包含 city 和 weather 字段用户能知道今天能不能出门部分一致缺少温度范围判断回答包含“注意安全”风险提示指标未覆盖真实风险场景调用工具次数少于 3 次降低延迟不一定可能减少必要探索发现不一致后要修改评估指标而不是让 Agent 更努力地迎合旧指标。5.4 成本膨胀自改进调用链越来越长自改进 Agent 每次任务都需要执行主模型、评估器、反思模型可能导致成本成倍增长。排查方法是记录每次任务的 token 消耗和 API 调用次数。可以在代码中增加一个计数器把日志输出到表格或时序数据库。阶段平均调用次数平均输入 token平均输出 token主 Agent 执行32000500评估器1800200反思生成0.21000300如果反思模型调用成本过高可以改为只在批量离线流程中触发反思不在每次在线请求中触发。这是学习环境和生产环境的关键差异之一。6. 从课程到项目实践建议和扩展方向6.1 先把基线跑通再谈自改进很多人学习自改进 Agent 时会犯同一个错误直接设计复杂框架结果第一版就出现大量 Bug。更好的做法是先实现一个没有自改进功能的普通 Agent固定测试集记录基线的成功率和平均成本。然后再逐步添加记忆、反思、规则注入。每添加一个模块都重新跑同一组测试。这样能清楚知道哪个改动真正带来提升。建议把测试集保存为 JSONL 文件每个样例包含输入、标准输出、评估字段。{input: 北京天气怎么样, expected: {city: 北京, weather: 晴}} {input: 上海天气怎么样, expected: {city: 上海, weather: 多云}}测试集规模不用大但必须覆盖正常情况、边界情况和错误输入。6.2 自改进 Agent 生产化的六个关键步骤配置外置化规则、prompt、模型版本不要写死在代码里使用配置文件或配置中心管理。日志结构化每一条轨迹都保存为 JSON方便后续离线分析。评估自动化把评估器接入 CI每次规则变更后自动跑回归。策略回滚规则和模型权重都要有版本记录发现问题可以迅速回退。监控指标至少监控任务成功率、平均成本、平均延迟、规则命中率。安全护栏对 Agent 的工具调用权限做最小化限制防止错误动作影响外部系统。6.3 可作为课程作业或项目扩展的方向如果正在跟学 CS329A可以从小任务开始扩展。推荐几个方向自动代码修复 Agent根据编译器报错信息修改代码并用单测通过率作为评估指标。信息检索 Agent根据用户问题选择搜索词再根据文档相关性优化搜索策略。表格问答 Agent让 Agent 学会写 SQL 查询并用查询结果正确率评估。多工具协作 Agent让 Agent 自行决定先调用哪个工具通过任务成功率评估工具调度策略。每个方向都可以套用“执行 - 评估 - 反思 - 策略更新”的闭环框架。关键不是框架本身而是你能否为任务定义出可靠的评估器和可执行的反思规则。6.4 可复用的自改进 Agent 检查清单发布自改进 Agent 前对照以下清单逐项检查明确任务边界Agent 可以做什么不能做什么。固定测试集至少 30 个典型样例包含成功和失败场景。评估器可解释每个评估分数都能对应到具体错误原因。反思规则可执行规则不是“下次要细心”而是“当输入包含城市名时直接调用天气工具”。有回归测试机制策略更新后旧任务成功率不下降。记录轨迹和版本每个输出都能追溯模型版本、规则版本、工具版本。控制成本和延迟有 token 用量和调用次数上限。保留人工审核入口关键任务或高风险任务不允许完全自动更新策略。这份清单既适用于课程作业也适用于生产项目。自改进 Agent 的价值不在于让模型“自己变聪明”而在于让开发者有能力把每一次失败都转化为下一次执行的指导信号。学习 CS329A 时最重要的练习不是背诵概念而是亲手把一个没有记忆的 Agent 改造成一个能感知失败、生成规则、并验证规则有效性的系统。跑通一次完整的自改进循环之后你会对评估信号、轨迹质量和策略更新的关系有更实际的理解。这个理解可以直接迁移到 RAG 调优、自动化测试、数据分析助手和代码生成等多个场景中。