KP 调查场景时间同步与防信息泄露三层协议：面向 CoC 并行调查的形式化建模、协议设计与可复现消融评估

技术报告草案 / 2026 年 7 月 5 日

摘要

《克苏鲁的呼唤》（Call of Cthulhu, CoC）调查场景常出现角色分队：一组调查旧报纸，一组潜入下水道，另一组盘问证人。此时 KP 需要同时处理两个问题。其一，不同场景的叙事时间以不同速度推进，若仅按桌面发言顺序结算，容易出现后果先于原因、角色提前抵达、共享倒计时被遗漏等错误。其二，玩家可能在公共频道旁听到角色并未获得的信息，并在后续行动中把这些信息转化为角色优势。既有规则文本多把该问题交给主持人裁量，社区实践也主要停留在经验建议层面，缺少可记录、可审计、可复盘的运行协议。本文将 CoC 分队调查建模为带信息标签的多场景离散事件系统，并提出 KP 时间同步与防信息泄露三层协议（Keeper Time-Sync and Leakage-control protocol, KTSL）。协议由 Schedule 层、Filter 层和 Coupling 层组成：Schedule 层维护因果偏序、同步屏障、事件提交和有限回滚边界；Filter 层维护信息敏感度、授权受众、输出通道和降密条件；Coupling 层依据共享线索、共享倒计时、共享资源、物理邻近和即时伤害依赖选择松散叙事、investigation exchange、严格轮次或合并场景。本文给出问题模型、核心命题、算法伪码、不变量、证明思路、主持流程、案例轨迹和可复现消融结果。两个确定性 fixture 的三层开关实验显示：Schedule 将因果违反总数从 2 降到 0；Filter 将未授权行动与公共高敏泄露合计从 4 降到 0，并把降密完整度从 0.00 提高到 1.00；Coupling 将高耦合时间漂移从 6 降到 0。H1 至 H3 在 fixture oracle 中均为 2/2。本文仍不把这些结果写成真实桌面实证；它们证明协议对象在受控案例中可复现地工作，也指出下一步需要真实 transcript 与盲审标注来检验外部效度。

关键词： TRPG；Call of Cthulhu；Keeper；时间同步；信息流控制；叙事系统；分布式系统；metagaming

引言

调查类桌面角色扮演游戏的时间问题，比战斗轮次表面上看起来要复杂。战斗场景通常有明确的顺序规则，角色依照敏捷、先攻或其他机制轮流行动；CoC Quick-Start 与 D&D Basic Rules 都把战斗组织成由主持人或先攻顺序管理的轮次流程 [cocquickstart; cocpdf; dndbasic2018]。调查场景则不是这样。玩家可能在同一晚分头行动：一名记者去图书馆查十九世纪的地方报纸，两名医生进入下水道寻找仪式痕迹，一名神父留在教堂解读壁画。桌面上，KP 总要一个场景一个场景地讲；叙事世界里，这些行动却可能同时发生，也可能跨越不同长度的时间。若 KP 按照现实桌面的叙述顺序直接决定叙事顺序，时间错位很快出现。

一个常见例子是这样的。A 在图书馆查到“祭坛位于下水道第三岔口，午夜前必须破坏银钥匙”。KP 为了照顾全桌参与感，在公共频道把这段线索念出来。随后 KP 切到 B 和 C 的下水道场景，问他们打算往哪走。B 的玩家立刻说：“我们去第三岔口。”桌面上，这个选择看似自然，因为玩家刚刚听到了地点。叙事上，它却没有合法路径：B 的角色没有见到日记，没有听到电话，没有遇到能透露地点的 NPC，也没有用其他线索推断出第三岔口。这不是玩家知道多少的问题，而是玩家知识是否已经越权影响角色行动的问题。

这个例子里还藏着另一个问题。假设 A 查日记需要三十分钟，B 和 C 在下水道只行动了两分钟，那么 A 读到地点时，B 和 C 是否已经越过第三岔口？如果 B 和 C 已经进入危险区域，A 的电话是否来得及？如果 D 在教堂解读壁画失败，是否会改变仪式倒计时？这些问题都不是单纯“谁先说话”能解决的。KP 需要维护一个叙事账本，记录哪些事件已经发生，哪些事实已经公开，哪些信息只属于部分角色，哪些局部推进必须在全局上同步。

许多主持人依靠经验处理这些情况。经验当然重要。社区讨论中常见的建议包括更频繁切镜、限制未在场玩家可利用的细节、在合适时机让角色重聚、提醒玩家区分 IC 和 OOC [rpgsplit; rpgmeta]。这些方法能解决一部分桌面问题，但经验方法仍有三个缺陷。第一，它难以传授。新 KP 很难知道什么时候该切镜，什么时候该私聊，什么时候该强制进入轮次。第二，它难以复盘。事后发现某个角色用了旁听信息，往往说不清是哪一处叙述泄露了 payload。第三，它难以迁移。一个 KP 在熟悉队伍中可行的处理方式，换到线上团、录播团、陌生玩家团或高秘密密度模组中可能失效。

本文关心的不是把 CoC 变成一套机械仿真规则。相反，本文的目标是保留 CoC 调查叙事的弹性，同时把几个高风险边界外化出来：哪些事件有因果依赖，哪些信息具有行动价值，哪些场景需要同步，哪些事实已经不可回滚。用更短的话说，本文试图回答：分队调查中，KP 如何在不牺牲可玩性的情况下同时维护叙事时间一致性和角色知识边界？

本文的中心论点是：CoC 并行调查更适合被看作一个带信息标签的多场景离散事件系统，而不是一个需要精确全局时钟的回合系统。对 KP 来说，精确秒表通常不重要；重要的是事件之间的因果偏序、信息的授权传播、共享倒计时的同步，以及角色行动是否具有叙事上可信的知识路径。这个论点分别来自 Lamport 的偏序时间、DIFC 的授权标签和 Riedl-Young 对叙事可信度的分析 [lamport1978; myers1997; riedlyoung2010]。基于这个论点，本文提出 KTSL，即 KP 时间同步与防信息泄露三层协议。

KTSL 的三个层次分别回答三个问题。Schedule 层回答“叙事事件如何排序和提交”。它记录局部时间窗、事件前置条件、happened-before 边、同步屏障和 flashback 可作用的 pending 区域。Filter 层回答“哪些信息可以给谁看”。它为线索和事实标注敏感度、owner、授权受众、降密条件和公共摘要。Coupling 层回答“两个场景需要多强同步”。它用共享线索、共享倒计时、共享 NPC 或物品、物理邻近和即时伤害依赖计算耦合度，再选择 loose causal、investigation exchange、strict round 或 macro scene。

本文作出四项贡献。第一，本文把 CoC 分队调查形式化为带有事件、局部时间、角色知识、玩家观察和信息标签的系统模型，并明确区分玩家听到的信息与角色合法知道的信息。第二，本文综合规则文本、社区实践和学术文献，说明 D&D 严格轮次、Fate exchange、Blades in the Dark flashback、Lamport 因果偏序、分布式仿真、信息流控制和叙事规划分别能为 KP 主持问题提供什么技术启发。第三，本文给出 KTSL 的协议对象、算法伪码、不变量和证明思路，使该协议可以被实现为一页式主持表、电子账本或跑团平台插件。第四，本文实现两个确定性 fixture 和三层开关消融，把 H1 至 H3 从待检验方案推进为可复现的工程证据，同时保留 transcript 审计作为真实桌面外部效度检验。

本文的范围也需要提前说明。第一，本文不声称玩家心理层面可以完全“不知道”旁听内容。公共桌面或语音频道中，玩家听见了就是听见了；协议能控制的是这些内容是否进入角色知识，以及是否转化为可行动优势。这个边界来自本文对 noninterference 的弱化应用，即关注可观察影响而非主体内部记忆 [goguen1982]。第二，本文不把所有主持行为都制度化。低风险、低耦合、低秘密密度的场景不需要完整账本。第三，本文报告的是确定性 fixture 和消融证据，不是大规模真实跑团实证。第九节给出假设、指标、fixture 结果和 transcript 审计方案；在没有真实 transcript 和盲审标注之前，当前结果只能说明协议对象在受控案例中满足预期，不能直接代表真实桌面效果。

问题、缺口与研究方法

目标环境与目标应用

本文的目标环境是 CoC 或类似调查型 TRPG 的分队场景。目标应用不是战斗轮次优化，也不是自动剧情生成，而是 KP 在真人桌面或线上语音跑团中进行运行时协调。这个环境有几个性质。首先，KP 通常全知，但玩家和角色不是全知。其次，事件时间是叙事时间，可能用“几分钟后”“同一晚”“仪式开始前”这样的窗口表达，不必精确到秒。再次，信息传播有角色内路径：看见、听见、阅读、电话、笔记、复述、展示物证、NPC 公开声明。最后，主持的目标并非唯一正确，而是在因果一致、玩家公平、秘密保护和戏剧节奏之间取可接受平衡。

因此，本文的系统边界与传统计算系统不同。这里的“进程”不是机器进程，而是场景或角色小组；这里的“消息”不是网络包，而是角色内通信、物证展示、NPC 转述或共享环境变化；这里的“安全策略”不是保护军事机密，而是防止一个角色使用叙事上没有获得的信息；这里的“性能指标”不是吞吐量，而是时间矛盾数量、未授权行动数量、玩家等待时间和事后 retcon 次数。这个转译需要谨慎。本文只借用结构性概念，不把 TRPG 简化成计算机程序。

现有方法的缺口

围绕分队调查，现有方法大致有四类。第一类是严格轮次，把所有分队场景都按战斗一样轮流结算。它简单，但常常过重。一个人查书、一组人在街上闲逛、另一组在警署交涉，这些场景未必需要秒级同步。强行轮次会把调查变成排队，降低恐怖叙事需要的停顿和不确定感。

第二类是全公开叙述。KP 把所有信息讲给全桌，要求玩家自觉区分 IC 和 OOC。这个方法参与感强，尤其适合录播、教学或低秘密密度场景。但当核心线索、怪物弱点、NPC 身份或陷阱机制在公共频道出现时，玩家很难完全不受影响。问题不在于玩家一定作弊，而在于他们后续的选择很难被区分为角色推理还是玩家记忆。

第三类是全私聊。KP 对每个分队单独开频道，避免其他玩家听见。它能降低直接泄露，但会带来等待成本。一个玩家在私聊中获得十分钟戏份，其他玩家只能等待，桌面共同体验被切碎。更麻烦的是，私聊并不会自动形成角色知识表。会合时谁告诉了谁、说到什么程度、是否展示证据，仍需要记录。

第四类是经验切镜。KP 在玩家犹豫时切到另一组，在危险临近时同步，在必要时让队伍重聚。这是成熟主持中最常见也最灵活的方法。它的问题不是不可用，而是缺少显式标准。什么时候算“必要时”？什么信息可以公开摘要？哪个事件已经不能被 flashback 改写？这些判断若不落到对象和规则上，就很难训练和复盘。

本文把这些缺口概括为四个 gap。G1：既有 TRPG 规则提供战斗同步机制，但对分队调查中的模糊时间窗缺少可迁移模型；CoC 与 D&D 的战斗规则能说明严格轮次如何工作，却不能直接说明低耦合调查如何并行 [cocquickstart; cocpdf; dndbasic2018]。G2：社区实践知道要防 metagaming，却少有把玩家观察、角色知识和公共事实分开的数据结构 [rpgmeta]。G3：私聊和公开叙述之间缺少中间层，KP 往往只能在参与感和保密性之间二选一；Fate 的 exchange 提供 spotlight 单位，但不处理高敏信息标签 [fateexchange]。G4：flashback、补叙和 retcon 的边界不清，BitD 的 flashback 说明补叙有玩法价值，但 CoC 调查还需要区分 pending 与 committed 事实 [bitdsrd; jefferson1985]。

