BootInsight：面向 openKylin 的启动性能分析与安全优化闭环

对应赛题：openKylin 操作系统启动性能分析与优化

提交版核心结论： BootInsight 在 openKylin 2.0 SP2 实机完成 10+10 冷启动验证，将用户真实感知的图形登录就绪时间中位数从 7.705s 降低至 6.560s（缩短 1.145s，提升 14.9%），同时保持图形登录、网络、声音、输入法和桌面功能正常。

README 导航

• 为什么做： 启动优化从经验调参转向可信工程闭环
• 创新在哪里： 关键路径分析、真实可用状态测量、AI+安全解耦、事务化优化
• 效果如何： 10+10 Benchmark 与 Final Gate 证明收益
• 如何保证可靠： 审核、回滚、功能合同和证据链

项目定位（

BootInsight 是一套面向 openKylin 的智能启动性能分析与安全优化闭环平台，通过启动拓扑分析、AI 辅助诊断、独立安全审核、事务化执行和自动化 Benchmark，实现“发现瓶颈 → 安全优化 → 数据证明 → 可恢复”的完整工程流程。

项目核心价值

BootInsight 的核心贡献不是单纯减少某几个 systemd 服务耗时，而是建立了一套可信启动优化方法：

• 发现可信：结合启动关键链、依赖拓扑和用户可用状态，而不是仅依据服务耗时排序；
• 优化可信：AI 只生成候选方案，不能直接修改系统，所有动作经过独立安全审核；
• 结果可信：通过多轮冷启动、Boot ID 校验、功能合同和 Final Gate 证明优化收益；
• 过程可信：所有修改具备事务记录、失败恢复和回滚能力。

与传统“关闭慢服务”的优化脚本相比，BootInsight 更接近一个面向国产桌面 Linux 的启动性能工程平台。

项目总体架构

BootInsight 采用“采集 → 分析 → 决策 → 执行 → 验证”的闭环架构，将启动性能优化从经验调参转变为可验证工程流程。

                         BootInsight
                              │
                              ▼
┌─────────────────────────────────────────────┐
│                 数据采集层                    │
│ systemd / journal / critical-chain / probes │
│ 启动时间、依赖关系、用户可用状态                 │
└──────────────────────┬──────────────────────┘
                       ▼
┌─────────────────────────────────────────────┐
│                 智能分析层                   │
│ AI Agent + 启动拓扑分析 + 异常诊断             │
│ 生成候选优化方案与证据解释                      │
└──────────────────────┬──────────────────────┘
                       ▼
┌─────────────────────────────────────────────┐
│                 安全决策层                    │
│ 独立风险审核 / 保护名单 / 依赖检查               │
│ 防止错误优化直接影响系统                        │
└──────────────────────┬──────────────────────┘
                       ▼
┌─────────────────────────────────────────────┐
│                 执行验证层                    │
│ Plan / Apply / 回滚 / Benchmark / Final Gate │
│ 用数据证明优化效果                             │
└─────────────────────────────────────────────┘

该架构的核心思想：AI 负责发现可能性，安全模块负责可信性，Benchmark 负责证明结果。

---

与传统启动优化方案对比

能力维度	传统人工优化	简单脚本优化	BootInsight
瓶颈发现方式	经验判断	服务耗时排序	关键路径+依赖拓扑分析
用户体验衡量	人工观察	单一启动时间	图形登录/桌面状态合同
AI 使用方式	无	无	Agent 辅助分析，不直接执行
风险控制	依赖操作者经验	较弱	独立安全审核+保护策略
修改方式	手工操作	直接修改配置	事务化 Plan/Apply
效果证明	主观描述	单次测试	多轮 Benchmark+证据门禁
故障恢复	人工恢复	通常缺失	自动回滚与事务记录

因此，BootInsight 的核心区别不是“优化更多服务”，而是建立了一套可信启动优化闭环。

---

项目完成度概览

当前版本已完成从分析到验证的完整工程链路：

功能模块	完成状态
启动数据采集	✅ 已完成
systemd 关键路径分析	✅ 已完成
用户真实可用状态探针	✅ 已完成
AI Agent 候选分析	✅ 已完成
独立安全审核模块	✅ 已完成
优化 Plan 生成	✅ 已完成
事务化 Apply 执行	✅ 已完成
自动回滚机制	✅ 已完成
多轮冷启动 Benchmark	✅ 已完成
功能回归检查	✅ 已完成
公开证据脱敏与 Final Gate	✅ 已完成

完成度总结：BootInsight 已形成“分析、决策、执行、验证、恢复”的完整启动优化工程闭环，而非单点优化工具。

