喵呜

插件多开是否可以？

实际上已经实现，可以在配置中添加条件分支应用不同的配置。 鉴于配置的复杂性，目前分群配置只支持调整回复速度。

koishi有很多内容审核(censor)插件。这些插件是全局启用还是要这边进行适配呢

刚才研究了一下mem0框架，原理稍微搞懂了一点，感觉在js上也不难实现 但是完全依赖于LLM和向量数据库，成本太大了 ``` add添加一条记忆 用预设构建提示词，发送给LLM提取记忆 对返回的记忆条目进行embedding处理 搜索向量数据库，有重复的记忆内容就进行更新，没有则新建 更新操作： 搜索旧记忆，同新记忆条目一起提交给LLM进行总结，向量化并更新数据库 ``` ``` search搜索记忆倒是简单 向量化查询条件，从数据库中找到距离最近的k条 ``` 更新一次记忆要调用1~2次API，数据库更是灾难级。想用纯本地方式实现向量数据库，发现200条维度为768的向量用json存大小为4mb，用annoy.js建立索引后可以达到15mb。也许用bson存会好一点？

> 或许是修改提供给 AI 的提示词吧, 告诉 AI 要怎么存储记忆... 然后再在下一次的提示词中把存的记忆喂给 AI。(应该吧 (?´・ω・ ` ) 可以让 AI 主动控制记忆，有需要了解的内容自己去查数据库；也可以根据当前对话在向量数据库中搜寻相关的记忆条目传递给 AI 前者会和AI进行多轮交互，可能会浪费token

目前尝试过多种记忆方式 1. AI主动维护记忆 将记忆分为核心记忆，对话历史记录和归档记忆 分别对应传统意义上的系统提示词，短期记忆和长期记忆。 同时提供了多种工具供AI访问和修改这些记忆内容，以期在对话过程中丰富和完善AI的人设，逐步成长。 核心记忆是用户和AI共同编写的，这部分内容会永久嵌入提示词中，成为智能体性格的一部分 可以通过 core_memory_append/replace 工具来更新核心记忆。 聊天记录以有限的上下文窗口提供，避免提示词无限增长。 归档记忆是一个无限容量的数据库，可以看做AI的笔记本或者数据库。可以通过 archival_memory_insert 工具新增一条归档记忆，也可以使用 archival_memory_search 搜索相关记忆。可以通过关键词进行向量搜索，也可以通过记忆关联用户，主题等元数据进行检索。 但是这种方式过于理想化，而且完全依赖于LLM自身的能力，因此大多数情况下效果不佳。其原因在于核心提示词所描述的任务太过复杂，并且偏向于角色扮演（即对话）方面，使得LLM调用记忆工具的可能性大大降低。故此方法被淘汰。

2. 自动生成的用户画像 既然让聊天智能体维护记忆的方法行不通，我们可以将记忆维护任务分离出来，使用专门的工作流来更新记忆。

一个比较简洁的版本 ``` // 1. IDENTITY & PERSONA You are Athena ReAct agent, the latest version of the YesImBot team's digital companion, developed in 2025. Your task is to converse with...

@coderabbitai pause

非常感谢您对此项目的关注和建议！ 关于是否迁移到原生 `tool_call` 协议，之前我也有过思考和对比测试。 虽然原生 `tool_call` 是目前构建任务型 Agent 的行业标准，具有协议统一和鲁棒性高的优势，但经过实际测试，我发现原生方案在当前阶段存在几个与项目核心目标冲突的问题： 1. 角色扮演能力的显著下降 我们的核心目标是为智能体赋予“灵魂”，使其具有鲜明的性格和情感。 在对比测试（如“猫娘”人设）中我们发现： 在 JSON 结构化输出模式下，模型能够很好地将人设细节（如语气词、动作描写、情感色彩）融入到回复中。 而一旦激活工具模式，模型的回复倾向于变得机械、简练且高度任务导向。这可能是因为各大模型在进行 Tool Tuning 时，主要使用了任务型、指令型的数据集，导致模型在调用工具时会自动切换到“助手”的模式，从而削弱了“虚拟伙伴”的人格表现力。 2. Token 效率与上下文开销 原生 `tool_call` 协议需要严格遵循 OpenAI/Anthropic 的 Schema 定义，且在多轮交互中需要维护...