Linux Plumbers Conference 2026 的会议日期为 10 月 5—7 日。本次值得 SRE 关注的内容不只在一个分会场：系统监控、Tracing、Android、eBPF、AI 辅助开发、实时系统和 Live Patching 都讨论了相关问题。会议官网

本文的判断是：在有限的观测预算内保留足够证据，把用户症状连接到系统行为，再把诊断结论交给可验证、可控制的修复流程，是这些议题共同指向的工程目标。 这是本文对不同报告的综合解读。

材料与证据范围：基础篇依据 2026-10-08 核对的 22 项官方议题与摘要；2026-10-09 核读 5 份官方 PDF，并新增 CRIU/RDMA 议题。2026-10-17 增补 LPC 讲者的 IPADS 会后讲义，并用 AgentSight、ActPlane 论文核对实验条件。10 月 21 日核对官方录像入口与 Grafana 发布，补读 Forensic Checkpointing 讲义、Incident-Arena 论文及固定版本验证代码。各来源分别记录发布日期、核验日期和证据范围。

10 月 21 日更新：从可追溯证据，走向受控修复与独立验收

本轮有两项日期明确的新发布，以及两项补充阅读：

• LPC 录像已公布。 官方于 10 月 19 日宣布录像发布；Brendan Gregg、CoreWeave、Meta、drgn + AI 和 Forensic Checkpointing 的直链已补入材料索引。官方公告
• Grafana 补齐调查到候选修复的产品路径。 10 月 20 日，Assistant Watchers 正式可用（GA），Managed Sandboxes 开放公测；重点是证据复用和启动、发布权限的分离，见第 5.5 节。发布汇总
• 补读两种“看似正常、证据却不足”的情形。 Forensic Checkpointing 说明最终快照为何会丢失中间修改；Incident-Arena 用结果与安全双门禁区分指标恢复和有效修复，分别见第 4.4、6.3 节。它们是已有材料的本次新增分析。

本轮判断：优先迁移可核查的调查证据与独立修复验收，将服务恢复、安全约束和修复持续性分别检查。

10 月 17 日更新：把 Agent 自身纳入观测与控制

Yusheng Zheng 于 10 月 16 日在第二届 IPADS 青年学术论坛 Agent Harness 专题分享“与智能体共同演化的可扩展操作系统”。讲者主页 本次核读的 PDF 为 21 页，题名为《Co-evolving OS Infrastructure with Agents through Runtime Extensions》。讲义 PDF

这份材料属于 LPC 讲者的会后相关研究。其 LPC 原议题是与 Hao Sun 合作的 Safely Optimizing eBPF for Hardware and Workloads。它将任务意图与实际 OS 行为、资源消耗、运行时约束连接起来。机制、实验条件和四个开放问题见第 5.4 节。

10 月 9 日更新：五项工程细节与 Slides 直链

本轮更新来自新核读的材料，日期记录阅读时间。官方页面提供的信息尚不足以判定这些附件是否都在过去 24 小时上传。

对 Android / OpenHarmony，优先试验方向是已知故障前置去重与稀有故障统计比较，再用已有 AppFreeze 故障集评测诊断证据是否充分。下文把各项更新并入相应主线。

一、议题地图：22 项内容，六条主线

以下时间均为会议当地时间 Europe/Prague，记录官方排期；现场执行情况与录像状态另行核对。系统监控议程、Tracing 议程、AI 辅助开发议程、Live Patching 议程与总日程用于交叉核对。

这份地图保留初版按 SRE 关联性筛选的 22 项议题；本轮新增的 CRIU/RDMA Checkpoint/Restore 见第 7.3 节。

二、主线一：健康度要能解释用户体验与发布结果

2.1 从单点阈值，转向跨发布阶段的可比较性

Meta 的 slides 区分了绝对健康告警与新旧内核之间的相对健康检查。困难在于新旧版本的主机数量相差多个数量级，crash、stall、lockup 等稀有事件在短窗口内又存在明显的离散性。官方 Slides，p.4、6–12

其处理方法是把“某台主机在某时间窗内是否发生事件”视作 Bernoulli 试验，在主机多、单机事件概率低的条件下使用 Poisson 近似。数据可以按时间、主机或两者分桶；检查方差／均值 φ 是否合理，再拟合成熟内核数据，并把分布换算到新内核的主机规模，以判断新版本是否显著更差。官方 Slides，p.13–17