研究方法与证据等级

本文采用跨域概念编译的方法。所谓概念编译，是指从规则文本、社区经验和计算机科学文献中抽取结构相似的机制，再把它们转写为 KP 可以执行的主持对象。这个方法不等同于证明 CoC 与分布式系统完全同构。更准确地说，本文把分布式系统文献用作“命名和约束工具”：它帮助我们说清哪些事件有因果边，哪些信息流是不授权的，哪些场景需要同步屏障。

本文把证据分为三类。A 级证据包括已读取全文的论文、全文规则文本或完整 SRD，可用于支撑主要定义和算法设计。B 级证据包括官方页面、标准页面、高票社区实践和可读全文镜像，可用于支撑工程启发和实践约束。C 级证据包括只读取摘要、元数据或部分扫描页的来源，只作为背景类比，不承担硬性论证。这个等级划分不是形式审查，而是为了避免把“听起来像”误写成“已经证明”。

在写作上，本文采取 systems paper 的结构。引言明确问题、缺口和贡献；背景部分给出术语与证据；模型部分定义系统对象；设计部分给出协议和备选方案；评估部分给出指标、确定性 fixture 消融和后续 transcript 实验方案；相关工作按方法分组讨论，而不是逐篇罗列。由于当前证据来自 deterministic fixture，而非真实跑团 transcript，评估节不会把模拟数值写成真人桌面实证。它同时报告可复现工程检查，并规定如何继续收集数据、如何标注、如何判断协议是否有效。

形式化问题模型

调查系统

定义一次分队调查为如下元组：

$\begin{array}{l}I=\\ langleP,U,S,E,M,T,loc,know,obs,ch,label\\ rangle.\end{array}$

其中，$P$ 是角色集合，$U$ 是玩家集合，$S$ 是场景集合，$E$ 是事件集合，$M$ 是信息单元集合，$T$ 是叙事时间域。函数 $loc(p,t)$ 表示角色 $p$ 在叙事时间 $t$ 所处场景。集合 $know(p,t)$ 表示角色 $p$ 在 $t$ 时刻合法知道的信息。集合 $obs(u,t)$ 表示玩家 $u$ 在桌面层面观察到的信息。谓词 $ch(p\_i,p\_j,t)$ 表示角色 $p\_i$ 到角色 $p\_j$ 在 $t$ 时刻存在合法通信通道。函数 $label(m)$ 给信息 $m$ 赋予敏感度、owner、授权受众和降密条件。

这个模型的关键是把 $know$ 与 $obs$ 分开。玩家听到某条线索，只能说明它进入了 $obs$，不能说明它进入了角色的 $know$。该区分来自两个来源：noninterference 强调一个主体的高敏行为不应影响另一主体的低权限可观察输出，DIFC 强调信息应携带 owner、reader 和 declassification 结构 [goguen1982; myers1997]。角色合法知道信息，至少需要满足一种叙事路径：同场感知、阅读物证、NPC 直接告知、角色内通信、他人复述、物证展示或经过 KP 认可的推理。叙事规划文献进一步提醒，角色行动还必须能被解释为角色意图和信念的结果 [riedlyoung2010]。这个区分看似细碎，却能把很多 metagaming 争议变成可讨论的证据问题。

事件 $\begin{array}{l}e\\ inE\end{array}$ 包含场景、参与角色、局部时间窗、前置条件、行动、输出信息和提交状态。事件可处于 pending 或 committed。pending 表示该事件已经在某个局部场景中发生或被记录，但尚未被公共叙述、机械后果或其他事件依赖锁定。committed 表示该事件已经对后续叙事产生不可逆影响，不能被普通 flashback 改写。

叙事 happened-before

本文把事件先后关系写作 $\begin{array}{l}e\_i\\ rightarrowe\_j\end{array}$。该关系不是现实秒表上的小于号，而是叙事 happened-before。若满足下列任一条件，就建立 $\begin{array}{l}e\_i\\ rightarrowe\_j\end{array}$。第一，两个事件位于同一场景，且 $e\_i$ 在局部叙事中先于 $e\_j$。第二，$e\_i$ 产生的信息通过合法通道进入 $e\_j$ 的参与者知识集。第三，两个事件受同一倒计时、NPC 行动或环境变化连接。第四，$e\_j$ 的前置条件引用 $e\_i$ 的结果。

这个定义直接借鉴 Lamport 对分布式系统事件偏序的处理方式 [lamport1978]。它的好处是避免伪精确。KP 不必为每个行动写下“耗时 37 秒”。只要记录“谁的行动依赖谁的结果”“谁通知了谁”“哪个倒计时推进到同一时间窗”，就能检测绝大多数叙事矛盾。

一个图书馆与下水道的例子可以说明。A 在图书馆读到祭坛地点，事件记为 $E\_L$。A 打电话告诉 B，事件记为 $E\_T$。B 前往第三岔口，事件记为 $E\_S$。若电话实际发生，则有 $\begin{array}{l}E\_L\\ rightarrowE\_T\\ rightarrowE\_S\end{array}$。若电话没有发生，B 的 $E\_S$ 就不能引用 $E\_L$ 的输出。玩家旁听不建立这条边。

信息泄露

本文只讨论可行动泄露，而不是心理层面“玩家听见了”。这个选择来自 noninterference 的可观察影响视角：安全风险不只是某主体内部是否接触信息，而是高敏信息是否改变了低权限主体可见的行为或输出 [goguen1982]。定义高敏信息 $m$ 对角色 $p$ 在时间 $t$ 发生未授权泄露，当且仅当满足三个条件：

$\begin{array}{l}leak(m,p,t)\\ Leftrightarrowm\\ notinknow(p,t)\\ landuse(m,p,t)\\ land\\ negauthorized(m,p,t).\end{array}$

其中 $use(m,p,t)$ 表示信息 $m$ 对角色 $p$ 的行动产生了可观察影响，$authorized(m,p,t)$ 表示存在同场感知、通信、物证、复述、展示、降密或合法推理路径。这个定义把泄露问题从“玩家有没有听到”转为“角色行动有没有未授权依赖”。它更适合桌面环境，因为许多桌面无法完全隔离玩家观察，但可以要求角色行动有叙事依据；这一点也与 RPG 社区对 split party metagaming 的处理建议一致，即减少可利用细节并在角色会合时再同步信息 [rpgmeta; rpgsplit]。

泄露也有强弱之分。氛围信息通常不是高风险泄露。例如 KP 公开说“图书馆里很潮湿，远处钟声沉闷”，即使其他玩家听见，也不会直接指向最优行动。相反，“银钥匙是唯一破坏仪式的触媒”是核心 payload。若不在场角色立刻去找银钥匙，就构成高风险可行动泄露。Filter 层正是为这种差别服务。

主持目标函数

KP 的目标不是单一最优，而是多目标平衡。本文把目标写作：

$\begin{array}{l}\\ min\\ langleV\_c,V\_l,W\_s,R\\ rangle\\ quad\\ texts.t.F\\ geqF\_min,N\\ geqN\_min.\end{array}$

其中 $V\_c$ 是因果违反次数，$V\_l$ 是未授权行动或公共高敏泄露次数，$W\_s$ 是 spotlight 最大等待间隔，$R$ 是 retcon 次数。约束 $F$ 表示叙事流畅度，$N$ 表示恐怖和推理体验的最低质量。这个写法不是要求 KP 真的求解数学优化，而是提醒：若只追求保密，可能牺牲 spotlight；若只追求流畅，可能牺牲因果；若只追求公平轮次，可能牺牲调查节奏。Spotlight 作为行动机会单位可由 Fate exchange 和社区切镜实践支持，叙事可信度则由 narrative planning 对 plot coherence 与 character believability 的区分支持 [fateexchange; rpgsplit; riedlyoung2010]。

相关工作与技术映射

TRPG 规则文本

CoC 7e Quick-Start Rules 给出了 Keeper 控制流程和战斗行动顺序，战斗中角色通常按 DEX 顺序行动，combat round 的长度则保持叙事模糊 [cocquickstart; cocpdf]。这支持本文对时间窗的处理：在调查场景中，KP 不必把所有行动换算为精确秒数，而应使用能维持因果的局部窗口。CoC 的规则气质本来就不是战棋式精确仿真，这一点很重要。

D&D Basic Rules 把战斗定义为一系列 rounds，每轮约六秒，每个参与者有自己的 turn，initiative 在战斗开始时确定 [dndbasic2018]。它是严格同步的代表。本文不把 D&D 轮次直接移植到 CoC 调查，但它提供了一个边界条件：当分队调查升级为共享危险、战斗、追逐、抢夺同一物品或仪式倒计时时，严格轮次有价值。

Fate Core 的 exchange 更接近本文需要的中间层 [fateexchange]。Exchange 不要求所有行动有精确秒数，而是保证参与者在一个冲突单位中获得行动机会。本文的 investigation exchange 借用这一点：每个分队在一个 exchange 中处理一个 significant action，然后 KP 检查同步屏障和信息传播。

Blades in the Dark 的 cut to the action、engagement roll 和 flashback 提供了另一个启发 [bitdsrd]。BitD 不要求玩家提前详述所有准备，而允许在行动中补叙过去准备。CoC 可以借用有限 flashback 作为调查自由度工具，但必须增加 committed 约束。若一条事实已经公开、已被他人行动依赖或已产生机械后果，就不能被 flashback 改写。

社区主持实践

RPG StackExchange 上关于分队和 metagaming 的讨论反复出现几个经验点：频繁切换 spotlight，在玩家犹豫或行动告一段落时切镜，不把全部私密细节公开，必要时引导重聚，明确玩家知识与角色知识的差别 [rpgsplit; rpgmeta]。这些建议不是形式化协议，却说明问题确实来自桌面实践，而不是人为构造的学术问题。

社区实践的不足在于缺少对象层。它会说“别公开太多细节”，但不说明“哪些细节属于高敏 payload”。它会说“经常切镜”，但不说明“高耦合场景最多能漂移多久”。它会说“让玩家别 metagame”，但不说明如何判定一个行动是否依赖未授权信息。本文的贡献不是推翻这些经验，而是给它们补上可执行数据结构。

分布式时间与仿真

Lamport 的经典论文指出，在分布式系统中，很多事件之间没有全局可观测的真实先后；系统真正需要维护的是 happened-before 偏序 [lamport1978]。这与 CoC 分队调查很像。图书馆读书和下水道探索未必有可比的精确先后，除非两者通过通信、共享倒计时或共享后果发生连接。把时间同步改写为因果一致性，是本文最重要的理论转译。

Chandy 和 Misra 的分布式仿真研究强调 logical process、消息、无全局控制和死锁避免 [chandymisra1979]。每个分队场景可以看作一个 logical process。若一个场景的下一步需要另一个场景可能产生的信息，KP 不应继续长距离推进，而应设置屏障或切换 spotlight。这个类比尤其适合处理“下水道队伍是否已经错过电话”之类问题。

Jefferson 的 Virtual Time 和 Time Warp 说明乐观推进必须配套 rollback 和全局虚拟时间边界 [jefferson1985]。TRPG 中的 flashback 与 rollback 不是同一机制，但二者共享一个思想：未提交区域可以改写，已提交区域不能随意改写。本文把这个思想转化为 pending events 与 committed events。KP 可以允许角色补叙“我出门前带了粉笔”，但不能允许“我其实早就拆掉了刚刚公开爆炸的炸弹”。

