Agent 与记忆系统

1. 长期记忆 vs 短期记忆

• 短期记忆：MySQL 会话表+消息表，滑动窗口保留最近 5 轮，每 5 轮生成摘要（AI 总结）防上下文爆炸。
• 长期记忆：Weaviate 向量化，分 6 类型（人物/地点/偏好/承诺/学习/事实），各有重要性阈值+保留天数；模型回复后做重要性评估，关键事实写长期库，主题脉络沉淀摘要。
• 管理策略：生命周期（创建→评估→迁移→压缩→归档→删除），冲突偏好用时间衰减系数不物理覆盖。

记忆类型表

💡 深入理解 · 为什么向量库+摘要而非 MySQL 筛历史？ ① "前天那个几何题"是模糊自然语言，MySQL 只能 LIKE 或 Text-to-SQL 容错低，向量库语义检索能理解；② Token 限制+Lost in Middle，原始记录全塞超窗口失焦，摘要=信息提纯。

2. 意图识别与路由

首页总控 Agent = 意图路由。轻量提示词把输入分类为预设意图（拍照搜题/写作辅导/判题），匹配成功返回统一路由 Schema 给前端跳转；未匹配大模型自由对话兜底。越界输入引入 Guardrails 安全护栏，强化角色边界礼貌拒绝。

3. Agent 规划能力

本质是把大模型"直觉生成"转成"逻辑搜索"。简单任务用 ReAct；复杂决策用 ToT/GoT（思维树/图）搜索；工业级高稳定用 Plan-and-Execute + Self-Reflection。

4. ReAct vs Plan-and-Execute

• ReAct（边做边想）：Thought→Action→Observation→下一轮。优点灵活实时纠错；缺点易死循环/跑偏、token 消耗大（每轮带全历史）。
• Plan-and-Execute（谋定后动）：Plan→Execute→Re-plan。优点逻辑清晰适合长链条、可并行；缺点缺乏灵活，第一步错则后续徒劳。

4b. 规划范式 CoT / ToT / GoT / Reflection

给 LLM 规划能力的主流方法，本质是把"直觉生成"变"结构化搜索"：
- CoT 思维链：让模型"一步步想"，把推理过程写出来（线性单链）。只是把推理显式化。
- ToT 思维树：每步生成多个候选分支，可回溯、剪枝，搜索多条路径选最优（适合有多种解法的问题）。
- GoT 思维图：比树更灵活，节点间任意连接，可合并不同推理路径的中间结论。
- Plan-and-Solve：先规划（把问题分解成清晰分步计划）再执行（严格按步骤走）。
- Reflection 反思：执行→反思（自我批判找错）→优化，迭代改进输出。

💡 深入理解 · CoT 和 Planning 的本质区别→ CoT 只是"把推理过程写出来"（线性、一次性、不可执行）；Planning 是生成一个"可执行的任务表"（结构化、分步、可调度可回溯）。例：CoT 是"我想想这题…先算 A 再算 B 得 C"；Planning 是"①调工具查 A ②用 A 查 B ③汇总"，每步可被单独执行和验证。

4c. 多 Agent 动态路由

多 Agent 里的动态路由 = 总控/路由节点根据意图或上下文条件，把任务分发到不同子 Agent 分支。实现：① LangGraph 用条件边（conditional edge），路由函数返回下一个节点名 ② 或路由 LLM 输出结构化决策（走哪个分支）③ 分支执行后可汇聚回主流程。和意图识别是一回事，只是粒度到"选哪个 Agent/工具链"。

4d. Agent 微调

什么时候要微调 Agent？ 基座模型识别不了特定领域工具、Agent 稳定性不够时。两种：
- 高效微调（SFT/LoRA）：核心是数据质量与覆盖度。构造"工具调用微调数据集"，让模型学会在一个对话里合理组合多个工具、稳定多步调用。
- 强化学习微调（RLHF/RLAIF）：把工具调用准确率、任务完成率、调用链合理性作奖励函数，让模型在环境里试错优化。

4e. 规划/反思进阶：LLM+P、Reflexion、常见框架

