就没有这种需求的产品？或者方案？你别偷懒

有，而且不止一个。上一轮我没搜充分，漏掉了直接符合你需求的方案。按“自身运行轨迹 → 提炼或修改行为 → 后续使用，并尽可能有评测闭环”筛，最值得看的是这些。 一、Reef：最贴近“给已有 Agent 接持续自改进后端” https://github.com/Human-Agent-Society/reef 它的 harness_evolve 不是定时派活，而是： 记录 Agent 实际交互 → 关联任务评分和文字反馈 → 生成新的 harness → 在配置的任务上比较新旧版本 → 候选胜出才发布。 修改对象包含 rules、Skills、配置、提示词和扩展，不局限于记忆，也不必训练模型权重。 官方已有 Pi 适配示例：用 reef-pi 执行修 bug 任务，跑测试后报告“漏掉空 token 情况”等反馈；后端用对应交互生成改进版本。适配器下次启动时检查更新，交互会话由用户选择是否更新，并非静默覆盖。 这就是你说的“用自己的执行经历改善自己”，而且有候选评测、版本管理和发布环节。 边界：它是需要部署和配置的基础设施，不是装上便能无监督变强。反馈、评测任务和演化 recipe 仍要接好。README 有独立的 harness 演化路线，不应把模型训练路线的 GPU 要求套到所有用法上。 二、Memento-Skills / Memento-S：已经有桌面产品的学习型 Agent https://github.com/Memento-Teams/Memento-Skills 这个更直接回答你“有没有产品”：官方已提供 Windows、macOS 桌面应用，不只是论文。 当前公开 runtime 明确描述了这条链： 任务执行失败 → 根据失败 trace 归因到某个 Skill → 隔离修改该 Skill → 静态检查、单元测试和合成测试 → 原子部署或回滚。 同时支持在缺少能力时创建并持久化新 Skill。它的 Read → Execute → Reflect → Write，把读取、执行、反思和写回放在同一个运行时里。 例如某个文件处理 Skill 因参数假设错误反复失败，它要做的不只是当场重试，而是定位和修复 Skill，检查通过后留下新版本供以后使用。 边界：公开实现强调“归因到单个 Skill 的受控修复”，不是任意重写整个 Agent。论文研究配置的成绩，也不能直接当作桌面产品的效果保证。 三、Reflexio：给现有 Agent 加学习层，也有托管产品 https://github.com/ReflexioAI/reflexio https://reflexio.ai/ 它接收真实会话，抽取用户纠正和成功执行策略，形成持久化 playbook；后续任务检索复用。重复出现的经验还可以聚合成共享 Agent playbook，经过审批再使用。 例如部署任务被纠正“生产环境不能用这个区域”，它不只是保存一句聊天记录，还会提炼出“部署前确认区域”这样的执行规则。成功完成的多步路径也可保留下来。 已有 SDK、CLI、自部署服务和托管入口；还提供会话成功评估、工具使用问题分析及 shadow 对比。 边界：它更偏“从交互和执行经验学习操作手册”，不是自动修改整个代码仓库。接入方仍需把检索结果应用到 Agent 上，不能把“有评估模块”直接等同于“每条改动都经过回归测试才能上线”。 四、Hermes Agent 本体：上一轮我漏查了本体，只盯着 self-evolution 扩展 https://github.com/NousResearch/hermes-agent 本体 README 已明确写了：复杂任务后自主创建 Skill、使用过程中改进 Skill、持久化经验，以及检索自己过往会话。 所以，不能因为独立 self-evolution 仓库里某条持续流水线仍是 Planned，就推断 Hermes 整体没有从自身经历学习的能力。 边界：本体的经验学习与 Skill 改进，不应直接等同于 GEPA 那种候选优化和严格评测筛选闭环。 你的需求不是没有对应项目：想在已有 Agent 上接“轨迹＋反馈→修改 harness→评测→发布”，优先看 Reef；想直接用带失败 trace 修复闭环的 Agent 产品，优先看 Memento-S。上面是按项目当前公开文档核实的能力，不是我实测后的稳定性背书。