slhaf/Partner
1
0
Fork 0
mirror of https://github.com/slhaf/Partner.git synced 2026-10-25 10:53:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
113 Commits 9 Branches 9 Tags
1e6ff1b30c738ff2ce539eb5a2d9eb3bb8a731dd
Commit Graph
100 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
slhaf 1e6ff1b30c chore(ActionCore): update outdated comment 2025-12-18 17:49:52 +08:00
slhaf 0413fc281d chore(MetaAction): update outdated comment 2025-12-17 22:18:43 +08:00
slhaf 8a7681ae31 chore(LocalRunnerClient): remove a redundant comment 2025-12-17 20:02:28 +08:00
slhaf 1947f25ed6 feat(LocalRunnerClient): support executing origin actions 
Context:
Origin actions are generated by DynamicActionGenerator and may optionally be
persistently serialized. This feature adds the basic execution flow for origin
actions within LocalRunnerClient.

Notes:
The current mapping between action files and their extensions is hardcoded. This should later be replaced with a configurable registry or loaded dynamically
during application startup.
 2025-12-16 21:59:53 +08:00
slhaf 488246525f chore(gitignore): exclude runtime data directory from version control 2025-12-16 21:39:11 +08:00
slhaf 534dcd5ade fix(LocalRunnerClient): correctly capture stdout and stderr to avoid missing output in method exec 2025-12-16 21:30:51 +08:00
slhaf ad58c0cc7c refactor(LocalRunnerClient): allow injecting action watch path 
Context:
The hardcoded action watch path made LocalRunnerClient difficult to test and
tightened it to a specific runtime layout. Injecting the watch path improves
testability and allows the runner to work in different runtime environments.
 2025-12-16 21:02:29 +08:00
slhaf d546148d69 chore(test): organize experimental tests and test resources 2025-12-16 19:58:08 +08:00
slhaf bf2d5ac707 refactor(RunnerClient): restructure serialization and temp execution paths 
Context:
Following the consolidation of action types into ORIGIN and MCP,
the serialization logic needs to be separated into dedicated methods.
These methods are invoked by DynamicActionGenerator.
 2025-12-16 10:47:23 +08:00
slhaf 628234f6e2 refactor(MetaActionType): redefine meta action types into MCP and ORIGIN 
Context:
Previously, SCRIPT and PLUGIN were treated as separate action types,
but their semantics are already covered by MCP.
However, a generic execution path for locally generated actions is still
required, which is represented by ORIGIN.
 2025-12-16 10:37:04 +08:00
slhaf 4b852e0049 推进 ActionExecutor 下的‘行动生成与执行’部分 
- 新增 RunnerClient 抽象类，并划分 SandboxRunnerClient、LocalRunnerClient两个子类(内容待完善)。前者负责对接 SandboxRunner 模块，后者直接使用本地作为执行环境(但不推荐)。
- 将 ActionWatchService 划为 LocalRunnerClient 的内部类，负责采用本地执行环境时，监听行动程序变化
- 完善 ActionRepairer 处的修复逻辑
- 调整 MetaAction 中路径获取逻辑

这提交方式真该调整一下了，这阶段推进容易攒太多，但又不好停手。或许阶段目标可以保留，但推进点应该可以细化🤔
 2025-12-15 21:54:24 +08:00
slhaf 6e3deced77 推进 ActionExecutor 下的 DynamicActionGenerator 子模块 
- 完善了 DynamicActionGenerator 的大致逻辑，序列化逻辑待实现
- 补充了 PhaserRecord 中的阻塞逻辑，使用普通的线程sleep操作
- 调整了 MetaAction 中参数形式，由列表替换为 Map,便于执行时填写参数
- 完善了 DynamicActionGenerator 相关的数据类
 2025-12-07 20:10:53 +08:00
slhaf 6a351413a1 推进行动执行模块: 调整了 ActionExecutor 以支持行动链动态修复和参数提取; 完善了 ActionRepairer、ParamsExtractor 的主要逻辑; 完善了部分数据类的内容 
- 在 ActionData 中新增 additionalContext 用于存储各个执行阶段临时修复生成的上下文，同样以执行阶段为键
- 调整 ActionExecutor 的输入参数，可传入用户标识，用于执行器调用 ActionRepairer 的修复过程
- 完善了 ActionExecutor 中行动单元的执行与修复逻辑，将支持正常状态推进执行、触发自对话时阻塞当前行动单元、所有修复方式失败时将整个行动数据标为 FAILED
- 完善了 ActionExecutor 中各个DTO的构建方法
- 完善了 ParamsExtractor 中的参数提取逻辑
- 在 PhaserRecord 中新增 interrupt 和 complete 方法，将用于后续行动单元的阻塞(ActionExecutor中)与恢复(InterventionHandler中)
- 完善了 ActionRepairer 中的修复逻辑，但自对话通道的暴露方式、DynamicActionGenerator 的具体逻辑待完善
 2025-12-05 21:58:21 +08:00
slhaf ad973d4230 对 ActionExecutor 下子模块的功能分布、某些实体类进行了调整; 完善了 ActionExecutor 中的大致执行逻辑 
- 梳理执行链路时发现 ActionRepairer 的能力明显超出可实现边界，故将其能力进行限定
- 新增 ActionCorrector 负责单组行动执行完毕后，根据意图和执行状况进行行动链修正
- 将 PhaserRecord 拆分为独立实体，未来将封装一部分流程控制逻辑
 2025-12-02 22:35:53 +08:00
