Agent 接管世界书

因为大量用户墙内引流数据库，所以数据库现在提示词默认不提供破限功能，任何gemini系列模型出现的涉黄涉恐涉暴涉未成年导致空回、截断、触发安全审查、AI响应收集失败、分组更新失败等等问题，要么自己缝合破限到提示词里，要么换低甲无甲模型

本章节方案为数据库兜底的可正常运行的设置，并非gemini应用方案

---

基础设置

确认设置无明显问题后

刷新浏览器页面

然后重进聊天记录

---

☯（独立）Agent接管世界书

【独立功能】Agent接管世界书

⚠️ 声明： 本教程仅适用于数据库 @spv7.0及以上版本观前提示：电脑端若看不清图片可以使用Ctrl加滚轮放大

返回目录请点击下面蓝色字体点我返回目录

这是数据库@spv7.0新更新的一个独立功能。

⚠️ 先纠正一个误解：Agent 接管世界书管的是"角色卡自己的世界书绿灯条目"，不是数据库的记忆。 数据库的纪要/总结记忆是另一回事。

一、它是什么（原理）

它管的是"角色卡自己的世界书绿灯条目"

一张角色卡通常自带一堆世界书条目（角色设定、世界观、地点、物品、NPC 介绍……）。这些条目很多是绿灯条目——靠关键词触发：你对话里说到对应关键词，这个条目才被激活、注入给 AI。

关键词触发的痛点

关键词匹配很死板。比如一个角色叫 toshima，做成绿灯条目后关键词只设了 toshima：

• 你打 toshima → 命中，绿灯激活。✅
• 你打 t一串、to一串（昵称 / 缩写 / 变体）→ 不命中，绿灯不激活。❌

老办法是手动给每个绿灯条目的关键词里疯狂加外号：toshima / to一串 / t一串 / 小t一串 / …，加到吐还总有漏的。

Agent 接管：把"关键词触发"换成"LLM 按语义判断触发"

Agent世界书开启后：

• Agent 会临时禁用这些绿灯条目的原生关键词触发（不让酒馆再靠死板关键词瞎点亮）。
• 每轮由 Agent（一个 LLM）读当前对话，判断"这段话是不是在指某个条目"，是就激活它。
• 判断的依据来自 Skill 元数据（条目的描述 / 触发条件），由一键 Skill 化自动生成。

回到 toshima 的例子——Skill 化以后，Agent（LLM）看了关键词和上下文，能理解"你是在把这个角色当作触发对象"，于是你写 t一串 / to一串 也能正常激活 toshima 那个条目。

Agent 接管 = 让 LLM 代替关键词匹配，来决定角色卡的绿灯条目该不该激活。 好处是不用再给每个条目手动加一堆外号，昵称 / 变体 / 代称都能正确触发。

Agent不管数据库的记忆

再说一遍容易混的点：

• Agent 接管管的是角色卡作者写的那些世界书的绿灯条目。

适合谁用？

角色卡自己没有动态世界书脚本

绿灯条目靠关键词触发

关键词机制触发结果不理想

如果你的卡已经用了完善的动态提示词机制控制条目触发，那就不需要 Agent 接管了。

二、三种模式

Agent 接管有三种模式（在剧情推进页的 Agent 总控条选）：

模式	行为	适合
关闭	Agent 不接管，绿灯条目走酒馆原生关键词扫描（默认）	新手、没昵称触发困扰
仅观察	Agent 只观察、不动条目，不改变现有触发	想试水、看 Agent 会怎么判断
Agent 接管	Agent 主动管理：禁用原生关键词触发，每轮由 LLM 判断该激活哪些	进阶、想解决昵称/变体触发问题

默认是关闭。

三、数据存在哪（重要）

• Agent信息存在角色卡的世界书里，不在聊天对话楼层里。 同一个角色卡换聊天，Agent信息还在。
• 数据库的记忆数据仍然存在聊天楼层，Agent 接管完全不改变这件事。

四、怎么用（操作步骤）

步骤

• 进剧情推进页，点 一键 Skill 化：让 AI 读每个绿灯条目的内容，自动给它生成 Skill 元数据（描述 / 触发条件），写进条目备注。这是 Agent 能"看懂"条目、做出正确判断的依据。
• 找到 Agent 总控条（在"剧情推进世界书"面板上方）。
• 把模式选成 Agent 接管。
• （可选）配一个 Agent API 预设：Agent 判断用一次 AI 调用。
• 正常聊天。Agent 会在后台每轮自动判断该激活哪些绿灯条目。

想重来 / 配置乱了：点 清理并初始化——它会删掉 Agent 写的状态条目和 Skill 元数据，恢复成没接管的样子，然后你可以重新开。

