|
|
ae5caf8475
|
更新 memory.md
|
2025-11-10 18:59:05 +08:00 |
|
|
|
980d9384d1
|
MemoryUpdater 流程图制作完毕
|
2025-11-08 17:33:05 +08:00 |
|
|
|
9ba0d1363a
|
创建了 action、memory、perceive 三类模块的流程文档; 完成了记忆模块中 MemorySelector 的流程图
|
2025-11-07 15:14:29 +08:00 |
|
|
|
f6d5cad5cd
|
更新 README
|
2025-11-07 13:51:30 +08:00 |
|
|
|
5419722c40
|
更新文档内容
|
2025-11-06 11:17:25 +08:00 |
|
|
|
31ebee3ded
|
制作了整体流程图
|
2025-11-06 11:14:37 +08:00 |
|
|
|
6bfa941c35
|
更新 README
|
2025-10-31 21:24:46 +08:00 |
|
|
|
456a7e04e8
|
更新 README
|
2025-10-24 17:29:55 +08:00 |
|
|
|
5864760f35
|
Action 模块语义缓存机制实现完毕，支持三种情况的语义缓存相关行为: 命中缓存且评估通过、命中缓存但评估未通过、未命中缓存但评估通过。将在评估过后步入主模块之前，进行异步更新操作(借助@AfterExecute注解，通过虚拟线程进入异步流程，在真正调用处使用平台线程加速计算)
|
2025-10-19 22:05:27 +08:00 |
|
|
|
aee6d879e9
|
推进 Action 模块语义缓存机制
- 完善缓存命中部分;
- 调整 ActionExtractor 以适配缓存逻辑
- 缓存更新大致框架待填充具体更新逻辑;
|
2025-10-18 21:56:50 +08:00 |
|
|
|
d1ea8dde79
|
推进 ActionExtractor 语义缓存机制: 移除了 VectorUtil，实现了 ollama、onnx runtime 两种向量客户端，通过 Agent 启动类暴露的后置启动任务加载并进行测试。
|
2025-10-17 11:20:11 +08:00 |
|
|
|
7094a8a68b
|
推进 ActionExtractor 语义缓存机制: 两种嵌入模型的连接方式测试完毕，在高性能主机上，可以通过ollama调用mxbai-embed-large这类模型，但放到4核8G香橙派3B就会出现推理时长过长，哪怕换成ONNX RUNTIME JAVA 也难以避免，但如果更换成 nomic-embed-text + ONNX RUNTIME JAVA ，仍能够拿到70左右ms的推理时长，远低于提取模型以及向量模型API的调用时长。预期可提供两种语义缓存所用的嵌入模型接入方式: 通过 http 调用 本地ollama接口; 指定 ONNX 格式的嵌入模型直接调用。
|
2025-10-16 23:04:41 +08:00 |
|
|
|
e78048f66d
|
推进 ActionExtractor: 新增语义向量计算工具;开始推进语义缓存相关;调整配置类格式
|
2025-10-16 15:39:38 +08:00 |
|
|
|
2f09c0cd71
|
推进 ActionExtractor: 完善大致逻辑，开始语义-行为缓存相关部分
|
2025-10-16 15:39:31 +08:00 |
|
|
|
8c43d6594f
|
推进 ActionPlanner: 新增行动确认机制，将与原‘提取-评估’流程并发执行; 将繁杂的装配逻辑封装在内部类ActionAssemblyHelper中
# Conflicts:
# Partner-Main/src/main/java/work/slhaf/partner/core/cache/CacheCapability.java
# Partner-Main/src/main/java/work/slhaf/partner/core/memory/MemoryCore.java
# Partner-Main/src/main/java/work/slhaf/partner/module/modules/memory/selector/MemorySelector.java
|
2025-10-16 15:39:16 +08:00 |
|
|
|
2d052442b1
|
推进 ActionPlanner: 添加行动短路机制，如果未提取到行动，则跳过评估子模块
|
2025-10-16 15:34:30 +08:00 |
|
|
|
84f7befb75
|
推进 ActionPlanner: 完成了 ActionPlanner 模块中的执行逻辑，同步调整了数据类中的字段。下一步将进行 ActionPlanner 子模块的开发。
|
2025-10-16 15:34:30 +08:00 |
|
|
|
85818556f8
|
将记忆模块的缓存逻辑迁移至 MemoryCore; 移除了 CacheCore，并将 CoordinatedManager 中原记忆模块与缓存模块中的逻辑迁移至现记忆模块中，确保语义正确
|
2025-10-16 15:22:19 +08:00 |
|
|
|
cb1a25e9d5
|
移除 ActiveData ，其逻辑回归至 CacheCore，下一步将对 CacheCore 及 CoordinateManager 中的 cognation 相关内容进行拆分
|
2025-10-16 11:40:55 +08:00 |
|
|
|
a10a149edb
|
开始推进行动模块(ActionModule); 针对框架与本体分别进行了一系列架构优化。
框架:
- 调整模块注册以及AgentRunningFlow的相关逻辑，以支持同组模块并发执行，将以@AgentModule注解中的order属性区分组间顺序先后及是否同组
- 针对@CoordinateManager注解新增了Core的自动注入处理，以便更好的协调不同Core的逻辑
本体: - 开始推进行动模块。将采取类似记忆模块的分层思路，分为ActionPlanner与ActionDispatcher两个主要模块，再各自细分子模块划分
- 将CognationCore从核心统筹的身份下降至与其他核心平级，同时将其中的序列化逻辑抽取至统一的PartnerCore父类，所有核心都将继承该类以获得序列化能力，不同core的内容将序列化至各自的memory文件
- 将SessionManager移除，相关逻辑迁移至CognationCore，统一序列化逻辑的同时又保证语义正确
- 将CognationCore中的某些缓存性质逻辑移动至CacheCore，确保语义正确
- 调整了目录结构以适应优化过的架构
|
2025-10-12 16:23:11 +08:00 |
|
|
|
41bf19f43e
|
将 .java 重命名为 .kt
|
2025-10-12 16:23:11 +08:00 |
|
|
|
941943f696
|
Partner 主体与框架适配完成! 完整逻辑已达到适配框架之前的完成度。发现并修复了不少问题，以及更新了README
框架:
- 由于`Gateway`的启动属于`Agent`启动流程的子线程，而主线程可能由于逻辑执行结束时机早于`Gateway`创建完成时机而报错，故引入`CountDownLatch`进行阻塞
- 在`AgentRunningModule`与`AgentRunningSubModule`中添加日志hook，记录模块执行的起始与截止时机
- 修复了`AgentUtil`中收集继承链时遗忘起始类的错误
- 在`CapabilityCheckFactory`中针对`CoordinateManager`无参构造方法的实现检验
- 在`CapabilityRegisterFactory`中添加了收集模块之外的CapabilityHolder的逻辑，与`@InjectCapability`的校验与注入逻辑保持一致
- 修复了‘生成模块启用配置时，多余局部变量导致无法执行流正确读取启用情况’的错误
- 在GlobalExceptionHandler中添加了对于未知异常的处理逻辑，确保不会导致程序异常终止
- 发现`ModuleProxyFactory`中使用`record`类型会导致`ByteBuddy`无法正确创建代理类，已修复，替换成普通类
本体:
- `ActiveData`由于`CognationCore`的引用，也需要实现序列化，已修复
- 修复了`MemorySelectExtractor`中由于匹配到的主题列表为空导致的空指针异常
- 将后置模块的trigger判定抽取到新的父类中，统一判断
- 修复了`WebSocketServer`如果存在过ws连接，关闭后短时间再次启动内仍提示端口占用的情况，设置允许端口重用
- 在`WebSocketGateway`新增了断开ws客户端连接的逻辑
|
2025-09-30 15:46:05 +08:00 |
|
|
|
a7d54349e4
|
进行 框架-主题 的适配测试，发现了一些问题并进行了修复
框架:
- 去除了 ActivateModel 中 modelKey() 方法的默认实现，对于特殊的 AgentModule 继承者(CoreModule)而言，直接获取注解信息不可行，如果保持，则需要另加判断逻辑。这是没有必要的
- 发现 Agent 启动流程中，由于 Gateway 的启动可能依赖配置文件的加载，故将 AgentConfigManager 与 AgentGateway 的指定替换为类型指定，在合适的时机通过反射进行实例化
- 在 AgentUtil 中新增了链式判断指定类的注解链上是否存在指定注解的方法，目前用于 CapabilityHolder 的持有实例判定
- 发现 CapabilityFactoryContext 中 cores、capabilities 未赋值导致空指针异常，已修复
- 将 AgentConfigManager 中的检验逻辑进行抽离，放到了 ConfigLoaderFactory 中，避免职责混淆
- 发现 CoreModule 的注解使用错误，`@Retention(RetentionPolicy.RUNTIME)`元注解可以使得注解在代码运行时能够被反射扫描
- 在 ModuleCheckFactory 中添加了对于 Module 与 SubModule 的注解、继承使用是否匹配的检验
- 发现对于一个类来说，无法直接通过一层反射获取到‘注解的注解’，故在 ModuleRegisterFactory 中针对 CoreModule 的注册做了特殊处理
主体:
- 发现一些类缺少必要注解，已修复
- 发现存在有些必要的类未公开化无参构造函数，已修复，并在框架部分增加校验逻辑
其他:
- 由于项目的启动流程与完整的配置文件密不可分，所以开始尝试编写启动说明，目前只写了开头
|
2025-09-21 23:29:45 +08:00 |
|
|
|
3c2ac32708
|
完成了本体与框架的适配工作，并修复了某些问题。需要进一步进行测试
- 修复了 CognationCapability 相关的注解使用错误
- 将前置模块中的 setAppendedPrompt 与 setActiveModule 方法抽取到 execute 模板方法中
- 完善了已有模块的适配工作, 并去除了不必要的单例配置
|
2025-09-18 16:03:59 +08:00 |
|
|
|
7f9d007f07
|
适配框架时发现工厂注册链上存在一些执行顺序上的错误，于是尝试修复问题，为Agent启动链添加了完整的注释，并做出了必要的修复与调整
|
2025-09-13 23:37:35 +08:00 |
|
|
|
c1018d6b54
|
进行 Partner 框架层的部分调整
- 新增 AgentSubModule 注解，用于标识子模块
- 新增 MetaSubModule 类，用于存储子模块元信息
- 支持子模块初始化和注入逻辑，不再使用单例模式为执行模块提供子模块服务
- 重构模块初始化流程，支持模块和子模块的初始化
- 优化模块注册流程，分别处理模块和子模块
|
2025-09-11 13:07:48 +08:00 |
|
|
|
47684c78e0
|
进行 Partner 本体对于框架的适配，以及框架层的部分调整
框架:
- 调整 ActivateModel 中模型初始化设置的 initHook 权重为-1(最优先)
- 为 AgentGateway 中 receive 操作提供模板方法，子类需实现发送逻辑并提供适配器
- 取消了 AgentInteractionAdapter 的单例配置
- 调整 RunningFlow 的异常处理，并在RunningFlowContext中提供错误码进行判断
- 调整模块基类
-
本体:
- 新增配置加载异常，继承自Agent启动异常
- 修改 GlobalExceptionData 获取逻辑
- 移除 MessageSender 等交互接口，适配框架的交互逻辑
- 异常处理已适配
- 配置加载逻辑已适配
- Gateway 已适配
- CoreModel 已适配
|
2025-09-09 20:42:28 +08:00 |
|
|
|
10fb689c83
|
完善了框架层的完整执行流程，待进行demo测试并适配进Partner本体。
- 调整 runtime 目录结构, flow/ 归为 interaction/ 的子包
- 新增了 AgentGateway 以及 Gateway 对应的 Adapter 抽象类，下游必须实现这两者才能启动项目
- 调整 MetaModule 中的某些字段类别, 锁定为 AgentRunningModule 相关子类, 便于在执行流中执行模块
- 修复了 ModuleCheckFactory 中对于 @AgentModule 的错误检验逻辑
- 更新 Agent 启动器为step builder模式进行逐步构建，强制实现 AgentGateway 相关内容, 其余带有默认实现的部分也可自定义实现，只需实现对应的类或接口
|
2025-08-13 22:03:32 +08:00 |
|
|
|
86548903a0
|
完善配置工厂遗留问题; 初步完善 AgentRunningFlow 流程相关。
- 修复了 ActivateModel 中 model 实例化后却未赋值的问题
- 调整 Api 包下目录结构, 新增 runtime 包用于存放运行时相关类
- 完善 AgentConfigManager 基类以及对应的默认实现类中的加载、序列化以及更新逻辑
- 将异常类型分类为‘启动时异常’与‘运行时异常’，前者将直接导致启动停止，后者可通过异常回调实现进行处理
- 新增全局异常处理类以及默认的异常回调实现
- 新增几个异常类
- 完善 Agent 链式构建流程, 实际上只是做了一些方法转发，但毕竟那些可提供自定义实现的，不管是factory还是manager、handler, 它们都过于分散了。
|
2025-08-11 00:19:08 +08:00 |
|
|
|
cf1578fd14
|
模块注解机制完成，待测试。
- 调整Api包下的目录结构
- 抽取方法‘递归收集某类的继承链上的所有类’中
- 移除 ModuleFactoryContext、ModuleRegisterFactory 中关于 Init 方法的加载逻辑，将在 ModuleInitHookExecuteFactory 中加载并执行
- 完善了 ActivateModel 接口中prompt通用加载的实现
- 移除原有的框架Demo实现，开始进行测试Demo的编写
|
2025-08-07 23:33:11 +08:00 |
|
|
|
35b7dc7cda
|
继续推进框架中的模块注册机制。
- 完善 ModuleProxyFactory 中的hook逻辑代理实现，从模块类开始，自下而上扫描继承链中每个类的hook方法, 收集完毕并排序后统一实现代理逻辑。
- 从 ModuleFactoryContext 、 ModuleRegisterFactory 中移除了原有的‘先注册hook方法’相关内容。
- 更新 README
|
2025-08-07 00:09:18 +08:00 |
|
|
|
b1ed79ae9d
|
推进框架中的模块注册机制; 完善启动逻辑流程。
- 调整 InteractionFlowContext 为抽象类，实现者的模块上下文应当继承自该类。
- 完善 Agent 启动类具体逻辑
- 取消 Agent 类中 launchRunners 中关闭虚拟线程池的行为，交由JVM等待线程关闭，而非直接停止整个进程。
- 调整原hook注解分别为 BeforeExecute 、 AfterExecute，该注解用于模块抽象类的子类时可抽取重复逻辑
- 新增 Init 注解，用于执行初始化逻辑，可通过 order 属性指定顺序，默认为 0
- ModuleRegisterFactory 中新增‘加载 Init 注解标注的方法’的相关逻辑
- ModuleCheckFactory 添加对于 Init 注解的校验
- 完善了 ModuleProxyFactory 中设置代理实例的内容，可同时添加pre、post hook逻辑
|
2025-08-06 00:17:10 +08:00 |
|
|
|
507917157d
|
推进框架中的模块注册机制。引入 ByteBuddy 完成针对模块的代理实现。
- 调整部分包结构
- 重构 AgentRegisterContext ，将不同的 Context 内容按照对应模块进行封装
- 调整了‘添加可扫描包’的添加逻辑、新增了添加外部目录的扫描逻辑
- 新增几个异常类
- 在 ModuleCheckFactory 中新增了对于执行模块‘是否实现无参构造方法’的校验逻辑
- 引入 ByteBuddy 库负责构造执行模块实例，并添加对应的hook逻辑
- 调整 ModuleRegisterFactory 的逻辑，允许注册加载Module内的Hook方法
- 调整依赖引用关系，因为Partner-Main、Partner-Demo都继承自Partner-Api包，故将通用依赖移动至Api的pom文件中
|
2025-08-05 01:01:42 +08:00 |
|
|
|
ca3ffca4ea
|
推进框架中的模块注册机制，完善了模块校验与加载，接下来应当进行对于PostHook的动态代理以及模块的实例化逻辑。
- 移除了 ActivateModel 中的 promptModule 方法，不再需要
- 添加了必要的注释
- 为 AgentRegisterFactory 添加了用于指定扫描包的方法
- 新增了几个异常类
- 新增 MetaModule 类，包含Agent执行模块的必要信息，在工厂流程中作为执行模块的上下文
- 完善了 ModuleCheckFactory 中的检查逻辑
|
2025-08-03 23:48:20 +08:00 |
|
|
|
3c41abbba8
|
完善配置加载逻辑.
- 在 AgentRegisterContext 中新增对应的配置字段，供后续与模块协同检验
- 调整 ActivateModel 接口中的 modelSettings 实现逻辑
- 可以通过 ConfigLoaderFactory 提供的静态方法设置所需的配置管理类，并提供加载逻辑实现
- 为 ModelConfigManager 提供了默认的实现，从运行目录下加载模型配置与模块对应的提示词
- 实现了 ModelConfigManager 中的初步检验，检测是否存在默认模型配置与基础提示词，以及是否存在多余的模型配置。
- 新增了两个实体类，对应从文件加载的原始配置、提示词数据。
|
2025-08-02 23:04:15 +08:00 |
|
|
|
64a7ed261e
|
新增配置加载功能并优化模型设置
- 新增 ConfigLoaderFactory 和 ModelConfigFactory 以及对应的默认实现用于加载模型配置和提示词列表
- 重构 ActivateModel 接口，支持基本提示和特定提示的加载，具体逻辑待实现，可通过ModelConfigFactory加载
- 优化模块注册和能力注入相关逻辑
- 添加了必要注释
|
2025-07-31 22:13:10 +08:00 |
|
|
|
ade922cbc2
|
推进核心服务与模块注册机制
- 完善Agent流程执行框架
- Api包下新增flow流程包，该部分对应模块的执行流程
- 明确ModuleFactory与CapabilityFactory以及ModuleHook的共同运作流程
- 调整了Hook注解名称
|
2025-07-25 23:46:54 +08:00 |
|
|
|
effa1df7fa
|
需继续为上层模块构建注册体系以适应完整的加载逻辑。
- 移除了 BaseCoordinateManager 抽象类,而是添加了 @CoordinateManager 注解
- 移除了 CapabilityHolder 抽象类，换成 @CapabilityHolder 注解
- 新增了适应新注册机制的部分类，仍需进一步推进
|
2025-07-22 22:04:46 +08:00 |
|
|
|
954095aa55
|
- 新建模块Partner-Api，推进Partner适配核心服务注册机制。
- 将原有的模块体系进一步区分，分离模型持有能力与调用能力，Model将有Module自身持有，可通过ActivateModel开启相应能力
|
2025-07-21 23:47:52 +08:00 |
|
|
|
c9c9b05f18
|
核心服务注册机制完成，Partner待适配
- 将`methodSignature`抽取至工具类中
- 新增了数个异常类，适配工厂注册时的异常处理
- 完善了核心服务的注解检测、函数路由表生成以及代理动态注入实现。
|
2025-07-17 19:08:13 +08:00 |
|
|
|
dd10b00fb6
|
推进核心服务注册机制，并调整了Partner的模块结构
- 为了方便调试，将项目分为两个子模块，demo模块中进行新机制的开发工作，core模块为原来的Partner项目;
- 新增了多个注解，用于适配新的核心服务注册机制;
- 在`CapabilityRegisterFactory`中，将首先启动`statusCheck`，检查各个注解是否正常工作，包括以下内容:
- `CapabilityCore`核心服务与`Capability`接口是否匹配
- 核心服务中的`CapabilityMethod`是否与`Capability`接口中的方法匹配
- 是否存在待协调方法`ToCoordinatedMethod`以及对应的存在于`BaseCognationManager`子类实现中
|
2025-07-15 16:48:27 +08:00 |
|
|
|
98d830d08b
|
调整包结构; 新增调度模块大致框架; 尝试实现能力注册与注入机制，减轻重复逻辑，增强扩展性
|
2025-07-13 23:05:06 +08:00 |
|
|
|
192ae1bf5f
|
第一版感知模块完毕，设计了该模块的提示词，支持态度、印象、关系以及变化历史等层面的关系建模。
计划先推进调度模块，至于‘自我认知’‘情绪状态’等模块，或许可以划分为感知模块的子模块，等待后续补充。
|
2025-07-11 21:28:32 +08:00 |
|
|
|
a1d3c1e295
|
初步完善感知相关模块，提示词待设计:
- 修复了`Config`中生成的配置文件的模块链未加入`PostprocessExecutor`的问题
- 发现`InteractionHub`中还留有未使用的`coreModel`、`taskScheduler`,已删除
- 将`PerceiveUpdater`感知更新模块的提取逻辑下放到感知子模块`RelationExtractor`和`StaticMemoryExtractor`，感知更新主模块只负责将两个子模块的执行进行并发以及整合结果，最终提交给`PerceiveCapability`进行更新
-
|
2025-07-07 16:26:04 +08:00 |
|
|
|
9302417e58
|
Partner开发正式重启，回顾并继续推进感知模块:
- 在MemoryGraph新增用户索引，用于后续感知等模块的触发流程
- CognationManager及相关调用链中updateUser()方法的参数调整为User, 不再是PerceiveChatResult, 后者会跨越分层影响架构
- Model子类移除字段: MODEL_KEY，同时在setModel()中将不再需要传递MODEL_KEY参数，只需要实现modelKey()方法即可
|
2025-07-05 23:34:22 +08:00 |
|
|
|
e9053a4e88
|
推进感知模块相关开发，这部分倒意外地简单，现在有些基础，可能以后会有改进
- 新增 PerceiveCore 中的 updateUser 方法
- 新增了 PerceiveSelector 用于获取用户信息，提供基础的身份建模信息
- 新增 PerceiveUpdater 类用于异步更新用户身份感知
- 抽取 MemoryUpdater 中的执行判定逻辑至新增的 PostprocessExecutor 类，判定逻辑适用于多个`后处理模块`
- 重构 Model 类，改为抽象类，将modelKey定义为抽象方法，强制规范子类实现
|
2025-06-12 22:08:34 +08:00 |
|
|
|
f5c37f26a5
|
重构认知模块、着手感知模块相关开发
- 调整MemoryManager为CognationManager
- 由于CognationManager方法数量过多，根据能力分类抽取为四个主要接口CognationCapability、CacheCapability、MemoryCapability、PerceiveCapability
- 开始推进感知模块开发
|
2025-06-11 16:48:55 +08:00 |
|
|
|
d11d39ea81
|
重构拆分原‘记忆图谱’以适应后续扩展
- 拆分原`MemoryGraph`为 MemoryCore, CacheCore, GraphCore, PerceiveCore几个部分.
- MemoryCore中将不再包含操作逻辑, 由MemoryManager统一处理, 序列化逻辑仍交给MemoryCore。
- 更新README
|
2025-06-06 19:28:10 +08:00 |
|
|
|
407181db05
|
进行第二阶段调试修复: 部分InteractionContext相关类没有实现序列化，已修复
|
2025-06-06 10:55:34 +08:00 |
|
|
|
c706ec6aaf
|
进行第二阶段调试修复：修复部分细节问题
- 调整'fixTopicPath'在提取主题路径时的执行时机
- 记忆切片索引出错将不再保存异常快照，只保留日志
- 尝试发布临时版本
0.5.0
|
2025-06-06 10:01:26 +08:00 |
|
