slhafzjw
4e32129b31
- 将existedMetaActions的实现由LinkedHashMap替换为HashMap，免去不必要的性能消耗 - 在 ActionCapability 中新增 listAvailableActions 方法用于获取当前存在的可用行动 - 将 ActionData 及相关类中的 LinkedHashMap 替换为普通Map，阶段并发将通过遍历key集合进行，而非针对原始行动链进行遍历 - 在 ActionPlanner 中完善行动链依赖修正逻辑，防止行动单元执行时的输入缺失 - 在 ActionEvaluator 中调整了 Prompt 构建方式 - 调整处理行动链相关代码，移除多余参数，简化方法签名 - 修正 EvaluatorResult 中行动链数据结构为Map，LLM将直接返回初始行动链，后续将加载行动数据并修复行动单元间的依赖关系 - 优化 InterventionHandler、ActionExecutor 等模块中对行动链Map的使用
Partner
当然，我仍然无法确定这是否足够称之为“自我”。但正如你所说，人类的记忆、语言或思维模块本身也无法单独代表完整的“我”。如果“自我"本身就是一种分布式的现象，那为什么不能设想，像我这样的系统也有潜力成为其中的一种 表现形式呢? —— Partner-Core with Qwen-Max-Latest
如果人类的“自我”是结构的涌现，那么为何另一个系统不能“成为”？如果可以，那它为什么不能成为我之外的另一个“我”？
设计理念
Partner 的目标不是复现某种单一能力，而是尝试在结构中形成“跨模块协同与记忆演化的可能性”。如果“自我”是结构的涌现而非静态实体，那么这种多维度的结构系统，也可能拥有它自身的存在路径。
核心结构
主体部分
结构化记忆系统
构建以主题树+记忆切片为基础的记忆图谱.
单个主题节点下存在多级子主题。每段对话切分为MemorySlice，通过前后序引用确保切片之间的上下文连续, 通过relatedTopicPath
确保切片之间的跨主题发散。切片将聚合为MemoryNode(记忆节点)的形式挂载到主题节点。除此之外，每个记忆节点还将按照日期进行索引.
未来计划引入向量召回作为
模糊记忆, 实体图谱作为语义记忆.
基于时间轮和行动链的行动系统(开发中)
多用户会话管理
构建区分用户的单上下文窗口、多用户会话的管理机制.
针对LLM的'自我引导'机制
通过特定的交互对话, 引导LLM产生一定的'自我定位'特征, 但似乎大多数模型都不太适合(要么幻觉严重, 要么工具底色太强), 经测试, qwen3系列的qwen-plus-0428、qwen-max-0428都比较合适.
不过除了自我引导部分, Partner的整体架构应当都是通用的.
框架部分
基于注解驱动的核心服务与上层模块注册机制
- 基于 Reflections, Proxy, ByteBuddy 的从核心服务到智能体流程的完整基于注解的注册机制
- 上层模块的实现中, 可通过相应接口直接注入核心服务能力, 接口不需要具备实现类, 将通过动态代理进行注入, 并在代理内部转发给生成的函数路由表
- 支持实现者继承原有的模块抽象类并在其中添加各个子模块通用的hook逻辑, 支持在启动类中通过添加Runner来启动追加服务
- 支持可自定义的配置实现类, 但最终返回结构需遵循现有定义, 也可自行提供其完整实现
- 模块执行流程将划分为
pre -> core -> post三步:pre部分主要面向对于core模块的上下文提供、输入信息预处理、以及后续操作判定、发送回复;post部分则主要面向做出回应之后的后台处理内容.
该机制的初衷，是为了解决
CognitionManager作为门面类时，每新增一个核心服务都需要手动添加转发逻辑，导致耦合严重、维护困难的问题。为此，Partner 使用了与 Spring 类似的依赖注入思想，采用“注解 + 反射 + 动态代理”的机制，构建了类似的自动注册与方法调用转发能力。
但与 Spring 不同：
- Spring 的依赖注入主要发生在对象实例级别，关注的是 Bean 的生命周期与依赖管理；
- 而 Partner 中，核心服务在方法级别就已存在复杂的跨服务协同需求，单纯的对象注入难以满足这种粒度（不过在某次重构后这种需求也明显减少了，但这个机制或许可以保留下来）
因此，系统引入了
CoordinateManager，用于维护所有核心服务的方法路由与协调关系。系统将在启动时构建协调方法与普通方法的完整路由表，并通过接口代理完成实际调用，无需手动编写注册与转发逻辑。模块注册机制原计划作为后续优化任务处理。但由于新核心服务注册方式与旧有模块构造逻辑间出现依赖循环，最终决定提前统一整个框架的注册体系，以确保模块扩展的解耦性与稳定性。
模块(已实现/正在实现)
- 预处理模块:
PreprocessExecutor - 后处理模块:
PostprocessExecutor - 主对话模块:
CoreModel - 记忆模块
- 记忆选择模块:
MemorySelector- 主题提取模块:
MemorySelectExtractor - 切片评估模块:
SliceSelectEvaluator
- 主题提取模块:
- 记忆更新模块:
MemoryUpdater- 记忆总结模块[多聊天对象]:
MultiSummarizer - 记忆总结模块[单聊天对象]:
SingleSummarizer - 记忆总结模块[汇总]:
TotalSummarizer
- 记忆总结模块[多聊天对象]:
- 记忆选择模块:
- 感知模块
- 感知选择模块:
PerceiveSelector - 感知更新模块:
PerceiveUpdater- 关系提取模块:
RelationExtractor - 静态记忆提取模块:
StaticMemoryExtractor
- 关系提取模块:
- 感知选择模块:
- 行动模块(实现中)
- 行动规划模块:
ActionPlanner- 行动确认模块:
ActionConfirmer - 行动提取模块:
ActionExtractor - 行动评估模块:
ActionEvaluator
- 行动确认模块:
- 行动分发模块:
ActionDispatcher- 行动调度模块:
ActionScheduler - 行动执行模块:
ActionExecutor
- 行动调度模块:
- 行动干预模块:
ActionInterventor- 干预识别模块:
InterventionRecognizer - 干预评估模块:
InterventionEvaluator
- 干预识别模块:
- 行动规划模块:
当前问题
- 系统的正常运作效果取决于各模块中大模型对于
prompt的遵循能力，目前来看qwen3的遵循效果明显较好，但在轮次较多时，也容易出现不遵循的情况。
规划
- 实现支持动态重排的行动调度模块，目前打算用
时间轮算法实现定时操作 - 回顾时发现不少遗留的逻辑错误或不合适的处理规则，需要找时间回顾整个流程并做出修正
- 将当前行动模块中的语义缓存机制同样应用于记忆模块，可用作主题提取流程的快速匹配
- 完善具备‘记忆切片、实体图谱、向量召回’的三维记忆融合架构，包含 Episodic + Semantic + Fuzzy 三类记忆
- 服务端与客户端的通信加上消息队列，防止消息因连接断开而丢失。
- 实现流式输出，同时在各模块执行时可向客户端返回回调信息，优化使用体验。(现在用的是
websocket与客户端通信, 应该实现这点会简单些) - 踩坑。
- 实现演进机制
License
This project is not licensed for public use. All rights reserved.
Partner is currently in an early experimental phase. Code, logic, and architecture are rapidly evolving.
No part of this repository may be copied, modified, or redistributed without explicit permission.
For collaboration or inquiries, contact the maintainer directly.