Harness 超牛逼的 三级记忆架构 上下文+历史分层+事实列表 ! 落地价值 逆天!!

绝大多数企业 Agent 框架 的记忆架构 , 没有设计好!!!

DeerFlow 不走寻常路,直接在后台搭了一套 三级记忆架构 记忆体系,让 Agent 能跨会话“记牢”用户、沉淀上下文、追踪核心目标,这才是企业级 Agent 该有的样子。

落地价值 逆天!!

DeerFlow 记忆体系 不是 传统 的 短期记忆+长期记忆。

DeerFlow 记忆体系 , 是一套完整的、可落地的架构,包含数据模型、配置管控、缓存策略、注入机制等多个核心模块,能真正解决 Agent“失忆”的痛点,让交互更连贯、更智能。

![

一、DeerFlow 三层记忆 架构](https://mmbiz.qpic.cn/sz_mmbiz_png/mXgcbpbXt9b85M5AQCOJ4meMfctJNl680AVrWVGZUGEdPIt02wYia3atXG1foIjWNvFGPbzwZeNHxulA1tOlm2hBfUZqNiar9k85R92ialoqUA/640?from=appmsg)

DeerFlow 通过 上下文+历史分层+事实列表 结合, 打造一套逆天的 三级记忆架构, 落地价值 逆天!!

本章,尼恩 就扒透这套落地价值 逆天 记忆架构的底层数据模型、配置体系和缓存策略,不玩虚的,全是可落地的硬核细节。

一、DeerFlow 三层记忆的“长短周期”总览


要理解 DeerFlow 的记忆体系,首先要搞懂它的核心数据结构——记忆不是杂乱无章的信息堆砌,而是按“用户上下文” “历史分层” “事实列表”三个结构化层次 划分的三层结构。

为了更直观地区分用户当前状态层与其他两层记忆,我们整理了核心维度对比表,结合源码中的设计逻辑,明确每一层的定位和特点,一目了然:

层级 类型 更新频率 生命周期 归属 核心作用(补充说明)
user(用户上下文 ) 短期 / 活跃记忆 每次对话 小时 / 天 短期记忆 实时反映用户当下状态(是谁、关注什么),支撑Agent即时响应
history(历史分层) 中期 / 长期记忆 按月 / 季度 月 / 年 长期记忆 沉淀用户过往行为轨迹(做过什么),提炼行为规律
facts(事实列表) 结构化长期记忆 低频率 永久 / 半永久 核心长期记忆 固化用户离散知识点(可检索),供Agent快速检索调用

一、DeerFlow 三层记忆 架构

每一层都有明确的职责和作用,三者相互配合,才能完整刻画用户。

直接打开 updater.py 里的 _create_empty_memory() 函数,记忆的骨架一眼就能看透,这个函数负责创建一个空的记忆对象,所有记忆数据都会基于这个骨架填充和更新:

def _create_empty_memory() -> dict[str, Any]:
    return {
        "version": "1.0",
        "lastUpdated": datetime.utcnow().isoformat() + "Z",
        "user": {
            "workContext": {"summary": "", "updatedAt": ""},
            "personalContext": {"summary": "", "updatedAt": ""},
            "topOfMind": {"summary": "", "updatedAt": ""},
        },
        "history": {
            "recentMonths": {"summary": "", "updatedAt": ""},
            "earlierContext": {"summary": "", "updatedAt": ""},
            "longTermBackground": {"summary": "", "updatedAt": ""},
        },
        "facts": [],
    }

这三层结构各有分工,各司其职,缺一不可,就像尼恩认识一个人:先知道他是谁(用户上下文),再了解他做过什么(时间线/历史分层),最后记住他的关键信息(事实库),层层递进,形成完整的认知。

1. 第一层:用户上下文(user,用户当前状态层)

核心是搞清楚“用户是谁”,精准刻画用户核心属性,对应记忆JSON的user字段,也是本文重点解析的层级——它不属于严格意义上的长期记忆,而是每次对话实时更新、高频刷新的「用户最新状态快照」。简单来说,它就像我们手机的“实时通知栏”,只显示当前最新的消息,一旦有新消息进来,就会覆盖旧消息,始终呈现最当下的状态。

它由记忆更新引擎(updater.py + prompt.py)通过LLM从最新对话中实时提取、结构化生成,核心作用是让Agent立刻知道“用户现在在做什么、关心什么”,是Agent实现“实时响应”的核心依据,也是区别于传统Agent“一次性对话失忆”的关键,其具体字段分工的源码级定义如下:

  • workContext:职业角色、所属公司、核心项目、主力技术栈,1-2句话说透,最多不超过3句,杜绝冗余。比如“字节跳动高级工程师,主导 DeerFlow 框架开发,技术栈以 Python + LangChain + FastAPI 为核心”,这样的描述既精准又简洁,Agent 能快速掌握用户的职业背景,适配技术沟通场景,对应源码中create_empty_memory函数定义的workContext字段,更新频率中等(用户工作内容变更时更新)。
  • personalContext:语言能力、沟通偏好、兴趣领域,1-2句搞定,抓核心不废话。比如“中英文双语,偏好简洁直接的技术沟通风格,不喜欢冗余表述”,这能让 Agent 调整沟通方式,避免出现用户不喜欢的表达,提升交互体验,对应源码中personalContext字段,更新频率低(个人偏好一旦确定,很少变更)。
  • topOfMind:用户当前关注的多个并行焦点,3-5句话说清,这部分更新频率最高,是 Agent 实时贴合用户需求的关键。比如用户近期在准备项目发布、优化调度策略,这部分信息就会实时更新,Agent 能主动关联这些焦点,提供更精准的帮助,而不是只停留在历史认知里,对应源码中topOfMind字段,是整个user层更新最频繁的部分,每次对话若涉及新关注点就会更新。
2. 第二层:时间线(history,历史分层)

核心是记录“用户做过什么”,沉淀用户行为轨迹,对应记忆JSON的history字段.

history 属于中期/长期记忆,核心作用是让Agent了解用户的过往行为规律,避免重复询问已明确的过往信息,其具体字段分工结合源码设计如下:

  • recentMonths:近1-3个月的详细活动摘要,4-6句话,重点突出核心动作和成果,不堆砌无关细节。比如“过去两个月主要在重构 Agent 中间件管道,完成了3个核心中间件的开发与测试,将 CI 覆盖率从62%提升到85%”,这些信息能让 Agent 了解用户近期的工作重点,提供针对性帮助,对应源码中history层的核心子字段,更新频率为按月/季度。
  • earlierContext:3-12个月前的重要行为模式,3-5句话,提炼规律,而非罗列琐事。比如“2025年初完成了 DeerFlow 1.0 到 2.0 的架构迁移,核心是拆分双层架构、引入 LangGraph 编排引擎”,这能让 Agent 掌握用户的长期工作节奏和技术方向,更新频率低于recentMonths
  • longTermBackground:长期不变的基础背景,2-4句话,比如从业经验、核心能力,是刻画用户的底层支撑。比如“5年 Python 后端开发经验,从 Django 转型到 AI Agent 领域,有大规模并发架构实践经验”,这部分信息相对稳定,更新频率最低,是 Agent 理解用户能力边界的基础,对应源码中history层的长期沉淀字段。
3. 第三层:事实库(facts,事实列表)

核心是存“离散可检索的结构化知识点”,相当于 Agent 的“知识库”,随用随取,对应记忆JSON的facts字段,属于结构化长期记忆。和前两层的“摘要式”描述不同,facts 是“碎片化、结构化”的信息,每一条都是一个独立的知识点,比如用户的偏好、专业知识、目标等,便于 Agent 快速检索和调用,不用从冗长的摘要中提取信息,对应源码中facts字段的设计逻辑——低频率更新,永久/半永久存储,供Agent快速检索使用。

Facts 的五种类别

每条 fact 都自带 category 字段,取值就5种,覆盖用户全维度信息,没有多余冗余,精准落地:

类别 含义 示例
preference 用户偏好 “偏好使用 Vim 而非 VS Code”
knowledge 专业知识 “精通 Rust 和 WebAssembly”
context 背景事实 “在字节跳动担任高级工程师”
behavior 行为模式 “习惯先写测试再写实现”
goal 目标意图 “计划在 Q2 发布 v2.0”

facts 作为记忆体系的“知识库”,不是杂乱无章的存储,而是按类别划分,每条 fact 都自带 category 字段,取值就5种,覆盖用户全维度信息,没有多余冗余,精准落地。这种分类设计的核心目的是“便于检索和管理”——Agent 在需要特定信息时,能快速按类别筛选,比如想了解用户偏好,就直接筛选 preference 类别的 fact,提升效率。

_apply_updates 方法里,每条新 fact 都会被封装成标准结构化条目,规范落地,避免混乱:

fact_entry = {
    "id": f"fact_{uuid.uuid4().hex[:8]}",
    "content": fact.get("content", ""),
    "category": fact.get("category", "context"),
    "confidence": confidence,
    "createdAt": now,
    "source": thread_id or "unknown",
}
current_memory["facts"].append(fact_entry)

尼恩拆解一下每个字段的作用:

  • id 是唯一标识,用 UUID 简化生成,避免重复;
  • content 是 fact 的具体内容,确保清晰准确;
  • category 是类别,默认是 context,避免无类别导致的混乱;
  • confidence 是置信度,后续会详细说明,用于过滤无效信息;
  • createdAt 是创建时间,便于追溯;
  • source 是来源,指向产生该 fact 的对话线程 ID,后续排查问题、去重都很方便。

这种结构化设计的好处是“统一格式、便于检索和更新”,不管是哪种类别的 fact,都包含固定字段,Agent 处理起来更高效,也便于后续的去重、排序和溯源

二、关键区分:用户上下文(user)到底是短期还是长期记忆?


在DeerFlow 2.0的分层记忆系统中,用户当前状态层(对应记忆JSON的user字段)是最具动态性的核心层级——它记录用户实时工作状态、个人偏好和当前关注点,直接决定Agent能否“读懂”用户当下需求。

用户当前状态层以“高频更新、实时响应”为核心特点,其处理、保存与Prompt组装的全流程,深度依赖updater.py(记忆更新核心)、storage.py(持久化存储)和Prompt工具类的协同工作。

1. 定位:短期 / 活跃记忆(最高优先级、高频更新)
  • 更新频率:每次对话都可能更新(最高频)——只要用户发送新的对话,且包含状态相关信息(比如“我现在在优化记忆模块”“我偏好用Markdown写文档”),就会触发状态层更新,这是它与history、facts层最核心的区别。
  • 生命周期:只保留最新、当前、当下的用户状态,生命周期以小时/天为单位,随着用户新的对话不断覆盖,不会长期沉淀。
  • 作用:让Agent立刻感知用户的实时需求,比如用户当前在做项目迭代,Agent就能针对性提供迭代相关的帮助,而不是停留在用户几天前的状态。
  • 与其他两层的对比:history层(时间线)沉淀用户过往行为轨迹,facts层(事实库)固化用户离散知识点;user层(用户当前状态层)实时反映当下,三者协同构成完整记忆体系。
2. 为什么user层不属于长期记忆?

很多人会误以为user字段属于长期记忆,核心原因是它和history、facts一起存储在memory.json中,但从源码设计和功能定位来看,它和长期记忆(history+facts)有本质区别:

  • 长期记忆(history+facts)的核心是“沉淀、固化、不频繁修改”——比如history层的longTermBackground(长期背景),可能几个月、几年才会更新一次;facts层的用户专业知识,也不会频繁变动。
  • 用户当前状态层(user)的核心是“动态、临时、随时覆盖”——每轮对话都可能更新,旧的状态会被新的状态直接覆盖,不会保留历史版本(旧状态会自动沉淀到history层的recentMonths字段,实现长期记忆的补充)。

四、整体架构概览:四大核心模块的协同闭环


DeerFlow 2.0 记忆模块的整体架构采用“分层解耦、异步协同”的设计思路。

![

四、DeerFlow 记忆处理 的四大核心模块](https://mmbiz.qpic.cn/mmbiz_jpg/mXgcbpbXt9aqRsZ8Fm8LTlvsnzyF9GUiaLMphibkQp8IAMLnIcptL2M4fRzibcXo4oLlQHaqdmvI4Gw5iaFmGshuVeaayL0lPiaWj7icRSeDmkKtE/640?from=appmsg)

从上到下分为四个核心模块,各模块职责清晰、接口统一,形成完整的记忆生命周期管理闭环。

结合源码目录结构(backend/packages/harness/deerflow/agents/memory/),我们可以清晰看到各模块的对应关系:message_processing.py(消息预处理层)、queue.py(防抖队列层)、updater.py+prompt.py(记忆更新引擎层)、storage.py(持久化存储层),再加上作为入口的MemoryMiddleware(对话交互层)和负责复用的记忆注入层,共同构成了完整的记忆系统。

下图直观地展示各模块的协同关系, 每一个箭头都代表着数据的流转方向,每一个模块都承担着特定的职责,缺一不可:

图片

用户与Agent的对话(比如用户说“我是后端开发,用Go语言”),会首先被MemoryMiddleware(DeerFlow 2.0的14个有序Middleware之一)拦截。

Middleware就像一个“守门人”,负责捕捉所有对话事件;随后,对话消息会被送到 message_processing 消息预处理层,进行清洗过滤(比如剔除临时文件上传信息)、关键信号检测(比如检测用户是否有纠正);

清洗后的有效消息,会被送入防抖队列,进行批量聚合(避免频繁更新);

当防抖窗口到期后,队列会批量触发记忆更新引擎,调用LLM生成结构化记忆数据(比如提炼“用户是后端开发,核心技术栈是Go”);

最后,结构化记忆会通过存储层持久化到本地文件或数据库,在下一轮对话前,记忆注入层会按Token预算格式化记忆,注入到Agent的系统提示中,让Agent能直接调用这些记忆,实现个性化回复(比如下次对话直接说“你好,后端开发的同学,需要我帮你解决Go相关的问题吗?”)。

五、记忆架构 核心模块深度解析(结合源码+架构思维)


下面结合DeerFlow 2.0最新源码、官方文档及社区解析,逐一对四大核心模块进行拆解,重点分析其实现细节、核心代码逻辑,以及分层架构思维、事件驱动异步设计在各模块中的具体落地。

  1. 1 记忆 交互层:MemoryMiddleware——事件驱动的入口

对话交互层的核心是MemoryMiddleware。

它是DeerFlow 2.0 Middleware链中的第9层(严格有序),负责拦截用户与Agent的对话消息,触发记忆更新流程,是事件驱动异步设计的“事件入口”。

5.1 记忆 交互层:MemoryMiddleware——事件驱动的入口

从源码来看,MemoryMiddleware的核心逻辑是: 在对话生命周期的“后置处理阶段”,提取对话消息,调用消息预处理工具检测关键信号,然后将对话上下文入队到MemoryUpdateQueue,触发异步记忆更新。

尼恩提示:原文3w字以上, 超过平台限制, 此处省略 1000字,具体请参考 免费pdf。

完整版本,请参考 尼恩 免费百度网盘 免费pdf ,点赞收藏本文后,截图 找尼恩获取

  1. 2 消息预处理层:清洗与信号检测——记忆准确性的第一道防线

消息预处理层对应源码中的message_processing.py。

核心职责是对拦截到的对话消息进行清洗、过滤,同时检测用户的纠正与正向反馈信号,为后续记忆更新提供高质量的输入,这是分层架构中“工作记忆”的核心处理环节,也是保证记忆准确性的关键。

该层主要包含两个核心功能:

  • 对话清洗
  • 关键信号检测。

两者均通过源码中的工具函数实现

5.2 消息预处理层:清洗与信号检测——记忆准确性的第一道防线

5.2.1 对话清洗:过滤无效信息,避免记忆污染

对话清洗的核心目标是剔除临时、无效的信息,避免其进入长期记忆,导致记忆冗余或污染。

根据源码逻辑,清洗规则主要包含三点:

(1) 仅保留用户输入(human类型)和最终助手回复(ai类型,无工具调用),过滤中间工具调用、临时调试信息;

(2) 自动剥离 uploaded_files 标签及内容,因为文件上传是会话临时操作,不适合存入长期记忆(避免临时文件路径污染记忆);

(3) 过滤纯文件上传消息(剥离标签后无有效内容)及其后续的AI回复,避免无效交互进入记忆更新流程。

5.2.2 关键信号检测:感知用户反馈,优化记忆更新策略

DeerFlow 2.0记忆模块的核心亮点之一,是能够自动检测用户的纠正与正向反馈信号,据此调整记忆更新策略:

  • 当检测到用户纠正时,会优先更新记忆中的错误信息;
  • 当检测到正向反馈时,会强化相关记忆的置信度,这也是实现“记忆自我优化”的关键。

尼恩提示:原文3w字以上, 超过平台限制, 此处省略 1000字,具体请参考 免费pdf。

完整版本,请参考 尼恩 免费百度网盘 免费pdf ,点赞收藏本文后,截图 找尼恩获取

  1. 3 防抖队列层:MemoryUpdateQueue——异步批量处理的核心

防抖队列层对应源码中的queue.py。

是事件驱动异步设计的核心载体,其核心作用: 接收对话预处理后的记忆更新请求,通过防抖机制实现批量处理。

防抖机制 的作用: 平衡记忆更新的实时性与性能,避免高频对话导致的LLM调用过载。

结合分层架构思维,该层属于“处理层”与“存储层”之间的缓冲层,负责将分散的记忆更新请求聚合,批量触发后续的记忆更新流程。

既减少了LLM调用次数,又保证了记忆更新的时效性,是分层架构中“解耦与优化”的关键环节。

5.3 防抖队列层:MemoryUpdateQueue——异步批量处理的核心

经过过滤的对话消息,不会立即触发 LLM 更新——这是工程化落地的关键优化。

尼恩提示:原文3w字以上, 超过平台限制, 此处省略 1000字,具体请参考 免费pdf。

完整版本,请参考 尼恩 免费百度网盘 免费pdf ,点赞收藏本文后,截图 找尼恩获取

  1. 4 记忆更新引擎层:结构化记忆生成——记忆模块的核心大脑

记忆更新引擎层对应源码中的updater.py和prompt.py,是整个记忆模块的 两个核心类。

其中队列处理 核心的核心,就是 MemoryUpdater.update_memory 方法。

5.4 记忆更新引擎层:结构化记忆生成——记忆模块的核心大脑

update_memory 这个方法相当于一条标准化的生产管道,把“读取-格式化-调用-更新-写入”的全流程串起来,逻辑清晰,可复用、可扩展:

(1) 读取当前记忆 → get_memory_data()(拉取存量记忆,避免重复创建)

(2) 格式化对话 → format_conversation_for_update(messages)(把消息列表转成 LLM 能快速识别的简洁格式)

(3) 构建 Prompt → 将当前记忆 + 格式化后的对话,填入 MEMORY_UPDATE_PROMPT 模板(标准化 Prompt,提升 LLM 抽取准确率)

(4) 调用 LLM → 让模型输出 JSON 格式的更新指令(结构化输出,便于后续解析和应用)

(5) 应用更新 → _apply_updates()(将 LLM 抽取的信息,合并到现有记忆中,避免覆盖存量有效数据)

(6) 清洗上传痕迹 → _strip_upload_mentions_from_memory()(二次清洗,防止遗漏临时资源痕迹)

(7) 原子写入 → _save_memory_to_file()(保证数据一致性,避免文件损坏)

其中,format_conversation_for_update 方法的核心作用,是把杂乱的消息列表,转成 LLM 能高效处理的简洁文本,同时做了超长消息截断,避免 Prompt 过长导致的 LLM 调用失败:

def format_conversation_for_update(messages: list[Any]) -> str:
    lines = []
    for msg in messages:
        role = getattr(msg, "type", "unknown")
        content = getattr(msg, "content", str(msg))
        # 截断过长消息
        if len(str(content)) > 1000:
            content = str(content)[:1000] + "..."
        if role == "human":
            lines.append(f"User: {content}")
        elif role == "ai":
            lines.append(f"Assistant: {content}")
    return "/n/n".join(lines)

这个方法,负责将预处理后的对话消息,通过LLM 调用, 生成结构化的记忆数据,实现“非结构化对话→结构化记忆”的转换,这也是分层架构中“情景记忆→语义记忆”的核心转换环节。

该层的实现严格遵循分层架构思维,将记忆分为“用户上下文”“历史分层”“事实列表”三个结构化层次,同时通过精细的提示工程(prompt),确保LLM生成的记忆数据符合规范,可直接用于后续的持久化存储与注入。

  1. 5 持久化存储层:MemoryStorage——记忆的可靠载体

持久化存储层对应源码中的storage.py。

核心职责是实现记忆数据的持久化存储与缓存管理,是分层架构中“持久化层”的核心,确保记忆数据在会话重启、服务重启后不丢失。

该层的设计遵循“抽象接口+具体实现”的模式,体现了“依赖倒置原则”。

“依赖倒置原则” 便于后续扩展存储后端,与DeerFlow 2.0官方RFC中“定义统一memory contract,兼容不同存储后端”的设计思路完全一致。

其中 抽象基类MemoryStorage定义统一的load、reload、save接口,具体实现(如FileMemoryStorage)负责实际的存储操作,上层模块仅依赖抽象接口,不依赖具体实现。

尼恩提示:原文3w字以上, 超过平台限制, 此处省略 1000字,具体请参考 免费pdf。

完整版本,请参考 尼恩 免费百度网盘 免费pdf ,点赞收藏本文后,截图 找尼恩获取

  1. 6 记忆注入层:格式化与Token预算控制——记忆复用的关键

记忆注入层对应源码中的prompt.py.

核心职责是将持久化的记忆数据,按Token预算格式化后,注入到Agent的系统提示中,供LLM在后续对话中复用.

这是分层架构中“记忆复用”的核心环节,也是实现“个性化交互”的关键。

5.6 记忆注入层:格式化与Token预算控制——记忆复用的关键

由于LLM的上下文窗口有限,直接将完整的记忆数据注入会导致Token溢出,因此DeerFlow 2.0设计了“Token预算感知”的动态格式化策略。

核心逻辑是:按置信度排序事实,优先保留高置信度、高相关性的记忆内容,确保在Token预算内,为LLM提供最有价值的记忆信息。

尼恩提示:原文3w字以上, 超过平台限制, 此处省略 1000字,具体请参考 免费pdf。

完整版本,请参考 尼恩 免费百度网盘 免费pdf ,点赞收藏本文后,截图 找尼恩获取

六、核心架构思维与方法的落地总结

================

结合前文全模块源码拆解与工程实现细节,DeerFlow 2.0记忆模块的两大核心架构思维——分层架构思维与事件驱动异步设计。

并非单纯的理论概念,而是深度落地到每一行代码、每一个模块职责划分的工程方法论,二者相辅相成,共同构建了这套高效、稳定、可扩展的智能记忆系统,本节将对两大思维的落地逻辑、核心价值做系统性总结,提炼可复用的架构设计经验。

六、核心架构思维与方法的落地总结

  1. 1 分层架构思维:从理论到工程的全链路落地

分层架构是DeerFlow 2.0记忆模块的核心骨架,其落地并非简单的模块拆分,而是遵循“职责单

一、层级解耦、数据流转闭环、增量优化”的核心原则,完全对标计算机存储分层与网络分层的成熟设计思路,彻底解决了传统Agent记忆系统“一锅烩”导致的性能差、难维护、不可扩展问题。

从落地链路来看,分层架构贯穿记忆全生命周期:交互入口层→预处理提纯层→异步缓冲层→核心计算层→持久化存储层→复用注入层,每一层只负责单一核心职责,层与层之间通过标准化接口通信,不直接依赖底层实现细节。这种设计带来三大核心工程价值:

  • 维护性极强:任意层级的逻辑修改不会影响其他模块,例如后续优化记忆清洗规则,只需改动message_processing.py,无需触碰队列、引擎、存储模块,大幅降低源码维护与二次开发成本;
  • 性能分层优化:高频交互的工作记忆放在内存缓存,长期沉淀的语义记忆落地磁盘,热点数据快速访问、冷数据持久存储,完美平衡低延迟与大容量需求,破解LLM上下文窗口瓶颈;
  • 极致可扩展性:存储层基于抽象接口设计,后续替换向量数据库、新增分布式存储、接入记忆检索引擎,只需实现对应接口,无需重构核心逻辑;同时支持多Agent独立记忆分层,适配Super Agent多实例编排场景。

相较于市面上多数Agent框架“对话历史直接拼接”的粗放式记忆设计,DeerFlow 2.0的分层思维将记忆从“临时缓存”升级为“结构化状态管理系统”,每一层的功能边界清晰、数据流转可控,真正实现了记忆的“可沉淀、可检索、可修正、可治理”,这也是其能支撑企业级长对话、多轮复杂交互的核心原因。

  1. 2 事件驱动异步设计:异步解耦与性能优化的工程实践

事件驱动异步设计是 DeerFlow 2.0 记忆模块实现 “高效交互 + 低损耗更新” 的核心支撑,其落地核心是以 “对话事件” 为核心驱动源,通过 “事件拦截 - 异步聚合 - 批量处理 - 结果反馈” 的闭环链路,实现 “对话交互” 与 “记忆更新” 的解耦,彻底解决了传统 Agent 记忆系统 “同步更新阻塞交互”“高频调用导致性能过载” 的行业痛点,与分层架构思维形成互补,共同支撑记忆系统的高效运行。

与分层架构思维聚焦 “空间上的模块解耦与职责划分” 不同,事件驱动异步设计聚焦 “时间上的流程解耦与效率优化”,其核心落地逻辑并非单纯引入异步队列,而是结合 AI Agent 对话场景的特性,实现了 “事件感知精准化、异步处理智能化、资源消耗可控化” 的工程实践,具体可从三个核心维度拆解。

小白/程序员如何系统学习大模型LLM?

由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。

但是具体到个人,只能说是:

“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。

这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。

我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段(10天):初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。

  • 大模型 AI 能干什么?
  • 大模型是怎样获得「智能」的?
  • 用好 AI 的核心心法
  • 大模型应用业务架构
  • 大模型应用技术架构
  • 代码示例:向 GPT-3.5 灌入新知识
  • 提示工程的意义和核心思想
  • Prompt 典型构成
  • 指令调优方法论
  • 思维链和思维树
  • Prompt 攻击和防范

第二阶段(30天):高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。

  • 为什么要做 RAG
  • 搭建一个简单的 ChatPDF
  • 检索的基础概念
  • 什么是向量表示(Embeddings)
  • 向量数据库与向量检索
  • 基于向量检索的 RAG
  • 搭建 RAG 系统的扩展知识
  • 混合检索与 RAG-Fusion 简介
  • 向量模型本地部署

第三阶段(30天):模型训练

恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。

到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?

  • 为什么要做 RAG
  • 什么是模型
  • 什么是模型训练
  • 求解器 & 损失函数简介
  • 小实验2:手写一个简单的神经网络并训练它
  • 什么是训练/预训练/微调/轻量化微调
  • Transformer结构简介
  • 轻量化微调
  • 实验数据集的构建

第四阶段(20天):商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。

  • 硬件选型
  • 带你了解全球大模型
  • 使用国产大模型服务
  • 搭建 OpenAI 代理
  • 热身:基于阿里云 PAI 部署 Stable Diffusion
  • 在本地计算机运行大模型
  • 大模型的私有化部署
  • 基于 vLLM 部署大模型
  • 案例:如何优雅地在阿里云私有部署开源大模型
  • 部署一套开源 LLM 项目
  • 内容安全
  • 互联网信息服务算法备案

学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。

如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

在这里插入图片描述

Logo

汇聚全球AI编程工具,助力开发者即刻编程。

更多推荐