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

回顾

书接上文。

这些的设计都是在有一个基础平台之上，这里并不会过多阐述平台型的建设或者中台型的内容，前期在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工具，参考其插件思路

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

回顾

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

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

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

概述

临时记录的笔记，表达中可能会略带有一些口语化，同时注意此版本平台还在研发调试中。

这里阐述以平台运营为主，这里假设说已经有一个平台，包括技术、数据、运维、管理、运营等基础设施的能力。

这个设计原来主要的问题是超自动化的提升，结合LLM为了更好的实现，在这个过程中，也包含了一些自主的感知和学习的能力，带有智能体的一定的特征。在前期的研究中也是不断的查看和摸索了很多的开源项目，包括一出来就热门的Github项目，但在使用遇到的情况更多的是还只是属于一些例子或者带有很多不稳定因素,并没有说见到能达到较稳定的层面。

在这个过程中也发现，GPT的交互过程中，涉及到的问题也很多，比如最直接的是内容生成的发散性太强，接口费用太高，返回内容不准确，还有数据提交过去产生的安全性问题，接口响应时间等问题，实际中见到运用得最多的是知识库，LLM+数据源(向量库/其它loader库)，比如langchain。针对于平台层来说，内容的不稳定还有交互不明确，数据安全性等，这些基本上就完全无法接入平台服务，试想，使用过程中突然有一个不稳定的因素，上层业务运行容易一片雪崩。

针对于前期的整合过程，做了一定的处理，以尽量减少和达到可用的目的，下面交互的架构图：

这里从几个点来进行阐述，前期研究中的一些交互设计思路和过程思路：

• 增加和调整平台的一些规范要求
• 结合AIGC进行的平台多场景Agent设计
• 支撑交互的服务组件建设设计

在此过程中的多方调试，为了更好的进行交互设计，针对于Prompt的编写上制定了一定的规范，还有平台的工程上面也做了一定的适配调整，我有我思。

处理方案

主要是针对于前期运营平台过程中的一部分自动化处理方案，当然场景还在挖掘，比如当前团队的培训就是使用上面的交互流程来培训，以提高团队能力而进一步提高平台在实际中的落地。

调整的一些规范要求

这里的规范性指的可能很多，这里主要是当前做的一些内容，可能还不全，也在调试和挖掘场景中。主要包括：

• 整体服务之间接口的规范，这个是遗留问题，涉及到的服务有的基本上要提供出可调用执行的api接口，比如k8s发布接口
• 服务之间交互需要增加一层adapter层，这个类似于DDD工程结构里面的基础设计层，作用类似
• 所有涉及到AIGC的交互，全部使用yaml格式来进行，同时要最小参数来生成结果，表达越简单越清晰越好。

以上服务调整的规范和提供能力，主要是为了更好的进行后期的交互，这里指的是所有的平台服务（包括技术、数据、运维),有一些自动化运维比如ansible或者k8s发布可能没有接口，可以结合第三方，比如jenkins来提供API以执行服务。

adapter层是针对于第三方交互的时候调用的，也是为了给AIGC服务调用的解析模板能力，这层目前还在适配，往往可能很多时候还是空的，做到的时候，统一通过这层进行交互对接处理。

使用yaml来交互的原因主要是上面提到的准确性的问题，在调试过程中发现，GPT结合yaml生成出来结果准确性基本上很高，没见到有哪些错误，甚至它还能帮你处理错误，这推理也是比较好.

比如下面的培训试题：

这个Prompt生成出来的试题准确程度还是比较高，除了见过一两次接口生成的时候不完整，基本上没见到错误，后续还继续观察，至少得到一定的准确比例。另一个原因是交互的数据提交问题，并不想提交太多数据以规避token的成本，只需要针对提交的参数，获取到清洗出来的数据即可，同时一些数据增加了脱敏的处理。

结合AIGC进行的平台多场景Agent设计

