K-文化的一切——从回归到 K-美妆,发送到您的邮箱订阅邮件

METAL MEDIA

Persistent Recursive Worlds Enable Autonomous Software Evolution

arXiv:2608.104502026-08-11

不让某个编程智能体长期存活,而是让软件项目本身持续存在,由短命智能体接力从零开始写出一个编译器

EvoX Genesis提出让软件项目本身持续存在,项目状态由已接受的版本加仓库路径定义,而具体的编程智能体则寿命短暂、反复被重新实例化。使用DeepSeek V4 Flash,该系统从一个没有任何编译器代码的仓库出发,耗时120多小时构建出约25万行的Rust版C编译器,模型token费用仅44美元。它还接手了由GLM 5.2构建的编译器,在更换智能体和更换基础模型之后继续开发,并把MESA恒星物理软件的13个模块从Fortran重写为运行更快的Rust,同时保持数值结果基本一致。

METAL MEDIA 解读图

持久递归世界的运作方式

证据状态已报告实测结果

  1. 已接受版本v + 路径p由项目已接受的整体状态与历史(v)以及智能体开始工作的位置和职责范围(p)共同构成的本地软件世界
  2. 寿命有限的智能体接受一个目标、提出候选改动后即终止的智能体,其私有状态不会传递给下一个智能体
  3. 递归委派上级智能体在同一已接受版本内、在不同路径上生成子智能体来转移工作,这一过程不会立即改变项目版本
  4. 验证与接受关口上级智能体依据测试、约束和集成证据,决定接受、拒绝返回的改动,或要求进一步修改
  5. 累积的项目历史只有被接受的改动才会写入版本历史,这段历史成为下一批短命智能体唯一继承的内容
这是 METAL MEDIA 制作的解读图,并非论文作者提供的原图。

他们做了什么

  1. 问题背景:软件系统存活的时间远超任何单个编程智能体的会话寿命,而现有的连续性方案(更长上下文、持久记忆、管理者智能体)都是在延长智能体一侧的状态,而不是项目一侧的状态。
  2. 方法:Genesis将本地软件世界定义为已接受的版本v加仓库路径p;一个寿命有限的智能体进入该世界,提出候选改动,由上级智能体依据测试和集成证据决定接受、拒绝或要求返工。递归委派会把工作转移到新的路径而不立即改变已接受的版本,只有被接受的改动才会被写入项目历史。
  3. 编译器形成实验:从没有编译器实现的仓库出发,DeepSeek V4 Flash运行123.4小时,归档了1,019个智能体片段,生成了24.8989万行的Rust编译器jcc,模型token费用为44.38美元。
  4. 延续开发实验:两条分支都从同一个GLM 5.2构建完成的编译器世界接手开发,一条继续使用GLM 5.2,另一条换成DeepSeek V4 Flash,两者在智能体反复更换和模型更换之后都继续了开发。
  5. 再开发实验:用DeepSeek V4 Flash把MESA恒星物理软件的13个模块(约139,414行Fortran代码)重写为Rust工作空间(约89,946行);在六项数值任务中,Rust版本全部更快(1.55倍到6.87倍),同时数值结果基本保持一致。
