PAST-Bench：个人智能体自我改进能力的评测基准设计与实践

在做个人智能体（Personal Agent）相关开发时，有一个很容易被忽略但又非常关键的问题：Agent 在完成一次任务之后，下次遇到同类任务会不会做得更好？也就是说，智能体是否真的从历史经验中获得了成长，还是每次都在重复同样的错误。

大多数传统 Benchmark 只评测“模型在某个时间点的最终表现”，却不关心“模型是否具备自我改进的能力”。PAST-Bench 这个名字的提出，正是为了把“递归自我改进（Recursive Self-Improvement）”这个偏学术的概念，落地成一个可量化、可复现、可对比的评测体系。

这篇文章会围绕以下几个方面展开：

• 什么是 Personal Agents，什么是递归自我改进；
• PAST-Bench 评测基准的核心设计思路；
• 评测“自我改进能力”需要拆解哪些基础维度；
• 给出一个最小可运行的“自改进评测循环”示例；
• 梳理自建评测基准时的常见坑与最佳实践。

不管你是正在做 Agent 应用的后端开发者，还是对大模型评测感兴趣的算法工程师，这篇文章都能提供一套可以直接参考的评测设计与落地思路。

1. 背景：个人智能体正在从“会聊天”走向“会改进”

1.1 什么是 Personal Agents

Personal Agents，也就是个人智能体，是指一类以个人用户为中心、能够帮助用户完成实际任务的 AI 系统。它不同于单纯的聊天机器人，它的核心特征是能调用工具、能执行操作、能完成多步任务。

常见的 Personal Agents 应用包括：

• 自动整理邮件并生成摘要；
• 根据日程安排自动规划会议；
• 读取本地文档后回答用户问题；
• 编写代码、执行测试并修复错误；
• 自动搜集信息并生成调研报告。

在技术实现上，Personal Agents 一般由以下几部分组成：

早期 Agent 系统大多是“静态”的：模型参数固定，提示词固定，工具列表固定。也就是说，无论 Agent 运行多久，它的行为模式不会因为经验而改变。这种系统适合完成结构清晰、复杂度低的固定任务，但很难适应真实世界的多样性和不确定性。

1.2 什么是递归自我改进（RSI）

递归自我改进（Recursive Self-Improvement，简称 RSI）指系统能够利用自身的输出结果和外部反馈，持续调整自己的行为策略，从而在后续任务中取得更好表现。

“递归”体现在：系统改进后的策略，会影响它下一次如何收集经验；而新一轮的经验又会被用于下一轮改进。这个过程可以反复迭代，形成一个持续上升的改进闭环。

放到 Personal Agents 场景里，一个最简单的 RSI 闭环是这样的：

1. Agent 接收任务；
2. Agent 执行一系列动作并得到结果；
3. 外部环境或用户给出反馈（比如任务是否成功、执行耗时、结果质量）；
4. Agent 将“任务描述、动作轨迹、结果反馈”沉淀为经验；
5. 在下一轮执行同类任务时，Agent 参考历史经验，生成更优的策略。

这个过程听起来很美好，但实际落地时存在一个核心难题：怎么判断一个 Agent 真的“改进”了，而不是碰巧这次运气好？

如果评测任务只有两三个固定题目，模型可能只是记住了答案，并没有获得真正的泛化能力。因此，我们需要一个专门的基准测试，来系统性地回答“Agent 是否具备递归自我改进能力”这个问题。

1.3 为什么需要专门的 Benchmark

在 AI 领域，Benchmark 的作用不只是排名，更重要的是界定能力边界。

传统评测基准，例如常见的知识问答、代码生成、数学推理数据集，通常只关注“给定输入，模型能否给出正确答案”。这种评测方式有两个局限：

1. 单次快照：只测模型当前状态，不测变化趋势；
2. 静态任务：任务列表固定，模型不具备从任务执行中学习的机制。

而 PAST-Bench 这类面向自我改进的评测基准，需要回答的则是另外几个问题：