这里交互的方式主要是使用很多Agent，也可以理解成专家，这些专家的目的是完成每一项目过程中的任务，也就是将原来一些手工处理的或者需要人工处理的，交由Agent来处理，比如刚刚提到的知识库，这也是一种解答的专家。

不同的场景针有一不同的专家来调用Prompt的服务，来获取到结果，可能调用一个或者多个，通过多线程进行结果的整合，类似于MapReduce一样的，这个不是很难处理，之前也有考虑工作流，这样一个流程可能就是一个专家。我们并没有使用langchian，主要是在使用过程中发现，可能调用服务和管理数据，会更可控。

在处理完成之后，返回的结果会针对于每个专家设定的角色去调用相应的服务实现，每个服务实现针对于yaml结果进行解析，然后调用本服务能力，比如发送邮件之类的，或者说数据抽取。这里如果用过DataX的同学可能就会比较理解，DataX在做数据抽取的时候，使用的是一个json文件，我们的目标也就是生成类似的文件，用于更好的做交互，这个生成对LLM来说，难度并不高。

最后便是结果的通知和整合情况，这里IM工具比较多，专家也可以做成接口服务，放到IM工具里面，比如在钉钉里面设置多个机器人，这样组合起来的ChatOps能力就更强一些，我们目前正在调度这几步，目前还没有调试到对话的程度，目前也在考虑这块。

数据来源的问题，每个Agent针对于特定的场景，在交互中数据的来源也是比较明确的，一个是向量库，另一个是数据服务，这两个可以理解成GPT的记忆能力库，会在交互过程中，进行记录分析，然后再进一步的将结果反馈，从而下一步调用的时候，GPT返回更加专业或者达到经验积累的目标，原来的考虑是类似于自我演化的系统，这也是在调试，这步也包含上面说的对话调试，当然效果上还没有达到预期。

支撑交互的服务组件设计

交互组件是以服务的形式的提供，即微服务的形式进行管理，每个是单独的服务，便于后期的共用或者单独使用。下面是服务的截图：

在这里为了更好的达到交互的目标，设计了几个服务组件，主要是:

• 推理服务：这个主要是对于基础层的Prompt工程管理，还有模板内容解析，还有一些向量库，总的目标来说就是管理Prompt工程
• 助理服务: 这个主要是对于Agent而言，也就是专家，每个场景的专家会调用推理服务的一个或者多个Prompt接口中获取到结果，并提供出yaml交互
• 脱敏服务：这个会比较好理解，主要是针对于一些敏感词和或者一些内部数据做的脱敏，回来之后在助理服务进行置换

服务化的另一个考虑是针对于LLM来说，是一个可拔插的东西，在不需要的时候，不部署或者这些服务即可，比如针对一些比较感触的团队。

总结

上面便是平台在前期AIGC交互中的一些探索和处理方式，在这个过程中想像空间还是比较大，能挖掘的场景也是比较多，目前发现的很多人工处理部分是可以使用自动化来替换的，比如刚刚提到的团队培训，后期便可形成梯队模式和定向培养，在这个过程中验证的效果大部分还是达到预期。这些也在之前的GDG活动中做过一些分享，这里表达得更加细化，也期望可以给做这方面的同学一些参考，也欢迎提供更好的思路和经验。

软件工程师罗小东，多年平台架构和落地经验，在与社区团队研究超自动化方面的设计和产品方向。

背景

以下是针对超化管理超化的设计，因此会偏向技术方向的阐述。

目前对于超化的关注点似乎更多集中在方法论方面，而较少关注具体实现，目前仍处于探索阶段。我们的编码工作目前在 Github 上进行，以便与对这个领域感兴趣的同学进行更好的交流。

在进行超自动化研究的过程中，我们遇到了数据采集的问题。在上层自动化过程中，需要大量的数据支持，因此需要采集大量内容。由于缺乏业务场景，我们在这方面的研究考虑是先使用超自动化来管理超自动化（即自己管理自己）。这里主要针对日志采集设计。

概述

