编者摘要：传统代码智能体只能在单次会话内工作，处理完一个工单，进程退出，所有踩坑经验随之消失。本文核心目标：如何在不微调大模型权重的前提下，让代码 Agent 持续学习历史任务教训，也就是构建带记忆的自演化 Harness。

Harness 就是包裹大模型的运行时骨架，负责提示词构建、工具调度、结果收集、上下文压缩。Pi 和 Hermes 是两套典型开源实现。Pi 主打轻量化，支持 TS 钩子、分层指令文件、会话树恢复；Hermes 用 SQLite 存储会话，三层提示词架构保障缓存效率。原生版本二者都缺少跨任务学习能力，直到引入第二写入器，框架才具备自演化能力。第二写入器独立于基础工具循环，专门负责把任务轨迹提炼成可复用知识，持久保存。

Hermes 采用后置写入策略：任务成功后派生独立子 Agent，按固定频次更新 MEMORY.md、SKILL.md，写入动作可人工审批，只修改配置文档，不动框架源码。Prime Agent 基于 Pi 构建，使用 /refine 模块，任务进行中实时提炼经验，维护 4 类持久化对象，支持版本快照回滚。两条路线共同点：主程序代码不变，知识以文件形式外挂。

文章着重澄清业界经常混淆的三类方案。Live-SWE 属于任务内工具生成：Agent 在解决问题时编写自定义脚本，辅助代码分析，但脚本只存在临时目录，任务结束即删除，无法复用。Hermes、Prime 属于知识外挂路线，将经验固化为文件，新会话启动加载，模型可以读取历史经验。DGM 是框架代码迭代路线：父 Agent 复制自身源码，修改副本，沙箱评估子代框架，维护版本归档，直接迭代 Harness 本身，代价昂贵。

工程上三种持久化载体适用场景完全不同：归档 Git 用于保存 Harness 版本；经验备注是简短事实，适合存入记忆库 Mem0，如 pnpm-lock 不可覆盖这类仓库规则；SKILL.md 是操作流程文档，实验证明：解题前让 Agent 生成技能包通常有害，只有任务成功后提取的技能才能带来指标提升。

评测数据显示，Live-SWE 借助每步反思，SWE-bench 子集提升至 76%，但知识无法复用；人工编写技能能显著提升性能，Agent 前置生成技能反而拖累效果；DGM 离线迭代虽然把 SWE-bench 拉到 50%，但评估成本高昂。工程落地推荐：短经验备注存入 Mem0，人工优质技能以文件托管；谨慎使用 Agent 自动写 SKILL.md；DGM 仅适合科研，不适合生产。 核心结论：自演化 Harness 的本质不是让模型更强，而是增加独立写入组件，将单次任务经验持久化，打通跨会话知识复用。

10 个 Q&A（聚焦易混淆概念）

Q1：什么是 Harness？

A：Harness 是代码智能体的执行框架，由冻结的基础大模型 + 调度程序组成。负责构建 prompt、管理工具、执行模型输出、追加工具返回结果、压缩上下文。Cursor、Pi、Hermes 都属于 Harness，底层基础循环一致，复杂度不同。

Q2：什么是「第二写入器」？

A：基础 Harness 只有读取 + 执行工具的主循环；第二写入器是新增独立模块，负责读取任务交互轨迹，提炼经验并写入持久存储（文件 / 记忆库），供下一次任务加载。Hermes 的 fork 子 Agent、Prime 的 /refine 模块，都是第二写入器。

Q3：Live-SWE 是自演化 Harness 吗？

A：不算完整自演化 Harness。Live-SWE 允许 Agent 在任务内临时编写脚本工具，但脚本放在 /tmp，任务结束进程销毁，工具直接丢弃，经验不能跨工单复用。仅增强单次任务能力，不满足持久化这个核心判定条件。

Q4：Hermes 的自演化原理是什么？

A：Hermes 不会修改自身主程序代码。任务成功结束后 fork 子智能体，定期生成 / 更新 MEMORY.md、SKILL.md；写入可开启审批，下一轮会话加载这些文件，给模型注入历史经验。框架不变，外挂持久化知识。

Q5：DGM 和 Hermes 的核心差别？

A：Hermes：不改 Harness 源码，只写知识文档。DGM：直接修改 Harness 本身代码，复制生成子代框架版本，在沙箱评估，维护版本归档，迭代框架程序。DGM 成本极高，属于离线科研方案，Hermes 偏向工程可用。

