做 Agent 开发的工程师应该都体会过同一个落差接一个大模型 API配上 system prompt 和几个工具函数一个能干活的 Agent 原型可能半天就搭出来了可一旦丢进真实业务问题接踵而至——模型会在多轮工具调用后忘记最初目标会在同一个 error 上反复重试会自信地编造一个并不存在的 API 返回值。这些问题的根源不在于某一次 prompt 写得不好而在于大多数人仍然把 Agent 当作大模型的另一个壳在写。斯坦福 CS329A 这门课把观察角度从提示词技巧拉高到了系统能力。从课程标题里的三个关键词就能看得很清楚推理Reasoning、搜索Search、强化学习Reinforcement Learning。它真正想问的是一个 Agent 能否在复杂任务里想得更清楚探索得更多并且从自己的错误里真正学会改进——而不是靠工程师反复调 prompt 来手动打补丁。这篇文章不做课程复述也不评价任何具体讲师而是站在准备系统学习 Agent 开发的工程师角度把 CS329A 这条主线拆开讲推理解决什么问题搜索解决什么问题强化学习解决什么问题三者怎么闭环成自我改进的 Agent以及你学完如何在真实项目里落地。如果你正在做或者准备做 Agent这篇文章能帮你先建立一张完整的技术地图再决定从哪一块开始投入。1. Agent 开发为什么需要系统级方法Agent 这个词被讲得很多但大多数项目里的 Agent本质还是大模型 工具调用 固定 Prompt的三件套。它能跑通 demo却撑不起复杂业务原因可以归纳成三层。第一层是不可靠。LLM 的输出是概率采样同样一个问题换一种问法结果可能从查餐厅并确认营业时间变成直接替你下单。Agent 必须在这种不确定性的基础上构建确定性的流程但 prompt 能约束的是语气和格式约束不了决策是否正确。第二层是不可控。多轮工具调用里模型会逐渐丢失上下文。比如一个链式任务查询用户订单状态如果异常则发起退款申请同时给客服发工单。 很多模型会在执行到退款的时候忘了同时给客服发工单这个并列要求。这类错误不是单点 prompt 能解决的它暴露的是模型在长程规划上的能力边界。第三层是最容易被忽略的不可改进。传统 prompt 项目里模型今天犯的错明天还会犯。工程师能做的是不断追加不要做 X的负例描述可补丁越多系统越脆弱甚至出现 prompt 过长导致截断。真正让 Agent 从错误中学习需要的是训练层面或搜索机制层面的迭代而不是对话层面的修补。如果把 Agent 开发看成一条路大多数人停在第一站再调一调 prompt再加一个工具再堆几篇 RAG 文档。但这条路越往后走边际收益越低。CS329A 提出的方向是把 Agent 当作一个系统来构建。推理负责想对搜索负责试全强化学习负责学会。后面所有内容都围绕这三点展开。2. CS329A 的课程主线一门课抓住三大支柱先说明一点课程讲义和课堂细节需要去官方渠道获取这里只基于公开信息和课程标题本身做主线分析。从自我改进 AI 智能体从推理、搜索到强化学习这个定位来看CS329A 的教学设计非常清晰——它不想讲Agent 是什么这种科普也不想只讲某个框架的用法它想把 Agent 的能力拆成三层每层对应一类关键技术。第一层是推理。让 Agent 在回答或行动之前先产生一条思考路径。模型不是直接给出结论而是先生成子问题、约束条件、候选方案再综合出一个结果。这一层解决的是答案质量问题。第二层是搜索。当问题足够复杂、候选方案爆炸时Agent 需要在状态空间里探索。搜索算法负责组织这种探索让模型不是一条路走到黑而是维护多条路径、回溯、剪枝、择优。这一层解决的是覆盖广度问题。第三层是强化学习。模型从成功的轨迹和失败的轨迹中提取训练信号通过策略优化不断调整自己的行为让碰巧做对变成稳定做对。这一层解决的是长期改进问题。可以用一个表格把三者区隔开能力核心问题典型方法改进时间点推理Reasoning如何想得更清楚CoT、Self-Consistency、Self-Refine生成阶段搜索Search如何探索更多可能BFS/DFS、MCTS、LLM-guided Search决策阶段强化学习RL如何从反馈中学会PPO、GRPO、RLVR、偏好优化训练阶段这张表值得贴在工位边上。它把 Agent 的能力分到了不同时间尺度推理发生在模型生成的那一刻搜索发生在 Agent 决策循环中而强化学习发生在你拥有一批数据之后的离线或在线训练中。三者不是互相替代的关系而是层层支撑的关系。下一章开始逐个展开。3. 推理Reasoning让 Agent 先学会想清楚再答3.1 为什么推理是 Agent 的第一块地基如果 Agent 连一个问题的正确推理都做不好后面的搜索和强化学习都是在低质量地基上盖楼。早期 GPT-3 时代大家就发现直接让模型回答数学题它经常一本正经地给出错误答案但如果你在 prompt 里加一句请先逐步思考再作答准确率会明显提升——这就是最简单的推理增强思维链Chain-of-ThoughtCoT。CoT 的原理不难理解它把模型的一次性映射变成逐步的中间推导。对于 Agent 来说价值不只是答对题而是把决策过程显式化。比如用户要求订明天上午的会议室并通知参会人模型如果在内部把任务拆成查询会议室可用性 - 选择可用时段 - 调用预定接口 - 发送通知那么每一步出错时开发者和模型本人都能看到错在哪里也才谈得上后面用搜索去修正。3.2 思路链路从 CoT 到 Self-ConsistencyCoT 只是一个起点。它对单条推理路径上的一步错、步步错非常敏感。于是出现了 Self-Consistency让模型用较高 temperature 采样多次生成多条独立的推理路径然后对最终答案做投票。这相当于在一个模型内部做了多次头脑风暴再民主决策。再往下走是 Self-Refine 和 Reflexion 这类方法。它们让模型先生成一个初步结果然后把它交给一个评论者角色检查错误再让生成者基于评论修正。这里已经出现自我改进的雏形不是靠外部人类的反馈而是模型自己检查自己。你可能会说这不就是多写几轮 prompt 吗对机制上确实是多轮生成但关键区别在于搜索阶段会系统化地决定评什么、改什么、什么时候停止这就把随意重试变成了可控算法。这也是推理向搜索过渡的连接点。3.3 示例用 Self-Consistency 提升 Agent 决策稳定性下面用一个最小可替换的 Python 骨架演示 Self-Consistency 的核心逻辑。call_llm是占位实现实际使用中请替换成你的模型服务OpenAI 兼容接口、vLLM、Ollama 都可以# 文件路径examples/reasoning_self_consistency.py 使用 Self-Consistency 提升 Agent 推理稳定性。 核心思路多次采样推理路径 - 提取最终答案 - 多数投票。 真实使用时把 call_llm 替换成你的模型服务即可。 import os from collections import Counter import requests MODEL os.environ.get(LLM_MODEL, your-model-id) BASE_URL os.environ.get(LLM_BASE_URL, http://localhost:8000/v1) def call_llm(prompt: str, temperature: float 0.7) - str: 调用 OpenAI 兼容接口的简单实现。 resp requests.post( f{BASE_URL}/chat/completions, json{ model: MODEL, messages: [ {role: system, content: 请逐步推理并在最后一行输出最终答案结果}, {role: user, content: prompt}, ], temperature: temperature, max_tokens: 1024, }, timeout60, ) resp.raise_for_status() return resp.json()[choices][0][message][content] def extract_answer(text: str) - str: 从推理文本中提取最终答案。 marker 最终答案 if marker in text: return text.split(marker)[-1].strip() lines [line.strip() for line in text.strip().split(\n) if line.strip()] return lines[-1] if lines else def solve_with_self_consistency(question: str, n_samples: int 5) - str: answers [] for _ in range(n_samples): raw call_llm(question, temperature0.7) answers.append(extract_answer(raw)) result Counter(answers).most_common(1)[0][0] print(f采样答案{answers}) print(f最终选择{result}) return result if __name__ __main__: question 一个 Agent 需要依次完成查天气、订餐厅、发送日历邀请。如果日历服务不可用应该如何处理 solve_with_self_consistency(question, n_samples5)这段代码的运行逻辑不复杂每次采样都让模型先输出推理过程再输出最终答案extract_answer负责从文本里截出结论最后用 Counter 做众数投票。真正工程化时你还可以给每条答案附上模型自评分或者用验证器过滤错误格式让投票更可靠。这里要注意一个容易被忽略的细节Self-Consistency 能提升稳定性靠的是多次采样之间的多样性。如果调用模型服务时关闭了 temperature设为 0那么多次采样结果几乎一样投票就没有意义。所以示例里特意用了 0.7你需要在多样性和质量下限之间做取舍。3.4 推理的边界想得对但不一定找得到推理再强也只是在已知路径上走得更稳。当一个问题本身有非常大的组合空间时——比如让 Agent 从几十个 API 中选出合适的组合流程或者修复一段有多个潜在缺陷的代码——单靠推理能力是不够的。它没有机制去系统性地检查我是不是漏掉了一条路径也没有办法在一条路走死之后主动换路。这个问题恰好是搜索要解决的。4. 搜索Search把试错变成算法能力4.1 当 Agent 面对开放解空间推理就不够了推理解决的是给定信息如何推出更好结论。但真实 Agent 任务常常没有一个封闭的推理链。比如帮我找到最近三天系统报错的原因正确的路径可能是查日志 - 过滤关键词 - 看对应时间段的指标 - 找到异常服务 - 检查最近发布单。每一步都有多个候选动作每个动作都可能引出新的状态。这种空间里模型不可能一次推理出完整路径正确做法是系统性地尝试。搜索算法的作用就是把这套尝试组织成有结构的探索。经典搜索算法比如 BFS广度优先、DFS深度优先、A*带启发式的最短路搜索在人工智能早期就是核心方法论而现在它们重新回到大模型时代变成了 Agent 决策引擎的一部分。4.2 从经典搜索到 LLM 引导的搜索经典搜索的问题是组合爆炸状态一多遍历成本指数级上升。于是现代 Agent 的做法不是纯暴力搜索而是用 LLM 来引导搜索方向再用搜索算法来保障探索质量。这种结合体现在最常见的两个形态是Best-of-N让模型生成 N 条候选轨迹再用一个评分函数选出最优的一条。这其实是一种极其简单的搜索适合并行和成本可控的场景。MCTS蒙特卡洛树搜索在候选动作树上反复走选择 - 扩展 - 模拟 - 回传四步。AlphaGo 用它下围棋现在不少推理模型也借鉴这一套思想来搜索推理路径。通俗理解搜索让 Agent 从下第一手棋就决定胜负变成先看看这步棋能引向什么局面再评估要不要走。4.3 示例在工具调用空间中做深度优先搜索下面用一个简化但有启发性的示例展示 DFS 在 Agent 工具调用路径搜索中的基本形态。这里的状态是模拟的真实场景中状态可以是当前上下文 已完成工具结果动作则由 LLM 生成候选# 文件路径examples/search_agent_dfs.py 在 Agent 动作空间中用深度优先搜索找一条可行路径。 动作search_web / query_db / send_email 目标先拿到数据库结果再发送邮件。 from typing import Any, Dict, List def search_web(state: Dict[str, Any]) - Dict[str, Any]: state[info] state.get(info, ) web_result; return state def query_db(state: Dict[str, Any]) - Dict[str, Any]: state[info] state.get(info, ) db_result; return state def send_email(state: Dict[str, Any]) - Dict[str, Any]: state[email_sent] True return state ACTIONS { search_web: search_web, query_db: query_db, send_email: send_email, } def is_goal(state: Dict[str, Any]) - bool: return state.get(email_sent, False) and db_result in state.get(info, ) def dfs( state: Dict[str, Any], path: List[str], depth: int, max_depth: int, solutions: List[List[str]], ) - None: if solutions: # 找到一条可行路径即可返回 return if is_goal(state): solutions.append(path[:]) return if depth max_depth: return for name, action in ACTIONS.items(): if path and path[-1] name: continue # 简单剪枝避免连续执行同一动作 next_state dict(state) # 分支之间隔离状态 action(next_state) dfs(next_state, path [name], depth 1, max_depth, solutions) def main(): init_state {info: , email_sent: False} solutions: List[List[str]] [] dfs(init_state, [], 0, 5, solutions) print(找到的可行路径, solutions[0] if solutions else 无) if __name__ __main__: main()运行后会输出一条可行路径比如[query_db, send_email]。这个示例的价值不在于算法本身而在于理解状态复制、分支隔离、剪枝、终止条件这四个搜索组件。在真实项目里LLM 负责生成候选动作评判函数负责给状态打分而搜索框架负责管理探索。你不需要把 DFS 改成多复杂关键是把 Agent 的试错过程从随机重试改成有结构的搜索。4.4 搜索的真正价值用探索弥补模型盲区搜索和推理最大的区别可以用两句话概括推理是对已知路径的深化搜索是对未知路径的拓展。一个 Agent 在工具调用中反复失败时最常见的本能是换一种说法再调一次这本质是随机重试而引入搜索之后系统会记住已经试过的后缀、分支、动作序列并基于探索策略决定下一步去哪。这里也有明显的代价搜索意味着多次调用模型延迟和成本都会上涨。所以在实际工程里通常只会对高价值且高失败率的任务开启搜索而不是对每个请求都做。这个取舍意识也是完整学习 CS329A 时值得重点体会的。5. 强化学习RLAgent 实现自我改进的真正引擎5.1 生成式模型为什么改不动自己推理和搜索都发生在决策时也就是用户请求到来之后。它们能提高单次表现但不会改变模型本身的参数。这意味着一个今天是二流水平的模型明天还是二流水平除非有人在训练阶段做点什么。这个在训练阶段改变模型的机制就是强化学习。很多工程师对 RL 的第一反应是RLHF 嘛让模型回答更符合人类偏好。这没错但只是 RL 的一个应用。对 Agent 来说RL 更关键的用途是把搜索到的好路径固化成策略。搜索负责找到一条好的试错路径而 RL 负责让模型以后不需要搜索也能走这条路或者让模型在同样的起点上更愿意生成好的动作。5.2 RLHF 之后的推理强化学习最近两年有个明显趋势多家头部模型把强化学习用于推理而不是对话讨好。比如 RLVRReinforcement Learning with Verifiable Rewards用规则验证器或代码执行结果作为奖励信号训练模型生成更长的推理链、更准确的工具调用序列。这种训练方式不依赖昂贵的人类偏好打分因为奖励是客观可验证的代码跑通了就是 1跑不通就是 0。这给 Agent 开发带来的启示非常直接如果你能定义什么是一次成功的 Agent 执行你就能把大量历史轨迹转成训练数据用 RL 让模型在统计意义上更擅长这类任务。这比在 prompt 里写一百条不要这样做要可靠得多。5.3 示例用 TRL 搭建一个最小 PPO 训练流程下面以 Hugging Face TRL 库为例给一个最小 PPO 训练骨架。注意 TRL 不同版本 API 有差异代码中的超参数不是最优值请以实际版本为准# 文件路径examples/rl_agent_ppo.py 最小 PPO 训练骨架对一个 Agent 任务样本做策略优化。 依赖transformers、trl具体版本请自查官方文档。 from transformers import AutoTokenizer from trl import PPOConfig, PPOTrainer, AutoModelForCausalLMWithValueHead # 1. 加载基座模型生产环境建议使用经过 SFT 的模型而不是从零训练 model_name your-base-model # 例如 Qwen/Qwen2.5-7B-Instruct model AutoModelForCausalLMWithValueHead.from_pretrained(model_name) tokenizer AutoTokenizer.from_pretrained(model_name) # 2. 配置 PPO 超参数 config PPOConfig( batch_size8, learning_rate1.41e-5, ppo_epochs4, log_withtensorboard, ) ppo_trainer PPOTrainer( configconfig, modelmodel, tokenizertokenizer, ) # 3. 构造一条 Agent 任务样本 query 请写一个 Python 函数从 JSON 文件中读取配置并返回键值对。 response ( def load_config(path):\n import json\n with open(path) as f:\n return json.load(f) ) query_tensor ppo_trainer.tokenizer.encode(query, return_tensorspt) response_tensor ppo_trainer.tokenizer.encode(response, return_tensorspt) # 4. 规则函数计算 reward真实项目可换成偏好模型或验证器 def compute_reward(text: str) - float: if def in text and json.load in text: return 1.0 return -1.0 reward compute_reward(response) # 5. 执行一次 PPO 更新回调中会自动完成 logits 和 KL 约束相关计算 ppo_trainer.step([query_tensor], [response_tensor], [reward])这段代码的核心要点不是让你马上跑通训练而是理解 RL 训练的数据形态一条query、一条response、一个reward。在真实 Agent 项目中这三样东西从一个大的轨迹数据集里批量产生——比如让现有 Agent 跑 10 万条任务用规则或验证器给每条轨迹打分再拿高分轨迹做策略优化。5.4 RL 的门槛数据、算力、稳定性说句实在话RL 是三个支柱里门槛最高的。它需要高质量奖励信号、足够的基座模型、可接受的训练成本还要面对训练稳定性问题。对大多数中小团队来说直接训练自己的 RL 模型并不现实。但这不代表不需要学如果你在评估和微调开源推理模型理解 RL 能让你读懂技术报告里模型是怎么变强的如果你接的是大模型 API理解 RL 能帮你设计更好的 reward 采集策略把模型不够强的问题反向反馈给模型服务提供方。6. 从推理、搜索到强化学习三者如何闭环6.1 三个能力的分工把三章内容放到一起可以这样理解推理给 Agent 提供了单步思考质量决定它每一步走得稳不稳。搜索给 Agent 提供了多步探索能力决定它在走错之后能不能换路。强化学习给 Agent 提供了长期学习机制决定它对这类任务会不会越来越熟练。三者各管一个环节但真正让 Agent 发生质变的是它们组合成闭环之后的效果。单独用任何一块都只是在局部优化。6.2 闭环循环一个代码生成 Agent 的自改进过程假设你正在做一个自动修 bug 的 Agent初始模型看到报错信息直接生成修复代码。这是最朴素的推理。如果修复失败Agent 进入搜索模式生成多种候选修复方案用编译器和测试用例快速验证记录哪些方案跑通了哪些没有。这是搜索。把跑通的修复方案和对应的原始报错组装成数据用规则奖励给高分比如测试全部通过然后用 RL 对模型做一轮策略更新。这是强化学习。更新后的模型再遇到类似报错可能第一步就直接生成正确修复不再需要走一遍完整搜索。这个过程就是一个自我改进闭环搜索负责产生经验验证器负责判断经验好坏RL 负责把经验沉淀成模型能力然后新一轮推理变强搜索范围可以变得更小、更高效。6.3 为什么说这是自我改进 Agent的技术内核如果把自我改进拆开看它包含三个动作探索新的行为、评估行为好坏、把好行为变成默认行为。这三个动作刚好对应搜索、推理或验证器判断、强化学习。换句话说CS329A 课程标题里的从推理、搜索到强化学习不只是罗列三个技术方向它正是在讲一套让 Agent 不断变强的循环机制。理解了这个闭环再回头看你手头的 Agent 项目就会有一个新的诊断框架如果 Agent 表现不稳定问题可能出在推理不够充分如果它在复杂任务里经常找不到出路问题可能出在没有搜索机制如果它同样的错误反复犯问题大概率出在没有学习机制。这套框架比继续调 prompt有用得多。7. 学了 CS329A 能做什么场景、边界与工程落地7.1 最值得优先尝试的场景CS329A 覆盖的技术最适合以下三类场景复杂工具调用类 Agent比如多个 API 的组合编排、任务拆解后按序执行。搜索和 RL 都能显著改善这类场景的稳定性。代码生成与代码修复代码天然有客观验证编译、测试、运行结果非常适合 RLVR 方法也是目前推理模型强化主要的应用战场。需要长程规划的业务流程比如自动报表、自动化运维排查、数据处理管线。这些任务路径长、分支多单纯 CoT 不够需要搜索机制介入。7.2 不适合的场景与成本警报也要冷静一点如果任务只是从文档里抽答案或改写一段文案推理、搜索、RL 这三件套都是超配。这类任务用 RAG 加精心设计的 prompt 已经足够加搜索反而增加延迟和成本。成本上搜索会让一次请求的模型调用次数从 1 变成 NRL 更是烧 GPU 的活。工程上的判断标准很简单只有当 Agent 错误带来的代价时间、钱、用户体验大于搜索或训练的成本时才值得引入这些机制。7.3 工程化落地的六个建议这套建议更多来自 Agent 工程实践中的通用经验具体约束条件会因为项目类型不同而变化但实施优先级基本是稳定的评估先行。任何 Agent 改造先建一个几十到几百条样本的评测集量化基线准确率、失败率、平均调用次数。不要在看不到效果的情况下盲目加复杂度。日志记录。把模型的原始输入、工具调用链、中间结果、最终输出全部落盘。没有日志所谓改进只是感觉。可观测的奖励信号。定义清楚成功的客观标准优先用规则验证器而不是人的主观印象。渐进引入。先做推理增强Self-Consistency 最便宜再在最高价值任务上做搜索最后再考虑 RL。设置安全边界。对会执行代码、发消息、改数据的 Agent加权限限制、确认环节和最大步数限制。保留回滚路径。新策略上线前做 A/B 对比任何时候可以切回旧 prompt 或旧模型版本。8. 常见问题与学习避坑指南8.1 常见问题排查表现象可能原因排查方式解决方案推理结果不稳定temperature 为 0多次采样无多样性检查 call_llm 的采样参数调高 temperature引入 Self-Consistency搜索分支过多导致超时没有剪枝和深度限制查看搜索日志中的扩展节点数加入最大深度、启发式剪枝、动作去重RL 训练不收敛reward 信号太稀疏或噪声大统计 reward 分布检查正负样本比设计更密集的奖励或改用规则验证器多轮工具调用丢失上下文上下文长度超出模型窗口查看工具调用链是否被截断压缩中间结果、按需摘要、减少无用步骤模型反复犯同一个错误停留在 prompt 层没有训练机制统计错误类型分布把错误轨迹加入搜索候选池或训练数据成本暴涨搜索采样数设置太高监控每次请求的 LLM 调用次数分级策略低价值任务不开搜索8.2 学习路径建议如果你准备把 CS329A 这条主线真正消化掉建议按这个顺序走先动手做一个大模型 工具调用的最简 Agent理解 baseline。做推理增强实现 CoT、Self-Consistency、Self-Refine量化它们对准确率的影响。选一个 Agent 任务引入搜索先做 Best-of-N再尝试 MCTS 或其他树搜索框架。用开源小模型跑一个 RLVR 实验比如让模型生成正确的字符串或简单代码用规则验证器打分。再回去读推理模型的技术材料你会发现很多概念不再是黑话。避坑提醒不要一开始就去复现大规模 RL 训练成本高、调试难。先用小模型、小验证集把机制跑通再迁移到更大的场景。学习过程也建议以周为单位评估进展不要指望两天吃透全部内容。真正有价值的是每做完一步都能回答它到底改进了什么、代价是什么——这种基于实验的体会比单纯读完所有概念重要得多。9. 总结Agent 开发的下一个分水岭回到开头的问题为什么你搭的 Agent demo 能跑、生产上却不好用因为它只有大模型 prompt 工具这种静态结构缺的是推理的深度、搜索的广度、学习的机制。CS329A 这门课真正有价值的地方不在于教你某个具体框架的 API而在于给了下一代 Agent 开发一张完整的技术坐标系推理负责单步质量搜索负责路径探索强化学习负责经验沉淀。三者组成的生成 - 评估 - 学习闭环才是自我改进 Agent这个说法落到技术层面的真实含义。如果你只记住一件事我建议记住这句话Agent 的下一个分水岭不是模型回答得更流利而是系统有没有办法让模型在复杂的真实任务里——想得更深、试得更全、错得更少。建议收藏这篇文章等开始设计自己的 Agent 评估集或奖励信号时再回来对照看看会有更具体的体感。