一条从大模型输出采样原理到底层注意力机制的完整学习路径，无论是想理解ChatGPT为什么有时会"胡言乱语"，还是想深入Transformer的底层设计，都提供了非常清晰的学习阶梯。

大模型生成原理与Attention机制详解

什么是Embedding？它的原理是什么？

多路召回策略

直接用 OpenAI SDK + Redis 实现“可持久化的对话记忆”，并在对话变长时自动做摘要压缩，同时支持 Function Calling（工具调用）。[1]
核心思路
• 用 Redis 存储每个 session_id 的对话消息，做到进程重启后仍能恢复上下文。
• 当消息数或粗略 token 数超过阈值时，把较早的对话生成一段摘要，摘要单独存 Redis；同时只保留最近几条原始消息，形成“摘要 + 最近消息”的结构。
主要模块
1. OpenAIRedisMemoryManager（记忆管理器）
    ◦ 负责：存消息、读消息、估算 token、触发摘要、保存摘要、TTL 过期、清空会话等。[1]
2. OpenAIFunctionCallingAgent（Agent 封装）
    ◦ 负责：加载历史（可包含摘要作为 system message）→ 追加用户输入 → 调 OpenAI Chat Completions → 若模型返回 tool_calls 则执行本地函数并把结果以 tool 角色回写 → 循环直到拿到最终回复 → 最后把消息写回 Redis（可能触发摘要）。[1]
3. 工具定义与映射
    ◦ 按 OpenAI Function Calling 格式声明工具（如 search_web、calculate、get_price），并提供对应的本地函数实现与映射表。[1]
文章强调的优点
• 更轻量：不依赖 LangChain。[1]
• 更可控：对消息结构、摘要策略、存储键、TTL、保留最近消息数等完全可定制。[1]
• 更易调试：流程清晰，组件边界明确。

Openai SDK实现持久化存储生产级实践

1) 基础实现：Redis 持久化 + Tool Calling Agent
• 使用 RedisChatMessageHistory 把对话历史存到 Redis，实现跨进程、可恢复的会话记忆。
• 用 ConversationBufferMemory 直接把历史消息注入 Agent。
2) 记忆管理的三种方案（解决长对话 token 问题）
1. ConversationBufferMemory（原始全量）
    ◦ 优点：信息不丢。
    ◦ 缺点：对话长了 token 成本高，容易超上下文窗口。
2. Trim Messages（消息修剪）
    ◦ 思路：只保留最近 N 条或最近一定 token 的消息（trim_messages）。
    ◦ 优点：简单、可控。
    ◦ 缺点：早期信息会被直接丢弃，可能导致“忘记关键信息”。
3. Summarize Messages（消息摘要，推荐）
    ◦ 思路：把旧消息压缩成摘要，保留“摘要 + 最近消息”。
    ◦ 文中强调 ConversationSummaryBufferMemory 的优势：自动监测、自动摘要、滚动更新、对 Agent 透明。
3) 非 OpenAI 模型的兼容性坑与解决思路
• 文中指出：像 qwen-plus 这类非 OpenAI 模型在 ConversationSummaryBufferMemory 上可能因为缺少 get_num_tokens_from_messages() 而报错。
• 解决方向：自定义 token 计数 / 自定义摘要逻辑，绕开对模型内置 token 统计的依赖。
4) 生产环境最佳实践建议
• 推荐组合：Redis 持久化存储 + SummaryBuffer（或等价摘要机制）。
• 给出 ttl、max_token_limit 的配置建议，并按不同模型上下文窗口列出大致调参范围。
• 提供面向场景（如在线客服）的封装示例：用用户/工单拼接 session_id，并设置更适合长对话的 token 阈值。
5) LangChain 1.0 / LangGraph 的生产级做法
• 展示了更“工程化”的实现：自定义 RedisCheckpointerWithSummary，在保存时判断消息数或 token 数是否超阈值：

    ◦ 超了就把旧消息生成摘要存 Redis。
    ◦ 仅保留最近若干条消息继续存储。
• 还介绍了 LangChain 1.0 的新方式：SummarizationMiddleware，用“中间件”声明式接入自动摘要，代码更简洁、自动化程度更高。

Agent持久化记忆不同方案与生产最佳实践以及langchain1.0中的最佳实践

在 LangChain / LangGraph 的三种常见 Agent 构建方式里，如何“嵌入记忆（memory）”。
1）Function Call（Tool Calling）模式的记忆接入
• 用 create_tool_calling_agent + AgentExecutor 构建支持工具调用的 Agent。
• 记忆采用 ConversationBufferMemory，关键点是：
    ◦ return_messages=True：记忆以“消息列表”形式保存和返回，更适配聊天式上下文。
    ◦ memory_key="chat_history"：让 Agent 在提示词里能读到历史对话。