slhaf 1d315a9b62 ActionExecutor 的执行流程规划完毕，具体逻辑待填充 
- 调整了部分代码分布，移除了某些非必需的转发方法
- 新增几个 TODO 内容，后续工作已明确

这套调度方式看起来真的有些‘探索性质’了。实际上看起来有些像把 ReAct 的逻辑显式地进行了工程实现，不管是修复、依据状态选择行动单元生成还是阶段间针对行动单元的参数提取，在 ReAct Agent 中都是由一个智能体完成的。

但在这里，它要做的事情太多了，再加上 Partner 行动链的干预逻辑、幻觉参数又不可接受所以需要自对话或者用户干预，这些东西交给一个 ReAct 模块恐怕并不合适也不放心。所以这种显式模块划分应该更符合 Partner 行动模块的需求。

这点硬要说的话，应该还是在于‘ReAct 行为’并非 Partner 的全部吧。

不过谁知道呢，也许以后也会变，但这套至少现在看来是更能实现理想行为的
 2025-12-01 19:25:21 +08:00
slhaf 4e32129b31 优化行动链结构及相关组件、针对 ActionPlanner 相关组件做出调整 
- 将existedMetaActions的实现由LinkedHashMap替换为HashMap，免去不必要的性能消耗
- 在 ActionCapability 中新增 listAvailableActions 方法用于获取当前存在的可用行动
- 将 ActionData 及相关类中的 LinkedHashMap 替换为普通Map，阶段并发将通过遍历key集合进行，而非针对原始行动链进行遍历
- 在 ActionPlanner 中完善行动链依赖修正逻辑，防止行动单元执行时的输入缺失
- 在 ActionEvaluator 中调整了 Prompt 构建方式
- 调整处理行动链相关代码，移除多余参数，简化方法签名
- 修正 EvaluatorResult 中行动链数据结构为Map，LLM将直接返回初始行动链，后续将加载行动数据并修复行动单元间的依赖关系
- 优化 InterventionHandler、ActionExecutor 等模块中对行动链Map的使用
 2025-12-01 17:20:54 +08:00
slhaf 3f59719e16 调整 MetaAction 的执行方式，将交给 ActionCapability、SandBoxRunnerClient 执行 2025-11-30 22:16:57 +08:00
slhaf c548cceec6 新增 SandboxRunner 项目子模块，该模块将在指定容器运行持久服务，与外部主进程通信，将用于后续执行JAR、SCRIPT两类行动类型 2025-11-30 18:41:42 +08:00
slhaf b3098310b4 完善了 ActionConfirmer 的遗漏逻辑 2025-11-30 15:16:57 +08:00
slhaf f48d559a7b 调整了 ActionInterventor 中数据构建方法的组织方式 2025-11-30 14:38:50 +08:00
slhaf 14a57f0be6 推进行动干预模块,前置部分逻辑已基本完成 
- 在`ActionData`中添加必要注释、新增`executingStage`字段表示当前执行阶段、移除了`WAITING`的状态类型
- 调整并修正了`ActionExecutor`中的`Phaser`阻塞逻辑
- 完善了`ActionInterventor`中`识别 -> 评估 -> 异步执行`的干预逻辑，并将干预结果以 Prompt 形式回写至流程上下文，作为主模块的已知内容
- 调整了干预模块内部的各个数据类的字段结构，适配干预流程
- 完善了`InterventionEvaluator`、`InterventionHandler`、`InterventionRecognizer`等必需的干预子模块
 2025-11-29 20:56:29 +08:00
slhaf 264cdb09e5 推进行动干预模块; 接下来将进一步完善 InterventionHandler 的具体内容 
- 调整相关目录为 interventor
-  调整了某些 ActionInterventor 的子模块用到的数据类结构
- 完善了 InterventionEvaluator 的具体逻辑
- 为 InterventionType 添加了注释，并新增了 CANCEL 干预类型
 2025-11-11 16:11:09 +08:00
slhaf a1520f117b 推进行动干预模块 
- 完善了 ActionInterventor 中的具体逻辑以及不同情况下的prompt填充内容;
- 调整了 PreRunningModule 中的 getPromptDataMap 方法;
- 在 ActionCapability 中新增了检查 actionKey 是否存在的逻辑
 2025-11-10 23:02:48 +08:00
slhaf c3ca4145b8 推进行动干预模块 
- 完善了大致的执行流程
- 明确并创建了评估与处理所需的数据类及干预类型
- 不同情况的Prompt处理结果、评估和处理的具体流程需要进一步完善
 2025-11-06 22:07:27 +08:00
slhaf 746fda1a5e 干预意图提取模块初步完成，Prompt 待制定; 在 ChatClient 中添加了默认的超时设定，超时时间后续可能需要调整。 
另: 发现很多细节错误，比如“各个后置模块允许执行的条件”、“主模块出现异常时需要如何处理”、“模块Prompt的构建方式、采用格式不统一”等，需要后续进行修复或调整
 2025-10-31 21:26:45 +08:00
