在 2026 中国国际大学生创新大赛的 openEuler 方向命题里“基于鲲鹏平台的 Agent Memory 记忆管理系统”是一个把大模型应用和国产基础软件结合得非常紧密的题目。Agent 在大模型对话、智能客服、办公助手等场景中越来越常见但模型本身没有记忆能力每一次对话结束后上下文就消失了。Agent 要连续完成任务、记住用户偏好、在后续会话中复用之前的结果就必须有一套独立的记忆管理系统。这个系统承担的不只是“把聊天记录存下来”而是要在合适的时机写入关键信息、在需要时快速召回、在记忆过时后更新或遗忘。这篇文章会沿着一条可复现的技术路线展开先在鲲鹏平台的 openEuler 系统上搭建依赖环境再实现一个包含持久化、检索和衰减策略的 Agent Memory 服务最后用一组接口验证记忆闭环是否成立。文章也会把备赛过程中最容易卡住的环境问题整理成排查清单帮助参赛队伍从“能演示”走向“能讲清楚”。1. 理解命题Agent Memory 到底要管理什么1.1 先看懂 Agent 为什么需要记忆大模型本身是无状态的。对于同一个模型输入同样的问题即使放在多轮对话中它也无法自发记住五分钟前用户说过什么。现在的聊天应用之所以看起来有上下文是因为应用层在每次请求前把历史消息拼进 prompt。但这种方式有两个明显问题成本问题上下文越长token 消耗越高响应越慢。检索精度问题所有历史消息都塞进去信息噪声会干扰模型输出。Agent 场景比单轮问答更复杂。Agent 需要在多个步骤之间保留中间结果需要记住用户长期的偏好需要区分哪些信息是临时的、哪些是跨会话复用的。这类需求催生了 Agent Memory也就是把记忆从模型外部独立出来管理。记忆管理系统并不是一个数据库那么简单。它至少要能回答几个问题什么值得记怎么存才能方便后续快速找到记忆什么时候应该更新记忆什么时候应该被遗忘或合并1.2 一个合格的记忆系统要包含哪些能力从工程实现角度看Agent Memory 的核心能力可以拆成四条写入从对话或 Agent 执行结果中抽取值得保存的信息结构化存储。读取将记忆注入到 Agent 的 prompt 或工具上下文中。更新当新信息和旧记忆冲突时决定是覆盖、合并还是保留多个版本。遗忘记忆不是永久不变的。当长时间未访问或重要度降低时需要衰减或清理。只做存储和读取那和普通 KV 存储没有区别。大赛命题强调“管理系统”重点往往在于有没有写入策略、有没有检索排序、有没有衰减机制、有没有可视化和评估手段。1.3 为什么命题要绑定鲲鹏平台和 openEuler这个命题选择鲲鹏平台而不是普通 x86 服务器原因可以从三个层面看基础软件适配鲲鹏是 ARM 架构底层指令集不同很多软件需要 aarch64 版本。openEuler 作为开源操作系统对鲲鹏有原生支持两者结合能减少适配成本。产业需求国产服务器和国产操作系统在不少政企场景已经落地AI 应用跑在国产底座上已经成为实际交付场景。大赛考察点命题要求基于鲲鹏平台本质上是希望参赛队伍能证明自己在国产计算平台上具备独立搭建、部署、调优 AI 系统的能力。要注意openEuler 同时支持 x86_64 和 aarch64如果只在自己的 x86 笔记本上装虚拟机也能写代码但最终演示和运行最好放在鲲鹏环境上这样能早一点发现架构差异带来的问题。1.4 从命题到作品应该交付什么结合大赛通常的评审习惯一个完整作品至少包括可运行代码仓库包含清晰的 README 和部署文档。一个能演示的最小闭环Agent 对话后记忆被保存下次对话可以复用。核心机制说明写入、检索、更新、遗忘策略分别如何实现。测试数据和评估方式比如一组模拟对话能证明记忆系统确实提升了召回效果。能力需要回答的问题设计要点写入哪些内容要进入记忆库抽取规则、重要度评分、去重存储用什么数据结构保存结构化字段、向量索引、版本管理读取召回哪些记忆交给模型检索排序、相关性过滤、上下文截断更新新旧记忆冲突怎么处理覆盖、合并、置信度比较遗忘记忆什么时候失效时间衰减、LRU、容量上限2. 系统设计从需求到模块拆分2.1 整体架构分四层参赛作品在架构上不需要一开始就追求复杂但要边界清晰。系统可以分成四个层次接入层HTTP API给 Agent 提供写入、查询、更新、删除接口。记忆管理引擎负责记忆的抽取、评分、去重、更新、衰减。存储层Redis 做缓存和快速访问SQLite 做持久化可选向量库做语义检索。基础环境openEuler Python 3.9 Redis Docker。这样的分层好处是每一层都能单独测试。答辩时可以讲清楚“接口层如何对接 Agent”“策略层如何决定记忆去留”“存储层如何保证重启不丢失”。2.2 技术选型为什么不用一个数据库解决所有问题设计记忆系统时常见的误区是“用一个向量数据库搞定”。实际上记忆可以分为显式记忆和语义记忆显式记忆用户姓名、偏好、任务状态这类是结构化数据用 Redis 或关系型数据库更合适。语义记忆一段话的具体内容适合向量化后检索。用 Redis 存储结构化字段用向量存储做语义召回用 SQLite 或 MySQL 做长期历史归档。对参赛作品来说Redis SQLite 足够支撑演示如果时间充裕可以再接入向量库。组件作用推荐软件说明系统运行底座openEuler 22.03 LTS SP4对鲲鹏适配好运行时应用开发Python 3.9AI 生态丰富缓存/索引快速读写Redis 7.x支持过期策略持久化归档备份SQLite 3.x零配置适合原型API接口框架FastAPI 或 Flask便于快速开发向量检索语义召回faiss / hnswlib可选组件2.3 记忆数据模型每条记忆保存哪些字段记忆数据模型需要兼顾“检索效率”和“表达力”。下面这个 JSON 结构可以作为一条记忆的最小单位{ memory_id: uuid, content: 用户李明的偏好是希望回答尽量简洁, memory_type: user_profile, importance: 0.85, access_count: 3, created_at: 2026-05-01T10:00:00Z, updated_at: 2026-05-01T11:30:00Z, metadata: { source: session_001, agent_id: customer_service, expire_policy: sliding } }字段含义说明memory_id全局唯一用 UUID 生成。content记忆正文通常是抽取出的事实或偏好。memory_type记忆类型例如 user_profile、conversation_fact、task_result。importance重要度评分控制记忆在召回时的权重。access_count访问次数用于热度排序。created_at 和 updated_at创建和更新时间用于衰减策略。metadata扩展字段保存来源会话、Agent 编号等上下文信息。2.4 记忆生命周期流程一条记忆不是写入数据库后永远不变的它会经历几个阶段写入抽取出事实计算重要度写入 Redis 和 SQLite。活跃被检索命中后访问次数增加updated_at 刷新。衰减长时间没有被命中热度降低在结果中的排序下降。遗忘超过 TTL 或容量上限后Redis 中的缓存被清理SQLite 中可保留审计记录。在实现时建议把“缓存层遗忘”和“历史归档层清理”分开。Redis 的 TTL 可以快速模拟短时遗忘SQLite 留作历史审计二者不冲突。3. 环境准备在鲲鹏 openEuler 上把基础服务跑起来3.1 选择 openEuler 版本很多队伍在备赛时会纠结“CentOS 7.5 应该用 openEuler 哪个版本”。从实际使用看建议避开老旧的 CentOS 习惯直接使用 openEuler 当前的主流 LTS 版本。使用场景建议版本架构备注鲲鹏服务器openEuler 22.03 LTS SP4aarch64稳定适配仓库全本地虚拟机openEuler 22.03 LTS SP4x86_64开发调试生产部署openEuler 最新 LTSaarch64按官方生命周期维护下载镜像时鲲鹏服务器要选择 aarch64 版本本地虚拟机如果不想模拟 ARM可以先用 x86_64 版本做开发。但最终必须有一份在鲲鹏 aarch64 上完整跑通的部署文档。3.2 系统初始化网络、SSH、yum 源在正式安装依赖前必须确认 yum 源可用。openEuler 安装完成后默认可能使用官方源也可能因为网络原因很慢。此时建议换成镜像源下面的示例使用阿里云镜像# 备份默认源配置 mkdir -p /etc/yum.repos.d/backup cp /etc/yum.repos.d/openEuler.repo /etc/yum.repos.d/backup/ # 写入镜像源配置 cat /etc/yum.repos.d/openEuler.repo EOF [openEuler] nameopenEuler baseurlhttps://mirrors.aliyun.com/openeuler/openEuler-22.03-LTS-SP4/OS/$basearch/ enabled1 gpgcheck0 EOF yum clean all yum makecache$basearch 变量会自动识别为 aarch64 或 x86_64不同架构下都能使用。开启 SSH 服务便于后续远程开发和部署dnf install -y openssh-server systemctl enable --now sshd systemctl status sshd3.3 安装 Python、Redis、DockeropenEuler 自带 Python 3但版本不一定满足项目要求。为了不破坏系统 Python建议用 conda 或 pyenv 建独立环境。# 更新系统 dnf update -y # 安装基础编译工具 dnf install -y gcc gcc-c make cmake git wget tar # 安装 Redis dnf install -y redis systemctl enable --now redis redis-cli ping如果要用 Docker可以在 openEuler 上直接尝试通过 dnf 安装dnf install -y docker systemctl enable --now docker不同版本、不同架构下的 Docker 包名可能稍有差异落地前要先确认当前仓库是否提供 docker 包。如果仓库没有对应包可以使用 Docker 官方提供的静态二进制或容器镜像仓库但要注意选择 linux/arm64 版本。安装 conda 时一定要选择 aarch64 版本wget https://mirrors.tuna.tsinghua.edu.cn/anaconda/miniconda/Miniconda3-py39_4.12.0-Linux-aarch64.sh bash Miniconda3-py39_4.12.0-Linux-aarch64.sh如果是在本地 x86_64 虚拟机需要换成 x86_64 对应文件名。3.4 环境验证清单安装完成后建议用下面表格逐项确认检查项命令预期结果架构uname -maarch64系统版本cat /etc/openEuler-releaseopenEuler 22.03 LTSSSH 状态systemctl status sshdactiveRedis 状态redis-cli pingPONGPython 版本python3 --version3.9Docker 状态docker infoServer Version 存在这些检查项要写进项目 README方便评委按文档复现也方便队友在不同机器上快速对齐。4. 核心实现构建一个可运行的最小 Agent Memory 服务4.1 项目结构创建一个项目目录mkdir -p /opt/agent-memory/{memcore,api,data,scripts} cd /opt/agent-memory推荐的项目结构如下agent-memory/ ├── api.py ├── memcore/ │ ├── __init__.py │ ├── model.py │ ├── store.py │ └── manager.py ├── data/ │ └── memory.db ├── requirements.txt └── scripts/ └── demo_session.py这个结构把数据模型、存储层、策略层、API 层分开后续扩展向量检索时只需要增加一个 retriever 模块。requirements.txt 内容fastapi0.104.1 uvicorn0.24.0 redis5.0.1 pydantic2.5.04.2 记忆数据模型实现在 memcore/model.py 中定义 MemoryItem 数据类# memcore/model.py from dataclasses import dataclass, field from datetime import datetime, timezone from typing import Any, Dict def _now_iso() - str: return datetime.now(timezone.utc).isoformat() dataclass class MemoryItem: memory_id: str content: str memory_type: str conversation_fact importance: float 1.0 access_count: int 0 created_at: str field(default_factory_now_iso) updated_at: str field(default_factory_now_iso) metadata: Dict[str, Any] field(default_factorydict)使用 dataclass 可以省去大量样板代码字段顺序和 JSON 结构也容易对齐。created_at 使用 UTC 时间避免不同服务器时区不一致导致衰减计算混乱。4.3 存储层实现Redis SQLite 双层设计存储层是记忆系统的基础。Redis 负责快速读写和 TTL 遗忘SQLite 负责持久化。# memcore/store.py import json import sqlite3 import redis from .model import MemoryItem class MemoryStore: def __init__(self, redis_urlredis://127.0.0.1:6379/0, sqlite_pathdata/memory.db): self.redis_client redis.Redis.from_url(redis_url, decode_responsesTrue) self.sqlite_path sqlite_path self._init_sqlite() def _init_sqlite(self): conn sqlite3.connect(self.sqlite_path) conn.execute( CREATE TABLE IF NOT EXISTS memories ( memory_id TEXT PRIMARY KEY, content TEXT, memory_type TEXT, importance REAL, access_count INTEGER, created_at TEXT, updated_at TEXT, metadata TEXT ) ) conn.commit() conn.close() def _key(self, memory_id: str) - str: return fmem:{memory_id} def write(self, item: MemoryItem, ttl: int 7 * 24 * 3600): key self._key(item.memory_id) self.redis_client.hset( key, mapping{ content: item.content, memory_type: item.memory_type, importance: item.importance, access_count: item.access_count, created_at: item.created_at, updated_at: item.updated_at, metadata: json.dumps(item.metadata, ensure_asciiFalse), }, ) self.redis_client.expire(key, ttl) conn sqlite3.connect(self.sqlite_path) conn.execute( INSERT INTO memories (memory_id, content, memory_type, importance, access_count, created_at, updated_at, metadata) VALUES (?, ?, ?, ?, ?, ?, ?, ?) ON CONFLICT(memory_id) DO UPDATE SET content excluded.content, memory_type excluded.memory_type, importance excluded.importance, access_count excluded.access_count, updated_at excluded.updated_at, metadata excluded.metadata , ( item.memory_id, item.content, item.memory_type, item.importance, item.access_count, item.created_at, item.updated_at, json.dumps(item.metadata, ensure_asciiFalse), ), ) conn.commit() conn.close() def get(self, memory_id: str): key self._key(memory_id) data self.redis_client.hgetall(key) if data: return self._from_redis_dict(memory_id, data) return self._get_from_sqlite(memory_id) def delete(self, memory_id: str): self.redis_client.delete(self._key(memory_id)) conn sqlite3.connect(self.sqlite_path) conn.execute(DELETE FROM memories WHERE memory_id ?, (memory_id,)) conn.commit() conn.close() def list_all(self): conn sqlite3.connect(self.sqlite_path) rows conn.execute(SELECT * FROM memories).fetchall() conn.close() return [self._from_row(row) for row in rows] def _get_from_sqlite(self, memory_id: str): conn sqlite3.connect(self.sqlite_path) row conn.execute( SELECT * FROM memories WHERE memory_id ?, (memory_id,) ).fetchone() conn.close() if row: return self._from_row(row) return None def _from_redis_dict(self, memory_id, data): return MemoryItem( memory_idmemory_id, contentdata.get(content, ), memory_typedata.get(memory_type, conversation_fact), importancefloat(data.get(importance, 1.0)), access_countint(data.get(access_count, 0)), created_atdata.get(created_at, ), updated_atdata.get(updated_at, ), metadatajson.loads(data.get(metadata, {})), ) def _from_row(self, row): return MemoryItem( memory_idrow[0], contentrow[1], memory_typerow[2], importancerow[3], access_countrow[4], created_atrow[5], updated_atrow[6], metadatajson.loads(row[7]) if row[7] else {}, )这里的关键点是写入时同时操作 Redis 和 SQLite。Redis 提供高速访问SQLite 保证进程重启后记忆不丢失。如果 Redis 中没有命中就回源到 SQLite 读取这非常像缓存与数据库的双写模式。4.4 记忆管理策略评分、去重、检索、访问计数光有存储还不够还需要一个 manager 层承载策略逻辑。# memcore/manager.py import re import uuid from datetime import datetime, timezone from typing import Optional from .model import MemoryItem from .store import MemoryStore def _now_ts(): return datetime.now(timezone.utc).timestamp() class MemoryManager: def __init__(self, store: MemoryStore): self.store store def _estimate_importance(self, content: str) - float: score 1.0 if re.search(r偏好|喜欢|需要|希望|不同意|不要, content): score 0.2 if re.search(r姓名|用户|任务|订单|退款|错误|修复, content): score 0.1 return min(score, 1.0) def write_from_agent( self, content: str, memory_type: str conversation_fact, metadata: Optional[dict] None, ttl: int 7 * 24 * 3600, ) - MemoryItem: metadata metadata or {} importance self._estimate_importance(content) # 去重同类型同内容不重复写入 for old in self.store.list_all(): if old.content content and old.memory_type memory_type: return old item MemoryItem( memory_idstr(uuid.uuid4()), contentcontent, memory_typememory_type, importanceimportance, metadatametadata, ) self.store.write(item, ttlttl) return item def search(self, query: str, limit: int 5): words [w for w in re.split(r\s, query.strip()) if w] results [] for item in self.store.list_all(): score 0.0 for w in words: if w in item.content: score 1.0 if score 0: recency item.importance / (1 item.access_count) results.append((score recency, item)) results.sort(keylambda x: x[0], reverseTrue) return [item for _, item in results[:limit]] def touch(self, memory_id: str): item self.store.get(memory_id) if item: item.access_count 1 item.updated_at datetime.now(timezone.utc).isoformat() self.store.write(item) return item这个实现有几个值得在答辩时讲清楚的点重要度评分是规则式的不用模型适合最小闭环。后续可以替换为模型打分。去重策略通过“同类型 同内容”判断避免同一事实反复写入。排序综合了关键词匹配数量、重要度和访问次数体现“热点记忆优先召回”。4.5 对外 API 封装使用 FastAPI 把记忆服务暴露成 HTTP 接口方便 Agent 或者演示前端调用。# api.py from typing import Optional from fastapi import FastAPI from pydantic import BaseModel from memcore.manager import MemoryManager from memcore.store import MemoryStore app FastAPI() store MemoryStore() manager MemoryManager(store) class MemoryWriteRequest(BaseModel): content: str memory_type: str conversation_fact metadata: Optional[dict] None app.post(/memories) def create_memory(req: MemoryWriteRequest): item manager.write_from_agent( contentreq.content, memory_typereq.memory_type, metadatareq.metadata or {}, ) return {memory_id: item.memory_id, importance: item.importance} app.get(/memories/search) def search_memories(query: str, limit: int 5): items manager.search(query, limit) return [ { memory_id: item.memory_id, content: item.content, memory_type: item.memory_type, importance: item.importance, } for item in items ] app.get(/memories/{memory_id}) def get_memory(memory_id: str): item store.get(memory_id) if not item: return {error: not found} return item.__dict__ app.delete(/memories/{memory_id}) def delete_memory(memory_id: str): store.delete(memory_id) return {ok: True} app.get(/memories) def list_memories(): items store.list_all() return [item.__dict__ for item in items]Pydantic 的 BaseModel 负责请求参数校验内容为空时会被 FastAPI 直接拒绝。这里没有做鉴权是因为参赛 Demo 面向本地和服务器内网演示后续如果要开放公网访问需要加上 API Key 或认证中间件。4.6 Agent 如何接入记忆系统Agent 接入记忆系统时推荐按以下顺序处理用户发起新请求。调用/memories/search?query用户问题获取相关记忆。将记忆拼接进系统 prompt。调用大模型生成回复。从本轮对话中抽取值得保存的事实调用/memories写入记忆。示例 prompt 结构你是一个智能客服助手。 以下是该用户的已知偏好 - 用户希望回答简洁控制在300字以内。 - 用户上次问过订单退款流程。 请基于这些信息回答当前问题...这种接入方式对现有 Agent 代码的侵入很小只需要在调用大模型前后增加两个 HTTP 请求。5. 运行验证用最小案例跑通记忆闭环5.1 启动服务安装依赖并启动cd /opt/agent-memory pip install -r requirements.txt uvicorn api:app --host 0.0.0.0 --port 8000启动后先用 curl 验证写入接口curl -X POST http://127.0.0.1:8000/memories \ -H Content-Type: application/json \ -d {content:用户偏好简洁回答,memory_type:user_profile}预期返回{memory_id: 32fd6f1e-2e8b-4e19-aec4-9a2d1b0f2b0b, importance: 1.2}importance 大于 1.0说明“偏好”关键词触发了加分规则。5.2 验证记忆检索搜索接口用于召回与当前问题相关的记忆curl http://127.0.0.1:8000/memories/search?query用户偏好limit3预期能召回刚才写入的记录。如果搜索“天气怎么样”则不会召回任何记忆因为关键词没有命中。5.3 验证记忆持久化重启 Redis 和 uvicorn再查询列表systemctl restart redis # 重新启动 uvicorn uvicorn api:app --host 0.0.0.0 --port 8000 curl http://127.0.0.1:8000/memories只要 Redis 重启前 TTL 没有过期list 接口会先走 SQLite 还原数据并重新写回 Redis。这一步骤是证明“记忆系统不是内存聊天记录”的关键演示。5.4 验证遗忘策略为了体现“遗忘”可以把写入时的 TTL 调小。当前代码中 write_from_agent 默认 TTL 是 7 天可以临时改为 10 秒或者通过 metadata 传入更短的 ttl 参数。写入后等待 15 秒再调用curl http://127.0.0.1:8000/memories/{memory_id}如果 Redis 中的缓存已过期而 SQLite 历史仍在说明系统具备“缓存层遗忘 历史归档”的能力。正式答辩时可以把这种两级设计讲清楚而不是简单说“删除记录”。5.5 模拟多轮对话脚本在 scripts/demo_session.py 中放一个演示脚本可以一键展示“第一轮写入、第二轮召回”# scripts/demo_session.py import requests BASE http://127.0.0.1:8000 # 第一轮用户告诉 Agent 自己的姓名和偏好 requests.post( f{BASE}/memories, json{ content: 用户叫张三希望回答尽量简洁, memory_type: user_profile, metadata: {source: session_001}, }, ) # 第二轮新的会话Agent 先搜索用户信息 resp requests.get( f{BASE}/memories/search, params{query: 用户是谁, limit: 3}, ).json() for item in resp: print(item[content])运行后输出应包含“用户叫张三希望回答尽量简洁”。这个脚本可以作为演示视频的基础素材。6. 常见问题排查鲲鹏 openEuler 上最容易踩的坑6.1 yum 源和仓库问题现象执行 dnf install 时出现 404、超时或者找不到软件包。原因仓库地址与系统版本、架构不匹配。检查方式cat /etc/yum.repos.d/openEuler.repo dnf repolist解决方案确认 openEuler 版本后替换为对应版本的镜像源。重点检查 baseurl 中的版本号路径例如 openEuler-22.03-LTS-SP4。6.2 aarch64 架构下 Python 包安装失败现象pip install faiss-cpu 或类似包时提示找不到匹配分发或编译过程中报错。原因部分 Python 包没有发布 aarch64 的 wheel源码编译又缺少依赖。检查方式pip debug --verbose | grep -A 5 Compatible tags解决方案优先选择已有 aarch64 wheel 的包如果确实需要 faiss可以尝试安装faiss-cpu的特定版本或改用hnswlib。在参赛 Demo 中可以先用简单的关键词检索实现最小闭环向量检索作为加分项再接入。6.3 Redis 连接失败现象应用启动后写入或读取时报 Redis 连接异常。原因Redis 未启动、绑定地址受限或防火墙拦截。检查方式redis-cli -h 127.0.0.1 ping ss -lntp | grep 6379解决方案启动 Redis 并设置为开机自启如果 Redis 只允许本机访问应用和 Redis 在同一台机器时连接串保持127.0.0.1即可。跨机器访问时需要修改 bind 配置并开放防火墙端口。6.4 SSH 无法远程登录现象从本机 ssh 到鲲鹏服务器超时或被拒绝。原因openssh-server 未安装、sshd 未启动或安全组没有放行 22 端口。检查方式systemctl status sshd解决方案安装并启动 sshd然后检查云服务器的安全组规则。openEuler 默认可能没有完全复制 CentOS 的 SSH 配置需要手动启用。6.5 Docker 镜像架构不匹配现象在鲲鹏上拉取 Redis、Python 等镜像后运行报 exec format error。原因镜像不是 linux/arm64 架构。检查方式docker inspect 镜像名 | grep Architecture解决方案拉取镜像时优先选择官方镜像官方镜像一般支持多架构。如果使用自定义镜像构建时要在 Dockerfile 中明确FROM --platformlinux/arm64。6.6 桌面环境与音频问题在 openEuler 上安装桌面版后可能会遇到没有声音、显示卡顿等问题。如果是参赛开发建议主服务器不安装桌面只保留最小化系统 SSH这样能减少不必要的依赖冲突。本机和远程开发环境使用 VSCode Remote SSH 即可不需要桌面。问题现象常见原因检查方式处理建议dnf 安装超时yum 源不可用dnf repolist换镜像源pip 安装失败aarch64 wheel 缺失pip debug改替代包Redis 连不上未启动/未放行redis-cli ping启动并检查端口SSH 登不上sshd 未启动systemctl status sshd启用 sshdDocker 运行报错架构不匹配docker inspect拉 arm64 镜像7. 参赛建议从 Demo 到完整作品7.1 建议增加记忆可视化界面答辩时只看命令行接口不够直观。建议用 Flask 或 Gradio 做一个简单的记忆管理面板展示当前记忆列表。每条记忆的重要度、访问次数、创建时间。搜索命中情况。遗忘清理记录。可视化不是核心功能但能让评委在几分钟内理解系统的记忆生命周期。7.2 评估指标要提前设计项目 README 里建议写清楚评估维度例如指标说明写入成功率合法记忆是否能成功持久化召回率构造 N 个查询能召回多少相关记忆精确率召回的记录中多少真正相关重复写入率同一条事实是否被重复保存遗忘有效性过期记忆是否被清理响应时延写入和查询的平均耗时使用模拟对话数据时要区分训练集和测试集避免用同一条对话既构造写入又构造问题。7.3 答辩前检查清单类别检查项状态环境鲲鹏 aarch64 能一键复现部署是/否功能写入、查询、更新、删除全部可用是/否策略重要度、去重、衰减机制有代码实现是/否接口Agent 可以通过 HTTP API 接入是/否文档README 包含环境要求和部署命令是/否演示scripts/demo_session.py 可以一键演示是/否排障已知坑记录在项目文档中是/否7.4 可继续扩展的方向如果基础版本已经稳定可以考虑以下扩展向量检索使用 embedding 模型 向量库实现语义召回。记忆合并相似记忆自动合并减少冗余。冲突消解新记忆与旧记忆矛盾时根据时间戳和重要度决策。多 Agent 共享记忆通过命名空间隔离不同 Agent 的记忆。分布式存储将 SQLite 替换为数据库支撑更大规模并发。这些方向每一个都可以作为答辩的“创新点”但要确保在正式演示前已经稳定运行而不是只画架构图。Agent Memory 是一个典型的交叉方向题目它要求参赛队伍同时理解 AI 应用、存储系统、基础软件适配三块内容。openEuler 和鲲鹏平台并不是单纯的运行环境它们会在依赖安装、包管理、架构兼容等细节上影响整个开发过程。备赛时尽早把环境固定在鲲鹏 aarch64 上可以省掉大量临场调试时间。对于新手团队先跑通一个不依赖向量库的 Redis SQLite 版本把记忆闭环和遗忘策略讲清楚再逐步加入向量检索和可视化是比较稳妥的递进路线。最终评审关注的不是一个“聊天记录查询系统”而是记忆系统是否有明确的写入决策、检索排序、冲突更新和遗忘机制以及这些机制能否在国产平台上稳定运行。