Skill 是什么 / 为什么要 Skill 化

Agent 要判断"这段对话该不该激活某个条目"，得先知道这个条目是讲什么的、什么情况下该激活。这就是 Skill 元数据：

• 描述：这个条目讲的是什么（比如"角色 toshima 的设定"）。
• 触发条件：什么情况下该激活它（比如"对话提到 toshima、或以昵称 / 代称指代这个角色时"）。
• TK：大概占多少 token。

一键 Skill 化就是让 AI 读每个条目、自动生成这套元数据。Skill 化之后 Agent 判断就有了依据。

没 Skill 化的条目不进候选池、Agent 不会管它。

五、大世界书、多条目人设、上限与 Skill 失败

1. 世界书特别大（300 多条）怎么办

Agent 有数量上限，超过上限的条目不进候选、也不会被 Skill 化，等于没被 Agent 管。默认上限：

• 进入 Agent 决策的候选条目数：默认 100（最大 300）。
• 一键 Skill 化单次最多处理的条目数：默认 100（最大 300）。

怎么办：

• 进 剧情推进页 → Agent 总控条 → 点 "Agent 高级设置" → 在「上下文参数」里把 "决策世界书候选数" 和 "Skill 化最大条目数" 都调到最大 300（见下一节"上限在哪改"）。
• 超过 300 条的部分，目前处理不了。要么拆世界书（把不常触发的挪到别的书），要么精简条目。
• 大世界书 Skill 化会逐条调 AI、按并发跑，耗 API。可以在高级设置里调高"Skill 化 API 并发数"加快（见下），但小心被公益站ban了。

2. 世界书里一个角色的人设拆成多个条目、拼接才完整，怎么办

如果一个角色的绿灯人设被拆成三四条（拼接起来才完整），而且这几条的关键词都设成一样的，开 Agent 会不会漏触发？

答案是会，有可能漏。

原因：Agent 决策时没有"按关键词分组、绑定一起激活"的机制。它把每个 Skill 化的条目都当成独立候选（各自一个编号），让 LLM 按编号多选——关键词相同并不会让它们被绑定。

怎么办（按推荐顺序）：

• 最好把一个角色的完整人设合并成一个条目——这是最稳的。
• 实在必须拆：给拆出来的每块条目，手动把它们 Skill 元数据里的"触发条件"写成完全一样且尽量宽，让 LLM 倾向于把它们一起选中。但这只是降低概率，不保证LLM 不会遗漏。
• 把这种人设改成蓝灯（常驻条目），让它始终注入、不靠触发，代价是占用token。
• 这张卡干脆别开 Agent 接管，保留原生关键词触发：反正你的关键词都设一样了，原生触发能保证几条一起亮，反而比 Agent 更可靠。

3. Skill 数量上限在哪改

剧情推进页 → Agent 总控条 → 点 "Agent 高级设置" 按钮（打开一个抽屉），里面分几块：

「上下文参数」（有"恢复默认"按钮）：

参数	默认	范围	作用
决策世界书候选数	100	1–300	进入 Agent 决策的候选条目最大数量
Skill 化最大条目数	100	1–300	一键 Skill 化单次最多处理多少条目
绿灯最小 TK 预算	20000	—	Agent 选绿灯条目的目标下限（提示模型别选太少）
绿灯最大 TK 预算	80000	—	每通道 / 每任务能选的绿灯条目 TK 上限
最近上下文层数	2	1–20	Agent 决策时读最近几层对话
Agent AI 最大尝试次数	2	1–10	Agent 决策与 Skill 化的 AI 重试次数
剧情世界书扫描消息数	3	1–20	剧情推进读世界书时回看几条消息

「Skill 化执行参数」：

参数	默认	范围	作用
Skill 化 API 并发数	3	1–5	一键 Skill 化同时调用 API 的条目数；调高更快但更压 API

提示词模板（Agent 决策提示词 / Skill 化提示词）也在这里编辑，每段都有"恢复默认"。新手别动提示词。

4. Skill 化失败了怎么办

Skill 化是逐条调 AI 生成元数据，可能部分失败（某几条没生成成功）。表现：操作结果会告诉你"成功 / 跳过 / 失败各多少条"。

应对：

• 检查 Skill 化用的 API（Agent Skill API 预设）通不通、模型够不够听话。
• 重新点一次一键 Skill 化——它会再处理，把上次失败的补上。
• 还不行，在 Agent 高级设置里把 "Agent AI 最大尝试次数" 调高一点（别太高，会放大请求量）。
• 看运行日志尾部看具体哪条失败、为什么。
• 实在不行，清理并初始化重来。

5. 为什么 Skill 化后条目"变少了"