任务分解的四种做法：① CoT 提示"think step by step" ② 简单提示"Steps for XYZ:\n1." ③ 针对任务的指令（"先写故事大纲"）④ 用户直接输入拆好的步骤。
LLM+P（外部规划器）：长序列规划外包给经典 Planner——LLM 把问题翻译成 PDDL（规划域定义语言）→ 经典 Planner 求最优计划 → LLM 再把计划翻译回自然语言。适合需要严格最优规划的长任务，前提是有领域 PDDL 和合适 Planner。
Reflexion（自我反思框架）：ReAct + 动态记忆 + 二元奖励。每个 action 后算启发式函数，判断轨迹是否低效（耗时久没成功）或幻觉（反复同样动作得同样观察），决定是否重启循环；反思结果（失败轨迹→理想反思）写入工作记忆作为后续上下文（最多 3 条）。本质是产 RL 数据自我改进，不需人类反馈。
Agent 三大能力：推理（reasoning）+ 模仿（few-shot learning）+ 规划（planning），再结合 Function Calling 实现工具使用。
常见多 Agent 框架：AutoGPT、AutoGen（微软）、ChatDev/XAgent（面壁）、GPT-engineer、MetaGPT。

4f. 从 AI-Coding 转 Agent 开发：知识地图 + 学习路线

真题原型："只有 AI-Coding（用 Cursor/Claude Code 写代码）经验，公司要我做 Agent 提速工作流程，开发 Agent 要涉及哪些知识？" 这题考的是知识体系完整度，不是某个点——答不全等于"只会用工具不会造工具"。

先摆结论：AI-Coding 是"用别人造好的 Agent"，Agent 开发是"造一个 Agent"。你已有的经验能迁移一半，缺的是另一半。分三句话答：① 能迁移什么 ② 缺什么核心知识 ③ 用什么框架落地。

① 能迁移的（别妄自菲薄）：用过 Claude Code / Cursor 就已经从用户视角理解了 Agent 的运行形态——ReAct 循环、工具调用、上下文治理、CLAUDE.md 记忆、MCP 接工具、子代理并行。这些"看过 Agent 怎么跑"的直觉正是造 Agent 的起点（详见 17-ClaudeCode原理 / 13-Harness）。

② 要补的六块核心知识（Agent 开发知识栈）：

💡 深入理解 · 和 AI-Coding 最大的认知差：用 Cursor 是"人在循环里"（human-in-the-loop，你审每一步）；造 Agent 是"让它自己在循环里连续行动"，所以多出来的活全是"没人盯着时怎么保证它做对"——护栏、评估、恢复、状态管理。这正是 13-Harness 工程 的主战场（"模型开始连续行动，谁来监督约束它"）。

③ 用什么框架落地——OpenAI Agents SDK（用户给的参考，主流轻量方案）：Swarm 的生产级升级，极少抽象、Python/TS 原生，围绕六大原语 + 一个内建循环：

Run Loop（核心）：SDK 内建执行循环——调工具 → 结果回喂 LLM → 继续，直到任务完成；tools/handoffs/审批/流式全建在这个循环之上。Agent + Runner 帮你托管 turns/工具/护栏/交接/会话；想自己掌控循环就直接用 Responses API。这和 17 Claude Code 单线程主循环、18 OpenClaw 七阶段循环 是同一个东西——所有 Agent 框架内核都收敛到"ReAct for 循环 + 工具 + 记忆 + 护栏"。

💡 深入理解 · 框架选型一句话：轻量单/多 Agent、要代码原生细粒度控制 → OpenAI Agents SDK；复杂带环状态机/人机交互循环/可持久化回溯 → LangGraph；国内生态/低代码快速验证 → Dify（07）。别纠结框架，内核都一样，先用一个跑通再说。

④ 学习路线（被追"你打算怎么上手"时答）：① 用 Agents SDK 跑通"单 Agent + 2 个函数工具"的 Hello World → ② 加 Guardrails + Sessions 记忆 → ③ 加 Handoffs 做多 Agent 分工 → ④ 接 MCP 挂真实工具（内部 API）→ ⑤ 上 Tracing 看链路 + 建 Eval 集回归 → ⑥ 针对本司"工作流提速"的真实场景（自动整理周报/跑测试/查数）落一个小闭环。先窄后宽，一个真实场景端到端跑通胜过啃十篇文档。

