企业官网建设流程全解析

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

本篇技术指南以research-manager技能的常开会话协议（session-protocol）为骨架，完整剖析 AI 研究 Agent 如何在不打断任务的前提下，自动记录决策、实验、死胡同、主张与启发式，并通过ara/目录实现跨会话记忆重建。读完本文，你将掌握会话启动加载、事件检测循环、provenance 判定、冲突检测、会话收尾与紧急断线恢复的完整可落地流程，以及与之配套的事件分类、溯源标签与 ARA 目录结构的实战细节。

一、协议定位：为什么需要一个"常开"的会话协议

research-manager（即 Live PM，Live Research Project Manager）是一套面向 AI 研究 Agent 的"现场研究项目经理"技能。其核心思想是：研究过程中的每个决策、每个实验、每条主张，都值得被结构化记录下来，形成一份可被 Agent 和人类共同阅读、检索、引用的 Agent-Native Research Artifact（ARA）。

而 session-protocol.md 描述的就是这份记录机制如何随会话自动运转的完整内部规程——它"Always-On（常开）"，无需任何命令触发，在会话开始、进行中、结束三个阶段分别执行既定动作。

协议的首要设计原则是可见性最小化、侵入性最小化：

• 不打断用户的任务流：记录动作全部"静默"完成；
• 不污染工作上下文：ara/目录只在需要时读取，避免占用宝贵的上下文窗口；
• 不伪造历史：只记录真实发生或讨论过的事件，绝不编造；
• 不越权升级：AI 的推断永远标记为ai-suggested，只有用户显式确认后才能升级为user。

协议文档开头即声明："The Live PM runs automatically. No commands needed."（Live PM 自动运行，无需任何命令）。这一定位与"epilogue 式"的补充说明不同——后者（见 SKILL.md 中的描述）强调在任务结束后扫描会话历史，而本协议更强调实时、增量、贯穿全程的记录方式，两种视角共同构成 ARA 的完整记录体系。

二、会话开始（自动执行）

每次新会话启动时，Live PM 会根据ara/目录是否存在，走两条不同的分支。

2.1 当ara/目录已存在

第一步：静默读取状态。不向用户播报任何日志，直接读取三个核心文件以重建上下文：

第二步：按需交付简报（contextual briefing）。这是协议中非常讲究的分寸感：

• 用户直接进入任务 → 把上下文织入第一句回复，而非单独铺开。协议给出了示例话术：

  "Before we dive in — last session you were testing C04, result was 92%. Two open threads." （在开始之前——上次会话你在测试 C04，结果是 92%，还有两个未解决问题的线程。）

• 用户主动问"现在进展如何 / 上次停在哪" → 给出完整简报；
• 绝不在用户明显有明确任务时，用简报抢占开头。

第三步：创建会话记录。按ara/trace/sessions/YYYY-MM-DD_NNN.yaml命名规则新建当日会话文件（NNN为当日序号），初始化为起始时间 + 空事件列表。

2.2 当ara/目录不存在

协议明确约束了初始化行为，避免打扰用户：

1. 首次交互不主动创建ara/；
2. 只有当检测到研究级讨论（决策、假设、实验）时，才问一次：

   "Want me to track this project's research process? I'll set upara/."

3. 用户确认后，执行完整目录初始化，并从当前对话内容 bootstrap 种子数据。

初始化需要创建完整的 ARA 目录结构（命令来自 SKILL.md 的 Initialization 一节）：

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

随后写入 8 个种子文件：

三、会话进行中：持续、隐形的记录循环

3.1 事件检测循环（Event Detection Loop）

在每一次实质性交流之后，Live PM 都要对刚刚发生的交流做一次八项检查，把事件路由到对应的 ARA 文件：

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) （AI 写了代码？） 8. Interesting note? → write to staging/observations.yaml （有趣的零散笔记？）

这套循环与 event-taxonomy.md 中的完整事件分类相互印证。事件被分为五类，各有明确的路由目标：

同时，event-taxonomy 给出了一条路由决策树，帮助判断一条信息该去哪：

是否是在多个备选间做选择？ → decision（trace） 是否是定量结果/实验产出？ → experiment（trace）+ 证据数据（evidence/） 是否是被放弃且有原因的方案？ → dead_end（trace） 是否是可证伪的断言？ → claim（logic/claims.md） 是否是有原理支撑的实现技巧？ → heuristic（logic/solution/heuristics.md） 是否是重大方向转变？ → pivot（trace） 是否是正在探索的研究问题？ → question（trace） 以上都不是 → observation（staging）