我们原来的整体设计方向是朝着数据支持方面发展的。根据一定的规则和判断条件，结合 AGI（人工通用智能）的推理判断，形成智能化的操作。在日志的采集和管理方面，我们需要采集完整的数据链，进行判断、管理和预测。在确定采集哪些数据时，我们参考了许多开源项目，但也发现了一些问题。各个开源项目过于分散，无法形成组合，数据分离也比较麻烦。另外，技术迭代速度较快，有些项目没有很好地跟进。综合考虑后，我们需要进行部分重写和整合。这里主要采集的内容包括：

• 前端日志：包括 UI 事件、访问日志、操作日志、热点日志和 IO 日志等。
• 自动化日志：镜像日志、构建日志、过程日志和操作日志。
• 安全日志：代码、质量、版本、漏洞安全、容器漏洞、密钥日志和 Git 提交日志等。
• 应用日志：运行日志、运行状态、请求日志、运行情况和链路情况等。
• 系统日志：操作日志、历史日志、IO 日志、网络日志、请求情况和运行情况等。
• 操作日志：操作记录、SQL 操作和审计操作等。
• 登录日志：登录的所有信息和请求，例如 IP、地点、位置和账号等。
• 项目日志：任务操作日志、变更日志、审计日志、人员变动和状态变更等。
• 链路追踪：请求链路、操作链路、日志链路、SQL 链路和阶段链路等。
• …

这只是初步设计，后期还会继续添加。目前按照上述设计进行集成，采集回来的数据使用流水线方式进行判断和处理。在这个过程中，我们主要使用了 GPT 的推理结果作为推理能力的基础。当前的原则是尽量使用流水线和自动化，在特定阶段使用 GPT 的能力作为辅助，以提高过程的稳定性。实现的超化能力演化效果类似于以下示例：

• 在云服务器准备到期时，自动采购或续费。
• 当功能准备延期时，自动通知并向指定人员提供合理建议的方案。
• 每月或每周自动生成报告结果，并给出合理的建议。
• 自动检测和构建验证过程中的漏洞，并生成分支。
• …

在这些过程中，我们使用规则和推理能力进行简单的判断，协调这些自动化流水线，类似于自动驾驶，但也有辅助驾驶，推理能力就是这个协调的大脑。为了实现更便捷的操作，我们还添加了语音交互，以便更好地进行操作，并将结果通过 SSE 推送到系统界面或进行语音播报。

下面是当前设计的整合思路，这仅涉及日志采集方面的设计，其他自动化内容不包含在其中，我有自己的思路。

过程设计

相对而言，采集的设计是相对简单的。目前有许多开源工具可用，但搭建起来可能需要较长时间。然而，由于 AIGC（人工智能生成代码）的能力，我们可以使用生成式代码和单元测试，效果还是不错的。

采集工具

我们的采集工具主要使用了一些开源工具，并结合了 Maven、Shell 和自研的流水线进行改进。在选择工具时，我们考虑了定制化的需求，并综合考虑后决定自行开发。下面是我们主要使用的采集技术：

• 前端采集：log.js、filebeat 和 nginx。
• 自动化采集：Python + shell，并将数据发送到 Webhook。
• 安全日志采集：Trivy、Checkstyle、Murphysec、SpotBugs、Gitleaks 等工具。
• 应用日志采集：自定义的 logback、OpenTelemetry、AOP、Nginx 等。
• 系统日志采集：Ansible、Shell、Python，定时采集结果并结合 node-exporter 返回。
• 操作日志采集：AOP 和自定义的 logback，自定义的 MDC 参数。
• 登录日志采集：Nginx、AOP 等。
• 项目日志采集：通过调用 API 进行定时采集，并有一些会接收推送结果（例如禅道）。
• 链路追踪采集：OpenTelemetry 和 agent 的方式。

对于数据量较大的情况，我们使用 Kafka 作为数据缓冲。为了方便交互和安全性，我们在 Kafka 前面加了一层控制器层，提供了 HTTP 接口，并使用自定义的令牌进行拦截。目前还在研究过程中，尚未添加 HTTPS。