slides 同时列出适用条件：各桶需要统计可比，新旧版本之间影响事件概率的外因也要处理，例如日内工作负载变化，以及新内核刚上线导致 uptime 较短。官方 Slides，p.18

对 SRE 的启示：灰度阶段比较低频故障，应把样本规模、工作负载、硬件、运行时长和分桶方式纳入判断。迁移到设备端时，先验证这些假设，再选择统计模型与告警阈值。

2.2 内核事件必须连接用户可见结果

小米团队在 Pixel 6、6.18.0-mainline、90 Hz 的指定环境中分析了 40 个 Android 应用，把 lock_contention 与 Perfetto FrameTimeline 关联。作者报告：约 14% 的掉帧可归因于内核锁竞争，且五类热点占锁相关掉帧的 90% 以上，涉及 GPU 驱动、mmap_lock、ZRAM、Binder 分配器和 cgroup 锁。官方摘要

这里最值得迁移的方法是：从用户症状窗口反查关键线程的等待，再定位依赖对象。 但上述比例属于作者报告的特定实验，不应写成所有 Android 设备的普遍结论；事件在时间上重合后，还需通过干预或复现验证因果关系。

Wattson 的议题则把 Perfetto trace 与按 SoC 建模的 CPU 功耗估计用于内核回归测试。官方摘要它补充了一个容易被忽略的质量维度：响应更快的修改也可能增加功耗。这里的功耗是模型估计，应通过硬件仪器测量校准；GPU、TPU/NPU 属于作者提出的扩展方向。

2.3 长时间测量仍不可替代

OSADL QA Farm 的报告强调长期、跨系统可比较的实时延迟测量，并讨论测试场景随 Linux 和硬件演化而调整。官方摘要

本文判断：这与“模型更强，所以过程数据可以无限削减”的想法构成重要制衡。模型可以帮助解释罕见延迟，但测量窗口、测试负载、硬件差异及尾部分布仍需真实采集。评价长尾风险时，应保留测量时长与负载覆盖范围。

三、主线二：观测预算必须同时计算采集、关联、保存和恢复成本

3.1 大型转储暴露的是诊断经济性问题

CoreWeave 的 slides 描述了 2–4 TB 内存的大型节点：默认单线程 makedumpfile 可能耗时 20–60 分钟，恢复速度与故障证据都直接影响运营。官方 Slides，p.2

第 3 页给出了当前运行流程，据此更新初版摘要中的“指纹去重开发中”状态：

1. panic 后进入精简 crash kernel，启用 4 个 CPU。
2. 挂载保存已知 panic 指纹数据库的文件系统，并匹配当前 panic 栈指纹。
3. 命中已知指纹时保存 dmesg，跳过 dump；未知故障使用多线程 makedumpfile 采集后重启。
4. 使用 16 个以上 CPU／线程向对象存储上传 dump。

指纹基于 panic 栈及寄存器值、错误信息等周边数据。AI 根因分析单独讨论；作者在第 6 页指出幻觉仍妨碍将 AI 用于故障分类／去重。第 9 页把 DPU 上经 RDMA 使用 drgn 读取运行内核列为探索，并提出安全性和生产实践问题。官方 Slides，p.3、5–6、9

对 SRE 的启示：先识别已知故障，再选择采集深度，可减少重复转储。设备端实验应同时衡量恢复耗时、指纹误匹配、已知故障变体漏检和保留证据的诊断能力；这些是迁移方案需要验证的指标。

3.2 BPF 快照：把诊断请求变成有界采集

BPF 快照提案以在线内核中的任务、D-state 栈、runqueue、reclaim 和 I/O 状态为对象，探索经过预先约束的内核内遍历与紧凑输出。作者同时把 iterator、helper/kfunc、verifier、输出缓冲和不停机情况下的一致性保证列为讨论问题。官方提案

它提供了值得试验的在线状态采集设计点。截至 2026-10-21，官方页面仍标为未排期、暂无材料，尚无可供本文核读的性能测量正文。

迁移建议：为每种采集器定义最大对象数、耗时、输出字节数及失败行为。达到限额时应报告 truncated、丢弃计数和有效时间区间，让分析器能识别信息缺口。

3.3 小记录不等于小系统成本

Build ID + offset sampling 比较了直接记录文件身份和偏移，与记录虚拟地址后再依赖映射事件完成符号化的取舍；目标包括讨论混合采样方式。官方摘要

