SmartPerfetto 2026.06.04-07.17 六周更新复盘：从 v1.0.28 到 v1.1.1

本文复盘 上一篇三周更新（2026-06-04，v1.0.28）之后，到 2026-07-17（v1.1.1）为止 SmartPerfetto 的全部主要改动。看完这篇文章，可以知道这六周每个功能解决什么问题、边界在哪里，以及当前版本的完整功能全景。项目地址：github.com/Gracker/SmartPerfetto。

一、变化概览（2026.06.04 – 2026.07.17）

这六周合入了约 150 个提交（不含 merge），发布了 13 个版本（v1.0.29 → v1.1.1）。如果说上一篇文章的主线是”把四条 Agent 运行时都跑通”，那这六周的主线就是把四条运行时收敛到同一套契约之下，同时在分析体验、场景知识、公共生态三个方向持续扩展。

先看几个可以量化的数字（按仓库内约定的统计命令计算）：

下面按对日常分析工作流的影响从大到小逐个展开：先讲改变使用方式的功能（双 Trace 工作台、Quick Mode），再讲改变能力上限的功能（私有分析上下文、运行时统一），最后是场景、知识、生态和工程化。

二、双 Trace 分析工作台

性能优化的核心动作是对比：优化前后对比、竞品对照、系统版本升级回归。此前 SmartPerfetto 已经支持在 AI 会话里挂一个参考 trace，但界面上只有一个时间线窗口，”两条 trace 对着看”这个最自然的动作做不到。7 月 10-11 日（v1.0.39）落地的双窗工作台补上了这一块。

使用路径设计成最短的一条：

• 一键进入：AI Panel 顶部有直达的”打开双窗”按钮，点击后立即出现双窗——一个窗口显示当前 trace，另一个窗口为空，从 workspace 历史里选参考 trace，不需要先进 trace 选择器。
• 窗口身份原子交换：两个窗口都有 trace 选择器，用户可以自由决定哪个窗口放当前 trace、哪个放参考 trace。在当前窗口里选中历史 trace 时，当前 trace 会原子移动到另一个窗口，不会出现两个窗口显示同一条 trace 或者中间出现”无主 trace”的状态。
• 运行身份保护：分析运行期间，”当前 trace + 参考 trace + agent 会话”构成同一个运行身份。此时切 trace、退出对比、切 Provider、换 workspace 都会被拒绝，只有显式 Stop 才走后端取消协议；而布局切换、最大化、拖拽、AI Panel 折叠只改展示状态，不销毁 iframe，也不转移流式连接的所有权。这条规则保证”分析跑到一半窗口动了一下”不会毁掉正在进行的分析。
• 退出语义分离：退出双窗只关闭视觉工作区，参考 trace 和 AI 对比上下文仍然保留；退出对比才会进一步清掉参考 trace、对比上下文和对比会话。

契约层面，CLI 的 smp compare 和前端双窗使用同一套后端对比身份、证据包和报告 section，不存在”CLI 对比结果和网页对比结果不一致”的私有路径。边界也明确：产品语义固定为”当前 trace + 一个 workspace 历史参考 trace”，不支持任意选择两条历史 trace 对比——那属于多分析结果对比（快照对比）的范畴。

完整操作模型（状态机、边界条件）见仓库 docs/architecture/dual-trace-workspace.md。

三、Quick Mode：证据直答与分析回执

日常使用里有大量问题是事实型的：”帧率是多少”、”前台应用是什么”、”掉帧严重吗”。这类问题走完整的 agent 循环——建计划、多轮工具调用、验证——既慢又浪费 token。这六周把 fast 路径重做成了真正的证据直答产品（6 月 29 日回执产品化，7 月 3 日四运行时对齐，v1.0.38 发布）。

工作方式分三步：

1. 意图识别：本地分类器识别问题属于哪类可直答意图——trace 事实（帧数、时长、进程线程）、前台应用、滑动流畅度初筛等。混合意图也能处理，例如”帧率是多少？整体流畅吗？”会同时命中 trace 事实和滑动初筛，合并两类证据一起回答。
2. 确定性取证：后端直接执行对应的 SQL/Skill 拿证据，不经过模型的工具调用循环。
3. 组装直答：用证据表格直接组装答案，附逐句数据引用，0 轮模型对话返回。答案末尾带分析回执，记录用了哪些证据、质量门禁状态。

