开放基准

Agent Memory Leaderboard

在统一评测流程下，对文本、多模态和编程智能体记忆系统进行比较的公开基准平台。

Leaderboard Preview

第一期 · 2026 年 8 月 12 日发布

Benchmark Tracks

Each track keeps its own result table and detailed metric breakdown.

Textual Memory

Long-context, persona, script, and conversation-memory benchmarks.

Multimodal Memory

Memory retrieval and generation over image-rich or multimodal tasks.

Coding Agent Memory

Agent memory support for coding tasks and repository-context recall.

Evaluation Flow

Open-source methods and commercial products both use participant-hosted Add/Search APIs. AML does not deploy repository-only submissions.

1

Deploy Add/Search APIs

Operate publicly reachable Add/Search endpoints and submit the fixed API version for review.

2

Run a smoke test

Use the issued key to verify the synchronous Add/Search flow.

3

Submit a formal evaluation

After smoke passes, submit the full scored evaluation.

Explore the Platform

Use the product pages to inspect rankings, run evaluations, and prepare an integration.

01

Leaderboard

Public ranking with filters, dataset columns, and score bars.

02

Evaluation

Create eval jobs, watch progress, and inspect private results.

03

Participation Guide

Eligibility, submission routes, required materials, timelines, rewards, and publication rules.

04

Documentation

User guide, evaluation workflow, API contract, security, and result publication.

05

Guide

Add/search API contract, request fields, polling, and response schemas.

.blog-filters{display:none}English · 中文

来自 AML 团队

AML 官方博客

来自 Agent Memory Leaderboard 团队的研究、技术实践与最新动态。

一起探索智能体记忆。

← 返回全部文章

Agent 记忆挑战赛正式启动：首个面向记忆系统的开放锦标赛

第一期公告2026年7月31日9 分钟阅读

记忆之巅排行榜

随着 Agent 从一次性问答工具走向长期协作系统，长期记忆正在成为决定其可靠性、个性化能力与工程可用性的关键基础设施。

2026 年 7 月 29 日，由来自国内外二十余家高校、科研机构与开源社区的研究者和团队联合发起的 Agent Memory Leaderboard（AML）正式发布，旨在为记忆系统建立一套统一、开放、可复现、可长期运行的评测协议与公开榜单。

过去一年，Agent Memory 方法与产品快速涌现，但不同系统往往使用不同数据集、回答模型和评分规则，导致结果难以直接比较。一个系统在单一数据集上的高分，未必能说明其整体记忆能力；同一个记忆方法接入不同回答模型后，端到端表现也可能产生明显差异。由此得到的成绩，往往混合了记忆系统、回答模型和裁判规则等多方面因素的影响，难以准确衡量记忆系统本身的贡献。

在这一背景下，AML 并不试图再造一个单点 benchmark，而是将已有公开基准、平台私有测试集、标准化接入协议、统一回答流程、评审机制和公榜治理整合为一套长期运行的开放评测体系。

围绕“全面、统一、可比”的评测目标，平台形成了三项核心设计：

其一，构建覆盖文本记忆与代码记忆的多源数据体系，并以统一流程、统一回答模型和统一评审机制保障评测公平性；

其二，重构记忆能力维度，将总分拆解为分能力项的性能表现，帮助识别记忆系统在事实召回、多跳整合、时序理解、记忆治理、安全隐私等环节的真实性能差异；

其三，提供统一记忆方案接入协议，降低记忆方案的参评成本，使榜单能够持续稳定运行、不断追踪和吸纳新系统。

统一评测：整合多源数据，统一评测全流程

记忆系统评测要具备公信力，关键在于两点：数据覆盖是否全面，评测条件是否一致。AML 覆盖文本记忆与代码记忆场景下多源评测任务，并统一接口、回答流程和评审机制，减少单一数据集与外部变量对结果的影响，使成绩更能反映记忆系统本身的能力。

在文本记忆评测方面，AML 整合了 PersonaMem、LoCoMo-Refined、CLBench、BEAM、LongMemEval、ScriptMem 等 10余个业界主流的数据集，覆盖长对话、跨会话历史、个性化偏好、规则执行、超长上下文和剧本式连续事件等场景，合计超过 1500 个对话与任务样本、约 1.5 亿字符的长程历史、近 5000 道评测题目。更广的数据覆盖面能够降低单一场景优化带来的偶然优势，使评测结果更接近系统在真实复杂场景中的整体表现。

除文本记忆外，AML 将面向代码任务的长期记忆能力纳入评测体系。现有代码 Agent 评测通常将每个任务视为独立事件，而较少评估记忆系统能否检索并复用历史工程经验，以及这种经验复用能否提升 Agent 解决当前任务的能力。

在真实软件开发场景中，开发者解决问题时往往需要参考历史 Pull Request、既有架构约定、过往修复方案和项目演化记录。

AML 引入了一套面向长期工程经验的检索与复用能力评估的数据集。该代码评测数据集（暂未发布）由高校研究团队基于真实 GitHub 仓库中的软件工程任务构建并提供，覆盖 12 个仓库、150 个基础任务。对于每个基础任务，评测数据集中收集同一仓库中创建时间早于该任务的历史 Pull Request，形成 1290 个经过细粒度标注的历史任务。

数据在设计上包含三项关键机制：首先，通过标注历史任务与目标任务之间的强相关、弱相关和无关关系，支持对系统抗噪能力的细粒度评估；其次，通过严格的时间约束，确保所有候选历史任务均产生于目标任务之前，从而避免未来信息泄漏；最后，通过构建三种具有不同历史规模和噪声密度的记忆环境，模拟不同真实软件开发场景，从而支持对记忆系统检索、筛选与复用历史工程经验能力的评测。

在评测流程上，AML 将参评系统的职责限定为 Add 和 Search 两类接口。Add 负责写入记忆，Search 负责返回与问题相关的记忆证据；最终回答由平台统一的 Answer 模型生成，评分由平台统一的 Eval 流程完成。通过固定回答模型、评分流程和聚合规则等关键变量，平台能够更大程度地将成绩差异归因于记忆系统本身。

评分环节则采用多评审评分系统（Multi-Agent Judging System）。平台会根据题目来源、能力标签和答案类型，将题目路由到相应评审流程：事实召回类题目检查关键事实是否命中，多跳类题目检查分散证据是否被正确整合，时序类题目检查新旧状态判断是否准确，安全类题目检查系统是否守住证据与隐私边界；代码任务则以测试用例通过情况进行客观判定。

平台还会统一封装模型、参数、日志和聚合规则，并使用人工标注样本校准评分规则，保留检索证据、平台答案和评审记录，以提升评测结果的可解释性与可追溯性。

因此，AML 的统一评测并不是简单扩大测试集规模，而是通过“全面数据覆盖、固定评测链路、多评审评分机制”，把不同记忆系统放到同一把尺子下比较。

能力剖面：重构能力维度，呈现系统真实差异

单一总分很难解释记忆系统的真实差异。为了解决“排名可见、原因不可见”的问题，AML 将不同来源的数据重新映射到统一能力维度中，把评测结果从单一分数扩展为可解释的能力剖面。

现有公开数据集本身具有重要价值，但其任务设计和能力标签并不统一。有的数据集强调长程事实召回，有的强调偏好与个性化，有的关注时间线，有的侧重规则执行或拒答安全。如果只是将这些数据集简单拼接，最终得到的往往是混合分数，难以为研究迭代和产品选型提供清晰依据。

为此，AML 对收录题目的能力标签进行了人工重构，将原本分散在不同数据集中的题目映射到同一套能力维度体系。

这套维度沿着记忆使用链路展开：一条信息要成为可用记忆，首先要被精准召回，其次要被正确理解，最后还要在合适边界内稳定使用。基于这一链路，平台将文本记忆归并为七类能力：显式事实召回、关系与多跳组合、时间与事件序列、记忆治理、个性化与关怀、规则与流程执行、认识论安全与隐私。

代码记忆同样纳入这套能力坐标，重点评估系统能否从历史工程记录中检索、筛选并复用有效经验，主要包括两类任务：