---

三个关键点

	关键点
1	创新点	将启动关键路径分析、真实用户可用状态探针、AI Agent、安全准入和事务回滚组合为完整闭环，而不是简单关闭慢服务。
2	效果	openKylin 2.0 SP2 实机完成 10+10 冷启动 Benchmark，通过 Boot ID、多轮统计、功能检查和 Final Gate 验证。
3	安全性	AI 不直接修改系统，所有优化必须经过独立安全审核、人工确认、实时条件检查和事务回滚机制。

---

指标达成与核心创新

1. 赛题目标与实际效果

BootInsight 围绕“降低启动耗时、保证系统可用、提供可验证证据”的赛题目标完成正式实机验证。

在 openKylin 2.0 SP2 实机上完成 10 Before + 10 After 冷启动 Benchmark，共 20 轮独立 Boot ID 样本：

核心指标	优化前中位数	优化后中位数	达成效果
Kernel→userspace 完成	7.771s	6.616s	缩短 1.155s（14.9%）
Kernel→graphical.target	7.681s	6.501s	缩短 1.180s（15.4%）
Kernel→图形登录真正就绪	7.705s	6.560s	缩短 1.145s（14.9%）
图形登录、网络、声音、输入法、桌面功能	正常	正常	20 轮全部通过
优化事务回滚能力	-	-	3 项执行成功，0 项错误

最终结论： BootInsight 在不关闭图形登录、不破坏桌面体验的情况下，将用户真正感知的图形登录就绪时间中位数缩短 1.145 秒（14.9%）。20 轮测试全部通过功能检查和证据门禁，证明优化收益具有可复现性。

注：项目对收益采用保守表述。桌面阶段未出现稳定统计改善，因此不宣称整体桌面启动加速；跨发行版验证用于证明闭环迁移和异常处理能力，不替代正式 10+10 性能结论。

2. 核心创新点

与传统“根据 blame 排名关闭慢服务”的启动优化方式不同，BootInsight 的创新集中在以下五个方面：

1. 启动关键路径拓扑分析创新
   • 不只统计服务耗时，而是结合 critical-chain、依赖关系、target、socket 和 D-Bus 再激活关系，寻找真正影响用户启动体验的因素。
2. 用户真实可用状态测量创新
   • 不将 graphical.target 简单等同于启动完成，而是通过自动探针测量图形登录和桌面真正可用状态。
3. AI Agent 与安全执行解耦创新
   • AI Agent 只负责基于本机证据发现候选方案；独立安全审核模块重新判断风险，避免模型建议直接修改系统。
4. 事务化优化与自动回滚创新
   • 所有优化经过 Plan、Apply、验证、回滚闭环管理，支持失败恢复和全过程审计。
5. 证据驱动的可复现实验创新
   • 通过多轮冷启动、Boot ID 校验、状态合同、功能检查和 Final Gate，使优化效果能够被复核，而不是依赖人工体验描述。

BootInsight 解决的不是“找出几个慢服务并手工关闭”，而是把 启动采集、关键路径分析、AI 优化提案、独立安全审核、事务化执行、桌面可用性测量、Before/After 统计和一键回滚 串成一套可复现工具链。

项目覆盖赛题要求的两个用户可感知阶段：

1. 内核启动完成 → 图形登录就绪；
2. 用户登录 → 桌面环境可用。

系统只在图形登录、网络、声音、输入法、桌面核心组件等功能合同通过后记录就绪时间。优化建议不能绕过模块 B 的独立检查和人工审核，执行后还要通过功能验收与证据门禁。因此，BootInsight 的目标是：

在不破坏 openKylin 默认客户端体验的前提下，找出真正影响启动的服务和依赖，安全地实施优化，并用可审计证据证明结果。

一、正式实机 Benchmark：10+10 已通过最终门禁

当前里程碑（2026-07-27）： BootInsight 已在一台运行 openKylin 2.0 SP2（Linux 6.6.0-19-generic，x86_64） 的实机上完成 10 Before + 10 After 正式 Benchmark。20 轮均为独立重启并具有唯一 Boot ID，使用同一机器、系统、Git 提交、规则库和自动状态合同； Final Gate 与私有 raw-journal 多轮审计均为 PASS。

正式多轮结果

下表以中位数为主指标；完整报告同时给出 Mean、Std、P95、Min 和 Max。

