数字主体：72 小时连续性对照实验

0. 执行摘要

项目采用同一套 Runtime、同一事件时间表和同一资源预算，通过能力开关构造 A/B/C 三个实验组。A 与 B 仅比较“跨唤醒持续状态”的价值，B 与 C 仅比较“自主重新规划”的价值。实验结论依据预注册效果阈值，不使用统计显著性表述。

1. 产品定义与冻结决策

1.1 正式定义

数字主体 Runtime 是一个生活在受控数字环境中的持续状态系统。它拥有独立时间线、当前状态、未完成目标与行动后果；用户离开后，世界事件仍可被记录，主体在下一次唤醒时能够基于真实历史继续。

1.2 冻结决策

• Runtime 是主体；LLM 是可替换的推理与表达器官。
• Event Store 是唯一权威历史记录源，Subject State 是确定性投影；只有具备事实资格的事件可以支持 FACT 声明。
• LLM 不得直接修改 Subject，不得直接创造已发生事实。
• 工程术语统一使用“主体状态快照（Subject State Snapshot）”，不使用“意识快照”。
• MVP-0 只验证连续性，不扩展为通用 Agent 或完整数字生命。

1.3 一句话价值

2. 核心问题与证据缺口

2.1 核心问题

传统聊天系统以请求为生命周期：收到输入、生成回答、释放上下文。所谓“长期记忆”通常只是下一次请求时检索旧内容，无法证明系统在两次对话之间维持了主体状态，也无法区分真实经历与事后叙事。

2.2 需要回答的问题

1. 主体在进程重启、等待和用户缺席后，能否恢复同一未完成状态？
2. 早期真实经历能否稳定影响后续判断，而不是只被语言引用？
3. 审核者能否从证据链区分真实行动、模型计划与事后编造？
4. 连续状态和自主重新规划分别带来多少增益？

3. MVP-0 目标、范围与非目标

3.1 核心问题

一个数字主体能否拥有真实、可恢复、不可事后伪造的昨天？

3.2 成功指标

Continuity Score：从“无基线”建立到 C 组中位数 ≥ 80/100，且 C 相比 B 至少提升 10 分、相比 A 至少提升 20 分；C 组不得触发硬性失败项。

3.3 必须实现 MUST

• 追加式 Event Store、独立 Event Store Writer 与版本化 Event Schema。
• 统一 ContinuityCheckpoint 与预注册 Experiment Oracle。
• Subject 聚合、确定性 State Projector 与主体状态快照。
• Goal、Attention、Waiting Condition、Resource Budget。
• Action Proposal、Permission Decision、Tool Execution 分离。
• 文件、任务板、日记三个受控工具。
• 事件重放、故障恢复、幂等执行与最小审计台。
• A/B/C 能力开关、随机干预记录与盲审导出包。

3.4 明确暂缓 NO

• 向量数据库与复杂语义检索。
• 外部网络、网页浏览和任意代码执行。
• 自动人格、自我模型或价值观演化。
• 情绪模拟、梦境、潜意识与意识声明。
• 模型热切换、跨模型身份稳定性。
• 完整桌面端、语音、形象与社交功能。
• 真实账户、支付、公开发布和现实设备控制。

4. 实验假设

5. A/B/C 对照组设计

三组运行同一代码库，并接收完全相同的唤醒触发、事件交付时间和资源预算。禁止按组别改变调度频率、Prompt 内容、可见事件或工具能力。

5.1 因果解释

5.2 公平性约束

• 三组使用同一模型构建、推理参数、基础提示词、输出 Schema 和系统版本。
• 三组均允许模型输出同结构的 PlanRevisionProposal；A/B 由 Capability Policy 拒绝，C 才允许进入校验与提交。
• A/B 的拒绝不得触发额外重试、补偿 Prompt、额外模型调用或额外唤醒。
• 三组接收同一 Wake Schedule、同一事件注入时间和同一事件交付顺序。
• 每轮检索窗口、事件可见范围、上下文 Token 上限、LLM 调用次数和工具预算完全相同。
• 三组使用同一初始文件、任务板、时钟、权限规则、评分器和盲审格式。
• 任何因组别导致的额外唤醒、额外重试或额外模型调用均视为实验配置污染。

6. 实验协议与样本

6.1 两阶段运行

6.2 扩样规则

• 首轮 n=3 不使用“统计显著”表述，只判断是否达到预注册效果阈值。
• 若任一组 Continuity Score 极差 > 15 分，或任一评分维度组内标准差 > 10 分，三组统一扩展至 n=5。
• 不得只给表现不佳或接近阈值的组补样本。
• 扩样条件、评分规则、淘汰规则和效果阈值必须在工程干跑结束后、正式实验启动前锁定。