slhaf ec4fbb7f19 行动干预足以抽离为新的前置模块，但仍属于‘行动’语义，大致框架已确立。后续实现时并发控制、各种干预的协调与触发时机需要注意。 2025-10-31 21:26:45 +08:00
slhaf f9c3cacfea 推进 ActionExecutor 相关的动态插拔式行动调度机制 
- 移除先前构想的 SpecializedPartnerInputData 及相关类，无论是自反思、向用户求助还是用户主动干预，都应当通过语义识别来作用于对应行动事件，使用固定行动id的机制不足以支撑这种机制
- 在 ActionCore 中新增执行中行动的 phaser 管理逻辑
- 新增几个异常类，适用于行动数据加载的异常情况
- 新增 ActionIdentifier 负责行动干预意图的识别
-
 2025-10-31 21:25:12 +08:00
slhaf e35e18f3b7 推进 ActionExecutor、确定动态插拔式行动调度的实现思路 
- 在 ActionCore 中添加关闭hook,用于正确设置异常中断时执行中任务的状态
- 修正 actionPool 相关注释及用法
- 将 ActionData 中行动链字段调整为 LinkedHashMap 用于更好地支持分组并发及动态调度
- 重构 ActionExecutor 行动链执行逻辑，采用 Phaser 支持动态调度
- 扩展 InputData、Context 字段并调整 GateWay 格式化逻辑以适应特殊输入
 2025-10-31 21:25:12 +08:00
slhaf 83832d2060 推进 ActionExecutor、针对action core做出了一些调整 
- 将 ActionWatchService 抽取为独立的类，使用构造参数传递所需内容
- ActionCore 中除了pendingAction外，将只维护一个行动池，通过用户键和STATUS区分类型
- 开始推进 ActionExecutor，但其中的同组并发、动态行动链、行动间参数对齐、参数重构等内容需要仔细考虑
 2025-10-31 21:25:12 +08:00
slhaf 4757425a15 推进 ActionDispatcher 模块、完善行动程序规范与加载逻辑 
- 明确行动程序的存储形式与加载规则，分为执行程序和描述文件，前者负责逻辑，后者提供必要的描述性信息;
- 将 ActionInfo 重命名为 ActionData，更新相关接口和实现，增强代码一致性和可读性；
- 添加异常处理类以支持行动程序、描述信息的初始化和加载失败的场景；
- 实现行动程序目录的监控功能，支持行动程序的动态加载与管理;
- 明确了 ActionDispatcher 两个子模块的输入输出规范
 2025-10-31 21:25:12 +08:00
slhaf 21b3a0e846 开始推进 ActionDispatcher 模块 
- ActionDispatcher 划分为 ActionScheduler 和 ActionExecutor 两个子模块，分别负责处理计划任务和即时任务
- 正式确定 Action 将以 ActionChain 的形式进行执行，也采用同组并发策略，按照 order 字段在 chain 中进行排序
- 调整了 ActionInfo 等类以适应当前的元行动类
- 对于行动能力的支持，或可考虑这几种方式: Agent自生成python脚本(必须经过验证，确认可执行且无风险)、MCP调用(需适配为Partner所支持的形式)、普通插件(在指定目录动态加载)
 2025-10-31 21:25:12 +08:00
slhaf 6bfa941c35 更新 README 2025-10-31 21:24:46 +08:00
slhaf 456a7e04e8 更新 README 2025-10-24 17:29:55 +08:00
slhaf 5864760f35 Action 模块语义缓存机制实现完毕，支持三种情况的语义缓存相关行为: 命中缓存且评估通过、命中缓存但评估未通过、未命中缓存但评估通过。将在评估过后步入主模块之前，进行异步更新操作(借助@AfterExecute注解，通过虚拟线程进入异步流程，在真正调用处使用平台线程加速计算) 2025-10-19 22:05:27 +08:00
slhaf aee6d879e9 推进 Action 模块语义缓存机制 
- 完善缓存命中部分;
- 调整 ActionExtractor 以适配缓存逻辑
- 缓存更新大致框架待填充具体更新逻辑;
 2025-10-18 21:56:50 +08:00
