简介:本文深入剖析Agent系统中Memory架构的核心命题,对比传统“存储导向”与“决策导向”的外部状态架构差异。通过解析(Ledger, Views, Policy)最小闭包三件套,帮助架构师与开发者理清选型依据,构建具备长文本记忆与高阶决策能力的智能体系统。
在构建复杂的Agent(智能体)系统时,开发者常常会陷入一个误区:将Memory等同于“存储历史对话或文档的数据库”。然而,当Agent面对长周期任务时,仅仅堆积历史数据并不能带来能力的跃升。本文将对比分析Agent系统中两种典型的Memory架构理念——传统“存储导向”模式与“决策导向”的外部状态模式,并深度拆解(Ledger, Views, Policy)三件套架构,帮助技术团队在AI应用开发中做出合理的架构选型。
在Agent的运行过程中,其本质可以看作一个从输入到输出的复杂函数。如何让历史信息有效参与当前的决策,是Memory系统存在的根本意义。我们在此对比两类典型的Memory设计思路:
方案A:传统存储导向型Memory(文档块/历史记录堆叠)
这类方案将Memory简单视为时间序列的堆积或向量化的文本切片。其核心逻辑是“存什么”以及“如何检索”,通常表现为将历史对话或外部文档切块后存入向量数据库,在需要时通过相似度检索取回部分“文档块”。
方案B:决策导向型外部状态((Ledger, Views, Policy)三件套)
此方案认为Memory不是静态存储,而是可被决策利用的外部状态。它不追求“存了多少历史”,而是构建一条从历史到当前决策的有效通道,其最小闭包由记录层、视图层和策略层构成,直接服务于推理层。
尽管两种架构理念不同,但它们在Agent系统中仍存在基础共识:
两种架构的差异不在于使用何种数据库,而在于对“信息价值”的理解与系统边界的划分。
1. 架构理念与系统边界
方案A的边界停留在“数据库+检索接口”,它的输出是一堆原始的或仅经过简单排序的文本块,这些文本块能否被有效利用完全依赖推理层自身的消化能力。而方案B的边界直接延伸至决策层,它负责从历史中提取当前可用的信息(证据、摘要、子图、可执行技能等),其输出要么作为精炼后的上下文,要么直接参与对输出分布的调制。
2. 数据处理与信息转化
方案A处理的是“符号本身”,即按照固定规则切片并计算向量相似度。方案B处理的是“状态转移”,它将历史视为一系列状态的变更,并通过视图动态生成当前任务所需的快照。
3. 决策干预能力
这是两者的分水岭。方案A是被动的“备查资料库”,对决策的影响是间接且粗粒度的。方案B是主动的“状态机”,其提取的不仅是文本,还可以是可执行技能或逻辑子图,能够直接改变Agent下一步的行动分布。
| 对比维度 | 方案A:存储导向型(文档块模式) | 方案B:决策导向型(外部状态三件套模式) |
|---|---|---|
| 核心本质 | 静态历史记录与文本块的集合 | 可被决策利用的动态外部状态 |
| 架构组件 | 向量库 + 检索接口 + 上下文拼接 | Ledger(记录) + Views(视图) + Policy(策略) |
| 输出形态 | 原始文本切片、相似度排序结果 | 证据摘要、知识子图、可执行技能指令 |
| 对决策的影响 | 间接参与(作为Prompt背景信息) | 直接参与(上下文注入或直接调制输出分布) |
| 信息价值 | 取决于“存了多少历史”与召回率 | 取决于“历史到当前决策的通道”是否有效 |
| 接入复杂度 | 较低,标准化接口易于集成 | 较高,需根据业务场景定制视图与策略 |
| 适用场景 | 简单知识问答、静态文档检索 | 复杂任务规划、多轮工具调用、长周期智能体系统 |
方案B之所以能构成Agent Memory的最小闭包,在于其三个组件形成了完整的信息闭环:
以下为该三件套架构的伪代码示意,展示其交互逻辑:
class AgentMemorySystem:def __init__(self):self.ledger = EventLedger() # 不可变事件账本self.views = MemoryViews() # 视图生成器self.policy = RecallPolicy() # 召回与调制策略def update_state(self, observation, thought, action):# 记录层:将新的状态转移写入账本self.ledger.append(observation, thought, action)def get_memory_for_inference(self, current_context):# 策略层:根据当前上下文决定需要哪些信息required_views = self.policy.determine_needs(current_context)# 视图层:从历史中提取当前可用信息(非简单文本块)active_memory = self.views.generate(required_views, self.ledger)# 策略层:决定输出形式(进入上下文或直接参与决策调制)if self.policy.requires_direct_modulation(active_memory):return {"type": "modulation", "data": active_memory.extract_skills()}else:return {"type": "context", "data": active_memory.summarize_evidence()}
1. 适合方案A(存储导向型)的场景
当你的应用是一个基于静态文档的问答系统,或者Agent的任务逻辑极其简单、无需多步规划时,采用方案A可以快速落地。团队若运维能力有限,且希望直接使用通用云服务中的对象存储与向量检索能力,方案A是低成本的首选。
2. 适合方案B(决策导向型三件套)的场景
当构建需要长周期运行、具备复杂工具调用能力、需要维护用户长期画像并进行个性化决策的Agent系统时,必须采用方案B。例如自动化编程助手、深度企业数据分析智能体等,这些场景下“历史”必须转化为“当前可用技能或状态”,而非简单的文本堆叠。
选型建议:不要盲目追求复杂的Memory架构。如果在高并发场景下,更需关注三件套架构中视图层生成的弹性扩展能力。在团队具备较强自研能力且业务逻辑复杂时,可优先考虑基于(Ledger, Views, Policy)构建专属的外部状态系统;若仅为解决短期上下文遗忘问题,则采用行业常见技术方案中的托管化向量存储更为经济。
若企业计划将现有的Agent系统从方案A向方案B迁移,需重点关注以下风险与成本:
Agent的Memory系统,其本质不是历史的博物馆,而是决策的兵工厂。能力不来源于“存了多少”,而来源于“历史能否以某种形式影响决策分布”。从简单的文档块向(Ledger, Views, Policy)三件套外部状态架构演进,是Agent从“能说话”到“能做事”的必经之路。架构师在进行技术选型时,唯有理清“存储”与“状态”的根本区别,方能构建出真正具备长程推理与决策能力的智能体系统。