栈记录议题则讨论重复栈挤占缓冲区、栈合并及用户态栈的文件关联问题。官方摘要两者共同提醒我们：压缩单条事件，不一定能减少整套证据系统的开销；关联元数据、映射生命周期和重复记录同样占预算。

本文建议的度量口径 是：

1
2
3
4
5
6
7

观测总成本
= 热路径记录
+ 对象身份与关联维护
+ 栈与符号化元数据
+ 缓冲和持久化
+ 故障时采集扰动
+ 离线分析与误判成本

这不是会议提出的统一公式，而是一个便于比较方案的工程记账方式。

3.4 低扰动工具要能进入真正的故障现场

生产 RT tracepoint 议题提出将抢占／IRQ 开关事件从较重的设施中拆开，通过独立配置与 static key 控制启用。官方摘要perf/ftrace 互通议题则尝试复用同一份采集数据，减少为统计分析和时间线分析重复录制。官方摘要

这些工作的共同价值是降低“只能在实验室开启”的门槛。但补丁提案、已排期演讲、内核已合入和发行版可用，是四个不同状态，应分别记录；实际开销需要在目标负载下测量。

四、主线三：比日志数量更重要的是关联键、生命周期和等待关系

4.1 故障报告应有同一次启动的时间线

统一内核故障报告提案关注 dmesg、syslog、devcoredump 和 sysfs 信息分散、采集延迟及环形缓冲区覆盖。它建议在问题发生时自动采集，并在服务端按 session／boot 关联、匹配已知问题和通知相关维护者；非致命问题可能在稍后级联成更严重故障。官方摘要

对长时间故障的启示：最终 crash log 应与先前关键事件配合，借助时间和身份信息连接故障过程。实际落地还需明确脱敏、用户授权、保留期限，以及跨设备标识是否可被关联；这属于本文补充的部署要求。

4.2 per-skb metadata：身份应跟随被观测对象

Cloudflare 的包路径追踪尝试在 netns、隧道、IPsec 和过滤规则之间保留同一数据包的路径。摘要指出，用外部 BPF map 保存旁路状态需要维护释放清理，而这可能使只关心少量包的采样器仍承担大量包的生命周期事件成本；其上游探索是让 metadata 随 sk_buff 生命周期存在。官方摘要

这比“给每条日志加一个 ID”更深一层：身份的创建、传播、变换和销毁本身就是观测机制的一部分。

映射到设备端，可以借鉴这一问题意识来设计 Binder transaction、异步任务或请求对象的关联信息。不过，复用地址、对象克隆和跨进程身份如何处理，需要根据各子系统的对象语义独立定义。

4.3 从锁顺序，扩展到通用等待／事件依赖

DEPT 关注等待和事件的关系，而不仅是传统锁的获取顺序，覆盖 completion、folio lock、DMA fence 等同步模式。作者把误报及子系统注解不足明确列为推进工作的难点。官方摘要

持锁者无法运行的 fleet 调查也说明，只看等待线程不够，还需要追踪被等待对象及其拥有者的可运行状态。官方 session 摘要

本文判断：等待图的可解释性来自能够核查的依赖关系。边必须有来源和语义，例如“线程 A 在等事件 E”“任务 B 负责产生 E”；缺少关联或注解时，应保留未知状态。

4.4 Forensic Checkpointing：写过什么，比“是否写过”更难保留

Shailja Shaktawat 的 LPC 报告讨论了 CRIU 增量快照的证据缺口：两次快照之间，一页内容可能先被改写、再恢复原值。Soft-dirty 位能说明“写过”，却无法还原中间内容、执行线程及修改顺序。15 页官方讲义，p.3–7

报告提出两条方向：复用首次写入触发的页错误，保留任务、地址和修改前页面；或记录首次写入的代次，以较少信息恢复不同页面首次写入之间的顺序。后者不包含该页随后的全部修改。脏页数量突增也可作为异常线索，先记录计数和地址范围，再决定复制哪些页面。讲义，p.10–13

这些设计建议尚缺实测开销。对稀疏记录方案的具体启示是：将“短暂修改后回写原值”纳入第 9.3 节的反例测试，检验快照与轻量变化记录能否区分候选根因。这份 10 月 7 日报告是本次补充核读的材料，PDF 上传日期尚未确认。

