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

第一部分Planner——Agent 的决策大脑1.1 Planner 是什么最常见的误解Planner 就是“任务拆解”。真正的定义Planner 的本质是决策Decision Making而不是简单的拆分。它负责回答“当前应该做什么”。Planner vs ExecutorPlannerExecutor职责决定下一步做什么真正去执行输出任务计划Task List执行结果Observation比喻大脑思考手脚行动1.2 为什么 Workflow 不能代替 PlannerWorkflow 和 Graph 的根本局限路径是预设的。Workflow流程固定遇到未预设的需求会走错路Graph支持条件分支但分支逻辑仍需提前定义Planner动态理解用户意图生成全新的执行计划对比示例用户说“帮我生成简历再帮我模拟面试再给职业建议。”这是一个复合任务Workflow 无法同时处理三条完全不同的执行路径。Planner 却能动态规划出三个 Task 序列。1.3 Planner 规划的是 Task不是 ToolTask任务Tool工具是什么要完成的一个语义步骤执行任务的具体能力谁决定PlannerExecutor例子“分析 JD”jd_analysis()函数分层流程Planner → 生成 Task 列表 Executor → 为每个 Task 选择对应的 Tool Tool → 执行具体操作1.4 为什么 Planner 一定要 LLMPlanner 不是 Router是 Reasoner。RouterReasoner根据关键词选分支理解意图后推理固定规则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面试第一问ContextMemory生命周期单次会话跨会话持久存在存储方式拼在 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 ≠ MemoryWorkflow StateAgent Memory生命周期Workflow 执行期间Agent 整个生命周期可见范围当前 Skill 内部所有 Skill 共享持久化流程结束即回收跨会话持久保存关键设计原则Memory 属于 Agent 层由 Memory Manager 统一管理不应下沉到 Workflow。2.4 Memory 工程设计要点写入时机重要信息触发写入新用户属性、对话轮次超阈值而非每轮强制存储。读取时机Planner 规划前统一读取 Profile SummarySkill 按需拉取 Retrieval。避免膨胀淘汰策略Conversation 只保留最近 N 轮压缩策略Summary 替代原始长对话去重策略Profile 更新时合并相同属性百万用户隔离方案组件技术选型隔离方式作用SessionRedissession_id临时对话TTL 过期持久存储PostgreSQLuser_idProfile、Summary向量检索Milvus/PineconeNamespace按用户隔离知识库热缓存Redisuser_id频繁访问数据加速第三部分Reflection——Agent 的自我意识3.1 为什么需要 ReflectionLLM 的根本矛盾会生成不会判断。LLM 的本质是预测下一个 token它的核心能力是“造句”而非“答题”。第一次生成的内容只是一个“候选答案”不是“最终答案”。Reflection 补上了“判断”的缺失——让 Agent 能在生成后审视不足定点修正。人类的工作模式打草稿 → 检查 → 修改Agent 的工作模式Generate → Reflect → Refine3.2 Retry vs Reflection面试高频维度RetryReflection核心动作重新执行先评价再决定如何重新执行是否改变策略否是适用场景临时性系统故障输出质量不满足要求本质工程容错智能闭环优化一句话区分Retry不改变策略只是“再试一次”Reflection先分析“为什么错”再“换种方式做”3.3 Reflection 的三层粒度层级检查范围行动Node Reflection单个步骤的输出重做当前步骤Workflow Reflection单个 Skill 的整体结果回退到 Skill 内部某步骤Planner Reflection整个任务计划的合理性重新规划全局任务分层优势Node 层快速拦截单步错误Workflow 层定点修复流程问题Planner 层调整全局策略3.4 Reflection 检查的四个维度维度含义示例Completeness有没有遗漏JD 要求 Docker简历没写Correctness有没有错误用户做 Java简历写 PythonConsistency前后是否一致第一页 Java第二页 PythonQuality表达是否专业口语化、重复啰嗦3.5 为什么 Reflection 不能无限循环成本爆炸每次 Reflection 都是一次 LLM 调用收益递减第一次改进最明显第三次可能更差跑偏风险过度修改可能偏离原始目标工程实践设置最大循环次数如 2 次、质量阈值超 8 分停止、Token 预算超限强制终止。第四部分三者协作——Agent 的完整闭环现代 Agent 的 PDCA 循环PDCAAgent 对应PlanPlanner 制定任务计划DoExecutor/Workflow 执行CheckReflection 评估输出质量Act重新 Planner 或 Workflow定点修复完整数据流用户输入 ↓ Planner ←────────── Memory规划前读取画像和历史 ↓ WorkflowSkill 内部流程 ↓ Node具体功能执行 ↓ Result ↓ Reflection多层评估 ↓ Memory Update重要信息持久化 ↓ Planner根据 Reflection 结果决定下一步核心关系总结Planner 是大脑决定做什么Memory 是海马体记住该记住的忘掉该忘掉的Reflection 是自我意识审视自己修正错误三者缺一不可没有 Planner 是盲目的没有 Memory 是健忘的没有 Reflection 是鲁莽的