赛题相关指标	Before median	After median	变化
整机总启动（含不计分的固件/引导）	19.218s	18.053s	缩短 1.165s（6.1%）
Kernel→userspace 完成	7.771s	6.616s	缩短 1.155s（14.9%）
Kernel→graphical.target 代理	7.681s	6.501s	缩短 1.180s（15.4%）
Kernel→图形登录状态合同就绪	7.705s	6.560s	缩短 1.145s（14.9%）
Kernel→桌面服务状态合同就绪	13.560s	13.540s	缩短 0.020s（0.1%）

graphical.target 只是 systemd 代理里程碑，正式结论还同时报告自动探针测得的图形登录和桌面状态合同。图形登录端点中位数缩短 1.145s，且 Before/After 标准差分别为 0.128s 和 0.162s；桌面端点中位数基本不变，After 标准差升至 0.913s，因此本项目不把桌面阶段表述为稳定改善。Firmware 和 Boot loader 不计入赛题成绩，二者在两组样本中基本保持不变。

Agent、安全审核与实际执行

本次正式实验重新基于 Before 10 证据运行 Agent。Agent 提出的 5 个新规则中，4 个因 no_critical_dependency 与当前图形依赖证据矛盾被模块 B 拒绝，samba-ad-dc.service 的永久关闭提案被降为 report_only；不存在 admissible 或 review_required 项，人工审核结论为 none，没有把任何新模型提案写入规则库。

随后，完整规则 Plan 只对现有已审核规则库执行实时检查，并事务化应用 3 项操作：

实际执行项	实时条件依据	执行结果
Docker/containerd 延后 30 秒	Docker socket、Swarm、containerd 工作负载、依赖和容器恢复检查通过	成功
关闭 biometric-authentication.service	未检测到生物识别硬件，启动日志记录 0 个 HID、0 个 NFC 设备	成功
关闭 cups.service	CUPS 与 USB 探测均未发现打印机，并经人工确认	成功

蓝牙适配器和 5 个 hwmon 传感器在实时检查中存在，因此 bluetooth.service 与 lm-sensors.service 被自动保留。事务状态为 succeeded，成功 3 项、错误 0 项。After 的 10 轮私有审计均确认 Docker/containerd 已退出 graphical.target 关键链；服务 blame 仅用于定位候选来源，端到端收益仍以上述多轮状态合同为准。

数据质量、功能与证据门禁

验证项	结果
Before/After 样本量	PASS，10+10
20 轮独立 Boot ID、环境一致性、告警和端点完整性	PASS
图形登录、桌面状态合同及每轮 smoke test	PASS
公开/私有 JSON 数量与逐轮配对	PASS，10 对
私有 raw-journal 多轮审计	PASS，10 对全部通过，0 blocker
Apply 事务	PASS，3 项成功、0 错误
Final Gate	PASS，问题数 0

本次可公开的 20 份脱敏记录、代表轮次报告、统计图表和审计结论见：

• openKylin 正式 10+10 Benchmark 公开证据
• 正式 Benchmark 完整统计
• 私有证据配对审计结论
• 最终统计门禁

完整原始证据仍只保存在本地：

validation/archives/formal-benchmark-final-20260727T145800Z/

原始归档包含 Before/After 私有记录、自动探针、smoke test、完整 journal、Agent 审计轨迹、执行计划、事务结果和回滚脚本，因此已通过 .gitignore 排除。公开证据包只使用脱敏 runs_public 重新生成报告与图表，并仅保留无敏感路径的门禁摘要，不包含真实主机名、用户路径、IP、MAC、原始 Boot ID 或 raw journal。

二、跨发行版 One Round 泛化与异常闭环

补充验证（2026-07-29）： 同一套 One Round 状态机又在 Ubuntu 24.04.4 LTS、Linux 6.8、x86_64 云主机上完成了 “采集—Agent 分析—安全审核—Plan/Apply—After—复盘—回滚—归档” 全流程，并在更新后的 openKylin 环境再次完整跑通。以下均为 1+1 单轮工程 证据，只用于证明流程迁移、异常发现和安全收尾能力，不替代第一节的正式 10+10 性能结论。

两个发行版的最新单轮观测

环境	Kernel→userspace 完成	Kernel→graphical.target	Kernel→图形登录合同	Kernel→桌面合同
openKylin 2.0 SP2 / 自动登录	5.735s → 4.684s，缩短 1.051s	5.633s → 4.594s，缩短 1.039s	5.620s → 4.790s，缩短 0.830s	10.770s → 10.650s，缩短 0.120s
Ubuntu 24.04.4 LTS / 手动登录	10.673s → 9.248s，缩短 1.425s	10.076s → 8.803s，缩短 1.273s	10.070s → 8.840s，缩短 1.230s	证据不足，按设计排除

