【免费下载链接】autocontext
a recursive self-improving harness designed to help your agents (and future iterations of those agents) succeed on any task
autocontext是一个递归自我改进的 agent harness:给它一个目标,它就反复生成策略、跑评测锦标赛、用门控机制决定哪些策略值得晋级。本文带你看清它内部两道关键关卡——Elo 锦标赛与Backpressure 门控——是如何决定一个策略"去"还是"留"的。
🏟️ 为什么策略需要一道"晋级之门"
autocontext 的每一代(generation)都会产出一个候选策略。如果每次都直接采用新策略,分数噪声、偶然超发挥都会污染学习结果;如果门槛太严,系统又会卡死在原地。
所以它设计了一套两级审查:
| 关卡 | 回答的问题 | 核心文件 |
|---|---|---|
| Elo 锦标赛 | 新策略到底比旧策略强多少? | elo.py |
| Backpressure 门控 | 这点提升够不够晋级?不够就重试或回滚 | gate.py |
流程一句话概括:先过锦标赛打分,再过门控裁决——只有拿到advance裁决的策略才会被写入previous_best并保留 Elo 积分,否则走retry或rollback。
🏆 Elo 锦标赛:给挑战者一个"擂台"
对局从哪里来
锦标赛的裁判是 EvaluationRunner,它让候选策略打matches_per_generation场(默认 3 场)对局。对手来自两类:
- baseline 对局:策略跑分超过 0.55 的
win_threshold即记一场胜; - self-play 对局:把本 run 里历史晋级的旧策略当作对手,同种子下比原始分,高者胜、平局记 0.5。
Self-play 池由 self_play.py 维护,是一个"滚动 Top-K 窗口"——只保留历史上最强的若干旧策略。这让系统不是只在固定基线上刷分,而是和自己的过去打,形成协同进化压力。
分数怎么变成 Elo 积分
每场对局结束后,积分按经典 Elo 公式更新,核心实现只有两行函数(elo.py):
def expected_score(player_rating, opponent_rating): return 1 / (1 + 10 ** ((opponent_rating - player_rating) / 400)) def update_elo(player_rating, opponent_rating, actual_score, k_factor=24.0): expected = expected_score(player_rating, opponent_rating) return player_rating + k_factor * (actual_score - expected)直觉很好懂:赢了强敌涨得多,赢了弱敌涨得少,输了则反向。锦标赛跑完产出一个EvaluationSummary,其中best_score和elo_after就是下一道关卡的输入。
顺带一提,评分后端是可插拔的(backends.py):默认elo,也可切换到带不确定性估计的glicko——早期噪声大的候选会因此拿到更"保守"的置信度。
🚪 Backpressure 门控:advance / retry / rollback 三选一
拿到锦标赛结果后,BackpressureGate 做最终裁决,规则只有三条:
| 条件 | 裁决 | 后果 |
|---|---|---|
delta >= min_delta(默认 0.005) | advance | 策略晋级,previous_best与 Elo 积分更新 |
| 提升不足,且重试次数未用尽 | retry | 携带失败报告重新调用竞品 agent 改策略 |
| 提升不足,且重试预算耗尽 | rollback | 丢弃本代策略,回到上一个最佳版本 |
delta就是"本代最佳分 − 历史最佳分",backpressure_min_delta则是那道看不见的门槛。它的名字很形象:给自动改进施加背压(backpressure)——不许为了"有进步"而盲目前进,防止噪声被当成实力。
retry 不是干等,而是"带伤重试"
裁决为retry时,tournament_helpers.py 里的build_retry_prompt会把失败上下文拼进提示词——上一版策略得了多少分、差多少 delta 才够线,再附上 failure_report.py 生成的逐场失败分析,然后让竞品 agent 重做一版。这是"重试即学习",而非机械重跑。
📈 趋势感知门控:卡在平台上时怎么办
如果连续几代分数都挤在同一区间(进入平台期),死守 0.005 的门槛可能让系统永远卡住。所以默认 preset 用的是升级版 TrendAwareGate,它内置两个"松闸"机制:
- 平台期检测:最近 3 代分数极差小于
min_delta时,门槛自动减半(plateau_relaxation_factor = 0.5); - 连续回滚检测:连续 3 次
rollback时同样放宽门槛。
换句话说:平时严格,卡住时自动给一条更窄的缝隙,避免改进循环僵死。
⚙️ 三个 preset:门控松紧一键切换
不同运行目标下,门控策略开箱即配(presets.py):
| Preset | 每代对局数 | 门控模式 | 说明 |
|---|---|---|---|
rapid | 2 | simple +min_delta=0.0 | 快跑模式:任何提升都放行,不设重试 |
standard | 3 | trend(默认) | 平衡模式:趋势感知 + 平台期松闸 |
deep | 5 | trend | 深度模式:更多对局 + 每 3 代整合 curator 知识 |
想微调时,两个最常动的旋钮都在 settings.py:backpressure_min_delta(门槛高低)和matches_per_generation(样本量多少)。样本越多分数越稳,但 API 成本也越高——这是典型的精度/成本权衡。
📂 关键模块路径速查
| 想改什么 | 去哪里 |
|---|---|
| Elo 公式与 K 因子 | autocontext/src/autocontext/harness/scoring/elo.py |
| 门控三态裁决 | autocontext/src/autocontext/harness/pipeline/gate.py |
| 平台期趋势门控 | autocontext/src/autocontext/harness/pipeline/trend_gate.py |
| 锦标赛执行与 self-play | autocontext/src/autocontext/harness/evaluation/runner.py、self_play.py |
| 晋级裁决与状态更新 | autocontext/src/autocontext/loop/tournament_helpers.py |
| 对局编排与重试学习 | autocontext/src/autocontext/loop/stage_helpers/tournament_prep.py |
| 行为验证测试 | test_elo.py、test_backpressure.py、test_trend_gate_integration.py |
小结:两道关卡如何"去留分明"
- Elo 锦标赛负责"量化实力"——用可复现的种子对局、可插拔的评分后端,把"新策略到底强多少"变成数字;
- Backpressure 门控负责"裁决去留"——提升过线就
advance,没到线就retry(带着失败报告再战)或rollback(回到上一最佳); - 趋势感知与 preset 提供弹性——平台期自动松闸,快速/标准/深度三档一键切换松紧。
这套设计保证了 autocontext 的自我改进是渐进且可回滚的:每一代都有据可查(delta、裁决、原因都落在事件流里),每一分提升都经得起复核。理解了这道"晋级之门",你就理解了 autocontext 递归自我改进循环里最核心的质量阀门。
【免费下载链接】autocontext
a recursive self-improving harness designed to help your agents (and future iterations of those agents) succeed on any task
相关推荐
DLSS Swapper 三步切换完整指南
DLSS Swapper 三步切换完整指南 DLSS Swapper 是一款 Windows 游戏 DLL 替换工具,能自动识别游戏里自带的 DLSS、FSR、
桌面应用0.2秒决定用户去留:INP指标如何重构页面交互体验
0.2秒决定用户去留:INP指标如何重构页面交互体验 你是否遇到过这样的情况:点击按钮后页面毫无反应,输入文字时光标卡顿,滑动列表时内容加载迟缓?这些看似微小的
前端可观测性LlamaIndex 集成包 Stale 政策解析:健康分如何决定一个集成包的去留
LlamaIndex 集成包 Stale 政策解析:健康分如何决定一个集成包的去留 LlamaIndex 仓库维护着数百个第三方集成包(向量库、LLM、Embe
人工智能RAG大模型
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考