[Todo]引入 Rig，构建通用模型提供层与 Agent/Tool/Skill 体系，释放 Agentic RP 能力

[makerlinck]

诉求

• 需要一份相对完善的CODE_OF_CONDUCT及CONTRIBUTING文档，将其作为该项目的理解补充，以便在不破坏当前实现的情况下更好地尝试参与本项目开发。
• 了解详细的项目线路图，以定位到自己能够参与的部分。
• 了解其他贡献者对以下内容 + AI RP的看法观点。

It's Time To Revolution

在 TauriTavern（TT）的 2.0.0-Prev 使用过程中，Agentic RP（具有智能体能力的角色扮演）展现出了显著潜力。为了将这一能力正式落地，后来我考察了多个具备 Tools & Skills 支持的前端平台（如 Open WebUI、Cherry Studio），并尝试在这些平台上运行 Agentic RP 工作负载。然而，它们普遍存在以下阻碍：

其他软件:

• 配置流程复杂且闭锁：无法像 SillyTavern（ST）那样一键导入角色卡；工具/技能的触发往往依赖类“世界书”的Tool Calling，缺少针对 RP 场景的简洁抽象。
• 工具调用稳定性差：OWUI 在智能体模式下频繁出现工具调用后无返回、工作流中断的问题（上游遗留缺陷）。
• Skill 实现不完整：CherryStudio 的“技能”仅是一个独立的 Markdown 文档，无法携带所需的 Python 脚本、参考资源等完整执行环境，导致难以构建功能完整的技能；两个平台均无法在 Skill 中引入脚本层以实现精细控制。

TT:

• 可复用性低：TT当前实现要兼容多种 LLM 提供商，需分别处理请求/响应模型、工具调用格式，维护成本高，且需要在上游供应商新标准下发后即时更新。
• 工具调用错误问题 在智能体产生非预期行为后的错误没有输出到用户可见的地方。

OWUI 的一个优势在于门控机制（Valve），可视为一种前处理-提示词注入-后处理的工作流编排能力，这一点值得参考，实现比ST更加优雅。

基于以上观察，我计划在 TT 中引入 Rig Crate —— 一个 Rust 生态中的 LLM 应用框架，它既能统一抽象不同模型提供商的请求/响应模型，又原生提供了完善的 Tool Calling 与 Agent 支持。这将大幅降低多供应商兼容性维护成本，并为 Agentic RP 提供基建。

目标

1. 统一模型提供层（ModelProvider）：通过 Rig 实现对接多种 LLM 提供商（OpenAI、Anthropic、本地模型等）的共同接口，覆盖请求构造、响应解析、工具调用格式转换等差异。
2. 原生 Agent / Tool / Skill 体系：利用 Rig 的 Agent 与 Tool Calling 能力，设计符合 RP 场景的 Tools 与 Skills 抽象，并支持引入 Python 等脚本语言实现更精细、有状态的控制。
3. 引入工作流编排能力：借鉴 OWUI 的门控机制，实现请求前处理（上下文组装、提示词注入）和响应后处理流水线，提升 Agentic RP 的连贯性和可控性。
4. 兼容且扩展的角色卡规范：定义包含 Agent 配置（工具绑定、技能列表、门控规则等）的新版角色卡结构，同时确保导入/导出逻辑不会修改或破坏现有 ST 角色卡中的无关字段。

拟实施方案

1. 模型提供层抽象

• 集成 Rig 作为模型交互的中间层，利用其 ModelProvider trait 统一不同后端的调用方式。
• 实现至少包括 OpenAI-compatible、Anthropic 等优先供应商的适配器，并保留扩展点。
• 通过 Rig 的原生 Tool Calling 支持，抽象各厂商在 function calling 实现上的差异。

2. Agent / SubAgent / Tool / Skill 设计