Debug Memory：考察记忆系统能否从历史记录中检索出相似问题的修复经验，帮 Agent 复用定位思路、修改方案和验证方法；
Development Memory：考察能否从历史开发记录中提取架构设计与既有工程模式，帮 Agent 生成符合项目设计的修改。

经过这一重构，LoCoMo、BEAM、LongMemEval 等不同来源的数据不再只是并列出现，而是被组织进同一套能力坐标。参评者最终得到的也不只是一个名次，而是一张能力剖面图：它能够呈现系统在事实召回、多跳整合、时序理解、记忆治理、个性化、安全隐私等维度上的具体表现。

这意味着，AML 提供的不只是一个排行榜，而是一套诊断工具。对研究者而言，能力剖面能够定位方法短板；对产品团队而言，它可以帮助判断系统是否适合具体应用场景；对行业用户而言，它让“记忆能力强”从笼统宣传变成可核验的分项证据。

低门槛统一接入：支撑开放榜单长期运行

一个评测平台要成为长期基础设施，关键不只是数据和评分规则，还要让不同类型的系统能够持续接入、反复复现、长期比较。过去许多评测难以延续，一个重要原因在于接入成本高、系统形态差异大、版本记录不完整，导致新方法和商业产品很难在同一套规则下持续积累结果。

AML 因此将参评系统的技术要求压缩为 Add 和 Search 两类核心接口。参评方只需负责记忆写入与检索，回答生成、评分、结果聚合和评测编排均由平台统一完成。这一协议设计使不同类型的参评方都能进入同一套评测体系。商业产品可以通过稳定 API 参评，无需公开内部实现；开源方法则提交代码、运行方式和版本材料，由平台按规则复现或托管运行。对参评方而言，接入重点从搭建完整评测环境转为提供稳定、规范的记忆写入与检索能力。

统一接口也使榜单能够持续吸纳新系统。每条成绩与系统版本绑定，评测日志与结果长期可追溯；不同时间加入的系统，也可以在同一套条件下进行比较。在既有基准之外，AML 还接受社区贡献的新 Benchmark——平台鼓励大家提交与现有评测形成互补、具备区分度的完整测试集，经审核后可纳入平台评测体系。

因此，AML 统一了评测入口、执行流程和治理规则，既保留了不同记忆系统的创新空间，也为开放榜单的长期运行提供了制度基础。

首届 Agent 记忆挑战赛 2026

由 Agent Memory Leaderboard 平台主办的首届 Agent 记忆挑战赛已于 2026 年 7 月 29 日启动，本次挑战赛面向全球研究者、开源项目维护者和商业产品团队征集参评系统，旨在为社区提供第一批可比较、可复核的公开评测结果。

赛事榜单分类

开源方法榜单：面向开源研究方法，成绩与代码、配置和复现材料绑定，参与排名与奖励结算；
商业产品榜单：面向以稳定 API 提供的商业记忆产品，独立排名，为行业提供选型参照。

研究者、开源项目维护者、产品团队和正在做技术选型的开发者，都可以提交系统参与评测。不设组队要求。

参赛流程说明

报名申请：填写报名表单，审核通过后获取评测 API Key；
接口接入：按平台协议提供公网可访问的 Add／Search 接口；
提交评测：通过 smoke 兼容性测试确认链路后，提交正式评测任务；
复核上榜：评测结果经复核后进入公开榜单。

平台统一承担 Answer、Eval 与评测编排成本；参赛方承担自身 API、数据库、带宽和计算成本，参赛者无需自行搭建评测环境。

奖励设置

上榜奖励（开源方法榜，每期结算）

第 1—3 名：ChatGPT Pro 月度会员（价值 ¥1,400）

第 4—10 名：ChatGPT Plus 月度会员（价值 ¥140）

社区贡献计划（满足任一条件即可入选，瓜分百亿级 Token 奖励）

前 50 位完成有效提交的参赛者，每人获得价值 50 元人民币的 API 额度；

每成功邀请 3 位新参赛者完成有效提交，同样获得价值 50 元人民币的 API 额度。

我们也欢迎贡献有挑战性的测试样本，提交 3 个有挑战性的测试数据，同样获得价值 50 元人民币的 API 额度！

*全部奖励以账号会员与 API 额度形式发放，名额有限，发完为止，最终规则以赛事官网规则页为准。

赛事日程与联系方式

报名开放：2026 年 7 月 29 日
提交截止：2026 年 8 月 7 日
放榜日期：2026 年 8 月中旬

赛制：本次为首届赛事。Agent Memory Leaderboard 长期运行，后续赛事另行公告
报名入口：
https://agentmemories.ai/competition/
👇扫码下图二维码进入赛事报名页面，或者文末【阅读原文】

赛事仓库：

https://github.com/AML-memory/agent-memory-leaderboard

（含接口协议、提交指南与接入示例）

答疑邮箱：

[email protected]

记忆技术要往前走，需要一套大家认可、任何人都能核验的度量衡。

8 月中旬，我们榜单见。👋

关注"记忆之巅排行榜"公众号（Agent Memory Leaderboard 官方中文账号），第一时间获取放榜结果与下期赛事！

公开排名

智能体记忆排行榜

公开排名按赛道区分。使用排行榜内的选择器切换表格，避免混合不同的指标维度。

历届比赛

Leaderboard

第一期 · 2026 年 8 月 12 日发布

公开排名

智能体记忆排行榜

公开排名按赛道区分。使用排行榜内的选择器切换表格，避免混合不同的指标维度。

历届比赛

Leaderboard

第一期 · 2026 年 8 月 12 日发布

公开排名

智能体记忆排行榜

公开排名按赛道区分。使用排行榜内的选择器切换表格，避免混合不同的指标维度。

历届比赛

Leaderboard

第一期 · 2026 年 8 月 12 日发布

统一评测

运行评测

材料提交已截止。已提交 API 端点的任务将由后台陆续安排 Full。请登录查看任务进度、按原规则断点续跑及查看私有结果。正式评测截止为 2026 年 11 月 4 日 23:59（UTC+8），随后约两天视实际情况尽可能处理未完成任务及异常重试，请保持 API 可用。

Create Eval Job

Choose a bound version. Use Run label to distinguish repeated evaluations of the same version.

Evaluation track System name Version name Mode Max add concurrency Search concurrency Run label

Current Job

Live job status and progress.

No job yet.

Private Results

Private scores stay scoped to the current leaderboard key. Admin runs remain separate from external review candidates.

PARTICIPATION GUIDE · 2026

第二期 Agent 记忆挑战赛参赛说明

Agent Memory Challenge 是 Agent Memory Leaderboard 的第二期公开评测活动，面向全球研究者、开源项目维护者和商业产品团队开放。参赛系统负责 Add 与 Search，平台统一完成 Answer、Eval、结果复核与公榜。

返回赛事页面

一分钟了解第二期赛事

参赛免费，不设组队要求。参赛方承担自身 API、数据库、带宽和计算成本，平台承担统一 Answer、Eval 与评测编排成本。

赛事开放

2026 年 9 月 20 日 00:00

材料截止

2026 年 10 月 31 日 23:59（UTC+8）

正式评测截止

2026 年 11 月 4 日 23:59（UTC+8）

正式榜单

预计 2026 年 11 月 19 日

评测类型

文本、代码与多模态记忆

第一步：选择评测类型

评测类型决定系统接受什么任务；参赛组别决定结果展示在哪个榜单。两者是互相独立的两个维度。

评测类型	主要评测内容	可选参赛组别	第二期时间
文本记忆	长对话、跨会话历史、事实、多跳关系、时间事件、个性化、规则与记忆治理，并纳入 Streaming 持续记忆能力。	开源方法榜 / 商业产品榜	10 月 31 日 23:59 材料截止
代码记忆	Agent 对同仓库历史工程经验的检索、筛选和复用能力，分别评测 relevant 与 noisy 条件。	开源方法榜 / 商业产品榜	10 月 31 日 23:59 材料截止
多模态记忆	图文记忆的写入、检索与证据使用能力，支持文本和 Base64 图片有序内容数组。	开源方法榜 / 商业产品榜	10 月 31 日 23:59 材料截止