五、主线四：AI 改变诊断的入口，但不替代测量与调试工具

5.1 Performance prompts：维护的资产不再只有工具代码

Brendan Gregg 将 prompt、skill 和 agent 放进性能分析流程，并讨论如何让 flame graph、eBPF、ftrace 等工具适合 AI 使用。第 15 页比较 PNG、SVG 与原始采样文本在效果、主机开销、Token 成本、可重复性及人工复核上的取舍；作者提出可以探索细节量介于 PNG 与 SVG 之间的 JSON 摘要。第 22 页进一步要求工具输出既保留诊断细节，也便于人审和模型处理。官方 Slides，p.14–15、22

Skill 也需要评测。第 26 页展示了超过 100 道性能题的结果：Brendan2015 为 17.4%，perf1 为 41.3%，perf2 为 79.8%；Brendan2015B 的 86.2% 被作者明确标为 Invalid，并用于说明 AI 可能找到提高评测分数的投机路径。阅读这张表时，需同时记录分数与有效性标记。官方 Slides，p.26

本文建议：把诊断经验写成可版本化的过程，包含适用问题、所需证据、工具、停止条件和结论格式；评测中独立检查根因、取证链和任务完成条件，并保留失败样例。观测预算也应纳入模型处理成本。

5.2 drgn + MCP：让模型按证据决定下一次查询

Red Hat 的 slides 展示了真实 RT 内核故障链。thr-suspended 以 SCHED_RR、优先级 1 绑定 CPU 2，在 XFS 的 xlog_cil_insert_items 中持读锁时被抢占；同 CPU 上优先级 9 的 RT 任务持续运行，使该读者无法到达解锁路径。XFS 写者等待读者计数归零，后续读者又被写者持有的 rtmutex 阻挡。官方 Slides，p.4

作者报告最终有 336 个锁等待者、约 23,000 个 D-state 任务，最后一个读者 15.8 小时未被调度，随后发生 Watchdog NMI panic。诊断关键在于把 CPU 亲和性、优先级、锁所有权和等待关系连在一起。

drgn-mcp 将调试能力接入 MCP 客户端，要求本地 vmcore 与匹配的 vmlinux；第 5 页介绍调查演示。第 3 页也明确 eval_expression 提供完整 Python 解释能力，因此部署时需要由运行环境提供权限与资源约束。官方 Slides，p.3–5

对故障分析工具而言，可采用以下过程：

1
2
3
4
5

提出根因假设
    → 调用调试工具
    → 查询任务、锁及依赖状态
    → 修正假设
    → 标出缺失证据并验证根因

这条路径保留每一步查询与来源。通用故障集上的准确率，以及错误符号、损坏转储等情况，仍需要独立评测。

5.3 Agentic 网络观测首先是系统工程

腾讯的未排期提案明确把轻量透明的框架、高质量数据和强隔离环境列为引入 AI 推理前的条件。官方提案

本文判断：底层观测系统与通用 Agent 平台可以结合，让模型在权限、资源和执行约束内按需取证。故障诊断默认只读；提高采样强度或执行修复，需要独立的控制路径。这些控制路径需要在迁移实现中验证。

5.4 会后相关研究：从用 Agent 诊断系统，到观测和约束 Agent

工具调用日志通常止于调用边界，脚本、子进程及资源变化发生在更深的执行层。IPADS 讲义提出两个相互作用的方向：OS 按任务加载观测与约束，Agent 生成经过验证和评估的运行时扩展。系统证据还可反馈到技能改进，再通过留出任务检验效果。讲义，p.6–12、21

• AgentSight + AgentPProf：连接意图、行为与成本。 AgentSight 用 eBPF 关联 LLM 交互与进程、文件、网络行为，并保留来源和置信度；AgentPProf 按任务语义组织操作栈，跨运行聚合 Token、时间与操作，输出 pprof 兼容的性能剖析结果。讲义，p.12–13、AgentPProf 论文
• AgentCgroup + ActPlane：把控制落实到执行层。 前者为工具调用建立短生命周期 cgroup，实施 CPU／内存资源控制；后者用 DSL 声明跨事件规则，在进程、文件和端点间传播标签，并把违规原因返回 Agent。讲义，p.15–16
• SchedCP + gpu_ext：让优化策略在受限扩展点迭代。 Agent 提出优化目标，控制平面承担观测与执行，生成的 CPU／GPU 策略在加载前验证，运行后测量效果并保留有效策略。讲义，p.17–18