实际验证用 DeepSeek 真实 API 跑了 9 个端到端用例：身份问题、复合事实、全局帧数加掉帧、滑动初筛、前台应用、CPU 频率存在性、英文提问等，其中 8 个用例实际模型对话轮数为 0，全部通过结论逐条校验（claim verification）。

两个值得说的工程细节：

• 四运行时行为对齐。直答的意图推导、证据组装、结论数量契约在 Claude、OpenAI、Pi Agent Core、OpenCode 四条运行时上收敛到共享模块。此前 Claude 路径是手写组合，混合意图会静默丢掉滑动证据，和其他三条运行时行为不一致；对齐之后这类漂移从结构上消除，结论数量上限这类契约数字也改为模板变量注入，全部单一来源。
• 不误触发。直答只覆盖确定性证据能回答的问题。问题超出范围（例如开放式的”帮我快速分析一下”）会正常落回 agent 路径，不会被硬塞进直答框架里给出残缺答案。

四、私有分析上下文：本机源码 + Android Internals 知识库

Trace 能告诉你”哪里慢”，但解释”为什么慢”经常要回到源码和系统机制。这六周把两类私有上下文接进了分析链路，并在 v1.1.0 里统一了它们的授权模型。这是版本号从 1.0 跳到 1.1 的主要原因。

本机源码（Code-Aware）。把本机代码库注册进 SmartPerfetto 后，AI 分析可以把 trace 现象定位到具体的类和函数。隐私边界从设计上就收紧：模型看到的是 CodeRef 元数据（chunk id、相对路径、行号范围、符号名），不是源码原文；原文只通过带权限控制的端点供用户自己查看；metadata_only 和 provider_send 是两档独立同意，前者保证源码片段永远不发给模型厂商。在此基础上还支持补丁建议（patch proposal）：AI 只能对已经查找过的源码上下文提修改建议，返回”已验证”级别的补丁前必须先通过 git apply --check。

Android Internals 外部知识库（7 月 14 日）。可以把本机的 android-internals-wiki checkout 注册为版本化的外部知识源。检索链路的约束逐条列出来是这样的：

• 路径默认拒绝，只有环境变量白名单内的 Markdown 可预览和索引；
• 注册需要权利确认（rightsAcknowledged），发送给模型厂商需要另一个可撤销的隐私同意（sendToProvider），撤销后新的索引和检索立即拒绝；
• 只有严格解析且状态为定稿的文章进入检索，草稿和待审文章只出现在审计里；
• 模型只收到经过预算控制和脱敏的命中片段，日志和流式事件只投影元数据；
• Wiki 命中只用于解释系统背景，不能替代当前 trace 证据——诊断结论仍然必须引用 SQL/Skill 的实际查询结果。

组合语义（v1.1.0）。源码和知识库是两套独立的授权清单，可以单用、可以组合。任何一类私有上下文存在时，fast/auto 模式会强制解析为具备相应工具和证据门禁的 full 模式。租户/工作区/用户、授权清单、索引代际、内容指纹、同意状态全部进入一个授权指纹；工具调用和运行边界上发现任何一项变化，直接拒绝执行（fail closed），而不是静默降级成另一种分析。这条规则的意义是：撤销同意、重建索引、变更权限之后，不存在”旧授权还在某个会话里继续生效”的窗口。

五、Agent 运行时架构统一

这是六周里代码体量最大的一条线，分两个阶段完成。

6 月上旬的重构（v1.0.32 前后，二十余个重构提交）：

• 四条运行时迁入独立的 engine 目录，公共逻辑（诊断、假设投影、运行时描述符）抽到共享层；
• 新增贯通到 SQL 工具层的取消语义——用户点 Stop 后，正在执行的查询会真正被取消，而不是等它跑完再丢弃；
• Pi Agent Core 和 OpenCode 两条第三方运行时恢复不透明会话状态（opaque state）的断点续传，会话恢复后能接着上次的上下文继续；
• Provider 快照与运行时环境绑定，会话恢复时不会因为用户切换了活跃 Provider 而静默换模型；
• 验证器的误诊模式库从策略文件加载，新增误诊模式不再需要改 TypeScript。

7 月 17 日的 v1.1.0 收口：四条运行时改为消费同一份与 Provider 无关的运行规格（run specification）和对比上下文构建器。此前的一类典型 bug——某个分析选项在 Claude 路径生效、在 OpenAI 路径被静默忽略——从结构上消除，因为选项只在一个地方解析。配套的还有可复现的 Perfetto UI 预构建产物和后端回归门禁 CI（GitHub Actions 上的 backend-agent-regression-gate）。