有些 Webhook 提供的是一个前端系统，例如 Spring Boot 应用或 gRPC 应用，它们接收数据后将其输入到数据仓库中。我们使用 ClickHouse 作为数据仓库，因为它能够保存多种数据结构。一些日志会在实时计算后保存到数据仓库中，另一部分会使用数据进行离线计算。我们对 ds 的 2.0 版本进行了二次开发，以适应当前的工程结构并更好地维护。

维护平台

采集之后，并不仅仅是结束了。我们还设计了几个平台来管理数据，以应对不同的应用场景。这些平台类似于数据的前端和展示，便于管理过程流程跟进，并提供更好的可视化。我们基于 Ruoyi-Plus 进行了改造，主要产出了以下平台，便于维护管理，比如自动操作服务、安全感知服务、持续集成服务、日志审计服务、容器管理服务、监控预警服务、链路追踪服务等。

这些服务功能主要是在数据上展示和管理，便于超自动化的管理。一些数据来源于 ODS 层和 ADS 层，目前的流水线集成还在 GitHub Actions 上，但数据应该已经采集到了。后续需要进行验证，并进行多个自动化流水线的验证处理。这个过程可能需要进行调试，当前的功能点已经规划和编码产出。

总结

以上是我们在研究超自动化过程中关于日志处理的思路和结构。目前还在进行调试和验证。除了日志的自动化处理，还有其他方面需要结合超自动化，例如项目管理、产品市场营销、流水线自动生成等。希望对从事这方面的同学提供一些经验参考。

鸣谢

在处理日志的过程中，我们参考了一些产品，主要包括以下内容：

• GitHub Security 服务
• 阿里云分布式链路
• AnsibleTower 自动化操作
• ELK 套件
• PlumeLog 开源日志工具

软件工程师罗小东，多年平台架构和落地经验，大模型的出现让通用型AI成为一种可能，针对数字化和平台化的结合一直在考虑整合点，让超级自动化方面落地更成为可能。

注意这里假设部分材料可以公开，数据隐私性不强的情况下的设计运用，比如规范

概念

相关数字中台概念，可以参考我为什么觉得数字中台是团队的新型基础设施，这里不做过多阐述。

背景

整个研究的目标点是为了针对于数字中台层级的超级自动化，这个是在继Ops架构体系之后的一个突破点，前两年在Ops架构突发和成熟，比如DevOps/GitOps/DataOps/AIOps等体系（这里不涉及AIOps架构)，在某个方面已经具备一定的自动能力，进而发展出数字中台的基础设施能力。

研究超级自动化的时间应该是在20年左右，前期在Ops上已经实践多年，一直想找更优的突破点，而且Ops模型体系也已经有了标准和完善，不管在微服务、中台技术、运维、数据治理上，这些都已经集成了自动化和流水线的能力，开源的产品也比较多，但是在超级自动化和数字中台整合方面上，目前市场和概念的意识还不够成熟。前期也研究过一段时间AI能力融入，但是多方面的限制，始终无法得到比较好的效果，而大模型(GPT)的出现，貌似把这超级自动化都变成了可能。

这里主要以落地结合实际为参考，基于数字中台基础设施上的进一步架构设计，从能力提升过程为维度进行阐述：

• 微服务和DevOps架构能力提升
• 数据治理能力的能力提升
• 服务治理和运维架构能力的提升

结合起来的建设的思路依然是大平台、轻中台、小前台，整合思路设计思路如下:

• 建立完整的规范文档，自定义大量的prompt前置库
• PromptOps(参考Ops)流水线体系的建设
• 结合数字中台多产品线的融入和落地

这里的大平台进一步的下沉和强化新型基础设施的概念和能力，更为突出层级的划分和固化，这个是以GPT模型为能力设计，整体设计是基于有完善的数字中台基础设施的能力上进行，这里主要给出参考，这里只是针对问题和解决问题思路来进行说明，也是后期落地和建设的方面，经验不一，我有我思。