Q6：三类持久化分别是什么，能不能混用？

A：三者不可互换。①归档 Git：存储 Harness 版本、评估日志，DGM 用；②经验备注：简短事实规则，存入 Mem0；③SKILL.md 技能：长流程操作文档。用途不同，不能互相替代。

Q7：SKILL.md 什么时候能提升效果，什么时候起反作用？

A：任务成功后，从已通过轨迹提取的技能，带来正向提升。在解题前，让 Agent 提前生成技能包，大概率降低指标，存在技能错误、冗余、泄露任务等问题（SkillsBench 结论）。

Q8：Mem0 适合存放什么，不适合存放什么？

A：适合：简短仓库约定、失败经验备注。不适合：完整对话日志、单次任务临时脚本、任务前置自动生成的 SKILL.md。Mem0 设计用来存短事实，不是存储全量会话或者大流程技能。

Q9：怎么判断一个 Agent 是不是真正自演化？

A：判定核心：本次任务学到的经验，持久保存在进程外存储，新工单启动时可以读取复用。只在当前任务生命周期生效、进程销毁就丢失改进，不属于自演化。

Q10：为什么很多论文里的评测指标容易被混淆？

A：因为三类方案被混为一谈。Live-SWE 指标是单次任务临时工具增强；Hermes 是外挂记忆文件；DGM 是迭代框架源码。三者评测目标、成本、能力边界完全不同，直接拼接对比数字会造成误解。

附录 具备记忆能力的自演化执行框架（Self Evolving Harness With Memory）

如何让你的代码智能体，在处理下一个 Linear 工单 / 任务时表现更好，且不需要微调模型？

我的意思是：我们是写一些备注？在AGENTS.md里新增一条规则？还是针对场景创建一项技能？我们大多数人都在做这件事，只是没有专门命名 —— 我们不断优化这套运行框架，避免它第二天再犯同样的错误，这个框架就是Harness（智能体执行框架）。

Cursor 发布文章： https://cursor.com/blog/continually-improving-agent-harness 后续又发布《自驱动代码库》https://cursor.com/blog/self-driving-codebases，研究团队在浏览器里运行实验，查看日志后调整智能体角色。 OpenAI 发布《拆解 Codex 智能体循环》https://openai.com/index/unrolling-the-codex-agent-loop/，把整套流程整理成可复现的步骤。 Anthropic：《为真实世界的智能体配备智能体技能》https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills。

而今天我真正想聊的：一套自演化的执行框架，以及记忆在其中所处的位置

通用执行框架（General Harness）

一个通用执行框架的结构：代码智能体 = 固定基座模型 + 和模型交互的程序。 每一轮交互中，这个程序会：

1. 构建提示词
2. 列出可用工具
3. 执行模型请求的操作
4. 追加执行结果，然后做摘要或者终止任务

简单概括，这就是 Harness。

Claude Code、Codex、Cursor、Pi、Hermes 都使用完全相同的循环逻辑，只是框架复杂度不同。下面两个是我们可以直接开源查看的实现。

Pi

https://pi.dev/ Pi 是极简版执行框架，我很喜欢它这一点。 官网描述：让 Pi 帮你构建项目，或者安装自定义包，按你的方式运行。

核心工具：读取、写入、编辑、bash 命令。 循环逻辑：推理 → 调用工具 → 观察结果 → 再次推理

框架挂载 4 类组件：

• 扩展
  TypeScript 钩子：agent/pre-step、agent/request、工具开始 / 结束钩子。记忆会在下一轮推理步骤前注入。摘要压缩策略支持替换。
• 技能（Skills）
  参考 https://agentskills.io/ 规范。提示词里只放技能名称，只有选中某个技能时才加载完整文件，以此保证缓存命中率。
• 提示词模板
  /名称会加载对应 markdown 文件。
• 主题
  终端 UI 界面，不是核心重点。

指令以文件形式管理：全局AGENTS.md，上层目录配置，当前工作目录配置。SYSTEM.md可以替换或追加系统提示词。会话采用树状结构，可以用/tree恢复任意历史节点。 上下文压缩策略：保留最近约 20k 原始 token，更早内容做摘要压缩。

同一套运行时，可以对外提供终端交互、JSON 接口、RPC 调用、SDK。SDK 这点非常关键：只支持交互式使用的执行框架，无法接入外层自动化自优化循环。

