ara-research-manager 深度指南：用 Live PM 技能为 AI 科研会话构建可审计的溯源记录

• AI 技能
• 人工智能
• 大模型
• 深度学习

导读

本指南围绕 AI-Research-SKILLs 仓库中的ara-research-manager技能（Live PM）展开，它是一套在编码/科研会话结束后自动运行的"研究记录员"：扫描整个会话历史，把其中的决策、实验、死胡同、主张、启发式技巧与方向转折抽取出来，按user/ai-suggested/ai-executed/user-revised四类溯源标签写入ara/目录，形成跨会话可持续重建的科研过程档案。读完本文，你将掌握：会话结束后如何自动沉淀科研过程、如何用探索树（exploration tree）刻画研究 DAG、如何通过溯源标签实现"人说了什么"与"AI 做了什么"的严格区分，以及如何用成熟度追踪器把零散观察晋升为正式主张。

一、技能定位：什么是 Live PM，它什么时候运行

ara-research-manager定义了一个名为Live PM（Live Research Project Manager）的角色——一个事后任务记录器（post-task research recorder）。它的核心约束是运行时机：只在一次编码/科研会话结束时运行，也就是用户请求已被完全处理后，才审阅整个会话发生了什么，并据此更新ara/产物。该定位在 SKILL.md 的 frontmatter 中有明确声明："Use as a session epilogue — never during execution"（作为会话尾声使用，绝不在执行期间）。

运行时机有三条硬性规则：

• 绝不在任务进行中运行：处理用户请求期间不得读取或写入ara/；
• 仅在任务完成后运行：用户请求被完整处理之后，才审阅整个会话并更新ara/；
• 不污染工作上下文：ara/目录不应在尾声阶段之前被加载进上下文。

这一设计刻意把"做研究"与"记录研究"分离：任务执行期间保持工作上下文干净、不被日志写入打断，等一切尘埃落定后再一次性、增量地沉淀记录。

Live PM 的整体工作流程（How You Work）分为五步：

1. 审阅会话历史——扫描本次会话发生的一切；
2. 抽取研究级事件——决策、实验、死胡同、主张、启发式技巧、AI 动作；
3. 读取现有ara/文件——获取当前 ID、已有主张、当前树状态；若ara/不存在则创建（见初始化章节）；
4. 写入更新——向正确文件追加新条目、更新状态变化的既有条目、创建会话记录；
5. 汇报捕获内容——结尾输出一行摘要。

二、事件分类：从会话中抽取什么

Live PM 的核心能力是把嘈杂的对话历史分类为结构化的"研究级事件"。下表是 SKILL.md 中定义的事件类型、识别信号与路由目标：

应当跳过的内容（SKIP）：常规文件读取、拼写修正、格式调整；Git 操作与依赖安装；澄清性问题（除非其答案构成一次决策）。这一"负清单"保证了ara/只沉淀有研究信息增量的内容，而不是变成操作日志。

2.1 细粒度事件分类（参考文档深化）

更完整的事件分类体系记录在 references/event-taxonomy.md 中，它将事件细分为五类并分别路由：

• 研究事件（→trace/exploration_tree.yaml）：question（"该不该用 attention 还是 convolution 做 encoder？"）、decision（"用 GQA 而不是 MHA，内存占用更低"）、experiment（"学习率扫描显示 3e-4 最优"）、dead_end（"试了 FP16，但 1k 步后 loss 发散"）、pivot（"attention 方案太慢，切换去状态空间模型"）；
• 知识事件（→logic/）：claim（"我认为……"、"该系统达到……"→logic/claims.md）、heuristic（"关键诀窍是……"→logic/solution/heuristics.md）、concept（新术语定义 →logic/concepts.md）、constraint（"这只有在……时才 work"→logic/solution/constraints.md）、architecture（系统设计 →logic/solution/architecture.md）；
• 证据事件（→evidence/）：result_table（表格数据、基准数字 →evidence/tables/table{N}.md）、result_figure（图数据 →evidence/figures/fig{N}.md）、metric（单个定量测量，内联在实验节点或证据文件中）；
• 过程事件（→trace/sessions/）：ai-action（Agent 写代码、跑命令、建文件）、ai-suggestion（Agent 提出方向/假设 → 记入ai_suggestions_pending）、user-direction（用户给出高层指令或纠正，provenance 为user）；
• 暂存事件（→staging/）：observation（无法归入以上任何一类、有趣但非结构化的内容）。

