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

概述

年度输出规划会偏向于主动表达的意向，主要的目标让更多的人了解一些研究的方向，期望可以认识这方面有兴趣的朋友和交流，共同推进一些愿景，促进交流。

遇到问题

在前期研究和输出的方向偏向于中台或者中台产品化一些设计和在过程中的实践心得，主要遇到的问题比较多，原寄托的解决方案是超自动化理念，想结合类似于自动驾驶的概念，实现是中台自动驾驶的能力，类似于基于中台产品基础设施之上，进一步的实现更简便的落地的能力。

前期的产品化经验，基本上中台达到标准架构，标准接口，从技术、数据、运维、自动化、商务、支撑等几个维度的融合，服务的可折可分的模块化，可减可加的能力。但是依然在落地过程依然需要比较多的经验、架构师、团队、培训等磨合等，落地和建设成本依然较高。即使有一个技术中台，并不代表团队就可以用起来，用好，结合业务、企业方向发挥出能力。

原考虑通过研发中台自动驾驶操作模式进行管理。使该中台可以管理项目和软件的底层基础设施，能在不干涉的情况下生成优化中台。自动根据多年的中台研发和产品化经验，运用经过实践检验和强化的最佳实践来管理和维护中台，特别是优化在最低级别的场景方面。这些工作有助于保护中台，提高基础中台的稳定性和可控性，使中台管理更加自动化和智能化，结合实践过程中的指导和管理的最佳实践。

输出内容

输出部分主要是针对以上问题的解决方向，结合大模型Agent一起，将整个中台进行重新调整，结合未来3-5年的技术，还有AIGC的能力,结合LLM的推理能力，实现更加智能化的中台。

以下是整个架构图:

这里的处理思路是在原来的中台上面加上一层LLM的推理能力，通过Agent来与中台进行交互，中台类似于沙箱，来进行整体的执行。

可以理解成LLM的推理是一个协调的大脑，而执行的操作，视觉，触觉，感知等，由中台来进行收集处理，这部分怡好是技术中台的强项。不断新增加的能力会沉淀到中台(按中台标准化)进行管理和输出，Agent通过上层进行交互管理。

在积累沉淀的Agent和团队实际情况结合，经验以Agent和知识库进行沉淀积累，不断下沉行业的内容，做加法。当然，也可以配置出Agent来不断的自动增加服务能力，比如自动生成代码生成器的插件。规避掉落地的成本，毕竟Agent是可以复制的，角色也是可以复制的。

前期架构于23年搭建，当前整体架构设计已输出一版本，前期做了部分工作，今年的主要的目标是调度和优化交互，还有完善底层各个服务组件的内容。在这个过程中，同步以电子书的形式做为记录。

这个过程以github开源和记录的形式进行内容输出，通过对自动化技术和多Agent协作的探索，希望能进入另一个产品和智能化产品开发时代。此为业余时间研究内容，只为学习使用，暂时不涉及商业性的，后期会跟一些朋友公司进行一些探索和内部团队落地测试，以技术讨论交流为主。

总结

以上为年度输出规划，过程会有细节性的调整，会根据一些交流的意见还有建议等进一步的优化，包括更新，升级等，总体架构基本不变。每个架构师和设计人员都有自己的思路，我有我思，期望可以认识这方面有兴趣的朋友和交流，共同推进一些愿景，促进交流。

个人知识和经验有限，为规避误导，过程以原创和实践操作过为输出的基本要求。

相关地址:

电子书同步开源项目: http://portal.infra.linesno.com

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

回顾

书接上文。

这些的设计都是在有一个基础平台之上，这里并不会过多阐述平台型的建设或者中台型的内容，前期在AIGC交互组件设计上，已经集成了交互的模块。

形成的管理模块已经集成到到几个点:

• 自定义Agent的聊天窗口和多频道设计
• Agent角色的流程化插件化配置，可控化
• Prompt的定义和分离和结果补偿机制

这些交互组件基本上确保了角色之间的交互达到一个比较稳定的状态和结果集可视化的状态，当然，还有一定的优化空间，但并不影响进入下一步Agent角色插件的自定义。

概述

参考集成类k8sGPT的原因只是做一个插件角色的示例，原来的k8sGPT集成较为简单，这里参考设计一个类似的Agent角色，一方面是熟悉了解Agent插件的自定义方式，另一个是方面是与实际的工作中结合，体现出价值性。
这只是一个单Agent角色的角色定义，当中包含多个Prompt的配置和数据接口的提取，多Agent、闭环Agent和复杂Agent暂时不属于本章节内容。

Agent角色的定义从设计维度进行阐述，如下:

• 角色设计: 定义Agent角色和作用，解决场景，Prompt等。
• 数据来源: Agent数据来源的处理，比如API、知识库等。
• 交互模式: 定义角色的交互方式，数据返回的格式等。
• 集成平台: 比如集成预警还有生成相关解决方案文档等。

