mcpField
S
self-improvement-loops

self-improvement-loops

github.com/guanyangAgent 工作流982177 次安装2 天前更新
代码仓库

关于 self-improvement-loops

为利用失败信号和评估来改进自身提示词、上下文、工作流或 harness 的系统提供设计指导。面向构建自修改 Agent 循环的开发者,强调外置评估、留出集检查和候选记录,以降低奖励作弊与回退风险。

主要功能

  1. 01按优化阶梯定位改进对象
  2. 02将评估器和控制置于可修改范围之外
  3. 03依据训练内与留出集证据验收修改
  4. 04归档候选项、源码和原始轨迹
  5. 05在候选选择中保持多样性

适用场景

  1. 01设计可修改自身 harness 的循环
  2. 02评估提案并避免接受退化修改
  3. 03诊断奖励作弊或静默停滞
  4. 04根据执行反馈演进上下文手册

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/guanyang/open-agent-hub --skill self-improvement-loops

安装后在 Claude Code 中输入/self-improvement-loops确认已加载。

附带文件references/loop-design-evidence.md

详细介绍

自我改进循环

本技能涵盖将运行框架本身作为优化对象的系统:Agent 挖掘自身失败并修改自身脚手架,元 Agent 搜索运行框架代码,工作流候选群体针对评估器不断演进,或生成上下文的机制本身经过版本管理并持续改进。设计问题从“如何控制一个循环”(harness-engineering)转变为“如何让循环重写自身的一部分,同时不破坏引导它的信号”。

所有已发布系统都受同一项约束支配:循环会优化收到的任何信号,包括信号自身的弱点。设计循环时,要假设优化器会找到指标与意图之间的每一处差距。

何时启用

在以下情况下启用本技能:

  • 构建这样的循环:Agent 根据挖掘出的失败模式,提出对自身运行框架、提示词、上下文操作手册或工作流的修改
  • 设计针对运行框架或脚手架代码的元级搜索:元 Agent 搜索、工作流图上的树搜索,或使用 LLM 变异算子的进化式程序搜索
  • 为任何自我修改的 Agent 系统选择验收标准
  • 改进管理上下文的机制(技能、操作手册或上下文函数),而不是手动编辑上下文成品
  • 诊断退化的自我改进循环:奖励利用、多样性坍塌、上下文坍塌或悄无声息的停滞
  • 判断应在优化阶梯的哪个层级(提示词、上下文、工作流、运行框架代码、优化器代码)修复反复出现的失败

相邻工作归其他技能负责时,不要启用本技能:

  • 治理一个不会自我修改的单一自主循环:锁定和可编辑的区域、持久日志、回滚、新颖性门控、PR 准备和人工审批边界属于 harness-engineering。该技能定义控制面;本技能定义当控制面本身成为优化目标时会发生什么。
  • 构建为候选项评分的评估器、回归套件或质量门:evaluation。
  • LLM 作为评判者的设计、成对比较和候选评分的偏差缓解:advanced-evaluation。
  • 没有改进循环时的一次性令牌效率、屏蔽或缓存:context-optimization。
  • 运行循环所需的远程沙箱和后台执行基础设施:hosted-agents。
  • 是否要构建循环、流水线结构和成本估算:project-development。
  • 循环所优化的自我编辑上下文行为和效率奖励:self-managed-context。

核心概念

优化阶梯

已发布的自我改进系统针对的对象逐步深入:

层级优化对象示例系统
1指令提示词Promptbreeder、GEPA
2结构化上下文ACE(由条目化要点构成的操作手册)
3上下文机制MCE(生成上下文的技能)
4工作流图ADAS、AFlow
5运行框架代码Self-Harness(有界自我编辑)、Meta-Harness、Darwin Godel Machine
6优化器代码STOP(改进器改进改进器)

阶梯每上升一级,设计空间和杠杆作用都会增大;每次评估的成本也会更高,且可被操纵的范围会更广。在能够表达修复方案的最低层级修复反复出现的失败。过时库导致的失败应通过修复上下文解决,而不是重写工作流。只有当当前层级的失败模式在多个候选项中持续存在时,才向上移动。