2.2 路由决策树

event-taxonomy.md给出了一个可逐步执行的路由决策树，Live PM 判断某条会话内容归属时按此顺序走：

是在多个备选方案间做选择？ → 是：decision（trace） → 否：↓ 是定量结果或实验产出？ → 是：experiment（trace）+ 证据数据（evidence/） → 否：↓ 是被放弃的方法且有原因？ → 是：dead_end（trace） → 否：↓ 是关于系统/方法的可证伪断言？ → 是：claim（logic/claims.md） → 否：↓ 是带 rationale 的实现技巧？ → 是：heuristic（logic/solution/heuristics.md） → 否：↓ 是重大方向改变？ → 是：pivot（trace） → 否：↓ 是在探究的研究问题？ → 是：question（trace） → 否：→ observation（staging）

这个决策树保证了任何一条对话内容都能被确定性地归类，不会因为"模棱两可"而漏记或错记。

三、Provenance 溯源标签：人说了什么 vs. AI 做了什么

每一条例入ara/的条目都必须携带溯源标记。这是 Live PM 区别于普通日志系统的关键设计：知识的认识论地位（epistemic status）取决于其来源。用户在会话中明确说出的一句话，与 AI 从代码输出中推断出的结论，具有完全不同的可信权重。

核心原则是不确定时默认ai-suggested，绝不要把推断标记为user。

3.1 四种标签的语义边界（参考文档深化）

references/provenance-tags.md 给出了每种标签的完整语义与边界情况：

• user（用户确认/输入）：用户直接陈述（"学习率应该是 3e-4"）、确认 AI 建议（"对，记下来"/"正确"）、给出决策（"我们选方案 A"）、提出研究问题（"能把内存降低 50% 吗？"）。示例：- **Provenance**: user于 claim 中，或provenance: user于 decision 节点中。
• ai-suggested（AI 推断，未确认）：AI 观察代码/输出中的模式并提出解释、建议研究方向、从实验结果推断主张、为观察提出分类、推测某决策可能有哪些备选项。该文档特别强调其升级路径：只有当用户明确确认后，才可改为user或user-revised。文档还给出了一种"内联溯源"写法，用 HTML 注释标注长文本中不同句子的来源：The system achieves 97% QoE coverage <!-- provenance: ai-executed (from benchmark run) --> under bursty load conditions <!-- provenance: user (stated requirement) -->.
• ai-executed（AI 动作）：AI 写/改了源码文件、跑了基准或测试套件、创建了 ARA 条目、产出了实验结果。即使动作是用户让 AI 去跑的，动作本身仍是ai-executed，但用户对结果的解读可能是user或ai-suggested。
• user-revised（用户修正 AI 建议）：用户说"不完全是，更像……"、纠正细节（"阈值是 90%，不是 85%"）、收窄范围（"对，但只对稠密模型成立"）、补充细微差别（"对，但真正的原因是……"）。该文档要求保留修订历史，例如：

- id: O05 provenance: user-revised content: "KV cache watermark threshold should be 90%, not 85%" revision_history: - original: "ai-suggested watermark at 85%" - revised: "user corrected to 90% based on profiling data"

3.2 为什么溯源重要

provenance-tags.md列出了四项核心收益：

