ASTER CODE / 设计原理
RSI 与 Meta Harness
候选执行策略的替换、评估、采纳和回滚。
RSI 的改进对象
RSI 是 Recursive Self-Improvement,即递归自我改进。Aster 讨论执行程序的递归改进。智能体提出工作方式的修改,宿主评估并采纳有依据的候选,再用新方式组织后续改进。修改对象包括提示、上下文策略、工具使用程序和调度组件。
这类改进发生在模型外部的执行程序上,不涉及模型权重训练,也不证明能力可以无限增长。STOP 研究改进程序对自身代码的修改。DGM 生成并评估经过自修改的编码智能体。STOP 论文、DGM 论文。
执行程序演进案例
从图谱左上角选择案例。点击节点可钻取细节,打开“演进历程”可按阶段阅读。DGM 与 STOP 根据原始研究重建算法关系,Aster 案例追溯仓库中的实际工程改动。每个节点都提供来源。“Aster 接入映射”表示应用设计建议。
“场景、改动、决策、方案、结果、依据”标明节点职责,箭头给出方向。条件标签显示分支结果。DGM 的有效性判断分为“入档”与“不入档”。STOP 展示论文报告的三类搜索策略。Aster 额度修复区分无计数上限、零工具额度和有限正额度。机制分支不表示一次已经发生的运行。
DGM · 编码 Agent 自修改
基于 DGM 原论文第 3–4 节、图 3 与附录 C。阶段顺序表达算法流程,连线不是完整实验谱系;改动和结果来自作者报告,未在 Aster 中复现。
目标:保留有效自修改,再从档案继续探索。
观察对象:编码 Agent 的实现。
演进历程6 个阶段
DGM · 编码 Agent 自修改
文献流程重建 · 2025
案例与证据边界
基于 DGM 原论文第 3–4 节、图 3 与附录 C。阶段顺序表达算法流程,连线不是完整实验谱系;改动和结果来自作者报告,未在 Aster 中复现。
- 初始条件
- 初始 Agent 使用整文件操作;基础模型冻结。
- 判断条件
- 候选能编译并继续编辑代码吗?
- 结果
- 有效候选入档;无效候选排除。
节点说明与全部来源
初始编码 Agent
原论文 §3、附录 A.1:初始 Agent 以冻结的基础模型调用工具完成编码任务;演化对象是 Agent 的 Python 实现。
- 改进对象:工具实现与工作流程,不是本实验中的模型权重。
- 起始能力:读取、修改与执行代码,为后续自修改提供基础。
Agent 档案库
原论文 §3:保存不同 Agent 版本,允许从不止一个候选继续探索。
- 为什么保留分支:即时得分较低的版本也可能成为后续改进的跳板。
- 图 3:作者给出实际谱系;本图是用于阅读的关系重建。
选择父 Agent
原论文 §3、附录 A.2:从档案库选择父 Agent,再由它修改自身实现。
- 递归位置:新发现的 Agent 后续也能承担自修改。
- 与固定元 Agent 的区别:始终用初始 Agent 改写其他 Agent,是论文中的另一条对照设置。
文件工具变更
原论文 §4.4、附录 C:作者报告:文件查看细化到行,编辑支持字符串替换。
- 改动前:初始工具以整文件查看或替换为主。
- 改动后:提供更细粒度的查看和定点编辑。
- Aster 接入映射:应用设计建议:通过会话注册工具实现,tools 视图提供目录;执行权限仍由 Core 决定。
多候选与评审
原论文 §4.4、附录 C:作者还报告生成、比较多个解法,并在新尝试中保留此前失败的信息。
- 实际报告:多候选选择与尝试历史属于作者列出的工作流改动。
- 不是单一路线:这些改动不表示每个 Agent 都按同一顺序获得全部能力。
- Aster 接入映射:设计建议:宿主组件组织候选与比较,结果写入同一事实日志。
候选仍能编译与编辑吗?
原论文 §4.2–4.4:DGM 先评估候选,再检查其能否编译并继续编辑代码。有效候选加入档案;低分本身不是排除条件。
- 评估用途:确认代码编辑能力,并估计下游编码表现。
- 不能混用的口径:论文的子集搜索结果与完整 Polyglot 结果有各自范围。
- 准入条件:论文 §3 与附录 A.4:保留可以编译并保持代码编辑能力的候选,其他候选不入档。
保留演进谱系
原论文图 3:论文展示实际谱系中的中间跳板;更好版本并非总沿着即时最优分支出现。
- 节点 24:图 3 将其描述为带来许多后续创新的关键节点。
- 实证范围:这是该次实验的观察,不是无限改进的保证。
论文结果与边界
论文 §4 · 非 Aster 结果:作者报告 SWE-bench 评估中从 20.0% 到 50.0%,完整 Polyglot 从 14.2% 到 30.7%。
- 来源:论文 §4 的 Results;SWE-bench 与完整 Polyglot 口径分别标明。
- 使用范围:这些数字不属于 Aster;当前页面没有重新运行相关基准。
- 后续应用:移植某个工具或流程仍需在自身任务集上独立验证。
无效候选 · 不入档
原论文 §3、附录 A.4 · 机制分支:编译失败或失去代码编辑能力的候选不会加入档案。这是论文算法的条件结果,不声称此处展示了某一次失败运行。
- 判断依据:检查编译与代码编辑能力,不用“分数较低”代替有效性检查。
- 分支结果:该候选不入档,原有档案继续用于下一轮父代选择。
STOP · 改进器改进自身
文献流程重建 · COLM 2024
案例与证据边界
基于 STOP 论文图 2–3、Algorithm 1、策略分析与官方代码仓库。这里重建算法关系,不把不同实验产生的搜索策略拼成一条伪造的部署历史。
- 初始条件
- 种子程序批量生成候选,再按效用选优。
- 判断条件
- 哪些候选在给定效用下表现更好?
- 结果
- 本批选出的改进器参与下一轮递归。
节点说明与全部来源
Seed improver
STOP 图 2:种子改进器多次请求模型生成程序候选,再按效用函数选择。
- 输入:初始程序、效用函数和语言模型。
- 输出:在本次候选中按效用选择的程序。
下游效用
STOP Algorithm 1:效用衡量改进后的程序在下游任务上的表现。
- 任务层:先运行改进器得到程序,再评价这个程序。
- 元层:改进器的价值来自它改善下游程序的能力。
以自身为输入
STOP 图 3、Algorithm 1:将改进器自身代码交给改进器,以元效用评价产生的新改进器。
- 递归步骤:上一代改进器参与生成下一代改进器。
- 模型边界:论文未修改基础语言模型本身。
探索哪种搜索策略?
STOP 论文策略分析:作者分析了模型提出的束搜索、遗传算法和模拟退火等策略。
- 具体变化:改的是怎样生成、搜索与选择代码候选。
- 证据边界:这是论文分析的一组策略,不是三次已知顺序的上线。
- Aster 接入映射:设计建议:由宿主组件或完整 Assembler 承载候选搜索,保持 Core 的权限和完成边界。
哪个候选的效用最高?
STOP Algorithm 1:种子改进器按效用从本次生成的候选中选优。三类策略节点是论文汇总,不表示同一次运行的并行执行日志。
- 比较对象:比较改进器对任务的效果,而非只比较提示文本长度。
- 实验范围:论文是受限范围的代码生成自改进研究。
下一代 improver
STOP 论文策略分析:改进后的改进器继续参与后续改进;语言模型保持不变。
- 实际研究含义:递归的是模型外部的脚手架代码。
- 应用边界:移植到 Aster 需要独立实现与验证,不能把研究结果当成本产品表现。
束搜索
STOP 图 1 与策略分析 · 论文汇总:扩展并保留多个候选,继续沿若干候选路线搜索。
- 改动方向:扩展并保留多个候选,继续沿若干候选路线搜索。
- 记录边界:这是作者报告的策略类型;本图不声称它与另外两类策略在同一轮同时执行,也不补造该分支得分。
遗传搜索
STOP 图 1 与策略分析 · 论文汇总:用候选群体与变异等操作探索程序空间。
- 改动方向:用候选群体与变异等操作探索程序空间。
- 记录边界:这是作者报告的策略类型;本图不声称它与另外两类策略在同一轮同时执行,也不补造该分支得分。
模拟退火
STOP 图 1 与策略分析 · 论文汇总:以退火式搜索探索候选程序。
- 改动方向:以退火式搜索探索候选程序。
- 记录边界:这是作者报告的策略类型;本图不声称它与另外两类策略在同一轮同时执行,也不补造该分支得分。
Aster · 长任务预算修复
仓库工程记录 · 2026-10-20
案例与证据边界
对应提交 ba17a7ca69bb39bd6a98dce14377777951fa9119 及其保留的验收记录。这是人工组织的 Meta Harness 工程演进,不是 Aster 已自主完成 RSI 的证明。
- 初始条件
- 无上限、零额度与有限上限需要分别处理。
- 判断条件
- 配置是 None、Some(0) 还是 Some(n),n > 0?
- 结果
- 三个配置分支各按其合同执行,并接受回归验证。
节点说明与全部来源
长任务被截断
提交说明与工程证据:交互式 ACP 的隐式工具或状态转换次数上限影响长任务。SDK 的默认界限与显式配置仍需保留。
- 修复目标:移除交互路径的隐式次数天花板,保留用户与父级明确设置。
- 范围:工程案例来自该提交,不能代表所有长任务都已验证。
工具额度是哪种配置?
该提交 · Effect 配置:用类型化的可选上限区分“无计数上限”和“零次工具额度”。
- 改动前的风险:用数值投影表达无上限,会混淆零额度含义。
- 改动后:执行路径读取真实 Option 限制,旧数值接口仍保留兼容语义。
组合准入保留约束
该提交 · Core Meta Harness:配方与宿主注册组件的准入路径保留真实可选限制;显式配方限制继续生效。
- 具体接口:admit_from_compose_with_registry 与 optional_budget 的接入。
- 不能删除的边界:权限、验证门禁、取消与重复调用保护不随计数上限取消。
有限脚本回归
已提交的测试源:测试包含 128 次工具调用的受控脚本、64 次后取消、显式零额度与有限步数等情况。
- 它证明什么:在确定脚本与测试边界内核对计数和取消合同。
- 不证明什么:不能据此推算真实模型任务速度、费用或成功率。
历史验收记录
2026-10-20 验收记录:记录报告该次隔离检查共 686 项通过、2 项已有忽略;同时明确全工作区检查仍有失败。
- 记录范围:历史验收对应当时冻结的源与命令。
- 当前状态:本网页没有重新执行那些 Rust 检查,历史通过不能冒充当前 CI。
候选之外的门禁
Core 合同与该次修复范围:可替换执行策略与固定治理边界分开。计数取消不产生权限,也不把未决副作用变成成功。
- 工程演进:这是 Meta Harness 可以承载的实际策略修复。
- RSI 映射:未来宿主可以把类似差异作为候选评估;搜索、接纳与回滚仍需宿主实现。
None · 无计数上限
已提交的额度合同 · 配置分支:显式无计数上限的交互路径可以继续执行长工具脚本;权限、取消和完成检查仍然生效。
- 配置语义:显式无计数上限的交互路径可以继续执行长工具脚本;权限、取消和完成检查仍然生效。
- 验证依据:对应同一提交中的 unbounded_counts.rs 回归场景;不把该配置分支当成某次真实模型运行结果。
Some(0) · 零次工具
已提交的额度合同 · 配置分支:显式零工具额度会阻止工具执行,不能被解释成无上限。
- 配置语义:显式零工具额度会阻止工具执行,不能被解释成无上限。
- 验证依据:对应同一提交中的 unbounded_counts.rs 回归场景;不把该配置分支当成某次真实模型运行结果。
Some(n) · 正数上限
已提交的额度合同 · 配置分支:明确设置的有限额度仍约束工具次数,达到上限后停止相应调用。
- 配置语义:明确设置的有限额度仍约束工具次数,达到上限后停止相应调用。
- 验证依据:对应同一提交中的 unbounded_counts.rs 回归场景;不把该配置分支当成某次真实模型运行结果。
- DGM:编码 Agent 自修改。 从初始实现、档案库和父代选择,钻取文件工具细化、多候选评审、编码评估与演进谱系。结果节点只展示作者报告的端点,不补造中间性能曲线。DGM 论文。
- STOP:改进器改进自身。 查看种子改进器怎样生成候选、用效用选择程序,再把自身作为待改进对象。搜索策略按分支展示,不拼接为虚构的上线顺序。STOP 论文。
- Aster:长任务预算修复。 查看一次真实提交如何区分无上限与零额度,并让装配准入保留显式约束。测试与验收节点链接到该提交的源文件和历史记录。这是人工组织的工程演进,不是自主 RSI 的证明。该次验收。
“演进历程”使用相连的阶段节点。选择阶段后,图谱聚焦并展开改动、判断与来源。“钻取节点”进入内部视图。阶段表示论文算法或工程阅读顺序,不补造日期、耗时和上线记录。右上角的专注按钮可隐藏文档导航。
拖动球形图谱可改变观察角度。点击节点后,从当前对象进入“关系类别 → 具体记录”的内部视图。全局图缩到角落时,文字保持可读字号。选择内部记录可查看说明。按 Escape 或“返回全局图”回到原节点。
在全局视图点击“开始讲解”,演示按当前案例的阶段依次钻入节点。在已打开的节点中点击时,只回放该节点的记录。光点沿全局关系、跨层连接和内部支路抵达目标。
节点随后出现短暂亮环,说明卡同步切换。当前序号表示讲解记录,不表示真实工具调用次数。“暂停讲解”保留进度。手动选择节点、记录或时间轴阶段会停止自动推进。
“暂停动效”停止绘制并保留静态关系。系统启用减少动态效果时,不自动回放;按钮改为“下一条讲解”,每次只显示一条记录。页面隐藏或离开视口后停止绘制与自动推进。
教学推演:两轮改进与回滚
以下虚构任务说明宿主决策:接口已经迁移,但调用方仍依赖旧签名。h0、h1、h2 和评估集 e1、e2 都是教学标识,不是上面三个案例的真实实验版本。
从 h0 到 h1:验证有限改变
基线 h0 直接编辑接口,兼容性检查暴露遗漏的调用方。改进者根据失败提出 h1:“编辑前先检查调用方”。候选只改变工作方式;模型、权限、预算、任务集 e1 与验收要求保持相同。
宿主为 h0 与 h1 分别创建隔离工作区和新会话,收集完整结果与收尾证据。示例设定这些证据支持接纳 h1;实际系统必须用真实对照运行得到这个结论。宿主记录采纳理由后,h1 才成为后续新运行的基线。
h1 参与产生 h2:递归的位置
第二回合的改进者已经采用 h1 的执行方式,并提出 h2:缩短检索上下文以减少输入。改进过的执行程序继续参与下一轮候选生成与验证,递归发生在这一环节。重复同一个提示不能证明递归改进。
示例中的 h2 漏掉跨模块调用,在留出任务上失败。宿主拒绝 h2,继续使用 h1。h2 没有生效,因此这一步叫“拒绝候选”,不叫“回滚”。失败候选的内容、原始结果和拒绝理由也要保留。
已采纳版本出现新回归:恢复基线
另一条分支中,已采纳的 h1 在新任务上暴露兼容性回归。宿主先取消原 Run,等待资源收尾,核实结果未知的外部操作,再恢复 h0 供后续运行使用。恢复配方不自动撤销已发生的文件或业务操作;这些效果需要另行核实和处理。
新失败可以进入下一版评估集 e2,但 e1 与其原始结果继续保留。比较必须标明任务集版本。e2 的分数不能作为 e1 上的提升,候选也不能通过删除失败检查来证明自己更好。
普通任务与改进任务
普通编码任务的目标是修改项目。改进任务还要修改完成任务的执行程序,并证明新方法在相同约束下更好。
假设候选 B 提议“先检索调用方再编辑”,基线 A 直接开始修改。比较时必须固定任务集合、模型设置、预算和验收条件,并分别运行。单次任务通过或模型自称能力提高,都不足以决定替换基线。
- 01固定比较依据
宿主保留原输入、检查器和基线。
- 02执行与记录
候选仍经过原有权限和运行约束。
fact_control.rsL126 ↗ - 03依据证据决策
检查失败或证据缺失时,宿主保留失败结果。
harness_loop.rsL1591 ↗
候选管理、实验调度、评分、采纳与回滚由宿主实现。Meta Harness 提供可组合和替换的执行过程,以及它与原有会话的接入边界。
Meta Harness 在改进实验中的职责
| 实验需求 | Meta Harness / Core 的职责 | 宿主的职责 |
|---|---|---|
| 描述一个候选策略 | 组合配方、提示槽、host 组件或完整组件树 | 保存候选内容、版本与准确来源 |
| 替换执行方式 | 在原有会话执行路径中装配组件 | 构建、检查并明确选择要接纳的实现 |
| 使用相同约束运行 | 工具权限、调用限制、工作策略和验证入口 | 固定实验配置、数据集与资源预算 |
| 核对实际结果 | 事实日志、修改回执、验证报告和准确 Run 状态 | 定义分数,比较基线,保留失败证据 |
| 停止失败候选 | 原运行的取消与资源收尾 | 等待退出,核实外部操作,恢复已知基线 |
Aster 将执行过程作为实验对象。Meta Harness 提供组合和替换执行策略的边界。宿主负责保存结果、比较候选并决定采纳。
候选可修改的范围
先选择容易比较和回退的修改,例如提示槽、检索资料、工具调用程序、调用预算或默认组件组合。需要更大改变时,再评估宿主组件或 Assembler。
原生 Rust 实现必须经过宿主的构建、测试和接纳流程。host:<id> 只查宿主已有注册表,模型不能用这个字符串下载或装入任意代码。候选需要编译执行时,还要给它独立的工作区和受控运行环境。
验证要求、权限决定、评估集合及采纳规则也需要版本与所有者。候选可以提出修改建议,是否采用由宿主记录。否则“删除一项失败检查”就可能被误算成能力提高。
版本与摘要的身份
| 标识 | 含义 | 用途 |
|---|---|---|
| 候选版本 | 本次测试选择了哪份配方、代码和模型设置 | 由宿主保存,实验结果关联同一份内容 |
| 动作 key 与 Run ID | 哪次运行中的哪个动作已经执行 | 用于恢复和控制,换 key 前检查旧日志 |
| effect_digest | 本次任务修改的工作区内容摘要 | 让验证报告对应当前修改,不代替候选版本 |
| 文档版本 | 某个产品版本的接口和用法说明 | 便于接入者查阅,不是某次实验的执行身份 |
一次 Run 验证通过,只能支持它检查过的任务。证明候选更好,还需要宿主比较一组任务的表现。除成功率外,还要比较工具调用量、使用量、耗时、失败模式和收尾结果。实验前应明确权衡规则。
改进实验步骤
- 保存基线配置、模型设置和实现来源,固定训练任务与独立留出任务。
- 提出范围明确的候选,例如只改变“编辑前检查调用方”的步骤。
- 检查候选差异。原生代码先通过小型无网络测试,再决定是否装入实验宿主。
- 为基线与候选分别创建隔离工作区和新会话,固定任务、权限、预算与验证要求。
- 等待原运行和资源收尾,保存回执、报告、停止原因及原始结果。先核实未知外部操作。
- 按预定规则比较结果。必要时重复试验,并记录采纳或拒绝理由。
- 采纳后保留可恢复的基线。下一轮使用新的候选身份,单独处理旧会话的动作 key 和恢复记录。
宿主负责组织实验流程。调用 with_harness 不会启动自动实验服务。长期目标接口可以帮助有界推进工作,但候选搜索和实验评分仍由应用实现。
评估标准的保护
候选可能改变评估自身的标准,例如放宽测试、扩大权限或少报失败。候选也可能把取消和清理异常排除在统计之外。每轮必须固定评估依据并保存可回查的结果。
增加记忆、延长任务计划或重复同一段提示,都需要各自的对照实验。接入 Meta Harness 只建立运行条件,效果仍需测量。
先用终端教程的 Harness 章节创建一个配方,再用验证与收尾章节建立失败场景。确认实验流程可核对后,再扩大候选的修改范围。