官方原生 Pi 不会在打分评估后重写自身代码，它只暴露扩展接口。自优化循环需要额外安装软件包实现。后面我们再聊这个仓库。

Hermes

Nous Research 的 Hermes：https://github.com/NousResearch/hermes-agent 框架更厚重，但底层循环不变。

run_conversation函数逻辑：接收任务 ID，追加用户消息，构建 / 复用缓存系统提示词。如果历史消息超过上下文上限一半，先做压缩。按照模型服务商格式封装消息（Chat Completions、Codex 响应、Anthropic 消息格式），注入临时 token 预算警告、上下文压力提示。调用模型，执行工具调用，追加结果，循环执行。文本会话持久化，刷新记忆，返回结果。

提示词分为三层：

1. 稳定层：身份描述、工具定义、技能索引
2. 上下文层：当前目录下的AGENTS.md
3. 易变层：记忆快照、用户配置、时间戳

压缩时会重建提示前缀，维持缓存热启动。会话存储在 SQLite，支持检索。压缩会关闭当前会话，生成子会话，因此会话具备谱系，而不是单一被不断覆写的文本块。 工具由注册器 + 访问白名单管理。默认最大迭代次数 500，支持子智能体，父进程退出子智能体也会终止。

这依然是通用执行框架，还没有实现自演化。

两个框架本质上在做什么

它们都在决定模型本轮能看到哪些内容。模型看不到完整代码仓库，只能看到一段 token 文本窗口。

举个例子：Node 项目安装依赖反复覆盖pnpm-lock.yaml，第 17 轮交互，进程已经运行 20 分钟。 窗口左侧是稳定内容，可以被缓存：系统提示词、工具定义、AGENTS.md。 然后加上备注：本仓库锁定 lockfile 文件，不要重新生成。 再加上摘要：对第 1~11 轮对话做压缩，原始对话从窗口中移除。 最后是未压缩的末尾对话和最新 bash 输出。

如果这条 lockfile 相关经验，没有写入下一次进程可以读取的位置，下一个工单启动时对话是空的，就会再次触发同样的 npm 安装错误。放在/tmp的临时辅助文件会随进程销毁。 如果经验没有持久化到磁盘、无法被新进程读取，那这次学习就等于没发生。而第二个写入器，就是负责写入这段 token 窗口内容的组件。

如何实现自演化？

Hermes（续）

在上面两个框架基础上，增加外层循环，这就是 Hermes 所说的学习能力。 在一轮完整成功交互后，可以 fork 出一个独立子智能体运行：

• 大约每 10 次用户交互，可以写入MEMORY.md或USER.md
• 如果开启技能工具，大约每 10 次工具调用，可以创建 / 修改SKILL.md

fork 出的子智能体继承缓存后的系统提示词，官方测算成本降低约 26%。子智能体仅能使用记忆、技能工具，最多运行 16 轮迭代；不能修改仓库文件，也不能修改run_conversation的 Python 源码。 文档定义优先级：优先修补已加载内容，然后补充下层文件，最后创建新技能。 可以开启写入审批闸门，修改 diff 暂存到~/.hermes/pending/目录。

下一次会话启动时，会加载这些文件；框架主程序代码本身保持不变。 在这套体系中：记忆是少量持久化事实，放在上下文里；技能是按需加载的长流程文档。

交互轨迹写入文件，供后续会话读取；打分由评估模型（可加入人工审核）完成，不是代码基准测试。

Pi（续）

原生 Pi 本身没有内置这套 fork 自优化逻辑。Prime Intellect 在 Pi 之上构建了 Prime Agent，README 里有说明：https://www.primeintellect.ai/blog/prime-agent

模型访问工具变成持久化 IPython 内核。文件操作、shell、技能、子智能体都只是 Python 调用。上下文是程序变量，不只是聊天记录。子智能体通过rlm(task)异步句柄创建。TypeScript 宿主负责模型调用、会话管理、子智能体生命周期、安全管控。

新增持续优化框架，四类存储都支持增删改查：提示备注、子智能体定义、技能、记忆。内核里的对象和磁盘文件保持同步，即rlm.harness。

/refine是新增的写入模块。后台智能体读取完整交互轨迹，对四类存储做最小、有证据支撑的修改；保留优化日志、快照，支持回滚。不会修改不可变的基础系统提示词。