❓ 常见追问 · AI-Coding 经验对做 Agent 有用吗？ → 非常有用。你已从用户视角理解了 ReAct 循环、工具调用、上下文治理、MCP——这是造 Agent 的直觉基础，差的是"无人盯守时保证做对"的那套工程（护栏/评估/恢复/状态管理）。
❓ 常见追问 · 不用框架能自己搭吗？ → 能，核心就是一个 while 循环（调 LLM→解析工具调用→执行→回喂→再调）。框架省掉重复造轮子（schema 生成、会话管理、追踪、护栏），生产建议用框架，但理解裸循环是根本。
❓ 常见追问 · 给工作流提速，用 Agent 还是 Workflow？ → 看确定性：步骤固定清晰用 Workflow（可靠），边界模糊需自主决策用 Agent；很多"提速"场景其实是 Workflow 为主 + 关键节点嵌 Agent（见 §5）。

5. Agent vs Workflow

• Workflow：确定性、线性，开发者预定义 DAG 按步执行，适合逻辑清晰高可靠。
• Agent：自发性、循环，模型作大脑自主决定调工具/反思/下一步，适合边界模糊复杂任务。

6. LangChain vs LangGraph

LangChain 是"线性流水线"，LangGraph 是"复杂网络地图"。

💡 深入理解 · LangGraph 三大能力：持久执行（故障中断处恢复）、人机协同（执行中检查修改状态）、全面记忆（短期工作记忆+跨会话长期记忆）。

6b. LangChain 核心组件与 8 种 Memory

核心组件：Component（模块化构建块）→ Chain（串起来完成任务，典型链=Prompt 模板+LLM+输出解析器）。六大能力域：LLM 与 Prompt、Chain、数据增强（RAG）、Agents、Memory、Evaluation。关键组件：Prompt Template、Example Selectors（动态选 few-shot）、Output Parsers、Indexes/Retrievers、Chat Message History、Agents/Toolkits（Agent 决策选工具，Agent Executor 驱动执行）。
三类 model 抽象：LLM（文本进文本出）、Chat Model（消息列表进出）、Text Embedding Model（文本转向量）。
❓ 常见追问 · LangChain 有什么坑？ → ① token 计数低效（改用 Tiktoken）② 概念过载、helper 函数多是标准 Python 薄包装 ③ 隐藏行为（ConversationRetrievalChain 自动重写问题，过度重写破坏连贯）④ 缺标准数据类型难集成。替代：LlamaIndex（数据框架）、Haystack（搜索问答）。

LangChain 8 种 Memory（多轮对话保持记忆的 8 种方式，本质是"信息完整度 vs token 成本"权衡）：
| # | Memory 类型 | 做法 | 适合 |
|---|---|---|---|
| 1 | ConversationBufferMemory | 存整段历史 | 需前后细节串联 |
| 2 | BufferWindowMemory | 只留最近 k 轮 | 响应快、聚焦 |
| 3 | EntityMemory | 抽取记住关键实体及关系 | 法律/个性化 |
| 4 | KGMemory | 实体+联系构建知识图谱 | 医疗多症状关联 |
| 5 | SummaryMemory | 滚动总结为摘要 | 长期跟踪 |
| 6 | SummaryBufferMemory | 近几轮原文+更早摘要 | 长期技术排障 |
| 7 | TokenBufferMemory | 按 token 上限保留 | 防信息混淆 |
| 8 | VectorStoreRetrieverMemory | 存向量库按相关性检索 | 不受时间新旧限制 |

6c. LCEL 与 SQL Agent

LCEL（LangChain Expression Language）：用管道符 | 把 prompt | model | output_parser 串成声明式链，替代旧版命令式 LLMChain。每个组件都实现统一 Runnable 协议，链本身也是 Runnable，天然支持 .invoke（单次）/.stream（流式）/.batch（批量）。
RAG 链标准范式：{context: retriever|format_docs, question: RunnablePassthrough} | prompt | llm | StrOutputParser。关键组件：RunnablePassthrough（原样透传输入）、RunnableParallel（{} 并行取多分支，如"检索+问题"同时准备）、RunnablePassthrough.assign（链中动态追加新键，实现上一步输出喂下一步）。
NL2SQL 三步链路：① LLM 把自然语言转 SQL → ② 执行 SQL → ③ LLM 用查询结果生成自然语言答案。工具：SQLDatabase.from_uri 暴露 dialect/表名/run 给 LLM 感知 schema；create_sql_query_chain（生成 SQL）+ QuerySQLDataBaseTool（执行）。详见 → NL2SQL 项目。
SQL Agent vs SQL Chain：Agent（create_sql_agent）能自主多轮——探查表结构、纠错重试、答开放式问题；Chain 是固定单向流程。CSV 问答优先转 SQL：df.to_sql 灌进 SQLite 再用 SQL Agent，比放开任意 Pandas 执行更安全可控。
Agent 创建三要素：① create_openai_functions_agent/agent_type="openai-tools"（定义决策）② AgentExecutor(agent, tools)（跑循环，创建器只定决策不执行）③ prompt 必含 MessagesPlaceholder("agent_scratchpad")（存中间步骤推理草稿）+ ("chat_history")（对话记忆）。
@tool 装饰器：定义工具最简方式，自动从函数名取 name、docstring 取 description（LLM 选工具的关键依据，必须写清）、类型注解取参数。create_retriever_tool 把 retriever 一键包成工具。

