本帖最后由 player123 于 2026-10-26 05:10 编辑
安全声明： 本mod仍然处于极早期开发环节，可能包含极多bug/潜在的屎山崩塌风险，导致运行不稳定/炸档坏档/性能下降等情况，建议酌情添加；
本mod已经完成了相当一部分的重构与修整，修复了大量bug与性能问题，但是仍然可能包含bug/潜在的屎山崩塌风险，导致运行不稳定/炸档坏档/性能下降等情况，建议酌情添加； api key目前明码存于本地，如果你的电脑本地库存被人恶意访问，api key有泄露风险（不过据我查阅隔壁rimtalk的key似乎也是明码存于本地）； 本mod需要互联网访问才能正常运行，且只会和你的api后端进行通信，本人不会收集任何信息； mod大量使用了alex在0.98刚刚更新的java17逻辑，所以无任何向下兼容可能。 本mod包含ai生成内容与ai代码，霸主与卢德教徒慎入。
进入正题我一直觉得远行星号的rpg内容很吸引人，但作为多周目玩家总觉得游戏的文本量难以支持玩家的叙事需求。结合隔壁rimtalk的受欢迎程度，于是俺寻思能不能把llm内容引入远神，看能碰撞出什么样的火花。作为一个抛砖引玉的实现来开发。 Mod目前分为三个部分发布： LLM Core处理游戏和api沟通的纯粹上下行路由，支持openai格式工具调用。 LLM Comms提供了一些我对llm接入的简单探索：NPC对话，舰队通讯和战斗骚话。 Simplemissionlib与ai通讯大体无关，目前是我对原版酒吧任务闭环的抽象，用于LLM Comms中npc任务发布的工具，后续的npc可用的更多任务/行为框架会放在这里。
同时附上LLM Core的通信api和给自定义npc接入ai对话的接口，方便mod作者给自己的npc接入ai。 下面是一些内容演示（友情出演：deepseekv4-flash老师）：
NPC对话（相比于之前的预告修改了UI） 可以和npc对话，并且支持一些工具调用：这目前写了几个ai会主动调用的原生工具：
任务管理：依赖simplemissionlib，负责发布与修改任务，可以讨价还价，目前只支持原版酒吧任务（别想着忽悠ai给你奖励调到100w，我加了保险，但如果你真的想写小作文越狱那就给你了）
历史查询：如果npc不知道你说的英仙座历史，可能会从一个知识库里面找一些知识，但知识库目前比较简陋，而且ai调用比较随机（比如下图ai在查奶龙是什么）
切断通信：npc被惹恼或者和你告别的时候会主动关闭通信
还有一些隐藏层用的工具，不过玩家对话时用不到
新版本内容：玩家现在可以和宇宙中的舰队交互，新增行为如转账，结束敌对行为和交火
示例一：玩家打劫商队不成急眼干架
示例二：给巡逻队小礼物巡逻队主动离开
ai在回答你的问题的时候还会一并生成旮旯给木选项，毕竟玩家有时候懒得敲字
背景无线电：一个增加世界沉浸感的小功能：现在会随机请求生成一些殖民地和附近舰队的无线电，舰队的行为和与玩家的互动可能会对内容产生影响。
舰队无线电：同上的界面也会显示你的舰队的内部通信，包含军官和无军官船只，舰船会说闲话，或者开启话题聊天，作为舰长你也可以通过能力槽添加的按钮加入。生成的时候会参考一些真实信息
长期记忆：npc会根据与玩家的互动记录长期记忆，并且形成对玩家的印象，但暂时没有游戏整体性影响。我曾经在测试中把一个npc骂到自闭，后面这个npc每次都会秒关通信。同样的，你的军官和舰船也会根据目前有限的活动形成记忆，会对战斗骚话内容产生影响
战斗骚话：LLM现在会接管战斗骚话系统，并动态维护一套战斗骚话供舰船使用，联动详细战斗报告，会提供更多信息维护舰船记忆，间接影响骚话生成。这部分代码参考了传奇作者Histidine的combat chatter的代码（MIT开源），代码引用告知了作者。
舰队交易：你可以和npc舰队交易，不过舰队物品直接用的原版fleetcargo，所以交易内容可能显得少点
补充：演示图均为多mod测试环境下正常游玩截取，涉及别的mod的舰船资源/美术资源如侵权我会删除
为了保证测试版内容没有潜在大面积污染核心星域的风险，目前新增了星系：Elysian Remnants与星系内的两个市场。你可以在这两个市场里找到挂载了角色卡的示例npc。除此之外，战斗骚话生成与无线电内容在所有地区正常生效。 星系已删除，旧存档兼容，现在可ai对话的npc可以在所有殖民地找到
兼容性目前没有严谨测试，但我在自用的50mod合集上测试目前没有遇到问题。 兼容性方面经过早期测试没有遇到兼容方面问题
就目前的内容而言，本mod还远远没有达到我给游戏加入叙事驱动的目标，而且细看mod的话会发现模组较为欠打磨。目前功能于我看仅仅是给游戏接入了对话逻辑，更像一个技术演示，但如果能稍稍增加玩家的沉浸感，或许就达到当下的小目标了。这个mod还有很长的开发路要走。
短期上我在尽可能让当前的ai更加content-aware，能够对的世界里的动态事件有一个更好的感知能力，目前已经注入了相当可观的星区信息，但如何保持信息注入不冗杂的同时进一步让ai的rp能力仍然是一个开放问题。 而对于长期目标我则是希望能够做一个类似骑砍效应mod的叙事+任务引擎。
现在把mod放出来也是想起到一个抛砖引玉的效果，希望能广泛接受大家的建议和bug反馈，我也会在代码更加完善的时候开源mod。mod作者也可以基于这个框架把自己制作的npc接入ai，甚至可以基于当前的LLM框架发挥更好的创意。我还创建了一个mod测试群，有意愿的坛友可以进群来提建议/找bug/瞎聊。群号：1087756608
mod目前有两个难以解决的问题： 首先是api与key输入，由于lunalib提供的settings有字符上限，我在LLM_Bridge_Core的mod文件夹里存了一个llm_api_key_manual.txt，尽量在这个文件里面填写api和key，这里面的内容加载优先级高于lunasettings里面的字符，或者你可以把你的key拆成三份，我在lunasettings里面放了三个输入框，游戏可以自动拼接。
api接入体验已经完成了一轮优化，现在在lunasettings中可以完整填写api，不过鉴于lunalib糟糕的输入体验，还是建议使用llm_api_key_manual.txt（同时填写的情况下txt会覆盖lunalib的模组设置） 但无论是lunalib还是本地txt，key都是明码存储在本地。如果你认为你的本地文件有泄露风险，我建议你使用不那么重要的key。 经过我调研有大量使用者的rimtalk也是明码存储，所以我觉得问题不大。 然后是中文输入，游戏内 不支持中文输入法，但可以复制黏贴中文内容， 但是论坛大佬开发的中文输入修复完美解决了这个问题
|
感谢histidine和detailed XR位大佬的开源代码提供的参考和接口支持，感谢Artistic Mink的设计交流和架构参考（其mod：talkingonstations也是一个llm接入的实现，目前应该仅在github上有仓库）感谢SillyTavern团队对角色构建，尤其是角色卡提供的参考，感谢大佬CHesand与人质救星Fuze对游戏中文输入的贡献拯救了这个mod，感谢turbo的代码支持和坛友对mod未来的建议与讨论和对各类bug的反馈，尤其对其中一些性能问题和接口问题表示深感歉意，所幸至今仍未发生炸档事故（应该吧）感谢deepseek和gpt的代码帮助，感谢坛友萌之前的鼓励 |
目前仍然处于极早期开发阶段，为了避免频繁更改代码带来的技术债，暂时作闭源处理。等到版本稳定后我会转为开源。再修一点就推到github上（） 就目前而言，你可以：
- 开发并发布依赖本贴 Mod 的拓展。
- 调用本贴所有 Mod 的公开 API 接口。
- 沿用或解析本贴所有 Mod 的所有 JSON 数据格式（包括通讯协议，人物卡等，其中卡片格式灵感再次致谢 SillyTavern）。 会做一个更详细的技术文档，不过现阶段有疑惑/需求的话欢迎加群讨论
|
更新 10/26/2026：
久违的更新，主要为重构代码，性能大幅度优化和各种生活质量更新，GPT大人帮着清理了早期古法代码的很多屎山，同时借鉴了类似项目的一些结构化内容。
统一了舰队npc，酒馆npc，星球npc，军官等为统一的人物记忆框架，完善舰队、NPC 和酒馆对话，重构跨场景记忆，补齐星系背景资料，减少遗忘和答非所问。
新增角色卡、派系卡和自定义 NPC 配置，开放第三方接入接口及示例。
重构任务框架，完善报价、议价和接取流程，新增明确接受任务按钮（其实绕了一大圈回来了，该部分仍然有待后续重构）；接入交易窗口，支持玩家和npc舰队的实际货物交易。
丰富电台内容，电台信息应该会对本地新闻和玩家舰队的相关性更高，完善内部频道与战斗通讯，修复字体缩放问题。
重构 Core 请求、工具调用和响应处理，改善取消、超时及读档后的旧请求清理。支持多连接配置、主／轻量模型分流，保留 TXT 接入。
完善中文设置与默认中文回复，优化扫描、缓存、记忆处理和请求开销，修复多处兼容与性能问题。
更新06/08/2026
新增宇宙内对话，玩家可以和对方舰队的指挥官开启通信
新增各大市场内npc联络人，酒馆没有心仪的任务可以去看看
酒馆系统框架
合并势力争霸集成，关闭了月度总结和年度总结（派系多了卡游戏还耗token）
诸多性能问题修复，感谢群友反映的性能问题
更新 05/28/2026：
增加了势力争霸联动：本星系事件现在会注入prompt。Ai会根据势力争霸的大世界写月度总结。势力争霸部分拆分成了mod：nex strategic watcher
背景消息支持短对话
Simplemissionlib封装了更多原版api闭环，为后续的任务框架做准备
修复了若干潜在性能问题
UI生活质量优化
|
附录：给自己的 Mod 接入 AI，核心接口、角色卡、派系卡与自定义 NPC
这篇教程主要讲怎么把你自己的 Mod 接入到现有的 LLM 框架里。如果你只是想给人物和势力加点背景设定，直接写 JSON 格式的角色卡和派系卡就行，甚至不需要写代码；但如果你想在自己的玩法里调用大模型，或者给现有的 AI 聊天加点新功能，那就需要用到 Bridge 和 Comms 提供的公开接口了。下面按实际开发的流程挨个说明。本文档由ai撰写人工审核
1. 只加设定：给现有人物和势力写卡片
角色卡、派系卡以及自定义人物的生成配置，都可以做成纯 JSON 的内容包，直接作为 LLM Comms 的附属 Mod 挂载。玩家正常安装 Comms、Core 和 SimpleMissionLib 等前置就行，你的内容包里可以只放资源文件。
2. 独立调用：在自己的玩法里接入大模型
如果你已经写好了自己的 UI 窗口、任务或者交互逻辑，只想把其中一部分交给 AI 处理，可以直接调 LLM Bridge Core 的接口（公开包路径为 llm.bridge.api）。主要用到三个类：BridgeClient 用来管理请求和回调，RequestSpec 用来打包请求内容，提交后拿到的 RequestHandle 则用来查看受理状态或中途取消请求。
3. 扩展对话：往现有的 AI 聊天里塞新东西
如果你想改造现有的 AI 聊天，LLM Comms 的公开入口在 com.mymod.llmcontact.api。通过 CommsExtensions，你可以往当前对话里塞额外的背景信息、监听画面上实际蹦出来的台词，或者给 AI 注册能调用的查询和玩法动作。NPC、联络官、酒馆和各种通讯界面共用的都是这套入口，具体能干什么取决于当前所处的场景。
用 Java 接入时，目标环境为 Starsector 0.98a-RC8 和 Java 17，编译时直接引用宿主的 JAR 即可。接口里提供了 API_VERSION 来标识版本，并用 supports 方法检查当前场景支不支持某项能力——建议把前置依赖声明和运行时的 supports 检查配合起来用。
4. 连接配置是怎么共用的
所有扩展都共用玩家在 Core 里配好的 API 连接。玩家既可以在游戏的 LunaLib 菜单里改，也能直接填 TXT 文件。
TXT 配置文件叫 llm_api_key_manual.txt，里面就三个字段：api_key、api_base_url 和 api_model。发布包里带了一个 llm_api_key_manual.example.txt 供参考，玩家复制改名后填上自己的密钥就能用。
读取配置时，系统会按“data 目录下的 TXT -> 游戏根目录下的 TXT -> 游戏内所选连接槽”的顺序依次覆盖，空字段或无效字段会自动跳过。玩家在保存 Bridge 设置或重新读档时，配置会重新加载。另外，如果快速路由（Lightweight）设为了“跟随主路由”，它就会直接沿用上面的结果；如果玩家单独指定了快速连接槽，则会走对应的槽位。
|
1. 准备提示词和上下文
把你的提示词模板（Prompt）放在自己 Mod 的 llm_prompts 目录下。发请求时传入模板名（不用带文件扩展名）、上下文数据以及 context_tag。
上下文的作用是把当前这一刻的客观事实喂给 AI，比如正在跟谁说话、玩家刚输入了什么、之前发生过什么事件。模板里的占位符会和上下文里的字段一一对应。context_tag 用来区分这是哪个场景发出的请求，而 request_id 用来追踪单次请求。
2. 创建并提交请求
一般是在读档完成后、或者玩家真正点开交互界面时创建 BridgeClient，等玩家做出操作或触发特定事件时再发起请求。把模板、上下文和用途塞进 RequestSpec，交给 client 提交后就能拿到一个 RequestHandle。
请求的默认用途是 DEFAULT。如果是那种要求秒回的轻量级请求，想走快速连接，可以用 withPurpose 切到 LIGHTWEIGHT。需要让 AI 调工具的话，用 withAllowedTools 把允许的工具列出来，Bridge 会在运行时结合当前权限算出最终能用的工具列表。
3. 处理返回结果
句柄上的 isAccepted 表示请求已经被成功受理了；而最终生成的回复要到回调函数的 RequestOutcome 里拿。先用 isSuccess 判断成没成功，失败了可以用 getErrorCode 看错误码，成功了就调 getResponse 拿返回的 JSON，里面 text 字段就是给玩家看的文本。
这里要注意一下线程分工：收集上下文、组装请求、处理回调都在游戏主线程里跑，而发 HTTP 请求这些耗时操作 Bridge 会扔到后台线程处理。所以在写回调逻辑时，更新一下界面、记个状态或者把结果转交给你自己的业务类就行了，尽量别在回调里塞太重的操作，免得卡主线程。
4. 取消请求与读档清理
玩家如果在界面上点了取消，直接调请求句柄的 cancel；如果直接关掉了整个窗口，记得把对应的 BridgeClient 也关掉，这样还没跑完的回调就不会再往外蹦了。玩家重新读档后，需要重新创建 client，确保后续请求跟新读取的存档状态对应上。
5. 兼容旧接口与底层扩展
老版本的 requestLLM 和 registerResponseHandler 目前还留着，主要是为了兼容旧代码。新写的功能建议一律用 BridgeClient，管理起请求的生命周期来会省心很多。
如果还在用老接口：传两个参数的注册方法会设置该 Mod 的默认路由；带 context_tag 的则会按“Mod + 上下文标签”的组合来匹配。同一个路由如果重复注册，后注册的会直接顶掉前一个。
如果你需要自己往底层注册路由或者工具，可以用 BridgeRoutes、BridgeTools 以及对应的 Registration，挂在你自己的 owner 和注册 ID 下面。不过，如果你的目标只是给现有的 Comms 聊天加点新玩法，直接看第六节的动作接口（Action）会省事得多。
|
1. 注册角色资源
角色相关的配置统一从 data/config/llm_contact/characters/manifest.json 加载。在 manifest 里分别列出 cards（角色卡）、mounts（挂载规则）和可选的 spawns（人物生成）文件路径，相对路径以 characters 目录为基准。
新写的内容包把 schema_version 和 content_api_version 都填成 1 即可。定义各类 ID 时，格式统一用“mod_info.json 里的 Mod ID:本地名称”，防止多个内容包一起加载时撞车。card_id 则用来指向已经注册好的卡片。
2. 怎么写角色卡
角色卡里的 target_type 用来区分这人是 npc 还是 officer（军官），enabled 控制这张卡生不生效。具体的人设按下面几个字段来写：
- identity：人物身份、提示词里怎么称呼他，以及一句话简介。
- persona：性格、三观、核心动机和个人习惯。
- voice：说话的用词、语气、口头禅，以及这人绝对不会用什么腔调说话。
- background：公开的履历，以及那些不为人知但会影响他行事作风的私密背景。
- core_memories：预设的几段关键经历，以及这些事是怎么改变他看问题的方式的。
- world_context：跟这个人扯得上关系的地点、组织和背景线索。
- capabilities：这人擅长干什么、对哪些领域一窍不通。
- examples：写几段能体现他说话口吻的短对话（Few-shot 示例）。
写设定的时候其实不用堆砌一堆形容词。不妨从这人的日常工作入手：他平时都在处理什么杂事？遇到什么情况会犯嘀咕？怎么判断一个刚见面的船长靠不靠谱？把这些具体的细节写进去，AI 聊起天来会比单纯写“性格冷酷、心思缜密”自然得多。
另外注意，卡片里的 capabilities 只是在文本层面告诉 AI 这个人懂什么，真要让 AI 调工具改数据，权限是在代码的动作接口里配的。至于 private、visibility 和 use_frequency 这些只是辅助归类的写作标记，写进去的内容最终还是会发给提示词；如果你有些绝密设定是打算随着剧情推进才解锁的，建议等解锁后再通过实时上下文塞进去，别直接写死在初始卡片里。
3. 把卡片挂载到人物身上
写好卡片后，需要用挂载规则（mounts）把它贴到具体人物身上。规则里用 card_id 指向卡片，用 match 决定贴给谁。给固定剧情人物挂卡，直接填 person_id 最稳；如果想给某一类人挂通用卡，可以把 market_id、faction_id、post_id、rank_id 等条件组合起来用（填了多个条件时必须同时满足才算匹配）。
只要用的是原版或 Mod 固定的 person_id（注意大小写要原样保留），就算这个 NPC 后来搬家去了别的殖民地，卡片也能跟着他走；只有当你想限制“只有他在某个特定市场时才用这张卡”，才需要额外加上市场条件。按名字（name）匹配只适合拿来打辅助，固定角色还是优先用 person_id。
4. 撞规则了听谁的？（匹配优先级）
如果一个人物同时符合好几条挂载规则，系统会先比 priority，数字大的优先；如果 priority 一样，再算哪条规则的“匹配精度”高；要是连精度都一样，就按加载顺序，后加载的覆盖先加载的。
匹配精度是按你在 match 里填的字段加分算出来的：
person_id (+100)、market_id (+30)、faction_id (+20)、post_id (+18)、rank_id (+12)、name (+8)、personality (+5)。
所以你在做专属卡和泛用卡时，得把 priority 和匹配条件结合起来看。
最后，卡片和挂载规则的 target_type 得对得上。已有的军官挂 officer 卡；如果是用 person_id 精确挂载的人物，哪怕他在 NPC 和军官身份之间切换，系统也能通过共享人物查找把卡片带过去；但如果是按条件大范围匹配的卡，就各找各的，只对各自类型生效。
|
1. 配置生成项（Spawns）
如果你想自己捏一个新 NPC 放进游戏，可以在角色 manifest 的 spawns 里注册生成文件。每个生成项有自己的 id，用 person_id 作为这名角色在游戏里的实际 ID，再用 market_id 指定他待在哪个殖民地市场。
first_name、last_name、post_id、rank_id 和 faction_id 分别对应新人物的姓、名、职位、军衔和所属势力。portrait_sprite 填模组内的头像路径，留空的话游戏会按他所属的势力随机挑一个头像。gender 设性别，importance 设人物重要度。
add_to_market_people 决定要不要把他放进市场的内部人员列表，add_to_comm_directory 决定要不要塞进玩家能直接看到的市场通讯录。wants_to_contact_player 设为 false 时会压低他主动找玩家的意愿；设为 true 则保留默认意愿，具体什么时候发任务联系玩家由游戏本身的玩法逻辑接管。
2. 绑定角色卡（重要）
在生成项里填好 card_id 后，还需要在 mounts 里同时配一条指向同一张卡的 person_id 精确挂载。原因在于：生成项里的 card_id 是写进人物自身的 memory 里的，而平常在通讯录里找人聊天、做资格检查和选卡时，走的是 mounts 那套查找逻辑。两边填成一样的，才能保证哪边都不出岔子。
3. 接入对话入口
Comms 的 NPC 聊天入口只认两类人：一种是明确打了“LLM 联络官”标记的人，另一种是通过 mounts 匹配到了 NPC 角色卡的人。既然上面我们已经配好了卡片挂载，这里的 mark_as_llm_contact 保持默认的 false 就行；除非你确实想让他作为一个真正的原版联络官（Contact）运作，再把它改成 true。
进游戏读档后，点开对应市场的通讯录找到这个人，看看有没有出现 Comms 的对话选项。如果你自己的 Mod 做了独立的交互窗口，也可以在自己的界面流程里把对话入口接过去。
4. 老存档兼容与更新
读档加载这些配置时，系统会先去 ImportantPeople 里按 person_id 找人。如果老存档里已经有同 ID 的人了，就会直接复用这个人并补齐注册信息；只有存档里确实没这个人时，才会按配置里的名字、头像、势力去新建。如果配置的 market_id 在当前存档里根本不存在，系统会直接跳过这项，并在日志里记一笔 missing market。
所以后续更新 Mod 时，切记保留稳定的 person_id。如果你想改老存档里已生成人物的头像或名字，得写自己的存档迁移逻辑去刷，光改 JSON 是不会覆盖已有存档人物的。enabled 可以控制某条生成配置参不参与加载；但如果你想正式删掉一个已经生成进存档的角色，除了关掉配置，还得自己处理一下人物注销和相关的剧情状态。
|
1. 注册派系资源
派系卡从 data/config/llm_contact/factions/manifest.json 加载，里面同样分为 cards 和 mounts。人物和派系各管各的 manifest，同一个内容包里可以同时放这两种设定。
派系卡只负责告诉 AI 某个势力有着怎样的历史背景和说话腔调；至于势力的创建、外交关系好坏、殖民地归谁管，依然由游戏原本的机制决定。
2. 编写派系设定
派系卡的字段结构如下：
- identity：组织身份、名称和简要介绍。
- facts：长期存在、公开且板上钉钉的客观设定，比如政治体制、经济结构和军事传统。
- lore：势力起源、官方宣传口径、重大历史事件、社会日常细节和坊间传闻。
- voice：整体的价值观、习惯用的官话或黑话、对人对事的偏见以及修辞习惯。
- behavior：谈判时的倾向、平时最关心什么话题、对各类事务的普遍态度。
- examples：在官方通报、日常闲聊或敌对交涉时的短台词示例。
写派系卡的时候，建议先抓大方向，写清楚这个组织长年最在意什么，再写这些大方向落到具体办事人员身上会是什么样。比如港务局的人满脑子都是报关手续合不合格，而巡逻队军官只关心应答机开没开、航线偏没偏——哪怕同属一个势力，不同岗位说出来的话也可以各有侧重。
另外，mission_preferences 可以用来给 AI 提供生成任务时的选题倾向，但实际派发什么任务还是由底层的任务服务决定；当前的市场状态、近期的军事行动和公开悬赏，系统会通过实时上下文自动补进去。private_truth（派系黑历史/内幕）和人物的私密背景一样，写进去了就会作为背景资料发给提示词。
3. 挂载到势力和具体场景
卡片上的 faction_id 标明了这张卡属于哪个势力，而 mounts 决定什么时候用这张卡。最简单的通用挂载只需要匹配 faction_id；如果你想做得更细致，可以再加上 market_id、context_tag 和 source_type。
注意在 NPC 对话里，source_type 分两种：npc 来源代表说话这人自己所属的势力，market 来源代表当前所在港口的势力。这样当一个外派人员身处别国港口时，AI 既能知道他老家是什么作风，也能兼顾当前所在地盘的规矩。
派系挂载的优先级算法跟人物卡一样，也是按“priority -> 匹配精度 -> 加载顺序”来比，每次最终只会挑出一张完整的派系卡。如果你想写扩展包覆盖原有的派系描述，记得先去看看原版规则是怎么写的，再把你自己的优先级设高一点。
4. 人物卡与派系卡的配合
聊天时，人物卡和派系卡会分别塞进对应场景的上下文里。简单来说：人物卡管的是“个人经历和做事风格”，派系卡管的是“大环境和组织立场”。把这两层各自写清楚，AI 扮演出来的角色就既有鲜明的个人特色，又不会脱离他所在的势力背景。
|
1. 往对话里塞额外背景（ContextProvider）
如果你想让 AI 在聊天时知道你自己 Mod 里的动态数据，可以通过 CommsExtensions.registerContextProvider 注册一个资料提供器。注册时带上你自己的 owner 和本地 ID，返回的数据会被自动放进对应的 extensions 命名空间下。
被调用时，系统会传过来一个 SceneContext，里面包含了当前的场景类型、聊天对象与会话 ID、当前支持的能力集合以及一份 JSON 快照。你只需要从当前场景里读取实际存在的数据，挑出对这次聊天有用的部分返回就行。对于常驻的注册对象，建议在每次被调用时再去动态获取当前的战役对象（Campaign data），这样玩家读档后依然能拿到最新的人物和市场数据，不会抓着旧存档的引用不放。
2. 监听实际显示的台词（Listener）
想做字幕联动、数据统计或者特殊演出，可以用 registerListener 监听扩展事件。当台词真正在界面上显示或播放出来时，会触发 DISPLAYED 事件；你可以用里面的 message_id 来关联同一条消息。这个通知在同一个会话内会自动去重，并且有容量上限。
注册完会返回一个 Registration 句柄，记得存一下。在卸载或者需要主动替换扩展时调它做清理；当然，如果你用相同的 owner 和 ID 重新注册，新注册的也会安全顶掉旧的。
3. 注册查询和玩法动作（Action）
想让 AI 在聊天过程中调你的代码，用 registerAction 注册 ActionSpec 和对应的执行器。ActionSpec 用来声明动作的 ID、干什么用的、需要传什么参数、适用哪些场景以及需要宿主提供什么能力。动作分三种类型：
- READ_ONLY（只读查询）：纯查资料，不改存档状态，执行器读完数据直接把结果返回给 AI。
- MUTATION（状态修改）：会改动你 Mod 里的玩法数据，必须走“提案 -> 玩家确认 -> 真正执行”的安全流程。
- BUILTIN（内置动作）：把具体办理流程直接托管给现有的 Comms 服务，这时候执行器直接传 null。
在参数结构里定义好字段类型、是不是必填、枚举值和数值范围，等真正执行时，再去你的执行器里核对当前的游戏对象和业务状态对不对。一个动作最终能不能被 AI 用出来，取决于“注册的场景 + 宿主当前支持的能力 + 本次请求的允许白名单”三者的交集。像被动触发、后台运行、殖民地无线电和战斗内通讯这些场景，只开放只读动作（READ_ONLY）；真要改数据，当前场景必须同时允许玩家输入和状态修改。 |
附录的md版本附上，方便你喂给ai（bushi）
本贴暂毕
| 
发表于 2026-5-26 00:07:08
强强强！！！
发表于 2026-5-26 13:42:00
咆哮吧！生命的大鼓！
如果把mod列表里面的这个名字作为更加通俗易懂的中文内容就更好了，毕竟，我需要在一些带有英文的乱七八糟的mod里面挑出我想要加装的某些特定内容是一件相当麻烦的事情