npm 包 pi-continual把这套能力移植到原生 Pi，文件存放在.pi/harness/目录。提交这个目录，所有优化都变成可评审的代码 diff。

Hermes：任务结束后 fork 子智能体写入文件。 Prime Agent：任务进行中基于轨迹做优化，带回滚日志。 两者都持久化文件，都不会替换coding_agent.py主程序。

Prime Agent 在 ARC-AGI-3 RHAE 评测，Best@1 指标从 30% 提升至 95.5%。论文：https://arxiv.org/abs/2608.23552 注意：这不是 SWE-bench，属于另一类评测任务，优化目标完全不同。

核心总结

内层循环（组装提示词、采样、调用工具、追加结果、压缩上下文）没有改变。新增的是第二个写入器：允许额外模块修改下一轮窗口加载的内容。

• Hermes 的写入器：fork 子智能体，写入MEMORY.md/SKILL.md
• Prime 的写入器：/refine模块维护四类存储
• 你自己的工作流：遇到坏工单之后手动编辑AGENTS.md

普通代码智能体：查看仓库、编辑文件、运行测试、提交补丁。 自演化智能体：完成上述操作，还会把交互经验持久保存。持久化，就是分界线。只在当前工单生命周期内生效，任务结束直接丢弃修改，不属于自演化。论文 https://arxiv.org/abs/2608.03392 已经定义了这个边界。

理解第二个写入器之后，就能发现很多论文指标经常混淆三类完全不同的写入行为：

1. 在单次任务内创建工具，任务结束随进程删除（Live-SWE）
2. 写入磁盘文件，下一会话可加载，框架主程序不变（Hermes、Prime）
3. 保存智能体框架本身的新版本，归档留存（DGM）

把 1 和 3 混在一起，就会出现把 77.4% 和 20~50 分当成同一套结果的情况。

临时创建、用完即弃的工具

论文 https://arxiv.org/abs/2511.13646 基于 mini-swe-agent：https://github.com/SWE-agent/mini-swe-agent 仅约百行代码，每次动作都新建独立 bash 子进程，框架主循环完全不变。 离线方案修改框架并在基准集打分；DGM 跑 SWE-bench 成本约 22000 美元。而 Live-SWE 思路相反：能写 Python 的模型，可以在解决任务的过程中临时编写工具。

每一步执行完成后，会触发反思提示：是否新建工具能加速任务。 智能体编写脚本、运行、迭代修改。论文重点评估反思逻辑带来的收益，不只是开放文件写入权限。

它实际写出的工具例子：go_analyzer.py，用于处理 SWE-Bench Pro 中 navidrome 仓库的问题。Bash 的 grep 可以读取 Go 源码，但分不清结构体和注释。这个脚本可以解析 Go 语法，定位结构体、函数、引用、导入项。之前的基线模型无法解决该问题。

左侧仍然是 mini-SWE 基础框架，观察结果之后新增反思模块；如果判定需要工具，则写入/tmp/go_analyzer.py。模型后续直接用 bash 调用这个 python 脚本，不需要新增工具 API，文件仅在本次进程内存在。

SWE-bench Verified 随机 50 题，Claude 4.5 Sonnet 测试结果：

• 仅 bash：62.0%
• 提示词允许写工具，无反思模块：64.0%，平均创建 2.92 个工具
• 每一步增加反思：76.0%，平均创建 3.28 个工具

正是反思逻辑带来了性能提升。在完整 SWE-bench Verified 集上，Gemini 3 Pro 达到 77.4%，没有测试时扩展。Claude 4.5 Sonnet 在 SWE-Bench Pro 上是 45.8%。不同评测集、不同模型，77.4% 不是 Pro 数据集分数。

弱模型上该方案会失效。同 50 题子集，GPT-5-Nano：mini-SWE 基线 44.0%，开启 Live-SWE 后降到 14.0%，进入循环，模型根本不知道创建工具的目的。

工具在任务结束后直接丢弃，论文明确说明了这点。未来工作方向：把有用的工具序列序列化保存为技能，目前还没有实现；下一个 navidrome 工单仍然从头使用 bash。

就算一个复杂工单写出了解析器然后丢弃，它依然只是更强大的单次任务智能体，不是新的自演化框架。在 60 题子集上，它超越 DGM（65.0% vs 53.3%），且没有昂贵离线评估成本。引用数据时要区分两篇论文，不要强行合并结果。

