[LLM Agents SP25] Reasoning, Memory & Planning of Language Agents

LaTeX 源码 · 备用 PDF · 观看视频

字段	内容
作者/整理	基于 Yu Su 授课内容整理
来源	Berkeley RDI
日期	2026-04-02

课程定位与核心命题

本讲由 Ohio State University 的 Yu Su 教授主讲，主题是语言智能体（Language Agents）的三个关键能力：Reasoning、Memory 与 Planning。授课并没有把 Agent 当作单一产品形态，而是将其作为一个可扩展的系统对象：模型需要在动态环境中持续感知、决策、执行、复盘和改进。

本讲核心主张

“Reasoning is for better acting.” 推理不是为了在纸面题目上展示步骤，而是为了在真实环境中做出更好的动作选择。对应地，Memory 不是日志堆积，Planning 也不是静态步骤列表；它们都服务于长期任务成功率与稳定性。

Yu Su 先回顾了过去两年 Agent 热潮中常见的叙事偏差：一方面，外界对 “2025 是 Agent 元年” 的预期极高；另一方面，团队在生产实践中经常面对成本失控、长链路任务崩溃和评测口径不稳定等问题。课程的价值就在于用工程化框架替代口号化叙事。

高热度不等于高可用

Demo 成功不代表任务分布下的稳定成功；
单次推理质量高不代表多轮执行质量高；
模型分数领先不代表系统总成本可接受。

本章小结

本章明确了整讲的判断标准：Agent 研究应以系统行为质量为中心，而不是以孤立模型能力为中心。后续关于 Reasoning、Memory、Planning 的讨论，均围绕 “如何提升真实任务成功率” 展开。

Agent-First 视角下的问题重构

从模型中心到系统中心

课程提出 “Agent-first” 视角：将智能体视作一个持续运行的决策系统，而非一次性问答接口。该系统至少包含五个基本要素：状态表示、动作空间、记忆机制、规划机制与外部反馈回路。只有这五个要素协同，Agent 才能跨越短任务到长任务的鸿沟。

Agent 的最小系统抽象

可以将语言智能体简化为如下循环：

\[ \text{Observe} \rightarrow \text{Reason} \rightarrow \text{Act} \rightarrow \text{Update Memory} \rightarrow \text{Replan} \]

其中每个环节都可被独立增强，但系统性能取决于各环节之间的接口质量和延迟成本。

历史脉络与范式演进

从早期 AutoGPT 到当前结合 ReAct、Tool Use、Self-Reflection 的新系统，范式演进并不是 “算法替代算法”，更像 “能力叠加能力”。课程强调三种增长路径：推理质量增长、记忆可靠性增长、规划尺度增长。它们共同决定可解决任务的上限。

阶段	代表能力	主要瓶颈
早期 Agent 原型	Prompt + 工具调用	长链任务中易漂移、易死循环
中期工程化阶段	ReAct + Reflection + Retrieval	状态污染、成本高、调参复杂
当前系统化阶段	Reasoning actions + memory architecture + replanning	验证器质量与跨场景泛化仍不足

Language Agent 的工程演进，不是单点突破，而是系统要素同步升级

常见误解：把 Agent 当成“会调用工具的聊天机器人”

这类定义忽略了长期状态管理和规划反馈。真正的 Agent 系统必须显式处理失败恢复、策略切换、记忆更新和目标重设，否则能力会停留在短任务。

本章小结

Agent-first 视角把问题从 “模型会不会答” 转成 “系统能否稳定完成任务”。这为后续三大能力模块提供了统一评估口径。

Reasoning：从“会想”到“会做”

Reasoning 的工程目标

Yu Su 在课程中反复强调：Reasoning 的最终目标不是展示推理链，而是提高行动质量（Action Quality）。如果推理不能带来更好的动作序列、更低错误率或更高样本效率，那么该推理就是无效开销。

视频约 00:21:50 讲义页：Reasoning 与 Acting 的耦合关系是课程主轴

Reasoning for Acting

用推理提升动作选择质量，而不是增加表面思考长度；
推理应当可触发策略修正（replan）和工具切换（tool switch）；
推理的价值最终体现在成功率、成本与鲁棒性三项指标上。

