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

在做个人智能体Personal Agent相关开发时有一个很容易被忽略但又非常关键的问题Agent 在完成一次任务之后下次遇到同类任务会不会做得更好也就是说智能体是否真的从历史经验中获得了成长还是每次都在重复同样的错误。大多数传统 Benchmark 只评测“模型在某个时间点的最终表现”却不关心“模型是否具备自我改进的能力”。PAST-Bench 这个名字的提出正是为了把“递归自我改进Recursive Self-Improvement”这个偏学术的概念落地成一个可量化、可复现、可对比的评测体系。这篇文章会围绕以下几个方面展开什么是 Personal Agents什么是递归自我改进PAST-Bench 评测基准的核心设计思路评测“自我改进能力”需要拆解哪些基础维度给出一个最小可运行的“自改进评测循环”示例梳理自建评测基准时的常见坑与最佳实践。不管你是正在做 Agent 应用的后端开发者还是对大模型评测感兴趣的算法工程师这篇文章都能提供一套可以直接参考的评测设计与落地思路。1. 背景个人智能体正在从“会聊天”走向“会改进”1.1 什么是 Personal AgentsPersonal Agents也就是个人智能体是指一类以个人用户为中心、能够帮助用户完成实际任务的 AI 系统。它不同于单纯的聊天机器人它的核心特征是能调用工具、能执行操作、能完成多步任务。常见的 Personal Agents 应用包括自动整理邮件并生成摘要根据日程安排自动规划会议读取本地文档后回答用户问题编写代码、执行测试并修复错误自动搜集信息并生成调研报告。在技术实现上Personal Agents 一般由以下几部分组成模块作用大语言模型负责理解指令、生成推理、输出动作工具调用层连接搜索、计算、文件操作、API 等外部能力记忆模块保存用户偏好、历史对话、任务状态执行引擎编排多步任务处理中间结果反馈模块收集执行后的奖惩信号用于后续改进早期 Agent 系统大多是“静态”的模型参数固定提示词固定工具列表固定。也就是说无论 Agent 运行多久它的行为模式不会因为经验而改变。这种系统适合完成结构清晰、复杂度低的固定任务但很难适应真实世界的多样性和不确定性。1.2 什么是递归自我改进RSI递归自我改进Recursive Self-Improvement简称 RSI指系统能够利用自身的输出结果和外部反馈持续调整自己的行为策略从而在后续任务中取得更好表现。“递归”体现在系统改进后的策略会影响它下一次如何收集经验而新一轮的经验又会被用于下一轮改进。这个过程可以反复迭代形成一个持续上升的改进闭环。放到 Personal Agents 场景里一个最简单的 RSI 闭环是这样的Agent 接收任务Agent 执行一系列动作并得到结果外部环境或用户给出反馈比如任务是否成功、执行耗时、结果质量Agent 将“任务描述、动作轨迹、结果反馈”沉淀为经验在下一轮执行同类任务时Agent 参考历史经验生成更优的策略。这个过程听起来很美好但实际落地时存在一个核心难题怎么判断一个 Agent 真的“改进”了而不是碰巧这次运气好如果评测任务只有两三个固定题目模型可能只是记住了答案并没有获得真正的泛化能力。因此我们需要一个专门的基准测试来系统性地回答“Agent 是否具备递归自我改进能力”这个问题。1.3 为什么需要专门的 Benchmark在 AI 领域Benchmark 的作用不只是排名更重要的是界定能力边界。传统评测基准例如常见的知识问答、代码生成、数学推理数据集通常只关注“给定输入模型能否给出正确答案”。这种评测方式有两个局限单次快照只测模型当前状态不测变化趋势静态任务任务列表固定模型不具备从任务执行中学习的机制。而 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 的评测单元不是“一道题”而是一个“完整的学习任务闭环”。一个闭环通常包含以下几个阶段初始化阶段给出任务环境、初始提示词、可用工具列表第一次执行阶段Agent 完成任务记录动作序列和结果反馈阶段系统返回任务成功/失败以及细粒度的中间结果评价反思与经验生成阶段Agent 根据反馈生成结构化经验例如“我因为遗漏了日期格式校验导致任务失败下次应先格式化日期再计算”存储阶段把经验写入长期记忆库再次执行阶段Agent 使用更新后的记忆库重新执行同类或相关任务对比评估阶段比较前后执行的成功率、任务效率、错误类型分布等指标。通过这种闭环设计PAST-Bench 把“自我改进”从一句口号变成了可以被指标观测的工程过程。2.3 与传统评测基准的差异理解了单任务闭环之后就能看清 PAST-Bench 与传统评测的差异了。对比维度传统 BenchmarkPAST-Bench评测对象模型静态能力Agent 动态改进能力任务形式单轮问答多轮闭环学习是否允许读取历史经验否是核心指标准确率、BLEU、F1改进幅度、迁移能力、稳定性是否关注失败模式变化较少重点关注是否考虑安全边界较少必须考虑也就是说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 的基本工作方式也方便在自己项目里扩展。示例会模拟这样一个场景任务类型从一段文本中提取“时间点 事项描述”并按时间先后输出结构化 JSONAgent 流程先尝试提取 - 校验结果 - 失败则记录反思 - 下一轮结合反思再次执行评测目标观察经过多轮学习后JSON 格式正确率和事项提取的完整率是否提升。4.1 创建项目结构首先建立如下目录结构past-bench-demo/ ├── agent.py # Agent 基础实现 ├── memory.py # 简单记忆存储 ├── tasks.py # 任务样本 ├── evaluator.py # 评测指标计算 └── main.py # 评测主流程4.2 实现一个带反思的 Agentagent.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( # modelgpt-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_k3) 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(keylambda x: x[0], reverseTrue) 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_accuracyJSON 格式正确率 - 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 这类评测基准时会遇到很多细节问题。下面整理几个高频问题。问题现象常见原因解决思路多轮训练后准确率没有提升反思结果没有被后续 prompt 利用检查记忆检索是否命中了相关内容训练任务准确率很高测试任务提升很小模型记住了训练任务模板发生了“背题”增加与训练任务结构不同但语义相近的迁移任务某一类任务能力提升另一类任务能力明显下降经验过多导致提示词信息过载或新经验覆盖了旧经验控制 top_k加入记忆时效性权重定期清理过期经验模型出现格式不稳定的输出JSON 解析逻辑过于严格先正则提取 JSON 片段再解析不要直接 json.loads 原始输出评测结果波动大大模型采样随机性影响设置 temperature0多次重复评测取平均反思内容千篇一律反思 prompt 没有要求结构化输出要求反思包含“失败环节”“失败原因”“下次动作建议”三个字段下面针对几个核心问题展开细说。5.1 反思“华丽但无用”很多反思看似有道理实际上无法指导下一步行为。例如反思“我需要更仔细地处理时间格式避免格式错误。”这条反思没有告诉系统具体怎么改。更有效的反思是“当文本中出现‘明天’时应该基于当前日期计算出具体日期。建议在提取时间前先用正则表达式将‘明天’替换为具体日期。”为了避免低质量反思建议在反思 prompt 中强制模型输出结构化内容请按如下 JSON 格式输出反思 { failure_step: 提取时间, cause: 没有将相对日期转换为绝对日期, action: 提取前先将‘明天’替换为具体日期 }结构化反思既能提高反思质量也方便评测算法对反思文本做自动化打分。5.2 训练集泄露导致“伪改进”如果评测任务和训练任务过于相似甚至只有具体数字不同模型可能只是拟合了任务模板而不是真正学到了泛化策略。解决办法是采用“留出任务集”训练任务集允许 Agent 执行多次并积累经验迁移任务集训练过程中完全不出现只在评测阶段使用对抗任务集故意设计一些容易产生误导的任务检查 Agent 是否会被错误经验带偏。只有迁移任务集上的表现也提升了才能说明 Agent 获得了真正的递归自我改进能力。5.3 评估成本过高真实 LLM 评测的 token 成本不可忽视。一个包含“执行 - 反馈 - 反思 - 再执行”的闭环单任务可能消耗数万 token。控制成本的常用手段在调试阶段使用小模型跑通流程大规模评测时才使用强模型对失败任务才触发完整反思成功任务只记录正确轨迹把相似任务的反思结果做聚合不要重复生成设置最大执行轮数防止 Agent 陷入死循环。5.4 记忆检索命中率低示例代码里使用了关键词匹配真实场景基本不可用。建议使用 Embedding 向量检索。流程如下将反思文本转成向量存入向量数据库检索时把当前任务文本转成向量用余弦相似度计算返回相似度最高的 top_k 条经验。用text-embedding-3-large、bge-m3或本地 Embedding 模型都可以。这个模块的检索质量直接决定了自我改进闭环的最终效果。6. 工程实践与落地建议如果说前面的部分是在讲“怎么评测”那这一节要讲的是“怎么把评测落地到工程里”。6.1 区分“知识注入”和“技能提升”个人智能体的改进可能来自两类不同机制知识注入Agent 在任务中读到了新的领域知识比如“公司报销流程是先在 OA 系统提交申请”技能提升Agent 学会了“遇到未知流程时应先去查询内部文档而不是直接猜测”。PAST-Bench 这类基准更关注后者。评测时要尽量把“查询知识”和“调用策略”分离否则无法判断改进到底来自记忆库扩充还是来自行为策略优化。6.2 固定随机种子保证可复现大模型推理大多是非确定性的但评测必须要求可复现。建议在评测脚本中固定全局随机种子调用 LLM API 时设置temperature0记录每次评测的完整参数包括模型版本、提示词版本、记忆库版本多条记录取平均值避免单次波动影响结论。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 迭代式的评测方案不要试图一次设计出完美评测集。建议从一个小规模原型开始先跑通闭环再逐步扩展任务类型。推荐的迭代路径用 10 ~ 20 个任务验证评测闭环能否运行实现 Reflection、Memory、Policy Update 三个基础模块增加迁移任务集验证泛化能力引入对抗任务集验证安全边界加入指标可视化追踪多轮改进趋势。7. 总结与下一步PAST-Bench 的价值在于它把“递归自我改进”从口号变成了可评测的工程问题。通过拆解经验抽取、记忆存储、行为调整、跨任务迁移、稳定性与安全边界五个维度我们可以真正回答一个 Personal Agent 是否在“变强”以及它的变强过程是否安全可控。对于正在研究或开发个人智能体的人来说以下几点值得优先关注自我改进评测的核心不是最终答案正确率而是多轮闭环中的能力变化趋势反思质量决定改进上限记忆检索质量决定改进下限必须设计“留出任务集”来排除背题式的伪改进在生产环境中部署自我改进机制前一定要先做小范围验证和可回滚设计。后面如果你打算继续深入可以从这几个方向入手向量记忆库的接入、反思质量自动评估模型、多任务对抗评测集设计、以及基于评测结果的策略自动更新管线。如果你正在搭建自己的 Agent 评测体系建议先别急着堆复杂框架把本文第 4 节的最小闭环跑通再逐步替换成向量记忆、真实模型和更大规模任务集。评测设计这种事动手实践比一次性看明白更重要。