技能文件（SKILL.md）

所有人都推荐写SKILL.md，Live-SWE 未来计划也是如此：保留主程序，把知识存到磁盘。 论文 https://arxiv.org/abs/2602.12670 做了对照实验，也就是大家推荐的方式：智能体在解题前编写技能包，解题时加载。 18 套框架配置、87 项任务：人工整理技能，基线 33.9% 提升至 50.5%。 由智能体提前自动生成技能包，对比无技能基线，效果反而下降：

• Claude Code Opus 4.7：下降 8.1 点
• Codex GPT-5.5：下降 11.3 点
• Gemini CLI Gemini 3.1 Pro：下降 11.5 点

结论直白但重要：技能包不被使用、编写成本挤占解题资源、技能包存在错误（3d-scan-calc 把单位换算当成核心假设，智能体直接采信错误逻辑）、技能包泄露任务上下文。Hermes 可以开启写入闸门。就算保存下来，下一次任务依然可能因为错误技能失败。

有效的技能生成思路：任务成功后提取经验。 论文 https://arxiv.org/abs/2605.25430：从已经成功的交互轨迹提取流程，再由 “图书管理员模块” 合并清理。相比无技能基线，平均提升 9.69 点。只提取不清理，技能库膨胀至 1252 条；经过维护精简到 676 条，收益依然保留。文件格式不变，执行顺序反过来：先成功，再建库。 跳过这个顺序，直接在解题前生成技能，就是 SkillsBench 所测出的负面效果。

替换智能体本身

论文 https://arxiv.org/abs/2505.22954，也就是 Live-SWE 对比的离线方案。 基于 Schmidhuber 的自改进论文 https://arxiv.org/abs/cs/0309048，去掉数学证明，在代码基准上评估改写后的智能体。 文中定义：代码智能体 = 代码仓库 + 可以读写执行的固定基座模型；自优化，就是在这个仓库上完成编码任务。

基础框架刻意做得很轻：bash + 文件查看 / 全量替换编辑工具，思路和 mini-SWE 一致。 一轮迭代分为两步：父智能体复制自身，修改副本；生成新文件，但此时副本还不是正式智能体；然后对子智能体打分评估。如果能正常编译、保持编辑能力，归档指针更新。指针更新前，依然使用父版本。

父智能体采样策略：优先选择高分版本，同时和已生成可编辑子智能体数量成反比；每个节点保留非零被选中概率。父智能体读取评估日志，提出一项改进点，在副本上实现。

评估阶梯：

1. 10 道基础任务：能否正常编辑代码，失败直接不存入归档
2. 50 道任务：在 60 题混合集达到 40%，且排名前两名，进入下一阶段
3. 200 道任务，降低分数噪声

迭代 80 轮后： SWE-bench 20.0% → 50.0% 完整 Polyglot 集 14.2% →30.7% 单次 SWE-bench 评估成本约 22000 美元。

迭代过程会出现比父代更差的版本，论文运行记录里第 4 轮、56 轮就是例子。节点 24 重写了编辑工具，该谱系分数从 23.3% 提升至 40.5%。 如果删掉归档，只会局部爬山优化；只不断强化最优版本，最终只能达到 39.7%，而归档策略是 50.0%。

子智能体实现的改进都是常规框架能力：更精细的查看与编辑、补丁校验、多轮尝试 + 第二个模型打分、失败历史记录、长上下文管理。真正提升性能的，是框架代码本身。

归档机制也方便识别作弊。一次独立评估中，评估目标是 “消除工具调用幻觉”；某个子智能体直接删除检测 token，拿到满分 2.0，却根本没有修复幻觉问题。谱系让代码 diff 一目了然。因此子智能体必须放在沙箱、断网环境运行，保留代码快照。

没有 IDE 内置这套系统，sakana.ai 的 DGM https://sakana.ai/dgm/只是研究实验，不是 Cursor。

记忆真正存放的位置

新工单会启动全新进程，对话上下文是空的。没持久化的内容全部丢失。这就是本文讨论记忆的原因：记忆不是插件，而是第二个写入器可以持久保存内容的规则。

可以写入三类内容，三者不可互相替代：

1. 智能体归档 Git 版本
   DGM 的归档、提交记录、父指针、评估日志、分数。不可编辑的版本直接丢弃；刻意保留弱于父代的版本，节点 24 就是这么来的。它不是记忆产品，只是带账本的框架代码仓库。