v1.1.0 落地前做了两轮独立审查（7 月 15 日周度审查、7 月 16 日 clean-room 审查，报告在仓库 docs/reviews/），确认没有已知 P0/P1 阻断项后才发布。同日的 v1.1.1 修掉了审查发现的十余个尾巴：源码引用可定位性校验、OpenAI 工具输出规范化、验证器证据标签解析、滑动指标语义恢复等。

六、Token 成本优化

6 月中旬定位到 full 模式 token 消耗的最大头：系统提示词的方法论段落会嵌入完整场景策略——启动场景约 51K token——而且原有的提示词预算机制只裁辅助段落，裁不到这一段。换句话说，之前每次 full 分析都在为一整篇”启动分析教科书”付费。6 月 18-19 日一次性落地了整套优化（v1.0.35）：

• 策略拆分：场景策略拆成 core 和 detail 两层。core 常驻注入，控制在几 K token；detail 按分析阶段推进按需投递。质量要求迁移到计划模板的期望调用清单和验证器上，保证”提示词变短”不等于”分析变浅”。
• 真实 token 基线回归：新增读取真实策略文件的 token 基线测试，覆盖最坏组合（场景 + 架构 + 完整性 + 选区 + 对比 + 源码感知同时启用），防止后续改动让提示词体积悄悄回退。此前的单测 mock 了策略加载器，抓不到体积问题。
• 大 SQL 结果自动摘要：超过阈值的 SQL 产物自动生成摘要，原始数据转为分页 artifact 引用，出处链不断。
• 工具描述压缩与缓存边界：压缩横跨四条运行时的 MCP 工具描述；为运行时增加提示词缓存边界，按 Provider 适配器声明的能力标记决定缓存策略，而不是按 Provider 名字硬编码。

收益分布有边界：对没有提示词缓存的 Provider（OpenAI 兼容端点、Pi、OpenCode）是直接的每次请求成本下降；对有缓存的 Provider，主要减少的是缓存创建开销和上下文窗口压力。

七、场景覆盖扩展：Camera、Heap、GPU

三个新场景都遵循同一条原则：证据优先，数据不足就明说，不编结论。

• Camera 分析（7 月 12 日）：新增面向证据的 camera 采集 preset（smp capture 可直接使用）和 camera trace 证据 Skill。关键设计是 tracepoint 可用性条件化——camera pipeline 各阶段的 tracepoint 在不同厂商、不同版本上可用性差异很大，Skill 会先探测当前 trace 里有哪些证据源，只对有数据支撑的阶段下结论，缺数据的阶段明确标注不可用，而不是套模板硬答。
• Heap 支配路径分析（7 月 14 日）：新增确定性的 heap dominator path 聚类与提取 Skill——从 managed heap graph 里提取支配路径，把同构路径聚成簇，回答”内存被谁的引用链占住了”。批量 trace 运行时自动聚合各 trace 的 heap 路径，在批量报告里呈现跨 trace 的内存簇分布，配套真实 heap graph trace 的回归用例。
• GPU 计算证据（7 月 14 日）：厂商中立的 GPU compute 证据 Skill，不依赖特定 GPU 厂商的私有 counter，配真实 trace 回归。
• 既有场景加固（6 月上旬）：内存分析证据处理加固、线程阻塞原因（blocked reason）的证据语义修正——后者修的是”阻塞原因”字段被错误归因的问题。

八、RFC-0025：八个 AI 工作流表面

7 月 7 日合入了 RFC-0025 定义的八个功能，方向是把”一问一答”的 AI 分析扩展成可审计、可批量、可协作的工作流。设计与实现文档在仓库 docs/architecture/perfetto-ai-rfc-0025/，落地前经过完整的逐功能独立审查，P1 级发现全部修复后才合入。

九、知识底座：Android 17 渲染管线与 Trace 案例语料库

• Android 17 渲染管线知识同步（7 月 13 日）：docs/rendering_pipelines/ 的 S01-S14 权威内容改为从固定 commit 的源仓库同步（npm run sync:rendering-pipelines），禁止手工修改，保证知识库和源头不漂移。这些文档不是普通说明文——渲染管线检测、教学模式和部分 Skill 会在运行时通过 doc_path 直接读取它们，因此构建时会打包进所有发布形态，包括 Docker 镜像（这次也修了 Docker 里漏打包的问题）。
• Trace 案例语料库（7 月 13-14 日）：新增 Trace/catalog.json 语料目录契约，真实 trace 全部迁入目录化语料库；同时引入确定性构造 trace——把 binder IO 阻塞、GPU 负载、framework pipeline 等场景做成可重复生成的合成 trace，每个案例带期望结论文件。场景回归从”6 条固定 trace”扩展为”目录驱动的语料回归”，新增场景只需要在目录里登记案例，不需要改回归框架。