7. 记忆冲突/更新

冲突偏好（昨天奶茶今天可乐）不物理覆盖，作为独立实体带时间戳存入，检索时用新鲜度算法/时间衰减系数赋最新记忆更高权重，保留历史轨迹。新用户用实名基础信息初始化画像。

8. 高频追问速答

❓ 常见追问 · 多 Agent 怎么协作？ → 总控识别意图后动态路由分发给专门子 Agent（苏格拉底/写作/判题），各司其职。
❓ 常见追问 · 群聊场景怎么拓展？ → 数据结构 (User_ID,Session_ID)→(Group_ID,Session_ID)，每条打 Sender_ID；短期窗口扩到 20 条格式化注入；长记忆公私域隔离（群组公共+用户私人）。
❓ 常见追问 · 记忆污染怎么避免？ → 写回前做重要性评估+置信度门控，不让模型猜测写进长期事实。

深度拆解:容易踩坑的点

维度一：架构设计

⚠️ 长期记忆会无限增长——用户用半年，Weaviate 里几万条记忆，检索越来越慢，召回的噪声（过时偏好、一次性事实）也越来越多，你怎么做遗忘/压缩/分级？

不能只靠"重要性阈值+保留天数"一次性写死，得分三层动态治理：① 遗忘——保留天数到期做软删除（先降权不物理删，观察一段时间没被检索命中再真删），fact 类阈值低（0.6/90天）本身就是快速淘汰低价值信息；② 压缩——同类记忆定期做聚类摘要，比如 30 条零散"学习记录"合并成一条"学习画像"摘要，向量库条数不涨但信息密度提升；③ 分级检索——不是每次都全库检索，先查高价值分层（person/preference 长保留），命中不足再下探；配合定期离线任务重新计算重要性分数（访问频率高的记忆权重回升，类似 LRU 思路）而不是只在写入时评估一次。本质是把记忆当成"有生命周期的缓存"而非"只增不减的日志"。

短期记忆用滑动窗口+摘要，摘要会丢早期关键信息（比如用户第 1 轮说的一个强约束，到第 20 轮摘要早被稀释掉了），什么时候该做摘要、摘要粒度怎么定？

不能靠固定轮数（每 5 轮）一刀切，粒度要看信息类型：① 强约束类信息（用户身份、明确禁止项、长期目标）不该经过摘要衰减，应该在识别到时立刻分流写入长期记忆或对话置顶区，绕开滑动窗口的摘要压缩路径；② 过程性信息（闲聊、中间推理）才适合摘要，且摘要应该是"增量摘要"（上一版摘要+新增 5 轮再摘要）而不是每次重新摘要全部历史，防止早期信息在多轮摘要嵌套后被稀释成模糊描述；③ 摘要时机可以从"定长轮数触发"改成"token 逼近窗口上限触发"，避免正常对话没超限也强行摘要造成信息损耗。核心答案是：不是所有信息都该被摘要一视同仁地"压缩",关键信息要有单独的逃生通道。

维度二：工程实现

⚠️ ReAct 循环和多 Agent 协作都可能陷入死循环——工具调用怎么调都拿不到满意结果，或者子 Agent 之间互相请求形成闭环，你怎么保证收敛？有没有硬性终止条件？

必须有多层兜底,不能只依赖模型"自己意识到该停了"：① 步数/轮数上限（AgentExecutor 有 max_iterations，超过强制终止并返回当前最优结果而非报错）；② 重复检测——像 Reflexion 那样比较连续几步的 Action+Observation 是否高度相似（同样的查询、同样的结果），判定为"幻觉式空转"就提前退出或触发反思重规划；③ 超时/成本上限（token 消耗或墙钟时间到阈值强制收口）；④ 多 Agent 场景额外加调用深度/路由跳数上限，防止 A 路由给 B、B 又路由回 A 的环路；⑤ 最后兜底是人工介入或降级为"如实告知未完成+已尝试的步骤"，而不是让系统无声挂起。没有任何一层是完全可靠的，工程上永远是这几层叠加做防御。