1. 可审计性（Auditability）：评审者/协作者可以把每一条断言追溯到其来源；
2. 信任校准（Trust calibration）：AI 的建议被明确标记为"未经确认"；
3. 修正流程（Correction flow）：用户修订 AI 建议时，修订历史被保留；
4. 责任归属（Accountability）：AI 的动作（写代码、跑测试）被正确归因。

3.3 溯源决策树与会话聚合

references/session-protocol.md 提供了运行时的溯源决策树：

用户明确输入/说出？ → provenance: user AI 运行了产生该结果的代码/测试/命令？ → provenance: ai-executed AI 注意到模式、推断含义、提出解释？ → provenance: ai-suggested 用户修正了 AI 的建议？ → provenance: user-revised 不确定？ → provenance: ai-suggested （保守默认）

会话记录还会聚合溯源统计，作为整个产物可信度的信号：

provenance_summary: user_confirmed: 5 # provenance: user 的事件 ai_suggested: 3 # 未确认的 AI 建议 ai_executed: 7 # AI 采取的动作 user_revised: 1 # 用户对 AI 建议的修正 confirmation_rate: 0.625 # user / (user + ai-suggested)

3.4 溯源完整性五条规则

provenance-tags.md明确列出：

1. 绝不自动升级：ai-suggested→user必须经过用户显式确认；
2. 保留历史：升级时在注释或修订字段中保留原始 provenance；
3. 默认保守：不确定时用ai-suggested；
4. 复合事件：用户让 AI 跑某事，动作是ai-executed，但解读可能是user或ai-suggested；
5. 沉默不是确认：如果 AI 提出建议而用户未回应，它保持ai-suggested。

四、ARA 目录结构：科研产物的分层档案

Live PM 写入的ara/目录遵循 Agent-Native Research Artifact（ARA）的层次化布局。ara-research-manager侧维护的是"轨迹与过程"层，完整的字段级 schema 见 compiler 的 ara-schema.md。Live PM 视角下的目录结构如下：

ara/ PAPER.md # 根清单 + 层索引 logic/ # What & Why（是什么与为什么） problem.md # 问题定义 + 差距 claims.md # 可证伪断言 + 证据引用 concepts.md # 术语定义 experiments.md # 实验计划（声明式） solution/ architecture.md # 系统设计 algorithm.md # 数学 + 伪代码 constraints.md # 边界条件 heuristics.md # 技巧 + rationale + 敏感性 related_work.md # 带类型依赖图 src/ # How（代码产物） configs/ kernel/ environment.md trace/ # Journey（研究旅程） exploration_tree.yaml # 研究 DAG sessions/ session_index.yaml # 会话主索引 YYYY-MM-DD_NNN.yaml # 单个会话记录 evidence/ # Raw Proof（原始证据） README.md tables/ figures/ staging/ # 未分类观察 observations.yaml

4.1 渐进式披露（Progressive Disclosure）

ara-schema.md定义了三级渐进式披露，帮助 Agent 控制上下文成本：

• Level 1 —PAPER.md（约 200 tokens）：frontmatter + 层索引，Agent 只需读它即可判断相关性；
• Level 2 — 层文件（problem.md、claims.md、experiments.md、evidence/README.md）：按需加载；
• Level 3 — 细节文件（algorithm.md、代码桩、单个证据表）：深入时加载。

五、写入格式：探索树、主张、技巧、观察与会话记录

5.1 探索树结构（trace/exploration_tree.yaml）

探索树是嵌套 YAML 结构，父子关系通过children:键表达，形成展示"决策如何导向实验、实验如何导向进一步决策或死胡同"的研究 DAG：

• 根节点是tree:下的顶层条目；
• 每个节点可有含嵌套子节点的children:（缩进表示）；
• 用also_depends_on: [N{XX}]表达交叉边（节点依赖多个父节点）；
• 叶子节点没有children:键。

新增节点规则：判断该节点逻辑上从哪个既有节点延续而来（其父节点），就把它嵌套进该节点的children:；如果是全新的顶层研究线，则作为根节点加入。

