Aster文档
搜索 Aster 文档
ESC
产品
版本

输入关键词开始搜索。

    文档目录

    ASTER CODE / 设计原理

    RSI 与 Meta Harness

    候选执行策略的替换、评估、采纳和回滚。

    RSI 的改进对象

    RSI 是 Recursive Self-Improvement,即递归自我改进。Aster 讨论执行程序的递归改进。智能体提出工作方式的修改,宿主评估并采纳有依据的候选,再用新方式组织后续改进。修改对象包括提示、上下文策略、工具使用程序和调度组件。

    这类改进发生在模型外部的执行程序上,不涉及模型权重训练,也不证明能力可以无限增长。STOP 研究改进程序对自身代码的修改。DGM 生成并评估经过自修改的编码智能体。STOP 论文、DGM 论文。

    执行程序演进案例

    从图谱左上角选择案例。点击节点可钻取细节,打开“演进历程”可按阶段阅读。DGM 与 STOP 根据原始研究重建算法关系,Aster 案例追溯仓库中的实际工程改动。每个节点都提供来源。“Aster 接入映射”表示应用设计建议。

    “场景、改动、决策、方案、结果、依据”标明节点职责,箭头给出方向。条件标签显示分支结果。DGM 的有效性判断分为“入档”与“不入档”。STOP 展示论文报告的三类搜索策略。Aster 额度修复区分无计数上限、零工具额度和有限正额度。机制分支不表示一次已经发生的运行。

    真实案例 · 执行程序如何演进可钻取图谱 · 非实时运行数据
    DGM · 编码 Agent 自修改
    文献流程重建 · 2025

    基于 DGM 原论文第 3–4 节、图 3 与附录 C。阶段顺序表达算法流程,连线不是完整实验谱系;改动和结果来自作者报告,未在 Aster 中复现。

    当前场景编码 Agent 怎样改进自己的工具与工作流?

    目标:保留有效自修改,再从档案继续探索。

    会话组件候选证据门禁失败光点 · 关系方向示意
    文献流程重建 · 2025从初始 Agent 出发

    先建立能读写与执行代码的初始 Agent,基础模型保持冻结。

    查看来源依据 ↗

    观察对象:编码 Agent 的实现。

    演进历程6 个阶段

    DGM · 编码 Agent 自修改

    文献流程重建 · 2025

    案例与证据边界

    基于 DGM 原论文第 3–4 节、图 3 与附录 C。阶段顺序表达算法流程,连线不是完整实验谱系;改动和结果来自作者报告,未在 Aster 中复现。

    初始条件
    初始 Agent 使用整文件操作;基础模型冻结。
    判断条件
    候选能编译并继续编辑代码吗?
    结果
    有效候选入档;无效候选排除。
    原始依据 ↗
    从初始 Agent 出发

    先建立能读写与执行代码的初始 Agent,基础模型保持冻结。

    观察对象:编码 Agent 的实现。

    从档案选择父代

    选择父 Agent,让已有版本参与产生后继。

    档案提供多条探索路线。

    钻取实际工具改动

    点击文件工具,查看作者报告的整文件操作到细粒度操作的改变。

    来源定位:论文 §4.4 与附录 C。

    查看工作流演进

    打开多候选与评审,查看生成多个方案、比较选择与尝试历史。

    来源是作者报告,不补造单次运行日志。

    判断是否可以继续演化

    候选经编码评估后接受有效性检查。能编译并继续编辑代码则入档;否则排除。低分但有效的分支仍可作为后续跳板。

    有效性决定入档;即时分数不等于全部探索价值。

    核对结果及局限

    查看报告的端点结果,再进入下一轮父代选择。

    不画未经来源提供的中间性能曲线。

    节点说明与全部来源

    初始编码 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,查看候选生成与效用选择的输入输出。

    来源:论文图 2。

    进入自应用步骤

    把改进器自己变成待优化的程序。

    来源:论文图 3 与 Algorithm 1。

    钻取搜索策略

    查看作者报告的不同搜索程序思路。

    不同策略是分支,不能伪造为同一条历史。

    评价下一代

    用下游任务效用评价改进器,而非让它自己宣称更好。

    元效用关联真实下游结果。

    继续递归

    下一代改进器再参与生成后继。

    不等同于基础模型权重自训练。

    节点说明与全部来源

    Seed improver

    STOP 图 2:种子改进器多次请求模型生成程序候选,再按效用函数选择。

    • 输入:初始程序、效用函数和语言模型。
    • 输出:在本次候选中按效用选择的程序。
    节点来源 ↗

    下游效用

    STOP Algorithm 1:效用衡量改进后的程序在下游任务上的表现。

    • 任务层:先运行改进器得到程序,再评价这个程序。
    • 元层:改进器的价值来自它改善下游程序的能力。
    节点来源 ↗

    以自身为输入

    STOP 图 3、Algorithm 1:将改进器自身代码交给改进器,以元效用评价产生的新改进器。

    • 递归步骤:上一代改进器参与生成下一代改进器。
    • 模型边界:论文未修改基础语言模型本身。
    节点来源 ↗

    哪个候选的效用最高?

    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?
    结果
    三个配置分支各按其合同执行,并接受回归验证。
    原始依据 ↗
    从真实问题进入

    点击失败节点,查看长任务次数上限的实际修复范围。

    来源:提交 ba17a7ca6。

    进入装配准入

    查看组合路径如何继承限制,哪些门禁不受影响。

    装配可变,权限与完成边界保留。

    钻取预算语义

    核对 None、零额度和显式限制的区别。

    保持 SDK 兼容语义。

    查看回归测试

    进入具体测试源,查看长脚本、取消与显式上限。

    测试场景不是模型任务收益。

    追溯历史验收

    打开该次记录,阅读通过项、忽略项和已知限制。

    历史证据与当前工作树状态分开。

    节点说明与全部来源

    长任务被截断

    提交说明与工程证据:交互式 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 直接开始修改。比较时必须固定任务集合、模型设置、预算和验收条件,并分别运行。单次任务通过或模型自称能力提高,都不足以决定替换基线。

    架构图FIG. 08 · 递归改进的实验闭环宿主固定评估依据,检查并运行候选,根据完整证据决定采纳或回退。Meta Harness 提供可替换的执行过程。
    一次候选改进怎样接受检查这是宿主组织的实验路径。图示不声称模型质量已有提升。固定基线原始检查提出候选宿主选择执行候选同一边界核对证据结果与成本接受或回退宿主决定
    1. 01固定比较依据

      宿主保留原输入、检查器和基线。

    2. 02执行与记录

      候选仍经过原有权限和运行约束。

      fact_control.rs L126 ↗
    3. 03依据证据决策

      检查失败或证据缺失时,宿主保留失败结果。

      harness_loop.rs L1591 ↗

    下载 SVG ↗

    候选管理、实验调度、评分、采纳与回滚由宿主实现。Meta Harness 提供可组合和替换的执行过程,以及它与原有会话的接入边界。

    Meta Harness 在改进实验中的职责

    改进实验需要的能力与接入位置
    实验需求Meta Harness / Core 的职责宿主的职责
    描述一个候选策略组合配方、提示槽、host 组件或完整组件树保存候选内容、版本与准确来源
    替换执行方式在原有会话执行路径中装配组件构建、检查并明确选择要接纳的实现
    使用相同约束运行工具权限、调用限制、工作策略和验证入口固定实验配置、数据集与资源预算
    核对实际结果事实日志、修改回执、验证报告和准确 Run 状态定义分数,比较基线,保留失败证据
    停止失败候选原运行的取消与资源收尾等待退出,核实外部操作,恢复已知基线

    Aster 将执行过程作为实验对象。Meta Harness 提供组合和替换执行策略的边界。宿主负责保存结果、比较候选并决定采纳。

    候选可修改的范围

    先选择容易比较和回退的修改,例如提示槽、检索资料、工具调用程序、调用预算或默认组件组合。需要更大改变时,再评估宿主组件或 Assembler。

    原生 Rust 实现必须经过宿主的构建、测试和接纳流程。host:<id> 只查宿主已有注册表,模型不能用这个字符串下载或装入任意代码。候选需要编译执行时,还要给它独立的工作区和受控运行环境。

    验证要求、权限决定、评估集合及采纳规则也需要版本与所有者。候选可以提出修改建议,是否采用由宿主记录。否则“删除一项失败检查”就可能被误算成能力提高。

    版本与摘要的身份

    改进实验中的几种身份
    标识含义用途
    候选版本本次测试选择了哪份配方、代码和模型设置由宿主保存,实验结果关联同一份内容
    动作 key 与 Run ID哪次运行中的哪个动作已经执行用于恢复和控制,换 key 前检查旧日志
    effect_digest本次任务修改的工作区内容摘要让验证报告对应当前修改,不代替候选版本
    文档版本某个产品版本的接口和用法说明便于接入者查阅,不是某次实验的执行身份

    一次 Run 验证通过,只能支持它检查过的任务。证明候选更好,还需要宿主比较一组任务的表现。除成功率外,还要比较工具调用量、使用量、耗时、失败模式和收尾结果。实验前应明确权衡规则。

    改进实验步骤

    1. 保存基线配置、模型设置和实现来源,固定训练任务与独立留出任务。
    2. 提出范围明确的候选,例如只改变“编辑前检查调用方”的步骤。
    3. 检查候选差异。原生代码先通过小型无网络测试,再决定是否装入实验宿主。
    4. 为基线与候选分别创建隔离工作区和新会话,固定任务、权限、预算与验证要求。
    5. 等待原运行和资源收尾,保存回执、报告、停止原因及原始结果。先核实未知外部操作。
    6. 按预定规则比较结果。必要时重复试验,并记录采纳或拒绝理由。
    7. 采纳后保留可恢复的基线。下一轮使用新的候选身份,单独处理旧会话的动作 key 和恢复记录。

    宿主负责组织实验流程。调用 with_harness 不会启动自动实验服务。长期目标接口可以帮助有界推进工作,但候选搜索和实验评分仍由应用实现。

    评估标准的保护

    候选可能改变评估自身的标准,例如放宽测试、扩大权限或少报失败。候选也可能把取消和清理异常排除在统计之外。每轮必须固定评估依据并保存可回查的结果。

    增加记忆、延长任务计划或重复同一段提示,都需要各自的对照实验。接入 Meta Harness 只建立运行条件,效果仍需测量。

    先用终端教程的 Harness 章节创建一个配方,再用验证与收尾章节建立失败场景。确认实验流程可核对后,再扩大候选的修改范围。

    实现与研究依据