先放心：条目没有被删，也没消失。 只是有些条目被候选过滤排除了，没进 Skill 化、所以界面里看不到它们被 Skill 化。

6. 用了数据库变量 / EJS 动态提示词 / 分阶段人设怎么办

先给结论：不冲突，可以正常用。 数据库自己会预先渲染 EJS 和数据库变量，Agent 功能不影响这一步。

很多人担心"Agent 会不会和动态提示词打架"，其实它俩各管各的事，不打架：

谁	管什么	什么时候做
数据库（变量/EJS 渲染）	把条目内容里的 {[db.…]} / {[sql …]} / EJS 按当前状态填成真实内容	注入时（发给 AI 之前）
Agent	只决定这条条目该不该被激活	注入之前，根据 Skill 元数据判断

关键点：

• Agent greenlight 的条目，走的是数据库正常的世界书注入管线。 条目被 Agent 选中后，内容照样经过数据库的变量 / EJS 渲染——所以 {[db.主角信息.…]} 会正确填成当前值，分阶段人设也会按当前阶段渲染出对应内容。不会变成一堆占位符原文。
• Agent 决策时只看 Skill 元数据（描述 / 触发条件），不看条目正文。 它判断的是"这条和当前对话相不相关"，不是"这条正文具体是什么"。而一个条目"是讲什么的"（比如"这是主角的人设条目"）不会因为阶段不同而变——变的只是正文内容（由数据库渲染负责）。所以 Agent 照样能准确判断该不该激活。
• 分阶段人设完全没问题： Agent 管"提到主角就激活这条"，数据库管"激活后按当前阶段把内容渲染出来"。该激活的照样激活，激活后该是哪个阶段就显示哪个阶段，各司其职。

提醒： Skill 化时，AI 读到的是条目正文原文（含 {[db.…]} 占位符），生成的"描述"是看模板写的。绝大多数情况下足够用——模板本身就能看出这条是讲什么的。只有当你的模板逻辑特别绕、AI 看不懂时，生成的描述质量才可能打折；这种时候手动改一下那条的 Skill 元数据描述就行。

动态变量 / EJS / 分阶段人设 和 Agent 不冲突，可以一起用。Agent 管"该不该亮"，数据库管"亮了之后填什么内容"。

六、世界书更新了 / 角色卡更新了 / 新增条目怎么办

角色卡更新（更新或替换了世界书）

因为 Agent 配置存在角色卡世界书里，导入新版角色卡可能会覆盖或丢掉这个配置。后果：

• Agent 配置没了。
• 应对：新版角色卡导入后，进剧情推进页重新把 Agent 开起来、重新 Skill 化一次。Skill 元数据如果也跟着世界书条目被覆盖了，也要重新生成。

自己在世界书里新增了条目

Agent 模式下，只有被 Skill 化的条目才进候选池。新加的绿灯条目默认没有 Skill 元数据，Agent 不会管它。

• 应对：新条目加好后，重新点一次一键 Skill 化，让 Agent 给新条目也生成元数据、纳入管理。

世界书条目改名 / 改关键词 / 改内容

Agent 接管时会拍一个快照记录候选条目的原状态。手动改了被接管的条目：

• 数据库能通过快照检测到变化，并按需更新。
• 一般不会出错，但改得多、想干净点，清理并初始化重来最稳。

七、会不会数据污染

正常使用不会。 数据库做了几层防护：

• 只动候选条目：Agent 只管理"被 Skill 化"的那批绿灯条目，不碰其他条目。你没纳入的条目（包括蓝灯常驻条目、数据库自己注入的条目），Agent 不会去改。
• 接管前拍快照：禁用原生触发前，记录每个候选条目的原状态（原来开没开、原关键词、原类型）。
• 关闭时自动恢复：你把 Agent 关掉（切回关闭模式）时，数据库会按快照把条目恢复成接管前的样子，不留尾巴。
• 配置条目是隐藏的：存配置的世界书条目默认禁用、防递归，不会自己跑去触发 / 污染提示词。

可能出问题的几种情况

情况	后果	应对
手动删了 / 改了那个隐藏的配置条目	Agent 配置丢失，回退默认	重新开启 Agent
导入新版角色卡覆盖了世界书	配置 + Skill 元数据可能都没了	重新开启 + 重新 Skill 化
同时被别的插件 / 手动改了候选条目	快照检测到变化，可能状态不一致	清理并初始化重来
Agent API 太弱 / 没配	Agent 判断失败，该激活的没激活	换听话模型，看日志

别手动去动那个配置条目和被接管条目备注里的 Skill 元数据；要换角色卡或大改世界书前，先"清理并初始化"或关掉 Agent。