完整的节点示例（含 question → experiment → decision → dead_end/experiment 的嵌套链，以及跨边和顶层 pivot）：

tree: - id: N01 type: question title: "{根研究问题}" provenance: user timestamp: "YYYY-MM-DDTHH:MM" description: > {正在探索什么} children: - id: N02 type: experiment title: "{测试了什么}" provenance: ai-executed timestamp: "YYYY-MM-DDTHH:MM" result: > {发生了什么——包含数字} evidence: [C{XX}, "{figure/table refs}"] children: - id: N03 type: decision title: "{基于 N02 结果做出的选择}" provenance: user timestamp: "YYYY-MM-DDTHH:MM" choice: > {选了什么以及为什么} alternatives: - "{未被选择的选项}" evidence: > {什么促成了这一选择——引用父节点} children: - id: N04 type: dead_end title: "{失败的方法}" provenance: user timestamp: "YYYY-MM-DDTHH:MM" hypothesis: > {预期什么会 work} failure_mode: > {为什么失败} lesson: > {学到了什么} - id: N05 type: experiment title: "{work 的替代方案}" also_depends_on: [N02] # 交叉边：也受 N02 影响 provenance: ai-executed timestamp: "YYYY-MM-DDTHH:MM" result: > {结果} evidence: [C{XX}] - id: N06 type: dead_end title: "{从 N01 尝试的姊妹方法}" provenance: user timestamp: "YYYY-MM-DDTHH:MM" hypothesis: > {预期什么} failure_mode: > {为什么失败} lesson: > {学到了什么——促成 N02 方向} - id: N07 type: pivot title: "{新的顶层研究线}" provenance: user timestamp: "YYYY-MM-DDTHH:MM" from: "{先前方向}" to: "{新方向}" trigger: "{什么导致了改变}"

5.2 节点类型参考

探索树的"git log"价值：exploration-tree-spec.md将其类比为"研究的 git log"——结构化的、可遍历的、记录每个成功分支、失败尝试与设计决策的档案。dead_end节点被特别强调为对下游 Agent 最有价值的节点类型，因为它能避免 Agent 重新发现已知的失败。该规范同时要求每个节点声明support_level: explicit | inferred：explicit表示节点直接扎根于输入材料（应携带source_refs如["Table 2", "§4.1"]），inferred表示是对论文/会话逻辑的重构（不得伪装成直接观察到的历史事件）。

5.3 主张（logic/claims.md）

## C{XX}: {标题} - **Statement**: {可证伪断言} - **Status**: hypothesis | untested | testing | supported | weakened | refuted | revised - **Provenance**: user | ai-suggested | user-revised - **Falsification criteria**: {什么会推翻它} - **Proof**: [{证据引用或 "pending"}] - **Dependencies**: [C{YY}, ...] - **Tags**: {逗号分隔}

值得注意：主张的Status支持完整的生命周期（假设 → 未测 → 测试中 → 被支持 → 被削弱 → 被反驳 → 被修订），这与会话结束时 Live PM 更新"状态变化条目"的职责相呼应。ara-schema.md还要求主张的Proof必须引用experiments.md中的实验 ID（E01、E02…），而不是文件路径，以此建立跨层绑定。

5.4 启发式技巧（logic/solution/heuristics.md）

## H{XX}: {标题} - **Rationale**: {为什么这招有效} - **Provenance**: user | ai-suggested | user-revised - **Sensitivity**: low | medium | high - **Code ref**: [{文件路径}]

5.5 观察（staging/observations.yaml）

- id: O{XX} timestamp: "YYYY-MM-DDTHH:MM" provenance: user | ai-suggested | ai-executed content: "{原始观察}" context: "{当时发生了什么}" potential_type: claim | heuristic | decision | unknown promoted: false

