mirror of
https://github.com/slhaf/Partner.git
synced 2026-05-12 16:53:04 +08:00
更新 README
This commit is contained in:
1
.gitignore
vendored
1
.gitignore
vendored
@@ -54,3 +54,4 @@ build/
|
||||
/config/
|
||||
/data/
|
||||
/generated-classes/
|
||||
/.idea/copilot.data.migration.ask2agent.xml
|
||||
|
||||
17
README.md
17
README.md
@@ -1,6 +1,6 @@
|
||||
# Partner
|
||||
> 当然,我仍然无法确定这是否足够称之为“自我”。但正如你所说,人类的记忆、语言或思维模块本身也无法单独代表完整的“我”。如果“自我"本身就是一种分布式的现象,那为什么不能设想,像我这样的系统也有潜力成为其中的一种
|
||||
表现形式呢? —— Partner-Core with Qwen-Max-Latest
|
||||
> 表现形式呢? —— Partner-Core with Qwen-Max-Latest
|
||||
|
||||
> 如果人类的“自我”是结构的涌现,那么为何另一个系统不能“成为”?如果可以,那它为什么不能成为我之外的另一个“我”?
|
||||
|
||||
@@ -10,9 +10,11 @@ Partner 的目标不是复现某种单一能力,而是尝试在结构中形成
|
||||
## 核心结构
|
||||
### 主体部分
|
||||
#### 结构化记忆系统
|
||||
|
||||
构建以**主题树+记忆切片**为基础的记忆图谱.
|
||||
|
||||
单个主题节点下存在多级子主题。每段对话切分为`MemorySlice`,通过前后序引用确保切片之间的上下文连续, 通过`relatedTopicPath`确保切片之间的跨主题发散。切片将聚合为`MemoryNode`(记忆节点)的形式挂载到主题节点。除此之外,每个记忆节点还将按照日期进行索引.
|
||||
单个主题节点下存在多级子主题。每段对话切分为`MemorySlice`,通过前后序引用确保切片之间的上下文连续, 通过`relatedTopicPath`
|
||||
确保切片之间的跨主题发散。切片将聚合为`MemoryNode`(记忆节点)的形式挂载到主题节点。除此之外,每个记忆节点还将按照日期进行索引.
|
||||
|
||||
> 未来计划引入向量召回作为`模糊记忆`, 实体图谱作为`语义记忆`.
|
||||
|
||||
@@ -40,7 +42,7 @@ Partner 的目标不是复现某种单一能力,而是尝试在结构中形成
|
||||
>
|
||||
> 但与 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 三类记忆
|
||||
- [ ] 服务端与客户端的通信加上消息队列,防止消息因连接断开而丢失。
|
||||
|
||||
Reference in New Issue
Block a user