当前位置：首页 > news >正文

LLM 学习笔记 Day 5：Agent 核心组件——Planner、Memory 与 Reflection

news 2026/7/5 4:03:00

第一部分：Planner——Agent 的决策大脑

1.1 Planner 是什么？

最常见的误解：Planner 就是“任务拆解”。
真正的定义：Planner 的本质是决策（Decision Making），而不是简单的拆分。它负责回答“当前应该做什么”。

Planner vs Executor

Planner	Executor
职责	决定下一步做什么	真正去执行
输出	任务计划（Task List）	执行结果（Observation）
比喻	大脑思考	手脚行动

1.2 为什么 Workflow 不能代替 Planner？

Workflow 和 Graph 的根本局限：路径是预设的。

Workflow：流程固定，遇到未预设的需求会走错路
Graph：支持条件分支，但分支逻辑仍需提前定义
Planner：动态理解用户意图，生成全新的执行计划

对比示例：
用户说：“帮我生成简历，再帮我模拟面试，再给职业建议。”

这是一个复合任务，Workflow 无法同时处理三条完全不同的执行路径。Planner 却能动态规划出三个 Task 序列。

1.3 Planner 规划的是 Task，不是 Tool

Task（任务）	Tool（工具）
是什么	要完成的一个语义步骤	执行任务的具体能力
谁决定	Planner	Executor
例子	“分析 JD”	`jd_analysis()`函数

分层流程：

Planner → 生成 Task 列表 Executor → 为每个 Task 选择对应的 Tool Tool → 执行具体操作

1.4 为什么 Planner 一定要 LLM？

Planner 不是 Router，是 Reasoner。

Router	Reasoner
根据关键词选分支	理解意图后推理
固定规则（if…else）	动态生成
只能处理见过的场景	能处理全新场景

关键词匹配只会触发相关流程。
LLM Planner能理解

1.5 Planner 分层设计（以简历生成 Agent 为例）

Planner（制定跨 Skill 计划） ↓ Tool Router（将 Task 映射到 Tool） ↓ Workflow/Graph（控制单个 Skill 内部流程） ↓ Node（完成具体功能） ↓ Tool（调用外部能力）

关键设计原则：

Planner 放最外层：它是唯一能理解用户全局意图的模块
Workflow 只负责一个 Skill：各 Skill 流程独立，避免“超级分支树”
Skill 内部用 Graph 而非 Planner：固定流程不需要动态决策
Node 不能决定调用 Skill：士兵不能决定打仗策略
Reflection 放 Planner 后：评估的是整体质量，不是局部正确性

第二部分：Memory——Agent 的记忆系统

2.1 Context ≠ Memory（面试第一问）

Context	Memory
生命周期	单次会话	跨会话持久存在
存储方式	拼在 Prompt 里	存在数据库/向量库
类比	看着聊天记录回答	记住了一个朋友的名字

Context：每次把完整聊天记录拼进 Prompt，模型是“重新看了一遍”，不是“记住了”。

Memory：昨天说你叫小明，今天新开窗口，Agent 依然知道。这才是真正的记忆。

2.2 Agent 的四层 Memory

第一层：Conversation Memory（对话记忆）

本质：最近几轮的原始对话记录
作用：维持多轮对话的连贯性
存储：保留最近 k 轮，存在 Session 中

第二层：Summary Memory（摘要记忆）

本质：用 LLM 对长对话做阶段性总结
作用：降低 Token 成本，保留关键信息
触发：对话轮次超阈值或遇到自然断点时压缩

第三层：Profile Memory（用户画像记忆）

本质：长期不变的用户基本信息（学历、技能、偏好）
作用：建立长期用户画像，支撑个性化服务
更新：极少更新，半年不变

第四层：Retrieval Memory（检索记忆）

本质：基于向量相似度的语义记忆（RAG 的思想基础）
作用：为 Agent 提供海量外部知识的动态检索
存储：向量数据库

2.3 Workflow State ≠ Memory

Workflow State	Agent Memory
生命周期	Workflow 执行期间	Agent 整个生命周期
可见范围	当前 Skill 内部	所有 Skill 共享
持久化	流程结束即回收	跨会话持久保存

关键设计原则：Memory 属于 Agent 层，由 Memory Manager 统一管理，不应下沉到 Workflow。

2.4 Memory 工程设计要点

写入时机：重要信息触发写入（新用户属性、对话轮次超阈值），而非每轮强制存储。

读取时机：Planner 规划前统一读取 Profile + Summary，Skill 按需拉取 Retrieval。

避免膨胀：

淘汰策略：Conversation 只保留最近 N 轮
压缩策略：Summary 替代原始长对话
去重策略：Profile 更新时合并相同属性

百万用户隔离方案：

组件	技术选型	隔离方式	作用
Session	Redis	session_id	临时对话，TTL 过期
持久存储	PostgreSQL	user_id	Profile、Summary
向量检索	Milvus/Pinecone	Namespace	按用户隔离知识库
热缓存	Redis	user_id	频繁访问数据加速

第三部分：Reflection——Agent 的自我意识

3.1 为什么需要 Reflection？

LLM 的根本矛盾：会生成，不会判断。

LLM 的本质是预测下一个 token，它的核心能力是“造句”而非“答题”。第一次生成的内容只是一个“候选答案”，不是“最终答案”。

Reflection 补上了“判断”的缺失——让 Agent 能在生成后审视不足，定点修正。

人类的工作模式：打草稿 → 检查 → 修改
Agent 的工作模式：Generate → Reflect → Refine

3.2 Retry vs Reflection（面试高频）

维度	Retry	Reflection
核心动作	重新执行	先评价，再决定如何重新执行
是否改变策略	否	是
适用场景	临时性系统故障	输出质量不满足要求
本质	工程容错	智能闭环优化

一句话区分：

Retry：不改变策略，只是“再试一次”
Reflection：先分析“为什么错”，再“换种方式做”

3.3 Reflection 的三层粒度

层级	检查范围	行动
Node Reflection	单个步骤的输出	重做当前步骤
Workflow Reflection	单个 Skill 的整体结果	回退到 Skill 内部某步骤
Planner Reflection	整个任务计划的合理性	重新规划全局任务

分层优势：

Node 层快速拦截单步错误
Workflow 层定点修复流程问题
Planner 层调整全局策略

3.4 Reflection 检查的四个维度

维度	含义	示例
Completeness	有没有遗漏？	JD 要求 Docker，简历没写
Correctness	有没有错误？	用户做 Java，简历写 Python
Consistency	前后是否一致？	第一页 Java，第二页 Python
Quality	表达是否专业？	口语化、重复啰嗦

3.5 为什么 Reflection 不能无限循环？

成本爆炸：每次 Reflection 都是一次 LLM 调用
收益递减：第一次改进最明显，第三次可能更差
跑偏风险：过度修改可能偏离原始目标

工程实践：设置最大循环次数（如 2 次）、质量阈值（超 8 分停止）、Token 预算超限强制终止。

第四部分：三者协作——Agent 的完整闭环

现代 Agent 的 PDCA 循环

PDCA	Agent 对应
Plan	Planner 制定任务计划
Do	Executor/Workflow 执行
Check	Reflection 评估输出质量
Act	重新 Planner 或 Workflow，定点修复

完整数据流

用户输入 ↓ Planner ←────────── Memory（规划前读取画像和历史） ↓ Workflow（Skill 内部流程） ↓ Node（具体功能执行） ↓ Result ↓ Reflection（多层评估） ↓ Memory Update（重要信息持久化） ↓ Planner（根据 Reflection 结果决定下一步）