Cristian 的概率时钟同步提醒我们，真实系统中的同步也不是绝对精确，而是依赖误差边界和故障假设 [cristian1989ibm; cristian1989springer]。本文只把它作为弱类比：KP 可以使用时间窗口和误差带，例如“图书馆场景在 22:10 至 22:40 之间”，而不是强行精确到每一分钟。IEEE HLA 标准则说明分布式仿真需要对象模型、federate 与时间管理 [ieee1516]。这些概念为本文的 SceneCard 和 EventRecord 提供了工程语言。

互斥、仲裁与等待成本

Ricart-Agrawala 分布式互斥算法通过 REQUEST 和 REPLY 消息实现对临界区的互斥访问 [ricart1981; ricartmirror]。在 TRPG 中，临界区可以是同一个 NPC 的注意力、同一件物品、同一道门、同一个仪式节点或同一段先手行动。若两个分队都声称“先去找同一个证人”，KP 不能只按谁先在桌面发言决定，而应显式建立仲裁。

Maekawa 的 quorum 算法减少了互斥通信成本，关键在于任意两个投票集合有非空交集 [maekawa1985; maekawamirror]。对 KP 来说，这个思想转译为“最小共同仲裁点”。并不是所有冲突都需要全桌重新同步；如果冲突只涉及一个 NPC 和两个角色小组，KP 可以把该 NPC、相关地点或共享线索作为仲裁点，只同步受影响的场景。

Rubinstein 的轮流议价模型揭示等待成本会影响策略和结果 [rubinstein1982]。本文只把它作为 spotlight fairness 的背景提醒。玩家等待不是中性的。一个玩家连续二十分钟没有镜头，即使其角色没有危险，也会降低参与感。严格保密如果造成长时间私聊，就可能以另一种方式损害体验。

信息流控制与隐私

Goguen 和 Meseguer 的 noninterference 将安全性表述为高安全级主体的行为不应影响低安全级主体可观察输出 [goguen1982]。转译到 CoC，某个分队的私密发现不应影响不在场角色的行动，除非有合法通信或降密。这个定义比“玩家别乱用”更清楚，因为它关注的是可观察影响。

Bell-LaPadula 模型提供了强制访问控制中的 no read up 与 no write down [belllapadula1976]。TRPG 不需要军事级访问控制，但可借用两个规则。角色不能读取权限之外的线索，高敏线索也不能直接写入公共频道。若 KP 需要维持全桌氛围，可以公开低敏摘要，而不是公开 payload。

Myers 和 Liskov 的去中心化信息流控制引入 owner、reader 和 declassification [myers1997]。这非常适合线索传播。线索并不总是 KP 单方拥有；A 读到日记后，A 成为该信息在角色层面的 owner。A 可以选择复述、隐瞒、打电话或展示证据。降密不是自动发生，而是由叙事动作触发。

LIO 的动态标签思想也适合 KP 叙述状态 [stefan2011]。当 KP 正在处理高敏私聊内容，当前叙述标签升高。回到公共频道时，KP 不能无过滤输出刚刚读取的 payload，而要降为 redaction 或等待降密条件。这个提醒很实用，因为很多泄露不是恶意，而是 KP 在解释掷骰、描述 NPC 反应或总结场景时顺手说漏。

Dwork 等人的差分隐私强调按 sensitivity 校准输出扰动 [dwork2006]。本文不把 TRPG 信息处理称为差分隐私，也不引入数学噪声保证。可借用的是敏感度意识：低敏氛围可公开，高敏弱点和地点要私发或延迟，中敏战术信息可以摘要化。Yao 的安全秘密交换则提醒，多方协作不必要求所有人知道全部输入 [yao1986]。

叙事规划

Riedl 和 Young 的叙事规划研究指出，故事需要同时维护情节因果和角色意图可信度 [riedlyoung2010]。这补足了纯信息流模型的不足。一次行动即使没有直接泄露，也可能因为动机路径不可信而破坏叙事。例如一个胆小的图书管理员角色突然无理由冲向下水道最危险的岔口，即使玩家声称“我只是猜的”，也需要 KP 要求更清楚的角色内依据。

因此，本文的安全概念不是只看信息集合，也看角色行动是否有叙事上可接受的解释路径。ValidateICAction 的作用并非惩罚玩家，而是让玩家补出角色能成立的推理。若补不出，KP 可以把行动降级为“朝声音更明显的方向探索”，而不是允许精准使用未授权 payload。

文献依据与协议应用矩阵

为了避免把跨域类比写成无来源观点，表 tab:source-application 将本文使用的主要文献与 KTSL 中的具体设计逐项对应。表中的“原始观点”只概括文献中与本文有关的部分；“协议应用”说明该观点如何被转写为 KP 可执行规则；“边界”说明本文没有从该文献中推出什么。后文每个协议组件都应能回到这个矩阵中的至少一条来源链。

文献观点到 KTSL 协议设计的应用矩阵。

来源

原始观点

在 KTSL 中的应用

边界

Lamport 1978 [lamport1978]

分布式事件之间存在 happened-before 偏序，并非所有事件都有全局可判定先后。

将分队场景中的时间同步写成事件因果边、通信边和共享倒计时，而不是要求所有场景共用秒表。

不把逻辑时钟算法直接实现为 KP 规则。

Chandy-Misra 1979 [chandymisra1979]

分布式仿真由多个 logical process 通过消息推进，保守推进需要避免死锁和错误先行。

把每个分队场景视为 logical process；当一组行动可能等待另一组信息时，设置同步屏障或切换 spotlight。

不要求 KP 执行完整保守仿真算法。

Jefferson 1985 [jefferson1985]

乐观推进可配合 rollback，但需要虚拟时间和回滚边界。

将 flashback 限定在 pending events，禁止改写 committed events。

不把 BitD flashback 等同于 Time Warp。

Ricart-Agrawala 1981 [ricart1981]

消息传递系统可通过请求和回复实现互斥访问。

把共享 NPC、共享物品、同一扇门等视为叙事临界区，需要 KP 明确仲裁。

不关心最小消息复杂度，只保留仲裁思想。

Maekawa 1985 [maekawa1985]

quorum 的共同交集可降低互斥协调成本。

只同步受共享资源影响的最小场景集合，而不是每次冲突都全桌严格轮次。

quorum 结构只是类比，不要求构造投票集。

Goguen-Meseguer 1982 [goguen1982]

noninterference 关注高敏主体行为是否影响低权限可观察输出。

定义可行动泄露：旁听本身不是泄露，未授权信息影响角色行动才是泄露。

TRPG 没有形式安全证明，只保留可观察影响判据。

Bell-LaPadula 1976 [belllapadula1976]

强制访问控制限制读写方向，防止高密级信息流向低密级输出。

高敏线索不能直接写入公共频道；公开叙述只能输出 redaction 或降密事实。

不把玩家或角色做军事安全分级。

Myers-Liskov 1997 [myers1997]

DIFC 使用 owner、reader 和 declassification 支持去中心化信息流控制。

InfoLabel 记录 owner、authorized audience 和 declassify_when；角色复述或展示物证才扩散知识。

角色 owner 是叙事 owner，不是系统权限主体。

LIO 2011 [stefan2011]

动态 floating-label 会随读取高敏数据而升高，并限制低标签输出。

KP 处理私密 payload 后回到公共频道时必须先做 redaction，避免顺手泄露。

不实现 Haskell monad，只转译叙述状态。

Dwork et al. 2006 [dwork2006]

输出扰动应按查询 sensitivity 校准。

信息按敏感度 0 到 3 分级；低敏氛围可公开，高敏 payload 私发、延迟或降密。

不声称提供差分隐私保证。

Yao 1986 [yao1986]

密码协议可控制知识转移，使参与方只获得协议允许的信息。

多角色协作不要求所有玩家知道全部输入；KP 可维持局部视图和最小必要传播。

不把跑团过程等同安全多方计算。

Riedl-Young 2010 [riedlyoung2010]

叙事规划需要兼顾 plot coherence 与 character believability。

ValidateICAction 同时检查信息路径和角色动机路径，防止“信息上偷跑”和“意图上突兀”。

不自动生成剧情，只用作审计标准。

Fate Core [fateexchange]

Exchange 用行动机会而非精确秒数组织冲突与 spotlight。

Investigation exchange 让每个分队处理一个 significant action 后同步。

Fate 的叙事经济不直接移植到 CoC。

BitD SRD [bitdsrd]

Flashback 允许行动中补叙准备。

允许低中耦合场景补叙准备，但受 committed facts 限制。

CoC 线索链更强调不可随意改写事实。

该矩阵也规定了本文的论证纪律。若某个主持建议只来自社区实践，正文中应标为实践启发，而不是理论保证。若某个设计来自分布式系统文献，正文中应说明它是结构类比，而不是直接工程等价。若某个条目只作为弱类比，例如等待成本或时钟误差带，就不能用它支撑核心正确性命题。

设计目标、非目标与总体结构

设计目标

KTSL 的第一目标是因果一致。该目标直接来自 Lamport 的 happened-before 偏序与分布式仿真对事件安全推进的要求 [lamport1978; chandymisra1979]。若事件 $E\_2$ 依赖事件 $E\_1$，则 $E\_2$ 不能在叙事上先于 $E\_1$ 成立。若某条线索通过电话传播，则电话事件必须存在，且时间窗必须允许这次通信发生。若某个仪式倒计时推进，所有受影响场景都应更新到同一倒计时状态。

第二目标是授权信息流。信息的可见性不再只靠 KP 记忆，而由 label 记录。每条核心线索有敏感度、owner、授权受众、降密条件和公共摘要。这个设计来自 Bell-LaPadula 的输出约束、DIFC 的去中心化标签与 LIO 的动态标签直觉 [belllapadula1976; myers1997; stefan2011]。公共叙述可以维持氛围和参与感，但高敏 payload 不能未经降密进入公共频道。

第三目标是 spotlight 公平。协议不能把防泄露等同于无限私聊。Fate exchange 提供了用行动机会组织 spotlight 的实践依据，Rubinstein 的等待成本模型则提醒等待本身会改变参与者处境，本文只把后者作为弱类比 [fateexchange; rubinstein1982]。每个 exchange 结束后，KP 应检查等待债务。若某玩家长期没有镜头，即使其场景低耦合，也应给一个状态更新、选择机会或低敏公共摘要。

第四目标是叙事弹性。CoC 调查需要即兴、误解、延迟揭示和玩家创造性。BitD flashback 说明补叙可作为一种有效叙事机制，Jefferson 的 rollback 边界则提醒乐观推进需要提交边界 [bitdsrd; jefferson1985]。协议不应要求 KP 记录每一步脚印，也不应禁止 flashback。它只限制高风险边界：高敏信息、共享倒计时、共享资源、即时危险和已提交事实。

非目标

KTSL 不保证玩家心理上遗忘旁听信息。这个限制来自本文对 noninterference 的弱化使用：协议只观察未授权信息是否影响角色行动，而不声称能控制玩家内部记忆 [goguen1982]。KTSL 也不取代 session zero、玩家信任和社交契约。若玩家故意把 OOC 知识转成 IC 行动，协议只能提供证据和处理流程，不能替代桌面沟通。

KTSL 不是完整自动主持系统。本文不尝试让程序替 KP 决定所有叙事结果，也不提供完整跑团平台实现。协议对象可以被纸笔、电子表格、Notion、Obsidian、VTT 模块或聊天机器人实现，但本文关注的是抽象接口和运行原则。

KTSL 也不是普遍适用于所有 TRPG 的通用定律。它更适合秘密密度高、分队常见、调查链复杂的模组。对于规则本身鼓励玩家共享作者视角的叙事游戏，严格角色知识边界可能不合适。本文讨论的是 CoC 及相近风格调查游戏。