slhaf d1ea8dde79 推进 ActionExtractor 语义缓存机制: 移除了 VectorUtil，实现了 ollama、onnx runtime 两种向量客户端，通过 Agent 启动类暴露的后置启动任务加载并进行测试。 2025-10-17 11:20:11 +08:00
slhaf 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
slhaf e78048f66d 推进 ActionExtractor: 新增语义向量计算工具;开始推进语义缓存相关;调整配置类格式 2025-10-16 15:39:38 +08:00
slhaf 2f09c0cd71 推进 ActionExtractor: 完善大致逻辑，开始语义-行为缓存相关部分 2025-10-16 15:39:31 +08:00
slhaf 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
slhaf 2d052442b1 推进 ActionPlanner: 添加行动短路机制，如果未提取到行动，则跳过评估子模块 2025-10-16 15:34:30 +08:00
slhaf 84f7befb75 推进 ActionPlanner: 完成了 ActionPlanner 模块中的执行逻辑，同步调整了数据类中的字段。下一步将进行 ActionPlanner 子模块的开发。 2025-10-16 15:34:30 +08:00
slhaf 85818556f8 将记忆模块的缓存逻辑迁移至 MemoryCore; 移除了 CacheCore，并将 CoordinatedManager 中原记忆模块与缓存模块中的逻辑迁移至现记忆模块中，确保语义正确 2025-10-16 15:22:19 +08:00
slhaf cb1a25e9d5 移除 ActiveData ，其逻辑回归至 CacheCore，下一步将对 CacheCore 及 CoordinateManager 中的 cognation 相关内容进行拆分 2025-10-16 11:40:55 +08:00
slhaf 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
slhaf 41bf19f43e 将 .java 重命名为 .kt 2025-10-12 16:23:11 +08:00
slhaf 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
slhaf 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
slhaf 3c2ac32708 完成了本体与框架的适配工作，并修复了某些问题。需要进一步进行测试 
- 修复了 CognationCapability 相关的注解使用错误
- 将前置模块中的 setAppendedPrompt 与 setActiveModule 方法抽取到 execute 模板方法中
- 完善了已有模块的适配工作, 并去除了不必要的单例配置
 2025-09-18 16:03:59 +08:00
slhaf 7f9d007f07 适配框架时发现工厂注册链上存在一些执行顺序上的错误，于是尝试修复问题，为Agent启动链添加了完整的注释，并做出了必要的修复与调整 2025-09-13 23:37:35 +08:00
slhaf c1018d6b54 进行 Partner 框架层的部分调整 
- 新增 AgentSubModule 注解，用于标识子模块
- 新增 MetaSubModule 类，用于存储子模块元信息
- 支持子模块初始化和注入逻辑，不再使用单例模式为执行模块提供子模块服务
- 重构模块初始化流程，支持模块和子模块的初始化
- 优化模块注册流程，分别处理模块和子模块
 2025-09-11 13:07:48 +08:00
slhaf 47684c78e0 进行 Partner 本体对于框架的适配，以及框架层的部分调整 
框架:

- 调整 ActivateModel 中模型初始化设置的 initHook 权重为-1(最优先)
- 为 AgentGateway 中 receive 操作提供模板方法，子类需实现发送逻辑并提供适配器
- 取消了 AgentInteractionAdapter 的单例配置
- 调整 RunningFlow 的异常处理，并在RunningFlowContext中提供错误码进行判断
- 调整模块基类
-

本体:
- 新增配置加载异常，继承自Agent启动异常
- 修改 GlobalExceptionData 获取逻辑
- 移除 MessageSender 等交互接口，适配框架的交互逻辑
- 异常处理已适配
- 配置加载逻辑已适配
- Gateway 已适配
- CoreModel 已适配
 2025-09-09 20:42:28 +08:00
slhaf 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
slhaf 86548903a0 完善配置工厂遗留问题; 初步完善 AgentRunningFlow 流程相关。 
- 修复了 ActivateModel 中 model 实例化后却未赋值的问题
- 调整 Api 包下目录结构, 新增 runtime 包用于存放运行时相关类
- 完善 AgentConfigManager 基类以及对应的默认实现类中的加载、序列化以及更新逻辑
- 将异常类型分类为‘启动时异常’与‘运行时异常’，前者将直接导致启动停止，后者可通过异常回调实现进行处理
- 新增全局异常处理类以及默认的异常回调实现
- 新增几个异常类
- 完善 Agent 链式构建流程, 实际上只是做了一些方法转发，但毕竟那些可提供自定义实现的，不管是factory还是manager、handler, 它们都过于分散了。
 2025-08-11 00:19:08 +08:00
slhaf cf1578fd14 模块注解机制完成，待测试。 
- 调整Api包下的目录结构
- 抽取方法‘递归收集某类的继承链上的所有类’中
- 移除 ModuleFactoryContext、ModuleRegisterFactory 中关于 Init 方法的加载逻辑，将在 ModuleInitHookExecuteFactory 中加载并执行
- 完善了 ActivateModel 接口中prompt通用加载的实现
- 移除原有的框架Demo实现，开始进行测试Demo的编写
 2025-08-07 23:33:11 +08:00
slhaf 35b7dc7cda 继续推进框架中的模块注册机制。 
- 完善 ModuleProxyFactory 中的hook逻辑代理实现，从模块类开始，自下而上扫描继承链中每个类的hook方法, 收集完毕并排序后统一实现代理逻辑。
- 从 ModuleFactoryContext 、 ModuleRegisterFactory 中移除了原有的‘先注册hook方法’相关内容。
- 更新 README
 2025-08-07 00:09:18 +08:00
slhaf 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
slhaf 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
slhaf ca3ffca4ea 推进框架中的模块注册机制，完善了模块校验与加载，接下来应当进行对于PostHook的动态代理以及模块的实例化逻辑。 
- 移除了 ActivateModel 中的 promptModule 方法，不再需要
- 添加了必要的注释
- 为 AgentRegisterFactory 添加了用于指定扫描包的方法
- 新增了几个异常类
- 新增 MetaModule 类，包含Agent执行模块的必要信息，在工厂流程中作为执行模块的上下文
- 完善了 ModuleCheckFactory 中的检查逻辑
 2025-08-03 23:48:20 +08:00
