软件工程师罗小东,多年架构和平台设计经验,目前在研究平台与新技术结合中。
回顾
上一篇梳理到我在平台与AIGC的交互的组件设计方案,进行了交互的设计架构,而进一步结合IM整合,将进一步阐述优化交互流程。同时到这步环节引入体验人员来验证LLM对工程师的提升效果,同时体现出超级工程师个体。
体验人员介绍:李小梅,测试工程师,前期有半年的时间跟进学习平台技术,熟悉平台的场景和使用流程。
引入新工程师主要目标是进行过程的交互体验,以更好的验证这个过程,以体现LLM结合对人员能力提升的效果,后期将通过体验结果来进一步形成超级工程师个体。
概述
书接上文。
LLM的推理能力和GC内容生成,为了更进一步的优化和结合多Agent的结合,在这里进行了自定义的GC的交互方式,自定义了一个简单的IM,以便于更好的管理。主要的目标是为了将难用的可视化管理界面进行尽量的规避,统一通过与Agent与员工的交互来进行整体平台的管理,形成类似于ChatOps的工具,但是在LLM上会更强大。
以下为交互管理界面:
在这个过程中,虚拟出多个Agent个体,这里分成了多个团队和多个细化的个体,通过不断的加入群交互,通过小梅工程师的调用和工程师审核,来进一步的完成多个工作结果,比如对虚拟需求团队、虚拟工程师团队、虚拟架构师团队等的管理把控,在不满足的情况下,不断的加入新的工程师来进行交互工作,直到完成一个闭环作业。
以下为虚拟的工程师团队:
这里跟AutoGPT之类的区别在于,这里引入LLM是为了更好的促进超自动化,来解决平时工作中的问题,通过超级个体和Agent角色的结合来完成这个目标,而不是类似于一开始就是完全自动,在这个阶段,我们对LLM的定位依然还是辅助角色。以下为相关的设计思路:
- 定义团队和多个Agent角色分工
- 定义Agent流程和审核方式,交互方式,流程编排
- 多频道(群)和多Agent协作
每个团队的设计思路都有自己的方案,上面是我们在这个过程中的一些实践经验,每个架构师有自己的思维,我有我思。
设计思路
这里的设计并不会有太多复杂的定义,整个过程以解决实践工作问题为主。
定义团队和多个Agent角色分工
为了更好的进行Agent角色的定义,进行多个角色的拆分,拆分的目标是为了更好的聚合,将每一项工作进行细化,形成独立的Agent角色,进而通过多个角色的聚合,形成一个闭环工作。以下是目前细化的团队和Agent,主要包括:
- 人才管理专家团队
- 解决方案架构师团队
- 技术工程师团队
- 数据挖掘分析团队
- 自动化运维管理团队
- 业务运营专家团队
以下为相关设计图:
在形成多个agent之后,调试好Prompt指令,确保结果达到可用或者说可以达到初步讨论的地步,目前还无法做到100%,所以在IM交互上,添加了工程师小梅审核的步骤,审核的意见来源来自于经验的积累和平时的讨论,目前这步暂时先这么处理。
定义Agent流程和审核方式,交互方式,流程编排
在增加到一定的Prompt指令,通过服务和流程编排的形式来进行每个角色的定义,当前以硬编码和自定义节点来处理,流程工具使用的是LiteFlow,暂时没有配置可视化的流程界面,主要的考虑在于定制化的内容较高,前期在研究调试阶段,以定制化编排为主。
以下为数据库设计聚合流程:
这样的交互形式,在某个角度上面,比较容易实现Agent的标准化和准确结果。
多频道(群)和多Agent协作
假设说一个虚拟的角色或者多模态的角色会输出结果,这里可以定义和理解成它就是一个”员工”,这里增加多频道主要是为了更好的在内部分享和结果共享,这样以更好的形成公司组织模式。通过增加频道的方式来进一步的集成多个Agent在工作台上面交互,或者集成多个结果进行交互管理,如下图:
这个过程上一个Agent的结果是下一个Agent的输入,而小梅工程师在这个过程的操作,主要是做审核校验,以确保上下结果的准确性,如果不准确,可微调或者重新生成。同时增加了知识库的交互,比如可以上传某份需求文档或者内容文档,进行更好的内容提取和推理,让AIGC结果更加准确。
总结
这个过程走下来的并不是说特别难设计,只是说新的概念为我们提供了新的思路,比如Agent、超级个体、智能体等,并不会完全搬照,而是针对于实际的问题进行了取舍,有比较多”完美”的想法,也在一步步进行延伸,最终的目标是期望能自我演化,但是怎么做,这还在设计,比如记忆系统,演化系统,成长系统等都需要进一步的定义和设计,前期的目标是能形成超自动化的方向,后期也同步在研究。
也期望有兴趣的同学可以一起讨论,分享经验。