Know What & Know How

在讨论具体的技术实现之前，这篇文章先说明一个更基础的问题： 为什么在 AI RP 场景下，可治理与可审计不是锦上添花，而是必须解决的前提。

LLM 天生就不可控

这是实话。

LLM 的输出不是确定性的。同样的输入、同样的模型、同样的参数，两次调用可能得到不同的结果。即使把 temperature 设为零，提示词的微小变动、上下文长度的变化、模型版本的更新，都会让输出发生偏移。

这个特性算不算问题？

对于很多人来说，不算。恰恰相反，很多人使用 LLM 就是因为它不可控。它偶尔会说出使用者没想到的东西，偶尔会在角色扮演中给出意料之外的反应。这种出乎意料，在很多场景下正是 LLM 的价值所在。

但对于另一些场景，尤其是中大型的 AI RP 项目，不可控会直接导致项目不可维护。

两类不同的使用方式

先区分两种情况。

第一种是轻量 RP。一个人打开聊天界面，选一张角色卡，开始对话。如果 AI 的回复不太对，可以重新生成一次。如果还是不对，可以手动编辑一下。如果整个体验偏了，可以删掉几层对话重新来。

这种情况下，不可控是可以接受的。纠正成本很低。

第二种是中大型 AI RP 项目。一个作者设计了完整的世界观、多个 NPC、复杂的状态规则、几十甚至上百条世界书条目、一组记忆提取和注入的逻辑。这个项目可能运行几个小时、几十个小时，甚至更久。

在这种情况下，如果系统在某个时刻做出了一个使用者无法理解的决定——一个奇怪的 NPC 反应、一条不该被写入的记忆、一个改变了关键状态的变量——使用者很难定位原因。

他不知道系统在那个时刻看到了什么上下文，不知道哪些规则被触发了，不知道记忆系统注入了什么内容，不知道提示词是怎样被拼出来的。

他只知道结果不对。但为什么不对，他无从查起。

不可控没有错，不可查才是问题

所以问题不在于 LLM 不可控。LLM 本来就不可控，这是它的底层特性，不是 bug。

问题在于，当不可控的事情发生之后，使用者有没有能力搞清楚发生了什么。

这就是"Know What"和"Know How"的区别。

Know What 回答的是：系统当前处于什么状态？哪些变量正在生效？哪些记忆 被写入了？哪些世界书条目命中了？当前会话绑定了哪些资产？

Know How 回答的是：这条回复是在什么条件下生成的？提示词具体是什么？编排器选择了哪个模式？每一步分别做了什么？记忆系统为什么决定提取这条事实而不是另一条？

缺少 Know What，系统对使用者来说是一个黑箱。使用者不知道系统知道什么。

缺少 Know How，系统对使用者来说是一个没有追溯能力的黑箱。出了问题时，使用者除了清空上下文重新来过之外，没有别的调试手段。

这不仅仅是调试需求

"可治理"和"可审计"听起来像是运维或者安全领域的词汇。但在 AI RP 项目里， 它们有更具体的含义。

可治理意味着使用者在任何时候都能看到系统状态的全貌，并且可以有选择地修正它。如果一条变量写错了，可以改掉。如果一条记忆不应该存在，可以标记为过时。如果一个世界书条目的触发条件太宽泛，可以调整。

做这些事情的前提是使用者知道状态是什么。

可审计意味着系统做出的每一个关键决定都有迹可循。一条回复被生成出来，使用者可以回溯：这一轮输入了哪些消息、注入了哪些记忆、命中了哪些世界书、Director 给出了什么导向、Verifier 做了什么检查。

做这些事情的前提是系统把这些信息记录下来，而不是用完就扔。

为什么许多现有工具做不到

很多 AI RP 工具的设计思路是：把上下文拼好，发给 LLM，把回复显示出来。中间的过程对使用者完全不可见。

这不一定是设计失误。这些工具最初是为轻量 RP 场景设计的，在那个场景下，这种简洁的路径是合理的。使用者不需要知道提示词长什么样。

但当同一个工具被用于更复杂的项目时，这个设计就会成为瓶颈。使用者被迫用猜测来排错。猜测 LLM 是不是收到了错误的上下文，猜测记忆是不是被错误注入了，猜测世界书是不是不该命中的条目命中了。

这种排错方式效率极低，而且不可靠。

TavernHeadless 在这个问题上的立场

TavernHeadless 从设计之初就把可治理和可审计当作基础要求，不是事后加上的可观测性功能。

几个具体的体现：

• 提示词组装过程不是隐藏的流水线。兼容模式有明确的拼接顺序，原生模式可以逐步映射为可回溯的节点图。每个阶段产出的中间结果都应该可以被查看和保存。

• Session State 是一个受治理的、可审计的状态层。使用者可以在任何时候查看当前会话的状态投影，知道哪些变量、哪些记忆、哪些约束正在生效。状态写入不是自动生效的，而是经过明确的提交流程。

• 记忆系统的提取、入库、检索逻辑是分离的。使用者可以查看哪些记忆被提取了、哪些被更新了、哪些被标记为过时了，以及这些操作的理由。

• Floor 和 MessagePage 的结构天然保留每一次生成的历史。不会因为重新生成而丢失旧版本的记录。

这些设计不保证 LLM 变得可控。LLM 仍然不可控。它们保证的是，当不可控 的事情发生时，使用者有能力知道发生了什么，并且有能力修正状态。

一个简单的判断标准

如果下面的问题在使用一个 AI RP 工具时都能得到明确的回答，那么这个工具在可治理和可审计方面是过关的：

• 系统现在认为哪些世界书条目是生效的？
• 这一轮的提示词最终长什么样？
• 这条记忆是什么时候、由哪一轮对话提取的？
• 如果一条回复不对，我能不能回退状态，而不是清空整个会话？
• 同一个楼层下两次不同的重新生成，提示词有区别吗？区别在哪？

对于一个只有几十轮对话的轻量 RP 来说，回答不了这些问题也许还能忍受。但对于一个需要维护几十个小时的大型项目来说，回答不了这些问题就意味着项目随时可能因为一个无法定位的问题而卡住。

这就是为什么 TavernHeadless 把这几个问题当作基本设计目标，而不是高级特性。