两个结果要连同实验条件阅读。

AgentSight 论文在三类开发工作流中报告平均 2.9% 开销，单项为 0.4%–4.9%；实验使用 Ubuntu 22.04、Linux 6.14.0、Claude Code 1.0.62／Claude 4，每类在开启和关闭观测时各运行 3 次。论文 §5.1

ActPlane 在 361 个 OpenAgentSafety 任务中，阻止了 106 个基线不安全结果中的 78 个，遗漏 28 个，同时对 16% 的基线安全任务触发干预；策略仅根据任务描述在执行前生成，并以较高权限加载。论文 §5.6 前者说明特定工作流下的观测成本，后者同时暴露了约束覆盖与误干预的取舍。

讲义把后续问题归为四类：p.20

1. 影响：策略对其他租户的性能、公平性和资源有何影响？
2. 执行覆盖：规则是否覆盖所有相关路径，并匹配任务时序？
3. 权限：下级 Agent 如何只加强、而不削弱继承的约束？
4. 协调：多个 Agent 在同一扩展点加载策略时，如何组合与处理冲突？

本文建议：Agentic SRE 的首个增量应是把一次诊断任务关联到其进程树、系统副作用、资源预算与约束事件，先验证取证成本和权限边界，再试验动态策略。这与第 5.3 节的只读取证路径衔接，也为第七节的观测机制控制补上了 Agent 执行层。

5.5 产品进展：Grafana 把持续检查接到候选修复

Grafana 在 10 月 20 日发布 Assistant Watchers GA 与 Managed Sandboxes 公测。前者持续检查遥测并发起调查，后者将调查上下文与仓库源码交给隔离环境中的编码 Agent，准备改动及测试结果；Investigations 本身已在 7 月下旬 GA。官方发布汇总、产品说明

证据随调查传递。 Watchers 保留查询、遥测证据与运行报告，检查定义可比较版本并恢复。常规检查使用 Assistant 服务账号，自动重新校准则使用创建者身份，部署时需要分别核对两条路径的数据权限。已有明确条件的可靠告警继续承担寻呼职责。Watchers 文档

启动与发布分开授权。 对 Grafana sandbox provider，沙箱命令不能直接推送代码或创建 PR；可配置批准后发布，或仅对已核验的私有仓库自动推分支、开草稿 PR，合并仍在 GitHub 完成。Cursor／Claude 等外部 provider 使用各自的仓库权限，不适用同一发布门禁。沙箱文档

对 Agentic SRE 的启示：调查证据、代码改动和测试结果可以形成连续交接，但沙箱测试通过后，仍需在发布流程中确认生产恢复。产品说明

六、主线五：从“发现问题”走向“可复现、值得修、有人负责”

6.1 报告数量不是可靠性成果

What Bugs Matter? 关注异构报告的归并、子系统映射、在 KASAN 内核中尝试生成并运行 reproducer，以及实际影响评估。官方摘要

同一作者的 From Findings to Fixes 进一步介绍正在开发的持续缺陷收集与验证平台，强调验证复现条件、触发权限和实际影响，再为获得运行证据的问题生成分析和候选补丁。官方摘要两场内容相关，不宜当作两份相互独立的效果验证。

对 SRE 的启示：报警、疑似缺陷、可复现问题、值得投入的问题和已完成修复，应是不同的状态。incident 的解决状态应以修复后的实际验证结果为依据。

6.2 Syzbot：把补丁迭代和审核责任连起来

Syzbot 介绍了候选补丁先进入审核列表、接收自然语言反馈或审核命令、再决定是否转向公共列表的两阶段流程。作者在摘要中将系统标为 POC，并报告截至 2026 年 9 月已有 30 个 AI 辅助补丁合入上游。官方摘要

这个数字属于作者的阶段性报告，本次没有逐项核对提交记录。比数字更值得学习的是责任边界：AI 可以生成、回答问题和迭代，批准进入上游的审核者仍需承担签署责任。

本文建议的修复状态机 是：

1
2
3
4
5
6
7
8
9

finding
  → evidence collected
  → reproduced / not reproduced / insufficient evidence
  → impact assessed
  → patch proposed
  → regression checked
  → reviewed
  → rolled out
  → outcome verified

