|
|
4b852e0049
|
推进 ActionExecutor 下的‘行动生成与执行’部分
- 新增 RunnerClient 抽象类，并划分 SandboxRunnerClient、LocalRunnerClient两个子类(内容待完善)。前者负责对接 SandboxRunner 模块，后者直接使用本地作为执行环境(但不推荐)。
- 将 ActionWatchService 划为 LocalRunnerClient 的内部类，负责采用本地执行环境时，监听行动程序变化
- 完善 ActionRepairer 处的修复逻辑
- 调整 MetaAction 中路径获取逻辑
这提交方式真该调整一下了，这阶段推进容易攒太多，但又不好停手。或许阶段目标可以保留，但推进点应该可以细化🤔
|
2025-12-15 21:54:24 +08:00 |
|
|
|
6e3deced77
|
推进 ActionExecutor 下的 DynamicActionGenerator 子模块
- 完善了 DynamicActionGenerator 的大致逻辑，序列化逻辑待实现
- 补充了 PhaserRecord 中的阻塞逻辑，使用普通的线程sleep操作
- 调整了 MetaAction 中参数形式，由列表替换为 Map,便于执行时填写参数
- 完善了 DynamicActionGenerator 相关的数据类
|
2025-12-07 20:10:53 +08:00 |
|
|
|
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 |
|
|
|
ad973d4230
|
对 ActionExecutor 下子模块的功能分布、某些实体类进行了调整; 完善了 ActionExecutor 中的大致执行逻辑
- 梳理执行链路时发现 ActionRepairer 的能力明显超出可实现边界，故将其能力进行限定
- 新增 ActionCorrector 负责单组行动执行完毕后，根据意图和执行状况进行行动链修正
- 将 PhaserRecord 拆分为独立实体，未来将封装一部分流程控制逻辑
|
2025-12-02 22:35:53 +08:00 |
|
|
|
1d315a9b62
|
ActionExecutor 的执行流程规划完毕，具体逻辑待填充
- 调整了部分代码分布，移除了某些非必需的转发方法
- 新增几个 TODO 内容，后续工作已明确
这套调度方式看起来真的有些‘探索性质’了。实际上看起来有些像把 ReAct 的逻辑显式地进行了工程实现，不管是修复、依据状态选择行动单元生成还是阶段间针对行动单元的参数提取，在 ReAct Agent 中都是由一个智能体完成的。
但在这里，它要做的事情太多了，再加上 Partner 行动链的干预逻辑、幻觉参数又不可接受所以需要自对话或者用户干预，这些东西交给一个 ReAct 模块恐怕并不合适也不放心。所以这种显式模块划分应该更符合 Partner 行动模块的需求。
这点硬要说的话，应该还是在于‘ReAct 行为’并非 Partner 的全部吧。
不过谁知道呢，也许以后也会变，但这套至少现在看来是更能实现理想行为的
|
2025-12-01 19:25:21 +08:00 |
|
|
|
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 |
|
|
|
3f59719e16
|
调整 MetaAction 的执行方式，将交给 ActionCapability、SandBoxRunnerClient 执行
|
2025-11-30 22:16:57 +08:00 |
|
|
|
c548cceec6
|
新增 SandboxRunner 项目子模块，该模块将在指定容器运行持久服务，与外部主进程通信，将用于后续执行JAR、SCRIPT两类行动类型
|
2025-11-30 18:41:42 +08:00 |
|
|
|
b3098310b4
|
完善了 ActionConfirmer 的遗漏逻辑
|
2025-11-30 15:16:57 +08:00 |
|
|
|
f48d559a7b
|
调整了 ActionInterventor 中数据构建方法的组织方式
|
2025-11-30 14:38:50 +08:00 |
|
|
|
14a57f0be6
|
推进行动干预模块,前置部分逻辑已基本完成
- 在`ActionData`中添加必要注释、新增`executingStage`字段表示当前执行阶段、移除了`WAITING`的状态类型
- 调整并修正了`ActionExecutor`中的`Phaser`阻塞逻辑
- 完善了`ActionInterventor`中`识别 -> 评估 -> 异步执行`的干预逻辑，并将干预结果以 Prompt 形式回写至流程上下文，作为主模块的已知内容
- 调整了干预模块内部的各个数据类的字段结构，适配干预流程
- 完善了`InterventionEvaluator`、`InterventionHandler`、`InterventionRecognizer`等必需的干预子模块
|
2025-11-29 20:56:29 +08:00 |
|
|
|
dff7b69b51
|
更新 README
|
2025-11-12 19:53:48 +08:00 |
|
|
|
d77ffd1db6
|
Merge remote-tracking branch 'origin/doc/architechture' into doc/architechture
|
2025-11-11 16:51:18 +08:00 |
|
|
|
264cdb09e5
|
推进行动干预模块; 接下来将进一步完善 InterventionHandler 的具体内容
- 调整相关目录为 interventor
- 调整了某些 ActionInterventor 的子模块用到的数据类结构
- 完善了 InterventionEvaluator 的具体逻辑
- 为 InterventionType 添加了注释，并新增了 CANCEL 干预类型
|
2025-11-11 16:11:09 +08:00 |
|
|
|
fea7f9c81f
|
PerceiveSelector、PeiceiveUpdater 流程图制作完毕
|
2025-11-11 08:47:21 +08:00 |
|
|
|
a1520f117b
|
推进行动干预模块
- 完善了 ActionInterventor 中的具体逻辑以及不同情况下的prompt填充内容;
- 调整了 PreRunningModule 中的 getPromptDataMap 方法;
- 在 ActionCapability 中新增了检查 actionKey 是否存在的逻辑
|
2025-11-10 23:02:48 +08:00 |
|
|
|
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 |
|
|
|
c3ca4145b8
|
推进行动干预模块
- 完善了大致的执行流程
- 明确并创建了评估与处理所需的数据类及干预类型
- 不同情况的Prompt处理结果、评估和处理的具体流程需要进一步完善
|
2025-11-06 22:07:27 +08:00 |
|
|
|
5419722c40
|
更新文档内容
|
2025-11-06 11:17:25 +08:00 |
|
|
|
31ebee3ded
|
制作了整体流程图
|
2025-11-06 11:14:37 +08:00 |
|
|
|
746fda1a5e
|
干预意图提取模块初步完成，Prompt 待制定; 在 ChatClient 中添加了默认的超时设定，超时时间后续可能需要调整。
另: 发现很多细节错误，比如“各个后置模块允许执行的条件”、“主模块出现异常时需要如何处理”、“模块Prompt的构建方式、采用格式不统一”等，需要后续进行修复或调整
|
2025-10-31 21:26:45 +08:00 |
|
|
|
ec4fbb7f19
|
行动干预足以抽离为新的前置模块，但仍属于‘行动’语义，大致框架已确立。后续实现时并发控制、各种干预的协调与触发时机需要注意。
|
2025-10-31 21:26:45 +08:00 |
|
|
|
f9c3cacfea
|
推进 ActionExecutor 相关的动态插拔式行动调度机制
- 移除先前构想的 SpecializedPartnerInputData 及相关类，无论是自反思、向用户求助还是用户主动干预，都应当通过语义识别来作用于对应行动事件，使用固定行动id的机制不足以支撑这种机制
- 在 ActionCore 中新增执行中行动的 phaser 管理逻辑
- 新增几个异常类，适用于行动数据加载的异常情况
- 新增 ActionIdentifier 负责行动干预意图的识别
-
|
2025-10-31 21:25:12 +08:00 |
|
|
|
e35e18f3b7
|
推进 ActionExecutor、确定动态插拔式行动调度的实现思路
- 在 ActionCore 中添加关闭hook,用于正确设置异常中断时执行中任务的状态
- 修正 actionPool 相关注释及用法
- 将 ActionData 中行动链字段调整为 LinkedHashMap 用于更好地支持分组并发及动态调度
- 重构 ActionExecutor 行动链执行逻辑，采用 Phaser 支持动态调度
- 扩展 InputData、Context 字段并调整 GateWay 格式化逻辑以适应特殊输入
|
2025-10-31 21:25:12 +08:00 |
|
|
|
83832d2060
|
推进 ActionExecutor、针对action core做出了一些调整
- 将 ActionWatchService 抽取为独立的类，使用构造参数传递所需内容
- ActionCore 中除了pendingAction外，将只维护一个行动池，通过用户键和STATUS区分类型
- 开始推进 ActionExecutor，但其中的同组并发、动态行动链、行动间参数对齐、参数重构等内容需要仔细考虑
|
2025-10-31 21:25:12 +08:00 |
|
|
|
4757425a15
|
推进 ActionDispatcher 模块、完善行动程序规范与加载逻辑
- 明确行动程序的存储形式与加载规则，分为执行程序和描述文件，前者负责逻辑，后者提供必要的描述性信息;
- 将 ActionInfo 重命名为 ActionData，更新相关接口和实现，增强代码一致性和可读性；
- 添加异常处理类以支持行动程序、描述信息的初始化和加载失败的场景；
- 实现行动程序目录的监控功能，支持行动程序的动态加载与管理;
- 明确了 ActionDispatcher 两个子模块的输入输出规范
|
2025-10-31 21:25:12 +08:00 |
|
|
|
21b3a0e846
|
开始推进 ActionDispatcher 模块
- ActionDispatcher 划分为 ActionScheduler 和 ActionExecutor 两个子模块，分别负责处理计划任务和即时任务
- 正式确定 Action 将以 ActionChain 的形式进行执行，也采用同组并发策略，按照 order 字段在 chain 中进行排序
- 调整了 ActionInfo 等类以适应当前的元行动类
- 对于行动能力的支持，或可考虑这几种方式: Agent自生成python脚本(必须经过验证，确认可执行且无风险)、MCP调用(需适配为Partner所支持的形式)、普通插件(在指定目录动态加载)
|
2025-10-31 21:25:12 +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 |
|