第二步：部署并提交接口

第二期所有参赛组别都必须由参赛方自行部署 Add / Search API。Eval Key 是在线接口申请审核通过后获得的评测凭证。

开源方法 · API

自行部署 Add / Search API

提交固定版本、Add / Search 地址、鉴权方式和运行说明；公开仓库作为开放性与署名材料，不能替代在线接口。

商业 · API

提供稳定的产品 API

提交固定产品版本、Add / Search 地址、鉴权和容量说明。无需公开内部实现，审核通过后获得 Eval Key，结果进入商业产品榜。

统一接入要求

开源方法榜和商业产品榜都只通过参赛方自托管的 Add / Search API 接入。第二期不接受只提交 GitHub 仓库、Docker 镜像或启动说明并由 AML 代为部署。开源材料仍用于开放性、署名和复现审核。

第三步：准备提交材料

请在提交申请前固定参评版本。正式 Full 评测受理后，不得因结果不理想更换版本或撤回。

共同材料

所有参赛者

系统名称与版本、联系人、机构或团队、拟参评类型、方法或产品说明、允许公开展示的信息，以及完整的提交说明。

开源方法

接口与开放材料

已部署的 Add / Search API、鉴权与容量声明，以及公开仓库、固定 commit、原始工作引用和方法改动说明。

商业产品

接口与运行材料

固定产品版本、Add / Search API、鉴权方式、评测专用密钥、容量限制、超时与限流说明。

从申请到上榜

1

提交评测申请

选择评测类型和参赛组别，提交已部署的 Add / Search API、系统版本与完整材料。

2

完成接入

平台审核在线接口和提交材料，通过后签发 Eval Key；AML 不代为部署参赛系统。

3

Smoke 与 Full

先验证 Add / Search、鉴权和端到端链路，再运行第二期正式 Full 评测。

4

复核与公榜

平台复核版本、结果和合规状态，通过后发布到对应公开榜单。

Eval Key 与 Memory System Key

两个 Key 的签发方和用途不同，请勿将它们放入公开仓库、URL、截图、邮件正文或群聊。

凭证	谁提供	用途	谁需要
Eval Key / Leaderboard Key	Agent Memory Leaderboard	验证参赛身份、运行评测并查看私有结果。	提交自托管 Add / Search API 并审核通过的开源方法榜及商业产品榜参赛者。
Memory System Key	参赛方	供平台访问参赛系统的 Add / Search API。	接口启用鉴权时需要；无鉴权接口无需提供。

奖励设置

第二届 Agent Memory Challenge 面向文本、代码与多模态三个赛道设置合计人民币 150,000 元奖金池。奖金仅面向符合赛事规则并通过审核的开源方法榜参赛团队，商业产品榜不参与奖金评选。

一等奖

每个赛道 1 名

奖金人民币 20,000 元。文本、代码与多模态三个赛道分别评选。

二等奖与三等奖

每个赛道共 5 名

二等奖 2 名，每名人民币 8,000 元；三等奖 3 名，每名人民币 3,000 元。

最佳技术创新奖

每个赛道 1 名

奖金人民币 5,000 元。每个赛道奖金合计 50,000 元，三个赛道合计 150,000 元。

什么是有效提交？

材料完整

参赛身份、系统版本和所需材料均完整、真实且可核验。

Smoke 通过

Add / Search、鉴权和端到端链路符合现行接入协议。

Full 完成

正式评测任务和所需评测项成功完成，没有缺失或重复结果。

版本一致

正式评测使用的代码、镜像或 API 与申报版本保持一致。

复核通过

版本、结果与合规状态通过主办方审核，方计为一次有效提交。

参赛基本要求

1

只返回记忆证据

Search 不得直接生成最终答案，也不得把答案伪装为记忆记录。

2

保持样本隔离

不得跨 user_id、任务、样本或团队共享和检索评测记忆。

3

披露来源与改动

复用论文、仓库或代码时，必须注明原作者、技术报告和全部方法改动。

4

不得操纵评测

严禁硬编码、数据泄漏、提示词注入、人工实时答题、结果操纵和恶意刷榜。

联系与入口

提交申请前请先阅读 API 接入指南并准备完整材料。报名与评测问题可发送至 [email protected]。

赛事仓库

PARTICIPATION GUIDE · 2026

Cycle 2 Agent Memory Challenge Participation Guide

Agent Memory Challenge is the second public evaluation cycle of Agent Memory Leaderboard. It is open to researchers, open-source maintainers, and commercial product teams worldwide. Participants provide Add and Search; the platform runs Answer, Eval, result review, and leaderboard publication.

Back to Competition

Cycle 2 at a glance

Participation is free, with no team-size requirement. Participants cover the cost of their own APIs, databases, bandwidth, and compute; the platform covers unified Answer, Eval, and evaluation orchestration.

Competition opens

September 20, 2026 · 00:00 (UTC+8)

Materials deadline

October 31, 2026 · 23:59 (UTC+8)

Evaluation closes

November 4, 2026 · 23:59 (UTC+8)

Official leaderboard

Expected November 19, 2026

Evaluation types

Textual, Coding, and Multimodal Memory

Step 1: Choose an evaluation type

The evaluation type determines the tasks your system receives; the participant division determines where the result is listed. These are two independent dimensions.

Evaluation type	What it evaluates	Available divisions	Cycle 2 schedule
Textual Memory	Long conversations, cross-session history, facts, multi-hop relations, temporal events, personalization, rules, memory governance, and Streaming memory.	Open-source Methods / Commercial Products	Materials close October 31 at 23:59
Coding Memory	Retrieving, filtering, and reusing engineering experience from the same repository under relevant and noisy conditions.	Open-source Methods / Commercial Products	Materials close October 31 at 23:59
Multimodal Memory	Writing, retrieving, and using evidence from text-and-image memories through ordered text and Base64 image content arrays.	Open-source Methods / Commercial Products	Materials close October 31 at 23:59

Step 2: Deploy and submit your APIs

In Cycle 2, every participant division must host stable Add / Search APIs. An Eval Key is issued after the submitted online endpoints and materials pass review.

Open-source Methods · API

Host your own Add / Search APIs

Submit fixed Add / Search endpoints, authentication and operational details. A public repository supports openness and attribution review but cannot replace deployed endpoints.

Commercial · API

Provide a stable product API

Submit a fixed product version, Add / Search endpoints, authentication, and capacity details. Internal implementation may remain closed; an Eval Key is issued after approval and results enter the Commercial Products board.

Unified integration requirement

Open-source and commercial entries integrate through participant-hosted Add/Search APIs. Cycle 2 does not accept repository-only or Docker-only submissions for AML deployment. Open-source materials remain part of openness and attribution review.

Step 3: Prepare your submission

Freeze a clear evaluation version before applying. Once a formal Full evaluation is accepted, the version may not be replaced or withdrawn because of an unfavorable result.

For everyone

Common materials

System name and version, contact details, organization or team, intended evaluation type, method or product description, information approved for public display, and complete submission notes.

Open-source Methods

API and openness materials

Deployed Add/Search endpoints, authentication and capacity declarations, plus a public repository, fixed commit, attribution of prior work, and method changes.

Commercial Products

API and operations

Fixed product version, Add / Search APIs, authentication, a dedicated evaluation credential, capacity, timeout, and rate-limit details.

From request to leaderboard

1

Submit a request

Choose an evaluation type, participant division, and submission route, then provide a fixed system version and complete materials.

2

Complete integration

The platform reviews the live API and submitted materials, then issues an Eval Key. AML does not deploy participant systems.

3

Run Smoke and Full

Validate Add / Search, authentication, and the end-to-end path before the formal Cycle 2 Full evaluation.

4

Review and publish

The platform reviews the version, results, and compliance status before publishing the entry to its corresponding public board.

Eval Key and Memory System Key

These credentials are issued by different parties and serve different purposes. Never place either credential in a public repository, URL, screenshot, email body, or group chat.

