mirror of
https://github.com/slhaf/Partner.git
synced 2026-05-12 08:43:02 +08:00
推进核心服务与模块注册机制
- 完善Agent流程执行框架 - Api包下新增flow流程包,该部分对应模块的执行流程 - 明确ModuleFactory与CapabilityFactory以及ModuleHook的共同运作流程 - 调整了Hook注解名称
This commit is contained in:
17
README.md
17
README.md
@@ -17,6 +17,13 @@
|
||||
### 针对LLM的'自我引导'机制
|
||||
> 通过特定的交互对话, 引导LLM产生一定的'自我定位'特征, 但似乎大多数模型都不太适合(要么幻觉严重, 要么工具底色太强), 经测试, qwen3系列的qwen-plus-latest、qwen-max-latest比较合适.
|
||||
|
||||
### 基于注解驱动的核心服务与上层模块注册机制
|
||||
结合自定义注解通过反射获取核心服务类,并根据其中的特定方法生成函数路由表.
|
||||
上层模块调用时将通过相应的接口进行调用.接口不需要具备实现类,将通过动态代理进行注入,并在代理内部转发给生成的函数路由表.
|
||||
该部分主要是为了处理原有的`CognitionManager`门面类中每添加一个核心服务就需要增加大量转发方法的问题,通过注解+反射+动态代理,可以实现类似Spring风格的自动注入模式,同时结合`CoordinateManager`,也可以针对不同的核心服务进行协调处理,这时将生成另一个路由表`coordinatedMethodsRouterTable`,它的运作方式与`methodsRouterTable`一样,都会在接口实际调用时进入的代理中被真正执行.
|
||||
> 在添加了这个机制后,实际上还是相当于取消了原CM门面类的作用,而是替换为了`CoordinateManager`充当协调类,仍然通过接口暴露核心能力,但统一转发到两个路由表中进行真正的执行操作.
|
||||
> 这对于上层模块的调用来说,实际上与原来相比改变前后上层模块都不需要关注核心服务的实现逻辑,更多的还是侧重于简化了CM的注册流程吧.
|
||||
|
||||
## 模块(已实现/正在实现)
|
||||
- 预处理模块: `PreprocessExecutor`
|
||||
- 后处理模块: `PostprocessExecutor`
|
||||
@@ -39,12 +46,12 @@
|
||||
|
||||
## 规划
|
||||
|
||||
- [ ] 调整模块加载机制,将记忆模块以及后续的任务调度模块作为不可替换的核心模块,但允许在主模块与前后模块之间添加新的模块。
|
||||
- [ ] 实现流式输出,同时在各模块执行时可向客户端返回回调信息,优化使用体验。(现在用的是`websocket`与客户端通信, 应该实现这点会简单些)
|
||||
- [ ] 服务端与客户端的通信加上消息队列,防止消息因连接断开而丢失。
|
||||
- [ ] 实现角色演进机制
|
||||
- [ ] 实现任务调度模块(主动调度、意图推断、定时调度)
|
||||
- [ ] 完善注解驱动的注册机制
|
||||
- [ ] 实现任务与主动调度模块,目前打算用 `时间轮算法` 实现定时操作
|
||||
- [ ] 服务端与客户端的通信加上消息队列,防止消息因连接断开而丢失。
|
||||
- [ ] 实现流式输出,同时在各模块执行时可向客户端返回回调信息,优化使用体验。(现在用的是`websocket`与客户端通信, 应该实现这点会简单些)
|
||||
- [ ] 实现角色演进机制
|
||||
- [ ] 调整模块加载机制,将记忆模块以及后续的任务调度模块作为不可替换的核心模块,但允许在主模块与前后模块之间添加新的模块。
|
||||
- [ ] 踩坑。
|
||||
|
||||
## License
|
||||
|
||||
Reference in New Issue
Block a user