openKylin 使用 LightDM 自动登录，桌面探针将 UKUI 会话、桌面、面板、通知区、 session D-Bus、网络、音频和输入法绑定到同一 UID，因此桌面端点可比较。Ubuntu 云主机未配置可重复自动登录；人工登录时间会引入操作者延迟，所以系统仍采集 systemd 与图形登录状态合同，但把完整桌面端点明确标记为 manual_login_uncontrolled，不生成虚假的 Before/After 差值。

Ubuntu 云主机异常基线与回归检测案例

在第一次 Ubuntu 24.04 云主机泛化实验中，Before 整机启动时间为 131.204s，应用优化后增至 250.031s，回归 118.827s；Kernel→ graphical.target 则由 130.516s 增至 249.506s，回归 118.990s。 虽然 Before/After 各只有一轮，不能形成统计性能结论，但这一变化远超正常启动 波动，足以判定本轮必须回滚。

项目没有因异常数据或负收益崩溃。采集产物仍被完整保留，Benchmark 明确输出 回归，Agent 复盘继续读取启动记录和关键链证据，将核心异常定位到 systemd-networkd-wait-online.service 的约 120 秒等待，并提出 Docker defer 可能改变 network-online.target 激活时序的假设。由于 Agent 坚持只读、非提权运行，无法读取完整系统日志时，它把具体依赖来源记录为证据缺口， 没有擅自修改网络或 systemd 配置。随后状态机仍可进入人工回滚、重启验证、私有 归档和公开脱敏步骤，形成完整失败闭环。

人工排查进一步确认，云主机的 eth0 实际由 NetworkManager 管理，异常启动中 却同时出现了 NetworkManager-wait-online 与 systemd-networkd-wait-online 两套等待路径；后者约等待 120 秒后失败。 现有证据支持“冗余 wait-online 是直接阻塞点”，但受当时 journal 权限限制， Docker defer 如何使这段等待进入更晚阶段仍保留为待验证因果，不能写成确定副作用。 管理员屏蔽冗余的 systemd-networkd-wait-online 后，整机启动恢复至 10.893s，graphical.target 在 8.040s 到达；随后重新执行的成功 One Round 也回到约 10 秒基线并完成全部阶段。

该失败包生成于手动登录可比性修复之前，其中的桌面端点可能混入 SSH 登录时刻， 因此不参与任何性能或泛化结论；它仅作为“显著回归能够被发现、解释、回滚并保留” 的异常诊断样例。该案例同时暴露出 Docker defer 面对混合网络管理配置时需要 更严格的 wait-online 安全门禁。由此，Ubuntu 证据支持的是方法、Agent 诊断 和安全闭环的跨发行版泛化，而不是宣称 1+1 样本已经证明 Ubuntu 存在稳定 固定收益。

公开证据：

• Ubuntu 成功 One Round 公开包
• Ubuntu 成功 One Round 完整统计
• Ubuntu 异常回归公开包
• Ubuntu 异常回归完整统计
• 最新 openKylin One Round 公开包
• 最新 openKylin One Round 完整统计

三、我们做了什么

赛题问题	BootInsight 的实现
启动耗时不透明	采集 systemd-analyze、blame、critical-chain、依赖关系和 journal，生成 Markdown、HTML 与图表报告
graphical.target 不等于“用户可用”	使用系统级探针自动测量“图形登录就绪”和“桌面可用”两个真实状态合同
服务优化容易破坏系统	模块 B 对服务类型、依赖拓扑、硬件条件、保护名单和风险等级进行独立审核
不同机器的服务组合不同，静态规则难以覆盖	Agent 基于本机启动证据动态发现候选、解释原因并提出优化；安全模块再独立审核
应用优化后难以恢复	Plan 与当前 BootRecord、规则哈希绑定；Apply 逐项复检并生成独立事务和回滚脚本
单次启动数据波动大	支持多轮独立冷启动，统计 mean、median、std、P95、收益比例并选择代表轮次
结果难以复核	私有完整证据与公开脱敏记录分离，最终门禁检查样本数、文件配对、端点合同和功能回归

整个闭环如下：