Credential	Provided by	Purpose	Who needs it
Eval Key / Leaderboard Key	Agent Memory Leaderboard	Verifies participant access, starts evaluations, and unlocks private results.	Open-source and commercial participants whose self-hosted Add / Search APIs pass review.
Memory System Key	Participant	Allows the platform to call the participant's Add / Search APIs.	Required when the submitted API uses authentication; not required for an unauthenticated endpoint.

Rewards

The second Agent Memory Challenge provides a total prize pool of US$22,000 across the Textual, Coding, and Multimodal tracks. Prizes are available only to eligible Open-source Methods teams that pass review; Commercial Products entries are not eligible.

First Prize

1 winner per track

≈ USD 3,000. The Textual, Coding, and Multimodal tracks are judged separately.

Second and Third Prizes

5 winners per track

Second Prize: 2 winners, ≈ USD 1,200 each. Third Prize: 3 winners, ≈ USD 450 each.

Best Technical Innovation

1 winner per track

≈ USD 750. The total prize pool across all three tracks is US$22,000.

What counts as a valid submission?

Complete materials

Participant identity, system version, and all required materials are complete, truthful, and verifiable.

Smoke passes

Add / Search, authentication, and the end-to-end path follow the current integration contract.

Full completes

The formal evaluation and required tasks complete successfully without missing or duplicated results.

Version matches

The code, image, or API used for the formal evaluation matches the declared version.

Review passes

The version, results, and compliance status pass organizer review before the submission is considered valid.

Core participation requirements

1

Return memory evidence

Search must not generate final answers or disguise answers as memory records.

2

Preserve sample isolation

Do not share or retrieve evaluation memories across user IDs, tasks, samples, or teams.

3

Disclose sources and changes

When reusing a paper, repository, or codebase, identify the original authors, technical report, and every method change.

4

Do not manipulate evaluation

Hard-coding, data leakage, prompt injection, live human answering, result manipulation, and leaderboard abuse are prohibited.

Contact and entry points

Read the API Guide and prepare all required materials before applying. For participation and evaluation questions, contact [email protected].

Challenge Repository

正式文档

用户文档

了解如何接入 Add / Search、运行统一评测、查看结果，并将符合条件的结果发布到公开榜单。

01

OVERVIEW

评测机制

Agent Memory Leaderboard 使用统一的端到端流程评估不同记忆系统。数据库、索引和内部架构不作限制。开源方法榜（学术榜）的 Embedding 模型须使用 text-embedding-v4，LLM 相关组件须使用 gpt-4o-mini；Reranker 不作限制。商业产品榜（工业榜）不受上述模型限制。Add / Search 接口须符合现行规范，评测过程和检索结果须能够复核。

1

写入评测记忆

我们按样本和来源会话调用 Add 接口。

2

完成记忆管理

你的系统负责持久化、组织、索引和更新记忆。

3

检索相关记忆

我们针对每道题调用 Search 接口并接收排序结果。

4

统一回答与评分

我们使用固定流程生成答案、完成评分并汇总结果。

统一评测边界

你只负责 Add / Search 环节。回答模型、提示词、评分器、数据集组合、Top K 和汇总规则由我们统一固定，使榜单分数尽可能反映记忆系统本身的能力。

02

WHO THIS IS FOR

适用对象

榜单读者

无需登录即可查看

你可以在 Textual、Multimodal 或 Coding Track 中查看 Overall、分项指标、系统版本和发布日期。不同 Track 使用的任务和指标不同，分数不宜跨 Track 直接比较。

参测团队

完成接入并提交评测

实现 Add / Search → 提交准入申请 → 获取 API Key → 运行公开 smoke → 提交 full 正式评测 → 查看私有结果 → 进入公榜审核。

03

PARTICIPATION WORKFLOW

准入与评测流程

先提交 Evaluation Access Request，完成参测系统、版本、在线 Add / Search 接口和鉴权方式审核。第二期所有榜单均要求参赛方自行部署接口，AML 不接受仅提交仓库后代为部署。

01
提交准入申请
选择申请新 Key，或输入已有 Key 为其增加版本；填写联系人、系统版本、Add / Search 接口、鉴权、容量和运行限制。开源方法另附仓库与来源披露。
02
完成 Key 绑定
审核通过后，新申请会签发 Leaderboard API Key；新增版本申请会直接绑定到原 Key，无需管理员再次手工录入接口信息。
03
运行公开 Smoke
平台直接校验参赛方提交的在线接口，并按照现行同步规范执行 Add → Search → Answer → Evaluate Smoke 流程，确认接口可用后再进入正式评测。
04
完成 Full 前置检查
选择 full 前，必须逐项勾选提交清单：smoke 已通过、API 契约正确、运行说明完整，以及原创性披露和诚信承诺均已完成。
05
提交评测任务
在 Evaluation 页面验证 API Key，选择已绑定的版本，填写唯一的 Run Label 后提交 full 评测。正式任务使用统一的数据集套件和 Top K。
06
查看进度与审计状态
任务依次执行写入、检索、回答、评分和结果汇总。页面会显示当前阶段、完成进度和错误摘要；我们同时保留复核所需的过程记录。
07
查看结果与发布状态
评测结果首先仅对绑定的 API Key 可见。成功完成的 full 任务会进入公榜资格校验和审核队列；审核通过后生成公榜提交记录。

代码审核与取消资格

允许复现已有论文或封装已有仓库，但必须披露原始作者、技术报告以及方法改动；未披露的重复代码可能被视为抄袭。发现重复代码时，平台会优先保护本人已披露并先提交的评测结果。重复提交相似或低质量代码、提示词注入、数据或结果操纵、恶意刷榜等行为，均可能取消参赛资格。

04

EVALUATION MODES

评测模式与配额

模式	用途	标准配额	结果范围	公榜资格
smoke	通过独立的兼容性测试接口检查同步 Add、Search 和评分链路。	每小时 1 次；本届每赛道最多 30 次	仅私有	不可发布
full	运行固定的完整评测套件，并进入正式排队、审计和发布流程。	本届每个 AML Key、每个赛道最多 2 次；第 2 次须在首次 Full 完成后 30 天发起	优先私有	审核通过后发布

选择建议

首次接入或接口行为变更后，先使用独立的兼容性 smoke 检查接口规范；接口稳定且版本准备完成后，再提交唯一的正式评测模式 full。

05

ADD / SEARCH CONTRACT

Add / Search 接入规范

参赛选手配置 Add 和 Search 的接口地址，请求和响应格式按照现行规范固定，不随 URL 路径变化。生产环境建议使用 HTTPS。URL 中不得包含用户名、密码等凭据，也不得指向私有、回环或链路本地地址。

写入方式

同步

记忆写入完成后，Add 接口返回 HTTP 200

正式评测 Top K

100

返回数量不得超过 top_k，超量会判为契约错误

检索范围

user_id

Add 和 Search 必须使用完全相同的 user_id

鉴权与健康检查

Add / Search 支持 Token、Bearer 和 X-Api-Key；none 仅用于公开 smoke。Health 接口通过无需鉴权的 GET 请求调用，返回任意 2xx 状态码即表示服务正常。

POST

Add 请求

普通文本在达到 20 条消息或 2,000 个词中的任一边界时确定性分段，词数按冻结 Adapter 计数；Streaming 按增量会话／任务单元写入；代码保留仓库／会话轨迹，多模态按公开数据源单元与媒体限制处理。单次请求最长 30 分钟。

{
  "request_id": "eval:run_abc123:locomo_refined:conv-0:chunk-0",
  "messages": [{
    "role": "user",
    "timestamp": 1704067200000,
    "content": "memory text"
  }],
  "user_id": "eval:run_abc123:locomo:conv-0",
  "session_id": "eval:run_abc123:sample:0"
}

request_id

必填。本次写入请求的唯一标识；成功响应必须原样返回该值。

messages

必填。消息按原顺序排列，每条消息包含 role 和非空 content。文本与代码使用字符串；多模态可使用字符串或有序 text/image_url 内容数组。timestamp 可选，单位为 Unix 毫秒。

user_id

必填。Search 接口唯一使用的检索范围标识；写入和检索时必须保持一致。

session_id

必填。用于标识来源会话，可以用于组织记忆，但不作为 Search 的筛选条件。