总体结构

Player Table / Voice Channel | KP Runtime Ledger | +================+================+ | | | Schedule Layer Filter Layer Coupling Layer | | | EventRecord InfoLabel SceneCoupling SceneCard Channel Barrier Commit Redaction Mode Selection | | | +================+================+ | Public narration, private note, regroup recap, IC action validation

KTSL 的运行结构。Schedule 层控制事件和时间，Filter 层控制信息输出，Coupling 层控制同步强度。三层共享同一份主持账本。

上图给出 KTSL 的结构。KP 在运行时维护一个轻量账本。每个场景有一张 SceneCard，每次显著行动生成一个 EventRecord，每条重要信息生成一个 InfoLabel，每对关键场景有一个 SceneCoupling。SceneCard 与 EventRecord 的设计来自 HLA 对分布式仿真对象与时间管理的要求、Lamport 事件偏序以及 Chandy-Misra logical process 模型的组合应用 [ieee1516; lamport1978; chandymisra1979]；InfoLabel 来自 DIFC、Bell-LaPadula 和 LIO 的信息标签传统 [myers1997; belllapadula1976; stefan2011]。三层不是三个孤立模块，而是同一份账本的三个视角。Schedule 层决定何时推进和提交；Filter 层决定如何叙述；Coupling 层决定是否切换调度模式。

Schedule 层：因果、同步屏障与提交边界

SceneCard 与 EventRecord

SceneCard 是场景层状态。它至少包含场景编号、地点、参与角色、局部时间窗、当前调度模式、pending events、committed events、公共可见摘要、私有事实、出入通信通道和与其他场景的耦合度。该对象借鉴 HLA 中 federate、对象模型和时间管理必须显式化的思想 [ieee1516]，但粒度降到 KP 可手工维护。SceneCard 的目的不是让 KP 写日志，而是让 KP 在切镜时能回答三个问题：这个场景推进到哪里了，哪些事实已经不能改，下一步是否会影响其他场景。

SceneCard: scene_id: library local_window: W2 participants: [A] mode: investigation_exchange pending_events: [E07] committed_events: [E01, E03] public_view: "A 正在查阅旧报纸，神色越来越紧张。" private_facts: [I12] channels: outbound: [telephone_if_declared]

EventRecord 是事件层状态。它记录行动者、场景、窗口、行动、前置条件、输出信息和提交状态。该对象对应 Lamport 偏序中的事件节点，也对应分布式仿真中 logical process 之间可产生依赖的离散事件 [lamport1978; chandymisra1979]。每次 significant action 至少生成一个 EventRecord。所谓 significant action，是指会改变线索状态、危险状态、角色位置、资源、NPC 态度或倒计时的行动。普通氛围描述不必生成事件。

EventRecord: id: E07 scene: library actors: [A] window: W2 action: "查阅馆藏日记" preconditions: [E01] happens_after: [E01] outputs: [I12] status: pending

调度模式

Schedule 层提供四种主要模式。Loose causal 适用于低耦合场景。KP 只记录因果边和大致时间窗，可以用 montage 快速推进。Investigation exchange 适用于中等耦合调查，其来源是 Fate exchange 对行动机会的组织方式 [fateexchange]。每个场景解决一个关键行动，然后检查信息传播和同步屏障。Strict round 适用于高耦合、高危险或共享资源竞争场景，其基线来自 CoC 与 D&D 战斗轮次规则 [cocquickstart; cocpdf; dndbasic2018]。它类似战斗轮次，但可以按叙事声明顺序、DEX 或现场优势决定。Macro scene 适用于多个分队实际上处在同一物理或叙事空间，例如同一栋宅邸的不同房间，此时应合并场景，同时保留局部可见性。

调度选择算法如下：

ChooseSchedule(scene_a, scene_b): c = Coupling(scene_a, scene_b) if CombatOrChaseActive(scene_a, scene_b): return strict_round if c >= 4: if SameMacroLocation(scene_a, scene_b): return macro_scene return strict_round if c >= 2: return investigation_exchange return loose_causal

这个算法有意简单。KP 不需要在桌上运行复杂模型。真正重要的是把“感觉上该同步了”改写为若干可见条件：有没有共享倒计时，有没有同一 NPC 或物品，有没有即时伤害依赖，有没有跨场景通信，有没有一条线索会改变另一组的行动空间。

事件提交与有限回滚

事件提交是 KTSL 中最容易被低估的机制。TRPG 中很多矛盾不是来自事件发生，而是来自事后改写了已经被别人依赖的事件。为了避免这种问题，Schedule 层把事件分为 pending 和 committed。这个划分来自两条来源链：BitD 证明补叙和 flashback 有玩法价值，Jefferson 的 Time Warp 则说明 rollback 必须有全局边界 [bitdsrd; jefferson1985]。Pending 事件可以被 flashback、补叙或轻微修正影响。Committed 事件则进入不可改写区。

CommitEvent(event): if event.has_public_narration and event.used_by_other_event: event.status = committed event.commit_reason = public_dependency else if event.has_irreversible_mechanical_effect: event.status = committed event.commit_reason = mechanical_effect else if event.declassifies_high_sensitivity_info: event.status = committed event.commit_reason = declassification else: event.status = pending

举例说，A 说“我出门前把手电筒塞进包里”，若这没有影响已公开事实，KP 可以允许作为 flashback。A 说“我其实早就给 B 打过电话告诉他祭坛地点”，如果 B 之前已经因为不知道地点而做出选择，这个 flashback 就可能改写 committed 事件。KP 可以拒绝，或要求付出代价并只允许它解释后续行动。

Schedule 层维护三个不变量。S1：对任意 committed 事件，不允许后续 flashback 改写其事实 payload。S2：若 $\begin{array}{l}e\_i\\ rightarrowe\_j\end{array}$，则 $e\_j$ 的结算不得引用未结算或已撤销的 $e\_i$。S3：若两个场景共享高耦合倒计时，每个 exchange 结束时必须检查同步屏障。

Filter 层：信息标签、输出通道与降密

InfoLabel

Filter 层的核心对象是 InfoLabel。每条会改变玩家选择的线索都应拥有标签。标签至少包含信息编号、来源事件、来源场景、敏感度、owner、授权受众、释放策略、降密条件和公共摘要。该对象直接吸收 DIFC 的 owner、reader 和 declassification 结构，并用 Bell-LaPadula 的 no write down 直觉约束公共输出 [myers1997; belllapadula1976]。低敏氛围不必全部标注；高敏线索必须标注。

InfoLabel: id: I12 source_event: E07 source_scene: library sensitivity: 3 owners: [A] authorized_audience: [KP, A] release_policy: private declassify_when: - A 通过电话复述 - A 与队伍会合并展示日记 - NPC 在公共场合说出同一事实 payload: "祭坛在下水道第三岔口，午夜前必须破坏银钥匙。" public_redaction: "A 读到一段与今晚某地点有关的危险记录。"

敏感度分为四级。0 级是氛围信息，没有直接行动价值。1 级是低行动价值信息，能影响情绪和方向，但不会直接给出关键最优解。2 级是战术信息，会改变近期选择，例如门后有脚步、NPC 在说谎、某条路危险。3 级是核心秘密，例如地点、弱点、仪式步骤、秘密身份和真相解释。这个分级不是差分隐私的数学 sensitivity，而是借用 Dwork 等人“输出处理应随敏感度变化”的方法论 [dwork2006]。

输出通道选择

输出通道选择算法如下。它把 noninterference 的“未授权影响不可见”、Bell-LaPadula 的输出限制和 LIO 的动态标签约束合并成 KP 可执行判断 [goguen1982; belllapadula1976; stefan2011]：

SelectChannel(info, audience): if info.sensitivity <= 1: return public if audience subseteq info.authorized_audience: return private if DeclassifyConditionSatisfied(info): return public if NeedPublicEngagement(info): return redacted return delayed

这个算法体现一个折中。高敏信息默认不公开，但 KP 可以公开 redaction 来维持桌面参与。例如 A 读到日记时，全桌可以听见“A 读到一段让他脸色发白的记录”，但不能听见“祭坛在第三岔口”。这种叙述保留戏剧张力，也让其他玩家知道 A 的场景有进展，却不把 payload 交给不在场角色。

Redaction 需要遵守两条原则。第一，保留表象，移除操作性 payload。第二，保留情绪和节奏，移除地点、弱点、身份和具体机制。若原文是“地下室有陷阱，失败会掉进井中”，公共摘要可以是“地板结构让你觉得不安”，而不是“这里有个很危险的机关”。后者已经给出了太多战术信息。

降密

降密是信息从私有知识进入共享知识的过程。它必须由叙事动作触发。DIFC 中 declassification 由拥有相应权限的主体释放信息；转译到 TRPG 中，owner 角色通过复述、展示物证或通信释放信息 [myers1997]。常见触发包括角色口头复述、电话沟通、展示物证、转交手记、翻译完成、NPC 在公共场合说出同一事实、环境变化使事实变得可见。KP 不应默认“会合就自动共享全部私聊内容”。会合只是提供降密机会，不是自动降密。

Regroup(characters): for info in private_infos: if OwnerNarrates(info) or EvidenceShown(info) or TranslationCompleted(info): Declassify(info) AddToSharedKnowledge(info) else: KeepPrivate(info)

降密的粒度也可以部分化。A 可以告诉 B“下水道里有危险，先别乱走”，但不说“第三岔口和银钥匙”。此时 B 获得的是一个 1 级或 2 级摘要，而非完整 3 级 payload。KP 记录 partial declassification，可以防止后续争议。

Filter 层维护三个不变量。F1：敏感度不低于 2 的信息不得写入公共频道，除非满足降密条件。F2：玩家旁听不得自动扩展 owner 或 authorized audience。F3：若公共叙述必须提及私密事件，只能输出 public redaction，不输出 payload。

Coupling 层：同步强度选择

场景耦合度

Coupling 层把“这些场景是不是互相影响很大”转为一个可讨论评分。本文使用五个二值因素：共享线索链、共享倒计时、共享 NPC 或物品、物理邻近、即时伤害依赖。该评分的来源不是单一论文，而是三类文献的合并：HLA 强调联邦对象和时间管理，Maekawa 强调共同仲裁点，TRPG exchange 强调按行动机会同步 [ieee1516; maekawa1985; fateexchange]。耦合度定义为这些因素之和：

$C(s\_a,s\_b)=I\_clue+I\_countdown+I\_object+I\_proximity+I\_harm.$

得分 0 到 1 为低耦合，适合 loose causal。得分 2 到 3 为中耦合，适合 investigation exchange。得分 4 到 5 为高耦合，适合 strict round 或 macro scene。这个评分不是自然法则，而是主持工具。若模组特点导致某个因素特别重要，KP 可以调整权重。

同步屏障

同步屏障是必须暂停局部推进并检查全局状态的节点。常见屏障包括共享倒计时推进、跨场景电话、同一 NPC 被两个分队接触、同一地点被两组角色同时进入、核心线索被一组发现且足以改变另一组行动空间、战斗或追逐开始。

NeedBarrier(scene_set): for each pair (sa, sb) in scene_set: if Coupling(sa, sb) >= 4: return true if SharedCountdownWillAdvance(sa, sb): return true if NewInfoChangesActionSpace(sa, sb): return true if CrossSceneCommunicationDeclared(sa, sb): return true return false

屏障不是暂停游戏的借口，而是减少 retcon 的保险。例如仪式倒计时从 23:30 推进到 23:45 时，所有相关场景都应更新。下水道中怪物苏醒，教堂壁画开始渗血，图书馆旧报纸上的墨迹也许出现变化。若某一组继续停留在旧时间窗，后续很容易出现“明明已经午夜，为什么这边还在傍晚”的矛盾。

