具身智能系列已经写到了第 4 篇前几篇我们聊过具身智能的基本概念也聊过机械臂/机器人怎么感知环境、怎么规划动作。但有一个问题很多人会忽略机器人在真实世界里执行任务不是“看一眼做一步”这么简单。真实的家庭环境里让机器人去“把客厅茶几上的水杯拿到厨房”看起来是一句话但中间会涉及“杯子在哪”“茶几在哪”“厨房怎么走”“中途有人经过怎么办”“杯子太烫要不要等一会儿”这一连串的问题。这里有两个关键能力浮现出来一个是具身推理机器人在动作过程中不断对环境进行判断和推断另一个是记忆或者说 Agent Memory机器人能不能把刚才看到的信息、上一次的教训、用户交代过的偏好记住并且在下一次决策时用上。这篇文章就围绕这两点展开。我会从概念出发再到长程任务规划为什么依赖记忆最后用一个实际可落地的例子演示如何给具身智能 Agent 加上简单的记忆模块。适合初接触具身智能的开发者也适合正在做大模型 Agent、机器人任务规划的工程师参考。1. 具身推理是什么1.1 从“会动手”到“会动脑”先看两个场景。场景 A一台传统工业机械臂在固定工位上抓取零件。零件位置固定路径固定程序写好后可以每天重复执行同一套动作。这种场景不需要太多“推理”本质上是轨迹复现。场景 B一台家庭服务机器人接收到指令“帮我把沙发上那件蓝色外套拿过来”。这里存在大量不确定信息沙发在哪里可能有多个沙发。蓝色外套是不是唯一一件蓝色衣服外套是被叠好的还是摊开的桌上那件蓝色帽衫算不算“外套”这时候机器人必须在当前环境里观察、对比、判断然后才决定执行什么动作。这种“根据环境状态和任务目标不断进行判断和决策”的能力就是具身推理。通俗地说具身推理是以身体和环境为依托的推理。它不是像 ChatGPT 那样只坐在服务器里想而是机器人或智能体在物理空间中行动时把感知信息、动作反馈、任务目标放到一起进行推断。具身推理的核心特点是推理结果会立即影响下一步动作动作执行后又会更新推理条件。专业一点的表述是具身推理Embodied Reasoning是在具身智能体与环境的交互过程中综合多模态感知信息、历史状态和任务目标对外部环境状态、自身动作结果以及未观测信息进行推断的认知过程。1.2 具身推理的常见任务类型目前具身推理在研究和工程中主要集中在以下几类任务上任务类型典型场景需要推理的内容物体定位与属性判断“把红色杯子拿过来”哪个物体是“红色杯子”位置在哪是否被遮挡空间关系推理“把书放到桌子左边的抽屉里”桌子左边是哪边抽屉是否打开空间是否足够行为后果推断“倒水时水会不会溢出”水杯容量、当前水量、倾斜角度和流速的关系任务拆解与排序“打扫房间”先扫地还是先拖地哪些区域已有障碍物人机协作意图理解用户手指向某处说“放那里”用户的指示指代哪个具体坐标可以说推理能力越强机器人就越能从“跟屁虫式执行”进化成“助手式执行”。1.3 具身推理与纯语言推理的区别很多人第一次接触具身推理时会把它理解成“给大模型一个复杂的任务描述让它生成步骤”。这个理解不完整。传统自然语言推理面对的是一个封闭的、只包含文本符号的世界。大模型根据训练语料中的统计规律推断出“接下来最合理的回复是什么”。但具身推理面向的是开放物理世界它必须处理以下几个纯语言推理很少遇到的新问题物理约束。语言模型可以说“把苹果放到空中”但真实机器人必须考虑重力、摩擦力、夹爪开合范围。感知不确定性。视觉识别不是 100% 准确摄像头角度不同、光照不同同一个物体会呈现不同特征。具身推理需要在概率意义上做判断。动作反馈闭环。机器人把杯子拿起来一半时杯子滑落了推理系统必须从传感器数据里感知到“抓取失败”然后重新规划策略。所以你会看到具身推理常常是“感知-推理-动作”循环的中间层。它接收视觉、语音、触觉等多种信号输出动作决策依据而不是直接指望大模型凭空生成可执行代码。2. 长程任务规划与记忆的关系2.1 什么是长程任务规划长程任务规划Long-Horizon Task Planning指的是智能体需要经过多个步骤、跨越较长时间才能完成的任务规划。判断一个任务是否属于长程任务可以从两个维度来看步骤数和时间跨度。简单任务比如“抓取面前的水瓶”可能只需要 1 个动作耗时 2 秒。长程任务比如“为客人准备一顿三菜一汤的晚餐”可能需要几十个甚至上百个动作耗时 30 分钟以上。经典的机器人规划方法一般依赖 PDDLPlanning Domain Definition Language这类描述语言把任务抽象成“初始状态-目标状态-动作集合”然后搜索一条可行的动作序列。但对真实家庭场景而言PDDL 建模成本极高而且环境状态是动态变化的动作执行结果往往带有随机性。最近几年大语言模型LLM的规划能力被引入到长程任务规划中。LLM 可以通过自然语言拆解任务把“整理书桌”拆成“识别桌面上有哪些物品”“确定每个物品的归类位置”“依次移动物品”“检查是否整理完成”等多个子任务。这大大降低了任务拆解门槛但同时也带出了一个新的问题规划模型只负责拆解步骤它记不住这个过程中已经发生过什么。2.2 长程任务的难点在哪里长程任务和短程任务最大的区别在于它不能假设环境在每一步之间保持不变。举例来说一个机器人执行“把书桌整理干净”的任务流程可能是识别桌面上有哪些物品。分辨哪些需要保留、哪些需要收纳。把杂物放进收纳盒。把书本按大小排列放好。检查台面上是否还有遗漏。在第 2 步时机器人判断“桌上的笔筒需要保留原位置”。但它在第 4 步搬书的时候不小心碰倒了笔筒笔撒了一地。这时候如果机器人没有记忆能力它会按照原先的规划继续排列书本然后直接宣布任务完成。但桌面实际上已经多了一片狼藉。出现这种问题的根本原因是传统任务规划把世界看成一组静态状态但真实世界的状态会由于智能体自身动作而改变。机器人需要有机制去追踪“当前任务执行到哪一步了”“过程中发生了什么意外”“哪些子目标已经完成了”。2.3 缺少记忆的表现如果你的机器人 / Agent 在做长程任务时表现很差很可能不是模型推理能力不够而是记忆能力缺失。常见表现有反复询问同一个信息。用户十分钟前说“咖啡杯在餐桌上”机器人规划任务时记不住于是再次问用户“咖啡杯在哪里”。重复执行已完成步骤。任务做到一半状态被刷新Agent 把之前已经完成的工作又做了一遍。比如明明已经扫完地又开始执行扫地动作。无法从错误中学习。上次抓取玻璃杯时因为用力过大导致杯子滑动这次遇到同样的杯子还是用同样的力度。没有记忆就没有经验复用。多模态信息丢失。视觉模块识别出“这是用户的书”但规划模块只知道“桌子上有物体”没有把视觉信息和任务上下文绑定。这就是典型的信息没有写入记忆。从工程角度看具身智能系统的记忆能力决定了它能不能应对多步、动态、开放环境下的真实任务。3. Agent Memory具身智能体的记忆架构3.1 从“无状态函数”到“有状态智能体”在大模型应用开发里Agent 这个词已经非常流行。如果你用过 OpenAI 的 Function Calling或者用 LangChain 写过 Agent应该知道一个基础概念给大模型挂上工具让它能查天气、能调 API、能读写文件。但很多人开发 Agent 时面临一个尴尬大模型本身是没有记忆的。你每调用一次它看到的内容只包含当前请求和当前对话上下文。一旦会话变长或者任务执行到中途前面已经确定的信息很容易被“遗忘”。这个问题在具身智能场景中会被放大。因为具身智能 Agent 面对的是一个真实的三维空间信息来源包括摄像头画面、激光雷达点云、机械臂关节角度、麦克风语音指令等等。每一帧数据量都很大不可能全塞进大模型上下文里。而且物理动作有持续性几分钟前抓取的物体现现在可能已经在另一个位置Agent 必须动态更新自己认知中的“世界状态”。所以我更愿意把 Agent Memory 理解成一套体系而不是一个简单缓存。它回答的问题包括这个任务的长期目标是什么当前执行到哪一步了这个物品之前放在哪里现在被移动到哪里了用户偏好的执行方式是什么上次同类任务失败的原因是什么3.2 记忆的几种类型参考认知科学中人类记忆的分类方法具身智能 Agent 的记忆可以划分成四个层面工作记忆Working Memory。与当前任务直接相关的临时信息。比如“当前目标是把杯子从茶几拿到厨房”“杯子现在位于茶几中央”“机械臂抓取位置是坐标 (x, y, z)”。工作记忆容量有限任务结束后一般会被清理或归档。情景记忆Episodic Memory。记录智能体过去经历的特定事件。比如“昨天 15:30我在厨房完成了洗碗任务”“上次抓取玻璃杯时失败原因是夹爪用力过猛”。情景记忆的特点是与时间、地点、事件绑定能用来做经验回放。语义记忆Semantic Memory。关于世界的一般性知识不依赖具体某个事件。比如“杯子是易碎品”“冰箱里的东西需要低温保存”“用户通常不喜欢物品被放到高处”。这部分记忆可以由知识图谱或参数字典来承载。程序性记忆Procedural Memory。已经固化为技能的动作序列。比如“抓取玻璃杯的标准力度曲线”“打开柜门的安全轨迹”。程序性记忆通常不需要每一次都通过推理得出而是直接调用。这四种记忆不是孤立的。工作记忆里的临时信息经过积累和提炼可以转存为情景记忆多次相似的情景记忆可以进一步抽象成语义记忆反复执行成功的动作策略则会沉淀为程序性记忆。3.3 典型技术方案实现这些记忆类型业界还没有统一的标准答案但目前的工程方案大致有几类基于缓存中间件的短期记忆。用 Redis 等内存数据库保存当前会话信息、任务执行状态、临时变量。优点是速度快适合承载工作记忆。基于向量数据库的长期记忆。将情景描述、环境状态、任务结果通过 Embedding 模型转换成向量存入 Milvus、FAISS、Chroma 等向量数据库。当新任务发生时通过语义相似度检索最相关的历史经验作为大模型输入的补充上下文。适合承载情景记忆和部分语义记忆。基于知识图谱的结构化记忆。使用 Neo4j 等图数据库保存实体及其关系。比如“用户 A -喜欢- 白色 -物品- 马克杯”“杯子 -位于- 茶几”。优点是可解释性和逻辑推理能力强适合承载语义记忆。基于参数化模型的技能库。用强化学习或模仿学习训练出的策略网络本身就相当于程序性记忆。机器人遇到熟悉的场景时可以直接调用策略而不需要从零开始规划。从工程落地节奏来看比较现实的路径是先用 Redis 解决工作记忆再用向量数据库解决长期记忆知识图谱按需引入技能库单独训练。4. 实战给具身智能 Agent 加一个 Redis 记忆模块前面讲了不少概念下面进入实战。我们用一个简化的项目来演示让一个模拟具身智能 Agent 具备基本的记忆能力在长程任务中记住环境状态和任务进度。这里用 Redis 来做记忆存储。选择 Redis 的原因有三个数据结构丰富支持字符串、哈希、列表、集合适合表达不同类型的记忆。支持设置过期时间方便模拟工作记忆的遗忘机制。部署简单大多数开发者本地都有 Docker几分钟就能启动。4.1 环境准备本示例假设你的电脑上已经安装了以下环境Python 3.9 或更高版本Redis 6.0 或更高版本或者能用 Docker 启动 Redis已安装redis-py库如果还没有 Redis推荐直接用 Docker 启动docker run -d --name redis-memory -p 6379:6379 redis:7安装 Python 依赖pip install redis4.2 记忆模块设计在设计记忆模块前先明确这个模块要对外提供哪些能力save_working_memory(task_id, key, value)保存工作记忆。get_working_memory(task_id, key)读取工作记忆。save_episodic_memory(event_id, episode_data)保存一条情景记忆。search_episodic_memory(keyword)根据关键词检索相关情景记忆。update_task_progress(task_id, step, status)更新任务进度。get_task_progress(task_id)获取任务当前执行进度。为了让代码结构清晰我们把整个记忆模块封装成一个类。下面是完整代码保存为agent_memory.py# 文件路径agent_memory.py import json import time import uuid import redis class AgentMemory: 具身智能 Agent 的记忆模块基于 Redis 实现。 主要包括 - 工作记忆与当前任务绑定的临时状态 - 情景记忆历史事件记录用于经验检索 - 任务进度长程任务执行到哪一步 def __init__(self, redis_hostlocalhost, redis_port6379, redis_db0): self.client redis.Redis( hostredis_host, portredis_port, dbredis_db, decode_responsesTrue, ) # 工作记忆的 key 前缀 self.working_prefix agent:working: # 情景记忆的 key 前缀 self.episodic_prefix agent:episodic: # 任务进度的 key 前缀 self.task_prefix agent:task: # ---------------- 工作记忆 ---------------- def save_working_memory(self, task_id, key, value, expire600): 保存工作记忆。默认 10 分钟过期。 expire 参数用来模拟工作记忆的遗忘特性。 redis_key f{self.working_prefix}{task_id}:{key} if isinstance(value, (dict, list)): value json.dumps(value, ensure_asciiFalse) self.client.set(redis_key, value, exexpire) def get_working_memory(self, task_id, key): 读取工作记忆。 redis_key f{self.working_prefix}{task_id}:{key} value self.client.get(redis_key) if value is None: return None # 尝试解析 JSON如果失败说明存的是普通字符串 try: return json.loads(value) except json.JSONDecodeError: return value # ---------------- 情景记忆 ---------------- def save_episodic_memory(self, event_type, content, resultsuccess): 保存一条情景记忆。 event_type: 事件类型例如 grasp, navigation, user_preference content: 事件详细内容dict result: 执行结果 event_id str(uuid.uuid4()) episode { event_id: event_id, timestamp: time.time(), event_type: event_type, content: content, result: result, } redis_key f{self.episodic_prefix}{event_id} self.client.set(redis_key, json.dumps(episode, ensure_asciiFalse)) # 用集合维护事件类型索引方便按类型检索 self.client.sadd(f{self.episodic_prefix}type:{event_type}, event_id) return event_id def search_episodic_memory(self, event_typeNone, limit10): 检索情景记忆。 可以按事件类型筛选也可以直接获取最近几条。 if event_type: event_ids self.client.smembers(f{self.episodic_prefix}type:{event_type}) else: # 简化处理扫描所有情景记忆 key 获取最近记录 keys self.client.keys(f{self.episodic_prefix}*) # 过滤掉类型索引 key event_ids [k.replace(self.episodic_prefix, ) for k in keys if not k.endswith(type:) and type: not in k] memories [] for eid in list(event_ids)[:limit]: raw self.client.get(f{self.episodic_prefix}{eid}) if raw: memories.append(json.loads(raw)) # 按时间倒序排列 memories.sort(keylambda x: x.get(timestamp, 0), reverseTrue) return memories # ---------------- 任务进度 ---------------- def update_task_progress(self, task_id, current_step, total_steps, statusexecuting): 更新长程任务的执行进度。 redis_key f{self.task_prefix}{task_id} progress { task_id: task_id, current_step: current_step, total_steps: total_steps, status: status, updated_at: time.time(), } self.client.set(redis_key, json.dumps(progress, ensure_asciiFalse)) def get_task_progress(self, task_id): 获取长程任务的执行进度。 redis_key f{self.task_prefix}{task_id} raw self.client.get(redis_key) if raw is None: return None return json.loads(raw)这段代码里有几个设计细节工作记忆默认 10 分钟过期。这是刻意设置的工作记忆的特点是“任务相关、临时性、容量有限”过期机制可以避免 Redis 被无效状态塞满。情景记忆用 set 做类型索引。后续按事件类型检索时不需要扫描全部 key性能更好。所有存储的 value 都统一 JSON 化。具身智能场景里的状态通常不是简单字符串而是坐标、物体列表、判断结果等结构化数据JSON 是最通用的表达方式。4.3 记忆模块的模拟联调下面写一个测试脚本模拟一个“整理书桌”的长程任务。Agent 在任务过程中会反复读写记忆我们观察记忆模块如何帮助 Agent 保持任务状态。# 文件路径demo_long_task.py from agent_memory import AgentMemory import time memory AgentMemory() # 模拟一个新的长程任务 task_id task_20250108_desk_cleaning # 1. 任务开始记录任务目标和初始状态 memory.save_working_memory(task_id, goal, 整理书桌) memory.save_working_memory(task_id, step_index, 1) memory.save_working_memory(task_id, total_steps, 4) # 2. 视觉模块识别桌面物品把结果写入工作记忆 objects_on_desk [ {name: 笔记本, position: [0.2, 0.5, 0.1], target: 桌面左侧}, {name: 咖啡杯, position: [0.5, 0.3, 0.1], target: 厨房水池}, {name: 笔, position: [0.7, 0.8, 0.05], target: 笔筒}, ] memory.save_working_memory(task_id, objects_on_desk, objects_on_desk) # 3. Agent 根据规划开始执行第一步先处理咖啡杯 print(第一步将咖啡杯移动到厨房水池) memory.update_task_progress(task_id, current_step1, total_steps4) # 4. 模拟执行过程中咖啡杯位置发生变化被移动过 memory.save_working_memory(task_id, coffee_cup_status, moved_to_kitchen) # 5. 处理第二步把书放到桌面左侧 print(第二步把笔记本放到桌面左侧) memory.save_working_memory(task_id, notebook_status, placed_on_left) memory.update_task_progress(task_id, current_step2, total_steps4) # 6. 模拟系统中途重启或上下文丢失 print(\n[系统重启上下文丢失]) print(如果没有记忆模块Agent 会忘记任务进度和历史信息。) print(有了记忆模块Agent 通过 Redis 恢复任务状态\n) # 7. 恢复任务状态 goal memory.get_working_memory(task_id, goal) objects memory.get_working_memory(task_id, objects_on_desk) progress memory.get_task_progress(task_id) print(f恢复目标: {goal}) print(f恢复桌面物品信息: {objects}) print(f恢复任务进度: 第 {progress[current_step]} / {progress[total_steps]} 步) # 8. 执行第三步把笔放入笔筒 print(第三步把笔放入笔筒) memory.update_task_progress(task_id, current_step3, total_steps4) # 9. 保存一条情景记忆记录本次任务中的经验 memory.save_episodic_memory( event_typeobject_handling, content{ task_id: task_id, object: 咖啡杯, note: 用户偏好咖啡杯放厨房水池右侧, }, resultsuccess, ) # 10. 步骤 4确认任务完成 print(第四步检查桌面是否整齐) memory.update_task_progress(task_id, current_step4, total_steps4, statuscompleted) print(任务完成。) # 11. 查看保存的情景记忆 print(\n最近的情景记忆) memories memory.search_episodic_memory(event_typeobject_handling) for m in memories: print(m)运行这个脚本你会看到类似下面的输出第一步将咖啡杯移动到厨房水池 第二步把笔记本放到桌面左侧 [系统重启上下文丢失] 如果没有记忆模块Agent 会忘记任务进度和历史信息。 有了记忆模块Agent 通过 Redis 恢复任务状态 恢复目标: 整理书桌 恢复桌面物品信息: [{name: 笔记本, position: [0.2, 0.5, 0.1], target: 桌面左侧}, {name: 咖啡杯, position: [0.5, 0.3, 0.1], target: 厨房水池}, {name: 笔, position: [0.7, 0.8, 0.05], target: 笔筒}] 恢复任务进度: 第 2 / 4 步 第三步把笔放入笔筒 第四步检查桌面是否整齐 任务完成。 最近的情景记忆 [{event_id: xxx, timestamp: 1700000000.0, event_type: object_handling, content: {task_id: task_20250108_desk_cleaning, object: 咖啡杯, note: 用户偏好咖啡杯放厨房水池右侧}, result: success}]这个示例看起来很简单但它已经体现了一个关键的工程思想长程任务不能只靠大模型的上下文窗口应该把重要状态外置到专门的记忆存储中。这样即使 Agent 的对话上下文被截断、服务重启、或者从单机切换到分布式环境核心状态仍能恢复。实际系统中工作记忆不一定只存字符串可能还需要保存视觉特征的索引、地图坐标、半成品物体的中间状态等等。这些都可以在save_working_memory里扩展成不同的序列化方式。4.4 与大模型规划结合上面的代码还没有接大模型下面补充一段演示如何把记忆模块嵌入到 LLM 规划循环里。这个循环的典型结构是接收用户自然语言指令。从记忆模块检索相关信息任务目标、历史经验、环境状态。组合成 prompt 发给大模型。大模型返回下一步动作。执行动作更新记忆。循环直到任务完成。核心代码如下# 文件路径llm_planner_with_memory.py核心片段 from openai import OpenAI from agent_memory import AgentMemory memory AgentMemory() client OpenAI() # 按你自己的 API 配置调整 task_id task_xxx def build_prompt_with_memory(user_instruction: str) - str: 从记忆模块读取相关状态构造带上下文的 prompt。 context_parts [] # 1. 获得任务进度 progress memory.get_task_progress(task_id) if progress: context_parts.append( f当前任务进度第 {progress[current_step]} / {progress[total_steps]} 步 f状态{progress[status]} ) # 2. 获得工作记忆中的环境状态 objects memory.get_working_memory(task_id, objects_on_desk) if objects: context_parts.append(f当前桌面物品信息{objects}) # 3. 检索相关历史经验 histories memory.search_episodic_memory(event_typeobject_handling, limit5) if histories: context_parts.append(f历史经验{histories}) context_str \n.join(context_parts) if context_parts else 暂无额外记忆 prompt f 你是一个具身智能机器人的任务规划器。你将根据当前任务目标和环境记忆决策下一步动作。 【记忆上下文】 {context_str} 【用户最新指令】 {user_instruction} 请输出下一步应该执行的具体动作以及动作完成后需要更新的记忆字段。 输出格式要求为 JSON{{action: ..., memory_update: {{...}}}} .strip() return prompt def planning_step(user_instruction: str): prompt build_prompt_with_memory(user_instruction) response client.chat.completions.create( modelgpt-4o, # 按你的实际可用模型调整 messages[{role: user, content: prompt}], response_format{type: json_object}, ) result response.choices[0].message.content print(模型输出, result) return result这里传递了一个重要思路记忆模块的价值不只是存数据而是要把数据变成大模型的推理上下文。在具身智能应用中Agent 的 prompt 不再是“用户问什么就答什么”而是“用户在真实环境中要求机器人做什么 机器人已经知道了什么 机器人过去的经验是什么”。结合记忆模块后大模型不需要在每次决策时都从零理解环境也不需要依赖隐式的对话历史来记住之前发生了什么。这样既降低了 token 消耗也提高了任务执行的稳定性。5. 记忆在长程任务规划中的完整工作流为了方便理解我把上面示例的完整工作流整理一下。假设一个机器人执行“整理书桌”的长程任务有记忆模块和没有记忆模块的差异非常明显。没有记忆模块的流程用户说“整理书桌”。视觉模块识别桌面物品发送给 LLM。LLM 生成计划把杯子拿走、放好笔记本、收纳笔。机器人执行“把杯子拿走”执行成功。机器人执行“放好笔记本”但此时 LLM 的上下文已经被上一轮长输出覆盖或截断它丢失了杯子的处理结果。视觉系统再次环视桌面发现杯子已经不在于是 LLM 重新规划可能重复执行或产生矛盾动作。有记忆模块的流程用户说“整理书桌”。记忆模块新建任务条目保存初始目标“整理书桌”。视觉模块识别桌面物品后写入工作记忆objects_on_desk [笔记本、咖啡杯、笔]。Agent 按计划执行“把杯子拿走”完成后把coffee_cup_status更新为moved_to_kitchen。任务进度更新为第 1 步完成。执行“放好笔记本”前重新读取记忆确认杯子已完成桌面物品信息已变化。任务继续推进直到所有步骤完成。任务结束后把“咖啡杯应放厨房水池右侧”写入情景记忆供未来任务检索。从这个对比可以看出记忆模块在长程任务规划中承担的角色类似于人类大脑的“工作日志 经验笔记”。它保证了智能体在长时间、多步骤的任务中不会迷失。6. 常见问题与排查思路在给 Agent 加记忆模块的过程中开发者常遇到一些问题。我整理了一份排查清单问题现象常见原因解决思路Redis 连接失败Redis 服务未启动或端口配置错误先ping测试redis-cli ping返回 PONG 表示正常检查 host 和 port读取到的记忆是乱码未设置decode_responsesTrue构造 Redis 客户端时添加decode_responsesTrue数据存入 Redis 但读出来是Nonekey 名拼写不一致或设置了过期时间且已过期统一封装 key 拼接逻辑检查 TTL工作记忆过期太快expire参数设置过短长程任务中建议根据任务复杂度设置 30 分钟到几小时情景记忆检索结果不准确仅用 set 做了粗粒度索引没有语义检索生产环境可引入向量检索按语义相似度召回Agent 重启后任务丢失没有在任务开始时持久化目标与进度任务启动时调用update_task_progress写入初始状态不同任务之间记忆互相干扰工作记忆 key 没有加 task_id所有工作记忆都要以 task_id 作为 key 的一部分记忆内容格式不一致有时存字符串有时存 JSON在封装层统一处理序列化统一用 JSON一个容易被忽略的点是工作记忆和情景记忆的生存周期必须明确区分。如果所有记忆都不设置过期时间Redis 中的数据会越来越多检索性能也会下降如果过期时间太短长程任务还没执行完关键状态就丢了。建议场景化地区分工作记忆任务级生命周期任务结束或明显超时后清理。情景记忆长期保留但可以通过定期归档或摘要压缩来控制规模。语义记忆静态知识基本不过期由知识管理流程维护。7. 最佳实践与工程建议到这里一个带记忆模块的具身智能 Agent 骨架已经比较清晰了。最后补充几条在真实项目中值得注意的工程建议。7.1 记忆内容要结构化不要把所有记忆都存成一段乱七八糟的文本。比如“桌面有三个物品一个笔记本在左边一个咖啡杯在中间一支笔在右边”这种自然语言描述看起来能读懂但机器人在后续计算坐标、做空间规划时很难直接使用。更好的做法是存结构化数据{ objects: [ {name: 笔记本, position: [0.2, 0.5, 0.1], category: stationery}, {name: 咖啡杯, position: [0.5, 0.3, 0.1], category: tableware} ] }这样上层规划器可以直接读取坐标视觉模块也可以同步更新。字段设计要兼顾可读性和可计算性。7.2 记忆与推理解耦很多人写 Agent 时喜欢把记忆逻辑直接写进大模型的 prompt 里比如在 prompt 里说“请记住用户刚才说……”。这种做法在简单场景下可行但一旦任务变长、并发变多token 消耗会很大而且大模型也不是可靠的存储介质。工程上更推荐记忆外置External Memory。记忆由专门的模块负责读写和检索大模型只负责基于检索结果做推理决策。这样记忆逻辑可以被复用、被测试也能在模型升级时不改动底层存储。7.3 考虑记忆的置信度记忆不是永远可信的。视觉识别可能有误差物体可能被移动用户的偏好也可能随场景变化。所以在设计记忆结构时可以考虑给每条记忆增加置信度或来源字段。例如{ content: {name: 咖啡杯, position: [0.5, 0.3, 0.1]}, source: camera_detection, confidence: 0.87, updated_at: 1700000000.0 }当置信度低于阈值时Agent 可以选择重新感知确认而不应该盲目相信记忆里的旧数据。这在真实机器人系统中尤其重要毕竟一个错误的记忆比没有记忆更危险。7.4 安全与权限边界给机器人加记忆本质上是让机器人长期保存环境信息和用户偏好。这会带来隐私问题。在家庭场景下机器人可能记录用户的生活习惯、房间布局、经常使用的物品位置。在企业场景下记忆模块也可能包含敏感业务数据。因此在工程实现中要注意最小权限原则记忆模块只保存完成任务所需的最少信息不采集与任务无关的数据。数据可删除用户应该有能力查看机器人记住了什么并且能一键清除记忆。不要把记忆变成黑盒。访问控制跨用户、跨租户的记忆要严格隔离避免 A 用户的记忆被 B 用户的任务检索到。敏感信息脱敏如果视觉识别过程中采集到人脸、身份证号等敏感信息应避免写入长期记忆。7.5 从单机走向分布式的扩展思路上面的示例是单机 Redis 方案适用在家庭服务机器人或实验室机器人上。如果要做多机协同——比如一个仓库里有十几台机器人同时工作——记忆模块就需要升级成更可靠的架构。常见方案包括使用 Redis Cluster 做分布式存储。将重要记忆同步到持久化数据库如 PostgreSQL防止 Redis 重启丢失。使用消息队列推送记忆变更事件让多个 Agent 共享环境状态。引入分布式向量检索库支撑跨机器人经验复用。架构选择取决于业务规模不需要一开始就上重架构。关键点是记忆模块从一开始就应当作为一个独立服务来设计而不是和 Agent 主程序强耦合。这样后续无论是换存储中间件还是扩展集群影响范围都可控。8. 下一步的学习方向如果你刚接触具身智能 Agent Memory我建议按下面的顺序逐步深入先动手跑通本文的 Redis 记忆示例理解工作记忆、情景记忆、任务进度三个基础概念。学习向量数据库的基础用法尝试把情景记忆从 JSON 存储升级为语义向量检索用文本相似度召回历史经验。结合大模型规划器把记忆模块接入 LLM 的任务拆解流程观察加入记忆前后任务完成的稳定性差异。了解具身智能主流评测基准比如具身智能相关的长程任务评测集看它们在任务规划里如何评估记忆能力。关注真实机器人平台如果你手边有机械臂或移动机器人可以把记忆模块接到真实的感知和运动控制单元上验证从“模拟状态”到“物理状态”的迁移。具身推理和记忆都是很新的方向目前还没有一套公认的“标准答案”。这意味着工程实践里有大量可以发挥的空间。先把记忆模块这个基础组件做好后续不管是接视觉模型还是运动规划都会顺手很多。如果这篇文章对你有帮助可以收藏备用。后续我会继续更新具身智能系列的实操内容也会把大模型 Agent 和机器人任务规划结合起来逐个拆解。也欢迎在评论区聊聊你在给机器人做长程任务规划时踩过的坑一起讨论。