多 Agent 链路里，如果某个子 Agent（比如 SQL 生成、意图路由）输出了错误结果，这个错误会沿着链路传导并被下游放大（错误 SQL 跑出错误数据，再被总结成"看似合理"的自然语言回答），你怎么做隔离和纠错？

三个层面：① 输入校验/契约约束——每个子 Agent 的输出用结构化 Schema（如 Pydantic）强约束，不合规直接拒绝进入下一环节而不是"尽力解析"；② 可验证的中间产物——像 NL2SQL 那样 SQL 生成后先执行再让 LLM 看真实结果生成回答，等于用"执行结果"做了一次事实校验，而不是端到端黑盒直出；③ 置信度/异常标记随链路透传——上游如果对自己的输出不确定（比如路由 LLM 置信度低），应该把这个不确定性作为元数据传给下游，下游据此决定是否要求人工确认或走保守分支，而不是把"可能错的结果"当成"确定无疑的事实"喂给下一个 Agent。本质是链路里每一环都要有出口校验，不能假设上游一定对。

维度三：性能优化

如果每一轮对话都触发一次长期记忆检索（向量库查询+重排），检索延迟和调用成本会跟对话轮数线性叠加，你怎么减少不必要的记忆检索？

核心思路是把"每轮必查"改成"按需触发"：① 先用一个轻量分类器/规则判断当前输入是否需要个性化记忆（比如包含指代词"我上次说的"、涉及用户偏好类问题才触发检索，纯任务型问题如"这道题怎么解"可以跳过）；② 缓存——同一 Session 内，短期内多次相近查询直接复用上一次检索结果（结合语义相似度判断是否要重新查）；③ 检索和主链路生成并行化而非串行等待，检索耗时可以和别的准备工作（比如工具调用）重叠；④ 对高频用户可以把最近命中率高的记忆预热进短期上下文/本地缓存，减少远程向量库往返。权衡点是：省检索有漏检风险（该查的没查），所以触发规则要保守，宁可多查一点也不能让"该记得的事情"被误判跳过。

维度四：数据策略

记忆冲突不只是"昨天奶茶今天可乐"这种简单偏好变化，还有事实性更新（比如用户从"高一"升到"高二"，或者地址变更），时间衰减系数解决不了"旧信息已经失效"这种情况——全覆盖会丢历史轨迹，全不覆盖又会互相矛盾拖累检索质量，怎么权衡？

关键是先区分记忆的"语义类型"再决定策略,不能一套时间衰减系数打天下：① 偏好类（口味、习惯）适合时间衰减——新旧都保留，新的权重高，能体现变化趋势本身就是有价值的信息；② 状态类事实（年级、地址、身份）应该是版本化覆盖而非简单加权——识别到是同一实体的状态更新时，旧记录标记为 superseded（失效但不删除，供审计和轨迹回溯），新记录成为当前有效版本,检索时默认只返回当前有效版本，除非显式要历史；③ 判断"这是偏好变化还是事实更新"本身依赖对记忆做实体/属性建模（比如 KG Memory 的实体-属性-值三元组），如果只是无结构的文本摘要就很难做这层区分，这也是为什么长期记忆需要分类型（人物/事实/偏好…）存储而不是一锅烩。

如果记忆抽取环节出错——把闲聊噪声或者模型自己的幻觉误判成"重要事实"存进了长期记忆库，这个错误记忆会在后续对话里被反复召回、持续误导模型给出错误回答，你怎么发现和清理这种"脏记忆"？

分三步：① 写入时前置过滤——不是模型评估完重要性就直接写库，而是要求抽取结果附带来源可追溯（关联到具体哪轮对话原文），并做置信度门控（低置信度先进"待确认"区，不直接进可检索的主库，类似前文提到的重要性评估+置信度门控）；② 运行时发现——监控某条记忆的检索命中后用户是否有纠正/否定反馈，把这种否定信号作为反向标记,触发人工/自动复核；③ 定期审计清理——离线任务定期对长期记忆做一致性检查（同一实体的属性是否自相矛盾、是否和最新对话明显冲突），矛盾的批量标记待复核而不是等它被检索到才发现。这三层本质是把"记忆写入"当成一次不可信的用户输入去做校验，而不是模型说什么就无条件持久化什么。