软件工程师罗小东，多年架构和平台设计经验，目前在研究平台与新技术结合中。

回顾

上一篇梳理到我在平台与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、超级个体、智能体等，并不会完全搬照，而是针对于实际的问题进行了取舍，有比较多”完美”的想法，也在一步步进行延伸，最终的目标是期望能自我演化，但是怎么做，这还在设计，比如记忆系统，演化系统，成长系统等都需要进一步的定义和设计，前期的目标是能形成超自动化的方向，后期也同步在研究。

也期望有兴趣的同学可以一起讨论，分享经验。