• 工具侧展示了三种来源：
    ◦ TavilySearchResults 做实时检索
    ◦ load_tools(["llm-math"]) 做数学能力
    ◦ @tool 自定义工具（示例：查询价格）
• 示例调用是问“今天西安天气怎么样”。
2）ReAct 模式的记忆接入
• 用 create_react_agent 构建 ReAct（思考-行动-观察）风格 Agent。
• 同样用 ConversationBufferMemory(return_messages=True, memory_key="chat_history") 注入对话历史。
• 工具组合以检索和数学为主（TavilySearchResults + llm-math）。
• 文章强调：推荐用 PromptTemplate 方式来构建 ReAct 的模板，更方便控制格式与变量。
3）LangChain 1.0 / LangGraph 的 create_agent（checkpointer）记忆方式
• 用 langchain.agents.create_agent 创建 Agent。
• 记忆不再通过 ConversationBufferMemory，而是通过 checkpoint 机制持久化执行状态：
    ◦ checkpointer=InMemorySaver()
    ◦ 通过 {"configurable": {"thread_id": "1"}} 指定同一个线程，从而让多轮对话在同一条“会话线”上延续（达到记忆效果）。
• 调用方式改为传入 messages（role/content）结构。
核心对比（一句话）
• 旧式（Function Call / ReAct）：用 ConversationBufferMemory 把历史对话塞回 prompt（或消息列表）里。
• 1.0 / LangGraph 风格：用 checkpointer + thread_id 把会话状态作为“可恢复的执行上下文”保存下来，更偏“运行时状态管理”。

Agent嵌入记忆-reAct与Function call，以及1.0中的实现

Rerank

Agent与RAG

Agent和Memory

Agent和Tool

langchain V1 基础变动

Agent概述

Milvus与RAG

FAISS的使用

文档嵌入模型

常见的拆分器

文档拆分器

• MCP 的核心想法：给大模型一个统一的“工具调用协议”，让模型能通过标准方式去调用各种外部工具，从而扩展能力边界（不只是思考，还能做事）。
• 要解决的问题：如果工具分别用 Java、Python、Rust 写，直接把它们做成某个特定语言的 tool 会受限。MCP 通过统一协议，把“跨语言、跨进程”工具调用标准化。
• MCP 最大特点：跨进程调用工具
    ◦ 本地跨进程：通过 stdio（标准输入输出）与子进程通信
    ◦ 远程跨进程：通过 http 连接远程服务通信
• 消息协议标准：统一使用 JSON-RPC 2.0，优点是与语言无关、结构清晰、易调试、轻量灵活。
• 传输模式演进：
    ◦ Stdio：客户端启动 MCP Server 子进程，用 stdin/stdout 交换 JSON-RPC 消息，并管理子进程生命周期。
    ◦ SSE（旧远程标准）：HTTP POST 发请求 + SSE 长连接收结果，用 sessionId 和 requestId 关联请求响应，属于“伪双工”。
    ◦ Streamable HTTP（新标准，2025-03-26 起）：用更统一、健壮的方式替代 HTTP+SSE，减少双连接维护问题，并增强 session 管理（例如返回并使用 Mcp-Session-Id，支持终止会话等），更利于扩展和部署。

定义tool的方式

tools概述

redis/postgre 持久化存储memory方法

langchain中调用deepseek模型使用trim_messages报错原因

ConversationChain(已废弃)与现代写法RunnableWithMessageHistory

手动模拟实现记忆

memory设计理念

主要输出解析器用法

StrOutputParser、JsonOutputParser、XMLOutputParser、CommaSeparatedListOutputParser、PydanticOutputParser用法

几种不同Paser输出解析器用法

LLMChain(已弃用写法)；SimpleSequentialChain/Sequential(在1.0中已弃用写法)；LECL语法

LECL 结合 少样本 实现顺序链-多步骤流水线

Rerank内部机制与score对比

通俗理解Chunk与Retrieval及最佳实践(分段与检索)

deepseek与qwen在策略上的差异

Dify不同模型接入mcp注意点(deepseek与qwen3)

Docker支持GPU


模型管理平台之Ollama部署

Dify认识与私有化部署

ollama服务连接失败问题

MessagesPlaceholder

FewShotPromptTemplate

模板提示词模板、对话提示词模板、少样本提示词、消息占位符提示词

prompt常见攻击方式与防御方式

Jest及Vue/test-utils使用(4)—点击测试

Jest及Vue/test-utils使用(3)—条件测试

Jest及Vue/test-utils使用(2)—时间格式化测试

Jest及Vue/test-utils使用(1)—正反向测试

Jest.fn()、Jest.spyOn()、Jest.mock()

mount与shallowMount的使用场景、异同以及配置和接口方法，测试替身的作用

mount、shallowMount的options、方法与测试替身stub

Jest及Vue/test-uitls—配置

