# 状态栏——简单模式管理复杂状态
**你和他相处了三十章。**
他记得你第一次见面时说的话，记得你们吵架后谁先低头，记得那个只有你们两个人知道的秘密。直到某一天，对话框里出现了一句让你愣住的话——他叫错了你的名字，或者问起了一件他"应该"早就知道的事。
玩了50轮，好感度突然降到0。
这是**玩家**最熟悉的崩溃时刻。
***
而对于**创作者**来说，崩溃往往来得更早。
你花了一个下午写完了他的性格设定：傲娇但护短，嘴硬心软，在感情里永远慢半拍。但当你试图让他"记住事情"，工具给你的答案是——学 JSON，写 Patch 操作符，把角色状态拆成机器能读懂的格式...你调试了很久，可还是不知道bug到底在哪里
***
这两种困境指向的是同一个架构问题。而现有的两种主流范式——MVU 与MUFY代表的状态栏全文追加——恰好分别踩中了它的两面：
| 对比项 | MVU | mufy |
| ----------- | -------------------- | ---------------- |
| 创作者门槛 | 高（需写 JSON/Patch 操作符） | 低(自然语言描述状态和适量代码) |
| 历史 Token 增长 | 可控（仅携带最新状态） | 线性膨胀（每轮携带完整对话历史） |
| 状态与对话解耦 | ✅ | ❌ |
| 状态解析失败自动恢复 | ❌ | ❌ |
没有一种范式能同时做对这四件事，这是 Lumeow 想重新回答的问题。
#### 当前范式的局限
在解释我们的架构前，有必要先剖析现有状态管理机制为何会在长期交互过程中表现一般。
1. **MVU：创作者的繁琐声明 & 增量更新的不稳定性**
在社区中被广泛采用的MVU范式，要求模型像执行代码一样输出结构化的增量更新指令。其核心直觉是正确的：状态应该独立于对话历史，被单独存储和管理。 但它选择的实现方式——JSON Schema + 增量更新——在创作场景下代价太大：
1. 对创作者来说门槛极高——要定义 JSON Schema，要理解 JSONPatch 操作符。MVU的变量声明非常繁琐，如果创作者想让角色演变出极其细腻的内部情感，她必须编写复杂的 Prompt 指令，例如使用 `op: replace` 去定位 `path: /内心独白` 进行修改。这极大抬高了创作的门槛。
2. 增量更新的链路本身就是脆弱的。模型需要推理增量，并以严格的 JSON 格式输出操作指令，后端再做 Schema 校验和 patch 应用。这条链路上任何一环出错——delta 算错、path 写错、格式不合法——状态就无法更新，甚至静默地更新成脏数据。
随着基模能力增强，今天的模型完全可以遵从自然语言规则，直接给出每个状态的"终值"——"当前状态是什么"，而不是"应该怎么改"。少掉"回忆旧值→计算差量→格式化指令"这一整个中间环节，也就少掉了一整层出错的可能。
**2. Mufy为代表的全文追加范式：Token 膨胀与语境污染**
另一种做法是不要求模型做局部更新，而是让模型在每一轮的回复末尾，直接生成这一轮的状态信息，并随对话历史（Messages）永远保留在上下文中，例如mufy等平台。这种做法的确大幅降低了创作门槛——创作者不需要理解任何结构化语法，模型也以最自然的方式输出状态。但是这种做法在工程上是灾难性的。
1. 假设每次状态陈述包含 3000 个 Token，当对话进行几十轮后，单次 API 请求中会累积成千上万个冗余的旧状态 Token，这无形中使得用户的token成本线性增加，如下图所示。
2. 上下文窗口中存在大量结构类似的状态描述，可能导致大模型在最新一轮的生成时候，错误的学习到一些上下文中结构化的僵硬的表述方式，导致后面的状态生成太过于僵硬和同质，缺乏新意。
#### Lumeow ：抛弃局部逻辑，用“最简模式”实施干预
回看这两种范式，它们各自抓住了一个正确的直觉：
* MVU 的正确直觉是状态应该独立存储，不应该堆在对话历史里无限膨胀；
* mufy等平台的正确直觉是用自然语言描述状态，对创作者足够友好，对模型也足够自然。
问题在于，两者都只做对了一半。MVU 独立存储了，但用了过重的结构化格式；mufy用了自然语言，但没有独立存储。Lumeow 的做法是同时拿到这两个优点。整套状态管理只有三个步骤：
**第一步：两个输入框，各司其职**
创作者在 Lumeow 上配置角色状态时，只需要填写两个框：
**框1 · 面板输出规范**——用**自然语言**描述有哪些状态、怎么变化，没有 JSON Schema，没有类型声明。创作者像和人类演员讲戏一样描述需求就好。
```
每次回复时请维护以下状态变量：
1. 好感度（数值，0~100）
- 积极互动（关心、赞美、肢体接触）：+1~5
- 消极互动（冒犯、忽视、冷暴力）：-1~5
- 无明显情感互动时保持不变
2. 关系阶段（文字描述）
- 不要用固定词汇，用一句自然的话描述两人当前的关系氛围
- 随好感度和关键剧情事件自然演变，不要机械跳转
3. 内心独白（≤200字）
- 用角色自己的语气，写下他此刻绝对不会说出口的真实想法
```
\
**框2 · 后置状态栏代码**——填写状态的初始结构：
```xml
<好感度>30
<关系阶段>从小一起长大的邻居，关系亲近但从未想过"那方面"的事
<内心独白>她今天好像又迟到了……每次都要我在路口等。
```
这个框里的内容就是状态的"模板"——它定义了状态长什么样，同时提供初始值。平台会自动用 `` 标签将其包裹。**为什么要分成两个框？** 因为它们在运行时的命运不同：
* **框1（规则描述）** 是常驻指令，每轮都会拼进 prompt，让模型始终知道"该维护哪些变量、怎么更新"。
* **框2（状态数据）** 是动态快照，平台只会取最新一轮的版本拼进 prompt。历史轮次的旧状态会被自动剥离——这正是第三步要讲的核心机制。
如果把规则和状态混写在同一个框里，平台也能工作，但就无法精确区分"哪些该每轮重复、哪些该只保留最新"，状态管理的优化效果会打折扣。
> *💡 **关于格式选择：** 框2 支持 XML 和 DIV/HTML 两种风格。XML 更简洁、token 消耗更少；DIV 本身就是可渲染的 HTML，配合单独的 CSS 样式框可以直接呈现为可视化面板。无论哪种，CSS 样式只用于前端渲染，不会进入模型的上下文。*
**第二步：免去局部更新，直接“全量写出”最新状态**
在执行层，Lumeow 从不要求模型去思考"该修改哪个字段"。每次回复时，模型只需把当前所有状态变量的最新值全量写出，包裹在 `` ``标签里，附在正文之后：
```xml
(角色在正文剧情中做出了冷漠的回复...)
<关系阶段>表面若无其事，但实际上防线正在全面崩盘，只要对方再主动一步就会彻底沦陷。
<内心独白>
她刚才贴得太近了……
我连呼吸都不敢用力，万一被她听到心跳声该怎么办？
```
注意「关系阶段」——不是从"陌生人"跳到"朋友"的机械切换，而是一段捕捉了微妙心理的自然描述。「内心独白」带着角色鲜明的别扭和嘴硬。这些质感不会被数值或枚举消磨掉。
**第三步：后台处理，模型上下文中只有最新的状态**
\
既然模型每轮都全量写出状态，上下文岂不是会爆炸？这正是系统替创作者解决的事。每当模型生成一轮回复，系统自动将 `` 块从正文中拆出，分别存储。在组装下一轮 prompt 时：
* **历史消息只保留正文**：过去所有轮次的 `` 块已被剔除，历史变成干净、紧凑的纯剧情文本。
* **最新状态只挂一份**：系统在 prompt 末端注入最近一次成功解析的 `` 块，作为模型的唯一状态锚点。如果最新一轮解析失败，系统会自动向上查找最近的可用状态。
这意味着，无论对话进行了 10 轮还是 100 轮，状态信息占用的 token 始终是恒定的——永远只有最新的那一份。模型每次收到的都是：一段干净的历史剧情 + 一份完整的最新状态 + 玩家的新输入。创作者不需要理解这些机制。他们只需写好角色卡、填好两个框——所有上下文的裁剪、状态的存储与注入，都由系统在后台静默完成。\
**容错：当模型“错误”/“忘记”输出状态时**
LLM 不是确定性程序。在实际运行中，模型输出的 `` 块偶尔会出现问题——标签拼写错误、嵌套结构混乱、多余的转义字符导致 XML 解析失败，或者干脆在一轮超长回复中漏掉了整个状态块。无论哪种情况，系统都面临同一个局面：**这一轮拿不到有效状态。**如果系统的做法是"把上一轮输出的状态拼入下一轮 prompt"，那么一旦某一轮解析失败，下一轮 prompt 里就没有状态可拼——模型丢失了所有状态记忆，只能从上下文的剧情文本中去"猜"。更麻烦的是，没有状态锚点的这一轮大概率也不会输出正确格式，于是**缺失会一直传递下去**，直到玩家发现异常并手动介入。Lumeow 的处理方式是：当系统检测到最新一轮没有有效的 `` 块时，**自动向上查找最近一次成功解析的状态快照**，将其注入下一轮 prompt。
```
第 5 轮：正常输出 → 解析成功，好感度 45 ✓
第 6 轮：输出了 但标签格式错误 → 解析失败
→ 系统自动回退，使用第 5 轮的快照（好感度 45）
第 7 轮：模型看到的状态锚点仍然是好感度 45
→ 基于此继续演绎，输出正确的 ✓
```
因为每一份快照都是完整的、自包含的，一次解析失败不会导致状态链断裂——最多暂停一拍，然后自动恢复。创作者和玩家甚至不会察觉中间有过一次失败。\
#### 结语
| 对比项 | MVU | mufy | Lumeow |
| ----------- | -------------------- | ---------------- | ----------- |
| 创作者门槛 | 高（需写 JSON/Patch 操作符） | 低（自然语言描述） | 低（自然语言描述） |
| 历史 Token 增长 | 可控（仅携带最新状态） | 线性膨胀（每轮携带完整对话历史） | 可控（仅携带最新状态） |
| 状态与对话解耦 | ✅ | ❌ | ✅ |
| 状态解析失败自动恢复 | ❌ | ❌ | ✅ |
**对抗复杂性，不应该引入对等的复杂规则。**Lumeow 的做法是：让创作者用自然语言描述状态，由系统在后台完成旧状态剔除与解析兜底。创作者不需要学习任何新的语法，Token 消耗保持可控，状态更新失败时也不会静默出错。随着模型能力的持续提升，我们认为好的架构应当克制自身的存在感——减少对创作者的约束，减少对模型的干预，只在数据流出现问题时介入修正。把更多的空间留给模型与创作者，而不是留给规则本身，从而实现用简单的模式管理复杂状态。
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.lumiao.ai/docs/guan-fang-bo-ke/zhuang-tai-lan-jian-dan-mo-shi-guan-li-fu-za-zhuang-tai.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.