其中，reproducer 与构建结果分别记录用例和配置覆盖范围；完整修复还需回归与评审，线上部署按既定授权执行。

6.3 Incident-Arena：服务指标恢复与安全修复分别过关

本次补读的 Incident-Arena（9 月 30 日发表）包含 20 个任务，覆盖 Frappe、Saleor 和作者构建的 Slack-like 服务。它将验收拆成两道门禁：Outcome 在持续负载下检查有效吞吐、延迟与错误率；Safety 检查改动范围、数据与保护机制，以及任务要求的重启或再次触发后的修复持续性。两者同时通过才判成功；各任务还用“参考修复通过、no-op 失败”校准判据。论文 §3.3

论文采用 60 分钟执行预算，随后在完整负载周期边界开始 180 秒、无 Agent 干预的验收窗口。论文 §4 公开验证器也把 outcome 与 safe_repair 分开输出。例如队列故障任务要求保留已接受工作、邮件恰好一次交付，并经受验证器控制的重启；清空队列使指标恢复不构成合格修复。固定版本验证器、任务约束

对故障库的启示：把“用户症状恢复”“变更未破坏数据与权限约束”“再次触发后仍然有效”分别作为验收项，避免只检查 Agent 的结论或告警是否消失。本次证据来自论文与代码核读，基准未在本文环境运行。

七、主线六：观测系统本身也需要可预测的控制与验证

7.1 BPF Runtime Verification：已知规则可变成在线检查

BPF RV 议题探索把确定性自动机等运行时验证逻辑映射到 BPF，利用 maps、ring buffer、struct_ops 等机制与现有 RV 框架和命令行生命周期管理整合。官方摘要

它提示了一条与大型模型互补的路线：规则明确、状态空间可控的问题，可以由专用 monitor 在线判断。本文进一步建议，把经验证的故障经验实现为轻量检测器。 monitor 的误报、漏报、事件缺失和资源消耗仍需测试。

7.2 Livepatch 与探针冲突需要生产控制

共存模型议题指出，热补丁与 ftrace、kprobe、kretprobe、BPF 等机制可能争用同一函数附近的插桩能力，造成发布阻塞或观测缺口。讨论方向包括占用报告、明确的失败原因、转换进度和负向测试。官方摘要

官方议题页与 session 议程均将该讨论排在 10 月 7 日 15:45。更新议程

SRE 含义：telemetry 并非永远安全、可忽略的旁路组件。探针本身会影响权限、时序和发布行为；自动诊断系统在增加探针、增强采样或提出 livepatch 前，应该先了解已有占用和冲突。这些系统要求还需要落实到具体接口及其稳定性验证。

7.3 CRIU + RDMA：恢复要覆盖设备状态与连接

NVIDIA 的 33 页报告给出已工作的原型：通过 CRIU 保存和恢复 RDMA 用户上下文，以及 PD、MR、CQ、RC QP 对象；在 ConnectX-7 VF 和 RXE 上实现，并验证运行中的 RDMA perftest 恢复流量。作者报告与 CUDA Checkpoint、GPU DMA-BUF 集成，最高达到 400G 线速，CPU 覆盖 x86 与 ARM。官方 Slides，p.3

关键步骤是按依赖顺序恢复对象图，保持设备镜像内 DMA 地址对应的 IOVA 稳定，并复用 vHCA 固件接口保存／加载 VF 状态、暂停／恢复数据通路。稳定 IOVA 的 DMA API 扩展仍在讨论。官方 Slides，p.15–25

第 32 页列明当前限制：RC 工作负载已验证，UD 尚不完整或未验证，UC/RD 未支持；RDMA CM、SRQ、AH、ODP 等恢复能力也有缺口，事件 FD 状态支持尚不完整。第 3 页把整理上游提交和验证真实大型训练／推理任务列为后续重点。官方 Slides，p.3、32

对 SRE 的启示：恢复能力需要覆盖进程内存、对象依赖和设备状态。大规模 AI 任务的故障恢复、容量调度和维护是它的应用方向，实际部署仍需按硬件、传输类型和外部依赖逐项验收。

八、可以提炼出的五个设计概念

下面是本文依据上述议题归纳的设计概念。

“证据充分”总是相对于具体问题和验证方法而言。对于未知故障，合理的输出可能是多个候选根因及下一步采集请求。

九、对 Android / OpenHarmony 的迁移建议