过程问题

这也是结合使用过程发现的一个特别大的问题点，规范化和完善基础设施是条件之一，而利用GPT的结合推荐，Prompt生成的整合，也是基于这个规范和基础设计为主，而更好的结合实际，而不是仅仅参考，更多的是运用，这个主要会更利于人员的成长和往更高一层的思考，将人的精力和学习能力更加的提升，这对于很多中小团队来说是致命的成本硬伤，以下是AIGC和数字中台结合的整体架构：

目前主要设计到的超级自动化上构建专家体系、自动化体系等。

微服务和DevOps架构能力提升

有工具和会用是另一回事，在成熟的前提上更进一步提升

这个可能是一个老生的话题，在过去的实践中还有目前行业的发展中，这个是工程结构的基础，也是面对于解决系统和架构问题的进一步架构提升，在业务和各个组件能力上，规范上，还有基础技术上的统一化和规范化等。解决这部分的能力，主要是在于后期服务治理能力、业务工程结构能力、还有自定义业务创新（或者说自研）业务上提供一定的保障。

前期在这块上体现可提升或者进一步需要优化的部分，过程遇到的体现在几个方面：

• 工程结构的规范、编码能力、基础编码优化等，比如针对于几百个规范和文档编写；
• 技术债成本高，涉及过多的概述和技术，比如往往需要多方面人才的指导才可以完整走下；
• 多组件沟通困难，针对于大量的组件和技术整合架构不够明确，比如场景无法更好的结合组件做架构
• 结合解决方案困难，无法针对现有的能力，更好的组合出更好的解决方案，比如往往会出现很多轮子
• 技术问题解决思路，这个成本较高，比如一般初中级工程师无法提出针对性的技术思路
• 产品和市场信息产生偏差，无法形成合力，比如你做你的方案，我找我找方案
• ……

针对于以上种种，可能临时可以解决或者”总会找到人”，但是这个如果项目PM在工时和项目经验上，做过精打细算经验的会发现，会有一种温水煮青蛙的感觉，无形中流失很多时间和问题在非业务功能需求上，虽然说在前期的基础架构上这些问题好像已经有规划和处理，但是在很多时候，自己一直得不到满意的效果（即使管理流程和组织架构上做优化），还是感觉这一步是可以进一步优化。

主要是构建专家体系、文档体系、规范体系、学习体系，而原来的组织结构会进一步调整和优化，从而更专注于业务场景需求和创新方面，培养业务专家体系(当然业务专家也可以结合，这里不做阐述)，集中精力在更具备价值的地方，在多个方面更好的实现业务能力和创新。

数据治理能力的能力提升

数据分析和挖掘会更一步精简化，更专注于数据运营效果

在应用采集的数据挖掘能力上，GPT基本上比较容易整合，对于数据多层级的划分，如ODS/DWD/APS等这些在前期使用过程中，基本上针对于系统会针对性的出一版本，这部分的处理一些方案和方向上已经达到，这里不做过多的阐述，得益于SQL规范上，指定一定的指标分析过程，只需要更好的结构好模型，做出模型投喂等，出来的指标一般来极具参数性的，这类型的可以参考Chat2DB，PhotoShop等，这部分的数据分析可能正向推、或者反向推都可以。

前期在这块上体现的一些问题点：

• 数据维度分析、指标分析，这块上需要较长的周期，无法快速给出参考，需要投入特定人员，比如一些初级的分析
• 数据计算上SQL编写，无法和现有模型较好的整合，有一定的技术复杂度，比如kafka/flink/hive/clickhouse等
• 人员培训成本上，技术和数据概述有差异，过程需要特定的数据人员指导全程指导
• 技术债成本高，涉及过多的概述和技术，业务、技术和数据的结合沟通成本上较高，比如数据总线概念和消息概念不一样，但是技术操作上可能是一样；
• ……

