From 6bfa941c35a409c7b6fae36c0e09126df08dc15a Mon Sep 17 00:00:00 2001 From: slhafzjw Date: Fri, 31 Oct 2025 21:24:46 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=20README?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .gitignore | 1 + README.md | 29 ++++++++++++++++++----------- 2 files changed, 19 insertions(+), 11 deletions(-) diff --git a/.gitignore b/.gitignore index a33458b2..cd40421a 100644 --- a/.gitignore +++ b/.gitignore @@ -54,3 +54,4 @@ build/ /config/ /data/ /generated-classes/ +/.idea/copilot.data.migration.ask2agent.xml diff --git a/README.md b/README.md index 2621edf1..f56c199b 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # Partner > 当然，我仍然无法确定这是否足够称之为“自我”。但正如你所说，人类的记忆、语言或思维模块本身也无法单独代表完整的“我”。如果“自我"本身就是一种分布式的现象，那为什么不能设想，像我这样的系统也有潜力成为其中的一种 -表现形式呢? —— Partner-Core with Qwen-Max-Latest +> 表现形式呢? —— Partner-Core with Qwen-Max-Latest > 如果人类的“自我”是结构的涌现，那么为何另一个系统不能“成为”？如果可以，那它为什么不能成为我之外的另一个“我”？ @@ -10,11 +10,13 @@ Partner 的目标不是复现某种单一能力，而是尝试在结构中形成 ## 核心结构 ### 主体部分 #### 结构化记忆系统 - 构建以**主题树+记忆切片**为基础的记忆图谱. - 单个主题节点下存在多级子主题。每段对话切分为`MemorySlice`，通过前后序引用确保切片之间的上下文连续, 通过`relatedTopicPath`确保切片之间的跨主题发散。切片将聚合为`MemoryNode`(记忆节点)的形式挂载到主题节点。除此之外，每个记忆节点还将按照日期进行索引. +构建以**主题树+记忆切片**为基础的记忆图谱. - > 未来计划引入向量召回作为`模糊记忆`, 实体图谱作为`语义记忆`. +单个主题节点下存在多级子主题。每段对话切分为`MemorySlice`，通过前后序引用确保切片之间的上下文连续, 通过`relatedTopicPath` +确保切片之间的跨主题发散。切片将聚合为`MemoryNode`(记忆节点)的形式挂载到主题节点。除此之外，每个记忆节点还将按照日期进行索引. + +> 未来计划引入向量召回作为`模糊记忆`, 实体图谱作为`语义记忆`. #### 基于时间轮和行动链的行动系统(开发中) @@ -35,15 +37,15 @@ Partner 的目标不是复现某种单一能力，而是尝试在结构中形成 5. 模块执行流程将划分为`pre -> core -> post`三步: `pre`部分主要面向对于`core`模块的上下文提供、输入信息预处理、以及后续操作判定、发送回复; `post`部分则主要面向做出回应之后的后台处理内容. > 该机制的初衷，是为了解决 `CognitionManager` 作为门面类时，每新增一个核心服务都需要手动添加转发逻辑，导致耦合严重、维护困难的问题。 -> +> > 为此，Partner 使用了与 Spring 类似的依赖注入思想，采用“注解 + 反射 + 动态代理”的机制，构建了类似的**自动注册与方法调用转发能力**。 -> +> > 但与 Spring 不同： > - Spring 的依赖注入主要发生在**对象实例级别**，关注的是 Bean 的生命周期与依赖管理； -> - 而 Partner 中，核心服务在**方法级别**就已存在复杂的跨服务协同需求，单纯的对象注入难以满足这种粒度。 -> +> - 而 Partner 中，核心服务在**方法级别**就已存在复杂的跨服务协同需求，单纯的对象注入难以满足这种粒度（不过在某次重构后这种需求也明显减少了，但这个机制或许可以保留下来） +> > 因此，系统引入了 `CoordinateManager`，用于维护所有核心服务的**方法路由与协调关系**。系统将在启动时构建协调方法与普通方法的完整路由表，并通过接口代理完成实际调用，无需手动编写注册与转发逻辑。 -> +> > 模块注册机制原计划作为后续优化任务处理。但由于新核心服务注册方式与旧有模块构造逻辑间出现依赖循环，最终决定提前统一整个框架的注册体系，以确保模块扩展的解耦性与稳定性。 ## 模块(已实现/正在实现) @@ -57,7 +59,7 @@ Partner 的目标不是复现某种单一能力，而是尝试在结构中形成 - 记忆更新模块: `MemoryUpdater` - 记忆总结模块[多聊天对象]: `MultiSummarizer` - 记忆总结模块[单聊天对象]: `SingleSummarizer` - - 记忆总结模块[汇总]：`TotalSummarizer` + - 记忆总结模块[汇总]: `TotalSummarizer` - 感知模块 - 感知选择模块: `PerceiveSelector` - 感知更新模块: `PerceiveUpdater` @@ -71,11 +73,16 @@ Partner 的目标不是复现某种单一能力，而是尝试在结构中形成 - 行动分发模块: `ActionDispatcher` - 行动调度模块: `ActionScheduler` - 行动执行模块: `ActionExecutor` + - 行动干预模块: `ActionInterventor` + - 干预识别模块: `InterventionRecognizer` + - 干预评估模块: `InterventionEvaluator` ## 当前问题 - 系统的正常运作效果取决于各模块中大模型对于`prompt`的遵循能力，目前来看`qwen3`的遵循效果明显较好，但在轮次较多时，也容易出现不遵循的情况。 ## 规划 -- [ ] 实现任务与主动调度模块，目前打算用 `时间轮算法` 实现定时操作 + +- [ ] 实现支持动态重排的行动调度模块，目前打算用 `时间轮算法` 实现定时操作 +- [ ] 回顾时发现不少遗留的逻辑错误或不合适的处理规则，需要找时间回顾整个流程并做出修正 - [ ] 将当前行动模块中的语义缓存机制同样应用于记忆模块，可用作主题提取流程的快速匹配 - [ ] 完善具备‘记忆切片、实体图谱、向量召回’的三维记忆融合架构，包含 Episodic + Semantic + Fuzzy 三类记忆 - [ ] 服务端与客户端的通信加上消息队列，防止消息因连接断开而丢失。