PAST-Bench 这个名字核心指向一个很具体的问题个人智能体Personal Agent能不能在真实任务中自我改进而不是每次都要人去调提示词、改工具、修流程。当前大多数 Agent 评测都在测“单次任务完成率”但递归自我改进Recursive Self-ImprovementRSI关注的是另一件事——智能体能否利用上一轮结果修改自身策略、工具调用方式或复盘记忆让下一轮表现得更好。这个基准的意义在于它把“自我改进”从口号变成了可量化、可对比、可复现的指标。如果你在做 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.11Agent 生态框架普遍兼容 - 网络策略能够访问模型服务的 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, encodingutf-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, encodingutf-8) as f: json.dump(self.config, f, ensure_asciiFalse, indent2)# 启动评测环境示例实际命令需按项目结构调整 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, encodingutf-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, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) 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: 收到一封来自 hrcompany.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, jsonpayload, timeout60) 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, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) 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], foutput_round_{i1}.json) metrics[fround_{i1}] round_result # 根据反馈更新 agent 配置 agent.update_config() print(fRound {i1}: {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 官方实现发布后可以在此基础上快速对接。 PAST-Bench 个人智能体递归自我改进评测基准解析与实操
PAST-Bench 这个名字核心指向一个很具体的问题个人智能体Personal Agent能不能在真实任务中自我改进而不是每次都要人去调提示词、改工具、修流程。当前大多数 Agent 评测都在测“单次任务完成率”但递归自我改进Recursive Self-ImprovementRSI关注的是另一件事——智能体能否利用上一轮结果修改自身策略、工具调用方式或复盘记忆让下一轮表现得更好。这个基准的意义在于它把“自我改进”从口号变成了可量化、可对比、可复现的指标。如果你在做 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.11Agent 生态框架普遍兼容 - 网络策略能够访问模型服务的 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, encodingutf-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, encodingutf-8) as f: json.dump(self.config, f, ensure_asciiFalse, indent2)# 启动评测环境示例实际命令需按项目结构调整 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, encodingutf-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, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) 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: 收到一封来自 hrcompany.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, jsonpayload, timeout60) 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, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) 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], foutput_round_{i1}.json) metrics[fround_{i1}] round_result # 根据反馈更新 agent 配置 agent.update_config() print(fRound {i1}: {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 官方实现发布后可以在此基础上快速对接。