Coupling 层维护三个不变量。C1：高耦合场景不得连续两个 exchange 不同步。C2：共享倒计时推进时，所有受影响场景必须同时更新 local window。C3：若两个场景共享同一关键资源，必须建立仲裁点。

协议运行流程

开团前准备

KTSL 不要求 KP 为模组中每个物件建模。准备阶段只需处理核心风险点。第一，列出核心线索，尤其是真相、地点、弱点、仪式步骤和秘密身份。第二，为每条核心线索写敏感度、owner 初始值和降密条件。第三，为可能分队的关键地点建立 SceneCard 草稿。第四，计算关键场景之间的耦合度。第五，在 session contract 中说明：分队允许，旁听也可能发生，但角色行动需要角色内知识路径。

一张最小线索表如下：

一张最小耦合矩阵如下：

开团中循环

运行时循环如下：

RunInvestigation(scene_set): initialize SceneCards while not scenario_finished: mode = ChooseGlobalOrLocalMode(scene_set) for scene in SpotlightOrder(scene_set, mode): event = ResolveOneSignificantAction(scene) labels = LabelOutputs(event) for info in labels: channel = SelectChannel(info, current_audience) Deliver(info, channel) CommitEvent(event) UpdateLedger(scene, event, labels) if NeedBarrier(scene_set): ResolveBarrier(scene_set) RebalanceSpotlightDebt(scene_set)

这个循环可以用纸笔执行。KP 每次只问一个实际问题：当前 spotlight 的这个行动是否显著？如果显著，它产生了什么信息？这些信息该给谁？事件是否已经提交？是否触发屏障？谁已经太久没有镜头？这些问题比“我应该怎样完美主持”更容易执行。

角色行动验证

当玩家提出一个明显利用旁听信息的行动时，KP 不必直接指责玩家。更好的做法是执行 ValidateICAction：

ValidateICAction(action, character): required_infos = InferRequiredInfo(action) for info in required_infos: if info not in know(character): ask "你的角色如何知道这一点？" if no valid channel or inference path: reject action or downgrade to low-confidence guess

“拒绝”不是唯一结果。KP 可以把精准行动降级为模糊行动。B 不能直接去第三岔口，但可以说“我沿着金属摩擦声更明显的方向走”。D 不能说“NPC 是混血”，但可以说“我觉得他的档案有问题，想继续查”。这样既保护信息边界，也不把玩家的创造性全部堵死。

性质与证明思路

P1：未提交事实回滚安全

命题 P1：若 flashback 只修改 pending events，且所有 committed events 禁止被改写，则 flashback 不会破坏已公开因果链。该命题的来源是 BitD flashback 的补叙机制与 Jefferson virtual time 中 rollback 边界的合并转译 [bitdsrd; jefferson1985]。

证明思路如下。根据 CommitEvent，一个事件成为 committed 至少因为公共依赖、机械后果或降密中的一种。Schedule 不变量 S1 禁止改写 committed 事件。Flashback 只作用于 pending 区域。因此 flashback 可改变尚未被其他场景依赖的局部事实，但不能改变后续 committed 事件的前置事实。若 $E\_i$ 已经被 $E\_j$ 引用，则 $E\_i$ committed 或应当在屏障检查中被提交。此时 flashback 不能撤销 $E\_i$，因果链保持稳定。这里的“因果链”按 Lamport happened-before 理解，而不是按真实秒表理解 [lamport1978]。

失效条件也很明确。若 KP 忘记把公共叙述标记为 committed，或允许玩家在事后补出已经影响他人选择的电话，P1 就失效。因此协议的实际效果取决于 KP 是否认真标记事件提交，而不是伪码本身。

P2：高敏 payload 不进入公共频道

命题 P2：若所有敏感度不低于 2 的信息都经过 SelectChannel，且 Filter 不变量成立，则高敏 payload 不会进入 public channel，除非满足降密条件。该命题对应 Bell-LaPadula 的输出限制、Goguen-Meseguer 的 noninterference 和 DIFC 的 declassification [belllapadula1976; goguen1982; myers1997]。

证明思路如下。SelectChannel 对低敏信息允许 public。对高敏信息，它只允许四种结果：授权私发、降密后公开、redacted、delayed。F1 禁止未降密高敏信息直接写入公共频道。Redaction 只保留低敏表象，不包含 payload。因此公共频道最多获得情绪、异常感和非操作性摘要，不获得完整地点、弱点、身份或机制。

这个性质的主要风险来自 KP 自己的临场解释。很多泄露不是正式叙述，而是“你这个检定失败，所以你没看出他是怪物”之类解释。LIO 的 floating label 类比在这里有实际提醒：KP 刚处理完高敏内容后，回到公共频道应先过一遍 redaction [stefan2011]。

P3：高耦合场景不会长期漂移

命题 P3：若 Coupling 不低于 4 的场景遵守 C1 和 NeedBarrier，则两个高耦合场景最多相隔一个 exchange 就会同步。该命题综合 HLA 时间管理、Maekawa 共同仲裁点和 Fate exchange 的 spotlight 单位 [ieee1516; maekawa1985; fateexchange]。

证明思路如下。NeedBarrier 在 Coupling 不低于 4 时返回 true。运行循环在每轮 exchange 后检查 NeedBarrier。C1 又禁止高耦合场景连续两个 exchange 不同步。因此只要 KP 执行循环，高耦合场景的本地窗口不会长期分叉。该性质不保证所有低耦合场景都同步，因为低耦合场景并不需要高频同步。

失效条件主要是评分错误。如果一个场景实际上有共享倒计时和即时伤害依赖，KP 却把耦合度估为 1，协议不会自动救场。这说明耦合评分最好在团后复盘中校准。

P4：旁听不自动授权角色行动

命题 P4：若 $obs(u,t)$ 不自动写入 $know(p,t)$，且 ValidateICAction 使用 $know$ 而不是 $obs$，则旁听信息不会自动成为合法行动依据。该命题来自 noninterference 的可观察影响标准、DIFC 的授权读者模型和叙事规划中的角色意图可信度约束 [goguen1982; myers1997; riedlyoung2010]。

证明思路如下。模型中玩家观察和角色知识是不同集合。玩家旁听只更新 $obs$，不更新 $know$。角色行动验证只检查 $know$。若某行动所需信息不在 $know$ 中，玩家必须提供通信、感知、物证、复述或推理路径。若路径不存在，行动被拒绝或降级。因此旁听不能直接授权精准行动。

这个命题不要求玩家真的忘记旁听内容。它只要求行动层面可审计。这比心理层面的要求更现实，也更适合桌面游戏。

案例研究：图书馆、下水道与教堂

场景设定

设一局 CoC 调查进入最后一晚。A 在图书馆查日记。B 与 C 在下水道探索。D 在教堂解读壁画。仪式将在午夜完成。真相由三条线索拼接而成：日记给出地点，壁画给出触媒，下水道给出当前危险。若玩家分队，KP 面临典型三难：如果公开日记内容，B 和 C 可能直接使用地点；如果私聊 A，其他玩家可能等待过久；如果不记录时间，下水道队伍可能在 A 查完资料前已经越过关键地点。

Baseline 主持可能这样运行。KP 公开对 A 说：“你在日记中看到祭坛在下水道第三岔口，午夜前必须破坏银钥匙。”随后切到 B 和 C：“你们在下水道听到金属摩擦声，准备去哪？”B 的玩家说：“我们去第三岔口。”在桌面层面，这个回答很顺；在角色层面，它缺少知识路径。若 KP 允许，就产生未授权行动。

KTSL 主持轨迹

使用 KTSL 时，KP 先为 A 的发现建立 InfoLabel：

I02: payload: "祭坛在下水道第三岔口。" sensitivity: 3 owners: [A] public_redaction: "A 读到一段和今晚地点有关的危险记录。" declassify_when: - A 通过电话告诉他人 - A 会合后展示日记

公共频道中，KP 说：“A 翻到一段让他明显停顿的记录。那段内容和今晚的某个地点有关，我私发给 A。”然后私发 payload。切到 B 和 C 时，KP 说：“你们在下水道听到远处金属摩擦声，声音从更深处传来，但岔路很多。”B 若说“去第三岔口”，KP 执行 ValidateICAction，询问“你的角色怎么知道是第三岔口？”若 B 无法提供路径，KP 可以允许“朝声音更明显的方向探索”，但不允许精准选择第三岔口。

若 A 选择打电话，则产生 EventRecord：

E08: type: declassification from: A to: B info: I02 channel: telephone happens_after: [E07] status: committed

此后 B 前往第三岔口合法。注意这里的关键不是禁止玩家使用聪明想法，而是要求聪明想法有角色内通道。电话、物证、复述都可以建立通道。旁听本身不可以。

时间同步处理

时间上，KP 把图书馆、下水道、教堂都置于 W2 时间窗。A 查日记消耗一个 exchange。B 和 C 聆听并选择方向消耗一个 exchange。D 解读壁画失败也消耗一个 exchange。每个 exchange 后，KP 检查屏障。若仪式倒计时推进到 23:30，则三个场景同时更新。若 D 解读出银钥匙信息，而 B 和 C 已接近第三岔口，教堂与下水道耦合度升高到 4，KP 应进入 strict round 或把场景合并为“仪式节点” macro scene。

这个案例展示 KTSL 的主要效果。它没有阻止公共戏剧张力，因为其他玩家仍知道 A 发现了重要内容。它没有强制所有人严格轮次，因为图书馆查资料和下水道探索在中耦合时仍可 exchange。它也没有让私聊无限延长，因为公共摘要给了全桌可见的情绪变化。最重要的是，它把“B 是否可以去第三岔口”从争吵变成了账本检查。

扩展案例：警署、医院与旧宅

案例动机

前一节案例以核心地点泄露为主。真实 CoC 调查中，泄露并不总是“地点答案”这么直接。更常见的是证词、医学证据和现场危险三类信息互相拼接。玩家可能没有听到完整真相，却听到足够多的碎片，从而让角色跳过调查过程。为了说明 KTSL 如何处理这种灰区，本节给出一个扩展案例。

设玩家分为三组。A 在警署查阅失踪案卷宗，并盘问值夜警员。B 在医院检查一具被水浸泡过的尸体。C 和 D 前往旧宅现场，那里有地下蓄水室和一个尚未关闭的暗门。模组真相是：失踪者并非在河边遇害，而是在旧宅地下被仪式水池淹死；值夜警员收过钱，改写了第一份报告；尸体肺部残留的泥沙成分来自旧宅地下水，而不是河水。

这个场景有三个潜在泄露点。第一，A 可能在警署得知“报告被改写”，这会让 C 和 D 在旧宅中优先寻找被掩盖的现场。第二，B 可能通过医学检定知道“不是河水”，这会让 A 盘问警员时直接质问伪造报告。第三，C 和 D 可能在旧宅发现暗门危险，若公共频道描述过细，A 和 B 可能让角色无理由赶来支援。这里没有单一地点答案，而是一组中敏和高敏信息的交织。

标签与耦合

KP 在准备阶段可以写下四条信息。I10：第一份警署报告被改写，敏感度 2，owner 初始为空，由 A 盘问或查档获得。I11：尸体肺部泥沙来自旧宅地下水，敏感度 3，owner 初始为空，由 B 医学检定获得。I12：旧宅地下暗门仍可开启，敏感度 2，owner 初始为空，由 C 和 D 现场搜索获得。I13：值夜警员收钱的对象与旧宅产权人有关，敏感度 3，owner 初始为空，由 A 深入盘问或查财务记录获得。