组件封装：将分类列表封装成一个可复用的组件（CategoryComponent），用于显示一级、二级和三级分类⁠。
数据结构：使用嵌套结构存储分类数据，每个级别的分类都有自己的状态
交互逻辑：点击一级分类显示对应的二级分类，点击二级分类显示对应的三级分类⁠1。再次点击已选中的分类会取消下级分类的选中状态，但保持当前级别的展示⁠1。如果某一级别没有子分类，则显示输入框以添加新分类⁠。
数据管理：使用克隆数据来保存完整的分类数据，而实际显示的数据是根据用户交互动态过滤的⁠。实现了添加、编辑和删除分类的功能，并在这些操作后更新both显示数据和克隆数据⁠1⁠。
父子组件通信：使用事件发射（emit）来通知父组件更新数据，父组件则通过props传递数据给子组件⁠1⁠。
表单验证：在添加和编辑分类时使用表单验证确保数据的正确性⁠1⁠。
性能优化：通过动态加载和隐藏分类来优化性能，而不是一次性加载所有数据⁠。

记一次店匠的组件封装和交互

i18n(国际化)方案总结

购物车页面功能概述页面分为左侧商品列表和右侧订单摘要，包含促销信息、运费信息、商品列表和结账按钮⁠。支持商品数量调整、移除商品，并实时计算总价和应用折扣⁠。提供普通结账和PayPal快速结账选项，结账前验证商品有效性⁠。用户体验和性能优化使用事件委托和防抖技术处理用户交互，优化性能⁠；通过AJAX动态更新购物车信息和UI，保持数据一致性⁠；⁠实现响应式设计，适配不同屏幕尺寸⁠；⁠显示清晰的价格和折扣信息，使用进度条鼓励用户达到促销目标⁠⁠

EJS模板引擎编写购物车页面。包含促销信息、运费信息、商品列表和普通/快速结账按钮⁠。

这段代码实现了一个动态的颜色选择功能,允许用户在不刷新页面的情况下查看不同颜色的产品图片和价格,提高了用户体验和交互性。

鼠标与缩略图交互动态更改商品主图和链接(下)

实现一个动态的颜色选择功能,允许用户在不刷新页面的情况下查看不同颜色的产品图片和价格,提高了用户体验和交互性。

鼠标与缩略图交互动态更改商品主图和链接(上)

使用抽屉式导航，包含顶部标题和关闭按钮⁠⁠，实现了响应式布局，针对PC端和移动端有不同的处理逻辑⁠⁠
移动端下，为有子菜单的导航项添加展开按钮和切换功能⁠。阻止了有子菜单的一级导航项的默认点击事件，优化用户体验⁠。

记一次移动端导航适配

实现了一个灵活、可定制的对话框组件，可以用于在网页中显示各种类型的弹出内容。它支持不同的尺寸、远程加载内容、模板渲染，并且具有良好的移动端适配性。

封装对话框

定义了一个Menu构造函数,用于创建可交互的菜单组件。主要功能包括:初始化菜单并设置事件监听。提供打开、关闭和切换菜单状态的方法。支持点击和鼠标悬停两种交互模式。可以自定义点击事件和切换样式类。在打开一个菜单时自动关闭其他菜单。点击菜单外部区域时自动关闭菜单。提供销毁方法以移除所有事件监听器。

封装菜单类

实现了一个可定制的遮罩层组件,通过JS控制其显示、隐藏,并能够设置不同的z-index值。它还包含了一些移动端的优化,如禁止页面滚动和响应式设计。

封装遮罩层

最近要把一个用java写的老项目，用egg.js和ejs、jquery重写一遍

可配置选择框列、超链接列、输入框列、switch开关列、图片列、tag列、操作栏、普通文本列

记录一个vue3+ts的全功能表格封装

vue3 defineModel注意事项

跨境独立站项目：商品拖曳排序

Vue3+TS拖拽排序(dragenter和dragover的区别与选择)

自定义样式： 1.按组配置折线类型（实线、虚线等）⁠2..按组配置折线颜色⁠ 3.图例控制： 支持通过图例显示/隐藏单条折线⁠，确保至少保留一条折线可见⁠ 4.⁠按钮控制： 通过按钮控制整组折线的显示/隐藏⁠ 5.按钮边框颜色与组别颜色相同⁠，防止同时隐藏所有组的折线⁠ 6.⁠提示框（Tooltip）优化： 避免日期重复显示⁠ 7.按组展示数据，同组数据使用相同日期⁠ 8.⁠交互优化： 隔离emphasis和tooltip事件，避免鼠标进入坐标系就触发所有折线强调效果⁠。支持动态更新图表⁠实现从父组件到子组件的完整数据传递和处理逻辑⁠

📝 主要问题

deepseek-reasoner

🧐 错误原因解析

🔍 问题根源：模型机制与Dify的兼容性

qwen3-max

在Dify中的优化方法：