slhafzjw 1d315a9b62 ActionExecutor 的执行流程规划完毕，具体逻辑待填充 ...

- 调整了部分代码分布，移除了某些非必需的转发方法
- 新增几个 TODO 内容，后续工作已明确

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

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

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

不过谁知道呢，也许以后也会变，但这套至少现在看来是更能实现理想行为的

2025-12-01 19:25:21 +08:00

..

data/log

推进 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

src

ActionExecutor 的执行流程规划完毕，具体逻辑待填充

2025-12-01 19:25:21 +08:00

dependency-reduced-pom.xml

开始推进行动模块(ActionModule); 针对框架与本体分别进行了一系列架构优化。

2025-10-12 16:23:11 +08:00

pom.xml

推进 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