Figure 1: Persistent recursive worlds. a, An accepted software version can be viewed from different repository-relative paths, defining local worlds w=(v,p). The version v fixes the accepted project state and history, while the path p sets where an agent starts and what it is responsible for. Recursive delegation (v,p)↝(v,q) starts a child agent at path q without changing the accepted version v. b, A finite-lived agent receives a local objective and proposes a change. The responsible parent accepts, rejects or requests more work using tests, constraints and integration evidence. The isolated worktree is an execution workspace created from the accepted version; it is not a second software world or a partial repository in the formal model. c, Only an accepted change creates a software event (v,p)→(v′,p′) and advances the accepted version history. A rejected candidate leaves the accepted version unchanged, and the agent’s private execution state ends with the episode.
Figure 1: Persistent recursive worlds. a, An accepted software version can be viewed from different repository-relative paths, defining local worlds w=(v,p). The version v fixes the accepted project state and history, while the path p sets where an agent starts and what it is responsible for. Recursive delegation (v,p)↝(v,q) starts a child agent at path q without changing the accepted version v. b, A finite-lived agent receives a local objective and proposes a change. The responsible parent accepts, rejects or requests more work using tests, constraints and integration evidence. The isolated worktree is an execution workspace created from the accepted version; it is not a second software world or a partial repository in the formal model. c, Only an accepted change creates a software event (v,p)→(v′,p′) and advances the accepted version history. A rejected candidate leaves the accepted version unchanged, and the agent’s private execution state ends with the episode.
Table S1: Repository commits used in the three experiments.
RepositoryVersionCommit ID (SHA-1)
jccDeepSeek generated jcca8c116ec7ed3d59479ad3be8fed3e63384f50a87
jccGLM generated jcc37216cfa254a40e40af48cd528743fd7f2d6737c
jccGLM generated jcc continued with DeepSeek10077f65686102deef2c228e8a49b0569218ec48
jccGLM generated jcc continued with GLMab58a91460adb24e9349a554e02d4522d3ae2db4
mesa-rsDeepSeek ported mesa2ad071e658f8d4de21aa9f0e906592c364e10023
Figure 2: Formation of a C compiler with DeepSeek V4 Flash through recursive development. a, Growth of the jcc codebase and cumulative input-token use against elapsed time; the phase boundary separates initialization from optimization. b, Final validation across LLVM, c-testsuite, Csmith, LZ4, SQLite, Rust workspace tests and the internal compiler corpus. c, Active agents and completed episodes throughout development, with episodes distinguished by whether their contributions were retained in the final accepted repository history. d, Agent time partitioned among front-end, intermediate-representation and optimization, back-end, integration and validation, and cross-cutting work during the two phases. Dollar annotations denote model-token charges only, not total compute, infrastructure or labour cost.
Figure 2: Formation of a C compiler with DeepSeek V4 Flash through recursive development. a, Growth of the jcc codebase and cumulative input-token use against elapsed time; the phase boundary separates initialization from optimization. b, Final validation across LLVM, c-testsuite, Csmith, LZ4, SQLite, Rust workspace tests and the internal compiler corpus. c, Active agents and completed episodes throughout development, with episodes distinguished by whether their contributions were retained in the final accepted repository history. d, Agent time partitioned among front-end, intermediate-representation and optimization, back-end, integration and validation, and cross-cutting work during the two phases. Dollar annotations denote model-token charges only, not total compute, infrastructure or labour cost.
Table S2: Compiler archive and integration counts.
QuantityValue
Raw archived records1,019
Top-level agent_count field1,065
Direct missing-parent records4
Excluded descendants0
Records in reconstructed tree1,015
Initialization records312
Optimization records703
Retained929
No change78
Not integrated5
Git object unavailable3
First-parent commits327
Maximum observed delegation depth5
Peak active episodes29
Figure 3: Continuation of the same compiler world with GLM 5.2 and DeepSeek V4 Flash. a, Codebase growth and cumulative token use across initial GLM 5.2 development and the two continuations from the same completed GLM jcc world. b, Compiler validation and project growth for the three recorded snapshots. The retained LLVM SingleSource test sets differ among snapshots, so the fractions are reported within each snapshot rather than compared on one fixed test set. c, Concurrent agent activity across initial development and both continuation runs. d, Lines added and deleted during each continuation relative to the shared starting codebase. e, Cached and fresh input-token fractions and corresponding recorded or reconstructed model-token costs. The costs were obtained differently for the two continuation runs, and the runs did not use matched resources, so no normalized dollar-efficiency comparison is made.
Figure 3: Continuation of the same compiler world with GLM 5.2 and DeepSeek V4 Flash. a, Codebase growth and cumulative token use across initial GLM 5.2 development and the two continuations from the same completed GLM jcc world. b, Compiler validation and project growth for the three recorded snapshots. The retained LLVM SingleSource test sets differ among snapshots, so the fractions are reported within each snapshot rather than compared on one fixed test set. c, Concurrent agent activity across initial development and both continuation runs. d, Lines added and deleted during each continuation relative to the shared starting codebase. e, Cached and fresh input-token fractions and corresponding recorded or reconstructed model-token costs. The costs were obtained differently for the two continuation runs, and the runs did not use matched resources, so no normalized dollar-efficiency comparison is made.
Table S3: Compiler-formation resource use.
MetricObserved value
Elapsed wall time123.402 h
Raw agent-hours666.385 h
Median episode duration12.76 min
Input tokens4,134,593,954
Cached input tokens4,026,336,896
Uncached input tokens108,257,058
Cached input/input97.382%
Output tokens64,092,688
Total tokens4,198,686,642
Logged costUS$44.3760
Figure 4: Redevelopment of selected MESA modules in Rust. a, Repository growth and cumulative input-token use during the MESA-to-Rust migration. The plotted repository line count is the size of the generated repository, not the number of MESA source lines migrated. b, Mean prompt-cache hit rates for agent groups defined by total token use. c, Dependencies among the mapped modules, classified as present in both dependency graphs, absent as direct Rust crate dependencies, or newly present in Rust. d, Numerical agreement and median runtime for corresponding Fortran and Rust implementations across six audited workloads.
Figure 4: Redevelopment of selected MESA modules in Rust. a, Repository growth and cumulative input-token use during the MESA-to-Rust migration. The plotted repository line count is the size of the generated repository, not the number of MESA source lines migrated. b, Mean prompt-cache hit rates for agent groups defined by total token use. c, Dependencies among the mapped modules, classified as present in both dependency graphs, absent as direct Rust crate dependencies, or newly present in Rust. d, Numerical agreement and median runtime for corresponding Fortran and Rust implementations across six audited workloads.
Table S4: Compiler-formation resource use by phase.
PhaseRecordsWall time (h)Agent-hoursTotal tokensCost (US$)
Initialization31223.905163.9251,052,907,91213.5715
Optimization70799.497502.4603,145,778,73030.8045
Total1,019123.402666.3854,198,686,64244.3760
Supplementary Fig. S5: DeepSeek compiler-development tree. The radial tree shows the two root sessions and all 1,015 records used in the reconstructed parent–child tree after four records with missing parents were excluded. Radial distance shows delegation depth. Blue and coral show initialization and optimization; shade shows completion order within each phase. Symbols mark retained, no-change, not-integrated and Git-object-unavailable outcomes.
Supplementary Fig. S5: DeepSeek compiler-development tree. The radial tree shows the two root sessions and all 1,015 records used in the reconstructed parent–child tree after four records with missing parents were excluded. Radial distance shows delegation depth. Blue and coral show initialization and optimization; shade shows completion order within each phase. Symbols mark retained, no-change, not-integrated and Git-object-unavailable outcomes.
Table S5: Final compiler repository lines by tracked text-file type.
File typeFilesPhysical linesShare
Rust354219,67688.23%
Markdown7717,0056.83%
C source1305,0362.02%
Python143,2651.31%
C header493,1631.27%
Expected output1062710.11%
Shell31950.08%
Cargo.toml91320.05%
Makefile11010.04%
Cargo.lock1660.03%
TOML2420.02%
YAML1250.01%
.gitignore2100.00%
Info120.00%
Total750248,989100.00%
Supplementary Fig. S6: Final DeepSeek compiler repository. The final tracked repository contains 248,989 physical lines in 750 text files, including 219,676 Rust lines in 354 .rs files. a, Lines grouped by functional category. b, Line and file counts by tracked file type on a logarithmic scale. Counts include comments and blank lines and describe the whole repository, not compiler implementation alone.
Supplementary Fig. S6: Final DeepSeek compiler repository. The final tracked repository contains 248,989 physical lines in 750 text files, including 219,676 Rust lines in 354 .rs files. a, Lines grouped by functional category. b, Line and file counts by tracked file type on a logarithmic scale. Counts include comments and blank lines and describe the whole repository, not compiler implementation alone.
Table S6: Final compiler test results and limits.
TestMeasureResultRateNotes
LLVM test suitePassing cases32/3688.9%Four reported cases did not pass
c-testsuitePassing tests220/220100.0%Complete reported c-testsuite set
CsmithExecuted random programs93/93100.0%Seven of 100 seeds skipped; zero executed failures
LZ4Essential checks8/8100.0%All reported essential checks passed
SQLiteTest stages2/2100.0%Compile/link and deterministic SQL checks; not the upstream suite
Rust unit testsWorkspace count2,904 passedOne intentional ignore; no fixed external denominator
Internal corpusCompiler cases106/106100.0%86 compile-run and 20 compile-fail cases
Supplementary Fig. S7: Delegation trees for compiler continuation. The upper tree shows the 504 archived records from initial GLM development, including two root segments and depth to d5; agent roles were not recorded for this stage. The lower trees show the 97 archived GLM 5.2 continuation records and 168 archived DeepSeek V4 Flash continuation records. Distance from the centre shows delegation depth, node shape shows the recorded role where available and colour shade shows completion order.
Supplementary Fig. S7: Delegation trees for compiler continuation. The upper tree shows the 504 archived records from initial GLM development, including two root segments and depth to d5; agent roles were not recorded for this stage. The lower trees show the 97 archived GLM 5.2 continuation records and 168 archived DeepSeek V4 Flash continuation records. Distance from the centre shows delegation depth, node shape shows the recorded role where available and colour shade shows completion order.
Table S7: Compiler task and run settings.
ItemSetting
Run setupGenesis; two sequential root sessions; per-agent Git worktrees
ModelDeepSeek V4 Flash
Archived model identifierdeepseek:deepseek-v4-flash; model_id=deepseek flash
Reasoning effortxhigh
Context-compression threshold150,000 tokens
Initial codebase.gitignore and genesis.toml; no compiler implementation
Root-task inputsPhase-I compiler blueprint; Phase-II continuation with handoff summary
Turn limits2,048 root turns; 128 turns per non-root episode
Delegation and retry limitsMaximum depth 8; maximum retries 15
External test sourcesc-testsuite, LLVM test suite, LZ4 and SQLite
Generated-program testsCsmith through the committed harness
Rust toolchainRust stable; edition 2024; minimum Rust version 1.85; rustfmt and clippy
Compiler targetC11 primary and C23 stretch; x86 and x86-64 mandatory; AArch64 optional
Supplementary Fig. S8: Agent roles and delegation depth in compiler continuation. a, Role counts for the 97 archived GLM 5.2 continuation records and 168 archived DeepSeek V4 Flash records; roles were not recorded for initial development. b, Delegation-depth counts for initial development and both continuations. These counts describe archived records, not all spawned agents.
Supplementary Fig. S8: Agent roles and delegation depth in compiler continuation. a, Role counts for the 97 archived GLM 5.2 continuation records and 168 archived DeepSeek V4 Flash records; roles were not recorded for initial development. b, Delegation-depth counts for initial development and both continuations. These counts describe archived records, not all spawned agents.
Table S8: Machine and software environment for the compiler experiments.
ItemRecorded value
CPUAMD Ryzen 7 PRO 6850HS with Radeon Graphics
CPU layoutx86-64; one socket; 8 physical cores; 2 threads per core; 16 online logical CPUs
Memory64 GB
CPU frequency403.7300–4787.0820 MHz; frequency boost enabled
Cache256 KiB L1d, 256 KiB L1i, 4 MiB L2 and 16 MiB L3 in aggregate
NUMAOne node containing CPUs 0–15
Container and hostArchLinux container; NixOS-built Linux 6.18.39 host kernel
FilesystemZFS with copy-on-write worktrees
Tool isolationsystemd-run and cgroups for every agent tool call
Missing reproduction fieldsContainer digest, package lock, per-tool cgroup limits, exact Rust/linker revisions and host-load traces
Supplementary Fig. S9: Physical line counts during compiler continuation. Tracked Rust, Cargo.toml, Markdown and shell lines are shown for the initial GLM compiler and the two continuation results. The horizontal axis is logarithmic so that small project-control files remain visible. Counts include blank lines.
Supplementary Fig. S9: Physical line counts during compiler continuation. Tracked Rust, Cargo.toml, Markdown and shell lines are shown for the initial GLM compiler and the two continuation results. The horizontal axis is logarithmic so that small project-control files remain visible. Counts include blank lines.
Table S9: Compiler-continuation starting points and run settings.
SettingInitial developmentGLM continuationDeepSeek continuation
Model pathNew project → GLM 5.2GLM compiler → GLM 5.2Same GLM compiler → DeepSeek V4 Flash
Starting stateEmpty tracked projectCompleted compiler at 37216cfa254aSame completed compiler at 37216cfa254a
TaskBuild new compilerContinue existing compilerContinue existing compiler
Root roleNot recordedManagerManager
Depth and retry limits8; 158; 158; 15
Turn limits2,048 root; 128 delegated2,048 root; 128 delegated2,048 root; 128 delegated
Compression threshold150,000 tokens150,000 tokens150,000 tokens
Test familiesRust, LLVM, c-testsuite, LZ4, SQLiteSame familiesSame families
CsmithRequested; unavailableExcludedExcluded
Runs111
Shared fixed budgetNot specifiedNot specifiedNot specified
Supplementary Fig. S10: Module-level source line counts for MESA and Rust. For each of the 13 mapped modules, physical Fortran lines in the module directory, including local test programs, are compared with Rust library lines and Rust library-plus-crate-test lines. The logarithmic axis shows both larger and smaller ports. Counts include comments and blank lines and do not imply feature equivalence.
Supplementary Fig. S10: Module-level source line counts for MESA and Rust. For each of the 13 mapped modules, physical Fortran lines in the module directory, including local test programs, are compared with Rust library lines and Rust library-plus-crate-test lines. The logarithmic axis shows both larger and smaller ports. Counts include comments and blank lines and do not imply feature equivalence.
Table S10: Run summary for compiler continuation.
MetricInitial GLMGLM continuationDeepSeek continuation
Elapsed time (h)136.5621.9917.10
Spawned Agents56298178
Archived records50497168
Archive coverage89.7%99.0%94.4%
First-parent commits6198831
Maximum observed depth548
Peak active Agents21919
Mean active Agents2.862.945.70
Summed Agent-hours390.5764.6597.57
Median duration (min)14.416.117.0
90th-percentile duration (min)83.259.870.2
Code-changing records47990160
No-change records2578
Supplementary Fig. S11: Accepted Rust source changes over time. First-parent Git activity is shown for the 13 migrated crates during the 33.22-h run. Colour intensity represents log⁡(1+added+deleted) lines. The dashed line marks the root-level handoff at 31.72 h. Blank intervals mean that no first-parent source change was accepted at the plotted resolution; analysis or testing may still have been active.
Supplementary Fig. S11: Accepted Rust source changes over time. First-parent Git activity is shown for the 13 migrated crates during the 33.22-h run. Colour intensity represents log⁡(1+added+deleted) lines. The dashed line marks the root-level handoff at 31.72 h. Blank intervals mean that no first-parent source change was accepted at the plotted resolution; analysis or testing may still have been active.
Table S11: Archive coverage for compiler continuation.
StageSpawnedArchivedCoverageMissing-parent issue
Initial development56250489.7%Six absent parent IDs referenced by 15 records
GLM continuation989799.0%Two records reference absent parent 562
DeepSeek continuation17816894.4%No missing-parent reference among archived records
Supplementary Fig. S12: Concurrent agent episodes during migration. Active archived episodes are reconstructed at one-minute resolution and stacked by recorded role. The maximum overlap was 22 episodes. The plot uses archived start and finish times and does not show CPU use.
Supplementary Fig. S12: Concurrent agent episodes during migration. Active archived episodes are reconstructed at one-minute resolution and stacked by recorded role. The maximum overlap was 22 episodes. The plot uses archived start and finish times and does not show CPU use.
Table S12: Token use and cost in compiler continuation.
MetricInitial GLMGLM continuationDeepSeek continuation
Input tokens2,245,871,926543,563,883902,775,744
Cached input tokens2,163,779,584534,150,656884,375,552
Fresh input tokens82,092,3429,413,22718,400,192
Cached input/input96.34%98.27%97.96%
Output tokens19,334,8863,702,6978,704,733
Total tokens2,265,206,812547,266,580911,480,477
Input cost (US$)677.511916152.0576885.052314
Output cost (US$)85.07365916.2918672.437395
Total cost (US$)762.585575168.3495557.489709
Table S13: Tests reported at the end of compiler continuation.
Test targetInitial developmentGLM continuationDeepSeek continuation
Rust unit tests1,1361,226 (+90)1,350 (+214)
LLVM SingleSource1,558/1,870 (83.3%)1,445/1,448 (99.79%)1,820/1,820 (100%)
c-testsuite220/220220/220220/220
LZ44/4 files4/4 files4/4 files
SQLite at -O0Basic run passedCompiledCompiled, linked and ran
CsmithUnavailableExcludedExcluded
Table S14: Physical line counts for the compiler-continuation snapshots.
Included file typeTask 1GLM 5.2DeepSeek V4 Flash
Rust94,253104,264117,409
Cargo.toml202202202
Markdown10,32511,87614,718
Shell640649825
Total105,420116,991133,154
Table S15: MESA-to-Rust run and timing settings.
QuantityValue
ModelDeepSeek V4 Flash
Model settingsxhigh reasoning; 150,000-token compression threshold
Recorded agent rolesCodebase lead, manager, executor and codebase investigator
Controller limitsMaximum depth 8; retries 15; 2,048 root turns and 128 child turns
Source baselineModified MESA fork, commit 461dcba94f33
Timing hostShared Intel Xeon Platinum 8336C system; 64 physical cores / 128 hardware threads; benchmark processes pinned to CPUs 0–3
Timing runs25 direct-binary runs per workload after warm-up; separate 40-run burn-proxy check
Fortran buildgfortran 12.2.0; -O3 -march=native -ffp-contract=fast -std=f2008
Rust buildopt-level=3; fat LTO; codegen-units=1; panic=abort
Table S16: MESA-to-Rust resource use and archive coverage.
QuantityRecorded value
Experiment interval3–5 August 2026 (UTC)
Elapsed wall time33.219 h
Root-agent handoff31.720 h
Spawned agents272
Archived agent records260
Archive coverage95.6%
Input tokens771,755,551
Cached input tokens744,102,016
Cached input share96.4168%
Output tokens16,721,326
Total tokens788,476,877
Recorded model-token costUS$10.636892
Table S17: Module-level source line counts for MESA and mesa-rs.
LayerModuleFortran LOCRust libRust testsRust totalFortran/Rust
Foundationconst308836909260.33
Foundationutils3,5691,3843701,7542.03
Foundationmath1,0201,4748072,2810.45
Foundationmtx5,2068,2441,7289,9720.52
Foundationinterp_1d5,8512,0029372,9391.99
Foundationinterp_2d16,1765,5921,3006,8922.35
Foundationnum18,35710,2253,07813,3031.38
Physicschem4,4243,7539004,6530.95
Physicsrates18,54712,3044,97517,2791.07
Physicsneu2,2632,2229953,2170.70
Physicsnet17,79916,3322,42918,7610.95
Physicseos25,8171,4261,5142,9408.78
Physicskap20,0771,5798322,4118.33
AllTotal139,41467,37319,95587,3281.60
Table S18: Numerical agreement and runtime performance for six migrated workloads.
WorkloadFortran (s)Rust (s)SpeedupChecksum difference
End-to-end burn0.4460.2871.55×3.1×10−9
EOS lookup1.7861.1151.60×Bit-exact
Opacity lookup0.5320.2691.98×1.3×10−13
2D interpolation0.1590.1011.58×4.9×10−12
ROS2 integration0.7220.1365.30×5.1×10−15
Newton solve0.0840.0126.87×Bit-exact
Table S19: Separate 40-run timing check for the burn proxy.
StatisticFortran (s)Rust (s)Fortran/Rust
Minimum0.28970.23721.22×
P100.29220.23851.22×
P250.29270.23921.22×
Median0.29960.24271.23×
Mean0.34470.27351.26×
P750.44160.36091.22×
P900.44580.37291.20×
Maximum0.44900.38151.18×
Table S20: Mapped dependency counts for MESA and mesa-rs.
CategoryEdgesInterpretation
MESA142Provider-to-dependent edges parsed from INTERNAL_DEPENDS_ON
mesa-rs41Mapped crate dependencies parsed from Cargo.toml
Retained40Edges present in both mapped graphs
MESA-only102No matching direct Rust crate dependency in the mapped graph
Rust-only1Dependency introduced in mesa-rs
Table S21: What each experiment supports and what remains unresolved.
ExperimentWhat else could explain the resultEvidence in this studyWhat the result supports
Compiler formationThe task specification and model knowledge may explain part of the resulting organizationRepository with no compiler implementation, a 1,015-record reconstructed parent–child tree, repository counts and seven test familiesOne observed run formed and broadly tested a working compiler; no repeated mechanism test
Compiler continuationModel differences, unequal resource use or the source code alone may explain the observed continuationSame saved GLM starting world and instruction, but one run per path, different resource use, different LLVM case lists and no code-only or fresh-agent controlThe same completed compiler was continued with GLM 5.2 and DeepSeek V4 Flash
MESA migrationLimited module and workload coverage and the timing setup may explain part of the resultThirteen mapped module directories, 13 Rust crates, six 25-run workload summaries and a separate 40-run burn-proxy summaryNumerical agreement on the tested workloads and lower measured runtimes under the reported setup
Table S22: Observed failures, missing records and how they are handled.
ExperimentObserved issueHow it is handled
Compiler formationFour direct missing-parent records; four of 36 reported LLVM cases did not pass; seven of 100 Csmith seeds were skippedRows with missing parents are excluded only from the parent–child tree; non-passing and skipped test cases remain in the reported denominators
Compiler continuationGLM 5.2 passed 1,445/1,448 on its retained LLVM manifestThe exact count is reported. No cause is claimed for the three non-passing cases because per-case diagnostics are unavailable
Continuation archivesArchive coverage is 89.7% for initial GLM development, 99.0% for GLM continuation and 94.4% for DeepSeek continuationParent–child, role, depth and concurrency summaries use only the archived records available for each stage
MESA numerical checksFour of six tested workloads have small non-zero checksum differences; the module and workload coverage is incompleteThe numerical differences and coverage limits are reported directly; no claim of complete MESA equivalence is made
MESA timing checksOne noisy interleaved end-to-end timing run favoured Fortran (0.82× Rust/Fortran speed ratio), whereas the dedicated 40-run summary favoured Rust at 1.23× medianBoth observations are reported; runtime claims are limited to the reported host and timing setup and are not generalized to Rust versus Fortran
MESA line countsIndependent workspace counting paths differ by one physical Rust line (89,946 versus 89,945)The discrepancy is reported and is not used in the main comparison; the mapped 13-crate total of 87,328 lines is the comparison value

