Agent上下文与记忆管理实践，从Harness架构到Reflex的无限记忆探索

当用户问完‘订单O-1001为什么还没到’后紧接着追问‘那我明天还要等吗？’，Agent必须准确理解‘那’所指代的对象、前一轮的物流结论，以及用户明确提出的‘回答简单一点’这一表达偏好——这已超出单轮推理范畴，进入持续任务执行的领域。真实场景中，Agent需在会话内维持状态连贯性，在跨会话时保留关键偏好，并在信息膨胀时合理裁剪输入。这些能力的核心支撑，正是日益成熟的上下文与记忆管理机制。

分层管理：会话状态、上下文与长期记忆各司其职

根据Agent Harness架构的设计逻辑，数据被划分为三个功能层级：会话状态（Session State）、模型上下文（Context）与长期记忆（Long-term Memory），三者协同但职责分明。

会话状态用于保存当前任务的执行进度，例如当前处理的订单号、已完成的工具调用列表、待触发的步骤等。它由服务端持久化存储，确保同一会话中多次请求间的状态可恢复。当用户第二轮输入‘那我明天还要等吗？’时，系统首先依据session_id恢复该会话的历史记录，再将新消息与已有状态拼接为完整输入。

模型上下文则是本次LLM推理实际接收的内容，通常包括系统提示、近期对话摘要、相关记忆片段、可用工具定义及最新工具返回结果。由于大语言模型存在窗口长度限制（如常见32K token），框架需动态判断是否压缩历史。例如，AgentScope v2.0.10中通过ChatModelBase.context_size配置本地预算，默认32768 token；若输入+计划输出超出该阈值，即触发压缩策略——优先保留关键事实与近期交互，将冗余轨迹存入持久库以备检索。

长期记忆则聚焦于跨会话稳定的元信息：用户偏好（如‘简短回答’）、项目约束条件、经验性结论（如‘某供应商发货延迟率高’）等。这类信息需满足两个前提：一是来源可靠，二是时效性低。值得注意的是，物流状态等强时效数据不应直接写入长期记忆，否则易导致错误复用；正确做法是仅保存查询动作本身，实时数据仍需通过工具重新获取。

图1展示了单次对话中消息流的典型路径：新消息抵达后，Harness恢复会话、组织输入（含历史摘要与相关记忆）、提交模型请求；模型生成回复或工具调用指令；Harness执行工具并将结果回填至上下文，最终保存状态与记忆。

多实例共享与状态隔离：企业级部署的关键挑战

在实际业务系统中，常存在多个Agent实例并行服务同一类用户请求（如订单助手、售后专员）。此时需解决两个问题：一是如何让不同实例能接续同一会话；二是如何避免状态污染。

如图2所示, 业务入口（A2A客户端）携带请求与会话标识，服务端验证身份后选择一个可用Agent实例处理首轮请求；后续轮次可路由至同一实例，也可由其他实例承接——只要它们共享同一个会话状态库。该库不仅存储原始消息序列，还包含摘要、进度标记、执行归属、状态版本及幂等记录，确保并发访问下的一致性。

与此同时，长期记忆与知识库采用独立后端：前者按用户/项目维度索引，存储偏好与经验；后者则为业务规则、产品手册等静态资料提供向量检索支持。二者虽均使用相似的检索技术，但在更新频率、内容性质与作用域上截然不同——记忆服务于个性化推理，知识库服务于标准化应答。

图2清晰呈现了多实例共享会话状态库的架构逻辑，强调“执行归属”与“状态版本”对并发安全的重要性。

新路径：决策模型驱动Harness与无限记忆引擎

传统方案依赖人工设计的压缩规则与摘要生成来控制上下文膨胀，但可能丢失关键细节。APUS AI于2024年10月开源的Reflex Agent提出了一种新思路：将Harness的核心控制逻辑交由专用决策模型接管，并配套开发Continuum记忆引擎，实现“无损记忆+无损输入”。

Reflex Agent不再仅靠提示词与代码组织工作流，而是让Reflex模型负责模型路由、技能选择、完成审查与执行监督等高层决策。Harness转为执行层协调者：调度工具、跟踪状态、接收反馈，并将结果重新送入决策环。整个过程构成“决策→执行→反馈→再决策”的Loop Working循环，使Agent能围绕目标持续推进复杂任务。

据APUS实测，该架构下响应速度最快可达主流Agent的3倍，尤其适用于需频繁调用工具的长链任务。更重要的是，Continuum引擎允许Agent在不压缩原始信息的前提下积累任务历史——所有中间步骤、判断依据、工具返回值均可完整保留，并在需要时精准注入当前上下文。这意味着，当用户数天后再次提及同一订单，Agent不仅能 recalling 偏好，还可回溯当时物流节点的具体时间戳与异常原因，而非仅依赖模糊摘要。

图3揭示了开发者如何通过Harness定义记忆策略：既可设定自动规则（如top_k检索），也可由Agent按需决定何时读写；SDK层负责从持久库拉取相关记录，经过滤后与当前问题组合成输入；LLM生成答案后，按策略提取可沉淀的事实写入记忆库，并标注来源、时间与主题以便后续更新。

行业演进趋势：从单轮问答走向持续任务代理

当前Agent能力边界正从“回答问题”向“完成任务”迁移。这一转变对底层架构提出更高要求：不仅要处理单次推理的输入输出，还需管理跨轮次的状态延续、跨会话的记忆继承，以及长周期任务中的信息保全。

主流框架如AgentScope已提供较完善的分层管理模板，但实际落地仍面临工程权衡：过度压缩牺牲准确性，全量保留则受限于模型窗口；长期记忆若缺乏有效更新机制，易形成“过期认知”。Reflex Agent的尝试表明，引入专用决策模型与专用记忆引擎，可能是突破现有瓶颈的有效路径。

值得指出的是，无论采用何种技术路线，核心原则不变：时效性强的数据必须实时查询，稳定的信息才适合长期存储；上下文组织应服务于当前推理目标，而非简单堆砌历史。未来随着模型上下文窗口持续扩大（如部分厂商已支持百万token输入），记忆管理的重点或将从“如何删减”转向“如何高效检索与激活”，这对向量数据库、记忆索引结构与推理调度算法都提出新课题。

目前，Reflex Agent以MIT协议开源，支持桌面端、Web及SDK集成，APUS期待通过真实场景反馈进一步优化其Loop Working能力。而更多团队也在探索类似方向——例如将记忆写入图数据库以支持关系推理，或利用稀疏激活机制动态加载历史片段。可以预见，Agent的记忆与上下文管理，将成为下一阶段智能体实用化竞争的关键战场。