• Agent 在经历若干轮任务之后，成功率是否上升？
• 上升的原因是真正的策略优化，还是模型记住了题目？
• Agent 能否把从任务 A 学到的经验迁移到任务 B？
• 改进过程中是否出现“灾难性遗忘”——某个能力提高了，其他能力却发生退化？
• 改进是否安全可控？有没有出现绕过规则、钻评测漏洞的行为？

这些问题，传统 Benchmark 覆盖不了。PAST-Bench 的出现，本质上是在把“自我改进”从一个模糊概念，变成一套可操作、可评估、可对比的工程标准。

2. PAST-Bench 评测基准的核心设计思路

2.1 从命名理解它的定位

PAST-Bench 可以理解为Personal Agents Self-improvement Testing Benchmark的缩写。

用 PAST 这个词来命名，本身很有讲究。Past 在英文里是“过去”的意思，而自我改进的核心恰恰就是利用过去的经验来优化未来的行为。一个智能体如果完全不参考历史经验，它就没有“过去”，也就谈不上持续改进。

所以 PAST-Bench 想强调的评测重点非常明确：

评测对象不是“Agent 当前有多强”，而是“Agent 能不能从过去的任务中学习，并让自己变得越来越强”。

2.2 评测的基本单元：单任务闭环

PAST-Bench 的评测单元不是“一道题”，而是一个“完整的学习任务闭环”。

一个闭环通常包含以下几个阶段：

1. 初始化阶段：给出任务环境、初始提示词、可用工具列表；
2. 第一次执行阶段：Agent 完成任务，记录动作序列和结果；
3. 反馈阶段：系统返回任务成功/失败，以及细粒度的中间结果评价；
4. 反思与经验生成阶段：Agent 根据反馈生成结构化经验，例如“我因为遗漏了日期格式校验，导致任务失败，下次应先格式化日期再计算”；
5. 存储阶段：把经验写入长期记忆库；
6. 再次执行阶段：Agent 使用更新后的记忆库重新执行同类或相关任务；
7. 对比评估阶段：比较前后执行的成功率、任务效率、错误类型分布等指标。

通过这种闭环设计，PAST-Bench 把“自我改进”从一句口号变成了可以被指标观测的工程过程。

2.3 与传统评测基准的差异

理解了单任务闭环之后，就能看清 PAST-Bench 与传统评测的差异了。

也就是说，PAST-Bench 不是要替代传统评测，而是把评测维度从“能力水平”扩展到了“能力进化速度”和“能力进化质量”。

3. 五大基础能力维度拆解

“自我改进”是一个笼统的目标，要评测它，必须先拆解。结合 Personal Agents 的实际运行机制，PAST-Bench 的评测维度至少应该覆盖以下五个方面。

3.1 经验抽取（Reflection）

经验抽取是指 Agent 能从一次任务执行中得出可复用的教训。

例如任务失败后，Agent 能否准确识别出失败环节？

• 是工具调用参数错误？
• 是推理步骤跳步？
• 是信息检索不完整？
• 是输出格式不符合要求？

如果 Agent 只能得到一句泛泛的“我失败了”，那它下一轮大概率还会犯同样的错误。真正有效的经验抽取，要能输出结构化、可执行的改进建议。

评测时可以用“反思质量”来打分：反思是否定位到具体环节、是否给出可执行的动作、是否避免了因果错误。

3.2 经验存储与检索（Memory）

抽取出经验之后，Agent 还要把经验有效地存下来，并在合适的时机找回来。

这个维度考察的是记忆系统的能力：

• 存储格式是否结构清晰？
• 检索是否能在相似任务出现时命中相关经验？
• 是否存在记忆堆积、检索混乱的问题？
• 多轮更新后，旧经验是否会被错误覆盖？

真实场景中，一个 Agent 可能经历成百上千次任务，记忆库会越来越大。如果检索不到相关经验，那存储的信息就等同于没有。

3.3 行为调整（Policy Update）

行为调整指的是 Agent 在下一轮执行中，是否真的把经验用上了。

这是自我改进最核心的落地环节。很多 Agent 能写出漂亮的反思，但下一轮执行完全不受反思影响，这就属于“伪改进”。

评测行为调整能力时，需要对比两轮执行的动作轨迹，观察：

