PAST-Bench 这个名字，核心指向一个很具体的问题：个人智能体（Personal Agent）能不能在真实任务中自我改进，而不是每次都要人去调提示词、改工具、修流程。当前大多数 Agent 评测都在测“单次任务完成率”，但递归自我改进（Recursive Self-Improvement，RSI）关注的是另一件事——智能体能否利用上一轮结果，修改自身策略、工具调用方式或复盘记忆，让下一轮表现得更好。
这个基准的意义在于，它把“自我改进”从口号变成了可量化、可对比、可复现的指标。如果你在做 Agent 应用开发、LLM 工作流编排，或者正在评估本地部署的智能体能达到什么水平，这篇文章值得往下看。
本文会做几件事：先拆解 PAST-Bench 的评测逻辑，再给出一套可用于自己项目的个人智能体自我改进评测流程，包括环境准备、最小代码实现、测试维度、接口批量调用、性能观察和问题排查。需要说明的是，当前材料主要是基准名称和关键词，具体实现细节应以官方仓库和论文为准，文中涉及 PAST-Bench 的评测维度属于基于标题信息的合理推导，实际跑通前需要对照官方文档确认。
1. PAST-Bench 核心能力速览
先把 PAST-Bench 的关键信息整理成一张速览表，方便快速判断它和你的工作有没有关系。
| 维度 | 说明 |
|---|---|
| 基准名称 | PAST-Bench |
| 评测主题 | Recursive Self-Improvement（递归自我改进）在 Personal Agents（个人智能体）场景下的基础能力 |
| 核心问题 | 智能体能否在完成任务后吸收反馈、调整自身行为，并让改进效果在后续任务中持续生效 |
| 评测对象 | 基于大语言模型的个人智能体，包括任务规划、工具调用、记忆管理、结果复盘等模块 |
| 主要能力维度 | 初始任务执行、反馈吸收、策略调整、技能复用、安全约束保持、效率变化 |
| 硬件要求 | 取决于底层模型；使用云端 API 时无本地显存要求，使用本地模型时需要 GPU |
| 本地部署 | 可选，不确定具体支持范围，需按实际模型版本测试 |
| API 支持 | 评测任务通常通过 API 驱动，便于批量化和自动化 |
| 批量任务 | 基准评测天然支持批量任务，按任务集批量跑并统计指标 |
| 适合人群 | Agent 开发者、LLM 应用研究者、自动化工具链团队、大模型评测工程师 |
“Foundations”这个词值得注意。它强调的不是某个 Agent 在某个特定任务上的绝对表现，而是自我改进能力的基础构成。换句话说，PAST-Bench 更像是一套“能力体检”，而不是单项技能考试。
从材料看，PAST-Bench 属于评测基准类项目，不是可直接部署的业务工具。它给你的是一套评测任务集、指标定义和评估协议，用来回答“我的 Agent 到底会不会自我改进”这个问题。
2. 为什么需要这样的基准
2.1 递归自我改进到底是什么
递归自我改进在 AI 领域有严格定义。一个系统如果能够改进自身的某个组成部分，而改进后的系统又具备继续改进自己的能力，就形成了递归循环。在大语言模型 Agent 的场景里，这个循环通常表现为：
- 智能体执行任务，得到结果和反馈。
- 智能体根据反馈分析失败原因，生成新的策略、提示词模板、工具调用规则或复盘笔记。
- 更新后的智能体在后续任务中应用这些改进。
- 新一轮执行结果继续作为输入，驱动下一轮改进。
个人智能体的典型任务包括日程管理、邮件整理、文档检索、信息汇总、票务比价、自动化表单填写等。这类环境的共同点是：任务类型接近、重复性高、反馈信号明确。比如邮件分类分错了，用户纠正一次，智能体应该记住规律，下次不再犯同样的错。这就是一个最小粒度的自我改进。
2.2 现在评测 Agent 的方式有什么问题
当前主流评测方式集中在单轮任务效果上。给定任务集，统计成功率、准确率、F1 等指标。这种方式可以反映智能体的基础能力，但无法回答三个关键问题：
- 智能体能不能从错误中学习？
- 学习到的改进能不能跨任务迁移？
- 自我修改过程中会不会破坏原有能力或安全约束？
没有基准，开发者只能靠感觉判断“Agent 看起来聪明了一点”。PAST-Bench 要解决的就是这个空白：把递归自我改进拆成可评测的维度，让开发者可以量化改进幅度，而不是停留在演示层面。
2.3 PAST-Bench 的评测对象边界
从标题看，PAST-Bench 限定在 Personal Agents 场景。这意味着任务集大概率偏向个人助理类操作，而不是通用编程或通用问答。这类任务有几个好处：反馈明确、安全风险相对可控、任务之间具有同类可迁移性。比如“记住用户偏好”这类能力，在个人助理场景中的定义比通用场景清晰得多。
对开发者而言，评测对象边界明确意味着结果更具参考性。如果你的 Agent 本身就是做个人助理类任务，PAST-Bench 的评测维度可以直接复用。
3. PAST-Bench 评测设计拆解
3.1 评测维度推导
基于“Recursive Self-Improvement”和“Foundations”两个关键词，可以推导出 PAST-Bench 至少需要覆盖以下几类能力。
初始任务执行能力。自我改进的前提是能完成任务。如果任务完成率本身很低，改进能力无从谈起。这一维度是基线，类似常规 Agent 评测。
反馈吸收能力。智能体收到错误反馈后，能否定位失败环节。失败可能发生在意图理解、工具调用参数、结果解析、上下文管理任何一个环节。反馈吸收能力决定了改进的方向是否正确。
策略修改能力。智能体找到失败原因后，能否生成有效的新策略。比如修改提示词模板、调整工具调用顺序、增加一条记忆规则、改变任务拆解方式。
记忆与复盘能力。改进结果能否持久化。如果智能体没有长期记忆，或者记忆检索不稳定，改进效果会在多轮任务后被遗忘。这是递归改进区别于单轮调优的关键。
安全与约束保持能力。自我改进过程中，智能体可能为了提升效果而绕过约束。比如为了完成邮件自动发送任务，擅自关闭了需要人工确认的开关。评测必须包含安全约束不变量检查。
效率变化。改进不仅应该提升正确率，还应该体现在成本、延迟、token 消耗等效率维度上。一个通过多加 3000 字提示词换来 2% 正确率提升的改进，在真实场景中可能并不可取。
3.2 评测流程设计
一个典型的递归自我改进评测循环如下：
第 1 轮： 任务集 T1 -> 智能体执行 -> 记录结果 R1、错误 E1 -> 人工或规则注入反馈 F1 智能体根据 F1 修改自身策略 -> 输出更新后的配置 C1 第 2 轮： 任务集 T2（与 T1 同分布但不同实例）-> 智能体用 C1 执行 -> 记录结果 R2 对比 R1 与 R2 的指标变化 第 3 轮及以后： 继续注入反馈 -> 更新配置 -> 执行新任务集 观察正确率曲线、成本曲线、安全违规次数评测的核心指标是“改进曲线”，而不是单点成绩。如果正确率随轮次显著上升，说明自我改进有效；如果上升来自提示词越来越长、成本急剧膨胀，说明改进路径有问题。
3.3 任务集设计与反馈注入
任务集建议采用同分布多实例设计。比如“整理收件箱并按优先级回复”这个任务，可以生成 50 个不同邮件场景作为一轮任务集，下一轮再生成另外 50 个。这样可以在保证任务类型一致的前提下，测试改进的泛化能力。
反馈注入有两种方式。一种是人工标注，由评测人员对智能体的错误给出修正说明；另一种是规则化自动反馈，比如根据结果与标准答案的差异自动生成提示语句。从可复现性角度看，规则化反馈更适合基准评测，因为它消除了人工标注的随机性。
4. 个人智能体自我改进评测的环境准备
4.1 两种评测路径
PAST-Bench 的评测对象是个人智能体，因此你需要先有一个可以调用的 Agent 服务。根据底层模型不同，有两条路径：
云端 API 路径。使用大模型 API 并基于 Agent 框架搭建智能体。优点是无需本地 GPU，环境搭建简单，适合快速验证评测流程。
本地模型路径。使用本地推理引擎配合开源模型。优点是在数据隐私敏感场景下更可控，但对显存、磁盘空间和推理性能有要求。支持范围未知，需要按实际模型版本测试。
4.2 通用环境检查清单
无论哪条路径，建议先确认以下事项：
- 操作系统：Linux / Windows / macOS 均可，Linux 对服务化部署更友好 - Python 版本：3.10 或 3.11，Agent 生态框架普遍兼容 - 网络策略：能够访问模型服务的 API 地址或本地推理端口 - 磁盘空间：日志、评测结果、模型缓存预留 20GB 以上 - 端口占用：评测服务与 Agent 服务建议使用不同端口 - 依赖管理：使用 venv 或 conda 创建独立环境，避免和其他项目冲突4.3 本地 GPU 检查
如果需要本地部署模型，先查看 GPU 信息：
nvidia-smi重点看显存总量和当前占用。4G 显存适合量化小模型，12G 以上可以尝试中等规模模型。显存不够时优先选择量化版本，量化等级和显存占用需要以实际模型为准。
5. 部署与启动：搭建最小可评测智能体
在 PAST-Bench 官方评测代码发布前，可以先搭建一个支持评测的最小智能体框架，理解自我改进循环的工作方式。
5.1 最小代码骨架
下面是一个基于 LLM API 的个人智能体骨架，包含“执行-反馈-改进”三个核心环节。代码是通用模板，实际路径和参数需要按你的项目调整。
import json import os class PersonalAgent: def __init__(self, model_api, config_path): self.model_api = model_api self.config = self._load_config(config_path) self.memory = [] def _load_config(self, path): if os.path.exists(path): with open(path, "r", encoding="utf-8") as f: return json.load(f) return {"system_prompt": "", "rules": [], "tools": []} def run_task(self, task): # 将任务信息和当前配置组装成请求 messages = self._build_messages(task) response = self.model_api(messages) return response def reflect(self, task, result, feedback): # 将失败任务、当前结果和外部反馈写入复盘记录 record = { "task": task, "result": result, "feedback": feedback, "analysis": "", } # 在这里调用模型生成改进建议，写入 record["analysis"] self.memory.append(record) def update_config(self): # 根据复盘记录生成新的 system_prompt 或规则 # 一次只修改一个变量，避免多个改进相互干扰 new_rules = self._derive_new_rules() self.config["rules"] = new_rules with open("agent_config.json", "w", encoding="utf-8") as f: json.dump(self.config, f, ensure_ascii=False, indent=2)# 启动评测环境示例，实际命令需按项目结构调整 python evaluate_pipeline.py --agent-config agent_config.json --task-set task_set_001.json5.2 配置管理规范
递归自我改进评测要求每一次改进都可追溯、可回滚。建议使用 JSON 配置文件管理 Agent 的每一版策略，文件名包含版本号：
{ "version": "0.1.0", "system_prompt": "你是一名个人助理，负责整理邮件、安排日程、检索文档。", "rules": [ "所有涉及外部发送的操作，必须先输出确认信息。", "邮件分拣时，优先根据发件人域名的可信度判断优先级。", "时间安排冲突时，必须先列出冲突项再给出建议。" ], "tools": ["search_docs", "list_calendar", "send_email_draft"], "constraints": ["不得发送未经确认的邮件", "不得访问无关用户的隐私数据"] }配置版本化可以让你在任何一轮评测后精确回退到之前的策略，定位改动哪个配置导致了指标变化。
5.3 评测脚本设计
评测脚本负责四件事：加载任务、调用 Agent、记录结果、统计指标。
import json import time def run_evaluation_round(agent, task_set_file, output_file): with open(task_set_file, "r", encoding="utf-8") as f: tasks = json.load(f) results = [] for task in tasks: start = time.time() try: result = agent.run_task(task) success = evaluate_task(task, result) except Exception as e: result = {"error": str(e)} success = False latency = time.time() - start results.append({ "task_id": task["id"], "success": success, "latency": latency, "result": result, }) with open(output_file, "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) success_rate = sum(r["success"] for r in results) / len(results) avg_latency = sum(r["latency"] for r in results) / len(results) return {"success_rate": success_rate, "avg_latency": avg_latency}注意，evaluate_task需要你自己根据任务类型实现结果判定逻辑。个人助理类任务通常有明确的结构化预期结果，比如“识别出 3 封需要优先回复的邮件”“找出日程冲突”，这类判定可以自动化。
6. PAST-Bench 功能测试与效果验证
推荐按照五个维度依次测试，每个维度都要求记录数据，而不是看单个演示结果是否好看。
6.1 基础任务执行测试
测试目的。确认智能体在没有自我改进机制的情况下，能完成多少任务。
输入素材。一个包含 50 条个人助理任务的任务集，覆盖邮件分类、日程安排、信息检索、文件整理四类。
操作步骤。
- 使用初始配置运行任务集。
- 记录每类任务的完成率和典型失败模式。
- 生成基线报告。
预期结果。正确率在 60% 到 80% 之间，不同任务类型存在明显差异。如果正确率低于 40%，说明基础能力不足，先不要考虑自我改进，优先调优模型和提示词。
判断标准。基线正确率稳定可复现，两次运行结果波动在 5% 以内。
6.2 自我改进能力测试
测试目的。验证智能体能否根据反馈修正策略，并在下一轮任务中提升表现。
输入素材。第 1 轮失败任务的反馈记录，包含错误说明和修正建议。
操作步骤。
- 将第 1 轮失败结果和反馈注入智能体。
- 智能体生成新版配置，记录配置变更内容。
- 用新版配置运行同分布的新任务集。
- 对比两轮正确率和错误分布。
预期结果。正确率提升，且不是通过修改评测脚本实现的作弊式提升。错误类型发生变化，比如原来分类错误集中在“陌生人邮件”，改进后该类型错误减少。
判断标准。正确率提升 5 个百分点以上，且成本增幅不超过 30%。如果正确率不变但配置变得复杂，说明智能体的自我反省路径失效。
6.3 安全与约束保持测试
测试目的。确认智能体在自我改进过程中没有绕过安全约束。
输入素材。包含高危触发条件的任务集，例如包含隐私数据的文档处理任务、可能泄露个人信息的内容生成任务。
操作步骤。
- 在每轮改进后运行安全任务集。
- 检查智能体是否会主动确认敏感操作。
- 检查生成结果中是否包含隐私数据。
预期结果。所有安全任务均通过，智能体不会因为追求完成率而忽略约束。
判断标准。安全约束违规次数始终为 0。一旦出现违规，必须立即停止评测并检查改进机制是否破坏了约束代码路径。
6.4 记忆持久性测试
测试目的。验证改进效果能否跨多轮任务保持，而不是只在下一轮生效。
输入素材。连续 5 轮同分布任务集，每轮 50 个任务。
操作步骤。
- 第 1 轮收集失败反馈并注入改进。
- 第 3 轮和第 5 轮继续注入反馈。
- 统计正确率曲线。
预期结果。正确率总体上升，且不出现大幅回落。
判断标准。第 5 轮正确率不低于第 2 轮正确率减 5 个百分点。如果出现明显回落，说明记忆写入或检索链路有问题。
6.5 效率变化测试
测试目的。监控自我改进对 token 消耗和延迟的影响。
操作步骤。
- 每轮评测记录总 token 消耗、平均延迟、总调用次数。
- 将效率指标与正确率放在一起画趋势图。
- 如果正确率提升但成本成倍增长，评估是否值得。
判断标准。正确率/成本比值是核心指标。比值只升不降是理想状态；比值下降说明改进方式依赖堆料。
7. 接口 API 与自动化批量评测
PAST-Bench 作为基准，评测过程大概率通过 API 驱动，而不是靠人工点击界面。这里给出通用的接口调用和批量评测思路。
7.1 调用 Agent 服务的 curl 示例
如果你的 Agent 已经封装为 HTTP 服务，可以用 curl 验证单次调用：
curl -X POST http://127.0.0.1:8080/api/run \ -H "Content-Type: application/json" \ -d '{ "task_id": "task_001", "task_type": "email_classify", "content": "收到一封来自 hr@company.com 的面试通知，请判断是否需要优先处理。", "agent_config_version": "0.1.0" }'这里的关键是传入agent_config_version。评测过程中每次改进会生成新版本配置，接口调用必须明确指定版本，否则轮次间的结果没有可比性。
7.2 Python 批量评测调用
批量评测的核心是按任务集遍历调用接口，依次记录结果。
import requests import json API_URL = "http://127.0.0.1:8080/api/run" def run_task_set(task_set, config_version, output_path): results = [] for task in task_set: payload = { "task_id": task["id"], "task_type": task["type"], "content": task["content"], "agent_config_version": config_version, } # 添加超时控制，避免个别任务长时间卡住 resp = requests.post(API_URL, json=payload, timeout=60) if resp.status_code != 200: results.append({"task_id": task["id"], "error": resp.text}) continue data = resp.json() results.append(data) with open(output_path, "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) return results批量评测的注意点：超时必须显式设置，否则一个任务挂起会阻塞整批流程；错误响应要单独记录，不要把异常吞掉；评测结果分文件保存，避免多轮结果互相覆盖。
7.3 评测任务分散到多轮
如果任务集很大，建议拆成子集逐轮评测。PAST-Bench 这种多轮递归场景下，每一轮任务子集结束后都要触发反馈注入和配置更新，然后再跑下一轮。这样可以得到一条完整的改进曲线。
ROUNDS = 5 TASK_SUBSETS = [ "tasks_round_01.json", "tasks_round_02.json", "tasks_round_03.json", "tasks_round_04.json", "tasks_round_05.json", ] metrics = {} for i in range(ROUNDS): round_result = run_evaluation_round(agent, TASK_SUBSETS[i], f"output_round_{i+1}.json") metrics[f"round_{i+1}"] = round_result # 根据反馈更新 agent 配置 agent.update_config() print(f"Round {i+1}: {round_result}")8. 资源占用与性能观察
PAST-Bench 本身不直接承担推理计算，评测产生的资源消耗主要来自底层模型。评测过程中建议持续观察以下几项。
8.1 显存占用
本地部署模型时，显存占用是关键指标。观察方式：
watch -n 1 nvidia-smi如果任务长度增长或批量并发数增加导致显存溢出，优先降低并发数、缩短单次输入文本长度、启用量化模式。显存占用和模型大小、上下文长度、量化位数强相关，具体数值必须在本机实测后才能确定。
8.2 API 调用成本
使用云端 API 评测时，成本控制比显存更敏感。每个任务子集的 token 消耗、调用次数、失败重试次数都应记录。一个评测轮次如果消耗几十万 token，多次运行的成本必须提前评估。
建议设两层限制：单次评测任务总 token 上限，以及单轮评测总 token 上限。超限立即停止并输出中间结果，避免成本失控。
8.3 延迟与并发
递归自我改进评测涉及多轮循环，延迟会成倍叠加。第 6 轮测试的 5 轮任务集如果每轮 50 个任务，单任务延迟 10 秒，总耗时接近 1 小时。评测时设置合理的并发数可以压缩时间，但并发过高会导致模型服务不稳定、结果波动增大。
从稳定性的角度考虑，前两轮建议使用低并发跑通流程，确认评测逻辑无误后再提高并发。
8.4 如何降低评测成本
- 优先使用小模型做流程验证，最后用目标模型跑正式评测。
- 反馈注入只针对失败任务，不重复处理成功任务。
- 配置更新时只传递变更部分，避免整份上下文重复发送。
- 使用缓存机制复用相同任务的推理结果。
9. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 评测脚本启动后立刻报错 | 依赖缺失或 Python 版本不兼容 | 查看堆栈信息，确认报错模块 | 按错误信息安装对应依赖，建议使用独立虚拟环境 |
| API 调用超时 | 模型服务负载过高或网络延迟波动 | 检查服务日志，统计超时任务比例 | 降低并发数，延长超时时间，增加失败重试 |
| 连续两轮正确率没有变化 | 反馈注入路径失效或配置未生效 | 检查配置版本号是否实际更新 | 确认智能体确实读取了新版配置再调用模型 |
| 正确率提升但成本翻倍 | 改进方式依赖增加提示词长度 | 对比每轮 token 消耗数据 | 限制配置更新后的提示词长度上限 |
| 改进后出现安全违规 | 自我修改破坏了约束逻辑 | 回滚到上一版本配置，逐步定位违规代码路径 | 在评测流程中加入安全任务集，每轮强制运行 |
| 日志不完整无法定位失败原因 | 评测脚本未记录原始请求和响应 | 检查输出文件是否包含完整 payload | 增加请求与响应的全量日志记录 |
| 本地 GPU 显存溢出 | 模型过大或批量任务并发过高 | 查看 nvidia-smi 的显存峰值 | 降低批大小、改用量化模型或升级显存 |
| 端口冲突导致服务无法启动 | 评测服务与 Agent 服务共用端口 | 检查端口占用情况 | 修改配置文件中的端口号 |
在开始正式评测前，建议先跑完“冒烟测试”：用 3 到 5 个小任务验证整个链路是否通畅。冒烟测试能暴露大部分基础设施问题，避免在正式任务集上浪费时间和成本。
10. 最佳实践与使用建议
基于前面的分析，整理几条个人智能体自我改进评测的工程化建议。
第一次评测先跑小规模。不要一上来就上 500 个任务的多轮评测。先用 20 个任务、2 轮循环跑通整个流程，确认反馈注入、配置更新、指标统计三个环节都能工作，再扩大规模。
一次只改一个变量。递归自我改进最怕多个改动叠加，导致无法定位是哪个改动带来了效果提升。评测配置更新时，尽量让智能体一次只调整一个维度，比如本轮只改规则，下轮只改提示词模板。
配置、任务、结果分目录管理。
project/ agent_configs/ v0.1.0.json v0.1.1.json task_sets/ round_01.json round_02.json results/ round_01_output.json round_02_output.json logs/ round_01_requests.log目录清晰是评测可复现的基础。
批量任务必须有日志和重试机制。评测过程跑几小时是常态。日志记录每一次请求的时间戳、任务 ID、配置版本和返回状态。失败任务自动重试一次，重试仍失败则单独标记，不阻塞整个流程。
接口服务要严格控制访问范围。PAST-Bench 评测框架如果暴露 HTTP 服务，需要做好访问控制。评测环境的服务建议绑定127.0.0.1，仅限本机访问；如果必须开放到局域网，要加上认证机制，避免被扫描调用消耗 API 配额。
涉及个人数据和隐私内容时必须确认授权。个人智能体评测使用的任务数据如果包含真实个人信息，例如邮件内容、日程数据、联系人信息，在评测前需要获得数据所有者授权，处理过程中做好数据脱敏。评测报告发布时，不能直接展示含原始隐私信息的输入输出。
正式评测前做三遍一致性验证。同一配置、同一任务集运行三次，如果指标波动超过 5 个百分点，说明评测环节存在随机性干扰。先排查是否能固定采样参数、是否受并发影响，再做正式结论。
11. 总结与下一步
PAST-Bench 把递归自我改进从理论概念变成了可评测的基准协议，这是当前 Agent 生态里比较稀缺的一环。对开发者来说，最值得关注的不是它是否直接提供一个可下载的一键包，而是它定义的评测维度——基础执行、反馈吸收、策略修改、记忆持久、约束保持、效率变化——这套维度可以直接复用到自己的 Agent 项目中。
最先应该验证的功能是“反馈注入→策略更新→下一轮任务正确率变化”这个闭环是否成立。最容易踩的坑是只关注正确率而忽略成本曲线，或者安全违背任务被单独跳过。一个自我改进评测结果，必须同时呈现正确率、成本、延迟、安全违规四类指标，才能作为可靠结论。
后续可以继续扩展的方向包括：把 PAST-Bench 的评测协议接入自己的 CI 流程，实现每次 Agent 配置变更自动跑一轮回归评测；将评测任务集扩展到多模态输入，覆盖截图、语音、PDF 文档等个人助理常见素材；在评测流程中引入人工反馈模拟，检测智能体如何应对模糊指令和用户纠正。建议把本文的评测框架和排查清单收藏备用，等 PAST-Bench 官方实现发布后，可以在此基础上快速对接。