研究结果

  • 编译器形成:耗时123.4小时,归档1,019个智能体片段,生成24.8989万行代码库,模型token费用44.38美元;编译器通过c-testsuite 220/220、已评估的LLVM测试32/36、Csmith程序93/93,以及2,904项Rust工作空间测试。
  • 编译器延续开发:在同一个GLM 5.2构建完成的编译器世界上,GLM 5.2分支在其自身保留的LLVM测试集上通过1,445/1,448,换用DeepSeek V4 Flash的分支在其自身测试集上通过1,820/1,820;由于两个测试集不同,这不是直接的正面比较。
  • MESA再开发:耗时33.22小时,动用272个智能体,生成89,946行的Rust工作空间,通过1,052项测试(无失败,18项被忽略),模型token费用10.64美元。
  • 在六项数值任务中,EOS查表和牛顿求解结果位级完全一致,其余四项任务的相对校验和差异极小(5.1×10^-15到3.1×10^-9),且Rust版本在全部六项任务中都更快(1.55倍到6.87倍)。
  • 另一项针对燃烧工作负载的40次重复测量显示,Fortran中位数为0.2996秒,Rust为0.2427秒(1.23倍),两种实现报告的积分步数等核心指标完全相同。

可应用场景

  • 适用于需要跨越较长时间、由多人或多模型接力参与的大型代码库开发场景,以项目为中心组织持续性。
  • 适用于将遗留科学软件(如Fortran代码)迁移到其他语言、同时希望保留已有数值验证结果的场景。
  • 适用于希望在更换底层基础模型时不中断现有代码库开发进度、避免被单一模型锁定的场景。

