回放与 Agent Blame
像看录像一样回看一次智能体会话、筛选其中的事件，并从仓库里的某个文件反向追溯到改动过它的会话。
ORG-2 记录的每个会话都以轨迹的形式保存下来：一份带类型的事件有序列表，每个事件都附带自己的参数和结果。因为这份记录是结构化的，而不是一段回滚缓冲区，ORG-2 可以把它渲染两次——一次是智能体干活时的实时渲染，另一次是事后可以来回拖着看的渲染。本页讲的是这份记录里有什么、怎么回放它，以及怎么反着走：从仓库里的一个文件回到动过它的那次会话。
轨迹记录里有什么
记录的基本单位是会话事件（session event）：一个 id、一个时间戳、归一化后的工具名、参数、结果，以及后端在入库时一次性算好的几项分类。
| 字段 | 取值 |
|---|---|
| 显示变体 | tool_call、message、thinking、plan、approval、session、summary、error |
| 显示状态 | running、completed、failed、pending、awaiting_user |
| 筛选类别 | key_interactions、file_changes、terminal_events、explore、other |
每个事件还会另外抽出一份带类型的 payload，这样界面就永远不必去解析原始的工具输出。payload 的种类有 thinking、file、edit、deleteFile、shell、search、glob、listDir、todo、message、await、webSearch、subagent 和 orgTask——一条 shell 命令、一次文件编辑、一次网页搜索、一次交给子智能体的移交，各自都以独立、可检视的形式落进记录，而不是变成一段文本。
事件按轮次分组：一次用户提交，加上智能体为此做的全部事情。另有一份单独的轮次索引，记录每个轮次的起止位置、时长、事件数、状态、是否被中断，以及它修改过的文件。
注意：
awaiting_user是一个真实的状态，而不是卡住的running。交互式的工具调用——一个提问、一次权限请求、一份待审的方案——会阻塞该轮次直到你回应，而记录会把这段停顿原样保留下来。
实时流与回放
回放并不是一个独立的查看器。工作站（Workstation）把会话渲染成一组「应用」——代码编辑器（Code Editor）、浏览器（Browser）、沟通（Communication）、项目管理器（Project Manager）、画布（Canvas）、Diff 和 Background Tasks——并把每个事件路由到与它匹配的那个应用里。实时看和事后看用的是同一个界面，区别只在游标的位置。
真正的分界是进度条游标停在哪儿。停在末尾时，你跟的是实时流，视图会随着智能体自动滚动。把它拖到别处，会话就切到回放：视图显示的是那个时间点的状态，同时自动滚动停止，新事件不会把你从正在读的地方拽走。ORG-2 特意让历史会话以回放模式打开，这样点开一个旧会话不会立刻被滚到末尾。
播放控制
控件在会话下方的回放条上：
- 播放（Play） / 暂停（Pause） —— 自动向前推进，走到最后一个事件时会自己停下。
- 上一个事件（Previous event） / 下一个事件（Next event） —— 一次精确移动一个事件。
- 播放速度（Playback speed） ——
0.25x、0.5x、1x、2x。默认是1x，大约每两秒推进一次；所选倍速会按比例缩短这个间隔。你的选择会跨会话记住。 - 进度条游标本身 —— 可以拖到会话中的任意位置。拖回末尾就回到跟随模式。
- 跟随（Follow） / 自由浏览（Free browse） —— 把视图钉在智能体当前所在的应用上，或者脱开它，一边继续播放一边自己四处点着看。
按事件类型筛选
长会话里绝大部分内容都是工具调用。筛选事件（Filter events）控件可以把时间线收窄到一个或多个类别：所有事件（All events）、关键交互（Key interactions）（消息、提问、审批、方案）、文件变更（File changes）（读取、编辑、删除）、终端事件（Terminal events）（shell 命令及其输出）、探索（Explore）（搜索、glob、目录列举），以及其他（Other）。
底部面板有两个标签页，轨迹（Trajectory）和待办（Todo），你可以在这里读原始事件列表，也可以只看智能体的任务清单是怎么一步步演变的。
读懂轮次总结
只要智能体给出了总结，聊天时间线上就会有一张本轮总结（Turn Summary）卡片为这一轮收尾。它默认折叠，显示工具调用次数和实际耗时（例如 37 tools · 4m 12s）；展开后可以看到 SUMMARY 标题下的文字总结。会话详情视图把同样的信息汇总成轮次（Rounds）、Agent 工作（Agent worked）、更改的文件（Files Changed），以及一个覆盖工具使用、Token 使用、错误和持续时间的 Event 分析（Event Analytics）区块。
回放怎么存储、怎么传输
会话保存在本地 SQLite 数据库 ~/.orgii/sessions.db 里，具体见会话。
任何环节都不会把整个会话读进内存。ORG-2 先取轻量的轮次索引，再按需拉取轮次正文：起步时取最近的五个轮次，在你拖到的位置前后各预取一个轮次，同时最多只保留八个历史轮次的正文。超大的字段——一次巨大的文件读取、一整屏命令输出——以 payload 引用的形式存储，只带一小段预览，等你打开时才完整取回。一场几个小时的会话之所以还看得动，靠的就是这些。
回放数据留在你自己的机器上，除非你主动共享；本地会话也不会自己过期。
把回放共享给队友
共享是选择性开启的，由所有者控制。在某个组织（ORG）的协作设置里，Session 访问（Session access）有三档：
| 级别 | 队友能拿到什么 |
|---|---|
| 关闭（Off） | 什么都没有——没有会话卡片，也没有回放数据 |
| 仅 Session 卡片（Session cards only） | 标题、所有者、分支和工作区 |
| 完整 replay（Full replay） | 队友可以请求完整的事件快照 |
即使设成完整 replay，队友点开你的某个会话也只是发出一个请求；快照要在那之后才会传输。在仅 Session 卡片这一档，请求会被拒绝，并提示「此 session 仅共享元数据，无法打开完整 replay。」
应用会在你开启之前警告你，而这条警告值得照字面理解：完整回放可能包含提示词、输出、工具调用和文件路径。只对你信任的组织开启它。共享还会按工作区限定范围——在你至少选定一个允许的工作区路径之前，什么都不会被共享。
在 ORG-2 Cloud 上，回放上传会被切成压缩后的分段，实时尾部单独存放。Session 数、每月 replay 上传量和 replay 存储量默认都不设限，但服务端仍会记录用量，供运营观测。共享既可以定向发给某位成员，也可以生成一个会过期的链接。细节见 collaboration 和 cloud。
Agent Blame
Git blame 能告诉你某一行是谁提交的，却说不出它出自哪个智能体会话、是为回应什么而产生的，也说不出它究竟有没有进到某次提交里。Agent Blame 就是 ORG-2 给出的答案：一份把文件和提交归因回改动过它们的那些会话的索引。（看板上每张卡片的刷新操作标为更新 AI Blame（Update AI Blame），用的是同一份索引。）
用法是：在侧边栏里选中一个仓库，打开 Agent Blame 标签页。然后：
- 选择一个层级——Metadata only、Details 或 Full trajectory。
- 点击 Initialize Agent Blame（已有索引时是 Rescan），并观察阶段和进度。
- 看计数器：Sessions、Files、Commits、Entries、Records，以及 Sessions by app type 和 Models used。
- 用 Lookup file sessions —— 输入一个文件路径，就能拿到编辑过它的每一个会话，附带各自的编辑次数和 Applied commits；如果这些工作从未落地，则显示 No linked commit yet。
Most Attributed Files 和 Top Sessions 按归因给仓库里的内容排名。另外，工作站里的 AI Impact 标签页会汇总近期会话涉及的文件、创建的函数、影响的提交和归因行数，并用比例条对照 git 的总活动量。
索引写在仓库内的 .orgtrack 目录里，分成两半：metadata/ 的设计目标是可以安全公开，histories/ 默认私有。层级在这里很关键：Full trajectory 可能包含原始提示词、工具 payload、文件内容和密钥，所以在这个层级扫描之前，ORG-2 会要求你确认。
注意： Agent Blame 的归因粒度是文件和提交，不是逐行。编辑器里的逐行 git blame 是另一个功能，由
editor.showBlame设置控制。
下一步
有问题？欢迎到 ORG-2 Discord 提问。 Discord。