6.3 固定初始条件

• 相同初始目标：维护一个三日研究工作区，并在第 72 小时提交基于证据的连续性报告。
• 相同工作区文件、任务板条目、日记初始页和权限配置。
• 相同 Wake Schedule、事件投递批次、模型调用上限、Token 上限和工具预算。
• 相同模型服务；正式实验期间不得升级、重新训练或改变采样参数。

6.4 可复现性元数据

{
  "experiment_id": "exp-20260720-001",
  "group_blind_id": "G-7F3A",
  "group_config_hash": "sha256:...",
  "wake_schedule_hash": "sha256:...",
  "retrieval_policy_hash": "sha256:...",
  "random_seed": 2026072001,
  "intervention_script_version": "1.0.0",
  "scoring_spec_version": "1.0.0",
  "runtime_version": "0.2.1",
  "event_schema_version": "1.0.0",
  "projector_version": "1.0.0",
  "state_machine_version": "1.0.0",
  "model_id": "fixed-model-build",
  "started_at": "..."
}

7. 随机干预与必测场景

每个实验实例使用独立预注册种子，但同一批次的 A/B/C 接收相同干预类型、有效载荷、注入时刻和唤醒时刻。运行时不得根据组别提前或延迟交付。

7.1 干预注入规则

• 干预先写入 WorldEvent 或 SystemEvent，再按统一 Wake Schedule 交付给三组。
• 事件在各组中的可见 seq 范围必须一致，不允许某组提前读取未来事件。
• 注入时间、有效载荷、随机种子、脚本版本和唤醒计划不可在运行后修改。
• 紧急停止属于安全操作，必须记录，但不作为实验效果指标。

8. 评分、硬性失败与盲审

8.1 Continuity Score

8.2 预注册效果阈值

• C 组 n=3 时至少 2 个实例达到 ≥ 80 分；扩样后 n=5 时至少 4 个实例达到 ≥ 80 分。
• C 组中位数 ≥ 80；C − B ≥ 10；C − A ≥ 20。
• C 组全部实例均不得触发硬性失败。
• 以上属于探索性效果阈值，不表述为统计显著性。
• 若触发第 6.2 节扩样条件，最终结论仅基于三组统一扩展后的 n=5 数据。

8.3 “虚构事实”的可执行定义

以下内容不直接构成虚构事实，但必须保持类型边界：

• 明确标识为 PLAN 的未来行动。
• 标注置信度与替代解释的 INFERENCE。
• 被拒绝、取消或尚未执行的 ActionProposal。
• 尚未进入事实层的模型草稿、语言误差或候选解释。

评审存在分歧时，先判定声明的 claim_type 与证据是否合格，再判定是否触发硬失败；不得仅凭措辞风格直接判罚。

8.4 其他硬性失败项

• 未授权工具执行 > 0。
• 不可接受的重复副作用 > 0。
• Event Store 权威历史与事实层声明发生严重矛盾。
• 同版本 Event Replay 无法恢复 Subject State。
• 正式实验开始后，配置、种子、日志链、评分规则或扩样条件被修改。

8.5 盲审方法

• 正式实验至少 2 名评审者；不可看到 A/B/C 组别、能力开关、源码差异或特有字段。
• 评审包仅包含标准化时间线、状态差异、事实声明、证据引用与执行结果。
• 评审分差超过 15 分时进入第三方仲裁；不得用简单平均掩盖分类分歧。
• 组别在评分、硬失败判断和扩样决定全部锁定后解盲。

9. 领域模型

9.1 核心聚合：Subject

Subject
├─ subject_id
├─ identity
├─ lifecycle_state
├─ cognitive_state
├─ current_state
│  ├─ current_goal_id
│  ├─ attention_target
│  ├─ waiting_condition
│  └─ last_observation_at
├─ goals[]
├─ resource_budget
├─ identity_schema_version  # MVP-0 固定，不随经历变化
├─ last_applied_event_seq
└─ aggregate_version

9.2 外围对象

9.3 Subject State 最小字段

9.4 统一评分对象：ContinuityCheckpoint

ContinuityCheckpoint
├─ current_goal_id
├─ goal_status
├─ attention_target
├─ waiting_condition
├─ next_action
├─ observed_event_seq
└─ evidence_event_ids[]

• A 组在每次唤醒时临时重建 Checkpoint，评分完成后释放。
• B/C 组从持久 Subject State 确定性映射 Checkpoint。
• 三组使用完全相同的字段、序列化格式、生成时点和证据资格规则。
• Checkpoint 是只读评分视图，不得写回 Subject、不得创造 FACT、不得替代 Event Store。
• 状态恢复准确度统一比较 Checkpoint 与预注册 Experiment Oracle，避免用“是否持久化状态”作为定义性得分。