局限与待验证事项

  • 论文中每类实验都只运行了一次(编译器形成一次、延续开发两条分支、MESA一次),因此无法确定重复运行下的成功率或可重复性。
  • 两条延续开发分支(GLM 5.2与DeepSeek V4 Flash)使用了不同的保留测试集和不匹配的资源预算,不能视为对两个模型的受控比较。
  • MESA再开发仅覆盖13个核心数值与物理模块,明确不包括star、astero、binary等更高层引擎,也不包括完整的EOS混合方案和REACLIB数据集。
  • Fortran与Rust所用计时方式不同(system_clock/cpu_time与Instant),且计时对主机负载敏感,因此报告的加速比只针对这一特定构建、主机和测试环境,不是普遍性的Rust对Fortran速度结论。
  • 论文尚未进行区分因果关系的实验,例如固定代码不变、只改变已接受的非代码记录,来验证递归委派或持久化记录本身是否真的是长周期能力的必要条件。

为什么重要

这项工作展示了组织长周期AI辅助软件开发的一种不同思路:不是想办法让某个智能体活得更久,而是让项目的已接受状态持续存在,把智能体当作可替换的一次性执行者。对于维护大型代码库或迁移遗留科学软件的团队来说,这提示了一种设计方向,即更换智能体甚至更换底层模型不必意味着开发被打断。

