尧图网页设计 
LifeOS Evals ViewResults 工作流解读评估结果、检查饱和度与失败分析【免费下载链接】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本文围绕 LifeOS 的 Evals 技能中的 ViewResults 工作流展开讲清楚评估eval运行结束后结果落盘在哪里、如何用jq逐层读取运行摘要与逐次试错trial明细、如何用SuiteManager判定一个套件是否已经饱和并给出晋级建议以及如何按固定模板产出结果报告。读完本文你可以独立完成跑完 eval → 检查结果 → 定位失败 trial → 判断套件是否需要晋级回归这一完整闭环。ViewResults 在 Evals 工作流中的定位Evals 是 LifeOS 中一套断言优先assertion-first的 AI 评估框架其完整能力由若干工作流组成。在 Evals 技能说明 的路由表中ViewResults的触发语义是eval results、how did it score、show the last run、saturation——即它专门负责 RunEval 之后的看结果环节而不是再跑一次评估。它解决三个具体问题读结果从 canonical 结果存储中取出某次运行的 summary、逐 trial 分数与 grader 输出判饱和当一个 capability能力型套件连续跑赢阈值时判断它是否该毕业进入 regression回归型套件出报告用统一模板把结果整理成可汇报的格式并明确当前技能没有内置趋势对比 CLI这一边界。结果落盘位置Evals-Results 是唯一的权威存储ViewResults 工作流首先定义了结果的存在位置原文档的 Where Results Live 一节~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/run-id/results.json每个results.json包含运行摘要run summary、逐 trial 分数per-trial scores、grader 输出grader outputs和失败细节failure details。LIFEOS/MEMORY/STATE/Evals-Results/目录是 canonical store权威存储工作流明确要求直接用标准工具查询它jq、rg、cat而不是依赖某个专用查看器。这个设计与 Evals 的核心纪律一脉相承。SKILL.md 在 Doctrine 一节写着Never trust a score until you read transcripts—— 每次运行都会把完整 case transcript 持久化到MEMORY/STATE/Evals-Results/suite/run/run.json。也就是说ViewResults 不只是看个分数而是把读原始输出作为看结果的必经动作。从源码结构看这个存储布局由运行器自己负责写入。以 v2 的断言优先运行器 EvalRunner.ts 为例每次运行结束会执行// 持久化完整 transcriptAnthropic 纪律 latest 状态 const dir join(RESULTS_DIR, name); mkdirSync(join(dir, runId), { recursive: true }); writeFileSync(join(dir, runId, run.json), JSON.stringify({ ...result, detail: caseResults }, null, 2)); writeFileSync(join(dir, latest.json), JSON.stringify({ ...result, ts: new Date().toISOString() }, null, 2));其中RESULTS_DIR被定义为~/.claude/LIFEOS/MEMORY/STATE/Evals-Results见 EvalRunner.ts#L30-L31每次运行额外还落一份latest.json方便取最近一次。ViewResults 文档里的results.json路径则对应更早的 v1 运行器TrialRunner.ts产生的按任务组织的结果文件两者的目录骨架use-case/run-id/ 单个 JSON 大文件是一致的。五步执行流程步骤 0语音通知可选best-effort原文档开头给出一条工作流启动时的语音通知命令curl -s -X POST http://localhost:31337/notify \ -H Content-Type: application/json \ -d {message: Running the ViewResults workflow in the Evals skill to display eval results} \ /dev/null 21 这里的localhost:31337是 LifeOS 的 Pulse 组件menu-bar 应用 :31337服务见 INSTALL.md 组件表。注意该命令以挂到后台、并丢弃全部输出——它是纯通知通知失败不影响工作流本身如果当前环境没有安装 Pulse这条命令静默失败即可。步骤 1列出某个 use case 的所有运行# 按时间列出某个 use case 的全部运行最新的在最上面 ls -1t ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/ # 或者通过 SuiteManager 列出套件 bun run ~/.claude/skills/Evals/Tools/SuiteManager.ts list第一条命令依赖结果目录 一个子目录的组织方式ls -1t按修改时间倒序天然就是最近运行优先。第二条则从套件定义侧入手—— SuiteManager.ts 的list子命令会扫描Suites/Capability与Suites/Regression两个目录下的.yaml/.yml文件源码注释明确说明.yml与.yaml同等有效见 SuiteManager.ts#L93-L99输出形如 name (N tasks)的列表。步骤 2查看最近一次运行的摘要# 取最新一次运行的 results.json LATEST$(ls -1t ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/ | head -1) cat ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/$LATEST/results.json | jq .summary # 或查看指定运行 cat ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/run-id/results.json | jq .summaryuse-case是占位符实际是 use case / suite 名称目录层级中的第一层。jq .summary只取摘要字段是最低成本的第一步先确认这是什么、结果如何再决定是否下钻。步骤 3检查饱和度capability → regression 晋级判断bun run ~/.claude/skills/Evals/Tools/SuiteManager.ts check-saturation suite-name饱和度的具体算法见下文饱和度机制一节这里先给出结论该命令输出三行关键信息——Saturated: Yes/No、Consecutive above threshold: N/3、Recommendation: action。步骤 4查看逐 trial 分数或失败细节# 逐 trial 摘要 cat .../results.json | jq .trials[] | {trial: .trial_id, pass: .passed, score: .score} # 只看失败的 trial cat .../results.json | jq .trials[] | select(.passed false) # 查看某个 trial 的全部 grader 输出 cat .../results.json | jq .trials[0].graders这三条jq是从摘要级下钻到证据级的关键第一条把每个 trial 压成{trial, pass, score}三列一眼看出哪几次挂了、分数分布如何第二条用select(.passed false)过滤失败 trial——失败项里通常带有error字段与完整grader_results是定位回归的第一现场第三条取出单个 trial 的全部 grader 输出每个 grader 的score、passed、reasoning、details这正是 SKILL.md 所说读 transcript 再信分数的落点。字段名称有类型定义可查Trial、GraderResult、EvalRun接口在 Types/index.ts 中定义其中EvalRun聚合了pass_rate、mean_score、std_dev以及两个关键可靠性指标pass_at_kk 次里至少成功 1 次衡量能不能做到与pass_to_kk 次全部成功衡量是否稳定。步骤 5按模板产出报告工作流给定了一份固定的报告模板完整继承自 ViewResults.md SUMMARY: Evaluation results for use-case STATUS: | Metric | Value | |--------|-------| | Run ID | run-id | | Date | date | | Model | model | | Pass Rate | X% | | Mean Score | X.XX | STORY EXPLANATION: 1. Retrieved evaluation run from date 2. N trials evaluated against use-case criteria 3. Key finding 4. Recommendation COMPLETED: Results retrieved for use-case, pass-rate% pass rate.模板中每一格都能从结果 JSON 中取到对应字段Run ID、Datestarted_at/completed_at、Modelmodel、Pass Ratepass_rate、Mean Scoremean_score。STORY EXPLANATION 一节要求用编号叙述交代数据来源、trial 数量、关键发现与后续建议——这是把一次冷查询变成可汇报结论的格式约束。v1 运行器的展示函数 TrialRunner.ts 的formatEvalResults生成的表格Trials / Pass Rate / Mean Score / Std Dev / passk / pass^k 逐 trial 状态 Trial 1 的 grader 明细与本模板字段高度对齐可以视为同一信息结构的程序化版本。饱和度机制SuiteManager 的源码级解读check-saturation是 ViewResults 工作流中唯一带决策输出的步骤。读 SuiteManager.ts 的checkSaturation可以完整还原其判定逻辑取历史读取Evals-Results/suite-name/下所有以run_开头的运行目录按名称排序取最近 10 个逐个解析其run.json抽出{date, rate}序列date取completed_at缺失时退回started_atrate取pass_rate。解析失败的运行静默跳过不会中断检查。定阈值threshold suite.saturation_threshold ?? 0.95即套件 YAML 未显式配置时默认 0.95。可参考仓库中现成的套件定义core-behaviors.yaml 把回归套件压得很高pass_threshold: 0.95、saturation_threshold: 0.99而 core-dispositions.yaml 用pass_threshold: 0.75并显式trials: 2注释解释了为何取 2 而非 3该套件在每次配置变更时都会触发每次 trial 都有真实推理成本2 次仍能保证 pass^k 表示两次都稳定而不是碰巧过一次。判饱和recentAboveThreshold history.slice(-3).filter(h h.rate threshold)当且仅当最近 3 次运行全部达标recentAboveThreshold.length 3时saturated true。给建议recommended_action三选一——条件建议动作套件是 capability 型 且 已饱和graduate_to_regression毕业进回归已饱和但非 capability 型add_harder_cases加更难的 case未饱和keep维持现状返回结构SaturationStatus见 Types/index.ts#L313-L319包含suite_id、pass_rate_history、saturated、consecutive_above_threshold、recommended_action五个字段CLI 的check-saturation子命令直接打印其中三项。毕业动作本身由graduate子命令执行graduateSuite把套件type改为regression、pass_threshold提到 0.95回归套件要求更高并把 YAML 文件从Suites/Capability/移到Suites/Regression/。这与 Evals 的整体教条一致——capability 套件是要攀登的山丘起点可以低regression 套件瞄准接近 100%通过的能力 case 应当晋升到回归里被永久守护见 SKILL.md Doctrine 一节。SuiteManager的完整 CLI 面无参数时打印帮助源码见 SuiteManager.ts#L271-L298命令作用create name -d desc [-t type] [--domain D]创建套件type 默认capabilitycreateSuite中默认阈值regression 0.95 / capability 0.70saturation_threshold默认 0.95list [type]列出套件可按类型过滤show name套件详情 饱和度状态含最近 5 次通过率列表add-task suite task向套件追加任务check-saturation nameViewResults 步骤 3 使用的饱和检查graduate namecapability 套件晋级为 regression读懂结果pass^k、passk 与加权断言查看 trial 分数时真正要理解的是评分语义而不是数字本身。v2 运行器 EvalRunner.ts 对每个 case 跑trials次每次 trial 的分数是各断言的加权平均weighted()Σ(score×weight) / Σweightscore caseThreshold判为 passedcase 级阈值缺省时回落到套件的pass_threshold。两个 case 级指标的计算见 EvalRunner.ts#L169-L182pass_at_k只要有任何一次 trial 通过即为 1否则 0 —— 能力型问题能不能做到pass_to_k只有当passed trials全部通过才为 1否则 0 —— 可靠性问题是否每次都做到。源码里有一段值得注意的修正注释EvalRunner.ts#L174-L179早期实现用passed/trials均值表示 pass^k会把3 次过 2 次报成 67%让一个 flaky不稳定的 case 看起来像是基本通过修正后的语义是 2/3 直接记 0。注释明确说这是语义修正不是回归——历史数字不可直接比较。所以当你用 ViewResults 对比新旧两次运行的 pass^k 数字时跨实现版本的数字没有可比性这一点源码已经提前声明了。套件级结果SuiteResult把 case 级指标再平均score是各 casemean_score的均值pass_to_k/pass_at_k是各 case 指标的均值passed meanScore threshold。CLI 输出形如pass^k 100%, mean 83.3% over 2 trials退出码 0 表示通过、1 表示回归——这让 ViewResults 看到的run.json/results.json里每个字段都能追溯到明确的计算来源。从源码结构看v1 与 v2 两套运行器的落盘字段有差异ViewResults 文档中的jq .trials[] ... .graders路径对应 v1 的results.jsontrials[].graders即 v1 的grader_results接口定义见 Types/index.ts 的 Trial/GraderResult而 v2 的EvalRunner写入的是run.json含detail明细数组每个 case 的 trials 内含asserts数组与output原文外加一份latest.json。因此在实际查看时如果目录里是run.json而非results.json把上面的jq字段路径换成对应结构如.detail[].trials[].asserts即可摘要 → 下钻失败项 → 读原文的三层查看方法不变。实操提示结果目录的拼写一致性有一个值得留意的细节EvalRunner.ts#L30-L31 使用~/.claude/LIFEOS/MEMORY/STATE/Evals-Results全大写LIFEOS而 ViewResults 文档与 v1 工作流一致地使用同样的大写路径但从源码结构看SuiteManager.ts#L15-L16 的RESULTS_DIR是相对技能目录拼出来的.../LifeOS/MEMORY/STATE/Evals-Results驼峰LifeOS。在大小写敏感的文件系统如 Linux上这两个路径解析到不同目录。如果你的check-saturation总报未饱和而 EvalRunner 明明每次都在跑可以推断原因之一是两边看的不是同一棵目录树——先用ls确认结果实际落在哪个拼写的路径下再决定从哪一侧读历史。对比与趋势分析当前技能的明确边界原文档在 Comparison and Trend Analysis 一节给出了诚实的边界声明当前技能没有内置趋势分析、回归检测或跨运行对比的 CLI。跨运行/跨模型对比被设计为在results.json之上用jq或小型临时脚本按需编写的使用场景如果确实需要反复做趋势分析文档建议的方向是编写一个Tools/TrendReport.ts脚本并接入路由表——并且明确说明该脚本尚不存在于仓库中。这一点在仓库中可以得到佐证Tools/ 目录下有EvalRunner.ts、SuiteManager.ts、TrialRunner.ts、FailureToTask.ts等 12 个脚本但没有 TrendReport跨模型对比的工作流 CompareModels.md 的 Step 4 也是同一模式——每个模型跑一次EvalRunner各自落一份结果 JSON然后直接jq读取这些 JSON 做并排比较本技能没有内置跨模型对比 CLI。换句话说ViewResults 的看单次运行是有工具支撑的看多次运行则交给你的一行jq。一个最小可用的跨运行对比示例基于目录组织方式无需额外脚本# 某 use case 最近 10 次运行的 (run-id, summary) 序列 for d in $(ls -1t ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/ | grep ^run_ | head -10); do f$HOME/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/$d json$(ls $f/*.json | head -1) echo $d $(jq -r .summary // .summary $json 2/dev/null) done小结ViewResults 工作流的产出边界在原文档 Done 一节有明确表述结果从LIFEOS/MEMORY/STATE/Evals-Results/use-case/run-id/results.json检查完成并可选地通过SuiteManager.ts给出套件饱和度状态。把它落回到本文的要点上一个权威存储~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/run-id/用ls -1t找最近运行、用jq下钻三步下钻法jq .summary看摘要 →select(.passed false)看失败 trial → 取单 trial 的 grader 输出读证据贯彻读 transcript 再信分数的纪律饱和判定最近 3 次运行全部 ≥saturation_threshold默认 0.95即饱和capability 套件饱和后graduate晋级 regression 并把pass_threshold提到 0.95明确的边界跨运行趋势/回归检测没有内置 CLITrendReport.ts尚未落盘——需要时基于results.json/run.json自行用jq或临时脚本实现。关键参考文件ViewResults.md、SKILL.md、SuiteManager.ts、EvalRunner.ts、TrialRunner.ts、Types/index.ts、core-dispositions.yaml。【免费下载链接】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 Evals ViewResults 工作流：解读评估结果、检查饱和度与失败分析
LifeOS Evals ViewResults 工作流解读评估结果、检查饱和度与失败分析【免费下载链接】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本文围绕 LifeOS 的 Evals 技能中的 ViewResults 工作流展开讲清楚评估eval运行结束后结果落盘在哪里、如何用jq逐层读取运行摘要与逐次试错trial明细、如何用SuiteManager判定一个套件是否已经饱和并给出晋级建议以及如何按固定模板产出结果报告。读完本文你可以独立完成跑完 eval → 检查结果 → 定位失败 trial → 判断套件是否需要晋级回归这一完整闭环。ViewResults 在 Evals 工作流中的定位Evals 是 LifeOS 中一套断言优先assertion-first的 AI 评估框架其完整能力由若干工作流组成。在 Evals 技能说明 的路由表中ViewResults的触发语义是eval results、how did it score、show the last run、saturation——即它专门负责 RunEval 之后的看结果环节而不是再跑一次评估。它解决三个具体问题读结果从 canonical 结果存储中取出某次运行的 summary、逐 trial 分数与 grader 输出判饱和当一个 capability能力型套件连续跑赢阈值时判断它是否该毕业进入 regression回归型套件出报告用统一模板把结果整理成可汇报的格式并明确当前技能没有内置趋势对比 CLI这一边界。结果落盘位置Evals-Results 是唯一的权威存储ViewResults 工作流首先定义了结果的存在位置原文档的 Where Results Live 一节~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/run-id/results.json每个results.json包含运行摘要run summary、逐 trial 分数per-trial scores、grader 输出grader outputs和失败细节failure details。LIFEOS/MEMORY/STATE/Evals-Results/目录是 canonical store权威存储工作流明确要求直接用标准工具查询它jq、rg、cat而不是依赖某个专用查看器。这个设计与 Evals 的核心纪律一脉相承。SKILL.md 在 Doctrine 一节写着Never trust a score until you read transcripts—— 每次运行都会把完整 case transcript 持久化到MEMORY/STATE/Evals-Results/suite/run/run.json。也就是说ViewResults 不只是看个分数而是把读原始输出作为看结果的必经动作。从源码结构看这个存储布局由运行器自己负责写入。以 v2 的断言优先运行器 EvalRunner.ts 为例每次运行结束会执行// 持久化完整 transcriptAnthropic 纪律 latest 状态 const dir join(RESULTS_DIR, name); mkdirSync(join(dir, runId), { recursive: true }); writeFileSync(join(dir, runId, run.json), JSON.stringify({ ...result, detail: caseResults }, null, 2)); writeFileSync(join(dir, latest.json), JSON.stringify({ ...result, ts: new Date().toISOString() }, null, 2));其中RESULTS_DIR被定义为~/.claude/LIFEOS/MEMORY/STATE/Evals-Results见 EvalRunner.ts#L30-L31每次运行额外还落一份latest.json方便取最近一次。ViewResults 文档里的results.json路径则对应更早的 v1 运行器TrialRunner.ts产生的按任务组织的结果文件两者的目录骨架use-case/run-id/ 单个 JSON 大文件是一致的。五步执行流程步骤 0语音通知可选best-effort原文档开头给出一条工作流启动时的语音通知命令curl -s -X POST http://localhost:31337/notify \ -H Content-Type: application/json \ -d {message: Running the ViewResults workflow in the Evals skill to display eval results} \ /dev/null 21 这里的localhost:31337是 LifeOS 的 Pulse 组件menu-bar 应用 :31337服务见 INSTALL.md 组件表。注意该命令以挂到后台、并丢弃全部输出——它是纯通知通知失败不影响工作流本身如果当前环境没有安装 Pulse这条命令静默失败即可。步骤 1列出某个 use case 的所有运行# 按时间列出某个 use case 的全部运行最新的在最上面 ls -1t ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/ # 或者通过 SuiteManager 列出套件 bun run ~/.claude/skills/Evals/Tools/SuiteManager.ts list第一条命令依赖结果目录 一个子目录的组织方式ls -1t按修改时间倒序天然就是最近运行优先。第二条则从套件定义侧入手—— SuiteManager.ts 的list子命令会扫描Suites/Capability与Suites/Regression两个目录下的.yaml/.yml文件源码注释明确说明.yml与.yaml同等有效见 SuiteManager.ts#L93-L99输出形如 name (N tasks)的列表。步骤 2查看最近一次运行的摘要# 取最新一次运行的 results.json LATEST$(ls -1t ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/ | head -1) cat ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/$LATEST/results.json | jq .summary # 或查看指定运行 cat ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/run-id/results.json | jq .summaryuse-case是占位符实际是 use case / suite 名称目录层级中的第一层。jq .summary只取摘要字段是最低成本的第一步先确认这是什么、结果如何再决定是否下钻。步骤 3检查饱和度capability → regression 晋级判断bun run ~/.claude/skills/Evals/Tools/SuiteManager.ts check-saturation suite-name饱和度的具体算法见下文饱和度机制一节这里先给出结论该命令输出三行关键信息——Saturated: Yes/No、Consecutive above threshold: N/3、Recommendation: action。步骤 4查看逐 trial 分数或失败细节# 逐 trial 摘要 cat .../results.json | jq .trials[] | {trial: .trial_id, pass: .passed, score: .score} # 只看失败的 trial cat .../results.json | jq .trials[] | select(.passed false) # 查看某个 trial 的全部 grader 输出 cat .../results.json | jq .trials[0].graders这三条jq是从摘要级下钻到证据级的关键第一条把每个 trial 压成{trial, pass, score}三列一眼看出哪几次挂了、分数分布如何第二条用select(.passed false)过滤失败 trial——失败项里通常带有error字段与完整grader_results是定位回归的第一现场第三条取出单个 trial 的全部 grader 输出每个 grader 的score、passed、reasoning、details这正是 SKILL.md 所说读 transcript 再信分数的落点。字段名称有类型定义可查Trial、GraderResult、EvalRun接口在 Types/index.ts 中定义其中EvalRun聚合了pass_rate、mean_score、std_dev以及两个关键可靠性指标pass_at_kk 次里至少成功 1 次衡量能不能做到与pass_to_kk 次全部成功衡量是否稳定。步骤 5按模板产出报告工作流给定了一份固定的报告模板完整继承自 ViewResults.md SUMMARY: Evaluation results for use-case STATUS: | Metric | Value | |--------|-------| | Run ID | run-id | | Date | date | | Model | model | | Pass Rate | X% | | Mean Score | X.XX | STORY EXPLANATION: 1. Retrieved evaluation run from date 2. N trials evaluated against use-case criteria 3. Key finding 4. Recommendation COMPLETED: Results retrieved for use-case, pass-rate% pass rate.模板中每一格都能从结果 JSON 中取到对应字段Run ID、Datestarted_at/completed_at、Modelmodel、Pass Ratepass_rate、Mean Scoremean_score。STORY EXPLANATION 一节要求用编号叙述交代数据来源、trial 数量、关键发现与后续建议——这是把一次冷查询变成可汇报结论的格式约束。v1 运行器的展示函数 TrialRunner.ts 的formatEvalResults生成的表格Trials / Pass Rate / Mean Score / Std Dev / passk / pass^k 逐 trial 状态 Trial 1 的 grader 明细与本模板字段高度对齐可以视为同一信息结构的程序化版本。饱和度机制SuiteManager 的源码级解读check-saturation是 ViewResults 工作流中唯一带决策输出的步骤。读 SuiteManager.ts 的checkSaturation可以完整还原其判定逻辑取历史读取Evals-Results/suite-name/下所有以run_开头的运行目录按名称排序取最近 10 个逐个解析其run.json抽出{date, rate}序列date取completed_at缺失时退回started_atrate取pass_rate。解析失败的运行静默跳过不会中断检查。定阈值threshold suite.saturation_threshold ?? 0.95即套件 YAML 未显式配置时默认 0.95。可参考仓库中现成的套件定义core-behaviors.yaml 把回归套件压得很高pass_threshold: 0.95、saturation_threshold: 0.99而 core-dispositions.yaml 用pass_threshold: 0.75并显式trials: 2注释解释了为何取 2 而非 3该套件在每次配置变更时都会触发每次 trial 都有真实推理成本2 次仍能保证 pass^k 表示两次都稳定而不是碰巧过一次。判饱和recentAboveThreshold history.slice(-3).filter(h h.rate threshold)当且仅当最近 3 次运行全部达标recentAboveThreshold.length 3时saturated true。给建议recommended_action三选一——条件建议动作套件是 capability 型 且 已饱和graduate_to_regression毕业进回归已饱和但非 capability 型add_harder_cases加更难的 case未饱和keep维持现状返回结构SaturationStatus见 Types/index.ts#L313-L319包含suite_id、pass_rate_history、saturated、consecutive_above_threshold、recommended_action五个字段CLI 的check-saturation子命令直接打印其中三项。毕业动作本身由graduate子命令执行graduateSuite把套件type改为regression、pass_threshold提到 0.95回归套件要求更高并把 YAML 文件从Suites/Capability/移到Suites/Regression/。这与 Evals 的整体教条一致——capability 套件是要攀登的山丘起点可以低regression 套件瞄准接近 100%通过的能力 case 应当晋升到回归里被永久守护见 SKILL.md Doctrine 一节。SuiteManager的完整 CLI 面无参数时打印帮助源码见 SuiteManager.ts#L271-L298命令作用create name -d desc [-t type] [--domain D]创建套件type 默认capabilitycreateSuite中默认阈值regression 0.95 / capability 0.70saturation_threshold默认 0.95list [type]列出套件可按类型过滤show name套件详情 饱和度状态含最近 5 次通过率列表add-task suite task向套件追加任务check-saturation nameViewResults 步骤 3 使用的饱和检查graduate namecapability 套件晋级为 regression读懂结果pass^k、passk 与加权断言查看 trial 分数时真正要理解的是评分语义而不是数字本身。v2 运行器 EvalRunner.ts 对每个 case 跑trials次每次 trial 的分数是各断言的加权平均weighted()Σ(score×weight) / Σweightscore caseThreshold判为 passedcase 级阈值缺省时回落到套件的pass_threshold。两个 case 级指标的计算见 EvalRunner.ts#L169-L182pass_at_k只要有任何一次 trial 通过即为 1否则 0 —— 能力型问题能不能做到pass_to_k只有当passed trials全部通过才为 1否则 0 —— 可靠性问题是否每次都做到。源码里有一段值得注意的修正注释EvalRunner.ts#L174-L179早期实现用passed/trials均值表示 pass^k会把3 次过 2 次报成 67%让一个 flaky不稳定的 case 看起来像是基本通过修正后的语义是 2/3 直接记 0。注释明确说这是语义修正不是回归——历史数字不可直接比较。所以当你用 ViewResults 对比新旧两次运行的 pass^k 数字时跨实现版本的数字没有可比性这一点源码已经提前声明了。套件级结果SuiteResult把 case 级指标再平均score是各 casemean_score的均值pass_to_k/pass_at_k是各 case 指标的均值passed meanScore threshold。CLI 输出形如pass^k 100%, mean 83.3% over 2 trials退出码 0 表示通过、1 表示回归——这让 ViewResults 看到的run.json/results.json里每个字段都能追溯到明确的计算来源。从源码结构看v1 与 v2 两套运行器的落盘字段有差异ViewResults 文档中的jq .trials[] ... .graders路径对应 v1 的results.jsontrials[].graders即 v1 的grader_results接口定义见 Types/index.ts 的 Trial/GraderResult而 v2 的EvalRunner写入的是run.json含detail明细数组每个 case 的 trials 内含asserts数组与output原文外加一份latest.json。因此在实际查看时如果目录里是run.json而非results.json把上面的jq字段路径换成对应结构如.detail[].trials[].asserts即可摘要 → 下钻失败项 → 读原文的三层查看方法不变。实操提示结果目录的拼写一致性有一个值得留意的细节EvalRunner.ts#L30-L31 使用~/.claude/LIFEOS/MEMORY/STATE/Evals-Results全大写LIFEOS而 ViewResults 文档与 v1 工作流一致地使用同样的大写路径但从源码结构看SuiteManager.ts#L15-L16 的RESULTS_DIR是相对技能目录拼出来的.../LifeOS/MEMORY/STATE/Evals-Results驼峰LifeOS。在大小写敏感的文件系统如 Linux上这两个路径解析到不同目录。如果你的check-saturation总报未饱和而 EvalRunner 明明每次都在跑可以推断原因之一是两边看的不是同一棵目录树——先用ls确认结果实际落在哪个拼写的路径下再决定从哪一侧读历史。对比与趋势分析当前技能的明确边界原文档在 Comparison and Trend Analysis 一节给出了诚实的边界声明当前技能没有内置趋势分析、回归检测或跨运行对比的 CLI。跨运行/跨模型对比被设计为在results.json之上用jq或小型临时脚本按需编写的使用场景如果确实需要反复做趋势分析文档建议的方向是编写一个Tools/TrendReport.ts脚本并接入路由表——并且明确说明该脚本尚不存在于仓库中。这一点在仓库中可以得到佐证Tools/ 目录下有EvalRunner.ts、SuiteManager.ts、TrialRunner.ts、FailureToTask.ts等 12 个脚本但没有 TrendReport跨模型对比的工作流 CompareModels.md 的 Step 4 也是同一模式——每个模型跑一次EvalRunner各自落一份结果 JSON然后直接jq读取这些 JSON 做并排比较本技能没有内置跨模型对比 CLI。换句话说ViewResults 的看单次运行是有工具支撑的看多次运行则交给你的一行jq。一个最小可用的跨运行对比示例基于目录组织方式无需额外脚本# 某 use case 最近 10 次运行的 (run-id, summary) 序列 for d in $(ls -1t ~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/ | grep ^run_ | head -10); do f$HOME/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/$d json$(ls $f/*.json | head -1) echo $d $(jq -r .summary // .summary $json 2/dev/null) done小结ViewResults 工作流的产出边界在原文档 Done 一节有明确表述结果从LIFEOS/MEMORY/STATE/Evals-Results/use-case/run-id/results.json检查完成并可选地通过SuiteManager.ts给出套件饱和度状态。把它落回到本文的要点上一个权威存储~/.claude/LIFEOS/MEMORY/STATE/Evals-Results/use-case/run-id/用ls -1t找最近运行、用jq下钻三步下钻法jq .summary看摘要 →select(.passed false)看失败 trial → 取单 trial 的 grader 输出读证据贯彻读 transcript 再信分数的纪律饱和判定最近 3 次运行全部 ≥saturation_threshold默认 0.95即饱和capability 套件饱和后graduate晋级 regression 并把pass_threshold提到 0.95明确的边界跨运行趋势/回归检测没有内置 CLITrendReport.ts尚未落盘——需要时基于results.json/run.json自行用jq或临时脚本实现。关键参考文件ViewResults.md、SKILL.md、SuiteManager.ts、EvalRunner.ts、TrialRunner.ts、Types/index.ts、core-dispositions.yaml。【免费下载链接】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），仅供参考