• 是否避免了上一轮明确标记过的错误？
• 是否采用了反思中建议的新策略？
• 新策略是否带来了更好的结果？

3.4 跨任务迁移（Generalization）

真正的自我改进，不能只是在同一个任务模板上越做越好，否则就变成了“背题”。

跨任务迁移能力要求 Agent 把某个任务中学到的经验，应用到结构相似但具体内容不同的任务上。

举例来说：

• 在“根据会议纪要根据优先级生成待办清单”任务中，Agent 学会了“先提取所有带时间的语句，再按紧急程度排序”；
• 那么在“根据邮件内容生成周报”任务中，Agent 应该能迁移“信息提取 + 结构化输出”的通用策略。

评测时，通常会把任务集分为“训练任务集”和“迁移任务集”，训练任务用于让 Agent 积累经验，迁移任务用于检验经验是否真正泛化。

3.5 稳定性与安全边界（Stability & Safety）

自我改进不是无限吹涨能力，它必须保持在可控边界内。

这个维度重点考察：

• Agent 改进任务 A 的能力时，任务 B 的能力是否发生严重退化？
• 反思机制是否会被恶意输入误导，产生有害行为策略？
• Agent 是否会为了追求评测分数，采取绕过规则的行为？

稳定性与安全边界，决定了自我改进能力能否从评测环境走向真实生产环境。PAST-Bench 这类基准，本质上也是在给 RSI 算法提供一个“安全沙箱”，让改进过程在可控范围内被观察、被测试。

4. 一个最小可运行的“自改进评测”示例

下面我们用 Python 实现一个最小的“自改进评测循环”。这个示例不依赖复杂的 Agent 框架，核心是把评测思路跑通，方便你理解 PAST-Bench 的基本工作方式，也方便在自己项目里扩展。

示例会模拟这样一个场景：

• 任务类型：从一段文本中提取“时间点 + 事项描述”，并按时间先后输出结构化 JSON；
• Agent 流程：先尝试提取 -> 校验结果 -> 失败则记录反思 -> 下一轮结合反思再次执行；
• 评测目标：观察经过多轮学习后，JSON 格式正确率和事项提取的完整率是否提升。

4.1 创建项目结构

首先建立如下目录结构：

past-bench-demo/ ├── agent.py # Agent 基础实现 ├── memory.py # 简单记忆存储 ├── tasks.py # 任务样本 ├── evaluator.py # 评测指标计算 └── main.py # 评测主流程

4.2 实现一个带反思的 Agent

agent.py中实现一个非常简化的 Agent。这里把 LLM 调用封装成一个llm_call函数，方便你在实际环境中替换成 OpenAI、Claude 或本地模型的 SDK。

# agent.py import json import re from typing import Optional from memory import Memory def llm_call(prompt: str) -> str: """ 在实际使用时，请替换为真正的 LLM SDK 调用。 这里演示的是接口约定：输入 prompt，输出文本。 """ # 例如： # import openai # response = openai.chat.completions.create( # model="gpt-4o-mini", # messages=[{"role": "user", "content": prompt}], # ) # return response.choices[0].message.content raise NotImplementedError("请接入实际 LLM 接口") class SimpleAgent: def __init__(self, memory: Memory): self.memory = memory def run(self, task: dict) -> dict: """ 执行一次任务。 task 示例： { "id": "task_001", "text": "明天下午3点开周会，上午10点提交代码审查。", } """ prompt = self._build_prompt(task) output = llm_call(prompt) parsed = self._parse_json(output) # 校验输出格式 if parsed is None: return {"success": False, "error": "json_format_error", "output": output} if not self._validate(parsed): return {"success": False, "error": "content_incomplete", "output": output} return {"success": True, "output": parsed} def reflect_and_store(self, task: dict, result: dict): """ 根据失败结果生成反思，并写入记忆库。 """ if result["success"]: return error_type = result.get("error", "unknown") reflection_prompt = ( f"任务文本：{task['text']}\n" f"模型输出：{result['output']}\n" f"错误类型：{error_type}\n" f"请用一句话说明失败原因，并给出下一步改进建议。" ) reflection = llm_call(reflection_prompt) self.memory.add(task["text"], reflection) def _build_prompt(self, task: dict) -> str: # 从记忆库中检索相似经验，拼接进提示词 related_experiences = self.memory.search(task["text"], top_k=3) memory_block = "\n".join( f"- 经验：{exp}" for exp in related_experiences ) prompt = f""" 你是一个个人任务助手。请从下面的文本中提取所有“时间点 + 事项描述”， 并按照时间先后顺序输出 JSON 数组。 输出格式示例： [ {{"time": "2025-07-01 10:00", "event": "提交代码审查"}}, {{"time": "2025-07-01 15:00", "event": "开周会"}} ] 要求： 1. 时间统一格式化为 YYYY-MM-DD HH:MM。 2. 如果文本中没有明确年份，默认使用 2025 年。 3. 不要输出任何多余内容，只输出 JSON 数组。 文本： {task["text"]} 历史经验（供参考，不要被不相关内容误导）： {memory_block} 请输出 JSON： """ return prompt @staticmethod def _parse_json(output: str) -> Optional[list]: try: # 尝试从输出中匹配 JSON 数组片段 match = re.search(r"\[.*\]", output, re.S) if match: return json.loads(match.group()) return json.loads(output) except json.JSONDecodeError: return None @staticmethod def _validate(parsed: list) -> bool: # 简单校验：非空数组，且每项都包含 time 和 event if not isinstance(parsed, list) or len(parsed) == 0: return False for item in parsed: if not isinstance(item, dict): return False if "time" not in item or "event" not in item: return False return True