警署与医院共享线索链，但没有即时伤害，耦合度约为 2，适合 investigation exchange。医院与旧宅共享物证来源，且旧宅存在即时危险，耦合度约为 3。警署与旧宅共享嫌疑人和地点，若 A 得到产权人线索，耦合度可升至 3。若 C 和 D 打开暗门并触发蓄水室危险，旧宅与其他场景的耦合度应升高，因为支援是否来得及成为时间问题。

这个案例显示耦合度不是固定值。它会随信息发现而变化。开场时警署和旧宅只是弱相关；一旦 A 查到产权人，C 和 D 的旧宅探索就变成直接相关。KP 应允许 Coupling 动态更新，而不是只在开团前打一次分。

运行轨迹

第一轮 exchange，A 查卷宗，KP 公开摘要：“A 注意到卷宗页码有一处不连续，像是后来重新装订过。”私下告诉 A：第一份报告的时间和地点描述被改写。此时 I10 owner 为 A。B 检查尸体，若检定成功，KP 私下告诉 B：肺部泥沙不像河泥，更像封闭地下水池沉积物。此时 I11 owner 为 B。C 和 D 到达旧宅，KP 公开描述：“房子比预想中潮，木地板下有空响。”这只是 1 级氛围，公共可见。

第二轮 exchange，A 若立刻打电话给 C 和 D，说“旧宅可能才是第一现场”，则 I10 部分降密给 C 和 D。C 和 D 因此搜索地下结构是合法行动。若 A 没有通信，C 和 D 仍可基于木地板空响调查，但不能因为玩家听见卷宗问题就直接寻找“被掩盖的第一现场”。B 若把医学发现发给 A，A 可以在盘问警员时质问河水说法；若 B 没有通信，A 只能基于卷宗页码问题追问报告是否完整。

第三轮 exchange，C 和 D 发现暗门。KP 不应在公共频道说“你们找到通往仪式水池的门”。更合适的 redaction 是：“C 和 D 在地板下找到一处潮湿的结构，里面有一股让人不舒服的水腥味。”具体 payload 私发给 C 和 D。若 C 和 D 呼叫支援，则暗门信息降密给接收者。若他们不呼叫，A 和 B 即使玩家听见公共摘要，也不能直接以“旧宅地下有水池”为理由改变行动。

灰区处理

这个案例的难点是推理链。A 知道报告被改写，B 知道不是河水，C 和 D 知道旧宅潮湿。任何单条信息都不等于真相，但组合起来足以指向旧宅地下水池。若玩家在会合前用公共旁听把三条线索拼起来，角色是否也能拼起来？答案取决于信息是否已经降密。若 A、B、C、D 没有通信，玩家可以在作者层面理解，但角色层面仍是分散知识。若其中两组通过电话交换了摘要，接收者可拥有部分组合推理。

KP 可以允许“低置信猜测”。例如 A 没有收到 B 的医学结论，但他根据卷宗被改写和旧宅产权人可疑，决定派人去旧宅，这可能合法。A 不能说“尸体不是河水淹死的”，因为他没有医学证据；但他可以说“报告可能遮掩了真正地点”。这种处理比简单允许或禁止更细。它让玩家推理有空间，也让证据边界保持清楚。

案例结论

扩展案例说明，KTSL 不只处理“一个秘密答案被旁听”的简单泄露。它也能处理多线索拼接、部分降密、低置信猜测和动态耦合。现实跑团中，许多争议来自这些灰区。协议的作用不是把灰区消灭，而是把灰区拆成可以讨论的对象：哪条信息被谁知道，哪条信息只是玩家听见，哪条推理可以由角色已有证据支持，哪条推理需要等待通信或会合。

可复现评估与 transcript 审计

研究假设与判定标准

本文提出三个可测试假设。H1：相比经验主持，使用 Schedule 层会降低因果违反次数和 retcon 次数。H2：相比只使用 Schedule 层，加入 Filter 层会降低未授权行动次数和公共高敏泄露次数。H3：加入 Coupling 层后，spotlight 最大等待时间不会显著恶化，且高耦合场景的时间漂移减少。

这些假设现在按两层证据处理。第一层是本文已经完成的确定性 fixture 消融：用固定事件、信息标签和耦合边检查协议对象是否产生预期差异。第二层是后续 transcript 审计：选择同一段 60 至 90 分钟的调查片段，分别在 Baseline、Schedule-only 和 KTSL-full 三种条件下运行。每次运行录音或文字记录，事后由不参与跑团的标注者根据统一规则编码。

指标

标注时需要保留上下文。一个行动是否未授权，不能只看玩家是否说出关键词，而要看角色是否有合法路径。例如 B 说“我去第三岔口”，若 A 已打电话，则合法；若 A 没有通信，且 B 没有其他线索，则记为未授权。一个公共 payload 是否泄露，也要看降密条件是否已满足。

对照条件与消融设计

Baseline 条件下，KP 不使用显式账本，只按平时经验切镜。Schedule-only 条件下，KP 使用 SceneCard、EventRecord 和同步屏障，但不使用 InfoLabel。 KTSL-full 条件下，KP 同时使用 Schedule、Filter 和 Coupling。确定性 fixture 进一步展开为 Schedule、Filter、Coupling 三个开关的八种组合，用来观察每一层到底修复哪类错误。若真实 transcript 中 KTSL-full 相比 Baseline 显著降低因果违反、未授权行动和公共高敏泄露，同时 Spotlight Max Gap 没有明显上升，则协议得到经验支持。

该实验不需要复杂设备。一个共享表格、录音转写和两名标注者即可开始。为了避免 KP 个人风格造成偏差，后续应在不同 KP、不同玩家熟悉度、线上和线下环境中重复。若结果显示协议降低泄露但显著增加等待时间，则需要改进 redaction 和 spotlight debt 机制。若结果显示协议负担过重，则需要开发简化表或平台插件。

确定性 fixture 结果

本文先用受控 fixture 检查协议机制本身。FateGear 中的两个 fixture 对应前文纸面案例：library_sewer_church 和 police_station_hospital_old_house。每个 fixture 都包含三类对象：事件提交顺序、敏感信息标签和高耦合场景边。评估脚本对 Schedule、Filter 和 Coupling 三层做全组合消融，得到 none、S、F、C、S+F、S+C、F+C 和 S+F+C 八种条件。原始输出保存在 experiments/ktsl-ablation-20260705/results/ablation-results.json 与同目录 CSV 文件中；该结果是确定性模拟检查，不是真实跑团 transcript 或盲审标注。

表 tab:ktsl-ablation 汇总两个 fixture 的 aggregate 指标。H1 的判定比较 none 与 S，H2 比较 S 与 S+F，H3 比较 S+F 与 S+F+C。在两个 fixture 上三项假设均通过，分别为 H1 $2/2$、H2 $2/2$、H3 $2/2$。

KTSL 确定性 fixture 三层消融汇总。因果、未授权、泄露、漂移和等待为两个 fixture 的总和；降密为两个 fixture 的均值。

消融结果支持三层拆分，而不是只支持“多记一点账”。Schedule 从 none 到 S 将因果违反从 2 降为 0，但未授权行动和公共泄露仍为 4，说明单靠时间屏障不能解决信息边界。Filter 从 S 到 S+F 将未授权与泄露合计从 4 降为 0，并把降密完整度从 0.00 提高到 1.00，但高耦合漂移仍为 6，说明信息标签不能替代时间同步。Coupling 从 S+F 到 S+F+C 将高耦合漂移从 6 降为 0，且 Spotlight Max Gap 保持 0，说明同步层在这两个 fixture 上没有造成额外镜头空窗。

该结果也暴露了边界。Retcon Count 在所有条件下均为 0，因此 H1 中关于 retcon 的部分尚未被当前 fixture 检验；它需要包含显式回滚事件的新 fixture 或真实 transcript。Barrier Wait 从 0 增至 4，说明 Schedule 的收益伴随等待成本。当前两个 fixture 的 Gap 均为 0，因此只能说明 Coupling 在这些案例中没有恶化 gap，不能证明所有桌面都不会增加等待。后续 transcript 实验仍需由独立标注者检查真实发言、私聊、会合和降密过程。

审计表

评估标注手册

标注单位

若要验证 KTSL，首先需要规定标注单位。本文建议以“可结算行动”为基本单位，而不是以自然语言句子为单位。一个玩家可能用三句话描述同一个行动，也可能一句话里包含移动、观察、交流和检定。标注者应把它拆成若干可结算行动：角色移动到哪里，尝试取得什么信息，是否把信息传给他人，是否使用某条已经获得或未获得的线索。

对每个行动，标注者记录四类上下文。第一，行动发生时角色的 $know$ 集合。第二，玩家可能通过公共频道拥有的 $obs$ 集合。第三，行动成功需要哪些信息。第四，是否存在合法桥接路径。合法路径包括同场感知、先前线索推理、他人复述、电话或纸条通信、物证展示、NPC 公开说明、KP 明确降密。若一个行动看起来使用了旁听信息，但角色也能从已知线索合理推断出来，则不应记为泄露。

例如，B 说“我去第三岔口”时，标注者不能只看 B 是否说出了“第三岔口”。若 B 之前听到金属摩擦声来自右侧，又在地图上看到第三岔口恰好是右侧唯一通路，那么这可能是合法推理。若 B 唯一来源是玩家刚听见 A 的私密线索，则记为未授权行动。这个差别很重要。协议不是要限制玩家推理，而是要限制无路径的精准使用。

因果违反标注

因果违反分为三类。第一类是前置未满足。角色行动引用了尚未发生、尚未结算或已被撤销的事件。例如 B 说“我已经收到 A 的电话”，但 A 从未声明打电话。第二类是时间窗不相容。例如 A 在 23:50 才查到仪式地点，B 却在 23:30 已根据该地点抵达祭坛。第三类是共享状态分叉。例如 KP 在下水道场景宣布仪式钟声已经敲响，但图书馆场景仍按钟声前状态处理。

标注时应避免把所有叙事模糊都判为错误。CoC 本来允许“过了一会儿”“与此同时”这样的叙述。只有当模糊造成角色行动、危险状态或线索链矛盾时，才计入因果违反。若一个时间差不影响任何结算，可记录为“模糊但无害”，不计入主要指标。这样能防止评估把自然叙事误伤为缺陷。

建议每条因果违反记录五列：事件编号、被引用前置、当前证据、违反类型、修复方式。修复方式包括补通信、回滚 pending 事件、公开 retcon、调整时间窗或拒绝行动。若修复需要改写 committed 事件，则同时计入 Retcon Count。若只是在 pending 区补一句“你刚才确实拨出了电话，但信号很差”，可以计为轻微修正，不必算作严重 retcon。

信息泄露标注

信息泄露标注也分三类。第一类是公共 payload 泄露，即 KP 在公共频道说出了敏感度不低于 2 的 payload，而降密条件尚未满足。第二类是未授权行动，即角色使用了不在 $know$ 中的信息并获得行动优势。第三类是暗示性泄露，即 KP 没有说出 payload，却通过检定名称、NPC 反应或过度具体的失败描述泄露了答案。例如 KP 说“你没有看出他是深潜者混血”，这句失败描述反而公开了目标身份。

暗示性泄露最难标注。本文建议采用保守原则：只有当暗示能让未授权角色显著缩小行动空间时，才计入。例如“你觉得这个人有点怪”通常只是低敏氛围，不计泄露；“你觉得他的血统不像普通人类”已经接近身份 payload，应计为中高风险。若两个标注者意见不一致，可记录为 ambiguous，并在统计中单独报告。

