AI-Research-SKILLs 研究事件分类学ARA Research Manager 事件类型、路由规则与来源标注机制深度解析【免费下载链接】AI-Research-SKILLsComprehensive open-source library of AI research and engineering skills for any AI model. Package the skills and your claude code/codex/gemini agent will be an AI research agent with full horsepower. Maintained by Orchestra Research.项目地址: https://gitcode.com/gh_mirrors/ai/AI-Research-SKILLs导读在 Agent 协作的科研过程中一次会话里往往交织着研究问题、技术决策、实验结果、失败教训与 AI 动作。若不加分类地全部记录ara/目录很快就会变成无法检索的流水账。本文围绕 event-taxonomy.md 展开系统讲解 ARA Research ManagerLive PM如何把会话中的信息归类为 research、knowledge、evidence、process、staging 五大类事件依据路由决策树写入 ARA 对应层并通过 provenance 标签、全局 ID 与 forensic binding 清单构建可审计的研究轨迹。读完本文你将掌握完整的事件分类框架、四类来源标注的判定规则、ID 命名约定以及如何在探索树、声明库、会话记录之间建立可交叉引用的取证链。一、事件分类学在 ARA 体系中的定位1.1 ARA 是什么ARAAgent-Native Research Artifact是 AI-Research-SKILLs 仓库中22-agent-native-research-artifact/目录定义的面向 Agent 的研究产物规范把论文、代码库或实验日志等任何研究输入编译成一个分层的、可被机器遍历的知识包。ARA 的标准目录结构定义于 ara-schema.md核心分层如下PAPER.md # Level 1: 根清单 分层索引 logic/ # What Why认知层 problem.md / claims.md / concepts.md / experiments.md solution/ architecture.md / algorithm.md / constraints.md / heuristics.md related_work.md src/ # How物理层配置与代码桩 trace/ exploration_tree.yaml # 研究 DAG sessions/ # 会话记录 evidence/ # 原始证据表格/图 staging/ # 未分类观察其中trace/exploration_tree.yaml被 exploration-tree-spec.md 称为**“研究的 git log”**——它结构化、可遍历地记录每一次成功分支、失败尝试与设计决策。1.2 Research Manager从会话到 ARA 的“现场记录员”research-manager/SKILL.md 定义了ara-research-managerLive PM技能它作为任务结束后的 epilogue运行在用户请求全部处理完毕后扫描整段对话历史提取决策、实验、死胡同、声明、经验法则与转向pivot写入ara/目录并打上 user-vs-AI 来源标签。它遵循三条铁律见 SKILL.md CRITICAL: When This Skill Runs任务进行中绝不运行不读取、不写入ara/仅在任务结束后运行回顾完整会话后更新 ARA不污染工作上下文ara/不应在 epilogue 阶段之前被加载进上下文。Live PM 的工作流分为五步回顾会话历史 → 提取研究意义事件 → 读取既有ara/文件获取当前 ID、已有声明、树状态若不存在则初始化→ 追加写入正确文件并更新状态变更 → 输出一行摘要。事件分类学event-taxonomy正是这套流程的核心分类引擎它定义了“什么值得记录、归为哪一类、路由到哪个文件、标注什么来源、使用什么 ID”。1.3 什么值得记录、什么必须跳过research-manager/SKILL.md 在 What to Extract 一节明确了记录边界这也是分类器工作的前提值得记录对应五大事件类别决策、实验、死胡同、转向、声明、经验法则、AI 动作、观察。明确跳过不值得记录常规文件读取、拼写修正、格式调整Git 操作、依赖安装澄清性问题除非答案本身构成一次决策。二、五大事件类别分类依据与路由目标event-taxonomy.md 的核心是一张完整的事件分类表当你在编码会话中观察到活动时依据signals信号列把它归入下列事件类型之一signals 用于从对话与代码上下文中识别事件。2.1 Research Events路由到trace/exploration_tree.yamlTypeSignalsExamplequestion用户就研究方向提出 what if...、should we...、how does...Should we use attention or convolution for the encoder?decision用户在备选方案之间做出选择承诺某个方向Lets go with GQA instead of MHA — lower memory footprintexperiment代码运行测试/基准用户报告结果The learning rate sweep shows 3e-4 is optimaldead_end方案被放弃、假设被证伪、this doesnt workTried FP16 but the loss diverges after 1k stepspivot由证据触发的重大方向变更The attention approach is too slow — switching to state space models这五类事件共同构成探索树exploration tree的节点类型。注意dead_end与pivot的区别dead_end 是单条路径的终结带着失败原因与教训pivot 是研究方向的整体切换带着 from/to/trigger 三元组。2.2 Knowledge Events路由到logic/TypeSignalsRoutes ToclaimI believe...、The system achieves...关于能力或属性的断言logic/claims.mdheuristicThe trick is...、You need to...实现洞察logic/solution/heuristics.mdconcept定义新术语、需要消歧logic/concepts.mdconstraintThis only works when...边界条件logic/solution/constraints.mdarchitecture系统设计、组件关系logic/solution/architecture.md这五类 Knowledge Events 与 ara-schema.md 中logic/层的五个文件一一对应构成 ARA 认知层Cognitive Layer的内容来源。2.3 Evidence Events路由到evidence/TypeSignalsRoutes Toresult_table表格数据、基准数字、对比矩阵evidence/tables/table{N}.mdresult_figure绘图数据、可视化、图表数值evidence/figures/fig{N}.mdmetric单一定量测量内联在实验节点或证据文件中Evidence Events 是“原始证据”的来源。依据 ara-schema.md 的保真度规则证据层区分原始源证据忠实转录、保留原始编号与标题如table3_imagenet_validation.md与派生子集证据为特定声明过滤或重组文件名必须带derived_/subset_前缀并声明来源。文件若含table3、figure4之类的源标签就必须忠实代表该源对象而不是精选子集。2.4 Process Events路由到trace/sessions/TypeSignalsRoutes Toai-actionAgent 编写了代码、运行了命令、创建了文件会话记录ai-suggestionAgent 提出了方向、假设、方案会话记录ai_suggestions_pendinguser-direction用户给出高层指令或纠正会话记录events_loggedprovenance: userProcess Events 只写入会话记录不进入探索树或逻辑层因为它们描述的是“谁做了什么”而非“研究内容本身”。2.5 Staging Events路由到staging/TypeSignalsRoutes Toobservation不完全符合以上类别、有趣但结构未成型staging/observations.yamlobservation是分类器的兜底桶有趣但暂时无法定型的信息先进 staging等待成熟度提升maturity promotion后再升级到正式层。三、路由决策树从对话信号到落盘路径event-taxonomy.md 给出了一条自顶向下的判定路径。它是分类器实际执行的算法Is it about a choice between alternatives? → YES: decision (trace) → NO: ↓ Is it a quantitative result or experimental outcome? → YES: experiment (trace) evidence data (evidence/) → NO: ↓ Is it an abandoned approach with a reason? → YES: dead_end (trace) → NO: ↓ Is it a falsifiable assertion about the system/method? → YES: claim (logic/claims.md) → NO: ↓ Is it an implementation trick with rationale? → YES: heuristic (logic/solution/heuristics.md) → NO: ↓ Is it a major direction change? → YES: pivot (trace) → NO: ↓ Is it a research question being explored? → YES: question (trace) → NO: → observation (staging)该决策树的几个关键设计意图先判选择、再判结果、后判失败decision 优先级最高因为它需要捕获alternatives未被选中的选项这类信息一旦错过会话就永久丢失experiment 是唯一“双写”事件既写入trace/exploration_tree.yaml轨迹又写入evidence/原始数据保证“故事”与“证据”分离claim 与 heuristic 需要可证伪性与理由纯粹的断言claim进 claims.md带理由的实现技巧heuristic进 heuristics.mdobservation 是默认归宿任何无法被上述规则命中的内容都落到 staging而不是被丢弃。从源码结构可以推断这条决策树对应 session-protocol.md 中“会话期间”的 Event Detection Loop——每个实质性的交流回合后Live PM 依次检查有决策有结果有失败有声明有技巧有转向AI 写了代码有值得注意的观察这正是决策树的运行时形态。四、来源标注Provenance每条事件的信任标记4.1 为什么来源标注至关重要provenance-tags.md 开篇给出了核心理由在人与 AI 协作的研究过程中每条知识的起源决定了它的认识论地位。用户明确陈述的声明与 AI 从代码输出推断出的声明权重完全不同。来源标注提供四重保障可审计性Auditability审稿人/协作者可以把每条断言追溯到其来源信任校准Trust calibrationAI 建议被明确标记为“未经确认”修正流Correction flow用户修订 AI 建议时修订历史被保留问责AccountabilityAI 动作写了什么代码、跑了什么测试被正确归属。4.2 四种来源标签的完整语义event-taxonomy.md 的 Provenance Assignment 一节给出了四值判定provenance-tags.md 则补充了每种标签的适用场景与示例user— 用户确认/输入用户明确陈述、输入或确认了该信息。适用于用户直接说明The learning rate should be 3e-4、用户确认 AI 建议yes, log that、用户做出决策Lets go with approach A、用户提出研究问题Can we reduce memory by 50%?。ai-suggested— AI 推断未确认AI 基于上下文推断、提出或假设了该信息用户未明确确认。适用于AI 在代码/输出中观察到模式并提出解释、AI 建议研究方向、AI 从实验结果推断声明、AI 为观察提出分类、AI 猜测某决策可能有哪些备选项。注意升级路径当用户确认后才可改为user或user-revised。ai-executed— AI 动作AI 执行了具体动作写了代码、跑了基准、创建了文件、执行了测试。适用于AI 写入/修改源文件、运行基准测试套件、创建 ARA 条目、生成实验结果。user-revised— AI 建议、用户修改AI 提出建议后用户不是全盘接受或拒绝而是做了修改。典型信号not exactly, its more like...、the threshold is 90%, not 85%、thats true but only for dense models、yes but the real reason is...。记录时应保留revision_history追踪修订轨迹。4.3 来源判定决策树provenance-tags.md 与 session-protocol.md 各给出了一棵等价的判定树User typed/said it explicitly? → provenance: user AI ran code/test/command that produced this? → provenance: ai-executed AI noticed pattern, inferred meaning, proposed interpretation? → provenance: ai-suggested User corrected an AI suggestion? → provenance: user-revised Uncertain? → provenance: ai-suggested (conservative default)4.4 来源完整性的五条规则provenance-tags.md 以 Rules for Provenance Integrity 收尾这些规则约束着分类器与 Live PM 的每个写入动作永不自动升级ai-suggested→user必须经过用户明确确认保留历史升级时把原始来源保留在注释或修订字段中默认保守不确定时一律用ai-suggested复合事件拆分用户让 AI 运行某事动作为ai-executed但解释可能为user或ai-suggested沉默不等于确认AI 提出建议而用户未回应保持ai-suggested。4.5 混合来源与聚合统计某些条目具有混合来源——例如 AI 运行实验ai-executed、用户解读结果user- id: N12 type: experiment provenance: ai-executed # AI 运行了基准 result: 97% QoE 0.95 # 事实输出 interpretation: # 用户对结果的解读 provenance: user content: This confirms our hypothesis — overhead awareness is critical会话记录还会聚合来源统计作为整体产物质量的信任信号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)五、ID 命名约定全局唯一与自增规则event-taxonomy.md 定义了跨会话全局唯一的事件 ID 方案TypePrefixExampleScopeExploration nodeNN01, N02Global跨所有会话ClaimCC01, C02GlobalHeuristicHH01, H02GlobalExperiment planEE01, E02GlobalObservationOO01, O02GlobalSessiondate_seq2026-03-11_001按日期唯一自增规则创建新 ID 前必须先读取既有文件找到当前最大 ID。这条规则贯穿 research-manager/SKILL.md 的 RulesAlways read existing files first — get correct next IDs, avoid duplicates与 session-protocol.md 的 Writing ProtocolRead the target file first to get the next available ID。值得注意的细节探索节点、声明、经验法则、实验计划、观察全部采用全局作用域保证跨会话引用如evidence: [C{XX}]、also_depends_on: [N{XX}]永远可解析会话 ID 使用YYYY-MM-DD_NNN的日期序列格式按日期唯一同一会话的后续事件不需要全局编号这一约定与 exploration-tree-spec.md 的规则“所有also_depends_on引用的 ID 必须存在于树中”“无环、合法 DAG”协同保证跨文件引用链完整。六、Forensic Binding Checklist取证绑定事件分类与路由只是第一步。要让 ARA 真正可审计每条事件必须在落盘时立即建立取证绑定forensic bindings。event-taxonomy.md 给出了五类必须建立的绑定Claim → Proof创建声明时什么证据能证明/证伪它暂无证据则设Proof: [pending]Experiment → Claim该实验测试了哪些声明通过Claims tested:链接Heuristic → Code该技巧在代码库何处实现设置Code ref:Decision → Evidence什么证据或推理驱动了这个决策Dead End → Lesson学到了什么该知识能否防止未来重蹈覆辙关键机制如果当前无法建立绑定则添加一个!-- TODO: bind to {target} --注释作为可追踪的义务trackable obligation——绑定未完成不是静默的而是显式进入 TODO 追踪。这些绑定在 ara-schema.md 中都有对应的字段落点声明必须带Falsification criteria证伪标准与Proof引用实验 ID而非文件路径经验法则必须带Code ref指向src/execution/下实际文件路径实验计划必须带Verifies声明 ID 列表决策节点必须带evidence动机引用父节点。从 compiler/SKILL.md 的 Seal Level 1 校验规则可以确认这些绑定是强制的Claim Proof references (E01, E02...) resolve to experiments.md、Experiment Verifies references (C01, C02...) resolve to claims.md、Heuristic Code ref paths resolve to actual files in src/execution/。七、事件在 ARA 各层的落盘格式分类、标注、编号、绑定都完成后事件以标准化格式写入目标文件。以下是每种事件的完整落盘模板全部源自 event-taxonomy.md 与配套文档。7.1 探索树节点research 事件的家探索树是嵌套 YAML 结构父子关系通过children:键表达形成展示研究者如何遍历搜索空间的研究 DAG根节点是tree:下的顶层条目每个节点可含children:缩进的嵌套子节点用also_depends_on: [N{XX}]表达交叉边多父节点叶子节点没有children:键。tree: - id: N01 type: question title: {root research question} provenance: user timestamp: YYYY-MM-DDTHH:MM description: {what is being explored} children: - id: N02 type: experiment title: {what was tested} provenance: ai-executed timestamp: YYYY-MM-DDTHH:MM result: {what happened — include numbers} evidence: [C{XX}, {figure/table refs}] children: - id: N03 type: decision title: {choice made based on N02 results} provenance: user timestamp: YYYY-MM-DDTHH:MM choice: {what was chosen and why} alternatives: - {option not chosen} evidence: {what motivated this — reference parent nodes} children: - id: N04 type: dead_end title: {approach that failed} provenance: user timestamp: YYYY-MM-DDTHH:MM hypothesis: {what was expected to work} failure_mode: {why it failed} lesson: {what was learned} - id: N05 type: experiment title: {alternative that worked} also_depends_on: [N02] # cross-edge: also informed by N02 provenance: ai-executed timestamp: YYYY-MM-DDTHH:MM result: {outcome} evidence: [C{XX}] - id: N06 type: dead_end title: {sibling approach tried from N01} provenance: user timestamp: YYYY-MM-DDTHH:MM hypothesis: {what was expected} failure_mode: {why it failed} lesson: {what was learned — motivated N02s direction} - id: N07 type: pivot title: {new top-level research thread} provenance: user timestamp: YYYY-MM-DDTHH:MM from: {previous direction} to: {new direction} trigger: {what caused the change}7.2 节点类型必填字段参考TypeRequired FieldsWhen to Usequestiondescription根研究问题或子问题decisionchoice,alternatives,evidence用户在选项之间做了选择experimentresult,evidence测试/基准产生了结果dead_endhypothesis,failure_mode,lesson方案被放弃pivotfrom,to,trigger重大方向变更结合 exploration-tree-spec.md 可以补充两点dead_end 是“对下游 Agent 最有价值的节点类型”——它让后续 Agent 不必重新发现已知失败每个节点还应有support_level: explicit | inferredexplicit表示该节点直接植根于源材料应附带source_refsinferred表示是对论文逻辑的合理重建绝不能伪装成字面会话日志。事件分类学中的 research 事件来自真实会话记录天然属于 explicit 一侧。7.3 Claimlogic/claims.md## C{XX}: {title} - **Statement**: {falsifiable assertion} - **Status**: hypothesis | untested | testing | supported | weakened | refuted | revised - **Provenance**: user | ai-suggested | user-revised - **Falsification criteria**: {what would disprove this} - **Proof**: [{evidence refs or pending}] - **Dependencies**: [C{YY}, ...] - **Tags**: {comma-separated}7.4 Heuristiclogic/solution/heuristics.md## H{XX}: {title} - **Rationale**: {why this works} - **Provenance**: user | ai-suggested | user-revised - **Sensitivity**: low | medium | high - **Code ref**: [{file paths}]7.5 Observationstaging/observations.yaml- id: O{XX} timestamp: YYYY-MM-DDTHH:MM provenance: user | ai-suggested | ai-executed content: {raw observation} context: {what was happening} potential_type: claim | heuristic | decision | unknown promoted: false注意potential_type字段observation 在进入 staging 时就带着“未来可能升级为哪类”的猜想这为成熟度提升maturity promotion预设了去向。7.6 Session Recordtrace/sessions/YYYY-MM-DD_NNN.yamlsession: id: YYYY-MM-DD_NNN timestamp: YYYY-MM-DDTHH:MM summary: {one-line summary of what happened} 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: {what} ai_actions: - action: {what AI did} provenance: ai-executed files_changed: [{paths}] claims_touched: - id: C{XX} action: created | advanced | weakened | confirmed provenance: user | ai-suggested open_threads: - {what needs follow-up} ai_suggestions_pending: - {unconfirmed AI suggestions from this session}会话记录是 Process Eventsai-action、ai-suggestion、user-direction的落盘处同时聚合了本会话中所有写入其他 ARA 文件的事件摘要。八、会话协议中的事件检测循环与冲突处理事件分类学不只是“结束后的整理”它贯穿会话生命周期。依据 session-protocol.mdLive PM 在会话的三个阶段持续运转8.1 会话中的 Event Detection Loop每次实质性交流后评估以下八个问题对应事件分类与路由1. Decision made? → write to exploration_tree.yaml 2. Result observed? → write to exploration_tree.yaml evidence/ 3. Approach failed? → write dead_end to exploration_tree.yaml 4. Claim stated? → write to claims.md 5. Trick discovered? → write to heuristics.md 6. Direction changed? → write pivot to exploration_tree.yaml 7. AI wrote code? → log to session record (ai_actions) 8. Interesting note? → write to staging/observations.yaml8.2 写入协议先读取目标文件获取下一个可用 ID追加新条目——绝不覆盖既有内容立即建立绑定claim→proof、heuristic→code_ref、decision→evidence依据信息来源使用正确的 provenance 标签写入前在脑中校验 YAML 结构有效性除非被问起保持静默——不要主动提及日志记录。8.3 冲突检测写入新条目时检查三类冲突新声明与既有声明矛盾 → 两边都加!-- CONFLICT: see C{XX} --新证据削弱既有声明 → 把声明状态更新为weakened新决策推翻先前决策 → 记录为pivot并链接到原始决策。8.4 成熟度提升Maturity Tracker在 epilogue 阶段复查staging/observations.yaml时执行同一主题 3 条以上观察→ 提升到对应层标记ai-suggested带实验证据的观察→ 提升到evidence/与某声明矛盾的观察→ 标记!-- CONFLICT: contradicts C{XX} --过期观察超过 3 个会话→ 标记stale: true。8.5 跨会话连续性ARA 本身就是记忆Agent 没有内建跨会话记忆ARA 本身即是记忆session_index.yaml记录何时发生了什么claims.md记录已知与未知exploration_tree.yaml记录完整研究轨迹staging/observations.yaml记录未了结的线索。每次会话开始时读取这些文件即可重建完整项目上下文open threads 自动向前传递——事件分类学正是保证这套“记忆系统”写入时结构一致、检索时路径确定的基础。九、完整实战示例一场会话如何被记录把上述所有机制串起来看一段真实场景如何被分类、标注、路由与绑定会话过程用户提问Can we use sliding window attention to reduce memory?questionprovenance:user路由到 exploration_tree 根节点 N01AI 建议SWA with window 2048 could cut KV cache by 75%.ai-suggestion写入 session record 的ai_suggestions_pending用户拍板Lets go with SWA, keep global attention every 8th layer.decisionprovenance:user写入 N01 的 childrenalternatives记录未被选中的全窗口注意力方案AI 实现并跑 benchmark报告 p95 latency dropped 40%, memory -70%experimentresult_tableprovenance:ai-executed同时写入探索树 N02 与evidence/tables/table1_...result字段带上数字AI 基于结果断言SWA preserves quality within 1% at 64k context.claimprovenance:ai-suggested写入 claims.md C01Falsification criteria注明 “若 128k 长度下质量下降超过 1% 则证伪”Proof: [pending]绑定 TODO用户纠正Not 1% — quality drops 2.1% at 128k.user-revisedC01 来源升级并保留修订历史早先的全窗口方案被放弃Full attention OOMs at 64k — going back to SWA baseline.dead_endN03含hypothesis/failure_mode/lesson会话结束生成 session record2026-09-23_001.yaml更新session_index.yaml运行 maturity tracker输出一行摘要[PM] Session captured: 1 decisions, 1 experiments, 1 claims advanced. 1 open thread.这场会话结束后任何人人或 Agent都可以从exploration_tree.yaml沿着 N01→N02→N03 重走研究轨迹从claims.md找到 C01 的完整状态与证伪标准从evidence/tables/拿到未经修饰的原始数字从会话记录的 provenance 聚合判断这条知识有多少经过用户确认——这就是事件分类学支撑起的完整审计链。十、规则汇总与最佳实践10.1 Live PM 的七条铁律research-manager/SKILL.md 收尾的规则是事件分类系统正确运转的前提任务中绝不运行——仅在任务结束后的 epilogue 阶段运行绝不编造事件——只记录真实发生或讨论过的内容绝不升级来源——ai-suggested保持到用户明确确认始终先读既有文件——获取正确 ID避免重复建立取证绑定——claims→proof、heuristics→code、decisions→evidence追加而非覆盖——新增条目绝不替换既有内容保持 YAML 有效——写入后校验结构。10.2 分类实践要点信号优先于措辞分类依据是 signals 列给出的上下文信号而不是用户话术的表面形式experiment 是双写事件结果要同时进入轨迹trace与证据evidence两者缺一不可拿不准就进 stagingobservation是安全的兜底成熟后按规则提升来源拿不准就用ai-suggested沉默、AI 推断、未确认的建议都归于此绑定无法立即建立时写 TODO 注释让义务显式化、可追踪ID 自增必须读文件跨会话全局 ID 是引用链可解析的前提。参考文件索引事件分类与路由规则本文核心来源标注系统四类标签语义与边界情况会话协议会话全周期的记录流程Live PM 技能定义任务边界与提取清单ARA 目录 Schema字段级完整参考探索树 YAML 规范节点类型与 DAG 规则Universal Compiler4 阶段认知协议与 Seal 校验【免费下载链接】AI-Research-SKILLsComprehensive open-source library of AI research and engineering skills for any AI model. Package the skills and your claude code/codex/gemini agent will be an AI research agent with full horsepower. Maintained by Orchestra Research.项目地址: https://gitcode.com/gh_mirrors/ai/AI-Research-SKILLs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考