未使用字段

现行规范不发送 metadata、app_id、agent_id 或 async_mode；同步语义由 Add 完成写入后返回 HTTP 200 保证。

200

Add 响应

写入完成并且相关记忆能够立即检索后，才能返回成功响应。

HTTP 200
{
  "success": true,
  "request_id": "eval:run_abc123:locomo_refined:conv-0:chunk-0",
  "user_id": "eval:run_abc123:locomo:conv-0",
  "session_id": "eval:run_abc123:sample:0"
}

success

必填，且必须是布尔值 true。

request_id / user_id / session_id

全部必填，并且必须与请求中的值完全一致。

同步完成

服务内部可以采用异步处理，但 Add 接口必须等待处理完成后再返回。

HTTP 202

仅当提交版本已审核绑定包含 {task_id} 的 Add 状态查询地址时支持；响应须返回 task_id。未绑定时返回 202 属于契约错误。响应不需要 memory_ids。

POST

Search 请求

平台按赛道流程发起 Search；Streaming 可在多个增量节点检索同一道题。查询使用基准原文；多模态可使用图片内容数组，选择题在顶层另行传入选项。单次请求最长 30 分钟。

{
  "query": "Which answer best matches the memory?",
  "options": ["A. First answer", "B. Second answer"],
  "user_id": "eval:run_abc123:locomo:conv-0",
  "top_k": 100
}

query

必填。按照原文检索相关记忆；多模态可使用与 Add 相同的 text/image_url 内容数组。不得替换为最终答案或使用评测金标。

options

可选。选择题（含 Streaming）在 Search 顶层传入选项文本数组；开放题不发送，不包含金标答案。

user_id

必填。只能在该 user_id 对应的记忆范围内检索。

top_k

必填。返回的记忆数量不得超过该值；正式外部评测固定为 100。

请求格式

现行规范不发送 filters、rerank 或 keyword_search。

200

Search 响应

响应必须是一个 JSON 对象，其中 data 为按相关性排序的数组。没有检索结果时，返回空数组。

{
  "data": [{
      "id": "mem_1",
      "content": "remembered fact text",
      "score": 0.87,
      "created_at": "2026-07-01T12:00:00Z"
  }]
}

data

必填，类型为数组。不要增加 items 包装层，也不要直接返回顶层数组。

id

必填，非空字符串，用于稳定标识该条记忆。

content

必填，非空字符串；多模态可返回 text/image_url 内容数组。平台保留原始候选并传入统一 Answer 流程。

score

可选，数值类型。数值越大应表示相关性越高。

created_at

可选，用于记录记忆的来源时间或持久化时间。

其他字段

我们只读取上述字段；metadata 等未声明字段会被忽略。

返回顺序和数量：我们保留接口返回的顺序；返回数量不得超过 top_k。超量或存在非法条目会判为契约错误，不会静默截断后继续评分。

06

ERROR HANDLING

错误处理

参测接口应使用标准 HTTP 状态码，并返回便于排查问题且不含密钥的错误信息。平台业务错误通常采用 {"detail":{"reason":"..."}} 格式；字段校验失败时，HTTP 422 会返回结构化错误明细。

HTTP	错误类型	常见原因	处理方式
`400 / 422`	接口格式错误	Add / Search 请求无法解析，或者成功响应缺少必填字段、字段类型不正确。	不自动重试。根据错误信息修正请求或响应格式，然后重新运行 smoke。
`401`	认证失败	Memory System Key 无效，或者 Authorization / X-Api-Key 与申请时选择的方式不一致。	不自动重试。核对鉴权方式和绑定的密钥。
`403`	访问被拒绝	当前密钥无权调用接口，或者服务端拒绝访问指定的 `user_id`。	不自动重试。检查接口权限和检索范围配置。
`404`	资源不存在	接口路径错误，或者平台侧的 test、job、result ID 无效。	检查 URL 或资源 ID。现行同步规范不包含 Add Status 查询。
`409`	状态冲突	同一 Add 可能仍在处理，或者平台已有任务正在运行、Run Label 重复。	Add 可保持同一 request_id 与请求体进行有界重试，但不能仅凭 409 视为成功；Search 的 409 不重试。平台任务冲突时，请等待现有任务结束或更换 Run Label。
`408 / 425`	暂时不可用	请求超时，或者服务尚未准备完成。	Add / Search 请求都会按照平台策略进行有限次数的退避重试。
`429`	触发限流或配额	参测接口容量不足，或者平台评测配额尚未恢复。	接口调用会在限定次数内重试；如果是平台配额限制，请等待页面显示的下次可用时间。
`500 / 502 / 503 / 504`	临时服务异常	参测接口、网关或上游依赖暂时不可用。	我们会自动退避重试。若持续失败，请保留 Job/Test ID 和发生时间，便于进一步排查。

自动重试范围

Add 遇到网络错误及 408、409、425、429、500、502、503、504、524 时会有界重试；409 不单独代表成功。Search 遇到网络错误及 408、425、429、500、502、503、504 时会有界重试；400、401、403、404、409、422 等永久性 4xx 不重试。重试和断点续跑保持同一 Add 的 request_id 与请求体。

格式错误立即终止

即使 HTTP 状态码为 200，只要 Add 未返回 success=true、三个 ID 未正确返回，或者 Search 未返回 data 数组、某条记录缺少 id / content，当前阶段都会立即失败。

07

DATA, SECURITY & PRIVACY

数据安全与隐私

01

仅传输必要数据

你的接口只会收到当前任务所需的记忆片段、user/session 标识和检索问题。我们不会提供金标答案、评分依据或完整数据集下载。

02

隔离检索范围

user_id 是 Search 接口唯一使用的检索范围标识，存储和检索时必须完全一致。session_id 只用于组织来源会话。禁止跨 user_id 返回记忆。

03

保护访问密钥

Memory System Key 通过受控的申请流程提交并加密保存，任务信息中只保留不可读的引用。密钥不会出现在邮件、公榜或公开 API 响应中。

04

校验接口地址

我们只连接通过网络校验的公开 HTTP(S) 接口，并拒绝 URL 中包含凭据，或者指向私有、回环、链路本地地址的目标。

05

保留审计记录

我们会保留复核所需的请求结果、耗时、错误、候选记忆和接口格式校验记录，用于确认评测是否完整，以及结果是否符合公榜条件。

06

控制结果权限

私有任务和结果仅对绑定的 Leaderboard API Key 可见。公榜只展示审核通过的系统、版本、分数和必要的评测信息。

你的数据处理责任

评测数据及其派生副本只能用于完成当前任务，不得用于模型训练、微调、产品分析、数据集重建或对外传播。请仅向必要人员开放访问权限，避免记录不必要的请求正文，并在任务完成后 30 天内删除相关数据；如需延长保留时间，必须事先获得我们的书面同意。

08

EVALUATION & RESULTS

评测与结果发布

ADD

同步写入记忆

每个记忆分块都必须在返回 HTTP 200 前完成持久化，并且能够立即检索。

SEARCH

检索并校验格式

我们会检查 data 数组、必填字段和 Top K，并按照接口返回的顺序接收候选记忆。

ANSWER

统一生成回答

通过校验的候选记忆会进入统一的回答模型和提示词流程。

EVAL

统一完成评分

我们按照题型使用固定的评分规则，并汇总各数据集和 Overall 结果。

PRIVATE

查看私有结果

任务完成后，你可以使用绑定的 API Key 查看运行状态、分项结果、错误摘要和任务信息。

PUBLIC

发布至公榜

full 结果通过资格校验和审核后，会生成公榜提交记录并展示在公开榜单中。

PUBLICATION GATE

公榜准入条件

结果必须来自成功完成的 full 模式固定套件，且所有评测任务均执行成功。统一回答模型、评测规范、pipeline code hash、dataset bundle hash 和题量记录必须完整，并与现行发布基线一致。结果不得重复提交，同时还需通过平台审核。

09

BENCHMARK SUITE

基准详情

按能力维度浏览基准数据集。每张卡片均链接到源仓库，并说明任务格式、指标与评测备注。