另一个是在数据生成API上，也一样针对于第一章节提到的规范可以进一步推出。比如一个简单的实时例子，在维度分析和指标分析上，会结合模型自动生成，同时另一个是也会输出FlinkSQL，这个往数据开发工具上复制和调试即可（目前是这么处理）。

主要是构建专家体系、文档体系、规范体系、学习体系，从而更专注于数据挖掘场景需求和创新方面，在多个方面更好的实现业务能力和创新。

另一个是数据分级、元数据、主数据的分析的抽取上，数据清洗、元数据管理、数据模型管理等流程化的工作，这些都有比较好的能力整合，结合模型训练基本上会更合适（如基础的数据模型算法）。

注意数据涉密的问题，这里只做模型提交处理，而且需要客户沟通

新一代的AI技术，让此类工作门槛大幅降低，数据分析不再成为一个难点，针对一般型的项目基本上是可以直接套过来，通过自然语言快速建表，包括自动生成维度表、建立范式模型和星型模型、自动分析表之间的逻辑关系、甚至提供建模建议，生成一定的SQL和脚本，更快的进行数据采集分析。

服务治理和运维架构能力的提升

自动运维能力的提升，更快速提供服务运维质量和范围

这里的运维包括监控、管理、安全、自动化等，自己一直在研究和运用的更多的是ChatOPS，以钉钉一类为代表的工具，一个是信息的交互，另一个是主动推送信息，这部分在某种模型上，会比较成熟，不过在运用上还是比较不得意，大部分是集成中通知和互相上，集成起来的能力点是极度有限的，是在现有的工具模型上做的API，然后结合各个服务能力进行一个窗口型的交互。

出于几方面的处理，很多方面是webhook/定时/api几个方面的能力结合，而这些操作过于通用而带来一定的限制，主要在几个方面：

• webhook能力有限，需要定制很多api来结合，机器人的结合，缺少推理的能力，在这块上学习成本和场景上依然会有很大的限制
• 技术债成本高，涉及过多的概述和技术，业务、技术和数据的结合沟通成本上较高，学习成本很高；
• 技术问题解决思路，这个成本较高，比如一般初中级工程师有些可能根本无法接过自动化运维这个内容
• 运维和数据挖掘的结合目前缺少一定的方案，技术方案突破存在一定的瓶颈，需要研究的成本很大
• 问题解决过程需要关联大量的基础设施信息，这个结合的成本需要特别熟悉的工程师才可以处理
• 问题分析模型创建困难，在海量的运维数据中，需要高级算法工程师和计算人员才可以，中小团队招人成本极高
• 运维/技术/数据整合起来困难，无法形成一体化的结合的能力，形成运维/技术/数据各个层级孤岛
• 相关过程问题沉淀效果不理想，重复问题参考效果未必能达到预期
• ……

前期一直有计划结合AI能力来处理这个，需要突破很多限制和成本，这对于中小团队来说，不管是精力还是人才，基本上会有很难的实现，特别是需要特别资深的工程师，而且甚至有可能做到半效果不理解，然后走到黑或者走到放弃的层面。

同样是构建专家体系、文档体系、规范体系、客服体系，在处理上更专注于稳定性和健壮性，提升问题预知和安全感知能力，促进业务的稳定性。确保系统、设备、应用程序等IT资源运转正常，并维护它们的高可用性和可靠性。运维人员通过对软件、硬件、网络等的监控、维护、检修、升级等工作来保证系统的稳定性和完整性。

整合思路

这里能这么做的主要利益于数字中台的规范性和完整的基础设施能力提供，稳定和成熟的中台体系。这个是针对原有的平台化的升级优化，而不是重构或者重建之类的，这个过程是没有必要的，应该来说以适当当前的任务平台或者业务系统。

建立完整的规范文档，自定义大量的prompt前置库

建立专属的Prompt库，指令会有一定的字符限制

根据自己在接触的平台的这几年，有一些经验和材料的沉淀，不管是文档和脚本库等，都有上千份，进行进一步的梳理和建立更好的资料库，服务系统之前标准API的提取和标准的定义，更加明确多个节点的标准规范，比如接口规范、日志规范、数据规范等，形成大量的知识库，而这些标准知识库，形成Prompt的前置库，为了形成更好的指令传递给GPT模型。从而结合实际的微服务技术、中台技术等。