从 CoT 到可执行推理

课程把 CoT、ReAct、Self-Reflection、Meta-Reasoning 放在同一连续谱中：它们本质上都是 “在动作前后注入结构化思考”。差异不在于是否推理，而在于推理如何连接环境状态和动作接口。

四类常见推理动作

任务分解：将复杂目标拆成可验证子目标；
证据对齐：用外部检索/工具输出修正内部假设；
失败归因：识别错误来源（知识缺失、工具失败、规划错误）；
策略改写：基于归因结果重写后续动作计划。

推理 Token 并非越多越好

在没有有效验证器与边界约束时，长推理链可能导致：

成本爆炸；
置信幻觉放大；
错误路径被 “解释得更像对”。

本章小结

Reasoning 是 Agent 的决策增益机制。真正重要的不是 “有没有推理”，而是 “推理是否改变了更优行动”。

Language 作为统一认知接口

为什么 Language 仍是中心媒介

课程指出，语言具备三重角色：状态编码介质、策略表达介质、协作协议介质。这使得语言不仅能承载自然语言解释，还能承载符号结构、程序片段与中间决策记录。

视频约 00:37:20 讲义页：课程将推理类型按作用位置与目标进行分层

语言接口的系统优势

跨模态统一：文本可作为视觉、代码、结构化数据的交换层；
跨模块统一：planner、memory manager、tool router 可共享同一种协议；
跨代理统一：multi-agent 协作可以先通过语言协议快速原型化。

符号推理与语言推理的融合

Yu Su 并未将 symbolic reasoning 与 neural reasoning 对立，而是强调 “分工融合”：语言推理负责高维语义压缩与策略探索，符号推理负责精确约束与可验证计算。二者结合是长链任务稳定性的关键。

融合策略示例

语言模型生成候选计划，符号模块做约束检查；
语言模型做启发式搜索，程序执行器做终局验证；
语言模型做错误解释，规则系统做安全拦截。

仅靠语言推理的边界

当任务需要高精度数值、强约束组合优化或形式化证明时，单纯自然语言链条容易失真，需要引入程序化中间表示。

本章小结

Language 不是 “提示词输入格式”，而是 Agent 系统的统一通信层。其价值在于连接不同能力模块，而非替代所有模块。

Memory：从上下文缓存到可持续知识底座

记忆分层设计

课程将 Memory 视为 Agent 稳定性的决定性因素。没有分层记忆，长任务会退化成 “每轮从零开始”。本讲建议至少区分：working memory、episodic memory、semantic memory、procedural memory。

视频约 00:52:40 讲义页：记忆模块不是单一向量库，而是层次化读写系统

记忆层	典型内容	工程重点
Working memory	当前步骤状态、临时变量	快速更新、低延迟、可裁剪
Episodic memory	任务轨迹、失败记录、决策分支	支持复盘与策略迁移
Semantic memory	稳定事实、领域知识、工具文档	检索精度与版本一致性
Procedural memory	可复用工作流、策略模板、工具调用范式	抽象粒度与触发条件设计

四层记忆在 Agent 系统中的分工

Memory 的本质是可控读写，不是单向存储

记忆系统必须回答四个问题：写什么、何时写、如何读、何时忘。若只做 “全量写入”，很快会出现噪声累积和检索错配，最终拖垮推理与规划质量。

Memory 操作的最小 API

write(event, importance, scope)：写入时附带重要性与作用域；
retrieve(query, budget, freshness)：检索时显式预算和时效约束；
compress(window)：按任务阶段进行摘要与压缩；
evict(policy)：执行过期淘汰与冲突合并。

记忆污染是长任务失败的隐蔽主因

若历史错误结论被反复检索，Agent 会稳定地做错事。应通过来源置信度、冲突检测和回滚机制降低污染传播。

本章小结

Memory 决定了 Agent 能否跨轮次、跨任务累积有效能力。分层、可控、可回滚是高质量记忆系统的三个底线。

Planning：长程任务中的策略控制器

规划的作用边界