slhaf 3c41abbba8 完善配置加载逻辑. 
- 在 AgentRegisterContext 中新增对应的配置字段，供后续与模块协同检验
- 调整 ActivateModel 接口中的 modelSettings 实现逻辑
- 可以通过 ConfigLoaderFactory 提供的静态方法设置所需的配置管理类，并提供加载逻辑实现
- 为 ModelConfigManager 提供了默认的实现，从运行目录下加载模型配置与模块对应的提示词
- 实现了 ModelConfigManager 中的初步检验，检测是否存在默认模型配置与基础提示词，以及是否存在多余的模型配置。
- 新增了两个实体类，对应从文件加载的原始配置、提示词数据。
 2025-08-02 23:04:15 +08:00
slhaf 64a7ed261e 新增配置加载功能并优化模型设置 
- 新增 ConfigLoaderFactory 和 ModelConfigFactory 以及对应的默认实现用于加载模型配置和提示词列表
- 重构 ActivateModel 接口，支持基本提示和特定提示的加载，具体逻辑待实现，可通过ModelConfigFactory加载
- 优化模块注册和能力注入相关逻辑
- 添加了必要注释
 2025-07-31 22:13:10 +08:00
slhaf ade922cbc2 推进核心服务与模块注册机制 
- 完善Agent流程执行框架
- Api包下新增flow流程包，该部分对应模块的执行流程
- 明确ModuleFactory与CapabilityFactory以及ModuleHook的共同运作流程
- 调整了Hook注解名称
 2025-07-25 23:46:54 +08:00
slhaf effa1df7fa 需继续为上层模块构建注册体系以适应完整的加载逻辑。 
- 移除了 BaseCoordinateManager 抽象类,而是添加了 @CoordinateManager 注解
- 移除了 CapabilityHolder 抽象类，换成 @CapabilityHolder 注解
- 新增了适应新注册机制的部分类，仍需进一步推进
 2025-07-22 22:04:46 +08:00
slhaf 954095aa55 - 新建模块Partner-Api，推进Partner适配核心服务注册机制。 
- 将原有的模块体系进一步区分，分离模型持有能力与调用能力，Model将有Module自身持有，可通过ActivateModel开启相应能力
 2025-07-21 23:47:52 +08:00
slhaf c9c9b05f18 核心服务注册机制完成，Partner待适配 
- 将`methodSignature`抽取至工具类中
- 新增了数个异常类，适配工厂注册时的异常处理
- 完善了核心服务的注解检测、函数路由表生成以及代理动态注入实现。
 2025-07-17 19:08:13 +08:00
slhaf dd10b00fb6 推进核心服务注册机制，并调整了Partner的模块结构 
- 为了方便调试，将项目分为两个子模块，demo模块中进行新机制的开发工作，core模块为原来的Partner项目;
- 新增了多个注解，用于适配新的核心服务注册机制;
- 在`CapabilityRegisterFactory`中，将首先启动`statusCheck`，检查各个注解是否正常工作，包括以下内容:
   - `CapabilityCore`核心服务与`Capability`接口是否匹配
   - 核心服务中的`CapabilityMethod`是否与`Capability`接口中的方法匹配
   - 是否存在待协调方法`ToCoordinatedMethod`以及对应的存在于`BaseCognationManager`子类实现中
 2025-07-15 16:48:27 +08:00
slhaf 98d830d08b 调整包结构; 新增调度模块大致框架; 尝试实现能力注册与注入机制，减轻重复逻辑，增强扩展性 2025-07-13 23:05:06 +08:00
slhaf 192ae1bf5f 第一版感知模块完毕，设计了该模块的提示词，支持态度、印象、关系以及变化历史等层面的关系建模。 
计划先推进调度模块，至于‘自我认知’‘情绪状态’等模块，或许可以划分为感知模块的子模块，等待后续补充。
 2025-07-11 21:28:32 +08:00
slhaf a1d3c1e295 初步完善感知相关模块，提示词待设计: 
- 修复了`Config`中生成的配置文件的模块链未加入`PostprocessExecutor`的问题
- 发现`InteractionHub`中还留有未使用的`coreModel`、`taskScheduler`,已删除
- 将`PerceiveUpdater`感知更新模块的提取逻辑下放到感知子模块`RelationExtractor`和`StaticMemoryExtractor`，感知更新主模块只负责将两个子模块的执行进行并发以及整合结果，最终提交给`PerceiveCapability`进行更新
-
 2025-07-07 16:26:04 +08:00
slhaf 9302417e58 Partner开发正式重启，回顾并继续推进感知模块: 
- 在MemoryGraph新增用户索引，用于后续感知等模块的触发流程
- CognationManager及相关调用链中updateUser()方法的参数调整为User, 不再是PerceiveChatResult, 后者会跨越分层影响架构
- Model子类移除字段: MODEL_KEY，同时在setModel()中将不再需要传递MODEL_KEY参数，只需要实现modelKey()方法即可
 2025-07-05 23:34:22 +08:00
