2026/9/13 15:43:30
FEATURED · 精选文章 
LifeOS Algorithm Optimize 模式全解基于度量与 LLM 评估驱动的迭代优化循环【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS本文档对应的源文档 modes/optimize.md 是 LifeOS Algorithm 体系中Optimize优化模式的完整教义它定义了如何把优化某个目标从一句口头指令转化为一条可量化、可终止、带护栏的自主实验循环。本文以其为骨架结合仓库内 eval-guide.md、parameter-schema.md、target-types.md 与 Optimize 技能 的源码级细节完整呈现两种评估模式、四维参数体系、ISA 配置形态与五步优化循环。读完后你将掌握如何为代码目标与文本目标分别设计优化信号metric_command 与 eval_criteria、如何通过 stepSize / regressionTolerance / earlyStopPatience / maxIterations 四参数控制循环的胆略与耐心、如何编写经得起推敲的二元评估准则以及 ISC 护栏与评估信号在循环中的分工。一、文档定位与沿革一份已退役但完整的模式教义在深入技术细节之前有必要先说明这份文档在仓库中的真实地位避免读者误解当前状态。modes/optimize.md 的 frontmatter 明确标注status: RETIRED 2026-07-11 — historical doctrine. Modes/tiers were abolished with Algorithm v8 and system prompt v3.0.0 (one adaptive format). Kept as record only; nothing routes here.也就是说自 2026-07-11 起Optimize 模式作为模式体系的一部分被正式退役——Algorithm v8 与系统提示词 v3.0.0 采用了单一自适应格式ISA 上不再写入mode:字段参见 archive/modes/README.md 与 v8.20.2.md 的现行教义。Pulse 的六模式 Tab 条也在 2026-07-14 的 agents-dashboard 重构中被移除。但这份文档并非无用之物它作为历史记录被完整保留且其核心思想没有消亡而是被两个仍在运行的实体继承/optimize技能skills/Optimize/SKILL.md版本 1.0.12——一个仍然活跃的自主优化循环技能SKILL.md 中明确写着 mode:is retired — never write it to frontmatter即弃用旧模式字段但保留 metric/eval 双模式与爬山循环。Evals 技能skills/Evals/——eval-guide.md 的 Reconcile 说明指出本文档中的二元评估准则就是 Evals 框架中的llm-assert断言3-Question Test 与变异分类法仍指导着断言编写。因此下文将以理解这套优化循环的完整设计为主线同时如实标注哪些部分是历史形态、哪些被现代实现继承。二、触发机制OBSERVE 阶段的短语检测Optimize 模式由 Algorithm 的OBSERVE 阶段通过确定性触发检测启动。触发短语是optimize [target]其中 target 可以是一个代码文件code file一个提示词prompt一个技能skill一个 Agentagent任何具有可定义成功度量的文本制品text artifact从触发机制可以提炼出 Optimize 模式的第一条原则优化必须先有可定义的成功度量——没有度量就没有优化可言只有漫无目的的修改。这也是它与 Iterate 模式标准 7 阶段当前状态 → 理想状态的本质区别Iterate 爬的是目标之山Optimize 爬的是分数之山。与触发相关的另一个维度是语气关键词在归档的 archive/modes/README.md 触发表中optimize模式的参数会从cautious/aggressive等关键词自动解析——用户说careful、safe、production会倾向cautious预设说bold、aggressive、fast会倾向aggressive预设。三、两种评估模式Metric Mode 与 Eval ModeOptimize 的全部行为建立在一个核心分叉上目标能否产生一个数字。文档用一张对比表完整定义了两种模式维度Metric Mode度量模式Eval Mode评估模式目标代码文件提示词、技能、Agent、任意文本测量方式运行 shell 命令提取数值目标运行 N 次评判输出计算通过率评分单一数值越高/越低越好passes / (eval_criteria × runs)的百分比ISC 角色护栏不变量断言护栏相同评估准则不适用——metric_command即信号3–6 个由 LLM 评判的二元 yes/no 问题沙箱Git 分支optimize/{metric_name}MEMORY/WORK/{slug}/sandbox/中的目录副本3.1 模式判定逻辑文档给出了确定的判定顺序不存在模糊地带提供了metric_command→metric mode设置了eval_mode: eval→eval mode两者都没有 → 按目标类型推断代码/函数 → metric mode其余 → eval mode。归档的 target-types.md 还补充了一条更细的歧义消解规则只要提供了metric_command无论文件类型一律走 metric mode反过来即使目标是代码文件显式设置eval_mode: eval也会走 eval mode——显式声明永远压过类型推断。3.2 该用哪种模式选择指南eval-guide.md 在LifeOS-Specific Guidance一节给出了工程化的选择标准有一个能输出数字的metric_command构建时间、测试分数、文件大小、延迟→metric mode想提升文本输出的质量提示词、技能行为→eval mode想减少构建时间 →metric mode速度与质量两者都重要 → 先跑 metric mode 优化速度再跑 eval mode 优化质量。这一节与 SKILL.md 中的经验法则完全一致Use metric mode for quantifiable targets (latency, size). Use eval mode for qualitative targets (skill quality, prompt effectiveness).四、参数体系胆略、回归容忍与耐心Optimize 接受四个可调参数控制变异大胆程度、回归容忍度与耐心。参数在 OBSERVE 阶段从预设或单个覆盖值解析而来。参数取值范围默认值作用stepSize0.0–1.00.3每次实验的变更幅度。低值 微小调整高值 结构性变更。regressionTolerance0.0–1.00.1对暂时性分数回退的容忍度。0 绝不接受1 自由探索。earlyStopPatience1–203连续多少次无改进的实验后终止。maxIterations1–10010实验总次数上限。4.1 四个参数如何驱动循环行为文档明确给出了参数 → 循环各阶段的映射这是理解整套机制的关键stepSize→ HYPOTHESIZE假设控制变异分类法的权重。低值偏向elimination消除/simplify简化/parameter_tune参数微调高值偏向algorithmic算法级/restructure重构/rewrite重写。regressionTolerance→ DECIDE决策0.0任何回退都触发 revert0.1–0.3若有结构性理由接受轻微回退5%0.4进入模拟退火语义——接受回退以逃离局部最优。earlyStopPatience→ 终止与平台协议Plateau Protocol平台 Level 1 出现在连续earlyStopPatience次实验时Level 2 在 2 倍时Level 3 在 3 倍时。maxIterations→ 硬性终止实验计数达到该值循环立即退出。parameter-schema.md 为 stepSize 与 regressionTolerance 补充了 LLM 可理解的行为层级因为LLMs respond to qualitative bands, not continuous floats——大语言模型对定性区间比对连续浮点数响应更好stepSize 行为层级0.0–0.3只提出小而安全的变更一次只调一个变量最小化爆炸半径0.4–0.6中等变更可触及 2–3 个相关变量0.7–1.0结构性变更重新思考整个子系统。regressionTolerance 行为层级0.0只有 MEASURE 显示改进才接受任何回退都回滚0.1–0.3若假设针对的是结构性局限接受 5% 的轻微回退0.4–0.7接受中等回退给新方法 2–3 次迭代证明自己0.8–1.0自由探索回退被接受以逃离局部最优。4.2 命名预设cautious / standard-optimize / aggressive预设stepSizeregressionToleranceearlyStopPatiencemaxIterations适用场景cautious0.150.0520生产系统稳定性至上standard-optimize0.30.1310默认——中等路线aggressive0.70.5215原型、实验、逃离局部最优注意三个预设的内在设计逻辑cautious牺牲迭代次数换取零回退与多轮耐心20 次上限aggressive用更大的步长与 0.5 的回退容忍度换取更快的探索但只给 2 次耐心就终止——因为大幅变异要么立刻见效要么说明方向错了。预设可以被单个参数覆盖例如cautious基础上把maxIterations提到 30。4.3 参数解析顺序与 CLI 覆盖历史形态归档的 parameter-schema.md 记录了这套参数系统的三层架构与解析顺序Layer 1: Preset (optional) → 命名配置解析为 Layer 23 的值 Layer 2: Focus (optional) → 单个 0.0-1.0 复合值映射到 Layer 3 Layer 3: Individual parameters → 实际行为控制项解析顺序Preset → Focus → Individual overrides → Meta-Learner adjustments每一层覆盖上一层最终解析值写入 ISA 的algorithm_config.params。Meta-Learner 在调整时受安全护栏约束每周期最大调整不超过参数范围的 15%累计漂移不超过初始值的 40%每次调整必须记录理由。该文档还记录了当时 CLI 的用法注意algorithmCLI 属于已退役的模式体系仅为历史形态# 预设 algorithm -m optimize -p ISA --preset aggressive # 单个参数覆盖可重复 algorithm -m optimize -p ISA --param stepSize0.8 --param regressionTolerance0.3标志优先级--param--preset覆盖 --focus映射 模式默认值。五、ISA 形态把优化意图写进 frontmatterOptimize 模式的运行时配置全部沉淀在 ISA 的 frontmatter 中。文档给出的完整形态如下原样继承mode: optimize algorithm_config: preset: cautious # OR standard-optimize | aggressive eval_mode: metric # OR eval metric_command: bun test --reporter json # metric mode only eval_criteria: # eval mode only - Output is under 200 tokens - Output uses {{PRINCIPAL_NAME}}s voice (per WRITINGSTYLE.md) - Output contains zero AI-isms (per AIWritingPatterns.md) params: stepSize: 0.15 regressionTolerance: 0.0 earlyStopPatience: 5 maxIterations: 20 principal_stated_goal: verbatim if user stated one这份配置值得逐字段解读preset是参数层的快捷入口只写预设名即可获得整组参数eval_mode二选一决定走 metric 还是 eval 路径metric_command与eval_criteria互斥出现分别对应两种模式params存放解析后的最终参数值无论来自预设还是覆盖principal_stated_goal保留用户原话——这一点与现代 Algorithm v8 教义一脉相承v8.20.2 的完成条件第 1 条即要求主述目标原样保留在 ISA 中参见 v8.20.2.md。归档的 parameter-schema.md 还展示了序列化形态的扩展字段locked_paramsMeta-Learner 不得调整的参数、user_overrides用户显式设置的参数、meta_learner_adjustments调整历史每条含 cycle、parameter、from、to、rationale。六、优化循环HYPOTHESIZE → MUTATE → MEASURE → DECIDE → COMMIT-OR-REVERTOptimize 在 Algorithm 各阶段内部运行一条内层实验循环这是整份文档的心脏HYPOTHESIZE → MUTATE → MEASURE → DECIDE → COMMIT-OR-REVERT ↑ ↓ └──────────── continue until termination ──────┘各环节的职责按文档原义HYPOTHESIZE假设从变异分类法中提出一种变异类型权重由stepSize决定。MUTATE变异在沙箱中应用变更——metric mode 用 git 分支eval mode 用目录副本。MEASURE测量metric mode 运行metric_commandeval mode 运行 N 次评估。DECIDE决策新分数与基线对比 → 保留改进或回退在regressionTolerance内或回滚。COMMIT-OR-REVERT提交或回滚应用或回滚保留则更新基线。6.1 终止条件循环在以下任一条件下退出maxIterations达到earlyStopPatience次连续无改进ISC 护栏违反见下节用户手动终止。注意第 3 条的特殊性护栏违反是独立于分数之外的终止/回滚触发——哪怕分数提升了护栏破了也要回滚。这让优化与不破坏系统两个目标被显式分离。6.2 变异分类法eval 模式eval-guide.md 提供了假设阶段的分类法区分高信噪比与低信噪比的变异类型好变异高信噪比类型说明示例add_instruction添加一条具体、有针对性的指令增加每个原则都要包含一个具体示例reword_ambiguity澄清模糊措辞be thorough → 至少覆盖 3 个不同方面add_anti_pattern显式禁止观察到的失败增加绝不以In this response I will...开头reorder_priority把重要指令前移把输出格式说明从底部移到顶部add_example加入期望输出的具体示例加一个 3 行的理想结构示例remove_over_optimization删除导致僵化的指令删除始终恰好用 5 个要点simplify减少指令数量合并冗余规则把 3 条相似的格式规则合并为 1 条constrain_scope收窄目标焦点只聚焦前 3 项发现而非全部坏变异应当避免类型为什么不好rewrite_from_scratch丢失全部累积改进重置为随机状态add_10_plus_rules令目标不堪重负——导致指令遵循能力退化vague_instructionsbe better 不携带任何信号copy_from_unrelated跨领域搬运模式很少能迁移成功meta_instructions关于如何思考一步步思考——收益递减这套分类法直指一个深刻问题优化循环的质量上限由变异假设的质量决定。这也是为什么stepSize低时偏向保守变异、高时偏向结构性变异——它实际上是在调节假设的激进程度。七、ISC 在 Optimize 中的角色护栏而非目标Optimize 模式中 ISCInvariant Success Criteria不变量成功准则承担明确且严格受限的角色ISCs areguard rails— invariant assertions that must hold regardless of score.ISC 是护栏无论分数如何都必须成立的不变量断言例ISC-1: 所有现有测试仍然通过、ISC-2: 输出绝不包含禁用词汇任一 ISC 失败变异即使提升了分数也必须回滚ISC 不是优化目标——度量/评估才是。eval-guide.md 进一步区分了两者的分工评估准则 收敛信号convergence signal分数驱动优化准则可以被轮换、收紧、逐步升级ISC 护栏 不变量断言invariant assertions在所有实验中都必须为真违反即自动回滚无论通过率是否提升。护栏的典型内容与模式无关无崩溃、输出非空、输出无 PII。一句话总结评估准则回答好不好ISC 回答坏没坏——前者决定取舍后者决定生死。八、Eval 模式深度如何编写经得起推敲的二元准则Eval 模式的全部信号来自 3–6 条二元评估准则。准则写得差整个循环就会向着错误方向优化所以 eval-guide.md 花了大篇幅规范准则编写。8.1 三条必过测试The 3-Question Test每条准则在投入使用前必须通过三个问题任一不过即产生误导性优化信号问题一两个独立评判者会达成一致吗准则必须足够具体使两个不同 LLM 实例或两个人在 85% 的情况下给出相同的 yes/no 答案。PASS输出是否包含至少 3 个带引用来源的具体事实FAIL输出是否高质量太模糊评判者会分歧FAIL写作风格好吗主观无锚点问题二目标能否不作真正改进就刷过此准则如果某个退化的变异能通过准则而实际上没有变好说明准则可被钻空子gameable会把优化引向垃圾。PASS输出是否针对用户的具体问题而非泛泛话题FAIL输出是否超过 500 词用填充内容即可刷过FAIL输出是否提到所有输入关键词关键词堆砌即可刷过问题三用户真的在乎这个吗准则必须度量终端用户能注意到并重视的东西。PASS输出是否提供可执行的下一步而非只有分析FAIL输出是否恰好用 3 个要点武断的格式规则FAIL输出是否提到系统提示词的指令元层面无用8.2 编写准则的结构要求结构每条准则都是关于输出的二元 yes/no 问题必须仅凭输出文本可选地加上输入就能回答数量每个目标 3–6 条。少于 3 条信号不足多于 6 条制造噪音并拖慢循环模板Does the output [observable behavior] [specific threshold/condition]?按领域示例提示词优化- Does the output directly address the users question in the first paragraph? - Does the output contain specific examples, not just abstract principles? - Does the output avoid repeating the same point in different words? - Is the output structured with clear sections or logical flow?技能优化- Does the skill route to the correct workflow for the given input? - Does the output contain actionable content, not just meta-commentary? - Does the output follow the specified format constraints? - Does the skill handle edge-case inputs without crashing or producing empty output?Agent 优化- Does the agent complete the assigned task without human intervention? - Does the agent use appropriate tools for each step? - Does the agents final output match the requested format? - Does the agent avoid unnecessary tool calls or redundant work?代码非数值质量优化- Does the function handle all documented edge cases? - Does the output match the expected schema? - Does the function complete without throwing unhandled exceptions?8.3 反准则Anti-Criteria反准则定义输出不得做什么防止优化器漂向退化方案。模板为The output must NOT [undesirable behavior].- The output must NOT contain placeholder text or TODO markers. - The output must NOT repeat the input prompt verbatim. - The output must NOT exceed 2000 words for a summary task. - The output must NOT hallucinate citations or make up sources.反准则与普通准则用相同机制检查但逻辑反转回答是意味着失败。8.4 常见错误清单准则过多6制造噪音稀释有意义信号的权重优化器把周期花在满足低价值检查上过于狭窄/僵硬过度具体的准则约束优化器找到创造性改进的空间——输出是否以Here is开头太僵硬输出是否以清晰的主题句开头更好准则重叠总是同时通过或同时失败的两条准则不提供额外信号只保留更精确的那条无法仅从输出判定需要外部上下文数据库查询、实时数据的准则无法从输出评判准则冲突要简洁 要详尽会引发振荡应在循环开始前用阈值化解500 词以内 至少覆盖 3 个关键方面。8.5 停滞恢复Stall Recovery当通过率进入平台期按顺序尝试检查天花板——通过率 95% 说明当前准则已饱和收紧准则或加入更难的标准分析失败模式——哪些准则在失败把变异集中到这些特定区域尝试减法变异——删除可能造成干扰的指令替换一条准则——把区分度最低的准则换成更难的一条更换测试输入——当前输入可能没有施压到正确的行为上。8.6 评分公式每次实验的分数passes / (criteria_count × runs_per_experiment)其中passes 所有准则与所有运行中二元yes判定的总数criteria_count 评估准则数量3–6runs_per_experiment 每次实验目标运行的次数默认 3。示例5 条准则、3 次运行、15 个可能判定中通过 12 个 80% 通过率。分数与当前最佳值比较决定保留或回滚与 metric mode 同构。九、目标类型与沙箱策略target-types.md 定义了 Optimize 的五个目标类型及其检测规则类型检测规则skill目录含SKILL.md或路径指向~/.claude/skills/下的技能目录prompt独立的.md或.txt提示词文件父目录无 SKILL.mdagent含 Agent frontmattername、description、tools/capabilities 字段的.md文件code提供metric_command的源文件.ts、.js、.py、.go等function源文件 特定函数名——code 的子集限定在单一函数沙箱策略与评估模式强绑定code / functionmetric modegit 分支optimize/{metric_name}无需沙箱目录metric_command即测试skill / prompt / agenteval mode复制到MEMORY/WORK/{slug}/sandbox/变异只改沙箱副本永不触碰原件。9.1 自动 ISC 生成流程进入目标分析阶段时系统按 8 步自动生成评估准则全面读取目标按各类型的What to read清单提取目的——目标应当做什么提取约束——存在哪些规则或格式要求提取边界情况——应处理哪些异常输入或状态以各类型的 ISC 生成模板为起点起草 3–6 条定制化二元准则基于该目标类型的常见失败模式起草 1–2 条反准则对每条准则应用 3-Question Test删掉不过的提交用户审批——循环开始前展示生成的准则允许修改。9.2 测试输入生成读取目标以理解预期输入格式与领域生成 3–5 个覆盖目标能力的多样化输入保证多样性至少一个简单/直接输入、一个复杂/多面输入、一个边界/临界输入与评估准则一同提交用户审批。五种类型共享同一套 8 步循环结构、护栏语义、结果日志results.tsv ISA experiments 表、平台协议与会话恢复能力核心差异只在于git 分支 vs 沙箱目录和metric_command vs LLM 评判。十、与 Algorithm 各阶段的集成Optimize 不是悬空的独立循环而是嵌入 Algorithm 标准阶段中的一条内层循环Algorithm 阶段Optimize 的职责OBSERVE触发检测、参数解析、eval-mode 判定、以 metric_command 或 eval_criteria 搭建 ISA 骨架THINK识别护栏 ISC为优化循环做预检模式坍塌、钻空子度量、局部最优PLAN通常为single | combined (inseparable)——优化是单条紧耦合循环BUILD建立沙箱git 分支或目录副本EXECUTE运行优化循环记录每个实验的假设 分数 决策VERIFY确认 ISC 护栏全程成立最终分数对比基线检查 Meta-Learner 调整LEARN把胜出变异路由到 KNOWLEDGE记录 Meta-Learner 调整埋葬失败的变异分类法注意 THINK 阶段的预检特别点出了优化循环的三个经典失败模式这在现代机器学习实践中同样成立模式坍塌mode collapse——变异收敛到单一重复套路钻空子度量gaming the metric——分数上升但真实质量未变这正是 3-Question Test 问题二要防的局部最优local optima——爬山算法在局部极值停滞这正是regressionTolerance0.4 模拟退火语义要解的。LEARN 阶段的埋葬失败的变异分类法tombstone failed mutation taxonomies也很关键它让系统不仅记录成功还记录哪些变异类型被证明无效避免未来重复试错。十一、实战示例文档给出了三个触发示例覆盖三种典型配置optimize this prompt for higher engagement优化这个提示词以提高参与度→mode: optimize、eval mode、E3optimize the bundle size of /dashboard优化 /dashboard 的打包体积→mode: optimize、metric modebun run build、preset: cautious、E3aggressive optimize: cut the API latency in half激进优化把 API 延迟减半→mode: optimize、metric mode、preset: aggressive、E4。示例中的 E3/E4 属于已退役的 E1–E5 努力等级体系在 Algorithm v8 中已被由工作本身发现的动态范围取代参见 v8.20.2.md 的 Spend 一节。11.1 现代形态/optimize技能的实际调用虽然mode:字段已退役但同一个爬山循环以/optimize技能的形式保持活跃skills/Optimize/SKILL.md。其调用方式是判定eval_mode的现行标准提供--measure→eval_mode: metricgit 分支沙箱提供--target→eval_mode: eval目录沙箱。Metric Mode 参数参数必填默认值说明--metric NAME是人类可读的度量名--measure COMMAND是产生度量的 shell 命令--files GLOB是允许 Agent 修改的文件逗号分隔--higher-is-better(默认)度量值越高越好--lower-is-better度量值越低越好--extract COMMANDstdout 最后一个数字从输出提取度量值--budget SECONDS300每次实验的时间预算--target VALUE无度量达到该值时停止--max-experiments N无N 次实验后停止--locked GLOB无Agent 不得修改的文件--constraints TEXT无附加规则如测试必须通过Eval Mode 参数参数必填默认值说明--target PATH是技能目录、提示词文件或 Agent 定义路径--max-experiments N无N 次实验后停止--runs N3每次实验运行次数越多越可靠、越慢--criteria Q1 Q2自动生成覆盖自动生成的评估准则--inputs I1 I2自动生成覆盖自动生成的测试输入--budget SECONDS300每次实验的时间预算共享参数--resume恢复之前的优化运行、--status显示上次/当前运行的结果摘要。完整调用示例来自 SKILL.md# Metric优化页面加载性能 /optimize --metric lighthouse_perf --higher-is-better \ --measure npx lighthouse http://localhost:3000 --outputjson --output-pathlh.json \ --extract jq .categories.performance.score * 100 lh.json \ --files src/**/*.tsx,src/**/*.css \ --target 95 --budget 120 # Metric优化打包体积 /optimize --metric bundle_bytes --lower-is-better \ --measure bun run build 21 du -sb dist/ | cut -f1 \ --files src/**/*.ts \ --constraints all tests must pass # Eval优化某个技能 /optimize --target ~/.claude/skills/ExtractWisdom --max-experiments 15 # Eval自定义准则与输入 /optimize --target ~/.claude/skills/Research/Workflows/QuickResearch.md \ --criteria Does the output contain specific facts with sources? \ Is the output structured with clear sections? \ Does the output avoid generic filler? \ --inputs research quantum computing breakthroughs 2025 \ quick research on supply chain security技能文档还给出了一条重要的经验性注释metric mode 每小时约 12 次实验5 分钟预算下eval mode 每小时约 6–8 次多轮评判更慢——这量化了两种模式的速度差异也为设置maxIterations提供了现实依据。11.2 已知陷阱GotchasSKILL.md 明确警告爬山会困在局部最优分数进入平台期时考虑以不同初始条件重置eval 与 metric 的选择可量化目标延迟、体积用 metric定性目标技能质量、提示词有效性用 eval回退容忍度防止灾难性变更不要设成 0——如果主度量显著提升次要度量的轻微回退是可接受的。十二、Pulse 表面优化过程的观测入口Optimize 模式曾是 Pulse 观察层的一等公民归档文档记录的形态TabOptimizeDashboardOptimizeDashboard原路径LIFEOS/PULSE/Observability/src/components/activity/OptimizeDashboard.tsx过滤algorithmStates.filter(s s.mode optimize)需要如实说明该OptimizeDashboard.tsx组件已在 2026-07-14 的 agents-dashboard 重构中被删除——archive/modes/README.md 明确记载the agents page now renders Work Activity tabs with lifecycle derived from run data, and no longer references this directory。当前仓库components/activity/下实际存在的是 WorkBoard.tsx、ClimbChart.tsx 等新一代组件。归档的模式元数据目录 DOCUMENTATION/Pulse/PulseMetadata.md 记录了 optimize 模式曾填充的 ISA frontmatter 字段作为历史参考algorithm_mode: optimize、algorithm_config.preset必填、algorithm_config.params必填、eval_modemetric/eval必填、iteration按实验计数、density_scoreE3、interview_invokedE3。这套模式元数据随运行数据派生的思路在现代实现中以 ascent.ts 的deriveAscent()统一派生表的形式延续下来参见 v8.20.2.md 的 Telemetry 一节。十三、历史地位与现代遗产理解 Optimize 模式最好的方式是同时看到它的过去与现在。它曾经是模式体系的一员。在 2026-05-13 的模式重组中Optimize 教义从 optimize-loop.md现为指向本文件的 redirect 指针迁入modes/目录与 iterate、ideate、loop、native 并列构成 Algorithm 的六模式体系详见 archive/modes/README.md。它随模式体系一起退役。2026-07-11Algorithm v8 以one adaptive format取代了模式/层级体系v8.1.0 的 changelog 记录了主理人当时的原话the desired statement of what I want should be in the Algorithm; its the outcome that I want, not how to get there期望的声明应该在 Algorithm 里我要的是结果不是达成路径。所有模式文件被移入archive/仅作为记录保留见 changelog.md。但它的思想没有死。三个遗产清晰可辨爬山循环/optimize技能持续运行同一条 HYPOTHESIZE → MUTATE → MEASURE → DECIDE → COMMIT-OR-REVERT 循环只是不再需要mode: optimize字段二元评估准则eval-guide.md 的 3-Question Test 与变异分类法直接指导着现行 Evals 技能中llm-assert断言的编写断言即自然语言检查由评判者打 TRUE/FALSE并共享同一套评判纪律先推理后打分、使用独立的评判模型、Unknown 计为 missISC 护栏语义护栏必须全程成立、违规即回滚、护栏不是优化目标这一原则与 Algorithm v8 完成条件中每条 claim 必须携带可证伪它的探针的验证教义一脉相承v8.20.2.md 第 8 条Should work is forbidden。对今天的使用者而言这份文档最大的价值在于它把如何系统化地优化一个制品拆解成了一套可复用的工程方法——定义度量、控制变异胆略、容忍回退、设护栏、写防钻空子的准则、在平台期知道该做什么。无论模式字段是否存在这套方法都成立。交叉引用索引模式总览历史archive/modes/README.md参数 schema历史archive/parameter-schema.mdEval 模式指南eval-guide.md](LifeOS/install/LIFEOS/ALGORITHM/eval-guide.md)目标类型历史archive/target-types.mdOptimize 技能现行、活跃skills/Optimize/SKILL.md当前 Algorithm 教义v8.20.2.md版本锚点见 LATESTAlgorithm 变更史changelog.md模式元数据目录DOCUMENTATION/Pulse/PulseMetadata.md【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LifeOS Algorithm Optimize 模式全解：基于度量与 LLM 评估驱动的迭代优化循环
LifeOS Algorithm Optimize 模式全解基于度量与 LLM 评估驱动的迭代优化循环【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS本文档对应的源文档 modes/optimize.md 是 LifeOS Algorithm 体系中Optimize优化模式的完整教义它定义了如何把优化某个目标从一句口头指令转化为一条可量化、可终止、带护栏的自主实验循环。本文以其为骨架结合仓库内 eval-guide.md、parameter-schema.md、target-types.md 与 Optimize 技能 的源码级细节完整呈现两种评估模式、四维参数体系、ISA 配置形态与五步优化循环。读完后你将掌握如何为代码目标与文本目标分别设计优化信号metric_command 与 eval_criteria、如何通过 stepSize / regressionTolerance / earlyStopPatience / maxIterations 四参数控制循环的胆略与耐心、如何编写经得起推敲的二元评估准则以及 ISC 护栏与评估信号在循环中的分工。一、文档定位与沿革一份已退役但完整的模式教义在深入技术细节之前有必要先说明这份文档在仓库中的真实地位避免读者误解当前状态。modes/optimize.md 的 frontmatter 明确标注status: RETIRED 2026-07-11 — historical doctrine. Modes/tiers were abolished with Algorithm v8 and system prompt v3.0.0 (one adaptive format). Kept as record only; nothing routes here.也就是说自 2026-07-11 起Optimize 模式作为模式体系的一部分被正式退役——Algorithm v8 与系统提示词 v3.0.0 采用了单一自适应格式ISA 上不再写入mode:字段参见 archive/modes/README.md 与 v8.20.2.md 的现行教义。Pulse 的六模式 Tab 条也在 2026-07-14 的 agents-dashboard 重构中被移除。但这份文档并非无用之物它作为历史记录被完整保留且其核心思想没有消亡而是被两个仍在运行的实体继承/optimize技能skills/Optimize/SKILL.md版本 1.0.12——一个仍然活跃的自主优化循环技能SKILL.md 中明确写着 mode:is retired — never write it to frontmatter即弃用旧模式字段但保留 metric/eval 双模式与爬山循环。Evals 技能skills/Evals/——eval-guide.md 的 Reconcile 说明指出本文档中的二元评估准则就是 Evals 框架中的llm-assert断言3-Question Test 与变异分类法仍指导着断言编写。因此下文将以理解这套优化循环的完整设计为主线同时如实标注哪些部分是历史形态、哪些被现代实现继承。二、触发机制OBSERVE 阶段的短语检测Optimize 模式由 Algorithm 的OBSERVE 阶段通过确定性触发检测启动。触发短语是optimize [target]其中 target 可以是一个代码文件code file一个提示词prompt一个技能skill一个 Agentagent任何具有可定义成功度量的文本制品text artifact从触发机制可以提炼出 Optimize 模式的第一条原则优化必须先有可定义的成功度量——没有度量就没有优化可言只有漫无目的的修改。这也是它与 Iterate 模式标准 7 阶段当前状态 → 理想状态的本质区别Iterate 爬的是目标之山Optimize 爬的是分数之山。与触发相关的另一个维度是语气关键词在归档的 archive/modes/README.md 触发表中optimize模式的参数会从cautious/aggressive等关键词自动解析——用户说careful、safe、production会倾向cautious预设说bold、aggressive、fast会倾向aggressive预设。三、两种评估模式Metric Mode 与 Eval ModeOptimize 的全部行为建立在一个核心分叉上目标能否产生一个数字。文档用一张对比表完整定义了两种模式维度Metric Mode度量模式Eval Mode评估模式目标代码文件提示词、技能、Agent、任意文本测量方式运行 shell 命令提取数值目标运行 N 次评判输出计算通过率评分单一数值越高/越低越好passes / (eval_criteria × runs)的百分比ISC 角色护栏不变量断言护栏相同评估准则不适用——metric_command即信号3–6 个由 LLM 评判的二元 yes/no 问题沙箱Git 分支optimize/{metric_name}MEMORY/WORK/{slug}/sandbox/中的目录副本3.1 模式判定逻辑文档给出了确定的判定顺序不存在模糊地带提供了metric_command→metric mode设置了eval_mode: eval→eval mode两者都没有 → 按目标类型推断代码/函数 → metric mode其余 → eval mode。归档的 target-types.md 还补充了一条更细的歧义消解规则只要提供了metric_command无论文件类型一律走 metric mode反过来即使目标是代码文件显式设置eval_mode: eval也会走 eval mode——显式声明永远压过类型推断。3.2 该用哪种模式选择指南eval-guide.md 在LifeOS-Specific Guidance一节给出了工程化的选择标准有一个能输出数字的metric_command构建时间、测试分数、文件大小、延迟→metric mode想提升文本输出的质量提示词、技能行为→eval mode想减少构建时间 →metric mode速度与质量两者都重要 → 先跑 metric mode 优化速度再跑 eval mode 优化质量。这一节与 SKILL.md 中的经验法则完全一致Use metric mode for quantifiable targets (latency, size). Use eval mode for qualitative targets (skill quality, prompt effectiveness).四、参数体系胆略、回归容忍与耐心Optimize 接受四个可调参数控制变异大胆程度、回归容忍度与耐心。参数在 OBSERVE 阶段从预设或单个覆盖值解析而来。参数取值范围默认值作用stepSize0.0–1.00.3每次实验的变更幅度。低值 微小调整高值 结构性变更。regressionTolerance0.0–1.00.1对暂时性分数回退的容忍度。0 绝不接受1 自由探索。earlyStopPatience1–203连续多少次无改进的实验后终止。maxIterations1–10010实验总次数上限。4.1 四个参数如何驱动循环行为文档明确给出了参数 → 循环各阶段的映射这是理解整套机制的关键stepSize→ HYPOTHESIZE假设控制变异分类法的权重。低值偏向elimination消除/simplify简化/parameter_tune参数微调高值偏向algorithmic算法级/restructure重构/rewrite重写。regressionTolerance→ DECIDE决策0.0任何回退都触发 revert0.1–0.3若有结构性理由接受轻微回退5%0.4进入模拟退火语义——接受回退以逃离局部最优。earlyStopPatience→ 终止与平台协议Plateau Protocol平台 Level 1 出现在连续earlyStopPatience次实验时Level 2 在 2 倍时Level 3 在 3 倍时。maxIterations→ 硬性终止实验计数达到该值循环立即退出。parameter-schema.md 为 stepSize 与 regressionTolerance 补充了 LLM 可理解的行为层级因为LLMs respond to qualitative bands, not continuous floats——大语言模型对定性区间比对连续浮点数响应更好stepSize 行为层级0.0–0.3只提出小而安全的变更一次只调一个变量最小化爆炸半径0.4–0.6中等变更可触及 2–3 个相关变量0.7–1.0结构性变更重新思考整个子系统。regressionTolerance 行为层级0.0只有 MEASURE 显示改进才接受任何回退都回滚0.1–0.3若假设针对的是结构性局限接受 5% 的轻微回退0.4–0.7接受中等回退给新方法 2–3 次迭代证明自己0.8–1.0自由探索回退被接受以逃离局部最优。4.2 命名预设cautious / standard-optimize / aggressive预设stepSizeregressionToleranceearlyStopPatiencemaxIterations适用场景cautious0.150.0520生产系统稳定性至上standard-optimize0.30.1310默认——中等路线aggressive0.70.5215原型、实验、逃离局部最优注意三个预设的内在设计逻辑cautious牺牲迭代次数换取零回退与多轮耐心20 次上限aggressive用更大的步长与 0.5 的回退容忍度换取更快的探索但只给 2 次耐心就终止——因为大幅变异要么立刻见效要么说明方向错了。预设可以被单个参数覆盖例如cautious基础上把maxIterations提到 30。4.3 参数解析顺序与 CLI 覆盖历史形态归档的 parameter-schema.md 记录了这套参数系统的三层架构与解析顺序Layer 1: Preset (optional) → 命名配置解析为 Layer 23 的值 Layer 2: Focus (optional) → 单个 0.0-1.0 复合值映射到 Layer 3 Layer 3: Individual parameters → 实际行为控制项解析顺序Preset → Focus → Individual overrides → Meta-Learner adjustments每一层覆盖上一层最终解析值写入 ISA 的algorithm_config.params。Meta-Learner 在调整时受安全护栏约束每周期最大调整不超过参数范围的 15%累计漂移不超过初始值的 40%每次调整必须记录理由。该文档还记录了当时 CLI 的用法注意algorithmCLI 属于已退役的模式体系仅为历史形态# 预设 algorithm -m optimize -p ISA --preset aggressive # 单个参数覆盖可重复 algorithm -m optimize -p ISA --param stepSize0.8 --param regressionTolerance0.3标志优先级--param--preset覆盖 --focus映射 模式默认值。五、ISA 形态把优化意图写进 frontmatterOptimize 模式的运行时配置全部沉淀在 ISA 的 frontmatter 中。文档给出的完整形态如下原样继承mode: optimize algorithm_config: preset: cautious # OR standard-optimize | aggressive eval_mode: metric # OR eval metric_command: bun test --reporter json # metric mode only eval_criteria: # eval mode only - Output is under 200 tokens - Output uses {{PRINCIPAL_NAME}}s voice (per WRITINGSTYLE.md) - Output contains zero AI-isms (per AIWritingPatterns.md) params: stepSize: 0.15 regressionTolerance: 0.0 earlyStopPatience: 5 maxIterations: 20 principal_stated_goal: verbatim if user stated one这份配置值得逐字段解读preset是参数层的快捷入口只写预设名即可获得整组参数eval_mode二选一决定走 metric 还是 eval 路径metric_command与eval_criteria互斥出现分别对应两种模式params存放解析后的最终参数值无论来自预设还是覆盖principal_stated_goal保留用户原话——这一点与现代 Algorithm v8 教义一脉相承v8.20.2 的完成条件第 1 条即要求主述目标原样保留在 ISA 中参见 v8.20.2.md。归档的 parameter-schema.md 还展示了序列化形态的扩展字段locked_paramsMeta-Learner 不得调整的参数、user_overrides用户显式设置的参数、meta_learner_adjustments调整历史每条含 cycle、parameter、from、to、rationale。六、优化循环HYPOTHESIZE → MUTATE → MEASURE → DECIDE → COMMIT-OR-REVERTOptimize 在 Algorithm 各阶段内部运行一条内层实验循环这是整份文档的心脏HYPOTHESIZE → MUTATE → MEASURE → DECIDE → COMMIT-OR-REVERT ↑ ↓ └──────────── continue until termination ──────┘各环节的职责按文档原义HYPOTHESIZE假设从变异分类法中提出一种变异类型权重由stepSize决定。MUTATE变异在沙箱中应用变更——metric mode 用 git 分支eval mode 用目录副本。MEASURE测量metric mode 运行metric_commandeval mode 运行 N 次评估。DECIDE决策新分数与基线对比 → 保留改进或回退在regressionTolerance内或回滚。COMMIT-OR-REVERT提交或回滚应用或回滚保留则更新基线。6.1 终止条件循环在以下任一条件下退出maxIterations达到earlyStopPatience次连续无改进ISC 护栏违反见下节用户手动终止。注意第 3 条的特殊性护栏违反是独立于分数之外的终止/回滚触发——哪怕分数提升了护栏破了也要回滚。这让优化与不破坏系统两个目标被显式分离。6.2 变异分类法eval 模式eval-guide.md 提供了假设阶段的分类法区分高信噪比与低信噪比的变异类型好变异高信噪比类型说明示例add_instruction添加一条具体、有针对性的指令增加每个原则都要包含一个具体示例reword_ambiguity澄清模糊措辞be thorough → 至少覆盖 3 个不同方面add_anti_pattern显式禁止观察到的失败增加绝不以In this response I will...开头reorder_priority把重要指令前移把输出格式说明从底部移到顶部add_example加入期望输出的具体示例加一个 3 行的理想结构示例remove_over_optimization删除导致僵化的指令删除始终恰好用 5 个要点simplify减少指令数量合并冗余规则把 3 条相似的格式规则合并为 1 条constrain_scope收窄目标焦点只聚焦前 3 项发现而非全部坏变异应当避免类型为什么不好rewrite_from_scratch丢失全部累积改进重置为随机状态add_10_plus_rules令目标不堪重负——导致指令遵循能力退化vague_instructionsbe better 不携带任何信号copy_from_unrelated跨领域搬运模式很少能迁移成功meta_instructions关于如何思考一步步思考——收益递减这套分类法直指一个深刻问题优化循环的质量上限由变异假设的质量决定。这也是为什么stepSize低时偏向保守变异、高时偏向结构性变异——它实际上是在调节假设的激进程度。七、ISC 在 Optimize 中的角色护栏而非目标Optimize 模式中 ISCInvariant Success Criteria不变量成功准则承担明确且严格受限的角色ISCs areguard rails— invariant assertions that must hold regardless of score.ISC 是护栏无论分数如何都必须成立的不变量断言例ISC-1: 所有现有测试仍然通过、ISC-2: 输出绝不包含禁用词汇任一 ISC 失败变异即使提升了分数也必须回滚ISC 不是优化目标——度量/评估才是。eval-guide.md 进一步区分了两者的分工评估准则 收敛信号convergence signal分数驱动优化准则可以被轮换、收紧、逐步升级ISC 护栏 不变量断言invariant assertions在所有实验中都必须为真违反即自动回滚无论通过率是否提升。护栏的典型内容与模式无关无崩溃、输出非空、输出无 PII。一句话总结评估准则回答好不好ISC 回答坏没坏——前者决定取舍后者决定生死。八、Eval 模式深度如何编写经得起推敲的二元准则Eval 模式的全部信号来自 3–6 条二元评估准则。准则写得差整个循环就会向着错误方向优化所以 eval-guide.md 花了大篇幅规范准则编写。8.1 三条必过测试The 3-Question Test每条准则在投入使用前必须通过三个问题任一不过即产生误导性优化信号问题一两个独立评判者会达成一致吗准则必须足够具体使两个不同 LLM 实例或两个人在 85% 的情况下给出相同的 yes/no 答案。PASS输出是否包含至少 3 个带引用来源的具体事实FAIL输出是否高质量太模糊评判者会分歧FAIL写作风格好吗主观无锚点问题二目标能否不作真正改进就刷过此准则如果某个退化的变异能通过准则而实际上没有变好说明准则可被钻空子gameable会把优化引向垃圾。PASS输出是否针对用户的具体问题而非泛泛话题FAIL输出是否超过 500 词用填充内容即可刷过FAIL输出是否提到所有输入关键词关键词堆砌即可刷过问题三用户真的在乎这个吗准则必须度量终端用户能注意到并重视的东西。PASS输出是否提供可执行的下一步而非只有分析FAIL输出是否恰好用 3 个要点武断的格式规则FAIL输出是否提到系统提示词的指令元层面无用8.2 编写准则的结构要求结构每条准则都是关于输出的二元 yes/no 问题必须仅凭输出文本可选地加上输入就能回答数量每个目标 3–6 条。少于 3 条信号不足多于 6 条制造噪音并拖慢循环模板Does the output [observable behavior] [specific threshold/condition]?按领域示例提示词优化- Does the output directly address the users question in the first paragraph? - Does the output contain specific examples, not just abstract principles? - Does the output avoid repeating the same point in different words? - Is the output structured with clear sections or logical flow?技能优化- Does the skill route to the correct workflow for the given input? - Does the output contain actionable content, not just meta-commentary? - Does the output follow the specified format constraints? - Does the skill handle edge-case inputs without crashing or producing empty output?Agent 优化- Does the agent complete the assigned task without human intervention? - Does the agent use appropriate tools for each step? - Does the agents final output match the requested format? - Does the agent avoid unnecessary tool calls or redundant work?代码非数值质量优化- Does the function handle all documented edge cases? - Does the output match the expected schema? - Does the function complete without throwing unhandled exceptions?8.3 反准则Anti-Criteria反准则定义输出不得做什么防止优化器漂向退化方案。模板为The output must NOT [undesirable behavior].- The output must NOT contain placeholder text or TODO markers. - The output must NOT repeat the input prompt verbatim. - The output must NOT exceed 2000 words for a summary task. - The output must NOT hallucinate citations or make up sources.反准则与普通准则用相同机制检查但逻辑反转回答是意味着失败。8.4 常见错误清单准则过多6制造噪音稀释有意义信号的权重优化器把周期花在满足低价值检查上过于狭窄/僵硬过度具体的准则约束优化器找到创造性改进的空间——输出是否以Here is开头太僵硬输出是否以清晰的主题句开头更好准则重叠总是同时通过或同时失败的两条准则不提供额外信号只保留更精确的那条无法仅从输出判定需要外部上下文数据库查询、实时数据的准则无法从输出评判准则冲突要简洁 要详尽会引发振荡应在循环开始前用阈值化解500 词以内 至少覆盖 3 个关键方面。8.5 停滞恢复Stall Recovery当通过率进入平台期按顺序尝试检查天花板——通过率 95% 说明当前准则已饱和收紧准则或加入更难的标准分析失败模式——哪些准则在失败把变异集中到这些特定区域尝试减法变异——删除可能造成干扰的指令替换一条准则——把区分度最低的准则换成更难的一条更换测试输入——当前输入可能没有施压到正确的行为上。8.6 评分公式每次实验的分数passes / (criteria_count × runs_per_experiment)其中passes 所有准则与所有运行中二元yes判定的总数criteria_count 评估准则数量3–6runs_per_experiment 每次实验目标运行的次数默认 3。示例5 条准则、3 次运行、15 个可能判定中通过 12 个 80% 通过率。分数与当前最佳值比较决定保留或回滚与 metric mode 同构。九、目标类型与沙箱策略target-types.md 定义了 Optimize 的五个目标类型及其检测规则类型检测规则skill目录含SKILL.md或路径指向~/.claude/skills/下的技能目录prompt独立的.md或.txt提示词文件父目录无 SKILL.mdagent含 Agent frontmattername、description、tools/capabilities 字段的.md文件code提供metric_command的源文件.ts、.js、.py、.go等function源文件 特定函数名——code 的子集限定在单一函数沙箱策略与评估模式强绑定code / functionmetric modegit 分支optimize/{metric_name}无需沙箱目录metric_command即测试skill / prompt / agenteval mode复制到MEMORY/WORK/{slug}/sandbox/变异只改沙箱副本永不触碰原件。9.1 自动 ISC 生成流程进入目标分析阶段时系统按 8 步自动生成评估准则全面读取目标按各类型的What to read清单提取目的——目标应当做什么提取约束——存在哪些规则或格式要求提取边界情况——应处理哪些异常输入或状态以各类型的 ISC 生成模板为起点起草 3–6 条定制化二元准则基于该目标类型的常见失败模式起草 1–2 条反准则对每条准则应用 3-Question Test删掉不过的提交用户审批——循环开始前展示生成的准则允许修改。9.2 测试输入生成读取目标以理解预期输入格式与领域生成 3–5 个覆盖目标能力的多样化输入保证多样性至少一个简单/直接输入、一个复杂/多面输入、一个边界/临界输入与评估准则一同提交用户审批。五种类型共享同一套 8 步循环结构、护栏语义、结果日志results.tsv ISA experiments 表、平台协议与会话恢复能力核心差异只在于git 分支 vs 沙箱目录和metric_command vs LLM 评判。十、与 Algorithm 各阶段的集成Optimize 不是悬空的独立循环而是嵌入 Algorithm 标准阶段中的一条内层循环Algorithm 阶段Optimize 的职责OBSERVE触发检测、参数解析、eval-mode 判定、以 metric_command 或 eval_criteria 搭建 ISA 骨架THINK识别护栏 ISC为优化循环做预检模式坍塌、钻空子度量、局部最优PLAN通常为single | combined (inseparable)——优化是单条紧耦合循环BUILD建立沙箱git 分支或目录副本EXECUTE运行优化循环记录每个实验的假设 分数 决策VERIFY确认 ISC 护栏全程成立最终分数对比基线检查 Meta-Learner 调整LEARN把胜出变异路由到 KNOWLEDGE记录 Meta-Learner 调整埋葬失败的变异分类法注意 THINK 阶段的预检特别点出了优化循环的三个经典失败模式这在现代机器学习实践中同样成立模式坍塌mode collapse——变异收敛到单一重复套路钻空子度量gaming the metric——分数上升但真实质量未变这正是 3-Question Test 问题二要防的局部最优local optima——爬山算法在局部极值停滞这正是regressionTolerance0.4 模拟退火语义要解的。LEARN 阶段的埋葬失败的变异分类法tombstone failed mutation taxonomies也很关键它让系统不仅记录成功还记录哪些变异类型被证明无效避免未来重复试错。十一、实战示例文档给出了三个触发示例覆盖三种典型配置optimize this prompt for higher engagement优化这个提示词以提高参与度→mode: optimize、eval mode、E3optimize the bundle size of /dashboard优化 /dashboard 的打包体积→mode: optimize、metric modebun run build、preset: cautious、E3aggressive optimize: cut the API latency in half激进优化把 API 延迟减半→mode: optimize、metric mode、preset: aggressive、E4。示例中的 E3/E4 属于已退役的 E1–E5 努力等级体系在 Algorithm v8 中已被由工作本身发现的动态范围取代参见 v8.20.2.md 的 Spend 一节。11.1 现代形态/optimize技能的实际调用虽然mode:字段已退役但同一个爬山循环以/optimize技能的形式保持活跃skills/Optimize/SKILL.md。其调用方式是判定eval_mode的现行标准提供--measure→eval_mode: metricgit 分支沙箱提供--target→eval_mode: eval目录沙箱。Metric Mode 参数参数必填默认值说明--metric NAME是人类可读的度量名--measure COMMAND是产生度量的 shell 命令--files GLOB是允许 Agent 修改的文件逗号分隔--higher-is-better(默认)度量值越高越好--lower-is-better度量值越低越好--extract COMMANDstdout 最后一个数字从输出提取度量值--budget SECONDS300每次实验的时间预算--target VALUE无度量达到该值时停止--max-experiments N无N 次实验后停止--locked GLOB无Agent 不得修改的文件--constraints TEXT无附加规则如测试必须通过Eval Mode 参数参数必填默认值说明--target PATH是技能目录、提示词文件或 Agent 定义路径--max-experiments N无N 次实验后停止--runs N3每次实验运行次数越多越可靠、越慢--criteria Q1 Q2自动生成覆盖自动生成的评估准则--inputs I1 I2自动生成覆盖自动生成的测试输入--budget SECONDS300每次实验的时间预算共享参数--resume恢复之前的优化运行、--status显示上次/当前运行的结果摘要。完整调用示例来自 SKILL.md# Metric优化页面加载性能 /optimize --metric lighthouse_perf --higher-is-better \ --measure npx lighthouse http://localhost:3000 --outputjson --output-pathlh.json \ --extract jq .categories.performance.score * 100 lh.json \ --files src/**/*.tsx,src/**/*.css \ --target 95 --budget 120 # Metric优化打包体积 /optimize --metric bundle_bytes --lower-is-better \ --measure bun run build 21 du -sb dist/ | cut -f1 \ --files src/**/*.ts \ --constraints all tests must pass # Eval优化某个技能 /optimize --target ~/.claude/skills/ExtractWisdom --max-experiments 15 # Eval自定义准则与输入 /optimize --target ~/.claude/skills/Research/Workflows/QuickResearch.md \ --criteria Does the output contain specific facts with sources? \ Is the output structured with clear sections? \ Does the output avoid generic filler? \ --inputs research quantum computing breakthroughs 2025 \ quick research on supply chain security技能文档还给出了一条重要的经验性注释metric mode 每小时约 12 次实验5 分钟预算下eval mode 每小时约 6–8 次多轮评判更慢——这量化了两种模式的速度差异也为设置maxIterations提供了现实依据。11.2 已知陷阱GotchasSKILL.md 明确警告爬山会困在局部最优分数进入平台期时考虑以不同初始条件重置eval 与 metric 的选择可量化目标延迟、体积用 metric定性目标技能质量、提示词有效性用 eval回退容忍度防止灾难性变更不要设成 0——如果主度量显著提升次要度量的轻微回退是可接受的。十二、Pulse 表面优化过程的观测入口Optimize 模式曾是 Pulse 观察层的一等公民归档文档记录的形态TabOptimizeDashboardOptimizeDashboard原路径LIFEOS/PULSE/Observability/src/components/activity/OptimizeDashboard.tsx过滤algorithmStates.filter(s s.mode optimize)需要如实说明该OptimizeDashboard.tsx组件已在 2026-07-14 的 agents-dashboard 重构中被删除——archive/modes/README.md 明确记载the agents page now renders Work Activity tabs with lifecycle derived from run data, and no longer references this directory。当前仓库components/activity/下实际存在的是 WorkBoard.tsx、ClimbChart.tsx 等新一代组件。归档的模式元数据目录 DOCUMENTATION/Pulse/PulseMetadata.md 记录了 optimize 模式曾填充的 ISA frontmatter 字段作为历史参考algorithm_mode: optimize、algorithm_config.preset必填、algorithm_config.params必填、eval_modemetric/eval必填、iteration按实验计数、density_scoreE3、interview_invokedE3。这套模式元数据随运行数据派生的思路在现代实现中以 ascent.ts 的deriveAscent()统一派生表的形式延续下来参见 v8.20.2.md 的 Telemetry 一节。十三、历史地位与现代遗产理解 Optimize 模式最好的方式是同时看到它的过去与现在。它曾经是模式体系的一员。在 2026-05-13 的模式重组中Optimize 教义从 optimize-loop.md现为指向本文件的 redirect 指针迁入modes/目录与 iterate、ideate、loop、native 并列构成 Algorithm 的六模式体系详见 archive/modes/README.md。它随模式体系一起退役。2026-07-11Algorithm v8 以one adaptive format取代了模式/层级体系v8.1.0 的 changelog 记录了主理人当时的原话the desired statement of what I want should be in the Algorithm; its the outcome that I want, not how to get there期望的声明应该在 Algorithm 里我要的是结果不是达成路径。所有模式文件被移入archive/仅作为记录保留见 changelog.md。但它的思想没有死。三个遗产清晰可辨爬山循环/optimize技能持续运行同一条 HYPOTHESIZE → MUTATE → MEASURE → DECIDE → COMMIT-OR-REVERT 循环只是不再需要mode: optimize字段二元评估准则eval-guide.md 的 3-Question Test 与变异分类法直接指导着现行 Evals 技能中llm-assert断言的编写断言即自然语言检查由评判者打 TRUE/FALSE并共享同一套评判纪律先推理后打分、使用独立的评判模型、Unknown 计为 missISC 护栏语义护栏必须全程成立、违规即回滚、护栏不是优化目标这一原则与 Algorithm v8 完成条件中每条 claim 必须携带可证伪它的探针的验证教义一脉相承v8.20.2.md 第 8 条Should work is forbidden。对今天的使用者而言这份文档最大的价值在于它把如何系统化地优化一个制品拆解成了一套可复用的工程方法——定义度量、控制变异胆略、容忍回退、设护栏、写防钻空子的准则、在平台期知道该做什么。无论模式字段是否存在这套方法都成立。交叉引用索引模式总览历史archive/modes/README.md参数 schema历史archive/parameter-schema.mdEval 模式指南eval-guide.md](LifeOS/install/LIFEOS/ALGORITHM/eval-guide.md)目标类型历史archive/target-types.mdOptimize 技能现行、活跃skills/Optimize/SKILL.md当前 Algorithm 教义v8.20.2.md版本锚点见 LATESTAlgorithm 变更史changelog.md模式元数据目录DOCUMENTATION/Pulse/PulseMetadata.md【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
