ai-memory 自动改进评估门Auto-Improve Eval Gates为高风险 Wiki 提案接入可执行评分器【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory导读本文聚焦 ai-memory 的[auto_improve.eval]可执行评估门机制。该机制允许运维人员在高影响的自动改进提案如_rules/规则页与procedures/流程页的创建或更新进入暂存staging与自动批准auto-approval之前先交给一个轻量、确定性的可执行评分器scorer把关。读完本文你将掌握评估门的配置方法、stdin/stdout 请求与响应契约、默认失败闭合fail-closed语义以及如何基于仓库自带的两个零依赖评分器模板写出符合项目特定约束的评估脚本。[auto_improve.eval]是 docs/auto-improvement-loop.md 所描述的审计优先自学习管线中的一个可选保险丝它运行在 LLM 校验之后、提案暂存或自动批准之前且 hooks 永远不会执行评估命令。下面先从它在线性管线中的位置讲起。一、评估门在自学习管线中的位置在 ai-memory 中后台调度器会周期性审视新完成的会话产生小幅 wiki 编辑提案新的 gotcha、规则提升、对过时概念页的补丁。每条提案都会经过 schema 校验、置信度下限、大小上限与评估门检查然后暂存到_pending/auto-improve/并默认通过正常 wiki 写入路径自动批准。详见 docs/auto-improvement-loop.md。从 crates/ai-memory-consolidate/src/auto_improve.rs 的实现看评估门在提案校验之后被调用apply_eval_gate是入口先检查eval.enabled是否开启随后按targets前缀过滤——只有路径匹配的目标提案才会送评不匹配的提案直接绕过bypass评估门匹配的提案调用run_eval_for_proposal执行外部命令。关键设计约束原文档明确写出源码run_eval_for_proposal亦印证命令按空白拆分后直接执行不经过 shell。需要引号、环境变量设置或多条命令时请自行封装 wrapper 脚本hooks 从不执行评估命令评估门不会增加 hook 延迟默认情况下enabled false即评估门默认关闭只有显式配置才启用。二、配置项详解在服务端配置文件默认模板见 crates/ai-memory-cli/templates/config.default.toml中按如下方式启用[auto_improve.eval] enabled true command python3 docs/examples/auto-improve-eval/score_proposal.py timeout_secs 30 targets [_rules, procedures] min_delta 0.0各字段含义与默认值对照源码AutoImproveEvalConfigcrates/ai-memory-consolidate/src/auto_improve.rs配置项默认值说明enabledfalse是否启用外部评估门关闭时全部提案照常走原流程command可执行命令 空白分隔的参数直接执行而非通过 shell。为空且enabledtrue时目标提案一律以eval_gate_error被拒绝fail-closedtimeout_secs120单条提案评估的超时秒数覆盖命令运行与被阻塞的 stdin 写入targets[_rules, procedures]需要评估的 wiki 路径前缀default_auto_improve_eval_targets()返回的默认值即这两个高危目录min_delta0.0当评分器同时返回score_before与score_after时要求score_after - score_before min_delta否则视为未通过要点enabled与command是成对出现的——启用但没有命令意味着目标提案直接拒绝这是刻意设计的失败闭合语义而不是静默放行。三、请求契约stdin 输入每次评估ai-memory 向评分器进程的 stdin 写入一个 JSON 对象{ path: procedures/release.md, kind: procedure, operation: update, edit_mode: patch, title: Release Procedure, confidence: 0.91, rationale: Capture the repeated release checklist., before_body: # Release Procedure\n\n## Steps\n- Run tests\n, after_body: # Release Procedure\n\n## Steps\n- Run tests\n- Run deploy smoke checks\n, expected_base_body_sha256: ... }字段语义path目标 wiki 页相对路径评分器据此决定检查策略kind提案类型如procedure、gotcha、rule等operationcreate或updateedit_modefull_page或patchtitle、confidence、rationale提案元信息供评分器做上下文判断before_body修改前正文。create 提案新建页面时该字段为空字符串after_body修改后正文expected_base_body_sha256仅当 patch 提案已针对已知基线物化materialized时才存在其余情况为null。仓库示例 docs/examples/auto-improve-eval/sample-proposal.json 展示了一个full_page更新before_body只有## Steps一节after_body补上了## Purpose与更完整的 Steps供你直接喂给评分器做冒烟测试。四、响应契约stdout 输出评分器必须向 stdout 打印一个 JSON 对象{ score_before: 0.72, score_after: 0.76, passed: true }字段规则字段必需性说明passed必需false直接拒绝该目标提案score_before/score_after可选两者同时出现时要求score_after - score_before min_delta否则同样拒绝reason可选一句话解释拒绝原因应简洁任何命令错误、超时、非法 JSON、缺少passed、passed false、分数增量不足都会针对该目标提案失败闭合——但同一轮运行中的其他提案仍可继续推进不会整体中断。若某轮所有提案都被评估门拒绝本轮仍会以零提案 被拒候选的形式暂存让拒绝缓冲区记住这次失败尝试见 docs/auto-improvement-loop.md 关于 rejection buffer 的说明。五、评分器设计规则原文档给出了明确的评分器设计约束仓库示例亦严格遵循确定性、快速、无副作用同一输入必须产出同一输出且只读 stdin 与可安全检查的本地项目文件不调用 LLM、不修改文件、不执行部署、不依赖网络服务返回有界 reasonai-memory 会对捕获的评估证据做上限截断源码read_eval_stdout_capped同样限制 stdout 字节数超限即失败闭合format_eval_failure会对 reason 做截断并标注eval reason truncated优先做匹配目标路径的简单检查procedures 看标题结构_rules查禁用占位符关键文档可用项目专属冒烟断言。六、仓库自带评分器模板本仓库提供两个零依赖模板位于 docs/examples/auto-improve-eval/README 见 docs/examples/auto-improve-eval/README.md。6.1 Python 评分器score_proposal.pydocs/examples/auto-improve-eval/score_proposal.py 是完整实现检查逻辑H1 标题正文含^#\s\S的多行匹配则 0.25否则记missing H1 heading占位符不含todo与tbd则 0.20否则记contains TODO/TBD placeholderprocedures/路径要求含## purpose/## overview0.20与## steps/## checklist0.25_rules/路径要求含always|never|must|do not|prefer等祈使语义0.35且正文不超过 2400 字符0.10其他路径基础分 0.45。评分后passed score_after 0.70 and score_after score_before未通过时拼接 reason 输出。该示例刻意保持简单 确定性正如其 docstring 所言把它们当模板而不是普适的质量门。6.2 Shell wrapperscore_proposal.shdocs/examples/auto-improve-eval/score_proposal.sh 是一个 POSIX shell 入口内嵌一段 Python 评分逻辑。它专为希望command指向单一脚本路径、同时保持 JSON 解析正确的主机设计command配置只需填sh .../score_proposal.sh内部由python3 -c ...完成解析与评分score_after 通过检查数 / 检查总数passed score_after 0.75。6.3 冒烟测试原文档提供了两种可复制的验证命令python3 docs/examples/auto-improve-eval/score_proposal.py \ docs/examples/auto-improve-eval/sample-proposal.json sh docs/examples/auto-improve-eval/score_proposal.sh \ docs/examples/auto-improve-eval/sample-proposal.json两者都会打印适合 ai-memory 评估门消费的紧凑 JSON。你可以改sample-proposal.json中的after_body例如塞进TODO或去掉## Steps来观察passed: false与reason输出从而验证失败闭合行为。七、源码级行为验证失败闭合如何落地crates/ai-memory-consolidate/src/auto_improve.rs 中的测试精确刻画了评估门的边界行为eval_disabled_preserves_current_behaviorenabled false时行为与未配置完全一致passing_eval_allows_proposal_and_records_evidence通过后提案继续并把page auto_improve_eval的证据记录进证据列表failing_eval_filters_and_records_rejectionpassed false时以eval_gate_failed理由拒绝并记录证据eval_error_timeout_and_invalid_json_fail_closed退出码非 0eval_gate_error、输出非法 JSONeval_gate_error、超时eval_gate_timeout三类异常全部失败闭合eval_timeout_covers_blocked_stdin_write连 stdin 写入被阻塞也在超时保护范围内oversized_eval_stdout_fails_closed与oversized_eval_reason_is_capped_before_rejection_evidencestdout 超限失败闭合reason 在进入证据前被截断non_targeted_proposal_bypasses_eval即使命令本身会失败exit 7非目标路径提案也直接绕过评估门。这些测试说明评估门把外部命令不可信当作默认假设——异常永远偏向拒绝而不是放行同时异常只影响目标提案不影响同轮其他提案与整体调度。八、与现有升级契约的衔接评估门默认关闭现有安装不受影响旧配置中的[auto_improve] mode ...已废弃并被忽略可随时删除见 crates/ai-memory-cli/templates/config.default.toml评估门是[auto_improve] require_approval审批策略的补充而非替代先过 LLM 校验 → 再过评估门 → 再按审批策略暂存或自动批准。即使require_approval true评估门依然先行把关减少人工审阅低质量提案的负担若启用评估门但暂不想拦截可把targets置空或暂时enabled false若想对所有高危目标从严把关则同时收紧min_delta与评分器阈值。九、实战建议从仓库模板起步直接复用 score_proposal.py 跑通冒烟测试再按项目实际补充检查例如禁止TODO、校验链接、断言某段固定文案保持评分器无网络、无 LLM、无写盘它运行在提案批准前的关键路径上任何副作用都可能放大为生产事故为评分器设定合理的timeout_secs默认 120 秒偏宽松简单脚本可收紧到 10–30 秒避免异常进程拖住管线先以enabled false 手动喂样本在真实启用前用sample-proposal.json反复调整阈值观察reason输出是否符合预期关注拒绝缓冲区评估门的拒绝会带着eval_gate_failed/eval_gate_timeout/eval_gate_error等理由进入拒绝上下文供后续 reviewer prompt 参考因此保持reason语义明确有助于长期迭代质量。结语[auto_improve.eval]把模型判断与机器可验证的结构约束解耦LLM 负责从会话中提炼值得沉淀的知识外部评分器负责用确定性的、项目特定的规则守住_rules/与procedures/等高影响页面的质量底线。它默认关闭、失败闭合、逐提案隔离不会拖慢 hooks也不会因单一提案异常而中断整轮学习流程——这正符合 ai-memory 自学习循环有界、可观测、可审查的整体设计哲学。【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ai-memory 自动改进评估门（Auto-Improve Eval Gates）：为高风险 Wiki 提案接入可执行评分器
ai-memory 自动改进评估门Auto-Improve Eval Gates为高风险 Wiki 提案接入可执行评分器【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory导读本文聚焦 ai-memory 的[auto_improve.eval]可执行评估门机制。该机制允许运维人员在高影响的自动改进提案如_rules/规则页与procedures/流程页的创建或更新进入暂存staging与自动批准auto-approval之前先交给一个轻量、确定性的可执行评分器scorer把关。读完本文你将掌握评估门的配置方法、stdin/stdout 请求与响应契约、默认失败闭合fail-closed语义以及如何基于仓库自带的两个零依赖评分器模板写出符合项目特定约束的评估脚本。[auto_improve.eval]是 docs/auto-improvement-loop.md 所描述的审计优先自学习管线中的一个可选保险丝它运行在 LLM 校验之后、提案暂存或自动批准之前且 hooks 永远不会执行评估命令。下面先从它在线性管线中的位置讲起。一、评估门在自学习管线中的位置在 ai-memory 中后台调度器会周期性审视新完成的会话产生小幅 wiki 编辑提案新的 gotcha、规则提升、对过时概念页的补丁。每条提案都会经过 schema 校验、置信度下限、大小上限与评估门检查然后暂存到_pending/auto-improve/并默认通过正常 wiki 写入路径自动批准。详见 docs/auto-improvement-loop.md。从 crates/ai-memory-consolidate/src/auto_improve.rs 的实现看评估门在提案校验之后被调用apply_eval_gate是入口先检查eval.enabled是否开启随后按targets前缀过滤——只有路径匹配的目标提案才会送评不匹配的提案直接绕过bypass评估门匹配的提案调用run_eval_for_proposal执行外部命令。关键设计约束原文档明确写出源码run_eval_for_proposal亦印证命令按空白拆分后直接执行不经过 shell。需要引号、环境变量设置或多条命令时请自行封装 wrapper 脚本hooks 从不执行评估命令评估门不会增加 hook 延迟默认情况下enabled false即评估门默认关闭只有显式配置才启用。二、配置项详解在服务端配置文件默认模板见 crates/ai-memory-cli/templates/config.default.toml中按如下方式启用[auto_improve.eval] enabled true command python3 docs/examples/auto-improve-eval/score_proposal.py timeout_secs 30 targets [_rules, procedures] min_delta 0.0各字段含义与默认值对照源码AutoImproveEvalConfigcrates/ai-memory-consolidate/src/auto_improve.rs配置项默认值说明enabledfalse是否启用外部评估门关闭时全部提案照常走原流程command可执行命令 空白分隔的参数直接执行而非通过 shell。为空且enabledtrue时目标提案一律以eval_gate_error被拒绝fail-closedtimeout_secs120单条提案评估的超时秒数覆盖命令运行与被阻塞的 stdin 写入targets[_rules, procedures]需要评估的 wiki 路径前缀default_auto_improve_eval_targets()返回的默认值即这两个高危目录min_delta0.0当评分器同时返回score_before与score_after时要求score_after - score_before min_delta否则视为未通过要点enabled与command是成对出现的——启用但没有命令意味着目标提案直接拒绝这是刻意设计的失败闭合语义而不是静默放行。三、请求契约stdin 输入每次评估ai-memory 向评分器进程的 stdin 写入一个 JSON 对象{ path: procedures/release.md, kind: procedure, operation: update, edit_mode: patch, title: Release Procedure, confidence: 0.91, rationale: Capture the repeated release checklist., before_body: # Release Procedure\n\n## Steps\n- Run tests\n, after_body: # Release Procedure\n\n## Steps\n- Run tests\n- Run deploy smoke checks\n, expected_base_body_sha256: ... }字段语义path目标 wiki 页相对路径评分器据此决定检查策略kind提案类型如procedure、gotcha、rule等operationcreate或updateedit_modefull_page或patchtitle、confidence、rationale提案元信息供评分器做上下文判断before_body修改前正文。create 提案新建页面时该字段为空字符串after_body修改后正文expected_base_body_sha256仅当 patch 提案已针对已知基线物化materialized时才存在其余情况为null。仓库示例 docs/examples/auto-improve-eval/sample-proposal.json 展示了一个full_page更新before_body只有## Steps一节after_body补上了## Purpose与更完整的 Steps供你直接喂给评分器做冒烟测试。四、响应契约stdout 输出评分器必须向 stdout 打印一个 JSON 对象{ score_before: 0.72, score_after: 0.76, passed: true }字段规则字段必需性说明passed必需false直接拒绝该目标提案score_before/score_after可选两者同时出现时要求score_after - score_before min_delta否则同样拒绝reason可选一句话解释拒绝原因应简洁任何命令错误、超时、非法 JSON、缺少passed、passed false、分数增量不足都会针对该目标提案失败闭合——但同一轮运行中的其他提案仍可继续推进不会整体中断。若某轮所有提案都被评估门拒绝本轮仍会以零提案 被拒候选的形式暂存让拒绝缓冲区记住这次失败尝试见 docs/auto-improvement-loop.md 关于 rejection buffer 的说明。五、评分器设计规则原文档给出了明确的评分器设计约束仓库示例亦严格遵循确定性、快速、无副作用同一输入必须产出同一输出且只读 stdin 与可安全检查的本地项目文件不调用 LLM、不修改文件、不执行部署、不依赖网络服务返回有界 reasonai-memory 会对捕获的评估证据做上限截断源码read_eval_stdout_capped同样限制 stdout 字节数超限即失败闭合format_eval_failure会对 reason 做截断并标注eval reason truncated优先做匹配目标路径的简单检查procedures 看标题结构_rules查禁用占位符关键文档可用项目专属冒烟断言。六、仓库自带评分器模板本仓库提供两个零依赖模板位于 docs/examples/auto-improve-eval/README 见 docs/examples/auto-improve-eval/README.md。6.1 Python 评分器score_proposal.pydocs/examples/auto-improve-eval/score_proposal.py 是完整实现检查逻辑H1 标题正文含^#\s\S的多行匹配则 0.25否则记missing H1 heading占位符不含todo与tbd则 0.20否则记contains TODO/TBD placeholderprocedures/路径要求含## purpose/## overview0.20与## steps/## checklist0.25_rules/路径要求含always|never|must|do not|prefer等祈使语义0.35且正文不超过 2400 字符0.10其他路径基础分 0.45。评分后passed score_after 0.70 and score_after score_before未通过时拼接 reason 输出。该示例刻意保持简单 确定性正如其 docstring 所言把它们当模板而不是普适的质量门。6.2 Shell wrapperscore_proposal.shdocs/examples/auto-improve-eval/score_proposal.sh 是一个 POSIX shell 入口内嵌一段 Python 评分逻辑。它专为希望command指向单一脚本路径、同时保持 JSON 解析正确的主机设计command配置只需填sh .../score_proposal.sh内部由python3 -c ...完成解析与评分score_after 通过检查数 / 检查总数passed score_after 0.75。6.3 冒烟测试原文档提供了两种可复制的验证命令python3 docs/examples/auto-improve-eval/score_proposal.py \ docs/examples/auto-improve-eval/sample-proposal.json sh docs/examples/auto-improve-eval/score_proposal.sh \ docs/examples/auto-improve-eval/sample-proposal.json两者都会打印适合 ai-memory 评估门消费的紧凑 JSON。你可以改sample-proposal.json中的after_body例如塞进TODO或去掉## Steps来观察passed: false与reason输出从而验证失败闭合行为。七、源码级行为验证失败闭合如何落地crates/ai-memory-consolidate/src/auto_improve.rs 中的测试精确刻画了评估门的边界行为eval_disabled_preserves_current_behaviorenabled false时行为与未配置完全一致passing_eval_allows_proposal_and_records_evidence通过后提案继续并把page auto_improve_eval的证据记录进证据列表failing_eval_filters_and_records_rejectionpassed false时以eval_gate_failed理由拒绝并记录证据eval_error_timeout_and_invalid_json_fail_closed退出码非 0eval_gate_error、输出非法 JSONeval_gate_error、超时eval_gate_timeout三类异常全部失败闭合eval_timeout_covers_blocked_stdin_write连 stdin 写入被阻塞也在超时保护范围内oversized_eval_stdout_fails_closed与oversized_eval_reason_is_capped_before_rejection_evidencestdout 超限失败闭合reason 在进入证据前被截断non_targeted_proposal_bypasses_eval即使命令本身会失败exit 7非目标路径提案也直接绕过评估门。这些测试说明评估门把外部命令不可信当作默认假设——异常永远偏向拒绝而不是放行同时异常只影响目标提案不影响同轮其他提案与整体调度。八、与现有升级契约的衔接评估门默认关闭现有安装不受影响旧配置中的[auto_improve] mode ...已废弃并被忽略可随时删除见 crates/ai-memory-cli/templates/config.default.toml评估门是[auto_improve] require_approval审批策略的补充而非替代先过 LLM 校验 → 再过评估门 → 再按审批策略暂存或自动批准。即使require_approval true评估门依然先行把关减少人工审阅低质量提案的负担若启用评估门但暂不想拦截可把targets置空或暂时enabled false若想对所有高危目标从严把关则同时收紧min_delta与评分器阈值。九、实战建议从仓库模板起步直接复用 score_proposal.py 跑通冒烟测试再按项目实际补充检查例如禁止TODO、校验链接、断言某段固定文案保持评分器无网络、无 LLM、无写盘它运行在提案批准前的关键路径上任何副作用都可能放大为生产事故为评分器设定合理的timeout_secs默认 120 秒偏宽松简单脚本可收紧到 10–30 秒避免异常进程拖住管线先以enabled false 手动喂样本在真实启用前用sample-proposal.json反复调整阈值观察reason输出是否符合预期关注拒绝缓冲区评估门的拒绝会带着eval_gate_failed/eval_gate_timeout/eval_gate_error等理由进入拒绝上下文供后续 reviewer prompt 参考因此保持reason语义明确有助于长期迭代质量。结语[auto_improve.eval]把模型判断与机器可验证的结构约束解耦LLM 负责从会话中提炼值得沉淀的知识外部评分器负责用确定性的、项目特定的规则守住_rules/与procedures/等高影响页面的质量底线。它默认关闭、失败闭合、逐提案隔离不会拖慢 hooks也不会因单一提案异常而中断整轮学习流程——这正符合 ai-memory 自学习循环有界、可观测、可审查的整体设计哲学。【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考