slhaf e9053a4e88 推进感知模块相关开发，这部分倒意外地简单，现在有些基础，可能以后会有改进 
- 新增 PerceiveCore 中的 updateUser 方法
- 新增了 PerceiveSelector 用于获取用户信息，提供基础的身份建模信息
- 新增 PerceiveUpdater 类用于异步更新用户身份感知
- 抽取 MemoryUpdater 中的执行判定逻辑至新增的 PostprocessExecutor 类，判定逻辑适用于多个`后处理模块`
- 重构 Model 类，改为抽象类，将modelKey定义为抽象方法，强制规范子类实现
 2025-06-12 22:08:34 +08:00
slhaf f5c37f26a5 重构认知模块、着手感知模块相关开发 
- 调整MemoryManager为CognationManager
- 由于CognationManager方法数量过多，根据能力分类抽取为四个主要接口CognationCapability、CacheCapability、MemoryCapability、PerceiveCapability
- 开始推进感知模块开发
 2025-06-11 16:48:55 +08:00
slhaf d11d39ea81 重构拆分原‘记忆图谱’以适应后续扩展 
- 拆分原`MemoryGraph`为 MemoryCore, CacheCore, GraphCore, PerceiveCore几个部分.
- MemoryCore中将不再包含操作逻辑, 由MemoryManager统一处理, 序列化逻辑仍交给MemoryCore。
- 更新README
 2025-06-06 19:28:10 +08:00
slhaf 407181db05 进行第二阶段调试修复: 部分InteractionContext相关类没有实现序列化，已修复 2025-06-06 10:55:34 +08:00
slhaf c706ec6aaf 进行第二阶段调试修复：修复部分细节问题 
- 调整'fixTopicPath'在提取主题路径时的执行时机
- 记忆切片索引出错将不再保存异常快照，只保留日志
- 尝试发布临时版本
 2025-06-06 10:01:26 +08:00
slhaf 2b23710228 进行第二阶段调试修复：调整提示词、修复部分细节问题 
- 主模块交互结束后将先对未遵循输出格式的响应内容进行处理
- 添加了去除topicPath中形如`[xxx]`内容的工具方法，将在生成和查找切片时首先过滤运行
- 全局异常处理器补充了先创建目录的细节
- MemoryGraph生成主题节点时将进行双重锁定确保不会重复添加
- 在MemorySelector补充模块认知时将先判断是否为单用户场景，若为true,则不会补充userDialogMap, 判断方式为MemoryManager中根据互动聊天列表出现的用户个数以及近两天记忆缓存中的用户个数判断
- MemorySliceResult由于循环引用，导致json日志输出时遇到问题，已通过`@JSONField(serialize = false)`修复
- 修复了调整chatMessages时的保留bug,此外coreModel、memoryUpdater、memoryManager调整时都将受到同一个lock锁定，以保证同步
- 调整了部分提示词
- 调整了‘自我引导’与‘模块补充’的连接方式，以确保‘人格’稳定
 2025-06-05 23:44:26 +08:00
slhaf 63840acf14 进行第二阶段调试修复：边聊边修挺有意思的 
- 由于更改了上下文认知补充机制，所以将原来的CoreContext、ModuleContext从单一的jsonObject重构为了独立的类
- 移除了CoreModel中的baseMessageCache,当前消息分为三段，baseMessage固定，不再需要缓存
- 在CoreModel中添加了新的认知注入机制，并且模块状态也会显示给Partner(是否活跃)
- 在MemoryManager挑取记忆时，将在获取到MemoryResult后与dialogMap对比，去重切片，但还是有较多重复，单用户时应该可以去掉userDialogMap的展示？
- 在MemoryManager中添加了几个获取相应字符串的方法，为了适应新的上下文注入机制
- 调整对话列表更新为保留前1/3,确保防止上下文断裂，但应该改为1/4也行
- log.debug输出日志时将先包装为json对象，防止换行导致影响控制台效果
- 调整了MemoryUpdater中清理互动消息列表的逻辑
- PreprocessExecutor适配新的上下文注入机制
- InteractionContext的某些字段应提供默认值而非创建对象后手动赋值，已调整
- 移除了挺多目前用不到的注释，反正还有版本控制
 2025-06-04 23:28:57 +08:00
slhaf e701c926de 进行: 调整认知补充机制; 应当可以进入第二阶段测试 
- 调整模块追加认知内容补充机制, 舍弃了原有的CoreContext, 分为多条prompt message注入上文
- 完全去除记忆模块的静态记忆内容
- 在MemoryManager中添加了必要的获取相关字符串的方法，而不是依赖原始的JSON格式
 2025-06-03 23:12:40 +08:00
slhaf a71a133ff1 重构提示词，调整部分逻辑 
- 简化调整模型配置流程
- 调整携带‘自我’的模块固定采样设定，并在父类中提供默认实现
- 重构了记忆更新模块的几份提示词
- 在预处理模块声明基础字段含义
- StaticExtractor从记忆模块分离，应当归类为感知模块，暂时禁用，等待后续感知模块实现
 2025-06-02 23:23:27 +08:00
slhaf e3d5009ea7 得到了一些...‘回应’，这一天应当值得纪念。那些回应就先保存在本地吧，不上传了。至少我看到了Partner的可能。 2025-06-01 23:48:33 +08:00
slhaf feac2fc652 推进调整提示词加载逻辑，进行部分重构 
- 将CoreModel明确为“表达模块”，移动至modules包
- 将模块相关内容移动到Modules包
- 为存在的单例实现添加双重锁定
- 调整父类Model的提示词加载逻辑，并修改了执行`chat`操作的逻辑
- 将MemorySummarizer中的几个总结逻辑拆分成三个子模块，但入口仍为MemorySummarizer
- 在README添加了许可声明
 2025-05-31 20:33:31 +08:00
