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
150 Commits 9 Branches 9 Tags
a6e33edc7aa1663ca675a95084e7306b7c3f449a
Commit Graph
100 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
slhaf a6e33edc7a refactor(LocalRunnerClient): support remove action temporarily while action is not usable 2025-12-31 16:27:34 +08:00
slhaf 94ef79c67d feat(LocalRunnerClient): support program deletion for DynamicActionMcp 2025-12-31 13:41:35 +08:00
slhaf a222015abb feat(LocalRunnerClient): support program modify and unify action load protocol 
Context:
The method buildModify reuses AsyncToolSpecification building logic in buildLoad.
This feature unifies local action directory protocol, and refactors related logic in buildLoad.
New action directory protocol defines the file names of program and description files.
 2025-12-30 20:52:32 +08:00
slhaf 1c562f0e7b refactor(LocalRunnerClient): update action keys building source in 
DynamicActionMcp

 Context:
 Building action keys by subdirector's name keeps unique identity for each local action.
 2025-12-30 16:43:39 +08:00
slhaf 89535a6b1c feat(LocalRunnerClient): add initial support for loading local action tools from filesystem 
Context:
This feature supports DynamicActionMcpServer.

During initialization, directories containing a program file and a
.meta.json description are scanned and registered as MCP tools.
Tool execution is handled asynchronously via boundedElastic to avoid blocking server threads.
 2025-12-29 20:46:26 +08:00
slhaf 6e90bc8d67 refactor(LocalRunnerClient): co-locate system execution result 2025-12-29 18:53:41 +08:00
slhaf 0e741802d1 refactor(LocalRunnerClient): consolidate MCP client transport params 
Context:
Group HTTP and STDIO transport parameter variants under a sealed internal transport parameter hierarchy.
 2025-12-29 18:48:53 +08:00
slhaf db3435fccf refactor(LocalRunnerClient): co-locate watch service builder internals 
Context:
Group WatchService build interfaces and registry implementation into a
single internal structure for better cohesion.
 2025-12-29 18:40:20 +08:00
slhaf e3294ec302 refactor(LocalRunnerClient): move system execution methods into SystemExecHelper 2025-12-29 18:26:30 +08:00
slhaf bf99e01b51 feat(LocalRunnerClient): introduce LocalWatchServiceHelper and internal implementations 
Context:
This change introduces an internal scaffold to organize WatchEventHandler building logic.
 2025-12-29 17:45:39 +08:00
slhaf 1bd23b20c4 refactor(LocalRunnerClient): introduce DescMcpServer 
Context:
This refactor supports creating descriptional files for common MCP Tools.
 2025-12-29 17:35:03 +08:00
slhaf 442dd55686 refactor(LocalRunnerClient): rename LocalWatchServiceRegistry 2025-12-29 14:27:00 +08:00
slhaf abe5dd5251 chore(idea): update misc.xml 2025-12-26 21:28:10 +08:00
slhaf 1f737c0e29 refactor(action): reorganize constants in action module 2025-12-26 21:28:02 +08:00
slhaf d41074c814 refactor(LocalRunnerClient): replace ActionWatchService with unified watch service builder. 
Context:
ActionWatchService was used to support SCRIPT and PLUGIN type actions loading from local FileSystem, this refactor allows register different paths to watch.
 2025-12-25 15:41:49 +08:00
slhaf 621441601a feat(LocalRunnerClient): correct method signature 2025-12-25 10:20:55 +08:00
slhaf e00d77f076 feat(LocalRunnerClient): add shutdown logic for dynamicActionMcpServer 2025-12-25 10:12:38 +08:00
slhaf d614ac0b15 feat(LocalRunnerClient): support initializing in-process dynamic action MCP Server 2025-12-24 21:36:39 +08:00
slhaf 592e2604d9 refactor(mcp): move InProcessMcpTransport into Partner-Common module 
Context:
Action modules in Partner-Main and SandboxRunner module rely on in-process MCP transport to support dynamically action generating.
 2025-12-24 19:34:04 +08:00
slhaf dcbd2c6569 build(maven): introduce common module 2025-12-24 19:21:53 +08:00
slhaf 476acb0641 refactor(LocalRunnerClient): rename McpServerParams into McpClientTrasnportParams 2025-12-22 15:02:07 +08:00
slhaf 88a14f36b2 refactor(runner): relocate InProcessMcpTransport to experimental and move local MCP client logic into LocalRunnerClient 
Context:
Recent changes blurred the responsibility boundary between RunnerClient and LocalRunnerClient.
This refactor moves local MCP client–specific logic into LocalRunnerClient and isolates InProcessMcpTransport and related code under the experimental package.
RunnerClient only defines indispensable methods and attributes.
 2025-12-22 14:56:23 +08:00
slhaf 05d1fff125 refactor(RunnerClient): remove unused MCP type enum class 2025-12-21 23:03:25 +08:00
slhaf 49a4c9eb01 docs(RunnerClient): add architecture-location comment on RunnerClient 2025-12-21 22:05:46 +08:00
slhaf 9e76c3e7ad refactor(SandboxRunnerClient): align doRun visibility with superclass 2025-12-19 23:34:17 +08:00
slhaf 9762739138 refactor(action): replace HashMap with ConcurrentHashMap for thread-safe MetaAction storage 2025-12-19 23:30:27 +08:00
slhaf 1f5509c17d refactor(RunnerClient): redesign existedMetaActions update strategy 
Context:
Resource-change events cannot reliably represent tool changes.
The previous approach attempted to externalize descriptive content into files, but the meta attribute of McpSchema.Tool can provide this information.
 2025-12-19 23:22:36 +08:00
slhaf ed042cfffa fix(action): correct params type in related DTOs 2025-12-19 22:57:34 +08:00
slhaf 128592e23c chore(MetaActionInfo): remove unused type attribute 2025-12-19 22:47:06 +08:00
slhaf 5ba36ed3e8 feat(LocalRunnerClient): support executing MetaActions via MCP type 2025-12-19 22:29:03 +08:00
slhaf 4dea948f82 refactor(MetaAction): separate key attribute into name and location 
Context:
This change adapts MetaAction locating to support different MetaAction types,
including loading from the local filesystem and from MCP tools.
 2025-12-19 21:35:39 +08:00
slhaf dc4074715e chore(MetaAction): remove unused order attribute 2025-12-19 20:53:01 +08:00
slhaf 225802c1a8 refactor(MetaActionInfo): remove key attribute and update related logic 
Context:
MetaActionInfo was previously located via its own key attribute.
This is now redundant, as ActionCore already uses the key of existedMetaActions
as the single source of truth.
 2025-12-19 20:41:07 +08:00
slhaf e851e33b2e feat(RunnerClient): support MCP type-based dynamic client/server registration 
This allows implementations of RunnerClient to dynamically register different types of MCP service, and also provides a shutdown hook to close client/server properly.
 2025-12-18 22:25:32 +08:00
slhaf cb28a5b068 feat(RunnerClient): add InProcessMcpTransport to support in-process MCP communication 
Context:
This allows RunnerClient implementations to host local MCP servers without spawning another process.
 2025-12-18 21:48:35 +08:00
slhaf ad58567ada chore(deps): introduce mcp dependencies 2025-12-18 17:52:15 +08:00
slhaf 0eee12d685 refactor(MetaActionInfo): remove outdated constructor 
Context:
Previously, MetaActionInfo comes from the local filesystem changes.
But now MCP Servers already provide a method to get information of MetaActions.
The pre- or post-dependencies are still required, for some MCP Tools cannot just be executed without additional context.
 2025-12-18 17:49:52 +08:00
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