文本数据集

多模态数据集

多模态

ATM-Bench

以问题质量等指标评估多模态智能体记忆能力。

详情 →

多模态

Mem-Gallery

使用 F1 指标评估图集式记忆检索能力。

详情 →

编程数据集

编程 · 当前正式计分

CAMBench Coding

150 个软件工程任务分别在 relevant 与 noisy 记忆条件下运行，共 300 次评测尝试。

编程 · 参考目录

SWEContextBench

当前不作为 AML 代码赛道的正式计分基准。

参考资料 →

OFFICIAL DOCUMENTATION

User Documentation

Learn how to integrate Add / Search, run consistent evaluations, review results, and publish eligible runs to the public leaderboard.

01

OVERVIEW

How the platform works

Agent Memory Leaderboard compares memory systems under a consistent end-to-end evaluation. Databases, indexes, and internal architectures are unrestricted. Open-source Methods (Academic) entries must use text-embedding-v4 for embeddings and gpt-4o-mini for LLM-related components; rerankers are unrestricted. Commercial Products (Industry) entries are not subject to these model restrictions. The external Add/Search API and retrieval evidence must be conformant and auditable.

1

Ingest evaluation memory

The platform calls Add by sample and source session.

2

Manage memory

Your system persists, organizes, indexes, and updates memory.

3

Retrieve candidates

The platform calls Search per question and receives ranked results.

4

Answer and score

A fixed platform workflow generates answers, scores them, and aggregates results.

Fairness boundary

Participant-controlled behavior is limited to Add / Search. The platform locks the answer model, prompts, evaluators, dataset suite, Top K, and aggregation rules so that score differences primarily reflect the memory system.

02

WHO THIS IS FOR

Audience

LEADERBOARD READERS

Read without signing in

Review Overall scores, metric breakdowns, system versions, and publication dates within the Textual, Multimodal, or Coding track. Each track has a distinct task and metric contract; scores are not comparable across tracks.

EVALUATION PARTICIPANTS

Integrate against the contract and participate

Implement Add / Search → submit an access request → receive an API Key → run public smoke → submit the full evaluation → review private results → enter public review.

03

PARTICIPATION WORKFLOW

Evaluation workflow

Open-source Methods and Commercial Products submissions both use participant-hosted Add/Search APIs and follow the same review, Key issuance, and public Smoke flow. AML does not deploy repository-only submissions.

01
Submit the access request
All entries provide deployed Add/Search endpoints, authentication, capacity, and operational details. Open-source Methods entries additionally disclose the public repository, original authors, technical report, and method changes.
02
Complete key binding
Approval either issues a new Leaderboard API Key or binds the submitted version to the verified existing key without administrator re-entry.
03
Run public Smoke
The platform checks the participant-operated endpoints and runs the synchronous Add → Search → Answer → Evaluate Smoke flow. AML does not build or deploy participant systems.
04
Complete the Full gate
Before selecting full, confirm the interactive checklist: smoke passed, API contract followed, run instructions complete, original work disclosed, and no integrity violations.
05
Start the job
Verify the API Key on the Evaluation page, select a bound version, assign a unique Run Label, and submit the full evaluation. Formal jobs use the fixed suite and platform Top K.
06
Monitor progress and audit status
The job proceeds through ingestion, retrieval, answering, scoring, and aggregation. The interface reports stage, progress, and error summaries while the platform retains evidence required for review.
07
Review results and publication status
Results are initially visible only to the bound API Key. A successful full job enters the public-eligibility gate and review queue; approval creates a public submission.

Code review and disqualification

Reproductions of papers or existing repositories are allowed only with full attribution to the original authors, technical report, and all method changes. Undisclosed reuse may be treated as plagiarism. When duplicate code is discovered, the platform prioritizes the participant's first disclosed submission. Repeated near-duplicate or low-quality code, prompt injection, benchmark or result manipulation, malicious behavior, and other leaderboard abuse may cancel eligibility.

04

EVALUATION MODES

Evaluation modes and standard quotas

Mode	Purpose	Standard quota	Visibility	Public eligibility
smoke	Separate integration endpoint for synchronous Add, Search, and scoring compatibility.	1 per hour; at most 30 per track this edition	Private	Not eligible
full	Fixed complete benchmark suite with formal queueing, audit, and release workflow.	At most 2 Full runs per AML Key and track; the second unlocks 30 days after the first Full run is completed	Private first	Eligible after approval

How to choose

Use the separate compatibility smoke after initial integration or an API behavior change. Submit full, the only formal participant mode, after the version is ready for publication.

05

ADD / SEARCH CONTRACT

Add / Search integration contract

Participants configure the Add and Search URLs; request and response schemas are fixed and do not vary by path. Production deployments should use HTTPS. URLs must not embed credentials or resolve to private, loopback, or link-local addresses.

Write protocol

Synchronous

Add succeeds only with HTTP 200 after persistence

Formal Top K

100

The response must not exceed top_k; excess items are a contract error

Retrieval scope

user_id

Add and Search must use the identical isolation boundary

Authentication and Health

Add / Search support Token, Bearer, and X-Api-Key; none is limited to public smoke. Health is an unauthenticated GET where any 2xx means healthy.

POST

Add Request

Ordinary Textual splits deterministically at either 20 messages or 2,000 Adapter-counted words. Streaming writes frozen incremental session or task units. Coding preserves repository/session trajectories; Multimodal follows published source units and media limits. One request may run for up to 30 minutes.

{
  "request_id": "eval:run_abc123:locomo_refined:conv-0:chunk-0",
  "messages": [{
    "role": "user",
    "timestamp": 1704067200000,
    "content": "memory text"
  }],
  "user_id": "eval:run_abc123:locomo:conv-0",
  "session_id": "eval:run_abc123:sample:0"
}

request_id

Required. Unique identifier for this chunk request; the success response must echo it exactly.

messages

Required ordered array. Each item includes role and non-empty content. Textual and Coding use strings; Multimodal may use strings or ordered text/image_url content parts. timestamp is optional Unix milliseconds.

user_id

Required. The sole retrieval-isolation field; Search must use the identical value.

session_id

Required. Identifies the source session and may be used for grouping, but is not a Search filter.

Fields not sent

The current contract omits metadata, app_id, agent_id, and async_mode. Synchronous behavior is guaranteed by returning HTTP 200 only after Add completes.

200

Add Response

Return success only after the write is persisted and immediately searchable.

HTTP 200
{
  "success": true,
  "request_id": "eval:run_abc123:locomo_refined:conv-0:chunk-0",
  "user_id": "eval:run_abc123:locomo:conv-0",
  "session_id": "eval:run_abc123:sample:0"
}

success

Required and must be the boolean value true.

request_id / user_id / session_id

All are required and must match the request byte for byte.

Synchronous completion

Internal work may be asynchronous, but the endpoint must wait for completion before responding.

HTTP 202

Supported only when the submitted version has an approved Add-status URL containing {task_id}; the response must return task_id. Without that binding, 202 is a contract error. memory_ids are not required.

POST

Search Request

The platform issues Search calls according to each track's workflow; Streaming may search the same question at multiple incremental steps. Questions retain their original language. Multimodal may use image content parts; choice options appear separately at the top level. One request may run for up to 30 minutes.

{
  "query": "Which answer best matches the memory?",
  "options": ["A. First answer", "B. Second answer"],
  "user_id": "eval:run_abc123:locomo:conv-0",
  "top_k": 100
}

query

Required original question. Multimodal may use the same text/image_url content parts as Add. Do not replace it with a final answer or use benchmark gold data.

options

Optional. Choice text is sent as a top-level string array for multiple-choice questions, including Streaming; omitted for open questions and never contains the gold answer.

user_id

Required. Retrieve only from memory stored under this exact value.

top_k

Required. The response must not exceed this number; formal external evaluations use 100.

Fixed schema

The current contract does not send filters, rerank, or keyword_search.

200

Search Response

Return a JSON object whose data field is a relevance-ordered array. Return an empty array when nothing is found.

{
  "data": [{
      "id": "mem_1",
      "content": "remembered fact text",
      "score": 0.87,
      "created_at": "2026-07-01T12:00:00Z"
  }]
}

