autocontext上下文门控晋升机制：为什么Agent的自我修改必须经过A/B验证

【免费下载链接】autocontexta recursive self-improving harness designed to help your agents (and future iterations of those agents) succeed on any task项目地址https://gitcode.com/gh_mirrors/aut/autocontext点击查看免费下载autocontext 是一个面向 Agent 递归自我改进的开源框架recursive self-improving harness。它的核心能力之一是用「上下文门控 A/B 验证」来决定 Agent 的自我修改能否真正上线。本文带你快速理解这套机制Agent 改动的 prompt、playbook 为什么不能直接生效以及门控晋升机制如何防止看似有效、实际有害的修改。为什么 Agent 的自我修改不能直接生效一个正在自我改进的 Agent 会不断产出新的想法改一段 prompt、加一条 hint、更新 playbook。听起来很美好但直接放行会带来两个经典问题过拟合假象新改法恰好在这一次任务里碰巧有效换个任务就翻车回归风险改 A 提示词的同时悄悄破坏了 B 能力单次观察根本发现不了autocontext 的答案是把完整的 prompt 与 harness 状态打包成不可变的ContextBundle任何修改都只是一个候选者candidate必须通过 A/B 对照试验才能晋升为现任incumbent。这套机制的完整设计见 docs/context-bundles.md。1门控晋升的生命周期5 个状态一目了然autocontext 给每个 ContextBundle 定义了清晰的升级路径proposed - screened - confirmed - active - superseded | | ----------- rejected状态含义proposedArchitect/Coach 产出的新候选仅存放在candidates/digest/下screened通过廉价初筛confirmed通过自适应匹配确认置信区间越过最小效应阈值active原子替换active.json正式进入线上 promptrejected/superseded被否决 / 被更新版本取代关键点候选者只是被写入并不会因为当前策略表现好就自动进入下一次 prompt。晋升协调器ContextBundlePromotionCoordinator是整个评估边界的实现位于 autocontext/src/autocontext/context_bundles/promotion.py核心入口是evaluate_candidate()。2三级 A/B 验证流水线是怎么跑的autocontext 的 A/B 验证不是跑一次看看分数而是一条三阶段流水线全部使用匹配配对matched pairs候选与现任在完全相同的 fixture、seed、cohort 和评估器 epoch 上成对对比。阶段一低成本初筛Screen用最便宜的匹配配对快速淘汰明显不行的候选。如果候选在这里就输了整个流程直接终止省下大量评估成本。阶段二自适应确认Confirmation只有初筛过关的候选才进入确认阶段。系统持续采样配对直到置信区间明确越过最小效应阈值——要么提前确认要么提前否决。这套统计逻辑的核心实现是 autocontext/src/autocontext/context_bundles/comparison.py 中的evaluate_matched_trials()。阶段三留出集回归检查Held-out最后候选必须在从未见过的留出配对上不出现回归。三组试验块screen / confirmation / held-out严格互斥防止同一个样本既用于证明有效又用于证明无害。通过后晋升提交只是对active.json的一次原子替换读取方要么看到完整的现任版本要么看到完整的候选版本绝不会出现半新半旧的状态。每次晋升都会把确切的候选、现任、评估器 epoch、策略与回滚目标记录到context_bundles/promotions/下。3防止幸运晋升虚假晋升预算A/B 试验还有一个隐蔽陷阱如果一次 campaign 里连续挑战多个候选总会有一次是运气好通过了统计检验。autocontext 用持久化 alpha 预算解决这个问题每个候选按familywise_alpha × 分配衰减预分错误概率且在评估开始前就持久化——重启或换生成器都无法重置预算被否决的候选不退还未使用的 alpha校准数据1000 个模拟 campaign显示空假设下的实际晋升率约 0.012而效应 0.40 的明显赢家晋升率为 1.000完整的统计设定与实测数据见 docs/false-promotion-calibration.md实现位于 autocontext/src/autocontext/context_bundles/false_promotion.py。更有意思的是失败也有账本被否决或证据不足的候选会写一份不可变的negative_result.json台账绑定确切的 bundle、epoch、种子与证据摘要避免同一个坏想法换个名字再来挑战。台账实现见 autocontext/src/autocontext/analytics/negative_result_ledger.py。4Playbook 人工审批门最后一道保险除了自动门控autocontext 还提供可选的人工拦截门开启require_playbook_approval后curator 批准的 playbook 不会直接写入而是落成playbook.pending.md。此时read_playbook仍返回上一版已批准的 playbook——被搁置的学习无法在批准前进入任何 prompt。POST /api/knowledge/{scenario}/playbook/approve晋升为正式 playbookPOST /api/knowledge/{scenario}/playbook/reject清空待定内容不动已批准版本详见 docs/playbook-approval-gate.md。5如何上手体验开启门控晋升只需一个环境变量AUTOCONTEXT_CONTEXT_BUNDLE_PROMOTION_ENABLEDtrueCLI、server、MCP 等入口的GenerationRunner会自动构造协调器用 Python API 直接评估候选coordinator.evaluate_candidate(support, candidate_digest)完整示例见 docs/context-bundles.md 的 Python API 一节想理解哪些改动可以归因为因果效应而非仅相关读 docs/context-attribution.md小结autocontext 的上下文门控晋升机制回答了一个朴素却关键的问题Agent 的自我修改凭什么可信答案是——不可变候选 匹配 A/B 配对 三级验证 持久化错误预算 人工审批门。每一步都可回放、可审计、可回滚。这正是递归自我改进从口号走向工程现实的分水岭。赞分享【免费下载链接】autocontexta recursive self-improving harness designed to help your agents (and future iterations of those agents) succeed on any task项目地址https://gitcode.com/gh_mirrors/aut/autocontext点击查看免费下载相关推荐为什么我们必须重新思考自动化脚本的伦理边界为什么我们必须重新思考自动化脚本的伦理边界 在GitHub_Trending/ha/hacker scripts项目中我们看到了一个热爱自动化的工程师留下的示例工程Nomad 与 CGO为什么 Linux 上的 Nomad 二进制必须启用 CGONomad 与 CGO为什么 Linux 上的 Nomad 二进制必须启用 CGO 本文基于仓库内 contributing/cgo.md https://l任务调度云原生运维后端EarlGrey 测试工程改造原理为什么必须修改 Scheme 并添加 Copy Files Build PhaseEarlGrey 测试工程改造原理为什么必须修改 Scheme 并添加 Copy Files Build Phase EarlGrey 是运行在 iOS 应用测试创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考