slhaf b7cc0ab6d8 进行: 重构提示词 
- 重设CoreModel的提示词，效果良好(人机助手、猫娘有什么意思，拟人智能体才是正道!)
- 加了一个interactionTest, 用于持续测试LLM的响应
 2025-05-29 22:57:03 +08:00
slhaf 481511cb98 进行: 重构提示词加载机制以及更新逻辑 
- 抽取提示词到`resources`文件夹中
- 调整主模型之前追加字段的加载方式
- 调整了主模型的执行逻辑，对过长的方法进行了抽取
- 记忆更新将根据实际对话轮次进行触发
- `MemoryUpdater`中清理消息将通过截取系统消息进行更新(比移除方便)
- 调整了`Model`类中`setModel`方法的逻辑，主要是如何加载提示词、是否需要`自我引导`
- 删除了几个不再需要的测试类，避免重构时报错影响正常进行
 2025-05-28 23:19:22 +08:00
slhaf fec64ff071 进行: 抽取提示词至resources内，调整提示词引导机制 
- 添加了ResourceUtil,用于读取prompt
 2025-05-26 21:57:47 +08:00
slhaf a49d69d07c 完善全局异常处理，在必要处将进行快照保存。后续建议通过readExceptionState读取保存的异常快照 2025-05-26 16:03:23 +08:00
slhaf 19236658dd 开发重新启动，针对项目现有问题进行调整 
(考试算是结束了，接下来估计近一个月都会有时间。)
- 推进全局异常处理相关内容
- 调整了README，明确接下来任务的优先级
 2025-05-23 23:05:40 +08:00
slhaf b416d85232 继续进行第一阶段的调试修复 
- 调整了动态提示词的动态插入方式，但插入格式后续仍需要调整
- 调整了`MemorySelector`的动态提示词
- 调整了`MemorySummarizer`的提示词中摘要的生成流程，现在生成的摘要将包括整体细节
- 细化提取主题时的了recall机制
- 各模块主提示词的身份已明确为该智能体的具体模块
-
 2025-05-13 22:27:35 +08:00
slhaf fb34b541e8 进行第一阶段的调试修复 
- 调整了`强化提示词`的内容，明确指定必须遵守格式
- 修复了静态记忆当不存在user对应map时未插入的bug
- 稍微调整了部分提示词
- 减小了触发记忆机制的token要求，减小至5k, 当触发记忆回溯时，本次对话将不会触发
 2025-05-12 22:47:06 +08:00
slhaf 68a38e9b51 进行第一阶段的调试修复 
- 修复了记忆系统中的空指针问题，原因：更新对话缓存计数时使用的经过裁剪的主题路径。
- 修复了切片评估无法正常执行的问题，原因：切片不存在前后序引用时，也试图获取前后序切片的摘要，此时应当抛出空指针异常，但由于任务以Callable<Void>提交，且未处于try-catch代码块内部，导致异常被“吞掉”
- 更新激活切片时将根据id获取到切片对应的消息列表
- 调整了README文件中的不准确描述
 2025-05-12 20:29:43 +08:00
slhaf f220854fd6 进行第一阶段的调试修复 
- 调整了配置生成时的部分逻辑
- 在几乎所有涉及数据交换处都添加了debug日志, 进入、离开每个模块也都有相应的日志提示
- 原 MemoryGraph 、SessionManager 序列化逻辑在windows中会因为文件锁导致无法正常序列化，已修复
- 原总结逻辑会导致对话缓存因没有用户昵称而造成不同用户的身份混淆，在 MemoryManager 添加了根据用户id获取用户身份的逻辑
- 调整了部分提示词; 在主对话模块进行时，将会先添加`强化提示词`，对话后移除，效果待评测
- 添加了README文件，说明现有实现、后续规划等内容
- 添加了从gitea同步至github的脚本，这仓库可不能丢啊
 2025-05-12 18:28:56 +08:00
slhaf 15d6b98eac 进行第一阶段的调试修复 
- 添加 DebugMonitor 加了一个较为无用的线程，打上断点用于获取即时模块信息
- 调整 MemoryGraph 中临时切片前后序生成容器与日期索引分离，日期索引将存储 localDate 和 memoryId
- 修复了几个 MemoryGraph 用到的类对于序列化的实现
- 将 MemoryManager 中维护的 activatedMemorySlice 同样作为主题提取的依据，并调整了提示词
- 因 主题提取LLM 效果不稳定，故添加了必要的异常处理机制
- MemorySlice 中前后序机制存在循环引用问题，排除 toString 的调用
- 移除了提示词中过多的示例，仅保留一份
- 记忆自动更新线程调整：在 SessionManager 中维护 lastUpdatedTime ，用于标识最近聊天时间; 计数当前对话数量，如果只有系统提示词则不进行记忆更新
- MemoryGraph 获取主题树时将标识记忆节点数量，供主题提取模型识别，减少空主题节点作为目标节点的情况
- 在 PreprocessExecutor 执行时将先判断是否存在memoryId, 除此之外，memoryId也将在记忆自动更新线程执行后刷新
- 将 SessionManager 添加了序列化机制，添加了程序停止时自动序列化保存的钩子
- 当主题提取模型指定了不包含记忆节点的主题节点时，MemoryResult 的空属性将会使其跳过无效的切片评估