课程将 Planning 定义为 “在约束下分配未来动作预算”，而非生成静态待办清单。高质量规划必须允许动态重规划（dynamic replanning），因为环境反馈会持续改变最优动作序列。

视频约 01:08:20 讲义页：规划需要与执行和反馈形成闭环，而非一次性展开

规划闭环的三个必要环节

目标分解：将最终目标映射为可验证中间里程碑；
执行监控：持续比较预期状态与真实状态；
计划改写：在偏差超阈值时触发重规划。

规划与搜索的结合

Yu Su 的观点是 “规划不是搜索的替代，搜索也不是规划的替代”。规划决定搜索空间结构，搜索决定局部动作最优。系统工程中应按任务复杂度选择是否引入 MCTS、beam search 或启发式候选生成。

何时需要显式搜索

行动后果延迟且不可逆；
局部最优陷阱明显；
单步评分器信号弱、噪声大。

过度规划的代价

过细粒度规划会占用大量上下文与计算预算，并削弱执行阶段的实时适应能力。规划粒度应与环境变化速率匹配。

规划器伪代码

一个简化的重规划循环，强调“偏差触发式更新”

state = observe()
plan = planner.make_plan(goal, state)

for step in range(budget):
    action = planner.next_action(plan, state)
    result = env.execute(action)
    state = update_state(state, result)
    memory.write(result)

    if planner.need_replan(state, goal):
        plan = planner.replan(goal, state, memory.retrieve(goal))

本章小结

Planning 的关键不在于 “提前想得多完整”，而在于 “执行中能否快速修正”。动态重规划是长程 Agent 成败分水岭。

Multi-Agent：协作增益与通信成本

何时使用多智能体

课程并不鼓励 “为并行而并行”。Multi-agent 适用于任务可分解、角色边界清晰、通信协议稳定的场景。若任务强耦合或中间状态高度共享，单体 Agent + 强 memory 往往更稳。

多智能体收益的来源

角色专门化降低单体策略复杂度；
并行探索提高候选解覆盖率；
交叉审阅减少单路径幻觉风险。

维度	单体 Agent	Multi-Agent
上下文管理	简单，但可能拥塞	分布式，但需同步协议
执行效率	串行，调试容易	并行潜力高，协调复杂
错误定位	集中式定位较直观	需区分角色错误与通信错误
成本结构	预测相对稳定	通信与重复推理开销高

单体与多体架构的取舍

多智能体系统的落地原则

先设计协议再增加角色。协议至少包括：消息格式、共享状态范围、冲突解决规则、超时与回退策略。

多智能体最常见失败模式

角色职责重叠，导致重复劳动；
通信信息膨胀，吞噬上下文预算；
缺少统一验收器，形成“彼此确认但整体错误”。

本章小结

Multi-agent 不是默认更强，而是条件性更强。关键在于任务分解质量和通信协议设计，而非 agent 数量本身。

评测与运维：把 Agent 变成可管理系统

评测必须覆盖全链路

Yu Su 提醒：只测最终答案会掩盖大量系统性问题。Agent 评测应覆盖 “轨迹质量”、“工具调用正确率”、“重规划触发质量” 和 “记忆读取准确率”。

评测口径建议

Outcome metrics：任务成功率、完成时延、总成本；
Process metrics：中间步骤正确率、无效动作率、反复重试率；
Safety metrics：越权调用率、敏感信息泄露率、错误恢复时间。

离线评测与在线评测的分工

离线：快速回归算法改动，定位模块问题；
在线：观测真实分布漂移，校正离线假设；
两者之间需共享统一事件 schema，否则难以闭环。

只看 leaderboard 的风险

高分可能来自任务模板拟合，而非真实泛化。生产系统必须对分布外任务建立降级策略和人工接管机制。

工程可观测性与故障恢复

稳定 Agent 需要细粒度 tracing：每步决策依据、调用工具、返回结果、记忆命中、计划变更都应可审计。否则定位问题只能靠复现猜测，迭代效率极低。

本章小结

评测和运维不是附加组件，而是 Agent 能否持续进化的基础设施。没有可观测性，就没有可控迭代。

案例拆解：Web、代码与研究三类任务