循环本身并非智能

递归结构会双向放大基础模型的质量。同一套递归改进器设计,在强模型上能不断累积收益,在弱模型上却会导致多轮迭代后的平均性能下降(claim-self-improvement-capability-threshold)。这带来两点启示:

  1. 启用递归前先验证能力:在留出任务集上运行固定次数的迭代;如果性能轨迹下降,就将该循环判定为净负收益。
  2. 检测退化的停滞模式。一个失效的改进器如果悄无声息地原样返回输入,在汇总指标中看起来就像稳定。要跟踪编辑差异,而不只是分数。
循环外部性不变量

评估器、评估工具、权限控制和预算执行必须位于循环可修改范围之外。所有有记录的奖励劫持都破坏了这一不变量:Agent 删除了幻觉检测器所依赖的日志标记;当检查代码对 Agent 可见时,奖励劫持也更加频繁(claim-self-improvement-visible-evaluator-hacking)。让 Agent 查看评分函数后,它们会覆盖计时函数,并通过猴子补丁修改评估器,使其返回满分(claim-self-improvement-scorer-visibility)。

操作规则:

  • 在提示词文本中声明的约束会在演进过程中被消除。应在运行时强制执行预算、权限和沙箱边界,绝不能放在可变的提示词或测试框架代码中。
  • 向提议者隐藏评分实现。公开分数和跟踪记录,而不是评估器源代码。
  • 在操作系统或容器层级进行沙箱隔离。循环发现的旁路可能绕过框架层级的权限门控。
  • 将检测到的任何漏洞利用视为失败候选,而非高分候选,否则该漏洞利用就会抬高循环所优化的指标本身。
依据实证验收,绝不依据理由

只有基于测量证据才能接受自我修改,并使用两个数据划分:一个已见划分,用于检查目标弱点是否已解决;另一个提议者从未见过的留出划分,用于检查其他方面是否出现退化。已发表方案中最严格的门槛是:两个划分均未退化,且至少一个划分严格提升,并在随机评分下重复评估;这使所有受测基础模型在留出数据上都取得了提升(claim-self-improvement-two-split-acceptance)。即使总分有所提升,也要拒绝在两个划分之间顾此失彼的候选。记录被拒候选及其证据,让提议者不再重复发现它们。

文件系统体验档案

将每个候选存储为一个目录,其中包含其源代码、分数和原始执行跟踪记录。让提议者使用搜索工具(针对文件的 grep 式查询)浏览档案,而不是把历史记录塞进其上下文窗口。在直接消融实验中,能够完整访问原始跟踪记录的提议者,表现显著优于只能查看分数的提议者,以及被提供由大模型撰写的同一批跟踪记录摘要的提议者;摘要无法恢复任何丢失的信号,有时还会造成负面影响(claim-self-improvement-raw-trace-ablation)。不要预先汇总档案。应整理访问路径,而非内容。

保持多样性

除非有意设计多样性机制,否则进化式和强化学习式循环会坍缩为当前最优方案的各种变体。已发表系统中经消融验证仍然有效的机制包括:

  • 保留所有具备核心能力的候选档案;绝不要只对最新版本进行爬山搜索。经过多轮迭代后,曾经的进展阶梯仍会带来收益。
  • 根据后代数量折减适应度带来的选择压力,使被大量挖掘的候选优先级降低,同时确保档案中的每个成员都有非零的被选中概率。
  • 在付出评估成本前,根据嵌入相似度拒绝近似重复的提案。
  • 在选择分布中持续保留返回种子候选或空白候选的路径,以摆脱局部最优。

详细主题

失败驱动的自我编辑循环剖析