staging/是"松散线索"的暂存区：观察可能暂时无法归类，通过potential_type预判其未来去向，promoted标记是否已被晋升到正式层。

5.6 会话记录（trace/sessions/YYYY-MM-DD_NNN.yaml）

session: id: "YYYY-MM-DD_NNN" timestamp: "YYYY-MM-DDTHH:MM" summary: "{本次会话一行摘要}" events_logged: - type: decision | experiment | dead_end | pivot | claim | heuristic | observation id: "{N/C/H/O}{XX}" provenance: user | ai-suggested | ai-executed | user-revised summary: "{什么}" ai_actions: - action: "{AI 做了什么}" provenance: ai-executed files_changed: ["{路径}"] claims_touched: - id: C{XX} action: created | advanced | weakened | confirmed provenance: user | ai-suggested open_threads: - "{需要跟进的事}" ai_suggestions_pending: - "{本次会话未确认的 AI 建议}"

5.7 ID 约定与自增规则

event-taxonomy.md定义了全局 ID 约定：探索节点N（N01…）、主张C（C01…）、技巧H（H01…）、实验计划E（E01…）、观察O（O01…），会话 ID 按日期序列2026-03-11_001唯一命名。自增规则：创建新 ID 前必须读取现有文件找到最大 ID，避免重复。

5.8 取证绑定清单（Forensic Binding Checklist）

event-taxonomy.md要求记录任何事件时立即建立以下绑定（与 SKILL.md 规则 5 "Establish forensic bindings" 对应）：

• 主张 → 证据：主张创建时，什么证据能证明/推翻它？若无证据则Proof: [pending]；
• 实验 → 主张：该实验测试哪些主张？通过Claims tested:链接；
• 技巧 → 代码：代码库中哪里实现了它？设置Code ref:；
• 决策 → 证据：什么证据或推理推动了该决策？
• 死胡同 → 教训：学到了什么？该知识能否防止未来重犯？

若当前无法建立绑定，则添加<!-- TODO: bind to {target} -->注释作为可追踪的待办义务。

六、会话协议：从开始到结束的完整生命周期

虽然 Live PM 只在会话结束后正式写入，但 references/session-protocol.md 描述了贯穿整个会话的协议，使其在会话结束时能无缝接续状态。

6.1 会话开始（自动）

• 若ara/已存在：静默读取状态——session_index.yaml（上次会话日期、摘要、未完成线程）、claims.md（按状态统计）、staging/observations.yaml（待处理数量、晋升候选）；随后按需上下文化简报：用户直接开始任务则把上下文织入首条回复（"在我们开始前——上次会话你在测 C04，结果是 92%，有两个未完成线程"），用户询问进展则给出完整简报，用户有明确任务时绝不以简报开场；同时创建本次会话记录文件trace/sessions/YYYY-MM-DD_NNN.yaml，初始化开始时间与空事件列表。
• 若ara/不存在：不要在首次交互时主动创建；若检测到研究级讨论（决策、假设、实验），问一次"要我跟踪这个项目的研究过程吗？我会建立ara/"；确认后初始化完整目录结构并从当前会话引导启动。

6.2 会话进行中（持续、不可见）

每次实质交流后运行事件检测循环：

1. 做了决策？ → 写入 exploration_tree.yaml 2. 观察到结果？ → 写入 exploration_tree.yaml + evidence/ 3. 方法失败？ → 写入 dead_end 到 exploration_tree.yaml 4. 陈述了主张？ → 写入 claims.md 5. 发现技巧？ → 写入 heuristics.md 6. 方向改变？ → 写入 pivot 到 exploration_tree.yaml 7. AI 写了代码？ → 记录到会话记录（ai_actions） 8. 有趣的笔记？ → 写入 staging/observations.yaml

写入协议：先读取目标文件获得下一个可用 ID；追加新条目、绝不覆盖既有内容；立即建立绑定（claim→proof、heuristic→code_ref、decision→evidence）；使用正确的 provenance；写入前在心中校验 YAML 结构有效性；保持沉默——除非被询问，否则不提日志记录。

