1. Persistent Recursive Worlds Enable Autonomous Software Evolution

推荐理由： 这篇提出了一个很值得 software factory 借鉴的反转：长周期开发不一定需要一个“永生”的 agent、无限 session 或越来越大的 memory；真正应该持久的是 project state。Genesis 让每个 agent 都可以是短命、可替换的执行单元，把连续性压到版本历史、仓库路径和可验证的 accepted state 上。这比单纯继续扩张上下文窗口更像软件工程系统本身的解法。

核心要点：

  • Genesis 把软件表示为 persistent recursive world：每个局部 world 由一个已接受版本和 repository path 定位；有限生命周期 agent 只负责提出局部修改，任务可以沿目录递归委派，只有通过接受机制的结果才推进全局版本。换句话说，Git/project state 成为长期记忆，agent 反而可以 disposable。
  • 从一个没有 compiler implementation 的仓库开始，系统使用 DeepSeek V4 Flash 连续运行超过 120 小时，归档 1,000+ agent episodes，以约 44 美元模型 token 成本生成约 25 万行 tracked Rust C compiler；最终通过完整 c-testsuite，并通过大部分 LLVM 与 Csmith 测试。另一轮 GLM 5.2 实验中，即使不断替换 agent，项目仍能延续开发并保持测试表现。
  • 系统还把 13 个 MESA 模块、超过 10 万行 Fortran 重实现为近 9 万行 Rust workspace，并在 6 个数值 workload 上取得 1.55–6.87× median speedup。更重要的工程启示不是代码量，而是：长周期自治可以围绕 persistent artifacts + versioned state + verifier + recursive delegation 组织，而不必围绕 persistent conversational agent 组织。

2. Understanding the Architecture of Coding Agents: An Exploratory Study Using a Research Prototype

推荐理由： coding agent 已经很像编译器或操作系统一样成为一种独立的软件系统，但我们通常只看到 Claude Code、Codex、OpenCode 的产品表面或庞大源码。这篇论文反过来做了一个“教学版内核” Ark：不追求 feature completeness，而是把现代 coding agent 最必要的控制流、工具协议、context/memory、patch、安全与 tracing 拆成一个可以直接读完的参考实现。

核心要点：

  • Ark 只有 13 个 Python source files、1,471 LOC 和两个外部依赖，却保留 agentic loop、LLM interaction protocol、tools、memory/history、workspace/context management、patch validation/application、error handling、security 和 tracing 等核心机制。中央 agent loop 本身只有 18 行，适合作为理解 agent harness 的“最小机器”。
  • 与 Codex CLI、OpenCode 对比后，三者在 control architecture 上其实高度一致：都是 LLM-driven sequential ReAct loop + imperative while loop。真正拉开系统差异的是 Tool & Environment Interface 和 Resource Management：例如 Codex/OpenCode 暴露 18–20+ tools，Ark 只保留 5 个；生产系统还有 sandbox、context compaction、persistent memory、model routing 等更复杂机制。
  • ArkBench 用 10 个小型 software maintenance/evolution tasks 做 sanity check，gpt-5.4-mini 单次运行完成 8/10，API 成本低于 0.50 美元。这个数字不应当当作新的 coding-agent benchmark——作者也明确强调 benchmark 很小且结果只来自一次执行；它真正的价值是提供一个可修改、可实验的 reference architecture，方便研究“换 context policy / tool set / memory / routing 后到底改变了什么”。