• 增加了模型能力的引入和团队能力提升的章节(可以理解成高级助手)
• 通过多个资料和材料的整合，形成多个专家体系，比如Java技术专家，数据分析专家，运维专家，数据库专家，产品专家等；
• 通过资料和规范，结合AI的推理能力，会更加结合形成结果，形成客服体系，进而形成人员成长体系，解决人员的问题；
• 通过专家体系的融合，形成方案解决方案设计能力，针对场景和项目的不同，结合和搭配出不同的场景技术方案，提供更好的参考。

而整个过程需要达到的目标依然是大平台，沉淀形成新型基础设施，将人力和精力更加的集成在更有价值的地方。这个阶段的整合，更多是针对于文档规范和调整，会有一定的调整，同时为了更好的区分和不影响当前业务，分离出GPT版本，进行小规模的试行和验证，推进。

PromptOps(参考Ops)流水线体系的建设

建立更新机制和流程

这个主要得益于在DevOps/GitOps上的成熟和规范，效果等，在以前的经验中，这两块基本上达到了较高的自动化能力。

为了平台化更好的优化和更新，需要不断的吸取新的知识和参考，同时获取到更好的项目参考，比如包括同类竞品项目，开源项目等，这个是一部分的集成能力，另一部分是本身Prompt库的升级，更新等，这里主要是参考DevOps的思路，形成流水线和自动化的能力，建立多个输入端，形成类似于人工智能标注一样的处理流程。

• 在原来的沉淀结构上提一步的提升和规范，提升了每个章节内容的建设范围和边界。
• 根据层级数据安全，做好一定的敏感词定义和过滤，形成Prompt安全规范，避免敏感信息和层级数据外漏
• 根据结果和返回数据进一步沉淀到数据平台，过程进一步的进行优化和维护

这个过程的主要目标是形成流水线，减少在Prompt上的投入的运维管理。

结合数字中台多产品线的融入和落地

这是一个落地的问题

这里主要利益于产品的自研能力，为什么一直坚持自研也是这个考虑，这样更好的创新和能力的整合。

在这里同样的思路，如果一个事情过于复杂，需要想办法让它变得更简单。在这块上搜索和输入的Prompt内容，结合上面的专家体系和规范体系，结合产品工程中的特定卡点进行嵌入，最终直接输出结果。这个方式类似于Prometheus/ELK等，直接嵌入到每个工程运行的卡点里面，直接点击即可查看结果，或者输入少量的提示词即可直观的看到。

• 通过找到每个产品服务的卡点，进行GPT产品线的埋点，进行产品整合，以获取得到更好的反馈结果，这里主要以sdk埋点的形式
• 在工程师层面淡化AI的各种概念，形成无感切入，在后期中不断的沉淀和优化，以达到更好的效果，比如缺少某个关键词，通过上面的流水线进一步优化

这个过程主要的目标是落地运用，达到原目标的结果，这个在数据设计和规范编码上已经有一定的运用，效果还是不错的。

总结

对于数字中台的升级上，结合GPT和超级自动化作为新的突破点，提出了在数字中台基础设施上进一步提升能力的架构设计思路，并探讨了落地建设方面的问题和解决思路。经验因人而异，每个人都有自己的思考和理解。这个是下一步升级架构方案，当前还在进一步的优化和思考中，同时也在初步的结合中。以上为升级的方案，期望可以给他人一些参考，也期望有兴趣的朋友可以关注讨论。

鸣谢

这里主要参考了一些开源项目研究和得到的思路，这里做鸣谢：

• AutoGPT 为了目标实现而实现的能力
• 阿里云运维体系 运维体系和客服体系相当成熟
• Chat2DB 基于规范(SQL语法)基础实现的能力
• Kuboard 多产品和结合落地的能力体现