Agentsview 性能调查实录稳态测量、OpenCode 扫描优化与证据边界【免费下载链接】agentsviewLocal-first session search, analytics, insights, and token use statistics for coding agents, supporting Claude Code, Codex, and more than 20 other agents.项目地址: https://gitcode.com/GitHub_Trending/ag/agentsviewagentsview 是一个本地优先的编码 Agent 会话归档与分析工具支持 Claude Code、Codex 等 20 多种 Agent。它的同步引擎需要持续扫描本地会话源文件、写入归档数据库并响应分析查询因此同步开销是否随新增数据增长还是随归档规模增长是项目长期关注的核心问题。本文基于仓库中保留的内部调查文档 Steady-state performance measurements完整还原这次性能调查环境与方法、五组已验证的修复及其量化收益、10,000 会话规模下的稳态开销分布、OpenCode SQLite 工作负载的深挖与回归测试设计以及对测量证据边界的严格界定。读完本文你可以掌握一套可复现的合成负载测量流程cmd/perfsim、如何用分配次数而非墙钟时间来锁定回归以及如何区分组件级收益与守护进程级收益这两类结论。测量环境与调查方法所有测量在macOS arm64、Go 1.27.0、SQLite FTS5环境下采集调查文档明确声明这些数字是本地观察值而非可移植的延迟目标local observations, not portable latency targets。这一前提很重要后文所有毫秒数和 MiB 数只能用于前后对比不能作为跨机器的 SLA。调查方法上有三个特点由实时日志和一个原生进程采样native process sample驱动方向而不是先拍脑袋优化再找问题分支代码运行在隔离的数据库和源克隆或合成数据上不触碰已安装应用的配置与归档这些运行不需要任何外部采集器No collector was needed即测量工具链全部来自仓库内的cmd/perfsim模拟器和标准 Go 工具。已验证的修复及其量化收益调查文档的第一张表列出了五项Before → After的组件级改进全部附带了各自的工作负载定义操作修复前修复后工作负载SQLite 侧边栏统计27.99 ms10.16 ms本地归档快照PostgreSQL 侧边栏统计11.1 ms4.7 ms匿名化会话元数据Codex 源发现约 90 ms约 56 ms12,656 个克隆源文件热文件系统变更路径追加批次12.60 ms5.72 ms1,000 会话、10,000 个空源、25 次迭代未变更跳过缓存持久化约 8.7 ms约 0.3 微秒聚焦基准10,000 个缓存条目每项修复的机制如下侧边栏统计五个总数合并为一次过滤聚合。统计查询现在用一条带过滤的聚合语句同时计算五个总数而不是逐个数数。这对应 Performance Gates 中保留的BenchmarkGetStats基准——在 10,000 个会话上计算所有总数一次刷新只扫描过滤后的会话一遍正是为了防止这类 O(会话数 × 指标数) 的查询形状回退。Codex 源发现复用目录条目类型省去重复 stat。发现阶段不再对每个源文件重复stat而是复用目录条目中已有的文件类型信息。单次发现路径的分配量从约 16.4 MB 降至 11.4 MB。Claude 重复解析直接探测请求的文件名。旧实现对每个项目枚举无关的转录文本来定位重复项新实现直接探测请求的转录文件名。每批次分配从 11.14 MB 降至 0.266 MB分配次数从 33,912 次降至 2,091 次。嵌套 subagent 候选仍需遍历这是文档明确保留的剩余成本。该修复配有回归测试对比8 个与 8,000 个无关文件两种规模验证重复项的选择与删除行为且该测试对旧实现会失败——这是典型的用工作量而非时间来定义不变量的做法。未变更跳过缓存不再拷贝 map、不再重写全部持久化行。旧路径每次持久化都会复制整个 map 并替换所有行新实现避免了两处开销。文档同时给出一个关键的归因警示模拟器中的空文件会变成空会话不会进入这个缓存因此上表变更路径追加批次的改善不能归功于跳过缓存持久化两者是独立的修复。配套的持久化回归检查覆盖未变更工作、更新、删除和引擎重启四种场景其聚焦基准即 Performance Gates 中列出的BenchmarkPersistUnchangedSkipCache重复持久化一个 10,000 条目的未变更跳过缓存必须避免拷贝 map 和重写行。10,000 会话规模的稳态开销分布组件级修复之后调查用保留的 性能模拟器cmd/perfsim跑了一个更大工作负载来定位剩余成本make perf-sim PERF_SIM_FLAGS--sessions 10000 --turns 20 --active-turns 1000 --iterations 5该负载从403,920 条消息起步每个迭代为两个活跃会话各追加一对消息。下表是首次摄取和查询预热之后的中位数由于每次追加后都会执行查询usage 读取包含了刷新变更数据的成本操作中位耗时中位分配内存Stats3.63 ms1.68 KiBSidebar index43.69 ms15.71 MiBAnalytics summary202.82 ms6.64 MiBDaily activity264.92 ms11.55 MiBDaily usage435.70 ms152.34 MiB常见词全文检索852.94 ms0.19 MiB未变更全量调和1,232.65 ms159.46 MiB长会话追加分批90.64 ms33.97 MiB对这张表的解读要点分配量是操作期间的进程级分配不是保留堆或常驻内存——理解这一点才能解释为什么 Daily usage 的 152 MiB 分配并不意味着泄漏CPU 画像中约60% 的采样落在 C 调用里说明瓶颈在 SQLite 一侧需要 SQL 查询计划或原生层面的剖析才能进一步解释全文检索刻意使用了一个高频词不代表罕见词查询的成本文档的立场很明确这些观察识别了进一步的工作并不宣称对这些分析查询完成了优化。未变更全量调和1,232 ms / 159 MiB是此表中最大的单项成为后文 OpenCode 深挖的入口。OpenCode SQLite 扫描从 source-missing 调和到虚拟事件修复调查的第二阶段聚焦 OpenCode 工作负载。保留的 OpenCode 负载使用生产者侧带索引的 session/message/part schema 并开启 WAL 模式两组运行均为每会话 20 轮、两个活跃会话各带 1,000 初始轮、5 次迭代。生产库与归档都随会话数增长而活跃会话长度与更新量保持不变。注意这些测量早于后述的虚拟事件删除检查修复。操作1,000 会话10,000 会话会话元数据扫描1.37 ms10.79 ms全量子项摘要扫描52.13 ms523.47 ms编辑后轮询两个活跃会话1.46 ms1.57 ms未变更容器事件4.42 ms37.04 ms追加两个长会话121.23 ms163.55 ms归档两个仅子项编辑333.50 ms2,428.55 ms未变更调和388.49 ms4,260.64 ms画像显示约30% 的总 CPU 采样来自 source-missing 调和。根因链条是逐成员的 provider 查找反复打开生产库检查会话是否存在而变更路径准备阶段把已被 provider 解析到既有会话的虚拟路径当作缺失的文件系统条目处理这些假删除又触发了活跃会话事件上的容器级所有权与存在性检查。修复方式是准备阶段把成功解析的 OpenCode 虚拟成员从缺失路径列表中移除真正缺失的成员仍走删除路径。配套回归测试覆盖 8 与 800 个归档会话的对比、未变更虚拟事件的工作量上界、删除目标生产会话后验证 source-missing 状态、保留的归档消息以及不受影响的邻居会话。旧实现对该未变更大事件分配189,332 次突破了测试三倍扩展上界 8,397 次。这个测试即仓库中的 TestOpenCodeVirtualEventDoesNotRecheckUnrelatedMembers它按 v1/v2/mixed 三种 schema 布局运行用testing.AllocsPerRun在 8 与 800 两个规模上采集分配序列并断言扩展上界。在匹配条件下相同的最终模拟器代码 旧引擎 overlay10,000 会话双会话子项编辑批次从2,491.26 ms 降至 120.17 ms约 20.7 倍中位分配从 596.72 MiB 降至 77.04 MiB分配次数从 2,824,784 次降至 327,523 次。但文档同时严格划界修复后未变更调和仍要 4.10 秒 / 1.07 GiB该改善只针对活跃虚拟事件不是全量调和或空闲守护进程的改善。10,000 会话下分析查询的中位数为 summary 166 ms、activity 242 ms、usage 360 ms、常见词检索 753 ms。全量调和的每次约 1.07 GiB 分配被列为独立优化目标。证据的历史局限调查文档专设一节声明证据边界值得在引用任何内部测量数字时对照上文的组件计时是在调查期间记录的原始临时捕获已不可用属于历史观察而非可独立复放的基准证据早期的模拟器报告缺少构建修订号和脏状态元数据匹配的 OpenCode 对比使用了 source overlay其数字在作为发布门禁之前必须用保留的模拟器重跑新的报告会记录构建元数据、可执行文件哈希和可选的 overlay 说明。cmd/perfsim的 provenance 模块 正是这一要求的实现通过debug.ReadBuildInfo提取vcs.revision/vcs.modified并对os.Executable()计算 SHA-256随results.json一并落盘。真实守护进程 合成 SQLite 生产者端到端观测除了组件测量调查还搭建了一个独立的 loopback 服务器基于包含已检入origin/main的构建a87db9ce0导入 10,000 个会话、403,920 条消息。其二进制哈希、HTTP 采样和进程测量保留在 daemon capture 中已安装应用及其归档未被改动原始 profile 与实验脚本留在工作树中被忽略的tmp/daemon-perf目录运行保留模拟器不需要它们。端到端场景与组件测量的差异被明确记录一个长会话接收 10 个 user/assistant 对和 10 次仅子项编辑SSE watch 保持打开客户端每 250 ms 检查最新 10 条 HTTP 消息首次被测量的追加在 watch 建立期间超时其余更新通过会话回退路径在约7–8 秒内出现。这些计时包含轮询和 5 秒回退延迟与上文的组件测量不可直接对比更新运行期间对每个分析端点各发 10 次请求全部成功HTTP 中位耗时stats 4.6 ms、sidebar index 37.7 ms、summary 161.0 ms、daily activity 238.2 ms、usage summary 397.3 ms、常见词检索 747.1 ms。窗口覆盖 UTC 六月至九月且包含每端点的首次请求因此是冷热混合观察。资源侧该阶段父进程占用约 29.5% 单核前 30 秒 profile 含 10.23 CPU 秒其中 51.7% 采样在 C 调用采样期间未观察到 sync-worker 子进程初始摄取的 worker 在捕获前已结束。RSS 在查询期间峰值接近 618 MiB60 秒恢复期加一次强制 GC 后活动 Go 堆约 17.2 MiB、macOS 物理占用 76.2 MiB更新前为 51.9 MiBGC 前 RSS 仍接近 469 MiBvmmap报告 406.4 MiB 已写入可写区域——文档强调这些是不同的核算口径且这次短运行不构成任何长周期内存保留结论。恢复期并非空闲生产者写句柄关闭后原生 watcher 每 5 秒批处理一次SSE watch 保持打开。profile 把 3.6 CPU 秒归因于 source-missing 调和主要是逐会话的 SQLite 存在性探测。一个聚焦复现显示一次WAL 文件缺失事件产生 188,690 次分配而 800 个会话下同一未变更容器事件只有 22,797 次。由此得出的语义修正是本次调查最重要的概念澄清之一WAL/SHM 旁车文件sidecar的消失不等于数据库或其中会话消失。修复后变更路径准备阶段会排除已知容器的消失旁车前提是发现前的状态被成功捕获内容分类仍然执行而容器真正的删除仍保留 source-missing 调和路径回归测试在删除数据库后同时验证保留的消息与 missing-source 状态。修复后的缺失-WAL 事件只做89 次分配从 188,690 次降下来。这一语义同样被记录在 模拟器指南 的Sidecar events and deleted members一节OpenCode、Kilo、MiMoCode、Icodemate 等 SQLite 容器中数据库旁 WAL/SHM 的消失是日常维护事件数据库/旁车变更批次只处理幸存源不承诺立即更新库内已删除会话的source_missing_at删除由下一次成功的权威调和发现且保留已归档消息。调查还刻意做了阴性对照单独的重复工告不成立昂贵的重复调和——后续一个无写者基线在 29.4 秒内仅消耗 0.11 CPU 秒一次 30 秒内 6 个空操作 SQLite 写事务加关闭的跟进实验修复前 0.12 CPU 秒、修复后 0.09 CPU 秒两次运行都没有复现最初的存在性扫描尖峰差异太小不足以支撑任何写者周期空闲开销改善的结论。分配回归与原始 profile 只支撑移除旁车这一定向修复不能证明每次写者关闭都会或都不会触发原始尖峰。对保留 daemon capture 的溯源警告调查文档的结尾对保留下来的 daemon-opencode-2026-09-04.json 给出了明确的负面清单该捕获是显式的探索性数据生成器溯源不完整——生成器由未检入的模拟器代码构建确切的生成器补丁、命令和工具链不可得生成器哈希与负载选项无法重建该源码。因此不得将其用作可复现基准或发布门禁不得推断其语料与已检入模拟器输出逐字节一致受控对比要求来自可识别的已检入构建或完整保留的补丁的新运行并适用模拟器指南中的溯源要求构建修订、脏状态、可执行文件哈希、--provenance-note记录 overlay。实操要点如何复现与延伸这些测量结合 模拟器指南 与 Makefile 中的目标定义perf-sim以CGO_ENABLED1 go run -buildvcstrue -tags fts5 ./cmd/perfsim $(PERF_SIM_FLAGS)运行即自动携带 VCS 构建元数据常用的工作负载形态为# 小归档稳态更新 每次更新后的分析查询 make perf-sim PERF_SIM_FLAGS--sessions 100 --turns 20 --iterations 10 # 大归档活跃会话带更长历史本文第二节的负载 make perf-sim PERF_SIM_FLAGS--sessions 10000 --turns 20 --active-turns 1000 --iterations 10 # 隔离追加工作排除周期性全量调和与分析 make perf-sim PERF_SIM_FLAGS--sessions 1000 --empty 10000 --iterations 25 --reconcile-every 0 --query-every 0 # OpenCode SQLite 容器扫描 长活跃会话 分析查询 make perf-sim PERF_SIM_FLAGS--source-format opencode --sessions 10000 --turns 20 --active-turns 1000 --iterations 5结果目录包含results.json配置、构建修订与脏状态、可执行文件 SHA-256、Go 版本/平台、真实归档总数、每项操作的耗时/分配字节/分配次数/堆、bench.txtGo 基准格式的非冷观测和steady.cpu.pprof摄取与首次查询预热之后的 CPU 采样。前后对比应保持相同的 flag、除被测变更外相同的源码修订、工具链与机器至少采集 5 次迭代并用 cmd/benchgate 做显著性比较进程级分配样本含异步信号工作只用于定位昂贵路径确认修复后应补聚焦基准或工作次数回归。小结这份调查文档的方法论价值这篇内部文档的可贵之处不在数字本身而在于它为性能工程立下的一组可复用准则用分配次数定义不变量。189,332 vs 8,397 的三倍扩展上界、188,690 vs 89 的旁车修复都是通过工作量计数回归测试锁定的天然免疫 CI 噪声且对旧实现确定失败组件收益与守护进程收益分开声明。20.7 倍的虚拟事件修复、27.99→10.16 ms 的统计聚合都被明确限定作用域从未外推为守护进程空闲 CPU 下降或内存保留改善阴性实验与阳性实验同等重要。6 个空写事务无法复现尖峰因此不宣称写者周期改善这一句防止了修复被过度归功于溯源是证据的一部分。保留的 capture 因生成器不可重建而被显式降级为不得作为门禁新报告则强制记录修订、哈希与 overlay 说明cmd/perfsim/provenance.go。如果你要在本仓库中做类似的性能工作建议的路径是先跑make perf-sim的对应工作负载定位昂贵路径 → 用steady.cpu.pprof与进程级分配样本缩小范围 → 修复后补一个工作次数回归测试参考 opencode_virtual_event_perf_test.go 的AllocsPerRun 扩展上界模式以及 Performance Gates 中列出的确定性不变量清单→ 用make bench-gate与cmd/benchgate做本地受控对比。机器相关的延迟阈值不构成强制门槛但确定性不变量必须进入常规测试套件。【免费下载链接】agentsviewLocal-first session search, analytics, insights, and token use statistics for coding agents, supporting Claude Code, Codex, and more than 20 other agents.项目地址: https://gitcode.com/GitHub_Trending/ag/agentsview创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Agentsview 性能调查实录稳态测量、OpenCode 扫描优化与证据边界【免费下载链接】agentsviewLocal-first session search, analytics, insights, and token use statistics for coding agents, supporting Claude Code, Codex, and more than 20 other agents.项目地址: https://gitcode.com/GitHub_Trending/ag/agentsviewagentsview 是一个本地优先的编码 Agent 会话归档与分析工具支持 Claude Code、Codex 等 20 多种 Agent。它的同步引擎需要持续扫描本地会话源文件、写入归档数据库并响应分析查询因此同步开销是否随新增数据增长还是随归档规模增长是项目长期关注的核心问题。本文基于仓库中保留的内部调查文档 Steady-state performance measurements完整还原这次性能调查环境与方法、五组已验证的修复及其量化收益、10,000 会话规模下的稳态开销分布、OpenCode SQLite 工作负载的深挖与回归测试设计以及对测量证据边界的严格界定。读完本文你可以掌握一套可复现的合成负载测量流程cmd/perfsim、如何用分配次数而非墙钟时间来锁定回归以及如何区分组件级收益与守护进程级收益这两类结论。测量环境与调查方法所有测量在macOS arm64、Go 1.27.0、SQLite FTS5环境下采集调查文档明确声明这些数字是本地观察值而非可移植的延迟目标local observations, not portable latency targets。这一前提很重要后文所有毫秒数和 MiB 数只能用于前后对比不能作为跨机器的 SLA。调查方法上有三个特点由实时日志和一个原生进程采样native process sample驱动方向而不是先拍脑袋优化再找问题分支代码运行在隔离的数据库和源克隆或合成数据上不触碰已安装应用的配置与归档这些运行不需要任何外部采集器No collector was needed即测量工具链全部来自仓库内的cmd/perfsim模拟器和标准 Go 工具。已验证的修复及其量化收益调查文档的第一张表列出了五项Before → After的组件级改进全部附带了各自的工作负载定义操作修复前修复后工作负载SQLite 侧边栏统计27.99 ms10.16 ms本地归档快照PostgreSQL 侧边栏统计11.1 ms4.7 ms匿名化会话元数据Codex 源发现约 90 ms约 56 ms12,656 个克隆源文件热文件系统变更路径追加批次12.60 ms5.72 ms1,000 会话、10,000 个空源、25 次迭代未变更跳过缓存持久化约 8.7 ms约 0.3 微秒聚焦基准10,000 个缓存条目每项修复的机制如下侧边栏统计五个总数合并为一次过滤聚合。统计查询现在用一条带过滤的聚合语句同时计算五个总数而不是逐个数数。这对应 Performance Gates 中保留的BenchmarkGetStats基准——在 10,000 个会话上计算所有总数一次刷新只扫描过滤后的会话一遍正是为了防止这类 O(会话数 × 指标数) 的查询形状回退。Codex 源发现复用目录条目类型省去重复 stat。发现阶段不再对每个源文件重复stat而是复用目录条目中已有的文件类型信息。单次发现路径的分配量从约 16.4 MB 降至 11.4 MB。Claude 重复解析直接探测请求的文件名。旧实现对每个项目枚举无关的转录文本来定位重复项新实现直接探测请求的转录文件名。每批次分配从 11.14 MB 降至 0.266 MB分配次数从 33,912 次降至 2,091 次。嵌套 subagent 候选仍需遍历这是文档明确保留的剩余成本。该修复配有回归测试对比8 个与 8,000 个无关文件两种规模验证重复项的选择与删除行为且该测试对旧实现会失败——这是典型的用工作量而非时间来定义不变量的做法。未变更跳过缓存不再拷贝 map、不再重写全部持久化行。旧路径每次持久化都会复制整个 map 并替换所有行新实现避免了两处开销。文档同时给出一个关键的归因警示模拟器中的空文件会变成空会话不会进入这个缓存因此上表变更路径追加批次的改善不能归功于跳过缓存持久化两者是独立的修复。配套的持久化回归检查覆盖未变更工作、更新、删除和引擎重启四种场景其聚焦基准即 Performance Gates 中列出的BenchmarkPersistUnchangedSkipCache重复持久化一个 10,000 条目的未变更跳过缓存必须避免拷贝 map 和重写行。10,000 会话规模的稳态开销分布组件级修复之后调查用保留的 性能模拟器cmd/perfsim跑了一个更大工作负载来定位剩余成本make perf-sim PERF_SIM_FLAGS--sessions 10000 --turns 20 --active-turns 1000 --iterations 5该负载从403,920 条消息起步每个迭代为两个活跃会话各追加一对消息。下表是首次摄取和查询预热之后的中位数由于每次追加后都会执行查询usage 读取包含了刷新变更数据的成本操作中位耗时中位分配内存Stats3.63 ms1.68 KiBSidebar index43.69 ms15.71 MiBAnalytics summary202.82 ms6.64 MiBDaily activity264.92 ms11.55 MiBDaily usage435.70 ms152.34 MiB常见词全文检索852.94 ms0.19 MiB未变更全量调和1,232.65 ms159.46 MiB长会话追加分批90.64 ms33.97 MiB对这张表的解读要点分配量是操作期间的进程级分配不是保留堆或常驻内存——理解这一点才能解释为什么 Daily usage 的 152 MiB 分配并不意味着泄漏CPU 画像中约60% 的采样落在 C 调用里说明瓶颈在 SQLite 一侧需要 SQL 查询计划或原生层面的剖析才能进一步解释全文检索刻意使用了一个高频词不代表罕见词查询的成本文档的立场很明确这些观察识别了进一步的工作并不宣称对这些分析查询完成了优化。未变更全量调和1,232 ms / 159 MiB是此表中最大的单项成为后文 OpenCode 深挖的入口。OpenCode SQLite 扫描从 source-missing 调和到虚拟事件修复调查的第二阶段聚焦 OpenCode 工作负载。保留的 OpenCode 负载使用生产者侧带索引的 session/message/part schema 并开启 WAL 模式两组运行均为每会话 20 轮、两个活跃会话各带 1,000 初始轮、5 次迭代。生产库与归档都随会话数增长而活跃会话长度与更新量保持不变。注意这些测量早于后述的虚拟事件删除检查修复。操作1,000 会话10,000 会话会话元数据扫描1.37 ms10.79 ms全量子项摘要扫描52.13 ms523.47 ms编辑后轮询两个活跃会话1.46 ms1.57 ms未变更容器事件4.42 ms37.04 ms追加两个长会话121.23 ms163.55 ms归档两个仅子项编辑333.50 ms2,428.55 ms未变更调和388.49 ms4,260.64 ms画像显示约30% 的总 CPU 采样来自 source-missing 调和。根因链条是逐成员的 provider 查找反复打开生产库检查会话是否存在而变更路径准备阶段把已被 provider 解析到既有会话的虚拟路径当作缺失的文件系统条目处理这些假删除又触发了活跃会话事件上的容器级所有权与存在性检查。修复方式是准备阶段把成功解析的 OpenCode 虚拟成员从缺失路径列表中移除真正缺失的成员仍走删除路径。配套回归测试覆盖 8 与 800 个归档会话的对比、未变更虚拟事件的工作量上界、删除目标生产会话后验证 source-missing 状态、保留的归档消息以及不受影响的邻居会话。旧实现对该未变更大事件分配189,332 次突破了测试三倍扩展上界 8,397 次。这个测试即仓库中的 TestOpenCodeVirtualEventDoesNotRecheckUnrelatedMembers它按 v1/v2/mixed 三种 schema 布局运行用testing.AllocsPerRun在 8 与 800 两个规模上采集分配序列并断言扩展上界。在匹配条件下相同的最终模拟器代码 旧引擎 overlay10,000 会话双会话子项编辑批次从2,491.26 ms 降至 120.17 ms约 20.7 倍中位分配从 596.72 MiB 降至 77.04 MiB分配次数从 2,824,784 次降至 327,523 次。但文档同时严格划界修复后未变更调和仍要 4.10 秒 / 1.07 GiB该改善只针对活跃虚拟事件不是全量调和或空闲守护进程的改善。10,000 会话下分析查询的中位数为 summary 166 ms、activity 242 ms、usage 360 ms、常见词检索 753 ms。全量调和的每次约 1.07 GiB 分配被列为独立优化目标。证据的历史局限调查文档专设一节声明证据边界值得在引用任何内部测量数字时对照上文的组件计时是在调查期间记录的原始临时捕获已不可用属于历史观察而非可独立复放的基准证据早期的模拟器报告缺少构建修订号和脏状态元数据匹配的 OpenCode 对比使用了 source overlay其数字在作为发布门禁之前必须用保留的模拟器重跑新的报告会记录构建元数据、可执行文件哈希和可选的 overlay 说明。cmd/perfsim的 provenance 模块 正是这一要求的实现通过debug.ReadBuildInfo提取vcs.revision/vcs.modified并对os.Executable()计算 SHA-256随results.json一并落盘。真实守护进程 合成 SQLite 生产者端到端观测除了组件测量调查还搭建了一个独立的 loopback 服务器基于包含已检入origin/main的构建a87db9ce0导入 10,000 个会话、403,920 条消息。其二进制哈希、HTTP 采样和进程测量保留在 daemon capture 中已安装应用及其归档未被改动原始 profile 与实验脚本留在工作树中被忽略的tmp/daemon-perf目录运行保留模拟器不需要它们。端到端场景与组件测量的差异被明确记录一个长会话接收 10 个 user/assistant 对和 10 次仅子项编辑SSE watch 保持打开客户端每 250 ms 检查最新 10 条 HTTP 消息首次被测量的追加在 watch 建立期间超时其余更新通过会话回退路径在约7–8 秒内出现。这些计时包含轮询和 5 秒回退延迟与上文的组件测量不可直接对比更新运行期间对每个分析端点各发 10 次请求全部成功HTTP 中位耗时stats 4.6 ms、sidebar index 37.7 ms、summary 161.0 ms、daily activity 238.2 ms、usage summary 397.3 ms、常见词检索 747.1 ms。窗口覆盖 UTC 六月至九月且包含每端点的首次请求因此是冷热混合观察。资源侧该阶段父进程占用约 29.5% 单核前 30 秒 profile 含 10.23 CPU 秒其中 51.7% 采样在 C 调用采样期间未观察到 sync-worker 子进程初始摄取的 worker 在捕获前已结束。RSS 在查询期间峰值接近 618 MiB60 秒恢复期加一次强制 GC 后活动 Go 堆约 17.2 MiB、macOS 物理占用 76.2 MiB更新前为 51.9 MiBGC 前 RSS 仍接近 469 MiBvmmap报告 406.4 MiB 已写入可写区域——文档强调这些是不同的核算口径且这次短运行不构成任何长周期内存保留结论。恢复期并非空闲生产者写句柄关闭后原生 watcher 每 5 秒批处理一次SSE watch 保持打开。profile 把 3.6 CPU 秒归因于 source-missing 调和主要是逐会话的 SQLite 存在性探测。一个聚焦复现显示一次WAL 文件缺失事件产生 188,690 次分配而 800 个会话下同一未变更容器事件只有 22,797 次。由此得出的语义修正是本次调查最重要的概念澄清之一WAL/SHM 旁车文件sidecar的消失不等于数据库或其中会话消失。修复后变更路径准备阶段会排除已知容器的消失旁车前提是发现前的状态被成功捕获内容分类仍然执行而容器真正的删除仍保留 source-missing 调和路径回归测试在删除数据库后同时验证保留的消息与 missing-source 状态。修复后的缺失-WAL 事件只做89 次分配从 188,690 次降下来。这一语义同样被记录在 模拟器指南 的Sidecar events and deleted members一节OpenCode、Kilo、MiMoCode、Icodemate 等 SQLite 容器中数据库旁 WAL/SHM 的消失是日常维护事件数据库/旁车变更批次只处理幸存源不承诺立即更新库内已删除会话的source_missing_at删除由下一次成功的权威调和发现且保留已归档消息。调查还刻意做了阴性对照单独的重复工告不成立昂贵的重复调和——后续一个无写者基线在 29.4 秒内仅消耗 0.11 CPU 秒一次 30 秒内 6 个空操作 SQLite 写事务加关闭的跟进实验修复前 0.12 CPU 秒、修复后 0.09 CPU 秒两次运行都没有复现最初的存在性扫描尖峰差异太小不足以支撑任何写者周期空闲开销改善的结论。分配回归与原始 profile 只支撑移除旁车这一定向修复不能证明每次写者关闭都会或都不会触发原始尖峰。对保留 daemon capture 的溯源警告调查文档的结尾对保留下来的 daemon-opencode-2026-09-04.json 给出了明确的负面清单该捕获是显式的探索性数据生成器溯源不完整——生成器由未检入的模拟器代码构建确切的生成器补丁、命令和工具链不可得生成器哈希与负载选项无法重建该源码。因此不得将其用作可复现基准或发布门禁不得推断其语料与已检入模拟器输出逐字节一致受控对比要求来自可识别的已检入构建或完整保留的补丁的新运行并适用模拟器指南中的溯源要求构建修订、脏状态、可执行文件哈希、--provenance-note记录 overlay。实操要点如何复现与延伸这些测量结合 模拟器指南 与 Makefile 中的目标定义perf-sim以CGO_ENABLED1 go run -buildvcstrue -tags fts5 ./cmd/perfsim $(PERF_SIM_FLAGS)运行即自动携带 VCS 构建元数据常用的工作负载形态为# 小归档稳态更新 每次更新后的分析查询 make perf-sim PERF_SIM_FLAGS--sessions 100 --turns 20 --iterations 10 # 大归档活跃会话带更长历史本文第二节的负载 make perf-sim PERF_SIM_FLAGS--sessions 10000 --turns 20 --active-turns 1000 --iterations 10 # 隔离追加工作排除周期性全量调和与分析 make perf-sim PERF_SIM_FLAGS--sessions 1000 --empty 10000 --iterations 25 --reconcile-every 0 --query-every 0 # OpenCode SQLite 容器扫描 长活跃会话 分析查询 make perf-sim PERF_SIM_FLAGS--source-format opencode --sessions 10000 --turns 20 --active-turns 1000 --iterations 5结果目录包含results.json配置、构建修订与脏状态、可执行文件 SHA-256、Go 版本/平台、真实归档总数、每项操作的耗时/分配字节/分配次数/堆、bench.txtGo 基准格式的非冷观测和steady.cpu.pprof摄取与首次查询预热之后的 CPU 采样。前后对比应保持相同的 flag、除被测变更外相同的源码修订、工具链与机器至少采集 5 次迭代并用 cmd/benchgate 做显著性比较进程级分配样本含异步信号工作只用于定位昂贵路径确认修复后应补聚焦基准或工作次数回归。小结这份调查文档的方法论价值这篇内部文档的可贵之处不在数字本身而在于它为性能工程立下的一组可复用准则用分配次数定义不变量。189,332 vs 8,397 的三倍扩展上界、188,690 vs 89 的旁车修复都是通过工作量计数回归测试锁定的天然免疫 CI 噪声且对旧实现确定失败组件收益与守护进程收益分开声明。20.7 倍的虚拟事件修复、27.99→10.16 ms 的统计聚合都被明确限定作用域从未外推为守护进程空闲 CPU 下降或内存保留改善阴性实验与阳性实验同等重要。6 个空写事务无法复现尖峰因此不宣称写者周期改善这一句防止了修复被过度归功于溯源是证据的一部分。保留的 capture 因生成器不可重建而被显式降级为不得作为门禁新报告则强制记录修订、哈希与 overlay 说明cmd/perfsim/provenance.go。如果你要在本仓库中做类似的性能工作建议的路径是先跑make perf-sim的对应工作负载定位昂贵路径 → 用steady.cpu.pprof与进程级分配样本缩小范围 → 修复后补一个工作次数回归测试参考 opencode_virtual_event_perf_test.go 的AllocsPerRun 扩展上界模式以及 Performance Gates 中列出的确定性不变量清单→ 用make bench-gate与cmd/benchgate做本地受控对比。机器相关的延迟阈值不构成强制门槛但确定性不变量必须进入常规测试套件。【免费下载链接】agentsviewLocal-first session search, analytics, insights, and token use statistics for coding agents, supporting Claude Code, Codex, and more than 20 other agents.项目地址: https://gitcode.com/GitHub_Trending/ag/agentsview创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 NavigationMenuContent 深度解析：挂载控制、DismissableLayer 关闭机制与 data-motion 动画体系)