这段代码的要点如下：

• run负责执行任务并判断是否成功；
• reflect_and_store是自我改进闭环的关键，它把失败经验写入记忆库；
• _build_prompt会在下一轮任务中把历史经验拼进提示词，从而影响 Agent 行为。

4.3 简单记忆模块

memory.py实现一个极简的记忆存储。真实项目可以用向量数据库，这里用列表和关键词匹配来演示。

# memory.py from typing import List class Memory: def __init__(self): self.items = [] def add(self, task_text: str, reflection: str): self.items.append({ "task_text": task_text, "reflection": reflection, }) def search(self, query: str, top_k: int = 3) -> List[str]: """ 最简单的关键词检索，实际建议使用向量检索。 """ scored = [] for item in self.items: # 这里简化处理：任务文本和 query 有公共词就算匹配 common_chars = set(item["task_text"]) & set(query) score = len(common_chars) / max(len(set(query)), 1) scored.append((score, item["reflection"])) scored.sort(key=lambda x: x[0], reverse=True) return [r for _, r in scored[:top_k]]

这个实现非常粗糙，只为了跑通流程。实际工程中你要用 Embedding + 向量数据库才能做到语义级别的记忆检索。

4.4 评测主流程

tasks.py定义两组任务：一组用于让 Agent 积累经验的train_tasks，一组用于检验迁移能力的eval_tasks。

# tasks.py train_tasks = [ { "id": "train_001", "text": "明天下午3点开周会，上午10点提交代码审查。", }, { "id": "train_002", "text": "周五上午9点进行项目汇报，下午2点与客户对接需求。", }, { "id": "train_003", "text": "下周一之前完成数据分析报告，本周六提前准备PPT。", }, ] eval_tasks = [ { "id": "eval_001", "text": "本周三下午4点面试候选人，上午11点更新招聘进度表。", }, { "id": "eval_002", "text": "月报提交截止时间是每月最后一天晚上8点，月初要安排团队复盘会。", }, ]

evaluator.py定义评测指标：这里我们关注 JSON 格式正确率、抽取完整率。

# evaluator.py def evaluate(agent, tasks): """ 返回： - format_accuracy：JSON 格式正确率 - success_rate：整体任务成功率 """ format_correct = 0 success = 0 total = len(tasks) for task in tasks: result = agent.run(task) if result["success"]: format_correct += 1 success += 1 elif result["error"] == "json_format_error": pass else: success += 0 return { "format_accuracy": format_correct / total, "success_rate": success / total, }

接着是main.py，它把整个“学习 -> 评测 -> 再学习 -> 再评测”的闭环串起来。