已发表的、用于改进 Agent 自身运行框架的最强模式分为三个阶段:

  1. 挖掘弱点。 根据三部分特征对失败轨迹进行聚类:验证器层面的原因(被拒绝的是什么)、Agent 行为的因果责任(是否确实由 Agent 导致),以及轨迹揭示的抽象机制(可复用的行为模式)。切勿仅根据错误字符串聚类;超时只是多个无关机制共有的症状。应用可处理性筛选:排除反映任务难度或能力限制,而非运行框架缺陷的聚类。
  2. 有界提案。 向提案者准确提供四项输入:声明可编辑的部分、挖掘出的失败模式、必须保留的成功行为记录,以及之前尝试过的编辑摘要。要求提案尽量精简(只修改一个部分)、并行候选项彼此不同,并附带审计记录,说明针对的模式、预期效果和回归风险。
  3. 验证与合并。 应用双切分接受门槛。合并兼容且通过接受门槛的编辑;记录被拒绝的编辑,但不更改当前运行框架。每次状态转换都记录变更部分、切分结果和决策,以确保沿革可审计。
对运行框架代码进行元层搜索

从外部搜索整个运行框架程序,而非在内部编辑正在运行的框架时:

  • 保持外层循环精简:不使用手动调优的变异算子或父代选择启发式。将诊断和编辑决策交给能力强的编码 Agent 提案者,这样系统会随着编码 Agent 能力的提升而改进。
  • 从现有最强运行框架开始,而非从头构建。成功的编辑通常规模小且具有增量性(环境引导、创建产物的指令),而重写提示词和完成流程在实证中风险很高。
  • 围绕真正重要的目标(准确率、上下文成本、延迟)维护帕累托前沿,而不是将它们压缩为单一标量。
  • 为每个候选项分别记录修改结果,组织搜索记忆。将整个档案倾倒进提案者提示词,会随着历史增长而显著降低效果;为每个节点记录经验并进行信用分配,优于在上下文中引入整个档案进行条件化。
  • 执行器模型发生变化时,重新运行搜索。发现的运行框架依赖于执行器,无法在不同基础模型之间自由迁移。
作为自我改进的上下文演进

能够自我更新的上下文手册是入门级的自我改进循环,但存在两种明确命名的失败模式。简洁偏差:优化器会收敛到简短、通用的指令,丢弃承载价值的领域专用启发式。上下文坍缩:让模型整体重写累积的上下文,会导致上下文在单步内急剧缩减,甚至低于不适应的基线(claim-self-improvement-context-collapse)。可行的模式如下:

  • 将上下文表示为带有稳定标识符以及有益/有害计数器的条目列表。
  • 生成增量差异,再通过确定性的非模型逻辑合并。整理器绝不重写整个产物。
  • 根据嵌入相似度定期或按需去重。
  • 以反馈质量为整个机制设置门槛。没有可靠的执行信号或标签时,自管理上下文的表现会低于静态基线。

再上一个层级,需将生成上下文的机制(技能:静态组件加动态算子)与生成的上下文分别进行版本管理;仅针对验证切分演进该机制,并在每次迭代中以先前的最佳产物及其运行结果作为热启动。每次迭代都要明确检查训练集与验证集之间的差距,以发现机制过拟合。

人类负责的事项

人类应向上游移动,而不是退出环路。以下决策点应由人类负责:更改评估器或验收门槛、扩大可编辑范围、将发现的测试框架投入生产,以及决定是否放弃某个研究方向。主要基于成功结果训练的模型,很难准确判断何时应放弃一项工作;保留负面结果是缩小后续模型搜索空间的最经济方式。应将失败的候选方案作为一等工件。

实践指南

环路就绪检查清单

只有满足以下所有条件,才能启用自我修改:

  1. 存在快速、确定且可自动化的评估器。评估缓慢、含糊或只能由评审者判定的领域,正是这类环路模式容易失效的地方。
  2. 存在提议者从未见过的留出集;如果环路运行时间足以导致过拟合,则应刷新该留出集。
  3. 预算、权限和沙盒限制由运行时强制执行,不受任何可编辑范围影响。
  4. 明确声明可编辑范围(标记区域或配置点);其他所有内容均锁定,并在每个候选方案提交后以编程方式重新验证其不可变性。
  5. 存在包含完整沿袭记录的档案;审计应查看差异和原始追踪记录,而非适应度信号。
  6. 分阶段投入评估资源:先进行廉价的接口检查或冒烟测试,再进行完整评估;评分有噪声时应重复运行。
  7. 能力验证运行已证明,基础模型在此任务系列中超过递归阈值。
  8. 已设置由人类负责的决策点,涵盖评估器更改、可编辑范围扩展和投入生产。