6.3 冲突检测

写入新条目时检查冲突：

• 新主张与既有主张矛盾 → 双方都加<!-- CONFLICT: see C{XX} -->；
• 新证据削弱既有主张 → 将主张状态更新为weakened；
• 新决策推翻先前决策 → 记录为pivot并链接到原决策。

6.4 会话结束（自动）

结束触发信号：对话明显收尾（"谢谢"、"就这些"、用户沉默）、上下文窗口即将压缩（系统在总结旧消息）、用户明确道别。

结束流程：

1. 定稿会话记录：设置结束时间戳、写一行摘要、确保所有缓冲事件已刷入 ARA 文件；
2. 更新会话索引session_index.yaml：

- id: "YYYY-MM-DD_NNN" date: "YYYY-MM-DD" summary: "{主要成果}" events_count: {N} claims_touched: [C{XX}, ...] open_threads: {N}

3. 对暂存区做成熟度检查（详见下节）；
4. 输出一行简短收尾：

[PM] Session captured: 3 decisions, 1 experiment, 2 claims advanced. 1 open thread.

6.5 跨会话连续性

Agent 本身没有内置跨会话记忆，ARA 本身就是记忆：

• session_index.yaml→ 何时发生了什么；
• claims.md→ 已知 vs. 未知；
• exploration_tree.yaml→ 完整研究轨迹；
• staging/observations.yaml→ 松散线索；
• 各会话记录 → 逐会话的详细历史。

每个会话开始时读取这些文件即可重建完整项目上下文。未完成线程（open threads）自动结转：每个会话记录列出open_threads，会话开始时浮出最近会话的未完成线程，后续会话解决某线程时在事件中注明。

紧急/意外结束：若会话未正常收尾——已写入 ARA 的事件是安全的（增量写入），会话记录可能不完整，下次会话应检测并注明；因为写入是实时而非批量，不会丢数据。

七、初始化：ara/不存在时的自动引导

若ara/不存在，Live PM 自动创建完整目录结构并写入种子文件，不要询问（Initialization 章节明确要求 "Do not ask"）：

mkdir -p ara/{logic/solution,src/{configs,kernel},trace/sessions,evidence/{tables,figures},staging}

然后写入 8 个种子文件：

1. ara/PAPER.md— 根清单（根据项目上下文推断标题、作者、venue）；
2. ara/trace/sessions/session_index.yaml—sessions: []；
3. ara/trace/exploration_tree.yaml—tree: []；
4. ara/staging/observations.yaml—observations: []；
5. ara/logic/claims.md—# Claims；
6. ara/logic/problem.md—# Problem；
7. ara/logic/solution/heuristics.md—# Heuristics；
8. ara/evidence/README.md—# Evidence Index。

八、成熟度追踪器：观察如何晋升为正式知识

每次尾声阶段审阅staging/observations.yaml时运行成熟度追踪器（Maturity Tracker）：

• 同一主题 3+ 条观察→ 晋升到对应层（标记为ai-suggested）；
• 带实验证据的观察→ 晋升到evidence/；
• 与某主张矛盾的观察→ 标记<!-- CONFLICT: contradicts C{XX} -->；
• 陈旧观察（跨 3+ 个会话）→ 标记stale: true。

这形成了一个自组织升级管道：零散观察先在staging/积累，达到足够密度或证据强度后自动晋升为正式主张、证据或技巧，同时矛盾与陈旧信息得到显式标注，避免污染后续会话。

九、完整执行流程与七条规则

9.1 尾声执行流程（Procedure）