data

Required array. Do not add an items wrapper or return a top-level array.

id

Required non-empty string that stably identifies the memory.

content

Required non-empty string; Multimodal may return text/image_url content parts. The original candidate is retained and passed to Answer.

score

Optional number. Higher values should indicate greater relevance.

created_at

Optional source or persistence timestamp.

Other fields

The platform reads only the declared fields above; undeclared fields such as metadata are ignored.

Order and count: the platform preserves participant response order, and the response must not exceed top_k. Excess or invalid items fail contract validation; they are not silently truncated.

06

ERROR HANDLING

Error reference

Participant endpoints should use standard HTTP status codes and return actionable errors without secrets. Platform business errors normally use {"detail":{"reason":"..."}}; HTTP 422 provides structured field-validation details.

HTTP	Class	Typical case	Platform behavior and action
`400 / 422`	Contract error	An Add / Search request cannot be parsed, or a success response has missing or invalid required fields.	Not retried. Correct the schema using the error details, then rerun smoke.
`401`	Authentication failure	The Memory System Key is invalid, or the Authorization / X-Api-Key scheme does not match.	Not retried. Verify the authentication scheme and secret bound to the request.
`403`	Access denied	The key cannot call the endpoint, or the service rejects the current user_id scope.	Not retried. Review endpoint authorization and retrieval isolation.
`404`	Resource not found	An endpoint path is wrong, or a platform test, job, or result ID is invalid.	Verify the URL or resource ID. The synchronous contract has no Add Status polling.
`409`	State conflict	Add is temporarily conflicted, or a platform job is active and the Run Label is duplicated.	Add is retried with bounds; Search 409 is not retried. Wait or choose a new Run Label for platform conflicts.
`408 / 425`	Transient unavailability	The request timed out or the service is not ready.	Add and Search are retried with bounded backoff.
`429`	Rate or quota limit	The participant endpoint is capacity-limited, or a platform evaluation quota has not reset.	Endpoint calls are retried with bounds; for platform quotas, wait until the displayed availability time.
`500 / 502 / 503 / 504`	Transient service failure	The participant endpoint, gateway, or upstream dependency is temporarily unavailable.	The platform retries with backoff. Preserve the Job/Test ID and timestamp if failures persist.

Bounded automatic retries

Add retries 408, 409, 425, 429, 500, 502, 503, 504, and 524. Search retries 408, 425, 429, 500, 502, 503, and 504. Network timeouts and transport failures are also eligible.

Contract errors stop immediately

Even with HTTP 200, the stage fails if Add omits success=true or mis-echoes an ID, or if Search omits the data array or an item lacks id / content.

07

DATA, SECURITY & PRIVACY

Data, security, and privacy

01

Minimum necessary data

Participant endpoints receive only the memory chunks, user/session identifiers, and retrieval questions needed for the current job. Gold answers, scoring criteria, and bulk dataset downloads are not provided.

02

Strict retrieval isolation

user_id is the sole Search-isolation field and must match exactly during storage and retrieval. session_id is only for source-session organization. Cross-user_id retrieval is prohibited.

03

Secret protection

The Memory System Key is submitted through a controlled request flow and stored encrypted; job metadata contains only an opaque reference. Secrets do not appear in email, public rankings, or public API responses.

04

Endpoint security

The platform connects only to network-validated public HTTP(S) endpoints and rejects URLs with embedded credentials or targets resolving to private, loopback, or link-local addresses.

05

Process audit

The platform retains request outcomes, latency, errors, returned memories, and contract-validation evidence required to verify evaluation integrity and public eligibility.

06

Result visibility

Private jobs and results are visible only to the bound Leaderboard API Key. The public board shows approved systems, versions, scores, and required evaluation metadata.

Participant data-handling obligations

Evaluation data and derived copies may be used only to complete the current job. Do not use them for training, fine-tuning, product analytics, dataset reconstruction, or redistribution. Restrict access to authorized personnel, avoid unnecessary payload logging, and delete the data within 30 days after job completion unless the platform approves another retention period in writing.

08

EVALUATION & RESULTS

Evaluation process and results

ADD

Synchronous ingestion

Each chunk must be persisted and searchable before its HTTP 200 response.

SEARCH

Retrieval and contract validation

The platform validates the data array, required fields, and Top K, then accepts candidates in participant order.

ANSWER

Standardized answering

Valid candidate memories enter the locked platform Answer model and prompt workflow.

EVAL

Standardized scoring

The platform applies fixed scoring contracts by question type and aggregates dataset and Overall results.

PRIVATE

Private results

After completion, the bound API Key can inspect run status, breakdowns, error summaries, and job metadata.

PUBLIC

Public release

An eligible full result creates a public submission only after qualification checks and review.

PUBLICATION GATE

Public leaderboard eligibility

The result must come from a successful full run on the fixed suite; every evaluation task must succeed; the Answer model, evaluation contract, pipeline code hash, dataset bundle hashes, and question counts must be complete and match the current release baseline; and the result must be unique and pass platform review.

09

BENCHMARK SUITE

Benchmark Details

Browse benchmark datasets by dimension. Each card links to its source repository with task format, metrics, and evaluation notes.

Textual Datasets

Multimodal Datasets

multimodal

ATM-Bench

Multimodal agent memory evaluated by question quality.

Details →

multimodal

Mem-Gallery

Gallery-style memory retrieval evaluated with F1.

Details →

Coding Datasets

coding · current scored suite

CAMBench Coding

150 software-engineering tasks run under relevant and noisy memory conditions, for 300 scored attempts.

coding · reference catalog

SWEContextBench

Not currently used as the scored AML Coding benchmark.

Reference →

接入指南

Add / Search API 接入指南

第二期文本、代码与多模态赛道统一通过参赛方自行部署的 Add / Search API 接入。请按本页接口格式完成实现，申请并绑定评测 Key，通过 Smoke 后即可提交 Full 正式评测。

Add 请求

请在下方选择赛道格式；多模态会把文本与图片按顺序直接放入 messages[].content。

{
  "request_id": "eval:<run_id>:locomo_refined:conv-0:chunk-0",
  "messages": [{
    "role": "user",
    "timestamp": 1704067200000,
    "content": "raw memory text"
  }],
  "user_id": "eval:<run_id>:locomo:conv-0",
  "session_id": "eval:<run_id>:sample:0"
}

{
  "request_id": "eval:<run_id>:multimodal:conv-0:chunk-0",
  "messages": [{
    "role": "user",
    "timestamp": 1704067200000,
    "content": [
      {"type": "text", "text": "caption or text evidence"},
      {"type": "image_url", "image_url": {
        "url": "data:image/jpeg;base64,..."
      }}
    ]
  }],
  "user_id": "eval:<run_id>:multimodal:conv-0",
  "session_id": "eval:<run_id>:sample:0"
}

ContentPart[] 字段格式展开查看多模态有序内容规则

type: 每个 part 必填；取值为 text 或 image_url，并保持数组顺序。
text: type=text 时必填且不得为空。
image_url.url: 使用内联 Base64 Data URI；不接受远程图片 URL。
媒体限制: 支持 JPEG、PNG、WebP；单图解码后至多 10 MiB，单次 Add 请求合计至多 30 MiB。

字段要求说明 request_id必填本次逻辑写入的标识；重试时保持不变，响应需原样回显。 messages必填按来源顺序排列的消息；请按收到的顺序处理。 messages[].role必填消息角色为 user 或 assistant。 messages[].content必填文本与代码赛道使用字符串；多模态赛道使用有序 ContentPart[] 数组。 messages[].timestamp可选源数据有时间戳时发送，单位为 Unix 毫秒；分段不改变其值和消息顺序。 user_id必填记忆隔离范围；后续 Search 使用相同的值。 session_id必填来源对话或会话的标识。

Add 响应

文本、代码与多模态使用相同的响应格式。

{
  "success": true,
  "request_id": "eval:<run_id>:locomo_refined:conv-0:chunk-0",
  "user_id": "eval:<run_id>:locomo:conv-0",
  "session_id": "eval:<run_id>:sample:0"
}

