ETOS LLM Studio Docs

主题

世界书与工具治理 ​

这一页讲两件很容易被混在一起的事：

  • 世界书如何决定“额外注入哪些规则或设定”
  • 工具中心如何决定“当前会话到底能不能真正调用某个工具”

一、世界书不是长文本备注 ​

世界书在 ETOS 里不是“写一段 lore 放那里”，而是一套可触发、可排序、可限流的注入引擎。

它的基本单元是条目，每个条目至少可以定义：

  • 主关键词
  • 次关键词
  • 次关键词逻辑
  • 注入位置
  • 角色
  • 扫描深度
  • 深度位置
  • 概率、延迟、粘性、冷却
  • 是否允许递归

所以它更像规则系统，而不是普通笔记。

触发怎么发生 ​

世界书评估时，会读取当前会话消息缓冲区，然后逐条判断条目是否命中。

基础逻辑是：

  1. 先取当前绑定的世界书集合。
  2. 按书与条目设置决定扫描深度。
  3. 用主关键词和次关键词做匹配。
  4. 再叠加概率、延迟、sticky、cooldown、递归等运行时效果。
  5. 最后按分组规则和预算规则筛掉超量条目。

这意味着世界书不是“命中就一定全部塞进去”，而是受预算约束的。

次关键词逻辑为什么重要 ​

ETOS 的世界书不仅支持主关键词，还支持 secondary keys 和 selective logic。

这让同一个条目能表达更复杂的条件，例如：

  • 任意命中一个次关键词才算触发
  • 必须全部命中才触发
  • 某些关键词不能出现

这样它才适合做真正的上下文规约，而不是纯文本替换。

递归、延迟、粘性、冷却在解决什么 ​

这些机制听起来复杂，但它们解决的都是“世界书太机械”这个问题。

  • 递归：允许某条目被已注入内容再次触发
  • 延迟：不是一命中就立刻出现，而是几轮后才出现
  • 粘性：触发一次后，接下来几轮保持生效
  • 冷却：刚触发过后，若干轮内不要反复出现

如果没有这些机制，大型世界书会很快退化成无差别灌 prompt。

注入位置不是一个 ​

世界书条目可以落在多个位置：

  • 系统前置
  • 系统后置
  • AN 顶部
  • AN 底部
  • 按深度插入
  • 消息顶部
  • 消息底部
  • Outlet

这意味着它不只是“加一段说明”，而是能精确控制自己影响哪一层消息结构。

预算控制为什么必要 ​

ETOS 会在世界书评估完成后再做一次预算裁剪，至少控制：

  • 最大注入条目数
  • 最大注入字符数

如果不做这层控制，大世界书很容易直接把上下文窗口吃空。

二、世界书隔离发送是什么意思 ​

这是 ETOS 一个非常有辨识度的设计。

当某个会话绑定世界书，并开启“绑定世界书时屏蔽记忆与工具”后，这个会话会进入更纯的上下文模式。

真正会发送的只剩：

  • 全局提示词
  • 话题提示词
  • 增强提示词
  • 世界书内容

不会发送的包括：

  • 长期记忆
  • 跨会话摘要
  • 用户画像
  • MCP
  • 快捷指令
  • 其他外部工具上下文

为什么这样做？

因为某些角色扮演、规则模拟、设定驱动型会话，最怕被外部工具和用户长期偏好“串味”。

三、工具中心到底在治理什么 ​

很多 AI App 会把工具管理做成一个很浅的“开关列表”。

ETOS 的工具中心更接近能力治理层。

它关心的不只是“用户是不是开了”，还关心：

  • 当前会话里是否真的可用
  • 是否需要审批
  • 是否被世界书隔离挡掉
  • 服务器是否被选中用于聊天
  • 单个工具是否被禁用
  • 审批策略是否为始终拒绝

配置启用，不等于会话可用 ​

工具中心有一个很关键的区分：

  • 已配置启用
  • 当前会话可用

这两个数字不一致，通常不是 bug，而是产品故意保留的解释层。

比如：

  • 记忆写入开着，但当前会话启用了世界书隔离，所以不可用
  • MCP 服务器在线，但没有被选中用于聊天，所以不可用
  • 某个工具开着，但审批策略是“始终拒绝”，所以不会实际暴露给模型

内置工具怎么治理 ​

ETOS 当前会把一部分能力视作内置工具，例如：

  • save_memory
  • search_memory
  • Widget 卡片能力
  • ask_user_input

其中记忆写入和记忆检索不仅依赖工具开关，还依赖记忆系统本身的配置：

  • 记忆系统总开关
  • 是否允许写入
  • 是否启用主动检索
  • Top K 是否大于 0
  • 当前会话是否被世界书隔离

这就是为什么工具中心会明确显示“状态原因”。

MCP 的治理逻辑 ​

MCP 不会因为你配置了服务器就自动全部进入聊天。

它至少还要经过几道门：

  • 服务器是否被选中用于聊天
  • 服务器元数据里是否真的发现了工具
  • 单个工具是否启用
  • 单个工具审批策略是否不是“始终拒绝”

Daily Pulse 读取 MCP 时，也只会把“当前可用能力摘要”当作可调用能力，不会假装自己已经读到了外部实时信息。

快捷指令为什么区分直连和桥接 ​

ETOS 对快捷指令工具提供两种优先模式：

  • 直连优先
  • 桥接优先

这不是视觉选项，而是执行策略。

它对应的是：

  • 直接调用目标快捷指令
  • 或者先通过桥接快捷指令中转，再回传结果

这让快捷指令既能轻量接入，也能承接更复杂的参数和回调流。

工具描述为什么也要治理 ​

在 ETOS 里，工具描述不是纯 UI 文案，它本身就是模型看到的能力声明。

所以快捷指令工具支持：

  • 自定义描述
  • 让模型重新生成描述

目的不是润色说明，而是把“模型如何理解这个工具”纳入可调参数。

最后怎么理解这一整套 ​

世界书解决的是“该给模型什么规则和设定”。

工具中心解决的是“该给模型什么能力，以及这些能力在当前会话到底算不算真的开放”。

两者一叠加，ETOS 才有了一个很重要的特征：

它不是单纯让模型越来越强，而是让上下文与能力都变得可解释、可治理、可隔离。