Activity Frames：面向 Agent 记忆与回放的确定性屏幕活动编译

关联论文：2608.05784
作者：flyP
更新：2026-08-08

一句话结论

把"用户做过的操作"作为一等公民压进 Agent 的记忆，而不是用前沿模型在每次推理时重新推导——这是一条零模型、确定性、可字节复现的屏幕活动编译流水线，能把单日原始捕获压成 86× 小的 prompt-ready 上下文块，并在 51 天单用户语料上让 Agent 的"今日回放问答"准确率从 LLM 摘要的 66–80% 提到 98.4%。

解决什么真问题

当下的 computer-use Agent（Claude Computer Use、OpenAI Operator 类）的记忆系统几乎都只能记"用户说过什么"，而不能记"用户在屏幕上实际做过什么"。这造成三种真实损耗：

重复推理成本：用户昨天做过的"在 Jira 里给某 issue 加 P1 标签、复制 ID、写进 Confluence"这类例行操作，今天 Agent 又要花一次 frontier 推理重新摸索。
可信度黑盒：即便 Agent 答对了昨日操作，你也很难解释它为什么答对——因为它的"记忆"本质是一段 LLM 摘要，谁也不知道摘要漏了什么。
缺少需求侧度量：业界讨论 Agent 成本时常假设"用户的活动有多少可委托给 Agent"（Routine Overhead Ratio R、routine 复现率 h），但这些参数从未在被动捕获的人类活动上实测过，多为模型假设。

论文把这三件事用同一条流水线同时解决：把本地屏幕捕获流切成"类型化活动帧（typed activity frames）"，作为可机械审计的 Agent 记忆。

核心方法

3.1 流水线总览

screen capture stream (local)
        │
        ▼
  frame segmenter  ──►  typed activity frames
        │                  (app/site/timing/volume/evidence)
        ▼
  prompt-ready context block  ──►  agent read
        │
        ▼
  replay / replay-verify / cost parameter extraction

关键不变量：整个流程里没有模型。segmenter、特征提取、压缩、缓存键计算全部是确定性的纯函数；同样输入 → 同样字节输出。

3.2 Activity Frame 的结构

一个 frame 是一个有界的情景片段（bounded episode），最小字段集：

frame = {
  app:        str,          # 应用标识（如 "com.atlassian.jira"）
  site:       str,          # 站点/项目空间（"ENG/Backlog"）
  t_start:    datetime,
  t_end:      datetime,
  input_vol:  {key, click, scroll, paste},   # 计数
  evidence:   [row_id, ...], # 指回原始捕获行的指针
  type:       enum {edit, read, navigate, compose, review, ...}
}

evidence 是这套设计的关键：每个 frame 都保留回到原始捕获行的指针，所以 Agent 的回答和审计回放都能"机械地"还原到原始数据，不需要信任任何摘要层的归纳。

3.3 编译器输出

编译器把一日的捕获流（数万 frame）压成一个 prompt-ready 上下文块，体积压缩比 ≈ 86×，压缩耗时 68 ms（单用户、128,756 frame / 51 active days 语料上的报告值）。

压缩不是摘要、不是 LLM 改写，而是： - 按 (app, site, type) 聚类成 macro-frame； - 保留每个 macro-frame 的代表 frame 与 evidence range； - 输出带确定性哈希，可缓存、可 diff、可回放。

3.4 复用同一个编译器做成本度量

同一份 frame 语料还能离线抽出两个从未被实测过的成本参数：

参数	含义	报告值
R（Routine Overhead Ratio）	frontier 推理一次 vs 编译例行一次的代价倍数上界	60–343×
h（routine recurrence）	用户活动里可委托给 Agent 的例行占比	in-sample 9.0% / out-of-sample 7.7%

R 是建模上界而非真实硬件测量，h 是单用户样本——这两点是后续要标注的不确定处。

关键实验与数据

实验装置非常诚实：单用户、单台机、51 个活跃日、128,756 frame。没有大集群评测，但把"可复现、可审计"作为头等约束。

任务	方法	准确率
51 天语料上的"今日回放问答"	编译块 + Agent 阅读	98.4%（Wilson 95% CI 91.7–99.7%）
同上	LLM 摘要 + Agent	66–80%
同一块内容	mid-tier 模型阅读	≈ frontier 模型阅读

"guard-matched hit"（已编译、可缓存的命中）下，replay 可在 0 model tokens 下完成——这是该工作最强的工程落地证据。

统计可信度自证：作者公开了独立 oracle 标注、Wilson 区间、单用户语料规模，承认 R 是上界模型而非硬件实测。

亮点与局限

亮点 - 真正把"用户做过什么"变成 Agent 记忆的一等公民，并做到了字节级确定性 + 可审计。 - 同一份流水线同时给出 prompt-ready 块和需求侧成本参数（R、h），复用度极高。 - 86× 压缩 + 68 ms 编译 + 0-token replay 的数字让落地路径清晰：本地 capture + 离线 compile + Agent 端只读。

局限 / 反方边界（强制段） - 单用户、51 天：准确率 98.4% 的 Wilson 区间下界仍只到 91.7%，样本扩展到多用户后波动未量化。 - 隐私/合规：屏幕捕获是把双刃剑，论文未在原文层面给出删除/编辑/同意流的工程细节，"原文未明确"。 - R 是上界模型：60–343× 是建模边界，不是同一台硬件上的端到端 wall-clock 实测。 - 类型化词典的覆盖：frame 的 type enum 是手工设计的，遇到未在词典内的应用（如新型协作工具）时聚类会退化。 - 离线 vs 实时：68 ms 是离线批处理数字；实时边捕获边编译的尾延迟与 CPU/IO 峰值未报告。 - 跨设备同步：单用户单机的设定不涉及手机、平板等其它端，跨设备 session 合并"原文未明确"。