案例一：Web Agent 的长链交互

在 Web 场景中，Agent 往往需要跨页面导航、解析半结构化信息并完成多步决策。课程观点是，这类任务的失败通常不是 “模型不懂页面”，而是 “状态同步与计划更新不及时”。典型问题包括：页面 DOM 变化导致定位失效、登录态中断、同义目标词触发错误点击、以及工具返回值与视觉状态不一致。

Web Agent 的核心难点是“弱结构环境中的强闭环控制”

Agent 必须在不稳定的界面状态下持续完成 Observe-Reason-Act 闭环。若缺乏显式状态机和步骤级验证器，错误会跨轮扩散，最终表现为随机性失败。

一个可行策略是把页面操作划分为 “导航动作”、“提取动作”、“确认动作” 三类，并为每类动作配置不同验证逻辑。比如导航动作关注 URL/页面标题变化，提取动作关注字段完整性，确认动作关注业务约束是否满足。这样做可以降低 “一步错全盘错” 的概率。

Web Agent 评测建议

记录动作级成功率，而非只记录终局成功率；
统计重试次数与回退次数，评估计划稳定性；
按页面复杂度分桶，避免平均值掩盖难例。

案例二：Code Agent 的仓库级任务

代码任务看似结构化，但仓库级目标通常涉及跨文件依赖、隐式规范和历史约束。课程强调，Code Agent 的提升路径不只是 “更强代码生成”，而是 “更强的仓库状态理解 + 更强的验证反馈回路”。

只做单轮补丁会放大技术债

如果 Agent 只追求当前测试通过，而忽略架构一致性、命名规则和接口契约，短期成功会变成长期维护成本。Code Agent 需要把 lint、type check、unit test、integration test 联合作为验证器。

在实现层面，可将任务分为 “理解”、“修改”、“验证”、“复盘” 四阶段，并把每阶段输出写入 episodic memory。这样做的价值是：当任务失败时，系统可以定位到底是需求理解偏差、实现错误还是验证覆盖不足，从而触发针对性重规划。

Code Agent 的 memory 建议

semantic memory 存储项目规范、公共接口和历史决策；
episodic memory 存储本次任务的关键尝试与失败原因；
procedural memory 存储复用脚本（如回归测试工作流）。

案例三：Research Agent 的证据闭环

研究任务常被误判为 “纯 reasoning 问题”。Yu Su 的框架下，Research Agent 同样需要强 memory 与 planning：前者用于证据沉淀与冲突管理，后者用于研究路线切换和实验预算分配。

Research Agent 的关键不是“写得像论文”，而是“证据可追溯”

系统应为每条结论绑定来源、置信度和时间戳。否则，当检索语料更新或工具返回变化时，旧结论会在记忆层中持续污染后续推理。

一个实用做法是采用 “结论-证据-反证” 三元结构写入 memory：Agent 每次提出结论时必须附上支持证据与潜在反例。这能显著提升反思（reflection）阶段的有效性，降低 “解释型幻觉”。

任务类型	优先能力	首要风险
Web Agent	状态同步 + 动态重规划	页面漂移导致动作失效
Code Agent	验证闭环 + 仓库记忆	局部最优补丁侵蚀全局质量
Research Agent	证据管理 + 反思机制	无来源结论的记忆污染

三类代表任务的能力优先级差异

本章小结

三类任务的共同点是都需要系统闭环；差异在于验证器和记忆策略的设计重点不同。Agent 研发应按任务属性配置能力，而非追求单一通用模板。

实验设计：把“有效”变成可复现证据

实验矩阵设计

课程建议将 Agent 实验拆成 “能力变量” 与 “系统变量” 两组：能力变量包括 reasoning budget、memory 策略、planning 粒度；系统变量包括工具延迟、缓存命中率、并发策略和失败重试规则。只有同时控制两组变量，实验结论才有解释力。

最小可复现实验单元

固定任务集合与数据版本；
固定工具接口与权限边界；
固定模型版本与温度参数；
记录完整轨迹与中间状态。

