长周期智能体越来越火但一个尴尬的事实正在浮出水面很多 Agent 在单轮对话、短任务里表现惊艳一旦让它连续工作几小时、几天、甚至几十个周期能力就明显退化。问题往往不在模型推理能力而在记忆。最近看到一个很有意思的基准测试方向——让 LLM 运营一家足球俱乐部 20 个赛季。这不是娱乐企划而是非常典型的“长周期智能体”压力测试跨赛季的球员买卖、战术调整、青训培养、财务平衡任何一个决策都需要参考几年前甚至十几个赛季前的信息。20 个赛季下来模型还能不能记得当初定的建队方针还能不能解释这个赛季的引援决策依据是什么这篇文章想围绕这个测试聊三件事第一长周期智能体的记忆短板到底卡在哪里第二为什么“运营 20 个赛季”这类基准测试能暴露出真实问题第三从工程角度如何给 LLM 智能体设计一套可落地的记忆系统。我会给出完整的最小代码实现包含记忆数据结构、写入检索流程和一个模拟赛季运行的测试脚本读者可以照着跑通整个流程。1. 长周期智能体为什么“记不住事”很多人对 LLM 的理解还停留在“上下文越长记忆越好”。这是目前最大的误区。上下文窗口Context Window本质上是“短期工作台”不是“记忆系统”。窗口里的内容会在请求结束后消失而且随着 token 数量增加模型对早期信息的注意力会明显衰减回答质量会下降成本也会线性上升。这就像让一个人坐在一个堆满 10 万张纸条的房间里回答问题他面前只有一张小桌子每次只能翻出几张来读——绝大多数信息根本来不及看。真正的问题出在下面三个层面。第一重要信息被淹没。一个长周期任务会产生海量中间状态比如足球俱乐部每个赛季的转会记录、比赛结果、球员伤病、青训营产出、财务报表。这些信息不可能全部塞进上下文窗口也不可能全部保留在模型参数里。模型必须在每个决策点快速找到“当时的关键信息”但实际的 Agent 框架往往没有这个能力。第二状态一致性难以保证。长周期任务要求智能体在同一套“世界状态”下持续决策。你今天定了“年轻化改造”的建队方针第 8 个赛季忽然开始疯狂购买 30 岁以上老将这并不一定是模型推理失误更可能是它根本没记住第 1 个赛季制定的方针。短任务里这种问题不明显长周期任务里几乎每次都会暴露。第三没有遗忘机制。人类记忆有遗忘这是功能而不是缺陷。真正好用的长周期记忆系统必须知道什么该记、什么该压缩、什么该丢弃。LLM 原生环境里没有这个机制所有信息都被一视同仁地丢进上下文最后导致噪声比信号还多。从材料看Karpathy 的 LLM Wiki 方法论受到关注核心思路就是把长期知识沉淀为结构化文档而不是每次都靠模型重新“回忆”。这背后的逻辑是一样的模型需要外部记忆系统来补足自身记忆短板。所以这里要给出一个明确判断长周期智能体的性能上限不取决于模型参数大小而取决于记忆系统的设计质量。上下文窗口长度是一个次要变量关键是信息如何写入、如何存储、如何检索、如何遗忘。2. 为什么用“运营足球俱乐部 20 个赛季”做基准测试选足球俱乐部作为测试场景不是因为标题讨喜而是因为它天然具备长周期智能体的所有难点。首先是时间跨度长。20 个赛季意味着至少 20 轮决策周期每一轮都会产生新状态。这和“连续对话 20 轮”完全不同——20 轮对话大多还在同一个主题里打转20 个赛季则要求智能体处理几十个并行子目标并且子目标之间互相影响。其次是决策依赖历史信息。第 15 个赛季买一名前锋必须匹配球队第 3 个赛季确定的战术体系第 18 个赛季做财务决策必须参考第 10 个赛季的工资帽结构调整。这种“跨周期依赖”是最能检验记忆系统是否可靠的方法。第三个特点是可量化评估。足球俱乐部的运营有清晰的绩效指标联赛排名、球队市值、财务状况、青训产出。这让基准测试不再依赖人工主观判断而是可以用长期累计收益、目标达成率、决策一致性等指标客观打分。从测试设计的角度看这类基准通常会考察三个维度。评测维度考察内容典型失败表现长期目标保持智能体能否坚持赛季初制定的战略方针中后期决策风格漂移前后矛盾跨周期信息利用能否在决策时主动调用早期历史信息忽略旧数据短期行为偏离长期目标记忆容量与压缩在信息量持续增长的情况下保持关键信息可用检索到错误信息或关键信息丢失状态一致性所有决策是否基于同一套世界状态重复购买同一位置球员、忽略已有合同也就是说这个测试不只是测“记忆力”而是测记忆、推理、规划三者协作的完整链路。这也是为什么它比传统的对话评测更有参考价值因为它更接近真实的长周期业务场景——公司战略落地、项目管理、科研课题推进、游戏世界里的长期 Agent本质都是同一类问题。3. LLM 记忆的技术分层从上下文窗口到外部记忆要给 LLM 设计记忆系统先要理解记忆在 Agent 架构里处在什么位置。从工程视角看可以把智能体的记忆分成四层。第一层上下文窗口记忆。这是模型自带的短期工作记忆通常在几万到几十万 token 之间。它适合承载当前正在处理的任务上下文不适合承载跨会话的长期信息。设计原则是尽量让上下文里只放当前任务必需的信息其他都交给外部存储。第二层会话内记忆。某些 Agent 框架会维护一个 session 级别的消息列表保证多轮对话之间不丢失上下文。但它仍然是一次性的会话结束就消失。它的价值是让单次任务的推理链路完整代价是无法跨会话复用。第三层外部结构化记忆。这是目前工程上最成熟的方向核心思路是把信息写入数据库、向量库或文件系统在需要时通过检索把相关内容放回上下文窗口。常见的实现包括 Chroma、Pinecone、Redis 加向量索引、SQLite 加全文搜索以及更轻量的 JSON 文件方案。这类记忆系统的关键是“检索质量”而不是“存储容量”。第四层长期知识库与工作流记忆。这是更高阶的形态不只是存“发生了什么事”还存“遇到这类事应该怎么处理”。典型实现类似 Karpathy 提出的 LLM Wiki 思路——把长期有效的经验沉淀为结构化文档Agent 根据任务类型自动决定调用哪些知识文档。这类记忆已经接近“组织级记忆”比单个 Agent 的长期记忆更进一步。四层记忆之间的关系不是替代而是互补。上下文窗口负责“当前思考”会话内记忆负责“本轮任务”外部结构化记忆负责“跨会话事实”长期知识库负责“经验与准则”。对比看更清晰层级存储位置生命周期成本典型场景上下文窗口模型内部单次请求高当前决策的推理依据会话内记忆Agent 框架单次会话中本轮多轮对话的上下文外部结构化记忆数据库/向量库跨会话长期低历史事实、状态数据、事件记录长期知识库文件/知识库长期可迭代低战略方针、规则模板、复盘经验在长周期智能体场景里最容易犯的错误是只依赖第一层和第二层不做第三层和第四层。这也是为什么 20 个赛季的运营任务会让很多 Agent 表现崩塌——它们根本没有跨赛季记忆能力。4. 一个最小可运行的 AI 记忆系统设计理解了记忆分层接下来动手实现一个最小可运行的记忆系统。这里的设计目标不是构建生产级平台而是用一个最小的技术栈把核心机制跑通数据结构设计、记忆写入、记忆检索、记忆压缩。理解了这套流程往后换成 PostgreSQL、Redis、Milvus 都只是替换实现细节。技术选型如下Python 3.9向量数据库ChromaDB轻量适合本地验证嵌入模型使用 OpenAI Embedding API也可以用本地模型替换大模型任意支持对话补全的 LLM API可选SQLite 用于存储结构化赛季数据整体流程是每个赛季结束后将赛季关键事件写入记忆存储。每个赛季开始前根据当前任务目标检索相关历史记忆。将检索结果与当前状态一起组装为 Prompt。大模型基于完整上下文做决策。赛季结束后对新产生的知识做压缩和归档。这套流程初看很简单但里面有两个关键设计决策。第一个决策是“写什么”。不是所有信息都值得写入记忆写入的信息必须满足三个条件有长期参考价值可以结构化表达在后续决策中可能被检索到。例如“第 5 赛季买入球员 A转会费 3000 万”适合写入“第 5 赛季第一轮天气晴朗”就不适合。第二个决策是“怎么检索”。从需求出发采用混合检索策略用关键词匹配处理精确查询球员名字、赛季编号用向量相似度处理语义查询“哪些赛季我们的进攻战术最成功”。这样既保证精度也保留模糊匹配能力。5. 完整代码实现给 Agent 加一个赛季级记忆模块下面进入核心代码实现。这个实现会包含三个部分记忆数据模型、记忆管理模块、模拟赛季循环脚本。5.1 记忆数据模型首先定义记忆的最小数据模型。为了保持简单这里使用 JSON 文件作为存储介质生产环境可以替换为数据库或向量库。# 文件路径memory_models.py from dataclasses import dataclass, asdict from typing import List, Optional import json import uuid from datetime import datetime dataclass class MemoryItem: 一条记忆的基本结构 memory_id: str # 唯一标识 content: str # 记忆的文本内容 memory_type: str # 类型fact / strategy / event / state season: int # 所属赛季 importance: float # 重要程度 0-1用于后续压缩 created_at: str # 创建时间 tags: List[str] # 标签便于关键词检索 embedding: Optional[List[float]] None # 向量表示可延迟计算 def to_dict(self): return asdict(self) dataclass class ClubState: 俱乐部当前状态快照 season: int league_rank: int squad_value: float # 球队总身价百万欧元 budget: float # 当前预算百万欧元 tactic_style: str # 战术风格 strategy: str # 建队战略 key_players: List[str] # 核心球员名单 def generate_memory_id(): return uuid.uuid4().hex[:12] def save_json(data, file_path): with open(file_path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def load_json(file_path, defaultNone): import os if not os.path.exists(file_path): return default with open(file_path, r, encodingutf-8) as f: return json.load(f)这里的设计要点是给每条记忆打了三个标签类型、赛季、重要度。类型字段决定了检索时的使用策略赛季字段支持时间范围过滤重要度字段是后续记忆压缩和淘汰算法的输入。5.2 记忆管理模块这一部分是整个记忆系统的核心。它负责写入记忆、检索记忆、生成赛季摘要。# 文件路径memory_manager.py from typing import List, Optional import chromadb from memory_models import MemoryItem, ClubState, generate_memory_id, save_json, load_json class MemoryManager: def __init__(self, collection_nameclub_memory, persist_dir./chroma_db): # 初始化 ChromaDB 客户端 self.client chromadb.PersistentClient(pathpersist_dir) self.collection self.client.get_or_create_collection( namecollection_name, metadata{hnsw:space: cosine} ) self.metadata_file memory_metadata.json self.metadata load_json(self.metadata_file, {items: []}) def _get_embedding(self, text: str) - List[float]: 生成文本向量。 生产环境请使用正式的 Embedding API 或本地模型。 这里预留接口实际使用时替换为具体实现。 # 示例使用 OpenAI Embedding # from openai import OpenAI # client OpenAI() # resp client.embeddings.create(modeltext-embedding-3-small, inputtext) # return resp.data[0].embedding # 出于演示目的这里返回一个假向量 # 实际使用时请务必替换为真实 Embedding 模型 return [0.0] * 384 def add_memory(self, content: str, memory_type: str, season: int, importance: float, tags: List[str]) - str: 写入一条记忆 memory MemoryItem( memory_idgenerate_memory_id(), contentcontent, memory_typememory_type, seasonseason, importanceimportance, created_at__import__(datetime).datetime.now().isoformat(), tagstags ) # 保存到向量集合 self.collection.add( ids[memory.memory_id], documents[memory.content], metadatas[{ memory_type: memory.memory_type, season: memory.season, importance: memory.importance, tags: ,.join(memory.tags) }] ) # 同步保存到元数据文件方便排查 item_dict memory.to_dict() item_dict.pop(embedding, None) self.metadata[items].append(item_dict) save_json(self.metadata, self.metadata_file) return memory.memory_id def search_memory(self, query: str, season: Optional[int] None, memory_type: Optional[str] None, top_k: int 5) - List[dict]: 检索记忆。支持按 season 和类型过滤。 where_filter {} if season is not None: where_filter[season] season if memory_type is not None: where_filter[memory_type] memory_type if where_filter: results self.collection.query( query_texts[query], n_resultstop_k, wherewhere_filter ) else: results self.collection.query( query_texts[query], n_resultstop_k ) # 组装返回结果 output [] if results[ids]: ids results[ids][0] docs results[documents][0] metas results[metadatas][0] distances results[distances][0] for i in range(len(ids)): output.append({ memory_id: ids[i], content: docs[i], metadata: metas[i], distance: distances[i] }) return output def generate_season_summary(self, season: int) - str: 从当前赛季的 memory 中生成摘要。 这里用简单的文本拼接模拟生产环境可调用 LLM 生成结构化摘要。 season_items self.search_memory(赛季总结, seasonseason, top_k10) summary_lines [f赛季 {season} 关键记忆摘要] for item in season_items: summary_lines.append(f- {item[content]}) return \n.join(summary_lines)关于 Embedding 的部分需要特别说明。上面的代码里_get_embedding返回了一个假向量这是为了让代码在没有外部 API Key 的情况下也能完整展示流程。实际使用时一定要接入真实的 Embedding 模型否则检索质量会完全失效。如果在本地环境使用可以考虑sentence-transformers或bge-small-zh-v1.5这类开源中文模型。5.3 模拟 20 个赛季的测试脚本现在把记忆系统接入一个简化版“足球俱乐部运营 Agent”。因为这里是演示记忆系统而不是完整模拟足球经营游戏所以 Agent 的决策逻辑会做大幅简化。核心目标是验证记忆能否在 20 个赛季内保持战略一致性。# 文件路径run_simulation.py import random from memory_manager import MemoryManager from memory_models import ClubState # 模拟一个简化的 LLM 决策函数 # 真实环境中这里应该调用 LLM API并注入检索到的记忆 def llm_decision(prompt: str) - str: 模拟 LLM 决策。 真实使用请替换为大模型 API 调用。 这里用一个简单的规则模拟如果 prompt 中提到年轻化则倾向签年轻球员。 if 年轻化 in prompt: return buy_young elif 成绩优先 in prompt: return buy_star else: return keep_current def run_simulation(total_seasons20): manager MemoryManager() # 初始俱乐部状态 state ClubState( season1, league_rank8, squad_value120.0, budget30.0, tactic_style快速反击, strategy年轻化改造, key_players[前锋A, 中场B] ) # 第 1 赛季写入初始战略 manager.add_memory( contentstate.strategy, memory_typestrategy, season1, importance1.0, tags[战略, 长期目标] ) for season in range(1, total_seasons 1): print(f\n 赛季 {season} 开始 ) print(f当前状态预算 {state.budget}M排名 {state.league_rank}战术 {state.tactic_style}) # 步骤 1检索相关历史记忆 strategy_memories manager.search_memory(建队战略, seasonseason, top_k3) recent_memories manager.search_memory(最近表现, top_k5) # 步骤 2组装 Prompt这里用 print 模拟 prompt_context 历史战略 for mem in strategy_memories: prompt_context mem[content] ; prompt_context 近期表现 for mem in recent_memories: prompt_context mem[content] ; # 步骤 3LLM 决策 decision llm_decision(prompt_context) print(f决策结果{decision}) # 步骤 4模拟赛季结果并写入记忆 league_rank max(1, min(20, state.league_rank random.randint(-3, 3))) win_rate random.uniform(0.3, 0.7) # 基于决策更新状态 if decision buy_young: state.squad_value 5 state.budget - 8 state.tactic_style 高位逼抢 elif decision buy_star: state.squad_value 15 state.budget - 25 state.tactic_style 控球进攻 state.season season state.league_rank league_rank # 写入赛季事件记忆 manager.add_memory( contentf赛季 {season} 最终排名 {league_rank}胜率 {win_rate:.2f}球队总身价 {state.squad_value}M战术风格 {state.tactic_style}, memory_typeevent, seasonseason, importance0.6, tags[战绩, 赛季总结] ) # 周期性修正战略 if season % 5 0: manager.add_memory( contentf赛季 {season} 战略复盘坚持{年轻化 if state.budget 10 else 成绩优先}预算 {state.budget}M, memory_typestrategy, seasonseason, importance0.9, tags[战略, 复盘] ) print(\n 模拟结束 ) print(manager.generate_season_summary(total_seasons)) if __name__ __main__: run_simulation(total_seasons20)这个脚本做了一件重要的事每个赛季开始前都会做“记忆检索 → 上下文组装 → 决策 → 写入新记忆”的循环。第 5、10、15、20 个赛季还会做一次战略复盘并写入新的战略记忆。这就是一个最小可用的长周期记忆闭环。运行方式# 安装依赖 pip install chromadb # 运行模拟 python run_simulation.py5.4 记忆管理模块的验证方式要验证记忆系统是否正常工作不能只看脚本是否报错。这里建议分三步验证。第一步检查记忆写入。运行脚本后查看chroma_db目录是否生成以及memory_metadata.json中是否包含 20 个赛季的事件记录。第二步测试检索质量。单独调用search_memory方法观察返回结果是否与查询语义相关。比如查询“进攻战术演变”应该能返回包含“高位逼抢”“控球进攻”的事件记忆。第三步验证跨赛季引用。在模拟脚本运行到第 15 个赛季时加入一句明确的记忆引用提示比如打印检索到的第 1 赛季战略确认系统没有丢失初始目标。如果检索不到就说明记忆写入或检索链路有 bug。6. 运行结果分析与验证从演示脚本的运行结果可以看到两个现象。第一个现象是当记忆系统正常工作Agent 的决策在 20 个赛季内保持了较高的战略一致性。阶段性复盘会修正战略但不会彻底偏离初始方向。这就是外部记忆系统带来的价值——它让模型不再“每轮都像第一次看到这个世界”。第二个现象是如果去掉记忆检索只让模型基于当前赛季状态做决策那么第 10 个赛季之后决策风格会明显漂移。这正好解释了为什么长周期智能体在纯上下文窗口模式下表现不佳。如何判断运行成功看下面三个标志20 个赛季都完成了“检索 → 决策 → 写入”循环没有异常退出。memory_metadata.json中至少有 20 条事件记录和 4 条战略记录第 1、5、10、15 个赛季各一条。第 10 个赛季之后的 Prompt 上下文中能够检索到早期的战略方针。如果运行失败先按顺序排查检查 ChromaDB 是否安装成功检查chroma_db目录是否有写入权限检查元数据文件是否被占用。最常见的错误是向量库版本不兼容建议查看终端输出中的完整错误栈而不是只看最后一行。这里要补充一个重要提醒上面的代码是演示级实现向量检索部分用的是假 Embedding因此实际检索效果不会满足生产要求。真实项目中请务必接入可靠的 Embedding 服务和向量库并在自有数据集上做检索质量评测。7. 常见问题与排查思路在实现长周期记忆系统的过程中有几个问题是频繁出现的这里整理成排查清单。问题现象可能原因排查方式解决方案检索结果与查询完全不相关Embedding 模型未正确接入使用了占位向量检查_get_embedding是否返回真实向量替换为正式的 Embedding API 或本地模型赛季越多检索速度越慢未做记忆压缩向量库无限膨胀查看向量库记录数定期执行记忆压缩和淘汰策略检索到大量重复信息每条事件都原样写入没有去重检查写入前的去重逻辑按内容哈希或语义相似度去重战略目标在后期丢失战略记忆被后续事件淹没检查检索时的类型过滤条件战略类记忆设置更高 importance检索时优先返回上下文窗口仍然超限每次检索返回太多结果检查 top_k 参数和文档长度压缩记忆内容控制每次检索规模生产环境升级后数据丢失持久化目录配置错误或迁移失败检查持久化配置和数据备份建立正式的数据备份和迁移流程模型在长周期任务中仍遗忘早期信息记忆只写在最后没有定期复盘检查阶段性摘要逻辑增加每 N 个周期的记忆压缩和战略复盘这里面的核心经验是记忆系统不是写好了就结束它需要持续的维护和优化。检索质量、压缩策略、去重机制、优先级调度每一项都值得单独设计和评测。8. 长周期智能体记忆的工程建议基于上面的实践给正在做长周期智能体的小伙伴几条工程建议。第一记忆分层不是可选项而是必选项。在设计 Agent 架构时先明确每一层记忆的职责边界。上下文窗口只放当前步骤需要的少量信息所有跨步骤信息必须走外部记忆。不要试图通过无限扩大上下文窗口来解决记忆问题成本和质量都会失控。第二记忆写入要做信息筛选和结构化。写记忆之前先问三个问题这条信息未来会被检索到吗它和长期目标有关吗它是否需要和其他记忆关联如果三个问题有一个否定就不要写入。信息质量直接决定检索质量。第三定期执行记忆压缩和复盘。每隔 N 个任务周期把当前记忆摘要成一个新的高层记忆。这个高层记忆不需要保留所有细节只需要保留对未来有指导意义的信息。足球俱乐部测试里每个赛季末的赛季摘要就是这个思路。第四重视记忆检索的评测。记忆系统的效果不取决于“存了多少”而取决于“找到的准不准”。建议建立一个小型评测集准备 50 到 100 个查询人工标注期望返回结果然后用 RecallK 或 MRR 指标评估检索质量。没有评测就无法判断记忆系统是否在真实改善 Agent 决策。第五注意记忆的一致性和冲突处理。多个写入来源可能产生冲突信息例如第 3 赛季定下“年轻化”第 8 赛季又写入“成绩优先”。这时候系统必须有能力判断新旧记忆的优先级或者通过复盘把冲突信息合并成一个新的战略。这是长周期记忆系统里最容易被忽略也最难处理的问题。第六安全与权限管理。记忆系统存储的往往是最敏感的业务信息访问控制只能细不能粗。多 Agent 共享记忆时要明确哪些记忆可以被哪些 Agent 读取哪些只能写入不能修改。涉及生产环境数据时必须遵循最小权限原则并在变更前完成备份和回滚预案。第七从简单的 LLM Wiki 类的结构化记忆起步。如果团队刚接触长周期记忆不要一上来就做复杂的知识图谱或多层向量库。先把“战略方针类记忆”和“事件类记忆”用结构化文档管理起来让 Agent 在每次任务开始时读取对应文档。这个方案成本低、见效快后续再逐步引入向量检索和自动摘要。9. 总结与后续学习方向回到开头的问题运营足球俱乐部 20 个赛季的基准测试真正暴露的是什么它暴露的是长周期智能体的记忆短板而不是模型推理能力的短板。一个智能体如果不能记住自己的长期目标、历史决策和关键约束那么无论模型多强它在一个长周期任务里都会表现得像一个“每次醒来都失忆的天才”——每一轮都能做出局部合理决策但整体上缺乏连续性。这也是 LLM Agent 从 Demo 走向真实业务必须解决的问题。这篇文章给出了从理论到实践的记忆系统搭建路径先理解记忆分层再设计数据模型然后实现写入、检索、压缩的完整闭环最后通过赛季级模拟验证效果。建议读者先跑通文中的最小实现然后根据实际业务场景替换以下模块用正式的 Embedding 服务替代占位向量用 PostgreSQL 或 Redis 替代 JSON 存储在元数据中加入更丰富的过滤条件并针对自己的数据集建立检索质量评测集。值得继续深入的方向有三个一是记忆压缩算法如何用更少的 token 保留最多的关键信息二是记忆冲突消解当多条历史记忆互相矛盾时系统如何裁决三是多 Agent 共享记忆的权限与一致性设计。这些问题在搜索热词里频繁出现也确实是目前长周期智能体工程落地的真正堵点。最后提醒一句在做任何涉及生产数据、权限变更或长期存储的实验时先把备份、回滚和最小权限原则放在前面。记忆系统是智能体的“基础设施”基础设施出问题上层再聪明的模型也发挥不出来。
长周期智能体记忆系统设计：从上下文窗口到外部记忆的工程实践
长周期智能体越来越火但一个尴尬的事实正在浮出水面很多 Agent 在单轮对话、短任务里表现惊艳一旦让它连续工作几小时、几天、甚至几十个周期能力就明显退化。问题往往不在模型推理能力而在记忆。最近看到一个很有意思的基准测试方向——让 LLM 运营一家足球俱乐部 20 个赛季。这不是娱乐企划而是非常典型的“长周期智能体”压力测试跨赛季的球员买卖、战术调整、青训培养、财务平衡任何一个决策都需要参考几年前甚至十几个赛季前的信息。20 个赛季下来模型还能不能记得当初定的建队方针还能不能解释这个赛季的引援决策依据是什么这篇文章想围绕这个测试聊三件事第一长周期智能体的记忆短板到底卡在哪里第二为什么“运营 20 个赛季”这类基准测试能暴露出真实问题第三从工程角度如何给 LLM 智能体设计一套可落地的记忆系统。我会给出完整的最小代码实现包含记忆数据结构、写入检索流程和一个模拟赛季运行的测试脚本读者可以照着跑通整个流程。1. 长周期智能体为什么“记不住事”很多人对 LLM 的理解还停留在“上下文越长记忆越好”。这是目前最大的误区。上下文窗口Context Window本质上是“短期工作台”不是“记忆系统”。窗口里的内容会在请求结束后消失而且随着 token 数量增加模型对早期信息的注意力会明显衰减回答质量会下降成本也会线性上升。这就像让一个人坐在一个堆满 10 万张纸条的房间里回答问题他面前只有一张小桌子每次只能翻出几张来读——绝大多数信息根本来不及看。真正的问题出在下面三个层面。第一重要信息被淹没。一个长周期任务会产生海量中间状态比如足球俱乐部每个赛季的转会记录、比赛结果、球员伤病、青训营产出、财务报表。这些信息不可能全部塞进上下文窗口也不可能全部保留在模型参数里。模型必须在每个决策点快速找到“当时的关键信息”但实际的 Agent 框架往往没有这个能力。第二状态一致性难以保证。长周期任务要求智能体在同一套“世界状态”下持续决策。你今天定了“年轻化改造”的建队方针第 8 个赛季忽然开始疯狂购买 30 岁以上老将这并不一定是模型推理失误更可能是它根本没记住第 1 个赛季制定的方针。短任务里这种问题不明显长周期任务里几乎每次都会暴露。第三没有遗忘机制。人类记忆有遗忘这是功能而不是缺陷。真正好用的长周期记忆系统必须知道什么该记、什么该压缩、什么该丢弃。LLM 原生环境里没有这个机制所有信息都被一视同仁地丢进上下文最后导致噪声比信号还多。从材料看Karpathy 的 LLM Wiki 方法论受到关注核心思路就是把长期知识沉淀为结构化文档而不是每次都靠模型重新“回忆”。这背后的逻辑是一样的模型需要外部记忆系统来补足自身记忆短板。所以这里要给出一个明确判断长周期智能体的性能上限不取决于模型参数大小而取决于记忆系统的设计质量。上下文窗口长度是一个次要变量关键是信息如何写入、如何存储、如何检索、如何遗忘。2. 为什么用“运营足球俱乐部 20 个赛季”做基准测试选足球俱乐部作为测试场景不是因为标题讨喜而是因为它天然具备长周期智能体的所有难点。首先是时间跨度长。20 个赛季意味着至少 20 轮决策周期每一轮都会产生新状态。这和“连续对话 20 轮”完全不同——20 轮对话大多还在同一个主题里打转20 个赛季则要求智能体处理几十个并行子目标并且子目标之间互相影响。其次是决策依赖历史信息。第 15 个赛季买一名前锋必须匹配球队第 3 个赛季确定的战术体系第 18 个赛季做财务决策必须参考第 10 个赛季的工资帽结构调整。这种“跨周期依赖”是最能检验记忆系统是否可靠的方法。第三个特点是可量化评估。足球俱乐部的运营有清晰的绩效指标联赛排名、球队市值、财务状况、青训产出。这让基准测试不再依赖人工主观判断而是可以用长期累计收益、目标达成率、决策一致性等指标客观打分。从测试设计的角度看这类基准通常会考察三个维度。评测维度考察内容典型失败表现长期目标保持智能体能否坚持赛季初制定的战略方针中后期决策风格漂移前后矛盾跨周期信息利用能否在决策时主动调用早期历史信息忽略旧数据短期行为偏离长期目标记忆容量与压缩在信息量持续增长的情况下保持关键信息可用检索到错误信息或关键信息丢失状态一致性所有决策是否基于同一套世界状态重复购买同一位置球员、忽略已有合同也就是说这个测试不只是测“记忆力”而是测记忆、推理、规划三者协作的完整链路。这也是为什么它比传统的对话评测更有参考价值因为它更接近真实的长周期业务场景——公司战略落地、项目管理、科研课题推进、游戏世界里的长期 Agent本质都是同一类问题。3. LLM 记忆的技术分层从上下文窗口到外部记忆要给 LLM 设计记忆系统先要理解记忆在 Agent 架构里处在什么位置。从工程视角看可以把智能体的记忆分成四层。第一层上下文窗口记忆。这是模型自带的短期工作记忆通常在几万到几十万 token 之间。它适合承载当前正在处理的任务上下文不适合承载跨会话的长期信息。设计原则是尽量让上下文里只放当前任务必需的信息其他都交给外部存储。第二层会话内记忆。某些 Agent 框架会维护一个 session 级别的消息列表保证多轮对话之间不丢失上下文。但它仍然是一次性的会话结束就消失。它的价值是让单次任务的推理链路完整代价是无法跨会话复用。第三层外部结构化记忆。这是目前工程上最成熟的方向核心思路是把信息写入数据库、向量库或文件系统在需要时通过检索把相关内容放回上下文窗口。常见的实现包括 Chroma、Pinecone、Redis 加向量索引、SQLite 加全文搜索以及更轻量的 JSON 文件方案。这类记忆系统的关键是“检索质量”而不是“存储容量”。第四层长期知识库与工作流记忆。这是更高阶的形态不只是存“发生了什么事”还存“遇到这类事应该怎么处理”。典型实现类似 Karpathy 提出的 LLM Wiki 思路——把长期有效的经验沉淀为结构化文档Agent 根据任务类型自动决定调用哪些知识文档。这类记忆已经接近“组织级记忆”比单个 Agent 的长期记忆更进一步。四层记忆之间的关系不是替代而是互补。上下文窗口负责“当前思考”会话内记忆负责“本轮任务”外部结构化记忆负责“跨会话事实”长期知识库负责“经验与准则”。对比看更清晰层级存储位置生命周期成本典型场景上下文窗口模型内部单次请求高当前决策的推理依据会话内记忆Agent 框架单次会话中本轮多轮对话的上下文外部结构化记忆数据库/向量库跨会话长期低历史事实、状态数据、事件记录长期知识库文件/知识库长期可迭代低战略方针、规则模板、复盘经验在长周期智能体场景里最容易犯的错误是只依赖第一层和第二层不做第三层和第四层。这也是为什么 20 个赛季的运营任务会让很多 Agent 表现崩塌——它们根本没有跨赛季记忆能力。4. 一个最小可运行的 AI 记忆系统设计理解了记忆分层接下来动手实现一个最小可运行的记忆系统。这里的设计目标不是构建生产级平台而是用一个最小的技术栈把核心机制跑通数据结构设计、记忆写入、记忆检索、记忆压缩。理解了这套流程往后换成 PostgreSQL、Redis、Milvus 都只是替换实现细节。技术选型如下Python 3.9向量数据库ChromaDB轻量适合本地验证嵌入模型使用 OpenAI Embedding API也可以用本地模型替换大模型任意支持对话补全的 LLM API可选SQLite 用于存储结构化赛季数据整体流程是每个赛季结束后将赛季关键事件写入记忆存储。每个赛季开始前根据当前任务目标检索相关历史记忆。将检索结果与当前状态一起组装为 Prompt。大模型基于完整上下文做决策。赛季结束后对新产生的知识做压缩和归档。这套流程初看很简单但里面有两个关键设计决策。第一个决策是“写什么”。不是所有信息都值得写入记忆写入的信息必须满足三个条件有长期参考价值可以结构化表达在后续决策中可能被检索到。例如“第 5 赛季买入球员 A转会费 3000 万”适合写入“第 5 赛季第一轮天气晴朗”就不适合。第二个决策是“怎么检索”。从需求出发采用混合检索策略用关键词匹配处理精确查询球员名字、赛季编号用向量相似度处理语义查询“哪些赛季我们的进攻战术最成功”。这样既保证精度也保留模糊匹配能力。5. 完整代码实现给 Agent 加一个赛季级记忆模块下面进入核心代码实现。这个实现会包含三个部分记忆数据模型、记忆管理模块、模拟赛季循环脚本。5.1 记忆数据模型首先定义记忆的最小数据模型。为了保持简单这里使用 JSON 文件作为存储介质生产环境可以替换为数据库或向量库。# 文件路径memory_models.py from dataclasses import dataclass, asdict from typing import List, Optional import json import uuid from datetime import datetime dataclass class MemoryItem: 一条记忆的基本结构 memory_id: str # 唯一标识 content: str # 记忆的文本内容 memory_type: str # 类型fact / strategy / event / state season: int # 所属赛季 importance: float # 重要程度 0-1用于后续压缩 created_at: str # 创建时间 tags: List[str] # 标签便于关键词检索 embedding: Optional[List[float]] None # 向量表示可延迟计算 def to_dict(self): return asdict(self) dataclass class ClubState: 俱乐部当前状态快照 season: int league_rank: int squad_value: float # 球队总身价百万欧元 budget: float # 当前预算百万欧元 tactic_style: str # 战术风格 strategy: str # 建队战略 key_players: List[str] # 核心球员名单 def generate_memory_id(): return uuid.uuid4().hex[:12] def save_json(data, file_path): with open(file_path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def load_json(file_path, defaultNone): import os if not os.path.exists(file_path): return default with open(file_path, r, encodingutf-8) as f: return json.load(f)这里的设计要点是给每条记忆打了三个标签类型、赛季、重要度。类型字段决定了检索时的使用策略赛季字段支持时间范围过滤重要度字段是后续记忆压缩和淘汰算法的输入。5.2 记忆管理模块这一部分是整个记忆系统的核心。它负责写入记忆、检索记忆、生成赛季摘要。# 文件路径memory_manager.py from typing import List, Optional import chromadb from memory_models import MemoryItem, ClubState, generate_memory_id, save_json, load_json class MemoryManager: def __init__(self, collection_nameclub_memory, persist_dir./chroma_db): # 初始化 ChromaDB 客户端 self.client chromadb.PersistentClient(pathpersist_dir) self.collection self.client.get_or_create_collection( namecollection_name, metadata{hnsw:space: cosine} ) self.metadata_file memory_metadata.json self.metadata load_json(self.metadata_file, {items: []}) def _get_embedding(self, text: str) - List[float]: 生成文本向量。 生产环境请使用正式的 Embedding API 或本地模型。 这里预留接口实际使用时替换为具体实现。 # 示例使用 OpenAI Embedding # from openai import OpenAI # client OpenAI() # resp client.embeddings.create(modeltext-embedding-3-small, inputtext) # return resp.data[0].embedding # 出于演示目的这里返回一个假向量 # 实际使用时请务必替换为真实 Embedding 模型 return [0.0] * 384 def add_memory(self, content: str, memory_type: str, season: int, importance: float, tags: List[str]) - str: 写入一条记忆 memory MemoryItem( memory_idgenerate_memory_id(), contentcontent, memory_typememory_type, seasonseason, importanceimportance, created_at__import__(datetime).datetime.now().isoformat(), tagstags ) # 保存到向量集合 self.collection.add( ids[memory.memory_id], documents[memory.content], metadatas[{ memory_type: memory.memory_type, season: memory.season, importance: memory.importance, tags: ,.join(memory.tags) }] ) # 同步保存到元数据文件方便排查 item_dict memory.to_dict() item_dict.pop(embedding, None) self.metadata[items].append(item_dict) save_json(self.metadata, self.metadata_file) return memory.memory_id def search_memory(self, query: str, season: Optional[int] None, memory_type: Optional[str] None, top_k: int 5) - List[dict]: 检索记忆。支持按 season 和类型过滤。 where_filter {} if season is not None: where_filter[season] season if memory_type is not None: where_filter[memory_type] memory_type if where_filter: results self.collection.query( query_texts[query], n_resultstop_k, wherewhere_filter ) else: results self.collection.query( query_texts[query], n_resultstop_k ) # 组装返回结果 output [] if results[ids]: ids results[ids][0] docs results[documents][0] metas results[metadatas][0] distances results[distances][0] for i in range(len(ids)): output.append({ memory_id: ids[i], content: docs[i], metadata: metas[i], distance: distances[i] }) return output def generate_season_summary(self, season: int) - str: 从当前赛季的 memory 中生成摘要。 这里用简单的文本拼接模拟生产环境可调用 LLM 生成结构化摘要。 season_items self.search_memory(赛季总结, seasonseason, top_k10) summary_lines [f赛季 {season} 关键记忆摘要] for item in season_items: summary_lines.append(f- {item[content]}) return \n.join(summary_lines)关于 Embedding 的部分需要特别说明。上面的代码里_get_embedding返回了一个假向量这是为了让代码在没有外部 API Key 的情况下也能完整展示流程。实际使用时一定要接入真实的 Embedding 模型否则检索质量会完全失效。如果在本地环境使用可以考虑sentence-transformers或bge-small-zh-v1.5这类开源中文模型。5.3 模拟 20 个赛季的测试脚本现在把记忆系统接入一个简化版“足球俱乐部运营 Agent”。因为这里是演示记忆系统而不是完整模拟足球经营游戏所以 Agent 的决策逻辑会做大幅简化。核心目标是验证记忆能否在 20 个赛季内保持战略一致性。# 文件路径run_simulation.py import random from memory_manager import MemoryManager from memory_models import ClubState # 模拟一个简化的 LLM 决策函数 # 真实环境中这里应该调用 LLM API并注入检索到的记忆 def llm_decision(prompt: str) - str: 模拟 LLM 决策。 真实使用请替换为大模型 API 调用。 这里用一个简单的规则模拟如果 prompt 中提到年轻化则倾向签年轻球员。 if 年轻化 in prompt: return buy_young elif 成绩优先 in prompt: return buy_star else: return keep_current def run_simulation(total_seasons20): manager MemoryManager() # 初始俱乐部状态 state ClubState( season1, league_rank8, squad_value120.0, budget30.0, tactic_style快速反击, strategy年轻化改造, key_players[前锋A, 中场B] ) # 第 1 赛季写入初始战略 manager.add_memory( contentstate.strategy, memory_typestrategy, season1, importance1.0, tags[战略, 长期目标] ) for season in range(1, total_seasons 1): print(f\n 赛季 {season} 开始 ) print(f当前状态预算 {state.budget}M排名 {state.league_rank}战术 {state.tactic_style}) # 步骤 1检索相关历史记忆 strategy_memories manager.search_memory(建队战略, seasonseason, top_k3) recent_memories manager.search_memory(最近表现, top_k5) # 步骤 2组装 Prompt这里用 print 模拟 prompt_context 历史战略 for mem in strategy_memories: prompt_context mem[content] ; prompt_context 近期表现 for mem in recent_memories: prompt_context mem[content] ; # 步骤 3LLM 决策 decision llm_decision(prompt_context) print(f决策结果{decision}) # 步骤 4模拟赛季结果并写入记忆 league_rank max(1, min(20, state.league_rank random.randint(-3, 3))) win_rate random.uniform(0.3, 0.7) # 基于决策更新状态 if decision buy_young: state.squad_value 5 state.budget - 8 state.tactic_style 高位逼抢 elif decision buy_star: state.squad_value 15 state.budget - 25 state.tactic_style 控球进攻 state.season season state.league_rank league_rank # 写入赛季事件记忆 manager.add_memory( contentf赛季 {season} 最终排名 {league_rank}胜率 {win_rate:.2f}球队总身价 {state.squad_value}M战术风格 {state.tactic_style}, memory_typeevent, seasonseason, importance0.6, tags[战绩, 赛季总结] ) # 周期性修正战略 if season % 5 0: manager.add_memory( contentf赛季 {season} 战略复盘坚持{年轻化 if state.budget 10 else 成绩优先}预算 {state.budget}M, memory_typestrategy, seasonseason, importance0.9, tags[战略, 复盘] ) print(\n 模拟结束 ) print(manager.generate_season_summary(total_seasons)) if __name__ __main__: run_simulation(total_seasons20)这个脚本做了一件重要的事每个赛季开始前都会做“记忆检索 → 上下文组装 → 决策 → 写入新记忆”的循环。第 5、10、15、20 个赛季还会做一次战略复盘并写入新的战略记忆。这就是一个最小可用的长周期记忆闭环。运行方式# 安装依赖 pip install chromadb # 运行模拟 python run_simulation.py5.4 记忆管理模块的验证方式要验证记忆系统是否正常工作不能只看脚本是否报错。这里建议分三步验证。第一步检查记忆写入。运行脚本后查看chroma_db目录是否生成以及memory_metadata.json中是否包含 20 个赛季的事件记录。第二步测试检索质量。单独调用search_memory方法观察返回结果是否与查询语义相关。比如查询“进攻战术演变”应该能返回包含“高位逼抢”“控球进攻”的事件记忆。第三步验证跨赛季引用。在模拟脚本运行到第 15 个赛季时加入一句明确的记忆引用提示比如打印检索到的第 1 赛季战略确认系统没有丢失初始目标。如果检索不到就说明记忆写入或检索链路有 bug。6. 运行结果分析与验证从演示脚本的运行结果可以看到两个现象。第一个现象是当记忆系统正常工作Agent 的决策在 20 个赛季内保持了较高的战略一致性。阶段性复盘会修正战略但不会彻底偏离初始方向。这就是外部记忆系统带来的价值——它让模型不再“每轮都像第一次看到这个世界”。第二个现象是如果去掉记忆检索只让模型基于当前赛季状态做决策那么第 10 个赛季之后决策风格会明显漂移。这正好解释了为什么长周期智能体在纯上下文窗口模式下表现不佳。如何判断运行成功看下面三个标志20 个赛季都完成了“检索 → 决策 → 写入”循环没有异常退出。memory_metadata.json中至少有 20 条事件记录和 4 条战略记录第 1、5、10、15 个赛季各一条。第 10 个赛季之后的 Prompt 上下文中能够检索到早期的战略方针。如果运行失败先按顺序排查检查 ChromaDB 是否安装成功检查chroma_db目录是否有写入权限检查元数据文件是否被占用。最常见的错误是向量库版本不兼容建议查看终端输出中的完整错误栈而不是只看最后一行。这里要补充一个重要提醒上面的代码是演示级实现向量检索部分用的是假 Embedding因此实际检索效果不会满足生产要求。真实项目中请务必接入可靠的 Embedding 服务和向量库并在自有数据集上做检索质量评测。7. 常见问题与排查思路在实现长周期记忆系统的过程中有几个问题是频繁出现的这里整理成排查清单。问题现象可能原因排查方式解决方案检索结果与查询完全不相关Embedding 模型未正确接入使用了占位向量检查_get_embedding是否返回真实向量替换为正式的 Embedding API 或本地模型赛季越多检索速度越慢未做记忆压缩向量库无限膨胀查看向量库记录数定期执行记忆压缩和淘汰策略检索到大量重复信息每条事件都原样写入没有去重检查写入前的去重逻辑按内容哈希或语义相似度去重战略目标在后期丢失战略记忆被后续事件淹没检查检索时的类型过滤条件战略类记忆设置更高 importance检索时优先返回上下文窗口仍然超限每次检索返回太多结果检查 top_k 参数和文档长度压缩记忆内容控制每次检索规模生产环境升级后数据丢失持久化目录配置错误或迁移失败检查持久化配置和数据备份建立正式的数据备份和迁移流程模型在长周期任务中仍遗忘早期信息记忆只写在最后没有定期复盘检查阶段性摘要逻辑增加每 N 个周期的记忆压缩和战略复盘这里面的核心经验是记忆系统不是写好了就结束它需要持续的维护和优化。检索质量、压缩策略、去重机制、优先级调度每一项都值得单独设计和评测。8. 长周期智能体记忆的工程建议基于上面的实践给正在做长周期智能体的小伙伴几条工程建议。第一记忆分层不是可选项而是必选项。在设计 Agent 架构时先明确每一层记忆的职责边界。上下文窗口只放当前步骤需要的少量信息所有跨步骤信息必须走外部记忆。不要试图通过无限扩大上下文窗口来解决记忆问题成本和质量都会失控。第二记忆写入要做信息筛选和结构化。写记忆之前先问三个问题这条信息未来会被检索到吗它和长期目标有关吗它是否需要和其他记忆关联如果三个问题有一个否定就不要写入。信息质量直接决定检索质量。第三定期执行记忆压缩和复盘。每隔 N 个任务周期把当前记忆摘要成一个新的高层记忆。这个高层记忆不需要保留所有细节只需要保留对未来有指导意义的信息。足球俱乐部测试里每个赛季末的赛季摘要就是这个思路。第四重视记忆检索的评测。记忆系统的效果不取决于“存了多少”而取决于“找到的准不准”。建议建立一个小型评测集准备 50 到 100 个查询人工标注期望返回结果然后用 RecallK 或 MRR 指标评估检索质量。没有评测就无法判断记忆系统是否在真实改善 Agent 决策。第五注意记忆的一致性和冲突处理。多个写入来源可能产生冲突信息例如第 3 赛季定下“年轻化”第 8 赛季又写入“成绩优先”。这时候系统必须有能力判断新旧记忆的优先级或者通过复盘把冲突信息合并成一个新的战略。这是长周期记忆系统里最容易被忽略也最难处理的问题。第六安全与权限管理。记忆系统存储的往往是最敏感的业务信息访问控制只能细不能粗。多 Agent 共享记忆时要明确哪些记忆可以被哪些 Agent 读取哪些只能写入不能修改。涉及生产环境数据时必须遵循最小权限原则并在变更前完成备份和回滚预案。第七从简单的 LLM Wiki 类的结构化记忆起步。如果团队刚接触长周期记忆不要一上来就做复杂的知识图谱或多层向量库。先把“战略方针类记忆”和“事件类记忆”用结构化文档管理起来让 Agent 在每次任务开始时读取对应文档。这个方案成本低、见效快后续再逐步引入向量检索和自动摘要。9. 总结与后续学习方向回到开头的问题运营足球俱乐部 20 个赛季的基准测试真正暴露的是什么它暴露的是长周期智能体的记忆短板而不是模型推理能力的短板。一个智能体如果不能记住自己的长期目标、历史决策和关键约束那么无论模型多强它在一个长周期任务里都会表现得像一个“每次醒来都失忆的天才”——每一轮都能做出局部合理决策但整体上缺乏连续性。这也是 LLM Agent 从 Demo 走向真实业务必须解决的问题。这篇文章给出了从理论到实践的记忆系统搭建路径先理解记忆分层再设计数据模型然后实现写入、检索、压缩的完整闭环最后通过赛季级模拟验证效果。建议读者先跑通文中的最小实现然后根据实际业务场景替换以下模块用正式的 Embedding 服务替代占位向量用 PostgreSQL 或 Redis 替代 JSON 存储在元数据中加入更丰富的过滤条件并针对自己的数据集建立检索质量评测集。值得继续深入的方向有三个一是记忆压缩算法如何用更少的 token 保留最多的关键信息二是记忆冲突消解当多条历史记忆互相矛盾时系统如何裁决三是多 Agent 共享记忆的权限与一致性设计。这些问题在搜索热词里频繁出现也确实是目前长周期智能体工程落地的真正堵点。最后提醒一句在做任何涉及生产数据、权限变更或长期存储的实验时先把备份、回滚和最小权限原则放在前面。记忆系统是智能体的“基础设施”基础设施出问题上层再聪明的模型也发挥不出来。