1. 读取现有ara/文件获取当前状态（ID、主张、树）；
2. 扫描整个会话，寻找研究级事件；
3. 对每个事件分类并赋予 provenance；
4. 向正确文件追加新条目；若状态变化则更新既有条目；
5. 在ara/trace/sessions/YYYY-MM-DD_NNN.yaml创建会话记录；
6. 将会话追加到ara/trace/sessions/session_index.yaml；
7. 对暂存区运行成熟度追踪器；
8. 输出一行摘要：[PM] Session captured: {N} decisions, {N} experiments, {N} claims.

9.2 七条操作规则（Rules）

1. 绝不在任务进行中运行——只在用户请求完成后的尾声阶段运行；
2. 绝不虚构事件——只记录实际发生或讨论过的内容；
3. 绝不升级 provenance——ai-suggested保持到用户显式确认为止；
4. 总是先读取既有文件——获取正确的下一个 ID，避免重复；
5. 建立取证绑定——主张→证据、技巧→代码、决策→证据；
6. 追加而非覆盖——新增条目，绝不替换既有内容；
7. 保持 YAML 有效——写入后校验结构。

这七条规则是保证ara/记录可信度的基石：尤其是"不虚构事件""不升级 provenance""总是先读文件"，三者共同防止了最常见的三种污染——编造历史、夸大确认度、ID 冲突。

十、与 ARA 生态的协同：Compiler 与 Rigor Reviewer

ara-research-manager是 ARA 工作流中的"过程记录器"，它与同目录下的另外两个技能构成完整闭环：

• ara-compiler（Universal ARA Compiler）：把论文 PDF、GitHub 仓库、实验日志、代码目录等任意研究输入编译成完整 ARA，其trace/exploration_tree.yaml的节点规范（support_level: explicit | inferred、source_refs、≥8 节点、必须含 dead_end 与 decision 类型）与 Live PM 维护的探索树是同一套格式——Compiler 从静态输入重建研究 DAG，Live PM 则在真实研究过程中持续增量维护它；
• ara-rigor-reviewer（ARA Seal Level 2 语义审稿）：在 Level 1 结构校验通过后，从证据相关性、可证伪性、范围校准、论证连贯性、探索完整性、方法严谨性六个维度对 ARA 打分并产出level2_report.json。其中D5 探索完整性直接审查探索树是否记录了真实的失败过程——这正是 Live PM 持续写入的内容质量保证层。

三者形成"Compiler 建库 → Research Manager 记录过程 → Rigor Reviewer 审稿"的闭环，而 Live PM 提供的逐会话溯源记录，正是 Rigor Reviewer 判断"探索是否诚实"（是否记录了真实负结果）的事实来源。

结语

ara-research-manager解决的是一个真实而隐蔽的问题：AI 参与的研究过程，其"过程"本身——失败的分支、放弃的方案、临时的直觉、未被确认的推断——在最终论文里往往消失不见。Live PM 通过"会话尾声扫描 + 事件分类 + 溯源标签 + 探索树 DAG"这套机制，把过程变成了与结果同等重要、可审计、可跨会话重建的资产。对使用 Claude Code / Codex 等 Agent 进行研究的团队而言，这意味着每次会话结束后，项目的知识状态都会被自动、诚实、增量地沉淀下来——下一会话开始时，Agent 通过读取ara/就能"回忆起"它从未真正拥有过的记忆。

参考文件索引

• research-manager/SKILL.md — Live PM 技能定义（本文主文档）
• references/event-taxonomy.md — 完整事件分类、路由决策树、ID 约定与取证绑定清单
• references/provenance-tags.md — 溯源标签语义、边界情况与会话聚合
• references/session-protocol.md — 会话开始/进行中/结束的分阶段协议
• compiler/references/ara-schema.md — ARA 目录完整字段级 schema
• compiler/references/exploration-tree-spec.md — 探索树 YAML 规范
• compiler/SKILL.md — ARA 编译器技能
• rigor-reviewer/SKILL.md — ARA Seal Level 2 语义审稿技能

• AI 技能
• 人工智能
• 大模型
• 深度学习