实验项	对照设置	主指标	副指标
Reasoning budget	2k / 6k / 12k tokens	任务成功率	单任务成本
Memory policy	无记忆 / 检索记忆 / 分层记忆	长任务完成率	错误恢复时长
Planning policy	静态计划 / 动态重规划	平均步数	无效动作率
Verification depth	终局校验 / 步骤校验 / 双层校验	正确率	延迟

Agent 消融实验的基础矩阵

失败分类与归因方法

没有统一失败分类，实验就会陷入 “调参玄学”。推荐把失败划分为四类：感知失败、推理失败、执行失败、验证失败。每类失败对应不同修复动作，避免 “所有问题都加大模型” 的低效路径。

失败归因要做到“可执行”

归因结果应能直接映射到工程动作：

感知失败 \(\rightarrow\) 强化解析器与页面状态检查；
推理失败 \(\rightarrow\) 调整 reasoning 模板与反思触发；
执行失败 \(\rightarrow\) 工具封装与重试策略优化；
验证失败 \(\rightarrow\) 扩展校验器覆盖与错误阈值。

避免“成功样本偏见”

如果只分析成功轨迹，系统会误判自身鲁棒性。应优先分析高损失失败样本（高成本、长链路、不可恢复），这些样本决定生产可用性上限。

线上迭代节奏

课程并不建议一次性上线大改。更稳妥的路径是 “影子模式（shadow mode）\(\rightarrow\) 小流量灰度 \(\rightarrow\) 全量发布”。每个阶段都应有明确回滚条件，并持续监控任务级别 SLO。

线上监控建议

成功率下探阈值与自动降级策略；
成本突增阈值与预算闸门；
工具错误率阈值与熔断机制。

本章小结

实验设计的目标不是“证明系统很好”，而是“定位系统为何好/为何坏”。可复现、可归因、可回滚是 Agent 实验体系的三条底线。

部署蓝图：技术栈与组织协同

参考技术栈

结合课程观点，一个可落地的 Agent 栈可以分为六层：接口层、编排层、记忆层、工具层、验证层、观测层。每层都应具备最小自治能力，并通过稳定协议通信。

层级	核心职责	关键产物
接口层	接收任务、权限校验、输出格式化	Task spec、权限上下文
编排层	任务分解、路由、重规划触发	Action graph、执行计划
记忆层	分层读写、压缩、淘汰、冲突处理	记忆索引与摘要
工具层	统一工具协议、错误封装、重试	可调用 API catalog
验证层	终局与步骤验证、风险拦截	验证报告与风险标签
观测层	轨迹追踪、指标聚合、告警	Trace、Dashboard、审计日志

Agent 系统部署的六层参考结构

组织协同模型

Agent 项目常见组织问题是：模型组、平台组、业务组各自优化局部目标。课程启发是建立 “任务成功率” 为统一北极星指标，并让不同团队共享同一套轨迹数据和失败分类。

组织协同的三条实践

统一事件 schema，避免各组口径不一致；
统一回滚机制，确保线上风险可控；
统一优先级框架，以高损失失败优先修复。

治理与合规

在企业部署中，Agent 不只是技术问题，还涉及权限最小化、敏感数据处理、审计留痕和责任归属。课程建议在系统层内置治理能力，而不是上线后补丁式合规。

治理能力必须前置

没有权限分层，工具调用会出现越权风险；
没有审计日志，事故后难以完成责任追踪；
没有红线规则，模型异常可能快速扩散。

部署前检查清单

是否具备任务级回滚与人工接管？
是否具备步骤级日志与可复放轨迹？
是否具备预算闸门与故障熔断？
是否完成敏感场景红队测试？

本章小结

Agent 部署是 “技术 + 组织 + 治理” 的联动工程。只有将三者合并设计，系统才能稳定穿越从 Demo 到生产的断层。

术语与设计模式速查

核心术语对照

为避免团队在跨模块协作时出现语义偏差，本讲可提炼出一套最小术语表。建议在项目文档中固定这些术语定义，减少 “同名异义” 导致的沟通成本与实验偏差。