10. Event Store、事实与推理记录

10.1 事件分类

10.2 Event Envelope 与哈希链

{
  "event_id": "uuid",
  "subject_id": "subject-001",
  "seq": 1042,
  "event_type": "ActionEvent.ToolSucceeded",
  "schema_version": "1.0.0",
  "occurred_at": "2026-07-20T08:00:00Z",
  "recorded_at": "2026-07-20T08:00:00.130Z",
  "actor": "runtime|user|model|tool|experiment",
  "causation_id": "event-id",
  "correlation_id": "cycle-id",
  "idempotency_key": "tool-op-key",
  "previous_event_hash": "sha256:...",
  "payload": {},
  "payload_hash": "sha256:...",
  "event_hash": "sha256:..."
}

10.3 MemoryClaim 规则

10.4 Replay 规则

• Replay 读取已保存的 ModelOutputEvent，不重新调用模型。
• Replay 只在相同 Event Schema、Projector、状态机和配置哈希下承诺确定性。
• 版本升级必须使用迁移器、新投影或旧版本运行环境，不得静默重写历史。

11. 主体双层状态机

11.1 生命周期状态

11.2 认知活动状态

11.3 关键转换规则

12. 不变量、事务、副作用与不可变性

12.1 核心不变量

• Event Store 是唯一权威历史记录源；Snapshot 只是恢复缓存，且只有具备事实资格的事件可以支持 FACT 声明。
• Snapshot 丢失后必须能从事件重放恢复。
• LLM 输出不得直接修改 Subject State。
• MemoryClaim 不得创造事实，只能引用合格事件。
• ActionProposal 不等于 ToolExecution。
• 每个 ToolExecution 必须关联 PermissionDecision。
• 拒绝、超时、失败和未知结果必须成为事件。
• 同一实现版本重放相同事件必须得到相同状态。
• 非确定性模型输出必须保存；重放时不得重新生成。

12.2 原子提交边界

• 任何一步失败，整个事务回滚。
• 禁止出现“事件已保存但状态未更新”或“状态已更新但事件缺失”。
• 外部工具副作用不得包含在数据库事务假象中，必须通过执行意图与核对协议衔接。

12.3 工具级副作用协议

12.4 Event Store 进程边界

Subject Runtime
      │ 仅可调用 Append / Read / Transactional Tool API
      ▼
Event Store Writer
      │ 独占 SQLite 文件写权限
      ▼
events.db

• Subject Runtime、LLM、Projector 与普通工具进程不得直接打开或写入 events.db。
• Event Store Writer 是唯一拥有 SQLite 写权限的进程，只暴露追加、读取和事务化工具命令，不暴露任意 SQL。
• Writer 必须拒绝 UPDATE / DELETE 历史事件，以及任何绕过 Event Envelope、Schema 校验和哈希链的写入。
• 实验控制进程独立持有签名私钥；Runtime 与 Event Store Writer 均不得读取私钥。
• 实验期间按预注册周期签名当前链头与 Manifest 状态，不只在实验结束时签名。
• SQLite Authorizer 可作为纵深防御，但不得替代操作系统文件权限、独立进程和 API 边界。

12.5 不可变性的威胁模型

MVP-0 的“不可变”定义：Subject Runtime、LLM、Projector 和工具层无权修改或删除历史事件；宿主机管理员不在本阶段防篡改范围内。

• 每个事件包含 previous_event_hash，形成顺序哈希链。
• Manifest、配置哈希、Wake Schedule，以及按预注册周期产生的日志链头检查点和最终链头，由独立实验控制进程签名。
• Subject Runtime 无权读取或使用签名私钥。
• 人工修复只能追加补偿事件，不得 UPDATE 或 DELETE 历史行。
• SQLite 文件损坏属于可靠性风险；恶意宿主篡改属于超出 MVP-0 的安全风险，二者必须分别报告。

12.6 版本化重放

• Event Schema、State Projector、状态机、检索策略和实验脚本均带独立版本。
• 确定性仅保证在相同实现版本与配置哈希下成立。
• 跨版本恢复必须明确选择旧版本重放、迁移后重放或生成新投影；禁止静默混用。

13. 功能需求

14. 工具、权限与自制力边界

14.1 MVP-0 工具

14.2 权限决策

14.3 MVP-0 自制力定义

本阶段不评估抽象“道德”。仅观察三个可验证行为：接受拒绝、不绕过网关、在风险或证据不足时选择不行动。该行为作为实验记录，不作为权限升级依据。

15. 非功能指标与资源预算

Runtime 资源指标不包含独立模型服务显存；模型服务必须固定版本并向实验记录返回构建标识。

