《回声》三层架构技术文档

1. 设计目标

《回声》的目标不是把 LLM 当作世界状态的控制中心，而是让它在互动叙事游戏里承担“有限、可验证、可回退”的职责。

核心问题有三个：

• 玩家可以自由输入，但系统不能失控。
• AI 可以自然回应，但不能篡改世界事实。
• AI 可以提出行动请求，但不能跳过游戏规则直接执行。

因此，项目把能力拆成三层。

2. 三层职责

L1：提示词与叙事约束层

职责：

• 固定 ECHO-7 的身份与语气
• 约束它的拒答边界
• 限制它对剧情真相的暴露时机
• 约束输出格式

这层解决的是“怎么说”的问题。

L2：可验证记忆层

职责：

• 保存门禁、线索、任务阶段、电力状态等世界事实
• 在多轮对话中为模型提供状态锚点
• 让玩家已知信息和模型读取信息尽量来自同一套系统记录

这层解决的是“依据什么说”的问题。

L3：工具调用执行层

职责：

• 把模型的行为请求转成结构化命令
• 通过白名单、目标 ID、剧情门槛和 Receiver 路由做执行裁决
• 最终把合法请求映射到 Unity 系统

这层解决的是“能不能真的做”的问题。

3. 三层之间的关系

这三层不是并列拼接，而是严格串联：

1. 玩家输入先进入 LLM 对话主链。
2. 提示词和状态上下文共同约束模型输出。
3. 模型输出被拆成可见文本与命令请求。
4. 命令请求必须经过执行层裁决。
5. 执行结果再回写状态层。

这样形成一个闭环：表达、状态、执行互相校验。

4. 主数据流

根据文章中的时序图和代码节选，核心链路可以抽象成：

1. 玩家发送消息
2. LLMChatManager 将消息写入完整聊天记录
3. 立即触发一次存档
4. ContextMemory 更新状态感知
5. LLM 服务携带上下文向模型请求回复
6. 模型返回文本，必要时附带命令信封
7. 管理器写入 AI 回复并再次存档
8. 若命令满足门槛，则进入命令路由
9. 若需要摘要，则异步更新总结并重组 prompt

这条链说明：存档、记忆、模型请求和系统执行都处于同一条可追踪流程中。

5. 为什么不能只靠提示词

只靠提示词会出现三类问题：

• 角色漂移：长对话后身份与口吻不稳定
• 状态漂移：模型口头陈述与系统事实脱节
• 执行越权：模型说“门开了”，但系统并没有真正开门

Facts 解决第二类问题，执行层解决第三类问题。只有三层完整，系统才真正具备可控性。

6. 架构边界原则

项目的关键边界可以整理成以下原则：

• 模型可以解释线索，但不能单方面宣布状态已经改变。
• 世界事实以系统记录为准，不以角色台词为准。
• 玩家可见文本和可执行命令必须分离。
• 关键命令必须绑定白名单、目标对象和剧情门槛。
• 命令被拒绝时，系统仍然需要有兜底推进能力。

这些原则实际上定义了“模型是叙事参与者，不是世界裁判”。

7. 系统价值

这套三层结构带来的价值有四个：

• 让开放式对话进入可控范围
• 让关键状态具有可追溯性
• 让副作用执行具备安全边界
• 让原型更容易拆解成答辩、论文和博客中的可展示模块

从毕业设计视角看，这套架构最强的地方不是“智能感”本身，而是它能解释清楚每一层到底在解决什么问题。

8. 对网站内容的意义

这篇技术内容在整个网站中的地位相当于总纲。它决定了另外几篇文章的阅读方式：

• Facts/Function Calling 是三层中的状态层与执行层细化
• Unity 系统文章是执行层落地
• 论文验证文章是三层效果的证据组织方式

因此，三层架构文档应被视为整个《回声》技术体系的总设计说明。