泄露标注还要区分听见和使用。玩家听见高敏信息，但后续没有任何相关行动，公共 payload 泄露仍然成立，因为 KP 已把信息放进公共频道；未授权行动不成立，因为角色没有使用它。反过来，KP 没有公开 payload，但玩家通过屏幕共享、私聊误发或其他方式获得并使用，也应记为未授权行动。两个指标测量的是不同风险。

Spotlight 与等待成本标注

Spotlight Max Gap 测量玩家两次获得实质镜头之间的最大间隔。实质镜头不是 KP 叫名字，也不是一句“你还在等”，而是玩家获得选择、叙述、检定或角色表达机会。若 KP 对某玩家说“你继续在门外等”，且玩家没有新的选择，这不算实质镜头。若 KP 说“你听见门内争吵升级，现在可以冲进去、继续听、找后门或给别人打电话”，这算实质镜头。

等待成本需要和保密机制一起分析。若 KTSL-full 降低了泄露，却让某玩家最大等待从 8 分钟变成 25 分钟，那么协议并不算成功。此时应检查私聊是否过长，公共 redaction 是否太少，低耦合场景是否被不必要地搁置。好的 Filter 层不只是藏信息，也要提供低敏公开材料，让未参与私聊的玩家仍能理解节奏。

建议记录平均等待、最大等待和等待方差。最大等待能捕捉最糟体验，平均等待能反映整体节奏，方差能反映 spotlight 是否集中在少数玩家。对于恐怖场景，少量刻意等待可以增强张力，但这种等待应伴随明确的叙事状态，而不是让玩家离开桌面。

实施路线与主持细则

纸笔实现

最小纸笔实现只需要一张 A4 纸。左侧写场景卡，每个场景一行：地点、角色、时间窗、当前模式、pending、committed。右侧写信息卡，每条核心线索一行：ID、payload 摘要、敏感度、owner、公开摘要、降密条件。底部写屏障：倒计时、共享 NPC、共享物、跨场通信。KP 每次切镜只更新一到两格。

纸笔实现的优点是低门槛，缺点是修改和检索不方便。它适合线下短团和一次性模组。为了降低负担，KP 可以只给敏感度 3 的线索建标签。敏感度 2 的战术信息若临场出现，再用铅笔补。敏感度 0 和 1 的氛围信息不进入表格，只在叙述中处理。

一个实用技巧是使用颜色。红色表示敏感度 3，橙色表示敏感度 2，蓝色表示公共或已降密，灰色表示 pending。颜色不是为了漂亮，而是为了让 KP 在紧张场景中快速看见“哪些东西不能公开说”。如果 KP 容易在解释检定时说漏，红色标记尤其有用。

电子表格实现

电子表格适合线上团。一个工作簿可包含四个 sheet：Scenes、Events、Info、Audit。Scenes 记录 SceneCard。Events 记录 EventRecord。Info 记录 InfoLabel。Audit 在团后标注因果违反和泄露。若使用 Google Sheets 或本地表格，还可以用筛选器查看“所有未降密高敏线索”或“所有 pending 事件”。

电子表格的风险是 KP 可能被界面吸走注意力。解决方法是把运行时字段压到最少。运行中只改 scene window、pending event、info owner、declassified 这几个字段。复杂审计留到团后。若 KP 在跑团中不断整理表格，玩家会感到节奏变慢。协议服务叙事，不应抢叙事的镜头。

电子表格还可以支持自动检查。比如若某条 sensitivity 为 3 的信息被标为 public，但 declassified 为 false，表格可以高亮。若某个 high coupling 场景连续两个 exchange 没同步，表格可以提示。本文没有实现该工具，但数据对象已经为这种实现留出接口。

VTT 与聊天机器人实现

在线跑团平台或聊天机器人可以把 KTSL 做成半自动工具。KP 给线索添加标签，机器人根据授权受众自动选择私聊或公共摘要。玩家会合时，KP 点击“降密”，机器人把某条信息加入 shared knowledge。玩家声明行动时，机器人可以显示该角色当前 know 集合，帮助 KP 判断是否需要询问知识路径。

这种实现要避免过度自动化。机器人不应替 KP 判断“这个推理是否合理”，因为合理性依赖角色背景、玩家表演和现场语境。机器人更适合做记忆辅助：提醒哪些信息未降密，哪些事件 pending，哪些场景高耦合。最终裁量仍由 KP 做出。

隐私也需要注意。若工具保存私聊 payload，应明确存储位置和访问权限。对于录播或公开团，未公开线索可能涉及剧透。工具应允许会后导出删减版 transcript，把高敏 payload 替换为 redaction。这样既便于复盘，又不泄露模组核心内容。

KP 语言细则

协议最终要落到语言。公共 redaction 的写法有四个建议。第一，用角色可见表象替代真相。例如写“档案有被撕掉的一页”，不要写“档案隐藏了深潜者血统”。第二，用情绪反应替代机制。例如写“A 读完后沉默了一会儿”，不要写“A 发现了怪物弱点”。第三，用风险方向替代精确解法。例如写“继续深入可能来不及回头”，不要写“午夜前必须破坏银钥匙”。第四，保留玩家选择。摘要不应只说“你不知道”，而应给出可行动但低精度的选择。

ValidateICAction 的语言也要温和。推荐句式是“这一步需要你的角色知道 X。你觉得他是从哪里推出来的？”而不是“你这是 metagame”。前者邀请玩家补角色推理，后者容易让玩家防御。若玩家给出一个勉强但有趣的解释，KP 可以允许低置信行动，并提高风险。这样既保护边界，也保留桌面的创造性。

对于新玩家，KP 应在开团前给一个例子。比如“如果你听见另一个场景里有怪物弱点，你本人知道，但角色不知道。你可以让角色害怕、犹豫、寻找证据，但不能直接冲去使用弱点，除非有人告诉你或你自己发现。”这个说明比抽象谈 IC/OOC 更有效。

反例与边界案例

低秘密密度场景

并非所有分队都需要 KTSL。若队伍只是在城市中分头采购装备、打听普通传闻、寻找住宿，且没有共享倒计时和核心秘密，完整标签会显得笨重。此时 loose causal 足够。KP 只需记录大致时间和重要花费，不必为每条普通传闻写 InfoLabel。若协议在低秘密密度场景中造成明显拖慢，就说明使用范围过宽。

这个反例提醒我们，协议的价值来自选择性使用。一个好 KP 不应因为有工具就处处使用工具。本文建议把 KTSL 看作“高风险模式”：当分队、秘密、倒计时、共享资源同时出现时打开；当场景只是日常探索时关闭或简化。

玩家共同作者视角

某些叙事游戏鼓励玩家从共同作者角度参与故事。玩家知道角色不知道的信息，并故意演出戏剧性误解。在这种桌面文化下，严格防泄露可能削弱乐趣。若玩家和 KP 已明确采用作者视角，KTSL 的 Filter 层应放松，重点转向 Schedule 和 spotlight。也就是说，角色知识边界是桌面契约的一部分，不是所有游戏的普遍义务。

CoC 通常更依赖未知和调查推理，因此本文选择较严格的知识边界。但即便在 CoC 中，也有队伍喜欢公开旁听，只要求玩家自觉。对这类队伍，KTSL 可以作为团后复盘工具，而不是运行时强规则。若出现争议，再用 InfoLabel 回看“这条线索当时是否已降密”。

高信任老玩家桌

一桌高信任老玩家可能几乎不需要显式验证。玩家会主动说“我本人知道，但角色不知道，所以我先不行动”。这种桌面仍可能受益于 Schedule 层，因为时间错位和共享倒计时不是只靠自觉能解决的。Filter 层则可简化为核心线索清单，不必频繁询问。

这说明 KTSL 的三层可以独立调节。高信任桌可以用轻 Filter、强 Schedule。陌生线上团可以用强 Filter、强 Coupling。低风险轻松团可以只用 Coupling 的切镜提醒。协议不是一个开关，而是一组可组合的主持约束。

故意误导与红鲱鱼

CoC 模组常有红鲱鱼。若某条线索本身是误导，它也可能是高敏信息，因为它会改变行动。InfoLabel 不要求 payload 必须为真。它只要求 payload 有行动价值。一个错误的 NPC 供词、一本伪造日记、一张伪地图，都可以是 sensitivity 2 或 3。降密它们不会破坏协议，因为协议管的是角色如何获得信息，不管信息是否真实。

这点对推理公平很重要。若 A 私下得到一条伪线索，并选择不告诉他人，其他角色不能因玩家旁听而避开错误路线。否则红鲱鱼失去意义。Filter 层保护的不只是正确答案，也保护角色被误导的权利。

角色间秘密与玩家安全

有些秘密不只是剧情信息，也可能涉及玩家安全工具。例如角色背叛、恐怖描写边界、个人触发内容。本文的 InfoLabel 可以记录叙事保密，但不应替代安全工具。若内容涉及玩家不适，X-card、lines and veils、暂停机制和会前沟通优先于协议保密。KP 不应以“防泄露”为理由向玩家隐藏可能越界的现实内容。

因此，KTSL 的安全性是叙事安全和信息边界意义上的安全，不是心理安全工具。两者有交集，但不能混为一谈。正式使用协议时，应在 session contract 中说明：玩家安全高于剧情秘密。

讨论

协议成本

KTSL 的成本来自记账。若每个物件、每句台词、每个氛围细节都打标签，KP 会被表格拖垮。因此本文建议只标注三类内容。第一，核心线索，包括真相、地点、弱点、秘密身份和仪式步骤。第二，共享风险，包括倒计时、追逐、怪物行动和同一 NPC。第三，高收益决策点，即一旦知道就会改变最优行动的内容。其他低敏叙述可以保留传统主持方式。

实际执行中，KP 可以使用极简版本。每条高敏线索只写四列：payload、owner、公开摘要、降密条件。每个场景只写三列：当前时间窗、pending 事件、是否触发屏障。耦合度也可以用低、中、高三档，而非五项评分。协议的价值不在格式复杂，而在让关键边界可见。

玩家体验

防泄露协议如果执行得像审讯，会破坏桌面信任。KP 在询问“你的角色怎么知道”时，应把它作为角色扮演邀请，而不是惩罚。玩家也许能给出合理路径：“我记得刚才报纸说下水道西段关闭，而金属声从东边来，所以我想走东边。”这不是泄露，而是推理。协议应保护这种推理，而不是压制它。

公共 redaction 也需要写得有戏。过度干瘪的摘要会让其他玩家无事可做。好的摘要给情绪、节奏和选择信号，但不给 payload。例如“他的表情变了，像是读到什么会让今晚变得更糟的东西”比“这里有一条私密线索”更适合 CoC。Humanizer 的原则在这里也适用：少写模板句，多写具体可感的表象。

与严格轮次的关系

KTSL 并不反对严格轮次。它反对把严格轮次当作所有时间问题的默认答案。严格轮次适合共享危险、共享资源和即时反应，却不适合所有调查。若 A 在翻报纸，B 在买装备，C 在街上问路，把三人都拉进六秒轮次只会增加噪音。耦合度的作用正是让 KP 知道什么时候该放松，什么时候该收紧。

与纯叙事信任的关系

有些桌面文化强调作者视角共享，玩家可以知道很多角色不知道的信息，并自觉演出不知道。对这类桌面，KTSL 的强信息边界可能显得多余。本文不是要否定这种玩法，而是服务另一类需求：秘密密度高、调查推理强、玩家容易因旁听改变选择、KP 希望可复盘的 CoC 场景。协议应服务桌面契约，而不是凌驾于桌面契约。

威胁与局限

第一，理论迁移有边界。分布式系统的进程没有情绪、审美和角色动机；TRPG 玩家也不会像机器一样严格遵守协议。本文借用 Lamport、信息流控制和分布式仿真的结构概念，而非声称 CoC 是分布式程序。若读者把 KTSL 用作机械规则，可能适得其反。