十、Case Knowledge 平台与自进化 V1

6 月 20-22 日（v1.0.36/37）落地了案例知识平台的第一版，目标是让分析经验可以沉淀和复用：

• 人工案例入库：把典型性能问题案例整理成结构化知识，分析时可检索引用。
• 自进化 V1：分析过程中被确认的模式可以沉淀为可复用的知识条目。这条链路的可靠性打磨占了大头——一份研究报告加多轮独立审查驱动了 14 个缺口修复，包括模式自动确认扫描、模式存储写入串行化（并发分析不会互相覆盖）、SQL 结果持久化等。
• 运行时记忆层加固：记录 Provider 连续性中断、CLI 降级来源等此前会静默丢失的状态，出问题时可以回溯”当时到底用的哪个模型、走的哪条降级路径”。

十一、生态：八个仓库连成一条完整路径

SmartPerfetto 不再是一个孤立项目。7 月 14 日上线的 Android Performance Ecosystem 把插桩、采集、分析、知识、复现八个仓库连成一条完整的 Android 性能分析路径：

其中 SmartPerfetto 和 Perfetto-Skills 的关系值得展开。两个仓库独立演进，但共享一套可移植分析契约：

• 公共 Skill 导出体系（7 月 11-12 日）：backend/skills/public-export.yaml 显式分类每一个运行时资产——可移植的工作流、SQL、方法论和管线知识进入公共投影，产品专属的 Provider/会话/流式语义留在 SmartPerfetto。导出结果由 npm run verify:public-skills 验证。
• 双向影响审查门禁：npm run check:perfetto-skills-impact 会识别所有触碰共享契约的提交（Skill、策略、证据契约、SQL 服务、管线知识、导出策略），要求作者显式记录配对决策——需要同步、不需要同步、或延期并附交接链接。契约漂移不再靠人肉记忆。
• Perfetto 上游同步：期间完成三次上游同步（v56.0 → v57.1 → v57.2），每次按仓库的同步规则完成 fork 合并、UI 预构建刷新和场景回归。

十二、工程化与可用性

• DeepSeek 真实链路端到端验证：Agent SSE 端到端测试默认走 DeepSeek 真实 API（npm run verify:e2e:deepseek*），并提供手动触发的 GitHub Actions workflow——真实 Provider 的行为差异（工具调用格式、流式分块）只有真实链路才能暴露。
• 审查制度化：每周架构审查加发布前 clean-room 审查，报告落盘 docs/reviews/；Quick Mode、RFC-0025、v1.1.0 三个大功能落地前都有独立审查记录。
• 可用性修复：免安装包排除运行时数据（v1.0.33）、macOS 签名资源 staging（v1.0.37）、启动器端口 fallback、Bedrock 模型 ID 跨区规范化、Docker 内 OpenCode 运行时链接、agent 轮次预算调整。
• 依赖维护：Claude Agent SDK、OpenAI Agents、Pi Agent Core、OpenCode SDK 等核心依赖持续升级。

十三、SmartPerfetto 功能全景

到 v1.1.1 为止，SmartPerfetto 的完整功能地图如下，按”入口 → 分析 → 证据与质量 → 知识 → 对比与代码感知 → 输出 → 扩展与治理 → 分发”八层组织：

十四、版本时间线

十五、试用与反馈

运行方式按使用场景选择（详见仓库 README 与 docs/getting-started/quick-start.md）：

• 想快速试用：Docker Hub 镜像，docker compose -f docker-compose.hub.yml up -d，不需要宿主机 Node.js。
• 不想装 Docker：GitHub Release 免安装包（Windows/macOS/Linux），自带全部运行时。
• 终端/脚本用户：npm install -g @gracker/smartperfetto，要求宿主机 Node.js 24。
• 想改代码：源码 checkout 加 ./start.sh；插件 UI 开发用 ./scripts/start-dev.sh。

反馈 bug 时请尽量附上：可复现的 trace、具体的证据位置（时间戳/进程/线程）、期望与实际分析结论的差异。带 trace 的 issue 处理优先级最高。