前期也遇到比较多的设计思路，插件化每个角色都可以定义比较个性化和较强的交互能力，上面是我们在这个过程中的一些设计经验，每个架构师有自己的思维，我有我思。

Agent角色定义

这里角色的定义根据自己工作的性质和内容定义，包括一些流程配置(这里是liteflow框架，并无界面)，角色多跟少由团队自己团队的情况设计，一般来说，都会有比较强的个性化要求，这里设计目标重点还是形成工作闭环或者减轻
一定的重复工作，形成团队和企业自己的Agent能力沉淀，解放上层人力进而可以思考更有价值的事情。

角色设计

定义Agent角色和作用，解决场景，Prompt等。

在这里设计了3个角色，同时注意并不是每个角色都跟LLM交互，理解成一个虚拟的员工或者能做事的角色即可，比如自动化也是一个角色，类似于ChatOps，角色定义如下:

• K8S问题收集Agent: 主要用于收集K8S问题，与数据接口接口进行交互的，这个比较容易理解，只需要分析好问题就可以
• K8S问题分析Agent: 针对获取到的问题分析出结果，然后给出合理的建议和处理脚本等，当然也可以结合知识库来处理，这个看怎么定义
• 问题报告生成Agent: 根据问题处理结果生成报告和每日或者每周运维报告

暂时定义那么多个，当然你也可以定义一个发邮件的Agent，或者说管理的Agent来管理上面的Agent，这里为了确保结果和可控性，会由人工对结果和审核和校验。

在定义好角色之后，再进一步的定义每个角色的Prompt，这里一样返回的是yaml格式方式，便于跟其它的平台进行交互。这里问题分析的Agent解决问题的思路来源于多种方面，比如自定义沉淀的知识库，
使用机器学习获取到的分析结果等，会根据结果和沉淀，还有反馈机制，不断的演化形成更符合团队的处理结果，当然这里属于另一个范围，这里不做过多的阐述。

插件化的机制，可以不断的优化插件和Prompt形成最优化的输出。

数据来源

Agent数据来源的处理，比如API、知识库等。

数据来源的处理参考的是k8sGPT的Analyzer，这里是在原来的k8s管理平台进行的升级，添加了一个分析的模块，提供出api接口，便于插件使用，插件通过参数调用api来获取到结果参考，返回结果解析。

下面是Pod解析的相关代码，原来考虑使用LLM将golang直接转换成java的，但是效果并不是很明显，转换了一部分，然后进行人工改造，跟原来k8sGPT接口有一定的差别。

为了做出交互，暂时接口数据做了一些简化。在插件节点定义的时候，通过http调用接口数据即可，以下是节点的定义。

交互模式

定义角色的交互方式，数据返回的格式等。

交互有一种，一个是Agent之间的交互，另一个是与人的交互。

Agent之间的交互依然是上文的内容是下文的输入，使用yaml来进一步规范的定义格式，如果异常会在Prompt组件进行补偿重试机制，也会有一定的定时监控通知机制。另一个是与人的交互，会相对比较简单，
这里主要参考的是平时工作的模式，考虑是组建一个k8s排查运维的团队，将上面的Agent拉入，专门针对k8s问题运维排查处理的，方便后期agent的复用和其它团队的共享使用。

定义的k8s排查运维团队如下:

可能后期工作过程中，还可能会缺少角色，不断的往上增加即可。下面是交互的情况还有多角色上下文的交互，界面还是简陋了些，后期还会进一步优化。

集成平台

比如集成预警还有生成相关解决方案文档等。

交互的yaml格式化，在集成平台上会相对比较容易，类似于开始的数据来源也是集成平台的一种方式，集成平台的主要目的是方便内部团队第三方IM或者通信，目标是做几个：

• 发送通知给钉钉,让群里直接看到看到word或者Excel结果，达到可评审的目的
• 每周或者每个时间段，给出问题的结果和每日的运维周报或者日报
• 抽取出重要问题事件，形成运维事件进一步的处理
• ……

这个会比较个性化，针对于团队自定义的情况来处理。到这步结束之后，基本上整个Agent角色定义就形成一个阶段，提交插件的代码到基线，通过CICD会自动构建和更新插件，
后期的调试和优化通过调整Prompt或者插件即可。

总结

在插件化和可控化的处理，完成上面的Agent角色与交互，会有比较大的想像空间，比如k8s可以，那SpringBoot程序是否也可以参考(数据通过脱敏组件处理)，只需要定义插件好可集成，在其它的场景下不断加入，形成新的工作模式。
上面是集成简单的Agent的设计和方案，期望给一些同学参考，也期望有兴趣的同学可以一起讨论，分享经验。

鸣谢

这里的设计思路参考以下开源项目:

• AgentGPT: 基于AutoGPT的可视化版，参考其交互UI
• k8sGPT: GPT结合k8s运维工具，参考其处理思路
• Langchain:，LLM框架,参考其架构思想
• Jenkins: CICD工具，参考其插件思路