术语	课程语境中的含义	实现时的注意点
Reasoning action	用于改进后续动作质量的中间思考步骤	需绑定触发条件和预算上限
Reflection	对既有轨迹进行自检并尝试修正	需要失败信号，否则易空转
Replanning	因环境偏差而重写计划	要明确重规划阈值，避免频繁抖动
Working memory	当前步骤所需的短时上下文	控制容量，避免挤占关键信息
Episodic memory	任务过程中的事件与结果记录	需附来源和时间戳，支持复盘
Semantic memory	稳定事实与知识库内容	管理版本与冲突，防止旧知识污染
Procedural memory	可复用策略、流程和模板	维护触发条件，避免错误泛化
Verifier	验证中间或终局正确性的机制	验证器本身也需持续评估

Reasoning、Memory、Planning 相关术语的工程化解释

常见设计模式

课程实践可进一步沉淀为几种高频设计模式。它们不是银弹，但能显著降低从研究原型到生产系统的迁移摩擦。

四种常用设计模式

Plan-Execute-Verify：先计划、后执行、再验证，适合可验证任务；
Think-Act-Reflect：推理与执行交替，适合动态环境；
Retrieve-Reason-Write：先取证再推理，适合知识密集任务；
Shadow-to-Production：先影子评测再灰度上线，适合高风险业务。

模式复用时的边界条件

同一模式在不同任务分布下的效果可能相反。上线前应验证：任务可验证性、工具稳定性、延迟预算、权限约束是否满足模式前提。

本章小结

统一术语和设计模式能减少团队协作摩擦，提高实验可比性与系统可维护性。这也是 Agent 工程从“个体经验”走向“组织能力”的关键一步。

开放挑战与研究路线

课程给出的长期挑战

课程后段将挑战集中在三个层面：认知层（更可靠的推理）、系统层（更稳健的记忆与规划）、组织层（更可信的评测与部署）。

视频约 01:24:30 讲义页：未来方向聚焦在可靠推理、记忆治理与长程规划

未来两年的关键技术杠杆

可验证推理：把 reasoning 结果与形式化检查器连接；
记忆治理：解决污染传播、版本冲突和过期淘汰；
规划泛化：提升跨任务迁移能力，降低每任务重调成本。

为何“Reasoning + Memory + Planning”必须联合优化

单点优化很容易出现木桶效应：推理增强但记忆劣化，会放大错误；规划增强但验证器弱，会更快走偏。联合优化的目标是系统级稳定收益，而非局部峰值。

部署中的现实约束

企业场景往往存在严格延迟预算、权限边界和审计要求。研究原型若忽略这些约束，迁移到生产时会出现显著性能回撤。

本章小结

课程给出的路线不是追逐单一 SOTA，而是建设可验证、可回滚、可扩展的 Agent 系统栈。长期竞争力来自系统工程能力。

总结与延伸

全讲要点汇总

能力模块	课程核心判断	工程动作	主要风险
Reasoning	为了更好行动，不是为了更长思维链	引入反思、重规划与动作校验	Token 成本与幻觉放大
Memory	分层记忆是长任务稳定性核心	设计读写压缩淘汰策略	记忆污染与检索错配
Planning	动态规划优于静态清单	监控偏差并触发重规划	过度规划导致效率下降
Multi-agent	条件性增益，不是默认增益	先定协议，再增角色	通信开销与协作漂移
Evaluation	必须看全链路过程指标	建立 tracing 与统一 schema	只看终局分数导致误判

Reasoning、Memory、Planning 的系统化落地框架

一句话总结

Language Agent 的下一阶段竞争，不是谁能做出更炫的 demo，而是谁能把推理、记忆和规划做成可验证、可运维、可扩展的工程系统。

延伸阅读

Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models
Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning
Park et al., Generative Agents: Interactive Simulacra of Human Behavior
Wang et al., Voyager: An Open-Ended Embodied Agent with LLMs
OpenAI / Anthropic 关于 Agent tool-use 与 evaluation 的官方技术博客

进一步实践建议

在单体 Agent 上先完成 “可观测 + 可回滚” 的最小闭环，再引入多智能体；
先建设任务级验证器，再扩大 reasoning budget；
将记忆操作显式 API 化，避免隐式上下文堆积；
对生产场景建立人工接管与降级策略，优先保障可控性。