• Tool：定义可被模型调用的原子操作（如获取角色信息、搜索世界知识、读写状态等），以 Rust trait 或结构体实现，同时桥接到 Rig 的 Tool 定义。增添内置Tool: Output Check，使用特定的方法检验输出是否符合用户要求（正则匹配/LLM模式，输入(str)，返回success(bool)、message:(string)）
• Skill：设计为打包了工具、脚本、资源文件和配置的完整单元，可包含 Python 脚本（通过进程调用或嵌入解释器），并支持在角色卡中执行。
• Agent：基于 Rig 的 Agent 抽象，管理对话上下文、工具调度与多步推理循环，确保工具调用后能够正确恢复对话流（解决 OWUI 中断问题）。
• SubAgent (新增): 通过Tool Calling新增 Create/Remove/Run SubAgent等方法实现子Agent调用

3. 门控工作流（可选，后续阶段）

• 定义 Gate 接口，按序执行前置处理（如动态提示词模板注入、RAG 检索）和后置处理（如结果审查）。
• 角色卡中可配置启用的 Gate 链。

4. 角色卡兼容性方案

• 在设计新版角色卡结构时，采用向后兼容的扩展方式（如增加 agent 字段），保持现有 ST 字段不变。
• 导入/导出逻辑基于 Serde 的反序列化策略，忽略未识别的字段，确保只修改与 Agent 相关部分，不影响其他内容。且导出逻辑新增可选携带Agent配置导出
• 提供迁移工具或文档，指导用户从传统角色卡升级为 Agentic 角色卡。

5. RP现状与未来可能 (愿望单)

未来模型提供商会推出更加强劲的模型，但构想是针对于提高模型表现的下限。
现状: ST生态下的RP要求LLM同时处理遵循用户指示、内容编排、文本生成等多种内容。然而从原理上来讲，提示词工程的上限已经确定了该模式在很多场景下（如多角色、文风控制、续写、严格指令遵循等）是有天生缺陷的，也不能要求所有创作者拥有顶级的提示词撰写能力。

上下文控制类改善方向:

---

• 现状: RP场景下会因为前文/提示词提到了某个物品、某件事而导致后文会频繁出现同样的描写 （你说得对，但是不是...而是） 或是因以科幻类世界观为基调，频繁在文学表达中出现大量专业术语破坏体验。
• 改善: 允许Agent根据条件自动丢弃部分上下文，让无关的文学类、场景渲染类信息不进入后续对话（文学表现与RP引擎上下文解耦，让特定模型自己筛选所需信息）

文风控制类改善方向:

• 现状: 因单个模型的缺陷而导致整个输出被污染，复用其他创作者提供的卡面表现差异大。
• 改善: 每次输出需要根据结果动态调整内容

世界常识:

• 现状: 单个模型获取上下文，判断计算变量，分散了对内容本身的关注点
• 改善: 引入事件链+世界变量、角色变量、用户变量，并通过Skill + Python脚本让AI操作对象变得单一，明确。

例子:
1. 用户输入: "Hello TauriTavern."
2. 提示词合成,请求（意图识别、指令解构）。
event -> from={{user}},action: greeting, to {{characterA}}
若拥有对greeting event的控制设定，则允许自动修改其他行为如reply行为提示摘要，随机情绪相关变量修改等。
3. LLM获得结果，并根据以上事件链、变量信息进行回复。

兼容性与风险

• 没有考虑全场景的适配度，需要考虑有没有更加通用的特性实现方式。
• 有待研究与评估 Rig 在 Tauri 环境下的集成可行性。
• 引入 Rig 可能会增加项目依赖体积，需评估其对 Tauri 构建产物大小和启动性能的影响。
• Python 脚本宿主的安全性需通过沙箱或进程隔离来保证。
• 角色卡兼容性必须经过充分测试，确保与 SillyTavern 生态的互通性不被破坏。

[Darkatse]

这个感觉放在Discussion更合适一点，我先转过来了