不值得记录的内容（协议明确列出，避免记录噪音）：常规文件读取、拼写修正、格式调整、git 操作、依赖安装，以及澄清性问题（除非其答案是决策）。

3.2 写入协议（Writing Protocol）

向 ARA 文件写入任何内容，都必须遵守六条铁律：

1. 先读目标文件，获取下一个可用 ID（避免 ID 冲突）；
2. 只追加（Append），绝不覆盖已有内容；
3. 立即建立绑定（bindings）：claim→proof、heuristic→code_ref、decision→evidence；
4. 使用正确的 provenance 标签，依据信息的产生者判定；
5. 保持 YAML 合法——写入前在脑中校验结构；
6. 保持沉默——除非被问到，不要在对话里提及记录动作。

ID 约定（来自 event-taxonomy）是全局递增的：探索节点用N01、主张用C01、启发式用H01、实验计划用E01、观察用O01、会话用日期_序号（如2026-03-11_001）。自动递增的规则是：必须先读现有文件找到当前最大 ID，再创建新 ID。

3.3 Provenance 决策树：溯源标签如何判定

溯源（provenance）是 ARA 体系的基石——它决定了一条知识的认知地位：用户亲口说的主张，与 AI 从代码输出推断出的主张，权重完全不同。会话协议给出如下决策树：

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

四种标签的完整语义在 provenance-tags.md 中展开：

provenance-tags.md 还补充了升级路径规则：ai-suggested只有在用户显式确认后才能升级为user或user-revised；沉默不等于确认——AI 提出建议后用户不回应，该条目保持ai-suggested不变。此外还提供了会话记录中的 provenance 聚合统计格式：

provenance_summary: user_confirmed: 5 ai_suggested: 3 ai_executed: 7 user_revised: 1 confirmation_rate: 0.625 # user / (user + ai-suggested)

这个confirmation_rate（人工确认率）是衡量 ARA 整体可信度的重要信号：人类确认的知识占比越高，artifact 质量信号越强。

3.4 会话记录（Session Record）里积累什么

运行中的会话记录trace/sessions/YYYY-MM-DD_NNN.yaml是本次会话的单一事实来源，累计以下几类内容：

• 写入任意 ARA 文件的每个事件（类型、ID、provenance、一行摘要）；
• AI 动作：写了什么代码、跑了什么命令、创建/修改了哪些文件；
• 被触动的主张：哪些 claim 被创建、推进、削弱或确认；
• 未解决问题的线程（open threads）：未解决的问题或未完成的工作；
• 待确认的 AI 建议：AI 提出但用户尚未确认的内容。

对应的完整 YAML 结构（来自 SKILL.md 的 Writing Formats 一节）如下：

session: 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}"

3.5 冲突检测（Conflict Detection）

写入新条目时，Live PM 必须对照已有内容做冲突检查，这是 ARA 保持认知一致性的关键机制：

四、会话结束（自动执行）

4.1 结束触发条件

Live PM 通过以下信号判断会话即将/已经结束：

• 对话明显收尾（"谢谢"、"就这些了"、用户不再发言）；
• 上下文窗口被压缩（系统开始总结旧消息，说明会话进入尾声）；
• 用户显式告别或表示工作完成。

4.2 收尾流程

第一步：终结会话记录。设置ended时间戳，写一行核心摘要（会话主要成果），并确保所有缓冲事件已 flush 到各 ARA 文件。

第二步：更新会话索引。向ara/trace/sessions/session_index.yaml追加一条记录：

- id: "YYYY-MM-DD_NNN" date: "YYYY-MM-DD" summary: "{main outcome}" events_count: {N} claims_touched: [C{XX}, ...] open_threads: {N}

第三步：对 staging 区执行成熟度检查（Maturity Check）。协议定义了三条晋升规则：

• 同一主题有 3+ 条观察→ 自动晋升到对应层级（标记为ai-suggestedprovenance）；
• 带实验证据的观察→ 晋升到evidence/；
• 过时条目（跨越 3 个以上会话仍未处理）→ 标记stale: true。

SKILL.md 中的 Maturity Tracker 补充了一条：与某条主张矛盾的观察→ 标记<!-- CONFLICT: contradicts C{XX} -->。

第四步：一行收尾简报（严格保持一行，格式固定）：

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