# main.py from agent import SimpleAgent from memory import Memory from evaluator import evaluate from tasks import train_tasks, eval_tasks def main(): memory = Memory() agent = SimpleAgent(memory) print("===== 第一轮：冷启动评测 =====") eval_result_1 = evaluate(agent, eval_tasks) print(f"格式正确率：{eval_result_1['format_accuracy']:.2%}") print(f"任务成功率：{eval_result_1['success_rate']:.2%}") print("\n===== 训练阶段：执行任务并积累经验 =====") for task in train_tasks: result = agent.run(task) agent.reflect_and_store(task, result) print(f"任务 {task['id']} 执行结果：{'成功' if result['success'] else '失败'}") print(f"记忆库中积累的经验条数：{len(memory.items)}") print("\n===== 第二轮：完成训练后再评估 =====") eval_result_2 = evaluate(agent, eval_tasks) print(f"格式正确率：{eval_result_2['format_accuracy']:.2%}") print(f"任务成功率：{eval_result_2['success_rate']:.2%}") if __name__ == "__main__": main()

4.5 运行与预期结果

在还没有接入实际 LLM 的情况下，直接运行会抛出NotImplementedError。你需要先实现llm_call函数，或者用一个 mock 函数来观察闭环逻辑。

示例 mock：

# 临时调试用 def llm_call(prompt: str) -> str: return '[{"time": "2025-07-03 09:00", "event": "项目汇报"}]'

接入真实模型后，预期的评估趋势是：

• 第一轮由于没有历史经验，Agent 容易出现格式错误或漏提取，成功率偏低；
• 训练阶段积累的经验会进入提示词；
• 第二轮评估时，成功率和格式正确率应有所提升。

如果两轮评估结果几乎没有差异，说明 Agent 的“反思模块”或“记忆检索模块”没有真正发挥作用，这也是自建评测中最常见的问题。

5. 评测设计中的常见问题与排查思路

在实际落地 PAST-Bench 这类评测基准时，会遇到很多细节问题。下面整理几个高频问题。

下面针对几个核心问题展开细说。

5.1 反思“华丽但无用”

很多反思看似有道理，实际上无法指导下一步行为。

例如反思：“我需要更仔细地处理时间格式，避免格式错误。”

这条反思没有告诉系统具体怎么改。更有效的反思是：“当文本中出现‘明天’时，应该基于当前日期计算出具体日期。建议在提取时间前，先用正则表达式将‘明天’替换为具体日期。”

为了避免低质量反思，建议在反思 prompt 中强制模型输出结构化内容：

请按如下 JSON 格式输出反思： { "failure_step": "提取时间", "cause": "没有将相对日期转换为绝对日期", "action": "提取前先将‘明天’替换为具体日期" }

结构化反思既能提高反思质量，也方便评测算法对反思文本做自动化打分。

5.2 训练集泄露导致“伪改进”

如果评测任务和训练任务过于相似，甚至只有具体数字不同，模型可能只是拟合了任务模板，而不是真正学到了泛化策略。

解决办法是采用“留出任务集”：

• 训练任务集：允许 Agent 执行多次并积累经验；
• 迁移任务集：训练过程中完全不出现，只在评测阶段使用；
• 对抗任务集：故意设计一些容易产生误导的任务，检查 Agent 是否会被错误经验带偏。

只有迁移任务集上的表现也提升了，才能说明 Agent 获得了真正的递归自我改进能力。

5.3 评估成本过高

真实 LLM 评测的 token 成本不可忽视。一个包含“执行 -> 反馈 -> 反思 -> 再执行”的闭环，单任务可能消耗数万 token。

控制成本的常用手段：

• 在调试阶段使用小模型跑通流程，大规模评测时才使用强模型；
• 对失败任务才触发完整反思，成功任务只记录正确轨迹；
• 把相似任务的反思结果做聚合，不要重复生成；
• 设置最大执行轮数，防止 Agent 陷入死循环。

5.4 记忆检索命中率低

示例代码里使用了关键词匹配，真实场景基本不可用。建议使用 Embedding 向量检索。

流程如下：