1、Rig这个库之前@LeenHawk 也和我提到过。怎么说呢，如果构建的是ChatBox类应用的话Rig是一个非常不错的选择。但是TauriTavern还有着兼容SillyTavern生态的任务，Rig可以轻松的提供Provider层面的统一，但是LLM API secrets、iOS policy、endpoint override、prompt cache、logging、HttpClientPool、cancel/session 生命周期这些东西仍然还在ChatCompletionService中，如果把这些东西全放进Rig的additional_params里，我觉得恐怕会比现在的状态更难以维护。

2、Agent系统目前与TavernHeadless的目标类似，想要打造全链路可审计的Agent环境。若要加入Rig的话，就会出现两套Agent runtime，journal与provider_state等字段的所有权问题就会变得很模糊，不利于后续维护

3、Python的话强行嵌入解释器还是太难了，后续会考虑加入可执行js脚本，直接扔给前端webview进行执行，维护成本最低（

[LeenHawk]

对项目定位大概了解了，这是非常有用的回复。🖖

其实感觉最大需求是缓存 缓存解决了 rp flow大不了多转两次

说到缓存了，其实酒馆后端也需要一个缓存系统。太多的东西是重复计算了。

啊 我说的是LLM缓存 大部分预设 插件 根本就是缓存破坏者 之前白嫖渠道多的时候还好 现在少了按token 感觉预算很紧张

[Darkatse]

对项目定位大概了解了，这是非常有用的回复。🖖

其实感觉最大需求是缓存 缓存解决了 rp flow大不了多转两次

说到缓存了，其实酒馆后端也需要一个缓存系统。太多的东西是重复计算了。

啊 我说的是LLM缓存 大部分预设 插件 根本就是缓存破坏者 之前白嫖渠道多的时候还好 现在少了按token 感觉预算很紧张

我知道是LLM缓存啦，但是这种生态的东西平台能做的有限。后端缓存纯粹是我最近在构思性能优化时候的小巧思。

[makerlinck]

对项目定位大概了解了，这是非常有用的回复。🖖

其实感觉最大需求是缓存 缓存解决了 rp flow大不了多转两次

说到缓存了，其实酒馆后端也需要一个缓存系统。太多的东西是重复计算了。

我认为在RP场景下可能更多是一种对指令遵循和成本节约的取舍，上下文+世界书作为完全静态的内容放在前面的话会不会造成过快遗忘，以及太过于关注世界书的一些内容，导致内容重复？

[LeenHawk]

对项目定位大概了解了，这是非常有用的回复。🖖

其实感觉最大需求是缓存 缓存解决了 rp flow大不了多转两次

说到缓存了，其实酒馆后端也需要一个缓存系统。太多的东西是重复计算了。

我认为在RP场景下可能更多是一种对指令遵循和成本节约的取舍，上下文+世界书作为完全静态的内容放在前面的话会不会造成过快遗忘，以及太过于关注世界书的一些内容，导致内容重复？

动态模式最大的问题就是0命中 至少官方的demo应该得考虑这个的

[LeenHawk]

对项目定位大概了解了，这是非常有用的回复。🖖

其实感觉最大需求是缓存 缓存解决了 rp flow大不了多转两次

说到缓存了，其实酒馆后端也需要一个缓存系统。太多的东西是重复计算了。

啊 我说的是LLM缓存 大部分预设 插件 根本就是缓存破坏者 之前白嫖渠道多的时候还好 现在少了按token 感觉预算很紧张

我知道是LLM缓存啦，但是这种生态的东西平台能做的有限。后端缓存纯粹是我最近在构思性能优化时候的小巧思。

那样得改执行模型吧 理论上当然是希望一个DAG里就存一份主体 其他都用diff来实现 但是感觉实际实现会很麻烦

[yezui1997]

API链接方面有没有考虑接入公益站？

[Darkatse]

目前的agent调用次数很多，会对公益站造成很大负担。若想使用公益站进行Agent RP，请咨询公益站主是否允许使用，或者自行寻找允许接入agent使用的公益站。