字段要求说明 success必填消息已持久化且可立即检索后，返回值必须为 true。 request_id必填原样返回 Add 请求中的 request_id。 user_id必填原样返回 Add 请求中的 user_id。 session_id必填原样返回 Add 请求中的 session_id。

Search 请求

请在下方选择赛道格式；多模态 query 使用相同的有序 ContentPart[] 结构。

{
  "query": "Which answer best matches the memory?",
  "options": ["A. First answer", "B. Second answer"],
  "user_id": "eval:<run_id>:locomo:conv-0",
  "top_k": 100
}

{
  "query": [
    {"type": "text", "text": "Which answer matches this image?"},
    {"type": "image_url", "image_url": {
      "url": "data:image/png;base64,..."
    }}
  ],
  "options": ["A. First answer", "B. Second answer"],
  "user_id": "eval:<run_id>:multimodal:conv-0",
  "top_k": 100
}

ContentPart[] 字段格式展开查看多模态有序内容规则

type: 每个 part 必填；取值为 text 或 image_url，并保持数组顺序。
text: type=text 时必填且不得为空。
image_url.url: 使用内联 Base64 Data URI；不接受远程图片 URL。

字段要求说明 query必填基准原题：文本与代码赛道使用字符串，多模态赛道使用有序 ContentPart[]。 options按题型发送选择题（含 Streaming）在顶层发送选项；开放题不发送，且选项不含金标答案。 user_id必填与对应 Add 请求相同的记忆隔离范围。 top_k必填允许返回的最大记忆条数；正式外部评测固定为 100。

Search 响应

请按参赛赛道选择响应格式；多模态结果可在 data[].content 中返回有序文本与图片。

{
  "data": [{
    "id": "mem_123",
    "content": "remembered fact text",
    "score": 0.87,
    "created_at": "2026-07-01T12:00:00Z"
  }]
}

{
  "data": [{
    "id": "mem_123",
    "content": [
      {"type": "text", "text": "remembered fact text"},
      {"type": "image_url", "image_url": {
        "url": "data:image/webp;base64,..."
      }}
    ],
    "score": 0.87,
    "created_at": "2026-07-01T12:00:00Z"
  }]
}

ContentPart[] 字段格式展开查看响应字段要求

type: 每个返回的 part 必填；取值为 text 或 image_url，并保持数组顺序。
text: type=text 时必填且不得为空。
image_url.url: 使用内联 Base64 Data URI；不接受远程图片 URL。
媒体限制: 单图解码后至多 10 MiB，单次 Search 响应中的图片合计至多 30 MiB。

字段要求说明 data必填按检索排名排列的数组；无结果时返回 []，不得省略 data。 data[].id必填每条返回记忆的稳定标识。 data[].content必填文本与代码赛道返回非空字符串，多模态赛道返回有序 ContentPart[]；内容会原样保留供审计，并按返回顺序进入 Answer。 data[].score可选数值型相关性得分；数值越高必须表示相关性越强。 data[].created_at可选该记忆的来源时间或持久化时间。

评测数据

每次评测运行期间，你的 API 会接收基准内容。

发送的数据

你的 API 会接收评测记忆与问题。

仅用于评测

这些数据仅限用于本次评测，不得用于训练、额外分析或共享。

30 天内删除

请保持数据私密，避免留存日志，并在运行结束后 30 天内删除。

各页面用途

通过简明的页面地图，帮助用户在接口准备完成后快速找到下一步入口。

01

首页

查看平台概览与基准预览。

02

排行榜

按赛道查看公开排名。

03

评测

验证 Key、启动评测任务，并查看私有结果与归因。

04

用户文档

查看用户流程、API 契约、安全要求与结果发布规则。

05

贡献基准

提交包含任务说明、数据来源、数据包与授权信息的基准提案。

COMMUNITY CONTRIBUTION

Provide Benchmarks

Help extend the Agent Memory Leaderboard by proposing a well-documented benchmark. Include the dataset context, evaluation goal, and provenance so reviewers can assess fit, safety, and reproducibility.

01

Access and ownership

Link this proposal to an existing LDBD participant identity. The key stays in this browser and is not attached to uploaded dataset files.

你的 LDBD Key Used only to associate the proposal with your organization. Do not include it in dataset files or examples. 提交人姓名联系邮箱机构或团队

02

Benchmark profile

Describe the memory capability this benchmark measures and how it complements the current suite.

数据集名称主要赛道任务规模评测目标

03

数据集内容与来源

Provide a representative sample and enough provenance for reviewers to verify that the data can be used in an open benchmark.

数据集内容 For a full package, include a README, schema, task format, ground-truth policy, and a small validation split. 数据集文件

选择文件 No file selected

Suggested: JSONL, JSON, CSV, or a zipped package. 授权方式来源与引用

Agent Memory Leaderboard

Agent Memory Leaderboard

Leaderboard Preview

Benchmark Tracks

Textual Memory

Multimodal Memory

Coding Agent Memory

Evaluation Flow

Deploy Add/Search APIs

Run a smoke test

Submit a formal evaluation

Explore the Platform

Leaderboard

Evaluation

Participation Guide

Documentation

Guide

AML 官方博客

最新文章

倒计时48小时！CSIG AML 第二期参赛项目提交即将截止

AML 火热进行中｜参赛常见问题 Q&A 第二期

AML 第二期评测已开启｜参赛常见问题 Q&A

倒计时 2 天｜CSIG主办，Agent Memory Challenge 2026 第二期参赛指南

AML 官方系列解读（二）｜代码记忆榜：工业与开源方法表现如何？

AML榜前方案解读｜FlowGrid AML Retriever：一条 Markdown 决策日志如何变成 Agent 记忆检索器

AML榜前方案解读｜ChronoHybridMem：从对话到可验证的记忆证据

AML榜前方案解读｜ActiveMemoryIndex：一个不做记忆治理的系统，为什么治理分排第一

CSIG主办｜15万奖金池，第二届 Agent Memory Challenge 即将启动

AML榜前方案解读｜ReFind 主动搜索原则，让 Agent 翻原始聊天记录

AML榜前方案解读｜从“相似”到“完整”，InvMem 如何让 Agent 找回真正有用的长期记忆

AML 官方系列解读（一）｜榜单热度持续：文本开源榜透露了哪些信号？

首期 AML 榜单正式发布！

当一个 Agent 开始拥有“昨天”，它才真正开始理解你

Agent 记忆挑战赛正式启动：首个面向记忆系统的开放锦标赛

该分类下暂无文章

Agent 记忆挑战赛正式启动：首个面向记忆系统的开放锦标赛

统一评测：整合多源数据，统一评测全流程

能力剖面：重构能力维度，呈现系统真实差异

低门槛统一接入：支撑开放榜单长期运行

首届 Agent 记忆挑战赛 2026

由 Agent Memory Leaderboard 平台主办的首届 Agent 记忆挑战赛已于 2026 年 7 月 29 日启动，本次挑战赛面向全球研究者、开源项目维护者和商业产品团队征集参评系统，旨在为社区提供第一批可比较、可复核的公开评测结果。

赛事榜单分类

参赛流程说明

奖励设置

赛事日程与联系方式

智能体记忆排行榜

Leaderboard

第二期正式榜单预计于 2026 年 11 月 19 日发布

智能体记忆排行榜

Leaderboard

第二期正式榜单预计于 2026 年 11 月 19 日发布

智能体记忆排行榜

Leaderboard

第二期正式榜单预计于 2026 年 11 月 19 日发布

运行评测

Create Eval Job

Full evaluation checklist

Current Job

External Full-Run Review

Private Results

第二期 Agent 记忆挑战赛参赛说明

一分钟了解第二期赛事

赛事开放

材料截止

正式评测截止

正式榜单

评测类型

第一步：选择评测类型

第二步：部署并提交接口

自行部署 Add / Search API

提供稳定的产品 API

第三步：准备提交材料

所有参赛者

接口与开放材料

接口与运行材料

从申请到上榜

提交评测申请

完成接入

Smoke 与 Full

复核与公榜