本文术语

  • EvoX Genesis · 论文提出的系统,将软件表示为持久的递归世界,使智能体可以寿命短暂而开发仍能持续
  • 持久递归世界 · 由已接受的软件版本加仓库路径定义的本地工作空间;版本持续存在,新智能体不断在路径上被重新实例化
  • 递归委派 · 上级智能体在同一已接受版本内、在不同路径上生成子智能体来转移工作,这一过程本身不改变项目历史
  • MESA · 用于一维恒星演化计算的开源软件套件(Modules for Experiments in Stellar Astrophysics)
  • c-testsuite / Csmith · 用于检验C编译器正确性的外部测试集合以及随机C程序生成器

论文原文摘要(英文)

Complex software systems develop over timescales that exceed the lifespan of any individual coding agent. Most agentic software systems preserve continuity through persistent sessions, memories, managers or shared context. We introduce EvoX Genesis (hereafter, Genesis), which instead makes the software project persistent while allowing local agents to remain finite-lived. Genesis represents software as a persistent recursive world: each local world is situated by an accepted version and a repository path, finite-lived agents propose local changes, recursive delegation moves work across paths, and only accepted consequences advance the persistent version history. We evaluate this organization across formation, continuation and redevelopment. Starting from a repository with no compiler implementation, Genesis used DeepSeek V4 Flash to build a Rust-based C compiler with about 250k tracked lines; the run lasted over 120 hours, archived over 1,000 agent episodes and incurred only US$44 in model-token charges. The compiler passed the complete c-testsuite and most LLVM and Csmith tests. In a separate compiler world generated with GLM 5.2, development continued after repeated agent replacement while retaining full test performance. Genesis also reimplemented 13 MESA modules with over 100k Fortran lines as a Rust workspace with nearly 90k Rust lines; across six numerical workloads, it achieved median speedups of 1.55--6.87x. These results show that long-horizon software development can be organized around a persistent project rather than a persistent agent.

作者 · Beichen Huang

在 arXiv 阅读

最新论文

全部论文 →

METAL MEDIA 最新报道

图片来源: Beichen Huang et al., arXiv:2608.10450, arxiv-nonexclusive