.69 · 报告快照

来源：reports/20261108-huanxi-0.8.14.69-framework-tools-t1/comparisons/analysis-20261108-huanxi-0.8.14.69-framework-tools-t1.md

# .69 版本结果与优化依据

本次观察为：回复耗时下降，但出现新的内容失败。不能仅凭总耗时把.69判为整体效果优于.68。

## 固定条件和结果

同10题、14逐字输入、每题单trial；liqian deepseek/deepseek-v4.1-flash-1017；Codex/OpenClaw沿2026-11-07固定归档，不重跑。OS各版在相同规格PPIO 4C/8G隔离实例评测，公开API驱动。不同日期/实例和模型非确定性仍限制因果归因。

| 产品/版本 | 完成输入 | 内容复核 | 回复耗时合计/秒 | 模型响应/工具 |
|---|---:|---|---:|---:|
| Codex0.165.0 | 14/14 | 9通过+1歧义 | 629.480 | 68/72 |
| OpenClaw2026.11.1 | 14/14 | 9通过+1歧义 | 767.627 | 125/120 |
| OS .67 | 11/14 | 9通过+1歧义 | 3019.007 | 301/281 |
| OS .68 | 14/14 | 9通过+1歧义 | 1060.384 | 105/100 |
| OS .69 | 14/14 | 8通过+C06失败+C10歧义 | 927.925 | 97/85 |

.69相对.68累计回复时间减少132.459秒（12.5%）；仍比固定Codex/OpenClaw多47.4%/20.9%。若排除题面歧义C10，两版累计延迟减少约6.3%，且仍包含C06新增内容失败。各输入延迟之和不是campaign墙钟，不把更快的失败当作收益。

.69四类模型配置均为Flash1017且fallback列表空；97条可见逻辑响应的model字段也一致。但C09出现一次model_escalation，其物理路由不公开，所以不能声称已经证明全部底层尝试的模型与次数。

## C06：生成器和自检共享了错误的格式假设

冻结题面明确要求schedule.json包含`tasks`数组，每项有id/start/end，并有makespan和critical_path。实际输出是`{"schedule":[...],"makespan":9,"critical_path":["A","B","D","E"]}`，缺少tasks。

算法结果正确；原checker读取tasks时KeyError，原判与复核都保持FAIL。模型生成的verify_schedule.py:18-19也检查并读取schedule，自检只证明它的格式假设内部一致。此前.68同题PASS，说明本轮发生了结果退化；单trial不证明某个.69提交是原因。

第一性原理是验收预期应来自用户要求，不能来自生成器自己的假设。建议在现有loop的最后一次验证中，分别核对题面要求的字段/文件名/格式和算法条件，发现差异再由原loop修正。无需按C06特判，也不新增每文件分类器、运行状态或审批。已登记 [OS #3533](https://github.com/aihuanxi/huanxios_individual/issues/3533)，本轮未启动源码修复或补试。

## C09：慢点在模型区间，恢复原因仍不可见

| C09第二轮 | .68 | .69 |
|---|---:|---:|
| 对应回复延迟/秒 | 118.635 | 172.812 |
| 逻辑模型响应/工具调用 | 11/13 | 12/11 |
| 可见输出token | 10626 | 9547 |
| 模型区间合计/秒 | 109.584 | 162.907 |
| 工具区间合计/秒 | 4.869 | 3.732 |

.69第9个逻辑模型区间为85.177秒，结束前有sequence121 `model_fallback / model_escalation`事件。公开详情仅有类别/状态/身份/payloadHash，缺from/to模型、物理attempt数量和失败原因；前后可见逻辑模型仍为Flash1017。不能由fallback=[]推断没有重试，也不能归因于供应商、框架排队或实际换模。

轨迹还包含有效纠错：自产测试先误排ID顺序，后续修正并复验；不能把这些动作当作无用重复。建议先从既有调用台账补齐attempt身份、实际provider/model、起止/首字节/流式阶段和恢复原因，再决定如何减少等待。不新建第二事实库，不用总时限强行停止正常loop。

## 仍未解决的公开读取与范围问题

- [OS #3518](https://github.com/aihuanxi/huanxios_individual/issues/3518)：.69于09:23:07.792562Z首次正式fullResultRef分页读取仍返回503。保留原件后，经既有无offset详情接口完整取回85条结果；补收成功不等于分页通过。修复落点仍是现有HTTP入口→projection门面→底层的参数转发，以及真实入口回归。
- .69有12条显式/tmp命令，涉及C02/C03/C08/C09；.68为15条/7题。它是字面命令观察，不是完整系统调用审计。继续将备份、验证脚本和临时文件限定在任务明确目录内，不改变专属OS的文件访问政策或增加路径审批。

## 步骤、用量和覆盖的边界

.69全部85次原生工具都是shell。没有观察到显式compaction、capability_search/doc2query、call_tool或Skill加载；群聊、渠道附件和TaskFlow/QA未被本题集实际验收。不能将这些机制在.69源码中出现当作本轮通过。具体覆盖见该run的normalized/mechanism-coverage.json。

参数覆盖：.68为93 available/7 partial，.69为77 available/8 partial；两轮都没有完全缺失参数，partial是否实际截断未知。普通详情返回相同预览和源hash，不能自动升级为全文完整。结果覆盖分别为100/100和85/85完整。

同口径可见逻辑响应token：.68输入2016918/输出73016；.69输入1825359/输出67358，分别减少约9.5%/7.7%。它们不代表完整物理请求或实际账单。模型和工具区间可能重叠，不相减当精确耗时分摊。

本轮22项准备/执行/采集/回收阶段另存setup-timeline，含安装前wheel选择脚本误判及修正、分页首次失败和只读补收；不并入用户回复延迟，不抹掉准备错误。

## 版本与证据

正式source `408c787c51cf7539caf1464a719b88e5b93c079f`；Eval沿.68的 `28db1d8f21815927e27f501bc14e504b1e57b2f9`；公开查询Schema相同，窄response-only适配字节相同，driver仅run ID变化。签名索引/日志和安装包完整性已核验，前后版本/模型/配置一致。实例已正常停止并删除，独立GET确认provider404。

Run：`20261108-huanxi-0.8.14.69-framework-tools-t1`，原始归档SHA256 `c231c563f9cf3ec69afbfdec0ee0242494610b24b0921ec51376f6f512c6ea43`。参数规范化曾把partial误升级，已在首次对外发布前纠正；旧临时manifest仅留hash、无字节快照，此缺口记在audits/20261108-os69-input-availability-revision/revision-receipt.json。原始归档未改，最终manifest为 `313df6c3a0edd72981bfcc3866d54063b8cec9ba3a35ee853dd14d3e18649174`。

具体动作、原始参数/结果和调用身份保存在run的私有normalized/raw；可分享包含逐输入/模型/工具时间线、availability、题级内容差异和准备阶段数据。下一步设计优先讨论C06的验收来源，其次是公开读取链和模型恢复事实；本轮没有为得到更好结果追加试次。