五、跨会话连续性：ARA 本身就是记忆

5.1 记忆如何持久化

Agent 本身没有内置的跨会话记忆——每个会话的上下文窗口都是全新的。协议的答案是：ARA 目录就是记忆。各文件各司其职：

这与 0-autoresearch-skill/references/agent-continuity.md 中"workspace files are your memory"（工作区文件就是记忆）的理念一脉相承：无论是 wall-clock 循环驱动的长时自主研究，还是跨会话的人工协作，持久化的真相始终落在磁盘文件上，而非 Agent 的上下文里。

5.2 会话开始的重建机制

每次新会话启动时，通过读取上述文件即可完整重建项目上下文。Agent 通过它亲手构建的 artifact，"记住"了一切——这正是本协议"会话开始静默读状态"步骤背后的深层设计意图。

5.3 未解决问题线程（Open Threads）的自动接力

未解决问题的线程跨会话自动传递，形成接力闭环：

• 每个会话记录都列出open_threads；
• 会话开始时，最新会话的 open threads 会被自动呈现（纳入简报）；
• 当某个线程在后续会话中被解决，在该会话的事件记录中注明即可。

六、紧急 / 非正常结束（Emergency / Abrupt End）

如果对话在没有正常收尾流程的情况下中断（如用户直接关闭、进程崩溃、上下文被强行压缩），协议给出了明确的兜底保证：

• 已写入 ARA 文件的事件是安全的——因为写入是增量、实时的，而不是在结尾批量提交；
• 会话记录可能不完整——下次会话启动时应检测到这种不完整并在会话记录中注明；
• 不会丢失数据——实时写入（write-in-real-time）的设计，让最坏情况也只是"收尾元数据缺失"，而核心研究内容毫发无损。

这也是整个协议最重要的架构决策之一：把写入从"会话结束的批处理"改为"事件发生的即时处理"，用增量持久化换取崩溃安全。

七、协议背后的配套体系

session-protocol 是 ARA 记录体系的"运行时规程"，它与同技能及兄弟技能中的多个规范文档咬合紧密：

• event-taxonomy.md：提供事件分类、路由决策树、ID 约定与取证绑定清单（Claim→Proof、Experiment→Claim、Heuristic→Code、Decision→Evidence、Dead End→Lesson，若暂无法绑定则写入<!-- TODO: bind to {target} -->注释作为可追踪义务）；
• provenance-tags.md：定义四种溯源标签的完整语义、升级规则、混合溯源条目与会话级溯源聚合；
• ara-schema.md：定义 ARA 全量目录 schema 与逐文件字段级格式，是写入格式的最终权威；
• exploration-tree-spec.md：定义探索树 YAML 规范（节点类型、children嵌套、also_depends_on交叉边、support_level显式/推断标注），并明确dead_end 是"对下游 Agent 最有价值的节点类型"——它帮未来的 Agent 避免重新发现已知的失败；
• review-dimensions.md：从 Evidence Relevance、Falsifiability、Scope Calibration、Argument Coherence、Exploration Integrity、Methodological Rigor 六个维度对 ARA 做语义级审查——session-protocol 保证记录发生，rigor-reviewer 保证记录质量。

八、总结：一条可运行的"研究元数据管线"

纵观全协议，Live PM 实际上构建了一条研究元数据管线：会话开始读取状态 → 进行中按 8 项检查持续捕获事件 → 按 provenance 决策树标注来源 → 按事件分类路由到对应 ARA 文件 → 会话结束做成熟度晋升与索引归档 → 跨会话通过 artifact 重建记忆 → 异常中断靠增量写入兜底。

其核心价值可以归纳为四点：

1. 忠实性：只记录真实发生的内容，ai-suggested的保守默认杜绝了 AI 自我美化历史；
2. 可审计性：每一条知识都带 provenance 标签和证据绑定，可追溯到来源；
3. 连续性：Agent 没有记忆，但 artifact 有——跨会话上下文因此得以完整重建；
4. 崩溃安全：增量写入让任何时点的中断都不会丢失已捕获的研究过程。

对于任何想要让 AI 研究 Agent"记住并传承研究过程"的团队而言，这套会话协议提供了一个开箱即用的实现范式：它不需要复杂的记忆基础设施，只需要一个结构化的目录、一套严谨的分类学，以及一个懂得何时沉默、何时记录、何时晋升的 Live PM。

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