世界书与工具治理
这一页讲两件容易被混在一起的事：
- 世界书如何决定"额外注入哪些规则或设定"
- 工具中心如何决定"当前会话到底能不能真正调用某个工具"
它们看似是两条独立的功能线，但会通过"隔离发送"机制互相影响。理解这层关系是用好 ETOS 的关键。
一、世界书不是长文本备注
世界书在 ETOS 里不是"写一段 lore 放那里"，而是一套可触发、可排序、可限流的注入引擎。
基本单元是条目，每个条目至少可以定义：
- 主关键词
- 次关键词
- 次关键词逻辑
- 注入位置
- 角色
- 扫描深度
- 深度位置
- 概率、延迟、粘性、冷却
- 是否允许递归
所以它更像规则系统，而不是普通笔记。
触发怎么发生
世界书评估时会读取当前会话消息缓冲区，逐条判断条目是否命中。基础逻辑：
- 先取当前绑定的世界书集合
- 按书与条目设置决定扫描深度
- 用主关键词和次关键词做匹配
- 再叠加概率、延迟、sticky、cooldown、递归等运行时效果
- 最后按分组规则和预算规则筛掉超量条目
不是命中就一定塞
世界书受预算约束——即使所有条目都命中，也会按上限筛掉一部分。
次关键词逻辑
ETOS 的世界书不仅支持主关键词，还支持 secondary keys 和 selective logic。
这让同一个条目能表达更复杂的条件：
- 任意命中一个次关键词才算触发
- 必须全部命中才触发
- 某些关键词不能出现
这样它才适合做真正的上下文规约，而不是纯文本替换。
递归 / 延迟 / 粘性 / 冷却各解决什么
这些机制听起来复杂，但都在解决**"世界书太机械"**这个问题：
| 机制 | 解决什么 |
|---|---|
| 递归 | 允许某条目被已注入内容再次触发 |
| 延迟 | 不是一命中就立刻出现，而是几轮后才出现 |
| 粘性 | 触发一次后，接下来几轮保持生效 |
| 冷却 | 刚触发过后，若干轮内不要反复出现 |
没有这些机制，大型世界书会很快退化成无差别灌 prompt。
注入位置不是一个
世界书条目可以落在多个位置：
| 位置 | 说明 |
|---|---|
| 系统前置 | 拼到系统提示词最前 |
| 系统后置 | 拼到系统提示词最后 |
| AN 顶部 | 上下文顶部锚点 |
| AN 底部 | 上下文底部锚点 |
| 按深度插入 | 在聊天历史里精确位置插入 |
| 消息顶部 | 最新消息之前 |
| 消息底部 | 最新消息之后 |
| Outlet | 中部 outlet |
世界书不只是"加一段说明"，而是能精确控制自己影响哪一层消息结构。
预算控制为什么必要
ETOS 会在世界书评估完成后再做一次预算裁剪，至少控制：
- 最大注入条目数
- 最大注入字符数
没有这层控制，大世界书很容易直接把上下文窗口吃空。
二、世界书隔离发送
这是 ETOS 一个非常有辨识度的设计。
某个会话绑定世界书并开启**"绑定世界书时屏蔽记忆与工具"后，这个会话进入更纯的上下文模式**。
隔离时会发送的
- 全局提示词
- 话题提示词
- 增强提示词
- 世界书内容
隔离时不会发送的
- 长期记忆
- 跨会话摘要
- 用户画像
- MCP 工具
- 快捷指令工具
- 其他外部工具上下文
为什么这样设计
因为某些角色扮演、规则模拟、设定驱动型会话最怕被外部工具和用户长期偏好"串味"。
比如你在做一个赛博朋克 RPG 跑团，不希望模型突然蹦出来"根据你的画像，你偏好简洁回答"——那不是 NPC 该说的话。
三、工具中心到底在治理什么
很多 AI App 把工具管理做成很浅的"开关列表"。
ETOS 的工具中心更接近能力治理层。它关心的不只是"用户是不是开了"，还关心：
- 当前会话里是否真的可用
- 是否需要审批
- 是否被世界书隔离挡掉
- 服务器是否被选中用于聊天
- 单个工具是否被禁用
- 审批策略是否为始终拒绝
「配置启用」≠ 「会话可用」
工具中心有一个关键区分：
| 状态 | 含义 |
|---|---|
| 已配置启用 | 用户在设置里把这个工具的开关打开了 |
| 当前会话可用 | 这个工具在当前这个会话里真的会被发给模型 |
两者经常不一致——通常不是 bug，而是产品故意保留的解释层。
典型不一致场景
| 场景 | 表现 |
|---|---|
| 记忆写入开着，但当前会话启用了世界书隔离 | 配置启用，会话不可用 |
| MCP 服务器在线，但没有被选中用于聊天 | 配置启用，会话不可用 |
| 某个工具开着，但审批策略是始终拒绝 | 配置启用，但模型实际拿不到 |
工具中心会明确显示状态原因——比如"当前会话因世界书隔离发送而不会实际启用该工具"。
内置工具的治理依赖
ETOS 把一部分能力视作内置工具，例如：
save_memory（写入记忆）search_memory（检索记忆）- Widget 卡片能力
ask_user_input（向用户追问）
其中记忆写入和记忆检索不仅依赖工具开关，还依赖记忆系统本身的配置：
- 记忆系统总开关
- 是否允许写入
- 是否启用主动检索
Top K是否大于 0- 当前会话是否被世界书隔离
这就是为什么工具中心会明确显示"状态原因"——任一条件失败都会让工具实际不可用。
MCP 的治理逻辑
MCP 不会因为你配置了服务器就自动全部进入聊天。它至少要过几道门：
- 服务器是否被选中用于聊天
- 服务器元数据里是否真的发现了工具
- 单个工具是否启用
- 单个工具审批策略是否不是"始终拒绝"
Daily Pulse 读取 MCP 时也只会把"当前可用能力摘要"当作可调用能力，不会假装自己已经读到了外部实时信息。这是 Daily Pulse 设计里反复强调的一条硬约束。
快捷指令为什么区分直连和桥接
ETOS 对快捷指令工具提供两种优先模式：
- 直连优先
- 桥接优先
这不是视觉选项，而是执行策略——对应：
- 直接调用目标快捷指令
- 或者先通过桥接快捷指令中转，再回传结果
这让快捷指令既能轻量接入（直连），也能承接更复杂的参数和回调流（桥接）。
工具描述为什么也要治理
在 ETOS 里，工具描述不是纯 UI 文案——它本身就是模型看到的能力声明。
所以快捷指令工具支持：
- 自定义描述
- 让模型重新生成描述
目的不是润色说明，而是把"模型如何理解这个工具"纳入可调参数。一个描述清晰的工具会被 AI 更准确地调用；描述模糊的工具会被 AI 错用或不用。
最终怎么理解这一整套
| 系统 | 解决什么 |
|---|---|
| 世界书 | 该给模型什么规则和设定 |
| 工具中心 | 该给模型什么能力，以及这些能力在当前会话到底算不算真的开放 |
两者一叠加，ETOS 才有了一个重要特征：
它不是单纯让模型越来越强，而是让上下文与能力都变得可解释、可治理、可隔离。
这才是为什么 ETOS 的设置页那么长——它承担了一整套 AI 系统的治理控制台。
下一步
- 看上下文拼装的完整顺序 → 提示词与上下文拼装
- 看 Daily Pulse 如何利用这套治理结果 → Daily Pulse 设计原理
- 看记忆 / 摘要 / 画像三层细节 → 记忆、摘要与画像