Agent 记忆架构设计参考
Agent 记忆架构设计参考
20260227
引言
在构建 Long-Run Agent 时，记忆架构的选择是核心设计决策。本文聚焦于两种在工业界广泛采用的实用方案：
- 方案 A：RAG（外化知识架构）
- 方案 B：SFT + 蒸馏 + Markdown（内化知识架构）
这两种方案代表了知识存储与检索的不同哲学，各自适用于特定的业务场景和技术约束。
方案 A：RAG（外化知识架构）
核心原理
知识外置存储于向量数据库或文档索引中，Agent 通过实时检索动态组装上下文。工作记忆保留近期交互，参考记忆通过 RAG 机制按需加载。
记忆分层
| 层级 | 形态 | 更新频率 | 作用 |
|---|---|---|---|
| 工作记忆 | 原始对话 token | 实时 | 保持即时上下文连贯性 |
| 参考记忆 | 向量索引 + 原始文档 | 分钟级 | 动态检索相关背景知识 |
| 核心记忆 | 提示工程 + 系统指令 | 手动 | 定义行为边界与基础能力 |
优势与局限
优势：
- 知识更新实时，无需重新训练
- 可溯源，支持事实验证与审计
- 存储容量可水平扩展
- 适合开放域、快速演变的知识
局限：
- 检索质量依赖索引质量，存在"检索失败"风险
- 上下文碎片化，多跳推理能力受限
- 每次请求需额外检索延迟（500ms-2s）
- 长上下文处理成本随检索结果增加而上升
典型应用场景
- 企业知识问答系统
- 实时信息检索助手（新闻、市场数据）
- 多文档分析与对比
- 需要频繁更新知识库的领域
方案 B：SFT + 蒸馏 + Markdown（内化知识架构）
核心原理
通过监督微调（SFT）和知识蒸馏将领域知识内化于模型权重，结构化知识以 Markdown 格式存储于上下文，Agent 直接基于预训练知识和显式结构化记忆进行推理。
记忆分层
| 层级 | 形态 | 更新频率 | 作用 |
|---|---|---|---|
| 工作记忆 | 原始对话 + Markdown 片段 | 实时 | 当前任务上下文 |
| 参考记忆 | 结构化 Markdown 文档 | 天/周级 | 领域知识、最佳实践、用户偏好 |
| 核心记忆 | 模型权重（蒸馏后） | 月/年级 | 深层领域模式与推理能力 |
优势与局限
优势：
- 推理速度快，无需外部检索延迟
- 知识内化后推理更连贯、深度更强
- 适合结构化、稳定的领域知识
- 离线可用，不依赖外部存储
局限：
- 知识更新需重新蒸馏或微调，周期长
- 存在"记忆幻觉"风险，难以精确控制
- 训练成本高，需持续 ML 工程投入
- 不适合快速演变的知识
典型应用场景
- 代码助手与 IDE 智能体
- 医疗诊断决策支持
- 法律合规审查系统
- 企业内部标准化流程助手
核心对比
| 维度 | 方案 A：RAG | 方案 B：SFT + 蒸馏 + Markdown |
|---|---|---|
| 知识位置 | 外部向量库 | 模型权重 + 结构化 Markdown |
| 更新速度 | 实时（分钟级） | 批次（天/周级） |
| 推理延迟 | 中（含检索时间） | 低（纯推理） |
| 可解释性 | 中（可溯源检索结果） | 高（Markdown 人类可读） |
| 幻觉控制 | 较好（事实可验证） | 中等（依赖蒸馏质量） |
| 领域深度 | 中等（依赖检索精度） | 深（内化后模式识别强） |
| 工程复杂度 | 中（需维护检索管道） | 高（需持续训练流程） |
| 扩展性 | 高（索引水平扩展） | 受限（模型大小固定） |
结论
两种方案并非互斥，而是针对不同的知识特性与任务需求。现代 Agent 系统往往采用混合架构，在实时性、深度、成本之间寻求平衡。理解这两种方案的特征，有助于在特定约束下做出明智的架构选择。
附录：多维度决策参考表格
附录 A：多维度决策参考表格
任务类型维度
| 任务特征 | 方案 A：RAG | 方案 B：SFT + 蒸馏 + Markdown | 备注 |
|---|---|---|---|
| 探索型任务（研究、头脑风暴、开放域探索） | ✅ 优秀 | ⚠️ 受限 | RAG 支持跨文档意外关联，适合探索；蒸馏知识固化，限制创新 |
| 确定性任务（标准化流程、合规检查、代码生成） | ⚠️ 一致性问题 | ✅ 优秀 | 蒸馏确保行为一致；RAG 检索波动可能导致输出不稳定 |
| 多跳推理（复杂分析、因果链追踪） | ⚠️ 检索链断裂风险 | ✅ 推理链内化更稳定 | RAG 每跳依赖检索质量；内化知识支持深层模式匹配 |
| 创造性生成（写作、设计建议） | ✅ 素材丰富 | ✅ 风格一致 | RAG 提供多样素材；蒸馏确保输出风格统一 |
决策建议：探索型选 A，确定性选 B，多跳推理优先选 B。
知识更新频率维度
| 更新频率 | 方案 A：RAG | 方案 B：SFT + 蒸馏 + Markdown | 备注 |
|---|---|---|---|
| 实时（秒/分钟级，股价、新闻、日志） | ✅ 原生支持 | ❌ 不可行 | RAG 索引实时更新；蒸馏需训练周期 |
| 高频（小时级，产品库存、用户行为） | ✅ 适合 | ⚠️ 成本高昂 | RAG 轻量更新；蒸馏频繁重训练不经济 |
| 中频（天/周级，文档版本、规则调整） | ✅ 适合 | ✅ 适合 | 两者均可，RAG 更灵活，B 更稳定 |
| 低频（月/年级，领域知识、法规） | ⚠️ 过度设计 | ✅ 最优 | 长期稳定知识适合蒸馏内化；RAG 维护成本高 |
决策建议：实时/高频选 A，低频选 B，中频根据稳定性需求选择。
知识领域宽度维度
| 领域特征 | 方案 A：RAG | 方案 B：SFT + 蒸馏 + Markdown | 备注 |
|---|---|---|---|
| 宽领域（跨学科、开放域问答） | ✅ 扩展性强 | ❌ 蒸馏覆盖困难 | RAG 通过增加文档扩展；蒸馏需大量多样化数据 |
| 深领域（专业垂直，如法律、医学） | ⚠️ 检索精度挑战 | ✅ 专家级表现 | 蒸馏可捕捉深层模式；RAG 需极高质量索引 |
| 结构化知识（数据库、API、代码库） | ✅ 精确检索 | ✅ 结构化 Markdown 友好 | 两者均可，RAG 适合动态查询，B 适合模式内化 |
| 非结构化知识（文档、聊天记录、邮件） | ✅ 原生支持 | ⚠️ 需预处理结构化 | RAG 直接处理原始文本；B 需先提取结构化知识 |
决策建议：宽领域选 A，深领域选 B，非结构化优先选 A。
风险偏好与一致性要求维度
| 风险/一致性要求 | 方案 A：RAG | 方案 B：SFT + 蒸馏 + Markdown | 备注 |
|---|---|---|---|
| 高风险厌恶（金融交易、医疗诊断） | ✅ 可溯源审计 | ⚠️ 黑箱风险 | RAG 提供事实来源；蒸馏决策难以解释 |
| 高一致性要求（合规审查、标准化输出） | ⚠️ 检索波动 | ✅ 行为稳定 | 蒸馏确保重复一致性；RAG 受索引质量影响 |
| 可解释性优先（监管报告、决策支持） | ✅ 检索结果即证据 | ✅ Markdown 人类可读 | RAG 提供片段溯源；B 提供结构化理由 |
| 容错容忍（内部工具、原型系统） | ✅ 快速迭代 | ✅ 快速推理 | 两者均可，根据其他维度选择 |
决策建议：高风险/审计需求选 A，高一致性需求选 B。
资源限制维度
| 资源约束 | 方案 A：RAG | 方案 B：SFT + 蒸馏 + Markdown | 备注 |
|---|---|---|---|
| 计算资源受限（边缘设备、移动端） | ⚠️ 检索服务依赖 | ✅ 推理后可离线 | B 蒸馏后模型可独立运行；A 依赖向量库服务 |
| 存储资源受限 | ✅ 索引可外部托管 | ⚠️ 模型体积大 | RAG 存储与计算分离；B 需加载完整模型 |
| 网络带宽受限（离线环境、高延迟网络） | ❌ 检索需网络 | ✅ 本地推理 | B 完全离线可用；A 需连接知识库 |
| 工程人力受限 | ⚠️ 需维护检索管道 | ⚠️ 需 ML 工程能力 | A 需 DevOps 维护；B 需算法工程训练 |
| 时间资源受限（快速上线） | ✅ 快速部署 | ❌ 训练周期长 | RAG 即插即用；蒸馏需数据准备与训练 |
决策建议：离线/边缘场景选 B，快速上线选 A，存储受限选 A。
综合决策矩阵
| 场景组合 | 推荐方案 | 理由 |
|---|---|---|
| 实时新闻助手 + 宽领域 + 快速上线 | A | 更新频率与上线速度优先 |
| 代码 IDE 助手 + 深领域 + 高一致性 | B | 稳定性与深度优先 |
| 医疗诊断支持 + 高风险 + 深领域 | 混合 | B 为主提供深度，A 为辅助提供最新研究 |
| 企业内部 FAQ + 低频更新 + 高一致性 | B | 稳定知识适合蒸馏 |
| 金融交易监控 + 实时 + 高风险 | A | 实时性与可溯源性优先 |
| 跨领域研究助手 + 探索型 + 宽领域 | A | 开放性与知识广度优先 |
混合架构建议
对于复杂生产环境，推荐采用分层混合架构：
┌─────────────────────────────────────────┐
│ 实时感知层（RAG） │
│ 处理：实时数据、外部 API、最新文档 │
│ 更新：分钟级 │
└─────────────────────────────────────────┘
↓ 蒸馏/沉淀（定期）
┌─────────────────────────────────────────┐
│ 预计算知识层（SFT + Markdown） │
│ 处理：领域模式、最佳实践、用户偏好 │
│ 更新：周/月级 │
└─────────────────────────────────────────┘
动态路由策略：
- 高频、实时查询 → 路由至 RAG 层
- 深度、稳定查询 → 路由至蒸馏层
- 冲突时 → 以 RAG 最新信息为准，但用蒸馏层进行一致性校验
附录 B：三类 Agent 部署形态下的记忆架构选择
Agent 的记忆架构不仅取决于知识特性，还受到Agent 逻辑运行位置与LLM 推理位置的深刻影响。根据这两个维度，可将生产级 Agent 划分为三种典型形态：
- 端侧 Agent + 端侧 LLM：全部计算发生在设备端。
- 端侧 Agent + 远程 LLM：Agent 逻辑在端侧，LLM 推理调用云端 API。
- 远程 Agent + 远程 LLM：全部计算发生在云端。
每种形态对记忆的位置、容量、更新机制、隐私保护都有截然不同的要求，进而决定了记忆架构的选择（RAG 外化知识 vs SFT 内化知识）。
形态一：端侧 Agent + 端侧 LLM
定义
Agent 的逻辑控制与 LLM 推理均在用户设备（手机、PC、边缘设备）上完成，完全离线或仅使用本地资源。
记忆架构特点
| 记忆层级 | 实现形态 | 约束与策略 |
|---|---|---|
| 核心记忆 | 蒸馏后的小型量化模型（1B–7B，INT4/INT8） | 模型体积受设备存储限制，需极致压缩 |
| 参考记忆 | 本地 SQLite / 轻量级向量库（如 LanceDB） | 存储容量 MB~GB 级，仅保留用户核心知识 |
| 工作记忆 | 短上下文（2K–8K tokens） | 受设备内存限制，需及时裁剪 |
优势
- 隐私极致：数据永不离开设备，满足医疗、金融等强合规场景。
- 零网络延迟：推理完全本地化，适合车载、工业控制等实时场景。
- 离线可用：无网络环境下的唯一选择（航空、远洋）。
劣势
- 模型能力受限：小模型在复杂推理、创意生成上远逊于云端大模型。
- 知识更新慢：依赖应用商店发版，无法实时获取最新知识。
- 资源拮据：电池、内存、算力均有限，无法承载大规模检索或长上下文。
记忆架构选择：强烈倾向方案 B（内化知识）
- 核心记忆必须通过 SFT + 蒸馏 将领域知识固化于权重中，以最小化运行时检索需求。
- 参考记忆可采用轻量本地 RAG（如设备本地文档、短信、日历），但需严格控制索引规模，避免性能开销。
- 工作记忆通常只保留当前对话，重启即清零，或通过加密文件持久化用户长期偏好。
典型场景
- 手机离线助理（如 Siri 本地模式）
- 车载语音助手（无网络隧道）
- 工业设备边缘诊断
- 个人健康数据分析（不上云）
形态二：端侧 Agent + 远程 LLM
定义
Agent 的核心逻辑、隐私数据处理、短期记忆在端侧运行，而复杂推理任务则通过 API 调用云端大模型完成。
记忆架构特点
| 记忆层级 | 实现形态 | 分工策略 |
|---|---|---|
| 核心记忆 | 端侧：蒸馏小模型（处理简单意图） 云端：通用大模型（70B+） |
端侧负责过滤、脱敏、缓存；云端负责深度推理 |
| 参考记忆 | 端侧：本地加密数据库（存储用户隐私知识） 云端：向量库 + 公共知识（实时更新） |
隐私数据不出设备；公共数据云端 RAG |
| 工作记忆 | 端侧：短期对话窗口 云端：部分对话上下文（经脱敏） |
端侧维持即时连贯；云端维持任务级上下文 |
优势
- 隐私与智能的平衡：生物特征、本地文件等隐私数据留在端侧，仅脱敏后的查询上云。
- 云端能力按需使用：简单请求由端侧小模型响应，节省成本与延迟；复杂请求才调用云端大模型。
- 可缓存高频知识：端侧可缓存云端返回的常见答案，减少重复调用。
劣势
- 依赖网络：复杂请求存在 500ms–2s 额外延迟。
- 端云同步复杂：需设计差分隐私、联邦学习等机制更新端侧知识。
- 成本控制挑战：云端 API 调用可能产生显著费用。
记忆架构选择：混合架构，动态路由
- 端侧采用**方案 B（内化知识）**处理隐私数据、高频场景，并作为第一道过滤器。
- 云端以**方案 A（RAG）**为核心，实时检索海量公共知识，辅以少量微调（SFT）处理稳定领域。
- 工作记忆采用“端侧主存、云端辅存”策略：近期对话在端侧，需多跳推理时打包脱敏后上传云端。
典型场景
- 智能手机语音助手（如 Google Assistant 在线模式）
- 智能音箱（端侧唤醒词 + 云端问答）
- 带隐私保护的医疗咨询 App（端侧病历 + 云端医学知识）
- 混合办公助手（端侧日历邮件 + 云端企业知识库）
形态三：远程 Agent + 远程 LLM
定义
Agent 的逻辑控制与 LLM 推理均部署在云端服务器，用户通过 API 或前端界面交互。
记忆架构特点
| 记忆层级 | 实现形态 | 扩展性 |
|---|---|---|
| 核心记忆 | 云端大模型（70B+，可 MoE） | 计算资源充裕，追求极致性能 |
| 参考记忆 | 分布式向量数据库（Milvus/Pinecone）、对象存储 | 水平扩展至 TB/PB 级，支持实时索引 |
| 工作记忆 | 长上下文窗口（128K–1M tokens） | 利用云端大内存，支持超长对话与文档分析 |
优势
- 最强模型能力：可使用顶尖大模型，复杂推理、创意生成能力无妥协。
- 无限存储：海量知识库实时更新，无容量焦虑。
- 运维简便：统一升级模型与知识，客户端零更新。
- 多租户共享：用户间可共享聚合洞察（经隐私清洗）。
劣势
- 数据隐私风险：用户数据需上传，合规成本高。
- 网络依赖：请求延迟受网络影响，无法离线。
- 成本高昂：长上下文推理、大规模检索带来显著算力开销。
记忆架构选择：灵活采用 A/B 或混合
- 实时性要求高、知识变动快的场景（如新闻助手、金融交易）优先 方案 A（RAG）。
- 稳定性要求高、知识固化的场景（如法律合规审查、代码生成）优先 方案 B（SFT + 蒸馏 + Markdown），或使用 RAG 作为事实补充层。
- 长上下文记忆可直接利用模型的原生窗口，或外挂向量缓存实现近似无限记忆。
典型场景
- 企业级知识问答系统（全员知识库）
- 多模态内容生成服务（文生图、视频生成）
- 复杂数据分析 Agent（BI 报表、科研计算）
- 跨语言实时翻译与本地化服务
三类形态对比总览
| 维度 | 端侧 Agent + 端侧 LLM | 端侧 Agent + 远程 LLM | 远程 Agent + 远程 LLM |
|---|---|---|---|
| 隐私保护 | ⭐⭐⭐（最高） | ⭐⭐（中等，隐私数据在端） | ⭐（最低，数据上云） |
| 离线能力 | 完全离线 | 部分离线（简单请求） | 不可离线 |
| 延迟 | 低（本地推理） | 中（网络+云端推理） | 中高（网络+云端推理） |
| 模型能力 | 受限（小模型） | 强（可调用云端大模型） | 最强（云端大模型） |
| 知识更新速度 | 慢（OTA 发版） | 中（端侧缓存 + 云端实时） | 快（实时索引/热更新） |
| 存储容量 | MB~GB 级 | 端侧有限 + 云端无限 | 几乎无限 |
| 典型记忆架构 | 方案 B（内化为主） | 混合（端侧 B + 云端 A） | 方案 A / 方案 B / 混合 |
| 工程复杂度 | 中（量化、压缩） | 高（端云协同、同步策略） | 中（运维、成本控制） |
决策指南：如何选择部署形态与记忆架构
| 核心约束 | 推荐形态 | 记忆架构考量 |
|---|---|---|
| 数据必须绝对不出设备（如医疗原始数据） | 端侧 Agent + 端侧 LLM | 采用方案 B，将领域知识蒸馏进小模型；必须检索时使用本地加密向量库。 |
| 隐私敏感但需要强大模型能力（如个人助理） | 端侧 Agent + 远程 LLM | 端侧用方案 B 处理隐私数据；云端用方案 A 处理公共知识；设计差分隐私同步。 |
| 实时性要求极高，网络不可靠（如自动驾驶） | 端侧 Agent + 端侧 LLM | 方案 B + 轻量本地 RAG，确保所有决策在本地闭环。 |
| 追求最强智能，隐私合规可满足（如企业知识库） | 远程 Agent + 远程 LLM | 根据知识变动速度选择 A 或 B：高频变动选 A，稳定知识选 B，通常两者混合。 |
| 成本敏感，希望复用现有云端设施 | 远程 Agent + 远程 LLM | 方案 A（RAG）可快速上线，无需训练成本；后续可对高频知识蒸馏优化。 |
| 跨设备一致性与个性化并存 | 混合形态（端云协同） | 端侧存储用户偏好（方案 B），云端同步脱敏后的画像，实现“端侧隐私 + 云端一致”。 |
总结
记忆架构不是孤立的选择，必须与 Agent 的部署形态协同设计。端侧 LLM 的兴起使“端侧 Agent + 端侧 LLM”成为隐私敏感场景的可行路径，而“端侧 Agent + 远程 LLM”则成为平衡隐私与智能的主流形态。无论选择哪种形态，记忆架构都应遵循“隐私数据本地沉淀，公共知识云端流动，核心能力模型内化”的原则，在具体约束下实现最优的智能体验。
附录 C：利用 LoRA 向端侧 Agent 发布 SFT 结果
端侧 Agent 的记忆架构中，核心记忆通常表现为内化于模型权重的知识（即通过 SFT 训练后的 LLM）。然而，模型一旦部署到设备端，便面临静态固化与用户动态需求之间的矛盾：用户希望 Agent 持续学习新知识、适应个性化场景，但完整模型更新成本高、周期长。
参数高效微调技术，特别是 LoRA，为解决这一矛盾提供了轻量级的发布途径。通过 LoRA，可将 SFT 结果封装为 MB 级的适配器插件，动态注入端侧 LLM，实现“一次基座，持续进化”的记忆架构。本附录聚焦于面向大语言模型（LLM）的 LoRA 发布方法，不涉及具体行业案例。
C.1 LoRA 原理概要
LoRA 的核心设计是：在预训练 LLM 的权重矩阵旁并联两个小型低秩矩阵（适配器）。训练时仅更新这两个小矩阵，原始模型权重保持冻结；推理时将小矩阵的输出与原始权重输出相加，等效于模型参数发生了微小调整。
这一结构带来了端侧部署极为看重的两个特性：
- 体积小巧：每个任务的适配器仅包含原始模型参数的 0.1%～1%，通常在数 MB 量级，便于通过网络分发。
- 热插拔能力：适配器可与基座模型解耦加载，运行时动态切换，无需重启应用，支持多业务共享同一基座。
C.2 端侧 LoRA 发布的三种技术路径
根据端侧设备的性能约束与业务需求，LoRA 适配器的发布与部署可分为以下三种模式。
C.2.1 静态编译 + 插件化部署
适用场景：端侧 Agent 需支持多个业务领域（如闲聊、知识问答、设备控制），内存资源有限，需灵活扩展。
核心流程：
- 基座模型预处理：对基础 LLM 进行量化压缩（如 INT4/INT8），减小磁盘占用与运行时内存。
- LoRA 适配器独立编译：将针对不同任务 SFT 得到的 LoRA 适配器与基座模型解耦，单独编译为插件模块。编译过程包括对适配器参数的量化，并生成元数据（任务类型、输入输出规范等）。
- 运行时动态加载：用户请求到达时，Agent 框架根据意图识别，加载对应的 LoRA 插件，与基座模型组合推理；请求结束后卸载插件，释放内存。
- 更新机制：新业务上线仅需推送 MB 级的 LoRA 插件文件；插件版本管理由框架负责，支持懒加载（首次使用时下载）与预缓存（根据用户行为预测提前下载）。
特点：
- 内存效率高：仅需在内存中保留一份基座模型。
- 切换开销可控：插件加载/卸载在微秒级，需优化调度策略。
- 多租户隔离：不同业务的适配器互不干扰，易于扩展。
C.2.2 合并部署
适用场景：推理延迟要求极致（如实时语音交互）、或业务相对固定（如专用设备），且可以接受低频更新。
核心流程：
- 离线合并：在设备空闲时（如充电、Wi-Fi 环境），将 LoRA 适配器参数与基座模型权重合并，生成一个新的完整模型。
- 模型替换：将合并后的模型重新量化、编译，替换设备上的原基座模型。
- 推理：后续所有请求直接使用合并模型，推理路径与原始模型完全一致，无任何额外计算开销。
特点：
- 性能最优：无运行时附加计算，延迟与原始模型相同。
- 更新粒度粗：需完整替换模型文件（GB 级），适合低频更新场景（如用户长期偏好固化、企业定制设备）。
- 可混合使用：设备可同时保留基座模型与若干合并模型，根据任务路由选择。
C.2.3 端侧在线微调
适用场景：隐私敏感且需要持续个性化学习的场景（如个人助手），设备具备一定 AI 算力（如旗舰手机、边缘 AI 盒子）。
核心流程：
- 本地数据收集：在用户授权下，收集设备上的交互数据（如对话历史、使用习惯），并进行差分隐私处理。
- 内存高效反向传播：利用设备 NPU/GPU 计算 LoRA 适配器的梯度。需采用梯度检查点、按需解压等技术控制内存峰值，使反向传播能在端侧内存限制内完成。
- 适配器本地更新：根据梯度更新本地的 LoRA 适配器参数。可结合差分隐私添加噪声，防止从梯度反推原始数据。
- 可选联邦聚合：在用户许可下，将加密后的梯度上传至云端参与联邦学习，聚合出更好的全局适配器，再分发给其他用户，实现“众包式”进化。
特点：
- 隐私最强：用户数据永不离开设备，仅上传脱敏梯度。
- 实时个性化：模型随用户使用习惯持续微调，越用越懂用户。
- 技术门槛高：对设备算力、内存、功耗有较高要求；目前处于前沿探索阶段，但正逐步实用化。
C.3 端侧 LoRA 发布的工程考量
C.3.1 量化与精度平衡
端侧部署必须量化。实践表明，INT8 量化对 LoRA 适配器精度影响较小，INT4 量化可能带来显著损失。可引入进阶量化技术（如自适应舍入、混合精度）在压缩比与精度间取得平衡。
C.3.2 多适配器管理
当设备支持数十个业务适配器时，需建立统一的管理机制：
- 元数据仓库：记录每个适配器的任务类型、版本、依赖的基座版本。
- 懒加载与预缓存：根据用户行为预测，提前下载可能使用的适配器。
- LRU 淘汰：内存不足时，自动卸载最近最少使用的适配器。
C.3.3 更新分发机制
- 增量推送：适配器更新时仅推送参数差异，减少流量消耗。
- 版本兼容：基座模型升级后，旧适配器需通过自动转换工具适配新基座，或提示用户重新下载对应版本。
C.4 决策指南：选择何种 LoRA 发布模式
| 业务场景 | 推荐发布模式 | 关键考量 |
|---|---|---|
| 多业务复用的通用助手（内存敏感） | 静态编译 + 插件化部署 | 内存效率优先，需调度优化 |
| 专用设备/固化场景（性能敏感） | 合并部署 | 推理性能优先，接受低频更新 |
| 隐私优先的持续个性化学习 | 端侧在线微调 | 隐私与智能的极致平衡，限高端设备 |
总结：LoRA 技术为端侧 Agent 的记忆架构引入了“可插拔的 SFT 能力”。通过静态插件、合并部署或端侧在线微调，端侧 LLM 能够在不频繁更换基座的前提下，持续吸收新知识、适应个性化需求，实现记忆的动态进化。随着端侧算力提升与微调框架成熟，设备本地的实时学习将成为端侧 Agent 的标准能力。
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
25
0- 0
已为社区贡献6条内容
所有评论(0)