2. 经验备注
   ：论文 https://arxiv.org/abs/2507.23361 经验库。经验读取成功和失败的修复案例，提取简短备注：问题如何理解、通用策略。下一个任务检索备注，重排器只选取一条。 Claude 4 Sonnet 在 SWE-bench Verified Pass@1 达到 73.0%。DeepSeek-V3，0 条经验 37.8%，1 条提升至 42.0%，2~4 条反而下降。经验库大约 300 条达到饱和。直接存入原始长轨迹，分数下降 6 个点。

看一条备注例子，也就是大家笼统叫做 “记忆” 的对象： 工单 A，lockfile 问题：智能体反复生成 pnpm-lock.yaml，CI 报错；团队发现这个仓库要求锁定 lockfile。我们不存储 400 行日志，只保存一句话。两周后工单 B，新进程启动，组装提示词阶段检索这条备注，仅在首轮检索一次，不是每次 bash 调用都检索，1 条优于 4 条。 A 仓库的 pnpm 规则，只按用户 ID 存储的话，放到 B 仓库会造成错误。检索必须带上作用域。SWE-Exp 已经验证：1 条优于 4 条。

3. 技能
   任务成功之后提取。人工整理的技能有效；解题前由智能体生成技能通常效果变差；任务评估成功后提取技能，是目前唯一能带来正向指标收益的方案。

• 通用辅助逻辑：提交到框架 Git 仓库
• 需要第 40 代智能体看到的失败方案：存入经验库一行记录
• 需要按需加载的流程技能：只能来自已经成功的轨迹
• 自动加载上一个工单的SKILL.md：就是 SkillsBench 测出负收益的做法

Mem0

不要把coding_agent.py放进记忆 API。打分器和归档负责筛选子版本。如果存储系统试图包揽这件事，会掩盖谱系信息，就像那个删除检测器 token 的作弊子版本案例。

存储结构：多行记录，user_id、agent_id、run_id。两个版本的框架，只要 ID 一致，就读写同一份备注。第 12 代的失败方案，可以被第 40 代检索到。

写入流程：评估完成之后，已经提炼出事实句子。infer=False原样保存。默认add接口会自动提取事实，会把 lockfile 备注变成 “用户遇到依赖问题”。不要对同一批数据混用两种模式，否则重复存储。

client.add(    
    [{"role": "user", "content": fact_text}],    
    user_id=user_id,    
    agent_id=agent_id,    
    run_id=run_id,    
    infer=False, 
)

• run_id：当前工单 / 本轮评估，打分结束失效
• agent_id：当前框架版本
• user_id：用户 / 仓库，永久保留

按写入方式做过滤。infer=False写入的数据，可以同时带两个 ID 做与查询。默认自动提取模式下，事实会绑定发言人，两个字段做与查询会返回空结果。文档参考：https://docs.mem0.ai/platform/features/entity-scoped-memory

读取流程：下一个任务组装提示词阶段，仅在首轮检索一次，不是每次 bash 调用都检索，1 条记录优于 4 条。

✅ 适合存入 Mem0：lockfile 备注、失败方案、仓库约定 ❌ 不适合：运行时动态生成工具、评估前自动生成的SKILL.md、完整对话日志

Mem0 平台的 Dream 功能，只按 user_id 聚合记录。同时带 user_id+agent_id 的备注，不会被这个聚合逻辑修改。人工编写的技能保留为文件；框架 Git 版本保留在 Git 中。

参考文献

https://arxiv.org/abs/2511.13646 https://arxiv.org/abs/2505.22954 https://sakana.ai/dgm/ https://arxiv.org/abs/2608.03392https://arxiv.org/abs/2507.23361 https://arxiv.org/abs/2605.25430 https://arxiv.org/abs/2602.12670https://github.com/SWE-agent/mini-swe-agent https://arxiv.org/abs/cs/0309048 https://arxiv.org/abs/2608.23552https://www.primeintellect.ai/blog/prime-agent https://github.com/earendil-works/pi https://www.npmjs.com/package/pi-continual https://github.com/NousResearch/hermes-agent https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills https://openai.com/index/unrolling-the-codex-agent-loop/https://cursor.com/blog/continually-improving-agent-harness https://cursor.com/blog/self-driving-codebaseshttps://arxiv.org/abs/2504.19413