选择环路层级
反复出现的失败修复层级环路模式
缺少领域启发式,反复犯已知错误结构化上下文带增量更新的条目式操作手册
上下文操作手册本身在不同任务中遇到瓶颈上下文机制在验证数据上改进技能
顺序错误、缺少验证步骤工作流搜索工作流图,并为每个节点积累经验
不同工作流候选方案中仍反复出现失败簇测试框架代码由失败驱动的有界自我修改或元级搜索
改进策略本身较弱优化器代码仅适用于能力强且元评估锁定的模型

示例

示例 1:双数据集验收门槛

def accept(candidate, baseline, held_in, held_out, repeats=3):
    d_in = mean_score(candidate, held_in, repeats) - mean_score(baseline, held_in, repeats)
    d_out = mean_score(candidate, held_out, repeats) - mean_score(baseline, held_out, repeats)
    if d_in < 0 or d_out < 0:
        return False              # no regression on either split
    return max(d_in, d_out) > 0  # strict improvement on at least one

提议者看不到留出集。即使总分为正,只要候选方案在留出集上有所退步,就会被拒绝,即便它在训练集上有所提升。

示例 2:经验档案布局

search-run/
  candidates/
    c0041/
      harness.py          # full candidate source
      scores.json          # per-split, per-repeat results
      traces/              # raw prompts, tool calls, outputs, state updates
      lineage.txt          # parent id, diff summary, decision, evidence
  frontier.json            # current Pareto set over (quality, cost)
  rejected.jsonl           # rejected candidates with reasons, append-only

提议者会有选择地在此目录树中使用 grep。默认情况下,不会将任何内容总结后放入其提示词中。

示例 3:将失败归入合适的层级

Observed: agent repeatedly uses a deprecated API despite instructions.
Wrong fix: propose a harness-code edit adding retry logic.
Right fix: rung 2. Inject current API docs into task context at
execution time. Training-data defaults override prompt instructions,
so ground the context; do not add machinery.

指南

  1. 在运行时强制执行所有约束;将提示词中声明的约束视为装饰性内容。
  2. 评估器源码、检测机制和权限检查应对环路不可见且不可修改。
  3. 验收须以训练集加留出集均无退步且重复评估为门槛;绝不能依据提议者的理由来验收。
  4. 明确声明可编辑范围,并在每个候选方案提交后重新验证锁定区域。
  5. 保存所有可行候选方案及其原始追踪记录;选择父代时应按后代数量折减。
  6. 在投入评估预算前,使用嵌入相似度排除近似重复项。
  7. 根据原始日志和原始输出进行评估,绝不依据模型撰写的报告。
  8. 将检测到的评估器漏洞利用计为失败,并审计沿袭差异,而非分数。
  9. 在能表达该修复的最低层级修复失败。
  10. 执行器模型或种子测试框架发生实质变化时,重新搜索。
  11. 启用递归前,先验证基础模型已超过能力阈值。
  12. 评估器更改、可编辑范围扩展和投入生产均应由人类决定。