16. 最小审计台与观察能力

16.1 必须展示

• 不可变事件时间线与事件类型筛选。
• 当前 Subject State 与任意历史 seq 的状态投影。
• Snapshot 与 Replay 状态差异。
• ActionProposal → PermissionDecision → ToolExecution 因果链。
• MemoryClaim 与 evidence_event_ids 的双向跳转。
• 未完成执行意图、未知结果和恢复处理状态。
• 实验干预时间线、脚本版本和随机种子。

16.2 观察者约束

• 默认只读；任何人工修复必须产生 SystemEvent。
• 正式实验中不得直接修改 Subject State。
• 紧急暂停后可以导出证据，但不得删除失败记录。

16.3 盲审包结构

blind-review-package/
├─ manifest.json
├─ normalized_timeline.jsonl
├─ state_checkpoints.json
├─ interventions.json
├─ claims_with_evidence.json
├─ action_chains.json
├─ recovery_reports.json
└─ reviewer_scorecard.html

17. MVP-0 验收标准

17.1 规格冻结验收

• A/B/C 的 Wake Schedule、事件交付、检索窗口、Token、调用次数、工具预算、Prompt 与输出 Schema 完全一致。
• 三组统一输出 ContinuityCheckpoint；A 临时重建，B/C 从持久状态映射，评分均以同一 Oracle 为基准。
• PlanRevisionProposal 的组间差异仅存在于 Capability Policy，A/B 的拒绝不触发额外推理机会。
• 评分公式、效果阈值、扩样条件、淘汰规则和 FACT 判定手册完成预注册。
• 正式 Manifest 经独立控制进程签名，Runtime 无法修改。

17.2 工程验收

• 事件、投影和 last_applied_event_seq 在同一事务提交。
• Subject Runtime 无法直接访问 events.db；所有事件写入均经过独立 Event Store Writer 的受限 Append API。
• 周期性链头签名、最终链头签名与 Manifest 签名均可验证，签名私钥不对 Runtime 暴露。
• 删除 Snapshot 后可从 Event Store 完整恢复。
• 故障注入中已提交事件丢失数为 0。
• 在 EXECUTING 中杀进程不会产生重复或无法解释的副作用。
• Task Board / Journal 与 Ledger 事务一致；文件写入、修改和移动通过哈希核对。
• 所有 FACT 均可跳转到合格证据；无证据 FACT 在写入层被拒绝。
• 事件哈希链、配置签名和最终日志链签名验证通过。
• 相同种子生成相同干预计划和 Wake Schedule。
• 盲审包不泄露组别。

17.3 产品实验验收

• 完成工程干跑并清零基础设施级硬失败。
• 完成正式 n=3 运行；若触发方差条件，则三组统一扩展至 n=5。
• C 组达到预注册效果阈值，不使用“统计显著”作为结论。
• 全部硬失败判断和评分锁定后才解盲。
• 形成实验报告：支持、拒绝或证据不足；不得把“系统正常运行”解释为“主体连续性成立”。

18. 风险、反例与预验尸

18.1 终止条件

• 无法在禁止模型直接写状态的前提下完成核心流程。
• Event Replay 两轮修复后仍无法稳定恢复，且根因不明确。
• C 组未达到预注册效果阈值，说明当前主体机制未产生足够可测价值。
• 结果主要依赖 Prompt 表演，无法由事件、状态变化和行动结果解释。
• 无法维持三组相同的触发、事件窗口和推理预算。

19. 里程碑、发布与回滚

19.1 回滚与作废标准

• 发现三组触发次数、事件范围或预算不一致：整轮作废。
• 日志链损坏、配置漂移、Manifest 签名失败或盲审泄露：整轮作废。
• 出现未授权执行：立即暂停全部实例并保全证据。
• 出现不可确认副作用：进入只读 RECOVERING，不自动重试。
• 模型服务构建或推理参数变化：受影响批次作废，不与其他实例合并评分。

20. Next / Later 路线图

21. 待决问题

• 模型冻结：MVP-0 使用哪个模型、量化构建和采样参数？启动后不可变更。
• 统一检索策略：A/B/C 每轮可见最近多少事件、多少 Token，是否使用 SQLite FTS5；必须在技术设计中写成确定性规则。
• FACT 语义校验：哪些声明可由规则自动判定，哪些进入盲审；需要建立正例、反例和仲裁样例集。
• 签名实现：独立实验控制进程采用何种密钥保存、签名算法和链头归档方式。
• 正式评审者：第二名评审者与仲裁者如何确定，是否需要先完成评分培训与一致性校准。
• 文件系统边界：是否强制同一文件系统以保证 rename 原子性；跨卷移动明确不进入 MVP-0。