1. 这个挑战赛到底在比什么Agent Memory Challenge 2026 第二轮开放报名了。如果你最近在关注 AI Agent 方向尤其是 Coding Agent 和 Multimodal 这两个赛道大概率已经刷到过这个消息。但很多人看到“Memory Challenge”第一反应是是不是又搞个向量数据库检索比赛是不是把长上下文塞进去就完事了如果你这么想那基本第一轮就被筛掉了。我先把话说在前面这个挑战赛的核心不是“谁能记住更多”而是“谁能在正确的时刻调用正确的记忆并且用正确的形式把它喂给模型”。听起来像绕口令但这就是 Agent Memory 的本质问题。你可以把它理解成一个超级助理它不需要记住你三年前说过什么废话但它必须在你今天写代码卡住的时候立刻想起你上周在类似场景下踩过的坑并且用你当时能理解的方式提醒你。这就是为什么今年的关键词里出现了 Coding 和 Multimodal。Coding 场景天然需要记忆——一个项目动辄几十个文件、几百次修改Agent 如果每次对话都从零开始那它就是个高级自动补全谈不上 Agent。Multimodal 则把记忆的维度从纯文本扩展到了图像、截图、UI 布局、甚至视频帧。你给 Agent 看一张报错截图它得记住这个报错的视觉特征下次遇到类似界面时主动预警。适合谁来参加我观察下来三类人最占优势第一类是有实际 Agent 开发经验的工程师哪怕你只是用 LangChain 或类似框架搭过一个小助手第二类是对 RAG 和向量检索有深入理解的人因为记忆的底层离不开检索第三类是做过 Multimodal 应用的人比如图文匹配、跨模态检索。如果你只是看过几篇论文没有动过手那这个比赛会让你非常痛苦因为它的评测指标极其务实。2. 记忆系统的架构设计思路2.1 为什么不能只靠长上下文很多人第一反应是现在模型上下文都到 128K 甚至 1M 了直接把所有历史对话塞进去不就行了我实测过这条路在 Coding 场景下走不通。原因有三个第一成本。你每轮对话都塞 10 万 token 的历史API 账单会教你做人。第二噪声。历史里 90% 的内容和当前任务无关模型注意力被稀释后反而容易忽略关键信息。第三延迟。长上下文的推理延迟是线性增长的Agent 需要快速响应用户等不起。所以记忆系统的第一原则是分层存储按需召回。我一般把记忆分成三层工作记忆、情景记忆、语义记忆。工作记忆就是当前对话窗口只保留最近几轮和当前任务直接相关的内容。情景记忆是具体的事件记录比如“某年某月某日用户让我改了一个 React 组件的状态管理逻辑从 useState 换成了 useReducer”。语义记忆是抽象出来的规律比如“这个用户偏好函数式组件不喜欢 class 组件”。这三层的召回策略完全不同。工作记忆直接拼进 prompt情景记忆通过向量检索召回语义记忆则通过规则或轻量模型判断是否触发。你如果能把这三层打通就已经超过 80% 的参赛者了。2.2 记忆的写入策略比读取更重要大部分人把精力花在“怎么查记忆”上但真正拉开差距的是“怎么写记忆”。我见过太多项目记忆库越跑越乱最后检索出来的全是垃圾。写入策略的核心是去重、抽象、打标签。去重不是简单的文本相似度而是语义去重。比如用户今天说“把按钮颜色改成蓝色”明天说“按钮色调调成蓝色系”这两条应该合并成一条记忆而不是存两条。抽象是指把具体操作提炼成模式比如“用户多次要求修改 UI 颜色”这比存十次具体颜色修改更有价值。打标签则是为了后续检索时能快速过滤比如给记忆打上coding、ui、react、preference等标签。我自己的做法是每次对话结束后用一个轻量模型比如 7B 级别的对本次对话做摘要提取出“事实”、“偏好”、“待办”三类信息分别写入不同的记忆库。事实类走向量检索偏好类走规则匹配待办类走状态机。这套组合拳打下来召回准确率能提升一大截。2.3 Multimodal 记忆的特殊处理Multimodal 记忆的难点在于图像和文本不在同一个语义空间里。你不能直接把一张截图扔进文本向量库那样检索出来的结果会非常离谱。我的经验是先对齐再存储。对齐的方法有两种。第一种是用 CLIP 这类跨模态模型把图像和文本映射到同一个向量空间然后统一检索。第二种是先对图像做描述生成把图像转成文本再存储。第一种方法检索精度高但需要额外的模型推理第二种方法实现简单但会丢失视觉细节。我一般会混合使用关键截图用 CLIP 对齐存储普通截图用描述文本存储。还有一个坑Multimodal 记忆的时效性。UI 截图变化很快今天这个按钮在左边明天可能就移到右边了。所以图像记忆必须带时间戳并且检索时要优先返回最近的版本。我试过不加时间衰减结果 Agent 总是根据旧截图给出错误建议用户直接骂街。3. Coding 场景下的记忆实战3.1 代码记忆的粒度控制Coding 场景的记忆粒度是个大学问。太粗了没用比如“用户写了一个函数”这等于没说。太细了也没用比如“用户在第 37 行加了一个分号”这属于噪声。我的经验是以函数或组件为最小记忆单元。具体来说当用户修改了一个函数我会记录函数名、所在文件、修改前后的 diff、修改原因如果用户说了、相关依赖。这样下次用户提到这个函数时Agent 能立刻回忆起上下文。如果用户只是改了一个变量名那就不值得单独存一条记忆合并到最近的函数记忆里就行。还有一个技巧代码记忆要带版本号。同一个函数可能被改过五次你不能只存最后一次。我一般会保留最近三次的修改记录更早的做摘要合并。这样既能追溯历史又不会让记忆库爆炸。3.2 跨文件依赖的记忆关联Coding 场景最头疼的是跨文件依赖。用户改了一个工具函数结果三个调用方都挂了。如果 Agent 能记住这个依赖关系就能提前预警。我的做法是在写入记忆时自动解析 AST提取函数调用关系构建一张轻量级的依赖图。这张图不需要很精确粗粒度的文件级依赖就够了。比如utils.js被api.js和ui.js引用了那当utils.js发生变更时Agent 就应该提醒用户检查另外两个文件。我实测下来这张图能让 Agent 的“主动提醒”准确率提升 40% 以上。构建依赖图的工具有很多JavaScript 可以用madgePython 可以用pydeps通用的话可以用 tree-sitter 自己解析。我建议不要追求完美先跑通一个粗糙版本然后在比赛中逐步优化。3.3 用户编码偏好的记忆每个开发者都有自己的编码习惯。有人喜欢用const有人喜欢用let有人喜欢写长函数有人喜欢拆成小函数。如果 Agent 能记住这些偏好生成的代码就会更贴合用户风格用户满意度会大幅提升。记忆偏好的方法是在每次代码生成后记录用户的修改行为。如果用户把let改成了const那说明他偏好const。如果用户把一个长函数拆成了三个小函数那说明他偏好小函数。这些信号积累多了就能形成一个偏好画像。我一般会用简单的计数器来维护偏好权重。比如const偏好权重是 0.8let是 0.2那生成代码时就优先用const。权重会随着用户行为动态更新时间久了画像会越来越准。这个思路不复杂但效果非常好强烈建议你试试。4. Multimodal 记忆的落地细节4.1 截图记忆的压缩与检索Multimodal 场景下截图是最常见的输入。但截图文件很大直接存储会迅速撑爆记忆库。我的做法是先压缩再提取特征最后存储特征向量和缩略图。压缩用 WebP 格式质量调到 60% 左右肉眼几乎看不出差别但体积能减少 70%。特征提取用 CLIP 的 ViT-B/32 模型输出 512 维向量。缩略图存 256x256 就够了用于快速预览。检索时先用向量做粗筛再用缩略图做精排。这里有个坑CLIP 对 UI 截图的区分度不够。两个不同页面的截图向量相似度可能高达 0.95。我试过用 UI 专用的模型比如基于 LayoutLM 微调的版本效果会好很多。如果比赛允许用外部模型建议优先考虑 UI 领域的预训练模型。4.2 视频帧记忆的采样策略如果输入是视频比如用户录屏演示了一个 bug那记忆系统需要从视频中提取关键帧。全量存储不现实必须采样。我的采样策略是基于画面变化率采样。具体来说计算相邻帧的差异度差异度超过阈值的帧才保留。这样既能抓住关键操作又能过滤掉静止画面。阈值一般设在 0.15 到 0.25 之间太低会保留太多冗余帧太高会漏掉关键帧。我实测下来0.2 是个不错的起点。采样后的帧还要做时间对齐。比如用户在第 10 秒点击了按钮第 12 秒出现了报错那这两帧应该关联存储检索时一起返回。这样 Agent 才能理解“点击按钮导致报错”这个因果关系。4.3 跨模态检索的融合排序Multimodal 记忆检索的最终难题是如何把文本检索结果和图像检索结果融合排序。你不能简单地把两个分数相加因为它们的量纲不同。我的做法是先归一化再加权融合。文本检索分数用余弦相似度范围是 -1 到 1归一化到 0 到 1。图像检索分数同样处理。然后根据查询类型动态调整权重如果查询是纯文本文本权重 0.8图像权重 0.2如果查询包含图像文本权重 0.4图像权重 0.6。这个权重不是拍脑袋定的而是根据验证集上的表现调出来的。还有一个技巧用交叉编码器做精排。粗排召回 top-50 后用一个小的交叉编码器对每个候选做相关性打分再取 top-5 返回。这样能显著提升检索精度代价是增加一点延迟。如果比赛对延迟不敏感强烈建议加上这一步。5. 评测指标与优化方向5.1 记忆召回率与准确率的平衡比赛评测一般会看两个指标召回率和准确率。召回率是指“该记住的是否记住了”准确率是指“记住的是否都是有用的”。这两个指标天然矛盾你存得越多召回率越高但准确率越低你存得越少准确率越高但召回率越低。我的调参经验是先保召回再提准确。因为召回率低意味着 Agent 会“失忆”用户体验极差准确率低只是偶尔给出无关建议用户还能忍受。所以初期可以把检索阈值调低多召回一些候选然后用精排模型过滤。等召回率稳定在 90% 以上后再逐步提高阈值优化准确率。5.2 记忆更新的时效性优化记忆不是一成不变的。用户今天说“我喜欢用 TypeScript”明天可能说“这个项目用 JavaScript 就行”。如果 Agent 还按 TypeScript 生成代码那就尴尬了。所以记忆必须支持更新和衰减。我的做法是给每条记忆加一个时间衰减因子。检索时分数乘以衰减因子越旧的记忆分数越低。衰减因子一般用指数衰减半衰期设在 7 天左右。这样既能保留长期偏好又能快速适应短期变化。对于明确被推翻的记忆比如用户说“之前那个方案不要了”那就直接标记为失效检索时过滤掉。不要删除因为可能还需要追溯历史。标记失效比物理删除更安全。5.3 多轮对话中的记忆一致性多轮对话最容易出现的问题是记忆不一致。比如第一轮 Agent 说“你上次用的是 React”第二轮又说“你上次用的是 Vue”。这种低级错误会严重损害用户信任。解决方法是在生成回复前先做一次记忆一致性检查。把本轮要引用的记忆和最近几轮引用过的记忆做对比如果发现冲突就触发澄清流程。比如 Agent 可以问“我注意到你之前提到过 React 和 Vue这次是以哪个为准”这样既避免了错误又显得 Agent 很细心。这个检查逻辑不复杂但很多参赛者会忽略。我建议你在系统里加一个轻量的一致性校验模块成本不高但效果立竿见影。6. 常见问题与排查技巧6.1 记忆检索返回无关结果这是最常见的问题。原因通常有三个向量模型不适合当前领域、检索阈值太低、记忆库噪声太多。排查顺序是先看召回结果如果全是无关的那是模型问题如果有一部分相关但排序靠后那是排序问题如果相关结果根本没召回那是写入时就没存好。我的解决套路是换一个领域适配的向量模型比如 Coding 场景用codebertMultimodal 场景用clip。然后提高检索阈值宁可少召回也不要召回垃圾。最后定期清理记忆库把低质量的记忆标记失效。6.2 记忆写入重复率高重复写入会导致记忆库膨胀检索效率下降。排查方法是统计最近 100 条记忆的相似度分布如果超过 30% 的记忆相似度高于 0.9那就是去重没做好。解决方法是在写入前先做一次检索如果找到相似度高于阈值的已有记忆就合并而不是新增。合并策略可以是取并集也可以是取最新版本。我一般用最新版本覆盖旧版本同时保留旧版本的时间戳用于追溯。6.3 Multimodal 检索跨模态对齐差文本查图像或图像查文本时结果不理想。这通常是跨模态模型的问题。排查方法是单独测试文本查文本和图像查图像如果这两个都正常那就是跨模态对齐的问题。解决方法是换一个更强的跨模态模型或者在现有模型上做微调。如果比赛不允许微调那就用“描述生成文本检索”的降级方案。虽然会丢失一些视觉细节但至少能跑通。6.4 记忆更新后旧记忆仍被召回这是时效性问题。排查方法是检查检索时是否应用了时间衰减因子以及失效标记是否生效。如果衰减因子没加那就加上如果失效标记没生效那就检查过滤逻辑。我的经验是时间衰减因子一定要加而且半衰期要根据场景调整。Coding 场景变化快半衰期设 3 天个人偏好变化慢半衰期设 30 天。不要一刀切。问题类型典型表现排查方向解决手段检索无关返回结果与查询无关模型适配性、阈值、噪声换模型、调阈值、清库写入重复记忆库膨胀快去重逻辑、相似度阈值写入前检索、合并策略跨模态差文查图效果差跨模态模型、对齐方式换模型、微调、降级方案更新失效旧记忆仍被召回衰减因子、失效标记加衰减、加过滤7. 报名后的准备建议如果你决定报名第二轮我建议你先别急着写代码。花两天时间做三件事第一把第一轮的公开评测报告仔细读一遍看看高分方案和低分方案的差距在哪里第二搭一个最小可用的记忆系统跑通“写入-检索-更新”的完整链路第三准备一个 Coding 场景和一个 Multimodal 场景的测试用例用来验证你的系统。工具选型上向量库我推荐 Qdrant 或 Milvus轻量且性能好。嵌入模型 Coding 场景用codebert或starcoder的嵌入层Multimodal 场景用clip或blip。框架可以用 LangChain 或 LlamaIndex但不要过度依赖核心逻辑自己写更可控。最后分享一个我踩过的坑不要试图一次性把所有功能都做完。第一轮很多队伍就是贪多结果每个模块都半成品。我的策略是先做一个能跑通的窄版本比如只支持文本记忆只做 Coding 场景。等这个版本稳定了再逐步加 Multimodal 和高级特性。这样至少能保证有一个可提交的版本而不是最后一天还在调 bug。这个比赛后续还可以这样扩展把记忆系统做成一个独立的微服务通过 API 给多个 Agent 共享。这样不仅能用于比赛还能直接落地到实际项目中。我目前就在做类似的事情效果比预期好很多。