第二，证据强度不均。Lamport、Goguen-Meseguer、Bell-LaPadula、Myers-Liskov、LIO、Dwork、Yao、Riedl-Young 等来源可支撑本文的核心概念转译。Cristian、Kuramoto、Rubinstein 在当前研究中只作弱类比。CoC Quick-Start 可支撑 Keeper 流程和模糊战斗轮次，但若要写正式投稿论文，仍应在合法条件下核对 CoC 核心书的更完整规则。

第三，外部效度仍有限。本文报告的 H1 至 H3 支持来自两个受控 fixture 和三层消融，不来自真实跑团 transcript。它能说明当前协议对象在纸面案例中按预期工作，也能暴露各层的作用边界；但它不能替代多 KP、多玩家和盲审标注的外部验证。尤其是 spotlight 指标可能在真实桌面出现反直觉结果：信息标签降低泄露，却增加等待时间。若出现这种情况，协议必须调整，而不是强行解释成成功。

第四，执行者效应显著。熟练 KP 使用 KTSL 可能只增加很小负担，新 KP 可能被表格分散注意力。玩家熟悉程度也会影响结果。老玩家可能更能自觉区分 IC 和 OOC，新玩家可能更依赖 KP 的显式提示。因此评估时应记录 KP 经验、玩家熟悉度、模组秘密密度和线上线下环境。

第五，协议可能改变游戏风格。明确标签、验证行动和记录降密会让桌面更偏审计化。对某些玩家来说，这能增加公平；对另一些玩家来说，这会降低沉浸。本文建议把 KTSL 作为可调工具，而不是默认全开规则。

相关工作分组比较

本文相关工作可按方法分组。第一组是 TRPG 同步机制。D&D 提供严格 round 和 turn，Fate 提供 exchange，CoC Quick-Start 提供 Keeper 裁量和模糊 combat round，BitD 提供 flashback 和 cut to action [dndbasic2018; fateexchange; cocquickstart; bitdsrd]。这些方法各有价值，但没有直接给出“分队调查中如何同时维护信息边界和时间窗”的协议对象。

第二组是分布式时间和仿真。Lamport 给出因果偏序，Chandy-Misra 给出分布式仿真的 logical process 视角，Jefferson 给出乐观推进与 rollback 边界，HLA 给出 federation 和时间管理语言 [lamport1978; chandymisra1979; jefferson1985; ieee1516]。本文与这些工作的关系是类比转译，而非系统实现。本文把场景当作逻辑进程，把角色通信当作消息，把同步屏障当作保守推进点。

第三组是互斥和仲裁。Ricart-Agrawala 与 Maekawa 讨论临界区访问和投票集合 [ricart1981; maekawa1985]。本文把共享 NPC、共享物品和共享地点看作叙事临界区。不同之处在于，TRPG 的目标不是最小消息复杂度，而是让玩家觉得先后顺序有理有据。

第四组是信息流控制。Noninterference、Bell-LaPadula、DIFC 和 LIO 都试图限制未授权信息影响低权限输出 [goguen1982; belllapadula1976; myers1997; stefan2011]。本文把这些概念转写为 InfoLabel、authorized audience、declassify_when 和 public_redaction。与安全系统相比，TRPG 信息流更强调可玩性和叙事降密。

第五组是叙事规划。Riedl-Young 强调情节因果和角色意图可信度 [riedlyoung2010]。这使本文不会把防泄露缩减为集合包含关系。一个行动即使信息上可解释，也要在角色动机上可接受。反过来，一个行动若信息上缺边，玩家可以通过补充角色推理建立合法路径。

结论

本文提出 KTSL，一个面向 CoC 分队调查的 KP 时间同步与防信息泄露三层协议。它把分队调查建模为带信息标签的多场景离散事件系统，用 Schedule 层维护因果偏序、同步屏障和提交边界，用 Filter 层维护信息敏感度、授权受众和降密条件，用 Coupling 层决定何时松散叙事、何时 exchange、何时严格轮次或合并场景。

KTSL 的核心判断是：分队调查中的时间同步不是全局秒表问题，防泄露也不是单纯私聊问题。KP 需要的是一个能区分事件因果、角色知识、玩家观察和场景耦合的运行时账本。这个账本不必复杂，但必须在高风险处清楚。

本文已经不再是只有评估方案的草稿。当前确定性 fixture 消融支持三层协议在受控案例中的机制有效性：Schedule 消除因果违反，Filter 消除未授权与公共泄露并完成降密，Coupling 消除高耦合时间漂移且未增加当前 fixture 的 spotlight gap。它仍不是完成真实桌面实证的最终论文。下一步应收集真实或更接近真实 transcript 的片段，用本文定义的指标比较 Baseline、Schedule-only、Schedule+Filter 和 KTSL-full，并根据结果校准耦合度阈值、redaction 规则和执行成本。若这些实验继续支持本文假设，KTSL 可以进一步发展为一页式 KP 工具、电子表格模板或跑团平台插件。

附录

一页式 KP 执行清单

开团前，KP 先列出核心线索。每条线索写四件事：谁最初能知道，敏感度是多少，公共摘要怎么说，怎样降密。然后列出可能分队的场景，给每对关键场景标低、中、高耦合。最后告诉玩家：分队允许，旁听也许会发生，但角色行动需要角色内依据。

开团中，KP 每次只处理一个 significant action。行动产生线索时，先写 InfoLabel，再选择输出通道。切镜前看一眼 SceneCard：有没有共享倒计时推进，有没有通信，有没有高耦合场景连续漂移，有没有玩家太久没有 spotlight。遇到高敏信息，不要在公共频道解释 payload。给 redaction，私发具体内容。

会合时，不要自动把所有私聊同步给全队。让角色复述、展示物证或转交笔记。复述到什么程度，就降密到什么程度。若玩家尝试使用旁听信息，问“你的角色怎么知道”。如果能给出合理路径，允许；如果不能，降级为模糊行动或拒绝精准行动。

团后复盘时，标注三件事：哪里发生了时间矛盾，哪里发生了未授权行动，哪里公共频道泄露了高敏 payload。若泄露主要来自 KP 公开叙述，下次调高敏感度或写更好的 redaction。若泄露主要来自玩家行动，强化 ValidateICAction。若等待时间过长，减少私聊长度并增加低敏公共摘要。

最小数据模板

SceneCard: scene_id: local_window: participants: mode: pending_events: committed_events: public_view: private_facts: barriers: EventRecord: id: scene: actors: action: happens_after: outputs: status: commit_reason: InfoLabel: id: source_event: sensitivity: owners: authorized_audience: payload: public_redaction: declassify_when: SceneCoupling: pair: shared_clue_chain: shared_countdown: shared_npc_or_object: physical_proximity: immediate_harm_dependency: score: recommended_mode:

证据等级索引

参考文献

• cocquickstart: Call of Cthulhu Quickstart Rules, 2026. https://chaosium.itch.io/call-of-cthulhu-quickstart-rules
• cocpdf: Call of Cthulhu 7th Edition Quick-Start Rules, 2014. https://www.fullasagoog.com/uploads/short-url/oTeMcZZrw4u3OOYgrpP0y3lZi2W.pdf
• dndbasic2018: Dungeons & Dragons Basic Rules, 2018. https://media.wizards.com/2018/dnd/downloads/DnD\_BasicRules\_2018.pdf
• fateexchange: Fate Core SRD: The Exchange, 2026. https://fate-srd.com/fate-core/exchange
• bitdsrd: Blades in the Dark SRD, 2026. https://raw.githubusercontent.com/amazingrando/blades-in-the-dark-srd-content/master/Blades-in-the-Dark-SRD.md
• rpgsplit: How do I keep a party together without railroading?, 2018. https://rpg.stackexchange.com/questions/113268/how-do-i-keep-a-party-together-without-railroading
• rpgmeta: How to prevent players from metagaming when they split the party?, 2016. https://rpg.stackexchange.com/questions/80118/how-to-prevent-players-from-metagaming-when-they-split-the-party
• lamport1978: Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 1978. https://lamport.azurewebsites.net/pubs/time-clocks.pdf
• ricart1981: An Optimal Algorithm for Mutual Exclusion in Computer Networks. Communications of the ACM, 1981. https://dl.acm.org/doi/10.1145/358527.358537
• ricartmirror: An Optimal Algorithm for Mutual Exclusion in Computer Networks, readable mirror, 1981. https://scispace.com/pdf/an-optimal-algorithm-for-mutual-exclusion-in-computer-lq856cslpa.pdf
• maekawa1985: A sqrt(N) Algorithm for Mutual Exclusion in Decentralized Systems. ACM Transactions on Computer Systems, 1985. https://dl.acm.org/doi/10.1145/214438.214445
• maekawamirror: A sqrt(N) Algorithm for Mutual Exclusion in Decentralized Systems, readable mirror, 1985. https://scispace.com/pdf/a-n-algorithm-for-mutual-exclusion-in-decentralized-systems-22c8zeohdp.pdf
• chandymisra1979: Distributed Simulation: A Case Study in Design and Verification of Distributed Programs. IEEE Transactions on Software Engineering, 1979. https://gdo-pdes-course-2014.llnl.gov/attachments/20776356/20906700.pdf
• jefferson1985: Virtual Time. ACM Transactions on Programming Languages and Systems, 1985. https://worrydream.com/refs/Jefferson\_1985\_-\_Virtual\_Time.pdf
• cristian1989springer: Probabilistic Clock Synchronization. Distributed Computing, 1989. https://link.springer.com/article/10.1007/BF01784024
• cristian1989ibm: Probabilistic Clock Synchronization, 1989. https://research.ibm.com/publications/probabilistic-clock-synchronization
• ieee1516: IEEE 1516-2025: Standard for Modeling and Simulation High Level Architecture, 2025. https://standards.ieee.org/ieee/1516/6687/
• rubinstein1982: Perfect Equilibrium in a Bargaining Model. Econometrica, 1982. https://arielrubinstein.tau.ac.il/papers/11.pdf
• goguen1982: Security Policies and Security Models. Proceedings of the 1982 IEEE Symposium on Security and Privacy, 1982. https://www.cs.purdue.edu/homes/ninghui/readings/AccessControl/goguen\_meseguer\_82.pdf
• belllapadula1976: Secure Computer System: Unified Exposition and Multics Interpretation. The MITRE Corporation, 1976. https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/early-cs-papers/bell76.pdf
• myers1997: A Decentralized Model for Information Flow Control. Proceedings of the Sixteenth ACM Symposium on Operating Systems Principles, 1997. https://www.cs.utexas.edu/~witchel/380L/papers/myers97sosp-iflow.pdf
• stefan2011: Flexible Dynamic Information Flow Control in Haskell. Proceedings of the 4th ACM Symposium on Haskell, 2011. https://www.scs.stanford.edu/~dm/home/papers/stefan%3Alio.pdf
• dwork2006: Calibrating Noise to Sensitivity in Private Data Analysis. Theory of Cryptography, Third Theory of Cryptography Conference, TCC 2006, 2006. https://people.csail.mit.edu/asmith/PS/sensitivity-tcc-final.pdf
• yao1986: How to Generate and Exchange Secrets. Proceedings of the 27th Annual Symposium on Foundations of Computer Science, 1986. https://mit6875.github.io/FA23HANDOUTS/yao-garbled-circuits.pdf
• riedlyoung2010: Narrative Planning: Balancing Plot and Character. Journal of Artificial Intelligence Research, 2010. https://faculty.cc.gatech.edu/~riedl/pubs/jair.pdf