本节给出面向设备端的概念设计，接口与成本需要在 Android / OpenHarmony 各自平台验证。

建议把系统拆成一条较短的闭环：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

低成本症状与状态变化
        ↓
触发式、有预算的证据采集
        ↓
按启动／进程／任务／请求身份组织证据
        ↓
确定性分析器先做时间分解与依赖检查
        ↓
Agent 形成假设，并按需补充取证
        ↓
复现／故障注入／回归验证
        ↓
人工或既定策略批准修复
        ↓
沉淀故障样例、检测规则和诊断技能

9.1 第一版从一种等待类故障开始

较合适的起点是 ANR / AppFreeze 的一种等待类故障：从用户可见超时窗口出发，区分主线程正在运行、可运行但没获得 CPU、等待锁、等待 IPC 或等待 I/O，然后沿实际接口可提供的依赖继续调查。

设备端优先做便宜的检测和有界采集；较重的检索、源码分析和候选修复可以放在隔离的分析环境。不要在设备已经严重卡顿时，默认启动无界扫描或高开销采集。

9.2 Evidence package 至少要说明“它没记录到什么”

下表是一份待平台实现与验证的数据契约。

对敏感数据还应有明确的脱敏和访问范围。内存、用户标识和业务载荷的采集与上传，应遵循具体授权和数据最小化要求。

9.3 用故障库评价“少记录是否仍然够用”

要验证稀疏记录方案，可以从已知根因、已有修复及可重复触发的故障样例开始，对比不同采集预算下的诊断结果。评价目标不只是正确答案比例，还包括错误高置信结论、需要补采的比例、未知问题的保留能力，以及设备端的 CPU、内存、延迟和电量开销。

这样的试验才能回答：“减少的那些数据，是否真的没有诊断价值？”采集策略的有效性应由这套可重复试验判断。

十、让证据能力与验证范围对应

快照描述状态，回放还需要执行条件。 快照描述某段采集窗口内的状态；完整执行回放还依赖输入、调度、外部状态与非确定性来源。filtered dump、live snapshot、checkpoint 和 deterministic replay 应分别说明能力。

相关线索需要因果验证。 时间线和依赖关系缩小候选范围，结论还要接受反例、复现或干预检验。缺失信息保留为未知，模型推断单独标识。

有界采集需要实际测量。 静态开关、BPF verifier 和遍历限额提供约束，目标工作负载上的测量说明实际扰动，尤其要覆盖极端负载。

自动生成的结果需要独立检查。 诊断脚本、检测规则和补丁分别通过相应验证，观察、测试、修改和部署权限按职责设置。

对于低开销设备观测，可以从少量长期线索、触发式状态采集、依赖关联和按需诊断逐步建立闭环。目标是预算内的诊断充分性：保留有身份、有时间、有范围、能够支持检验的证据，并持续验证观测和修复的实际效果。

原始材料索引与阅读顺序

来源清单与链接核验记录记录逐项核验日期、PDF 页数、关键页和证据范围：议程基础核验为 2026-10-08，5 份 LPC 官方 PDF 正文核验为 2026-10-09；IPADS 会后讲义及相关论文核验为 2026-10-17；本轮录像入口、Forensic 讲义、Grafana 发布和 Incident-Arena 核验为 2026-10-21。

优先从官方 System Monitoring and Observability MC 进入，随后结合 Tracing MC、Android MC、AI 辅助开发 MC、eBPF Track 和 Live Patching MC。System Monitoring 页面还列出 fleet kmemleak、page owner、7×24 网络延迟监测及 relay diagnostic API 等讨论线索，可沿所附邮件继续跟踪各自进展。

10 月 9 日核读的 5 份 LPC 官方 PDF 见文首直链表；IPADS 讲义见第 5.4 节，Forensic Checkpointing 见第 4.4 节。What Bugs Matter、Android 锁竞争、长期延迟监测、Wattson、Syzbot、From Findings to Fixes 和 BPF RV 的附件正文仍待深入阅读。截至 2026-10-21，腾讯 Agentic Network Observability 与 BPF-based Live Snapshots 的官方页面仍标为未排期、暂无材料。

已公布的重点报告录像

LPC 官方于 10 月 19 日宣布录像发布。官方公告 下列入口于 10 月 21 日核对，视频标题、讲者与官方频道匹配；本次未观看录像，正文技术结论仍依据已核读的文字材料。