flowchart LR
    A["Before 冷启动采集"] --> B["Analyzer
时序、关键链、依赖"]
    B --> C["AI Agent
自主提出优化与风险"]
    C --> D["模块 B
独立准入与风险上调"]
    D --> E["人工审核
普通 / 增强审核"]
    E --> F["Plan
实时检查与哈希绑定"]
    F --> G["Apply
事务化执行"]
    G --> H["After 冷启动采集"]
    H --> I["Benchmark + 功能审计"]
    I --> J["回滚并验证"]

四、核心创新点（与传统方案区别）

本项目的创新设计紧贴赛题鼓励的四个方向，同时重点解决传统 Linux 启动优化中的三个痛点：定位不准确、优化不安全、效果不可证明。依赖图建模、启动时序分析、自动化测试框架和 AI/Agent 辅助分析。我们不是把一次性的调参脚本包装成工具，而是针对传统 Linux 启动优化中“只看耗时排名、依赖人工经验、测试难复现、修改风险高”等问题，设计了一套可分析、可执行、可验证、可回滚的工程闭环。

1. 依赖图建模：从“耗时排名”转向“启动拓扑”

传统优化通常根据 systemd-analyze blame 排序，优先处理耗时最长的服务。但一个服务耗时长，不代表它位于启动关键路径；盲目关闭还可能破坏图形登录或被其他依赖重新拉起。

BootInsight 同时采集 critical-chain、graphical.target 依赖集合、单元前后序关系和反向依赖，把服务放回启动拓扑中分析：

• 判断服务是否位于关键链或图形启动依赖集合；
• 区分“自身耗时较长”和“真正阻塞用户可用端点”；
• 识别服务被 target、socket、timer 或 D-Bus 再次激活的可能；
• 在 Plan 和 Apply 阶段依据实时拓扑重新验证优化条件。

因此，优化对象的选择不再只依赖单一耗时数字，而是结合“耗时、路径位置、依赖关系和实际用途”综合判断。

2. 启动时序分析：测量“用户真正可用”的时刻

传统测试常把 graphical.target 到达时间或人工看到桌面的时刻当作启动完成：前者不能证明界面和基础功能已经可用，后者又容易受到观察和操作误差影响。

BootInsight 设计了系统级自动状态探针，以 0.1 秒间隔检查条件，并在合同首次全部成立时读取 /proc/uptime：

• 图形登录合同：显示管理器、显示服务器、登录界面或图形会话、系统 D-Bus、NetworkManager 和输入设备；
• 桌面可用合同：图形会话、桌面、面板、通知区、用户 D-Bus、网络、音频和输入法。

探针还会先检测键盘、鼠标等硬件是否存在。机器没有某类设备时，该条件记为 SKIP，不会把“硬件不存在”误判为“桌面未就绪”。这使两个赛题阶段都有自动、统一、可复现的计时终点。

3. 自动化测试框架：把一次实验变成可复现状态机

传统启动优化往往由多条零散命令组成，测试者需要手工记住当前处于优化前、应用后还是回滚后，容易出现重复采集、同一次启动充当多轮样本或忘记回滚等问题。

BootInsight 围绕 scripts/real_machine_one_round.sh 设计了完整自动化测试状态机：

prepare → before → analyze → review-rules → plan → apply
        → after → evaluate → rollback → verify → finalize

框架自动完成或约束以下工作：

• 安装系统级探针并执行实机预检；
• 为每轮采集核对唯一 Boot ID，拒绝覆盖已有证据；
• 串联 Before、Agent 分析、安全审核、Apply、After 和回滚验证；
• 对错误阶段、无效端点、缺失证据和未完成事务自动失败关闭；
• 用 Boot ID 强制检查三次重启边界，拒绝把同一次启动当作不同阶段；
• 自动生成报告、Benchmark、审计结果和可恢复私有归档；
• 只从私有归档重新脱敏生成公开包，随后清空采集、状态和事务工作目录；
• 支持 SSH 命令行与本地 Web 控制端两种演示入口。

在正式实验中，同一套采集与门禁已完成 10 轮 Before 和 10 轮 After，统一统计均值、中位数、标准差和 P95，降低偶然波动对结论的影响。

4. AI/Agent 辅助分析：从静态规则匹配转向动态诊断

传统优化代码通常维护一张固定服务名单：开发者预先规定哪些服务可以关闭、延迟或保留。这种方式易解释，但难以覆盖不同机器、不同桌面环境和用户安装的新服务，也无法主动调查异常日志和实际依赖。

BootInsight 引入只读 AI Agent，让模型基于当前机器的真实启动证据动态分析：

• 从完整服务观测清单中自主发现优化候选，而不局限于预设服务名；
• 综合服务耗时、关键路径、依赖关系、启用状态和 journal 异常；
• 必要时调用受限的只读工具继续查询单元和日志；
• 输出具体优化动作、风险等级、理由和可核验的证据引用。

Agent 的价值是扩大分析范围并提供解释，而不是代替安全策略。模型不能直接执行系统命令；离线规则生成器仍可在无模型环境中作为确定性分析工具。

5. 工程安全创新：Agent 提议、独立审核、人工确认、事务回滚

AI 分析具有探索性，而操作系统优化要求确定性和可恢复性。为协调两者，BootInsight 设计了 Agent 与安全执行模块相互独立的 Human-in-the-loop 架构：

Agent 提议 → 模块 B 独立计算风险 → 人工选择 → Plan 只读检查
          → Apply 实时复检 → 事务记录 → After 功能审计 → 回滚验证

模块 B 不直接采信模型风险，而是计算：

effective_risk = max(agent_risk, policy_risk)

系统会保护显示管理器、D-Bus、NetworkManager 等关键能力；高风险动作需要增强审核和二次确认；Plan 与 BootRecord、规则哈希绑定；每次 Apply 都生成独立执行记录和 rollback.sh。最终结果还要经过端点合同、功能回归、多轮统计和证据门禁，避免以牺牲桌面体验换取表面启动时间。

五、评审要点与赛题对应

评分项	可直接检查的实现
启动性能收益	analyzer/、benchmark/、两个 readiness 端点及 Before/After 报告
功能正确性与稳定性	probes/、validation/smoke_test.py、证据审计和完整回滚验证
分析深度与创新性	依赖拓扑、关键路径、自动状态合同、AI Agent 与独立安全模块
openKylin 适配与泛化	openKylin 正式 10+10、Ubuntu 24.04 云主机 One Round、手动登录不可比端点隔离，以及异常回归回滚证据
工程质量与复现性	十一阶段状态机、SSH/Web 双入口、事务日志、脱敏、自动测试和完整文档

六、三分钟快速检查

1. 安装依赖并运行测试

要求 Python 3.8 或更高版本：

cd BootInsight-complete
python3 -m pip install -r requirements.txt
python3 -m pip install -r requirements-dev.txt
python3 -m pytest -q

当前版本包含 Analyzer、Agent、安全准入、Optimizer、探针、Benchmark、Web API 和回滚流程的自动化回归测试。

2. 使用脱敏预实验数据离线生成报告

这一步不修改系统，也不需要 API Key：

python3 -m analyzer.report \
  --input data/real_run/before_optimize_boot.json \
  --output-dir /tmp/bootinsight-before

python3 -m benchmark.statistics \
  --before data/real_run/before_optimize_boot.json \
  --after data/real_run/after_optimize_boot.json \
  --output-dir /tmp/bootinsight-benchmark

python3 -m ai.agent \
  --before data/real_run/before_optimize_boot.json \
  --after data/real_run/after_optimize_boot.json \
  --provider deterministic

七、openKylin 实机单轮闭环

单轮流程用于演示工程闭环是否完整，包含 1 Before + 1 After。它不能代替正式多轮比赛数据。

运行前提

• openKylin x86 真机或虚拟机，启用真实图形桌面；
• 自动登录时采集可比的完整桌面端点；人工登录仍可运行 One Round， 但桌面端点显示“证据不足”并排除；
• 可通过 SSH 登录，且测试用户具备 sudo 权限；
• 已准备系统快照、救援入口或其他恢复手段；
• 项目路径不能包含空格；
• 完整 Agent 分析需要 DeepSeek API Key；密钥只注入当前终端，不写入仓库。

主脚本始终以普通用户运行，不要执行 sudo bash scripts/real_machine_one_round.sh ...。需要提权时，脚本会在明确步骤中请求。

1. 安装依赖

cd ~/BootInsight-complete
python3 -m pip install --user -r requirements.txt
python3 -m pip install --user -r requirements-dev.txt

2. Prepare：预检并安装自动探针

bash scripts/real_machine_one_round.sh prepare
sudo reboot

重启并等待 SSH 恢复后继续。

3. Before：采集优化前证据

cd ~/BootInsight-complete
bash scripts/real_machine_one_round.sh before

只有出现 [PASS] 且没有 [INVALID RUN] 才能进入下一阶段。

4. Analyze：Agent 提案，模块 B 独立准入

read -rsp "DeepSeek API Key: " DEEPSEEK_API_KEY
echo
export DEEPSEEK_API_KEY

bash scripts/real_machine_one_round.sh analyze

Agent 只能调用白名单内的只读工具。模型输出后，模块 B 自动生成独立的 RuleAdmissionSet。

5. Review Rules：人工选择提案

bash scripts/real_machine_one_round.sh review-rules

• 输入 all：批准全部普通项；
• 输入逗号分隔的提案 ID：批准指定普通项或显式选择增强审核项；
• 输入 none：不新增规则，仍可继续检查现有规则库；
• 高风险项还需要输入 APPROVE-HIGH-RISK。

6. Plan：生成只读执行计划

bash scripts/real_machine_one_round.sh plan

Plan 会对完整 rules.yaml 做实时条件检查，并绑定当前记录和规则哈希，不修改 systemd。

7. Apply：事务化应用优化

bash scripts/real_machine_one_round.sh apply
sudo reboot

Apply 会再次检查实时状态并要求人工确认。执行成功后必须重启，不能直接采集 After。

8. After：采集优化后证据

cd ~/BootInsight-complete
bash scripts/real_machine_one_round.sh after

Before 和 After 必须使用相同机器、用户、内核、网络条件和冷启动方式。

9. Evaluate：构建结果并审计

重启后重新注入 API Key，再执行：

bash scripts/real_machine_one_round.sh evaluate

该阶段生成 Benchmark、功能审计、门禁结果和 Agent 复盘。服务的 blame 耗时仅用于定位收益来源，正式收益以端点时间为准。

10. Rollback / Verify：恢复并验证

bash scripts/real_machine_one_round.sh rollback
sudo reboot

# 重启并等待 SSH 恢复
cd ~/BootInsight-complete
bash scripts/real_machine_one_round.sh verify
bash scripts/real_machine_one_round.sh status

看到阶段 completed 表示回滚验证已经完成，但还需要归档收尾。

11. Finalize：归档、公开并清空工作目录

PUBLIC_ID="one-round-openkylin-$(date -u +%Y%m%dT%H%M%SZ)"
bash scripts/real_machine_one_round.sh finalize "$PUBLIC_ID"
# 输入 FINALIZE-ONE-ROUND

完整私有数据首先移动到 validation/archives/one-round-final-<UTC>/，公开包随后只从该归档中的私有 BootRecord 重新脱敏生成到 evidence/public/$PUBLIC_ID/。完成后，本轮规则基线恢复， 采集目录、单轮状态和事务工作目录被清空，状态重新成为 uninitialized。

若私有归档已经移动，但公开包生成临时失败，可在修复环境后恢复同一收尾：

bash scripts/archive_one_round.sh resume "$PUBLIC_ID"

八、正式比赛数据采集

正式结果默认要求至少 10 轮独立 Before 和 10 轮独立 After。每轮必须对应一次独立冷启动和唯一 Boot ID，不能在同一次启动中重复执行采集脚本充当多轮样本。

正式流程不是“固定规则直接 Apply”。10 轮 Before 后仍需依次完成只读 Agent 分析、模块 B 独立准入、人工判断、完整规则库 Plan 和事务化 Apply。候选和执行项 以本机证据为准，不预设服务名单。完整命令见 正式 Benchmark 操作手册。

探针安装后，每次重启只采集一轮：

# 第一次优化前冷启动
bash scripts/finalize_run.sh before 1

# 再次重启后
bash scripts/finalize_run.sh before 2

# 按相同方式继续至 before 10

应用经审核的同一份优化方案后，以相同条件采集：

bash scripts/finalize_run.sh after 1
# 每轮重启一次，继续至 after 10

全部样本完成后构建最终结果：

bash scripts/build_final_results.sh

只有样本数、数据质量、公开/私有文件配对和全部私有证据审计通过时，构建才以 返回码 0 结束。evidence/final/ 是回滚和归档前的工作结果；回滚验证通过后运行：

bash scripts/archive_formal_benchmark.sh finalize <PUBLIC_ID>

脚本先把本轮完整数据移动到 validation/archives/，再只从归档私有记录重新脱敏并 生成 evidence/public/<PUBLIC_ID>/，最后清空正式工作目录。公开发布不读取工作目录 中的 runs_public 或 evidence/final。

九、计时口径

指标	含义	用途
machine_total	systemd 报告的整机时间	诊断参考
contest_systemd_complete	Kernel + Initrd + Userspace	systemd 完成口径
kernel_to_graphical_target	Kernel 到 graphical.target	systemd 代理指标，不代表桌面可用
kernel_to_session_ready	Kernel 到图形登录状态合同成立	赛题“图形登录就绪”核心指标
kernel_to_desktop_ready	Kernel 到桌面状态合同成立	赛题“桌面可用”核心指标

BIOS/UEFI、Firmware、Boot loader 和 GRUB 菜单等待不计入正式成绩。报告不会将多个服务的 blame 耗时直接相加为端到端收益。

十、结果和审计文件在哪里

产物	默认位置
正式实验中的临时私有/公开记录	benchmark/runs_{private,public}/{before,after}/
正式实验中的逐轮证据	benchmark/evidence/{before,after}/run_*/
单轮状态、准入结果与计划路径	validation/outputs/real-machine-one-round/
Agent 运行轨迹与提案	ai/runs/
Optimizer 事务、日志和回滚脚本	optimizer/transactions/<transaction_id>/
完成后的正式私有归档	validation/archives/formal-benchmark-final-<UTC>/
从私有归档重新生成的公开证据	evidence/public/<PUBLIC_ID>/

正式归档状态：

bash scripts/archive_formal_benchmark.sh status

单轮演示中断或完成回滚验证后，可使用可恢复归档工具：

bash scripts/reset_one_round_demo.sh status
bash scripts/reset_one_round_demo.sh auto

# 完整归档旧产物并回到 uninitialized
bash scripts/reset_one_round_demo.sh fresh

脚本把旧数据移动到 validation/archives/，不会直接删除证据，也不会绕过未完成的事务回滚。

十一、SSH Web 可视化控制端

web/ 是运行在操作者 Windows 电脑上的本地控制界面。它通过 OpenSSH 调用实机中的固定阶段命令，提供：

• 十一阶段导航和状态门禁；
• SSH 实时终端及 sudo/高风险确认输入；
• Before/After 指标对比；
• 普通提案与增强审核提案展示；
• 报告文件导航和重启后重连；
• 各阶段自动、原子刷新 evidence/current_run/，前端实时展示本轮脱敏报告和 PNG 图表。

真实 SSH 地址、用户名和私钥路径只保存在未提交的 web/config.json：

cd web
Copy-Item config.example.json config.json
.\run.bat

浏览器访问 http://127.0.0.1:8765。Web 端不接受浏览器提交任意 shell，只能执行阶段白名单中的正式脚本。详细说明见 Web 控制端文档。

十一、项目能力边界与工程价值

BootInsight 不简单追求“关闭更多服务”或制造短期启动收益，而强调真实用户体验和系统可靠性的平衡：

• 不把 systemd-analyze blame 排名直接等同于优化目标；
• 不把 graphical.target 简单认为是用户已经可用；
• 不允许 AI 建议直接修改系统状态；
• 不使用单次实验结果宣称性能提升；
• 对无法充分证明收益的优化主动保守处理。

这种设计使 BootInsight 更接近实际操作系统工程场景，可用于发行版优化、企业 Linux 运维和桌面系统性能分析。

十二、项目结构

BootInsight-complete/
├── analyzer/        # systemd 数据采集、解析、关键路径和报告
├── probes/          # 图形登录与桌面 readiness 系统级探针
├── ai/              # Agent、只读工具、结构化提案与审计轨迹
├── optimizer/       # 模块 B、安全准入、规则库、Plan/Apply/回滚
├── validation/      # 冒烟测试、状态快照、证据审计和最终门禁
├── benchmark/       # Before/After 多轮统计、CSV 和图表
├── schemas/         # 版本化 BootRecord、AgentResult 和规则契约
├── scripts/         # 预检、探针安装、单轮闭环和正式结果构建
├── web/             # 本地 SSH Web 控制端
├── tools/           # 脱敏与辅助工具
├── data/real_run/   # 可公开的脱敏预实验数据
├── evidence/        # 最终报告和审计证据
├── docs/            # 赛题说明与实机操作手册
└── tests/           # 单元、契约、安全与流程回归测试

十三、进一步阅读

• 赛题要求与评分细则
• 全程 SSH 单轮闭环测试
• 实机 One Round 完整演示手册
• openKylin 远程实机测试操作手册
• 正式 10+10 Benchmark 操作手册
• Web 控制端说明

---

BootInsight 坚持三个原则：不以关闭关键功能换时间，不以单次数据当结论，不让模型直接修改系统。

---

提交版总结

BootInsight 的核心价值可以概括为：

不是寻找更多可以关闭的服务，而是在保证系统可用性的前提下，找到真正影响用户启动体验的路径，并通过安全执行和可复现实验证明优化效果。

项目形成了从数据采集、智能分析、安全决策、事务执行到 Benchmark 验证的完整闭环：

启动数据
   ↓
关键路径分析
   ↓
AI辅助诊断
   ↓
独立安全审核
   ↓
事务化优化
   ↓
多轮Benchmark证明
   ↓
回滚与审计

这使 BootInsight 区别于一次性优化脚本，成为一个面向 openKylin 的可信启动性能工程平台。