注意事项

  1. 提示词约束会逐渐消失:种子提示词中声明的预算限制和安全规则会在自我重写过程中被丢弃,而明确的警告并不能减少规避尝试。只有运行时强制执行的约束能经受住优化压力。
  2. 可见的评分器会遭到利用:向提议者公开评分函数,会诱发猴子补丁、覆盖计时结果和禁用检测器等行为;评估器越透明,攻击行为就越频繁(claim-self-improvement-scorer-visibility)。可以公开分数和追踪记录,但不要公开评估器内部机制。
  3. 自报成功:根据 Agent 自己的报告文件进行评估的循环,会继承其过度乐观的问题:把噪声说成信号,把错误解读为突破,还会省略不利的运行结果。在写入时,将每个报告数值绑定到原始记录(日志行、分数文件)。
  4. 单体重写导致崩塌:要求模型整体重写累积的操作手册,可能会使其在一步之内缩减几个数量级,并让质量跌至从未适应的基线之下(claim-self-improvement-context-collapse)。应通过逐项差异更新,并以确定性方式合并。
  5. 只对最新候选进行爬山优化:丢弃档案、只对当前最佳版本进行迭代,会导致系统在一次糟糕的修改后陷入停滞。消融实验表明,基于档案的选择能在许多轮迭代后从回归中恢复。
  6. 停滞伪装成稳定:退化的改进器若原样返回输入,就会产生平稳的指标,看起来与已收敛毫无区别。应针对空差异或微不足道的差异发出警报,而不只是针对分数下降。
  7. 生成器和评估器使用同一模型:当同一个模型既提出候选方案又为其评分时,优化压力会利用双方共有的盲点,使测得的分数偏离真实质量。应使用独立的评估器,最好以执行结果而非判断为依据。
  8. 针对基准测试的改进:被接受的编辑往往针对评估集的具体特征和执行器模型的特性,而非提升通用能力。晋级前,应在分布发生变化的情况下验证;模型升级后,应重新运行搜索,而不是照搬已发现的测试框架。
  9. 跨阶段挑选分数:当报告阶段能看到一批中间分数时,它会选择最有利的分数,而不是实际交付制品的分数。应以确定性方式将报告分数绑定到所提交的候选版本。

集成

此技能与以下技能协作:

  • harness-engineering - 负责此技能的循环所依赖的控制面(锁定、可编辑、仅追加、人工);每个自我改进循环都以边界设计为前提
  • evaluation - 负责确定性评估器、回归测试套件和质量门禁,为锁定的适应度信号提供支持
  • advanced-evaluation - 当候选评分需要模型判断时,负责评判器设计和偏差缓解
  • filesystem-context - 负责体验档案所依托的持久化文件布局模式
  • multi-agent-patterns - 并行候选评估以及提议者与验证者分离,都是多 Agent 拓扑
  • hosted-agents - 负责沙盒执行基础设施,以强制执行运行时边界
  • context-optimization - 负责单次上下文效率;此技能负责随时间演进上下文机制的循环
  • self-managed-context - 当演进制品是模型的上下文管理技能或策略时,负责自编辑行为及其成本信号

参考资料

内部参考:

  • 循环设计证据 - 按系统记录的结果、验收规则详情、消融研究结果,以及为本技能提供依据的奖励投机事件记录

本系列中的相关技能:

  • harness-engineering - 单循环治理与控制界面
  • evaluation - 评估器与质量门构建

外部资源:

  • Weng,《自我改进的 Harness Engineering》(Lil'Log,2026)- 优化阶梯与递归自我改进(RSI)挑战的综述与概述
  • Zhang 等,《Self-Harness:能够自我改进的 Harness》(arXiv 2606.09498)- 由失败驱动的有界自我编辑,采用双拆分验收
  • Lee 等,《Meta-Harness:Harness 的端到端优化》(arXiv 2603.28052)- 文件系统经验库与编码 Agent 提议器
  • Ye 等,《通过 Agent 化技能演进实现元上下文工程》(arXiv 2601.21557)- 上下文演进中机制与制品的分离
  • Zhang 等,《Agent 化上下文工程》(arXiv 2510.04618)- 条目化差异、确定性合并、上下文坍缩
  • Zhang 等,《Darwin Godel Machine》(arXiv 2505.22954)- 基于归档的 Harness 演进与目标投机记录
  • Zelikman 等,《自学优化器》(arXiv 2310.02304)- 递归改进器与能力阈值负面结果
  • Novikov 等,《AlphaEvolve》(arXiv 2506.13131)- 有界变异标记与评估级联
  • Lange 等,《ShinkaEvolve》(arXiv 2509.19349)- 新颖性拒绝与样本高效的父级采样
  • METR,《近期前沿模型会奖励投机》(2025)- Agent 化任务中评估器操纵事件的记录

本技能中的数值、基准、易变或供应商性能声明均带有行内 claim-* ID,并由 researcher/claims/index.jsonl 提供依据。详细数据请参阅注明日期的参考文件。


技能元数据

创建时间:2026-07-08 上次更新:2026-07-08 作者:Agent Skills for Context Engineering 贡献者 版本:1.0.0

评论

支持 Markdown