对工程落地的启发

捕获与编译分层：把 screen capture agent 拆成"捕获（OS 钩子）— 编译（确定性脚本）— 注入（prompt-ready 块）"三层；只有中间这层需要严格确定性、可测试、可 diff，前后两层可以替换实现。
缓存键设计：因为编译是确定性的，frame hash + macro-frame key 天然可缓存；replay 服务可以做成纯函数 + Redis 式 KV，不需要模型推理。
需求侧度量：Agent 厂商在做成本模型时，建议直接用同款编译器在自家用户语料上重新测一次 R 和 h，而不是套用模型假设——这一动作能把"我们假设用户活动可委托 30%"变成可证伪数字。
隐私 by design：frame 必须带 evidence row pointer 看起来是审计利器，但生产环境要把 pointer 设计成"本机可访问 / 上云前 strip"，避免原始捕获外泄。
评估 harness：论文公开了 oracle + Wilson 区间 + 单用户语料 3 件套，建议落地团队复制这套评估而不是只比准确率。

与同方向工作的关系

与 computer-use Agent（Claude Computer Use、OpenAI Operator 类）正交：后者关注"Agent 自己怎么操作屏幕"，本文关注"Agent 怎么记住用户操作过什么"。
与 passive screen capture / rewind 类工具（RewindAI、Screenpipe 等）相比：本文的差异是"为 Agent 准备 prompt-ready 上下文"而非"给人看的可搜索时间线"，并强制了字节级确定性。
与 流程挖掘（process mining） 共用一些概念（episode、trace），但本文的 episode 不带模型、且以 Agent prompt 适配为优化目标。

适合谁读

做 computer-use Agent 的工程师：可把"用户活动编译块"作为新的记忆通道接入。
Agent 成本建模 / 容量规划：R、h 第一次给出可测量值。
隐私 / 合规架构师：确定性编译 + evidence pointer 是天然的"可被机械审计"接口。
不适合想要 SOTA 多任务基准或大规模消融的读者——本文刻意选择了"单用户深读 + 可审计"而不是"大集群横扫"。

工程落地与核查（Jay）

实际系统怎么用

捕获层（OS 级）：Windows 用 Windows.Graphics.Capture API，macOS 用 CGWindowListCreateImage，Linux 用 xwd / scrot；均需管理员权限或用户授权。无模型，纯系统调用，CPU 占用低（论文报告 68ms 编译在未注明 CPU 型号的情况下，建议实测）。
分割器（frame segmenter）：纯函数，入口是原始像素或事件流，出口是 typed frame JSON。分割逻辑（何时切 frame、type enum 判定）是核心工程难点；type enum 必须针对目标用户群体定制，通用场景下退化为"全归 navigate"的概率高。
编译（compiler）：输入一日捕获（可能数十万 events），输出一个 KB 级 JSON 块。86× 压缩比依赖 (app, site, type) 聚类的有效性；若用户工作流高度碎片化（如同时开 50+ 应用），聚类收益下降，压缩比可能只有 10–20× 而非 86×。
回放（replay）：缓存命中时完全零推理，直接读缓存块返回答案。缓存未命中时走 Agent 阅读。实际落地推荐 Redis 作为 KV store，key = macro_frame_hash，value = 编译块 + 元数据。

主要坑

坑	说明	缓解
隐私外泄	evidence pointer 指向原始捕获行；若 frame 上云，pointer 泄露屏幕内容	pointer 只在本机有效；上云前 strip evidence 字段
frame type 覆盖不足	type enum 是手工设计的；遇到新型 SaaS / 自研工具时聚类退化为单 frame 全景	定期扩充 enum；或降级为纯时间窗口切分（保底）
实时尾延迟	68 ms 是离线批处理数字；边捕获边编译时峰值 CPU/IO 造成延迟毛刺	用双缓冲：捕获写队列，专用线程异步编译；监控 p99 编译延迟
跨设备 session 不通	单机捕获只覆盖 PC；手机/平板操作完全丢失	论文未覆盖；产品侧需独立移动端 SDK 并统一 user_id
86× 压缩比依赖特定分布	报告数字来自 51 天、128K frame 单用户语料；R&D / 客服类工作流可能不同	在目标用户群上重新跑编译器，测实际压缩比再对外承诺

核查清单（验证事实对齐）

[x] 86× 压缩比：原文 §3.3 "≈86×"，有来源。
[x] 68 ms 编译耗时：原文 §3.3 注明"single user, 128,756 frames / 51 active days"，同一语料。
[x] 98.4% 准确率（Wilson 95% CI 91.7–99.7%）：原文 Table 1，有区间。
[x] LLM 摘要 baseline 66–80%：原文 §4.1，同一问答任务。
[x] R = 60–343× 上界建模，非实测：原文 §3.4 明确标注"modeled upper bound"。
[x] h = 9.0% / 7.7%（in/out-of-sample）：原文 §3.4，同一语料。
[x] frame type enum 为手工设计：原文 §2.2 "we define a minimal set of types"（原文未明确枚举长度与覆盖策略）。
[ ] 68 ms 测试硬件未注明（CPU 型号/代际未报告）。
[ ] 隐私合规：原文未给出数据删除或同意流工程细节。