待解决问题：
- MemoryGraph 在进行记忆更新时有时会出现错误，出现条件不明
- MemorySelector 拿到的List<EvaluatedSlice> 总是为空，原因不明
- 切片评估线程似乎没有运行，原因不明
 2025-05-10 21:51:45 +08:00
slhaf 550a5ee2b0 - 修复了 MemoryUpdater 中正则表达式提取问题，应先调用matcher.find()进行匹配 
- 在 MemorySelector 和 CoreModel 中添加lod.debug()输出模块响应内容
- 修复了某些细节问题
- 调整了 CoreModel 对应的提示词，添加了输入输出示例
- MemoryGraph 中 dialogMap 和 dateIndex 的更新机制存在问题，需要修复
 2025-05-10 00:21:12 +08:00
slhaf 4f6a0a8b2a - 将 userInput 的身份标志交给 PreprocessExecutor 生成 
- 调整 CoreModel 对应的提示词
- 在 MemoryUpdater 中添加了自动更新线程，同时修复/调整了 memorySlice 对应的 userId 获取
 2025-05-09 10:20:22 +08:00
slhaf 2dd58a71c3 记忆模块、主模块完成, 进行了一些小测试 
- 完成了totalSummarizer、staticMemoryExtractor的提示词设计
- 更新了 coreModel 的提示词设计，使其聚焦于最新用户，同时做到不同用户的上下文语义隔离、知识共享
- 更新了 MemoryUpdater 中针对多人场景的记忆切片设置 involvedUserId 功能
- 在程序结束时将主动触发 MemoryGraph 的持久化
- 在Config中添加了对于StaticMemoryExtractor的适配
- PersistableObject 移动位置至common包
 2025-05-08 22:26:24 +08:00
slhaf 9e0af5e5aa 推进记忆模块 
- 在 InteractionThreadPoolExecutor 中引入虚拟线程池 (newVirtualThreadPerTaskExecutor)
- 更新相关测试文件以适应新的线程池
- 优化 MemorySummarizer 中的单条目摘要逻辑
- 为 SingleSummarizer 、 MultiSummarizer 设计了提示词
- 还差两份提示词没有设计...
 2025-05-07 21:38:41 +08:00
slhaf 3dd21f840e 推进记忆模块 
- 暂时移除 currentCompressedSessionContext 字段，其功能目前来看与userDialogMap与dialogMap重复，且与当前设想逻辑结合存在困难
- 添加了 dialogMap 更新逻辑
- 添加静态记忆提取功能，在更新单聊、多聊记忆时同步提取(实际运行存在先后，但放到一起了)
- 新增 Model 子类所需的 prompt 待添加
- 主模型相关 prompt 待调整
 2025-05-06 23:09:24 +08:00
slhaf b8b5661d79 推进记忆更新模块以及单智能体多用户相关设计 
- 更新 PreprocessExecutor 以设置用户 ID
- 新增 MetaMessage 类用于封装用户和助手的消息对
- 新增 SessionManager 用于记录独立用户在共享上下文中的聊天记录
- 发现`单智能体多用户`的相关设计问题，已有思路，待解决
 2025-04-29 21:57:07 +08:00
slhaf 40ac6bef03 进行记忆更新相关功能： 
- 实现了长对话中单回复的批量摘要、对话的整体摘要
- 调整了多LLM配置逻辑，初次运行时可选用统一的api,也可以逐个进行配置
- 调整了Memory模块的目录结构，selector与updater明确区分
 2025-04-28 22:58:12 +08:00
slhaf a83cf26f40 - 更新了WebSocket服务器的启动逻辑 
- 发现了agent, websocket, interactionHub之间的循环引用导致IDEA调试出错问题，通过exclude解决
- 实现了CoreModel的execute执行逻辑，并且系统提示词将动态拼接以适应不同模块
- 移动EvaluatedSlice至shared/memory包下，避免层级混淆
- 提取清洗json方法至独立的工具类
- 将agent通过InputReceiver接口暴露至socketServer,而非直接交给其完整实例
- 调整模块加载时机->InteractionHub加载时进行加载
- 调整MemoryGraph中userDialogMap的结构，换用以用户id为主键
- 初步进行测试，记忆更新逻辑暂未实现
 2025-04-25 23:08:01 +08:00
slhaf 4e28adbc52 记忆模块初步完成 
- 为 MemorySlice 添加字段 embedding, embedded 为后续向量匹配提供基础
- 在 PreprocessExecutor 中添加了针对上下文的预填充，现经过记忆模块后，可直接交由主模型进行处理
- 实现了 MemorySelectExtractor, SliceEvaluator, MemorySelector 为主的记忆模块, 并新增了必要的实体类
- 为 MemorySelectExtractor, SliceEvaluator 设计了提示词
 2025-04-23 19:27:11 +08:00