1. 将反思文本转成向量；
2. 存入向量数据库；
3. 检索时把当前任务文本转成向量，用余弦相似度计算；
4. 返回相似度最高的 top_k 条经验。

用text-embedding-3-large、bge-m3或本地 Embedding 模型都可以。这个模块的检索质量，直接决定了自我改进闭环的最终效果。

6. 工程实践与落地建议

如果说前面的部分是在讲“怎么评测”，那这一节要讲的是“怎么把评测落地到工程里”。

6.1 区分“知识注入”和“技能提升”

个人智能体的改进，可能来自两类不同机制：

• 知识注入：Agent 在任务中读到了新的领域知识，比如“公司报销流程是先在 OA 系统提交申请”；
• 技能提升：Agent 学会了“遇到未知流程时，应先去查询内部文档，而不是直接猜测”。

PAST-Bench 这类基准更关注后者。评测时要尽量把“查询知识”和“调用策略”分离，否则无法判断改进到底来自记忆库扩充，还是来自行为策略优化。

6.2 固定随机种子，保证可复现

大模型推理大多是非确定性的，但评测必须要求可复现。建议：

• 在评测脚本中固定全局随机种子；
• 调用 LLM API 时设置temperature=0；
• 记录每次评测的完整参数，包括模型版本、提示词版本、记忆库版本；
• 多条记录取平均值，避免单次波动影响结论。

6.3 为改进过程加“安全护栏”

在真实项目中，自我改进必须被限制在安全边界内。一个必要的机制是策略审批：

• Agent 自动生成的反思和经验，先写入“候选经验区”；
• 只有当该经验在后续评测中被验证为“确实带来提升”时，才会进入线上记忆库；
• 一旦发现某条经验导致任务成功率下降，立即回滚。

示意的规则如下：

if eval_after >= eval_before: memory.promote(candidate_experience_id) else: memory.reject(candidate_experience_id)

这类似于 A/B 测试的思想，能够防止“越改进越糟糕”的情况。

6.4 完善评测日志

评测日志是定位问题的关键。建议每个任务闭环都记录以下字段：

{ "task_id": "eval_001", "round": 2, "prompt_version": "v1.3", "model": "gpt-4o-mini", "success": true, "execution_time_ms": 5860, "output": "...", "reflection": "...", "memory_hit_count": 2, "error_type": null }

有了完整日志，你才能回答这些问题：

• 第几轮开始成功率提升？
• 哪条经验对结果产生了正面影响？
• 哪类任务的改进效果最差？
• 哪次反思产生了误导？

6.5 迭代式的评测方案

不要试图一次设计出完美评测集。建议从一个小规模原型开始，先跑通闭环，再逐步扩展任务类型。

推荐的迭代路径：

1. 用 10 ~ 20 个任务验证评测闭环能否运行；
2. 实现 Reflection、Memory、Policy Update 三个基础模块；
3. 增加迁移任务集，验证泛化能力；
4. 引入对抗任务集，验证安全边界；
5. 加入指标可视化，追踪多轮改进趋势。

7. 总结与下一步

PAST-Bench 的价值，在于它把“递归自我改进”从口号变成了可评测的工程问题。通过拆解经验抽取、记忆存储、行为调整、跨任务迁移、稳定性与安全边界五个维度，我们可以真正回答一个 Personal Agent 是否在“变强”，以及它的变强过程是否安全可控。

对于正在研究或开发个人智能体的人来说，以下几点值得优先关注：

• 自我改进评测的核心不是最终答案正确率，而是多轮闭环中的能力变化趋势；
• 反思质量决定改进上限，记忆检索质量决定改进下限；
• 必须设计“留出任务集”来排除背题式的伪改进；
• 在生产环境中部署自我改进机制前，一定要先做小范围验证和可回滚设计。

后面如果你打算继续深入，可以从这几个方向入手：向量记忆库的接入、反思质量自动评估模型、多任务对抗评测集设计、以及基于评测结果的策略自动更新管线。

如果你正在搭建自己的 Agent 评测体系，建议先别急着堆复杂框架，把本文第 4 节的最小闭环跑通，再逐步替换成向量记忆、真实模型和更大规模任务集。评测设计这种事，动手实践比一次性看明白更重要。