我对智能体和业务场景结合设计

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

前言

目前大模型能达到的场景和优化的效果,基本上能达到专家的效果。在微调试下回复和表达可以已经可以达到中高级产出,这里主要针对的是行业深度场景结合的设计方案。

概述

这里的设计原则依然是定位在辅助人的角色上,核心节点需要人工的确认。目前遇到的或是可以看到的基本上很多是概念视频展示不做结合参考,以市面上结果稳定输出的大模型为主。

在结合,某一行业或是场景上,需要比较大的定制化和数据调试,有成本的投入可以是三方或是自己训练行业针对性的场景,这个的成本不言而喻,中小团队无法或是很难承接。

针对这样的情况,通用大模型已经具备很强的推理能力,结合的这个来做针对话的业务场景定制,一个是降低成本,简单可维护,以提高落地能力。

阐述从这几个维度进行,分别是【业务_智能体_产品_原型】这样的思路:
1. 业务场景结合设计方案
2. 定制化智能体自我演化方案
3. 智能体产品设计方案
4. 通用智能体平台产品化演示

不同的接触层面会带来不一样的设计思路, 技术需要结合场景才有更大的意义和价值体现,每个设计人员思路不一,我有我思。

场景结合

业务本身的探索已经有多个不一样的团队在探索有很多年,一个是对行业和先前人员的努力的敬畏,结合这块并不是说要取代,而是进一步的加强,利用新技术提高和加强行业产品的服务和质量。

业务场景结合设计方案

以下是整体的业务赋能设计方案,以智能体结合业务整合作为基本设计方向:

整体的流程说明和过程设计,这里从上到上的分析:

  1. 数据采集层:这个是企业或是团队的核心,也是输出推理结果的主要推理数据来源,数据的采集不仅是互联网还有团队经验,这些会形成特有的知识库;
  2. 数据治理层:这些服务从数据治理的角度支持了数据的标准化、集成、开发和实时处理,确保了数据在整个生命周期内的质量、一致性和可用性,从而提升了智能体决策的准确性和业务运营的效率。
  3. 智能体推理层:逻辑推理是大模型的优势之一,在大部分情况下,数据加上大模型推理会给出很理想的结果建议和方案,会比人工快得多,针对每个不一样的业务流程节点上,针对性的定制化不同业务场景的智能体,由数据采集再到逻辑的推理,给出初步的结果方案或是执行方式;
  4. 业务逻辑层:以基础的智能体平台为依托,它是一个类似于员工的角色来不停的为业务的每个节点切入,不停的在业务里面深入了解和学习,还有不停的进行执行。

我们可以把上面的过程理解成雇佣关系,岗位上不停的招聘流水线人员。这里的流水线就是业务场景,人员是智能体员工,它会一直吸收经验和不停作业,团队不停的招聘智能体员工,通过不断优化和增加智能工具,可以达到更高效的工作流程,直到这里的流水线上最快最好的输出。

解放出来的人力就可以更加深入流程和场集结合,进一步的提高服务和产出质量。

比如工程师在开发一个功能,在设计阶段的思路提交给大模型,它就能给你产出各个模块的代码,然后我再拼凑,效率和质量都不错。这样的过程你会发现,你会更加专注于设计思考,而不是编码上。难道还为变量命名、接口测试数据、单元测试、注释等这些烦恼或是思考?工程师能够更专注于设计和创新,从而提升开发效率和代码质量,减少低级错误和重复工作。

定制化智能体自我演化方案

假如我们发现智能体员工可以处理一部分工作,那要怎么建立智能体。目前很多平台都有智能体,比如星火、千问等,你会发现做一个智能体很简单,定义Prompt场景和投喂数据。

目前的大模型发展上面,推理能力成熟度比较高,主要在数据上的清洗处理。我们要给智能体对应的感知能力,推理能力还有执行,仅仅是简单的向量数据是不够的。另外数据质量要求,大模型本身的限制等都是问题。

数据的采集也包含很多,包括网络的,视频,音频,日志,行为,企业数据等多种感知数据,这些过程再进一步交互采集和加工处理,针对特定数据处理,形成智能体的数据资产。

在业务逻辑上需要的是更稳定、跟可控的结果。包括记忆能力,分析和自动的结合,以下为智能体演化的过程:

设计说明:

  1. 数据清理:针对性的智能体员工,所采集的数据,质量,检索等都需要比较高的要求,这就对数据治理上,数据服务还有分类上面下点功夫,幸运的是,行业数据治理给了很好的基础,这个应该来说问题不大。
  2. 分析能力:分析逻辑推理这个是大模型的强项,过程规避掉针对性的模型训练,使用通用大模型解决这个分析推理的问题,通过数据挖掘和推理,获取到我们想要的计划和执行要求。
  3. 执行能力:执行过程工具比较多,这个也是基于研发技术,属于比较成熟的方式,结合业务场景做开发调用即可。
  4. 记忆反思:在这个过程,所以的问题和记录,三方感知等会进一步的消化成经验数据,进行总结和为下一次执行做好基础,而不是海量知识库,提炼出精准知识库,为智能体发展作准备。

在这个过程你会发现,演化体系会慢慢形成,而通用大模型不断发展,也会有更好的推理能力,两者结合起来,形成特定的智能体员工,不断的积累加深。

比如写方案的场景,制定出方案目录编辑的智能体员工,专门针对不同的主题,场景定制方案目录。在初期第一个方案目录出来之后,不断的人工确认评审,修改意见收集,这些都会形成数据经验不断的积累。

下次再写类似场景方案,可以直接出对应的结果,规避掉前期的低级错误和问题,包括一些特定的要求等。

智能体产品设计方案

结合上面的设计方案,针对性的整理出来的智能体产品设计。

这里 产品设计思路,只要包括几个点,实现功能数据采集、处理、推理、服务、运维、运营等一套智能体平台产品,需要的是可结合生产实践的平台。

目标也是针对于中小型团队的产品能力,低成本,可维护,能落地,能见效果。以下为产品的设计方案图:

设计描述,这里从上到下的进行产品说明:

  1. 数据处理层,这里可以立即成感知服务,用于多平台数据的收集,接入,清洗,分析,资产,服务等,相对来说,基本上属于中小团队的数据方法论实现。
  2. 模型推理层,大模型的接入,还有prompt的管理优化,流程管理,智能体管理,多智能体交互,还有数据接入验证等,数据标注等一套标准平台。
  3. 软件开发层,可以理解成开发层的内容,包括不限于平台的开发,接口开发调用等,主要提供软件和执行层的技术规范和方案。
  4. 运营管理层,整个平台的管理体系,比如各个节点的管理和SaaS化,对人员提供产品力的表现,对整体智能体平台的管理。

以上是智能体平台的产品设计和研发过程总结,这个也是在研究智能体过程中的实践总结。

拿一个上面写目录的智能体来说例子,收集数据的来源可以是团队内部的规范和要求,另一个是会议纪要和记录,这些通过采集之后进入到数据仓库,在进一步的分析得到数据资产和服务,形成一个简单的DataOps流程。

在逻辑推理部分获取到特定的目录结果和数据格式,这些就是出来的版本。有了目录的数据针对性的开发出模版解析能力和工具,生成文档目录结构,输出发给对应人员,人员可以进一步的审批验证完善等。这些过程智能体平台会记录,进一步记录分析形成经验记录。

以下为多Agent协作的设计思路:

当然,也可以考虑建立一个是审核的智能体角色。

通用智能体平台产品化演示

以下为智能体平台产品的原型设计,前期是一边设计一边编码,大部分也是使用AI开发,这个过程你会发现,效率会快很多,基本上所想即所得的代码。

  1. 智能体门户设计,包含管理入口,SaaS化管理和组织管理。
  1. 推理管理平台,形成模型的管理和角色推理逻辑和分析。
  1. 数据治理体系,针对于中小型团队的数据治理方法论的落地和实践。
  1. 数据资产服务,提供数据资产管理和服务管理。
  1. 软件开发体系,技术研发框架和自动化设计。

这些整合在一起,主要是形成一个平台管理的概念,一套SaaS来进行管理。 过程设计每个模块会设计成单独的服务,也就是这样的,方便形成积木类似的软件组合,其他缺少的,按接口和规范引入即可。

以下为智能体团队:

每个产品设计人员和架构师有不同的见解和思路, 这里针对的是中小团队,低成本,方便维护为主。针对结合数据整合模块,进行数据元数据和主数据的抽取上报,集中到数据仓库和数据湖,形成数据资产能力。平台能力和业务架构的体现从开放平台和新平台对外门户,形成行业业务+智能体团队沉淀,形成核心业务能力资产

同时相比于传统人员,智能体员工在业务场景中的优势包括:

  1. 专注复杂任务:使人类工程师能够更多地专注于创造性和战略性的任务,而不是日常的重复性工作
  2. 高效率:智能体可以快速处理大量任务,不受时间和体力限制,能够24/7不间断工作。
  3. 一致性:智能体执行任务时能保持高度一致,减少了人为因素导致的误差。
  4. 学习与优化:智能体能够通过机器学习不断提高自身性能,优化工作流程。
  5. 成本效益:一旦部署完成,智能体的边际成本较低,长期来看可以节省人力成本。
  6. 可扩展性:可以根据需求轻松增加或减少智能体的数量,灵活应对业务量的变化。
  7. 减少人为错误:避免了因疲劳、疏忽等人类常见原因导致的错误,提高了工作的准确性。

通过高效、一致且持续优化的工作特性,能够在降低成本的同时提升业务处理的速度和准确性,使人类工程师更专注于创造性任务。

总结

以上是我在大模型结合业务场景的设计思路,在结合,某一行业或是场景上,需要比较大的定制化和数据调试,有成本的投入可以是三方或是自己训练行业针对性的场景,这个的成本不言而喻,中小团队无法或是很难承接。这里从小团队结合场景的整体的结合思路,产品设计,还有一些建设经验,目前也是在不断的开发验证,希望可以给一些同学参考和思路。

我在研发的开源智能体平台笔记


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

概述

大模型的出现让智能体成为可能,智能体平台由原来的中台升级而来,目前产出整体的形态,为一阶段进度。

中台的集成架构很产品为智能体平台做了一个很好的基础,整个过程做了笔记记录(以电子书形式维护,并不会出版):

用于对外输出而期望得到更多有兴趣的同学交流。

电子书地址:https://alinesno-agent.linesno.com/book/

建设过程

之前平台或是中台提供了基础能力,但是还是没有达到想要的预期,在得出数据分析,资产后,进一步的升级到智能体层级。

还是在定位在平台范围,新的架构设计使平台具备有感知、推理、分析、演化的能力。过程做了设计思路和笔记,以下为目录:

有一部分章节未完成,主要还是在测试阶段,还未能输出经验文案,也是在进行中。

项目介绍

运营团队较小,不到4个人,以开源形式运作,以Apache 2.0协议对外,考虑以获取更多同行交流,也是长期运营的一个计划。

开发技术主要是微服务、devops、中台、容器化、自动化之类的,这里不过多阐述。

以下为github项目地址:https://github.com/alinesno-infrastructure

这里将多个平台进行融合,也是可以将之前的技术、数据、运营、智能体到一个门户,这样为业务上层做好基础。

运营门户:

智能体交互:

运营门户包含了技术中台、数据治理、数据中台、智能体平台一体化。

方向愿景

市面上很多智能体平台可能还是缺少整体的体现,依托于前期中台的基础架构和产品,这里的平台会更加完善。

开源也是对外提供中小团队赋能的一个期望,内部可以定制化的一个针对业务性的智能体。

总结

这里是我们对外研究智能体的一些设计经验和产品思路,有兴趣的同学期望可以多交流。

我对多智能体协作过程自动演化架构设计

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

前一章节描述对产品的重新设计思路和愿景我在大模型时代把平台型产品重构设计,书接上文。

概述

多智能体(以下简称Agent)协作的针对的是平台自我演化和自我成长的协作方式,在这个过程更加会体现超级个体的概念,也体现对上层业务项目的支撑方式和模式,会以一个示例来进行简单说明多Agent的操作方式。

设计稿为临时笔记会比较粗,但整体思路方向不变,后期会根据此基础进行拓展。

智能体模型设计

在运营平台过程中需要多个Agent协助,每个智能体都有同样的模型,每个智能体在这个模型上不断的发展出针对性的内容输出,这里我们定义智能体的统一模型,为了下面虚拟出不同场景智能体做好基础。

这里的设计会有一些参考游戏概念,以更好的融入下面的设计。先提出【环境】条件,游戏里面貌似叫世界,这里我们以尽量简化为主,人的角色类似于上帝视角,偏向于管理员职责。

下面是智能体的模型架构:

模型架构主要从支撑平台到Agent,再到中间的关联进行了描述,这里从上到下的进行描述:

  • 管理员:进行整体规则的制定和审核,基础平台规则的制定者;
  • 环境:运行所需要的元素,针对平台来说,主要是计算资源,数据库,角色等都属于环境,类似于游戏里面的世界;
  • 智能体:在环境里面的AI角色,包含感知、记忆、反思决策等能力,管理和操作环境各个因素;
  • 技术层:平台运行需要的治理套件,包括技术,数据,AI,运营等服务套件能力;

可以描述得更加直白一些,在这个世界里面,Agent和管理者的任务主要是维护平台发展和稳定,平台是为上层业务提供支撑能力,需要稳定和技术支持服务。

针对于业务场景来说,基于平台模型和能力,可以虚拟出不同行业,不同场景的智能体角色,进行深入的场景结合,对于不同的项目,同样也可以虚拟出不同的角色。

数据的沉淀和检索主要依赖的数据治理套件,在执行过程中会使用技术和运营的相关接口进行调用。数据的来源可以是互联网或者自家的前期沉淀数据池,这些数据资产的处理形成团队特定的智能体能力,输出的结果也会更加的精确和符合要求。

这里依然还需要人工的介入(当然这个人工也可以是智能体),主要的考虑是稳定和针对场景,规避产品设计中的过度发散,同时也是为了更好的专注于基础平台的建设。

解决方案编写示例

为了更好的阐述在这个过程中的协作,以常见的解决方案设计为示例设计描述多Agent的操作,从数据感知、计划、执行角度来说明示例设计。在进行多Agent协作之前,有兴趣的可以看看单个Agent的处理示例我自定义k8s运维Agent插件:仿k8sGPT设计

下面是多Agent协助示例流程图:

现场假定在数据分析中发现一个商机,触发客户需要解决方案的需求,进而形成计划放在计划池中,这个时候平台感知需要编写一份关于某项目主题的解决方案给管理员。这个假设比较容易实现的,这里就不做过多阐述。

收到编写方案需求的Agent便开始对应的工作,这里需要5个智能体角色:

  • 解决方案架构师Agent:负责收集需求和定制编写目录大纲,进而分解任务。
  • 需求分析专家Agent:根据目录大纲编写需求分析章节。
  • 行业业务专家Agent:根据目录大纲编写业务分析和功能章节。
  • 系统技术架构师Agent:根据目录大纲编写技术方案章节。
  • 解决方案评审Agent:最后在评审阶段,针对于每个输出内容进行评审和进一步的优化。

最后合成一稿件解决方案初稿,发送邮件对应的管理员,并给出相应的建议内容。

操作过程中,智能体会从数据资产中不断的获取最优化的记忆库和内容,还有自定规则的内容来进行章节的编写。这里数据资产的来源会先从互联网或者自家的数据材料中获取和并解析到平台数据治理仓库中形成数据输出。

在经过评审过的内容进一步的形成沉淀,对下一个份解决方案为好输出,由此形成闭环的操作。

结尾

上面是目前平台对多智能体协作过程自动演化的设计思路和方案,过程实现并不是说特别难实现,主要还是在Prompt和大模型的成熟度上,还有Agent的交互模型,消息存储模型等,也在进一步完善交互,有兴趣的同学也可以关注交流。

说明

  • 设计思路参考斯坦福AI小镇模型,包括论文和源码

我在大模型时代把平台型产品重构设计

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

愿景

  • 【操作】之前的平台手工驾驶的汽车,要变成智能化自动驾驶汽车
  • 【成长】之前的平台是死的,要把它变成能自我成长和演化的

概述

这里指的基础平台指软件基础平台,包括K8S容器化、DevOps技术平台、微服务平台、数据治理平台、人工智能等

前期基础平台建设的情况,在这个过程中差不多经历有几个年头,也从这个过程中不断的接触和引入新的技术体系,形成一套标准平台体系,标准平台化产品。

针对的场景依然是中小型项目和团队。

下面是前期平台项目演化的过程:

  • 一版(ACS):提取出非需求性模块,提供基础的权限服务,类似ruoyi
  • 二版(ACP_1.0):形成集成数据治理和数字中台型模块,从产品化提供服务,类似于CDH
  • 三版(ACP_2.0):形成SaaS形态,中台化,形成标准型输出,思路类似于金蝶云苍穹
  • 四版(AIP):形成智能自动驾驶形态,自我演化和成长,形成新智能体平台(方向)

以下为简称及项目开源(Apache-2.0协议)地址:

同时在建设过程中,不断记录和完善,整理出一些建设经验参考,相关建设过程经验和参考材料电子书:

从零建设数字中台产品与运营实践

重构设计的方向

前期曾经结合大模型与实时计算服务进行结合,还有代码生成器结合,历史设计的原因始终无法达到最优效果。

为什么要重构?

主要原因是发现原来的设计思维已经在大模型时代存在代差,不是落后一点,而是感受到不是一个维度的架构和方案设计理念,俗称降维打击 :-)

所谓的重构设计,不仅仅是将前期的经验和产品设计融合在一起,而在针对的是未来3-5年行业市场的发展进行的规划,除了一些新框架版本的升级以外,更多是产品型的思路,还有与传统型平台产品的区别。

这个也是在前期落地过程中的一直想解决的痛点。

之前的平台手工驾驶的汽车,要变成智能化自动驾驶汽车

基础平台的管理运维一直是无法规避的痛点,类似于一辆汽车,在建造出来的同时,还需要匹配的能力的人员、团队、资金、项目等才能开启,承认每一步都有文档材料,每一步过程都有技术支持,但当开出的那一刻,油费就在燃烧。比如:

  • 实施过程需要运维工程师规划,对服务器配置要求、网络情况进行梳理;
  • 前期使用需要技术架构师的培训和指导,人员技术培训;
  • 中间问题处理需要高级工程师的指导,各种小组问题和会议;

这里会产生很多的沟通成本,时间成本,管理成本等,往往是一个项目的组的成本,这个过程的投入和产出比,是否达到预期还需要看团队人员的基本情况。再比如后期的管理:

  • 团队的投入:架构师团队,包括技术、数据、运维,基本上都是技术经理级别;
  • 项目的支撑:太小的项目不需要,中等的项目在犹豫,大项目不差钱,会有一种鸡肋感;
  • 平台的维护:几百上千份的材料,后期问题的处理还有收集,产品技术的沉淀等;

在经历过问题,会思考遇到的这些平台是否能做引导或者自我处理。

这里引入平台自动驾驶的概念,在减少人工干预或者不需要人工的处理下,结合前期的实施经验,主要体现在几个方面:

  • 部署实施:平台在不同的项目条件下做的最合理化的自动实施和运维管理;
  • 运维管理:优化在最低级别的场景方面,保护平台提高基础平台的稳定性和可控性;
  • 知识库:结合大模型Agent知识库给不同的人员岗位角色提供材料和引导建议;
  • AI团队:针对于不同的知识库虚拟出不同的大模型Agent岗位角色,形成多Agent团队;
  • 问题处理:在运行出现问题的情况下给出问题的分析和合理化建议甚至修复;
  • 自动化:每个节点结合自动化执行,并结合日志可视化监控预警;

以下为Agent团队自定义模式:

通过不断的采集数据分析和数据管理上,对数据进行资产管理,再结合输入值,形成输出值。平台自动驾驶管理更加自动化和智能化,结合实践过程中的指导和管理的最佳实践。

之前的平台是死的,要把它变成能自我成长和演化的

假如在没有人工介入的基础下,平台基本上就是一套软件或者代码,升级依赖的是产品经理或者维护人的经验水平来进行。但是行业是在发展的,商机是在不断出现的,
行业市场竞争力也不断的变化,业务场景需求也是不断的在变化。知识库在使用过程中,也是在不断的知识库沉淀。

在这个过程中,是否可以结合大数据分析,使得平台变成自我演化。

这里并不能说做到完全的自我处理,同样需要人工的介入,但是整个自我演化流程需要走起来。这里对平台的演化,从几个角度来进行的处理,主要是:

  • 自我感知能力:对运行的自我数据进行采集管理,除了本身的运行数据还包括互联网数据,第三方数据,数据沉淀到数据资产中;
  • 自我学习沉淀:在数据采集过程中,对于有作用的数据进行数据资产的管理和沉淀,形成一套针对性的知识库;
  • 自我决策执行:根据采集到的数据和设定的规则,自主做出决策并执行相应的操作,可以极大地提高平台的效率和响应速度;
  • 服务自我添加:在运行过程中能够自动检测到新的服务需求,并动态添加相应的服务模块或功能,快速响应新的业务需求和变化;
  • 文档自我输出:具备文档自我输出的能力,即能够自动生成和更新相关文档、报告等资料。

在这个过程中,我们依然无法做到多强大的能力,依然需要人工介入,但是介入的过程和节点是不一样的,由原来的主动变成被动形式去完成这个工作,形成一套自己的管理运作方式。

这里主要集成匹配的服务套件如下:

  • 数据治理套件:数据治理体系,包括采集、清理、任务编排、数据资产沉淀等;
  • 技术研发套件:技术规范、代码生成和服务沉淀,服务角色资产的管理;
  • 大模型Agent套件:包括逻辑推理、agent角色设定和知识库的结合,AI团队的设定和管理优化等;
  • 自动化编排套件:设置规则管理,结合自定义的数据资产接口进行自动化操作;
  • 可视化监控套件:过程的可视化监控管理,预警管理还有全链路的监控管理;

这些套件本身就是属于平台管理体系,以轻量型为主,这里就不再过多阐述,只是过程中不断的融合和调试,将整个成长和演化流程进行理顺。更多的类似于数据治理+自动化结合的思路,针对的场景不同,结合的结果也同样不同。

业务和团队赋能模式

进行团队赋能,团队私有化模式,形成中小团队业务壁垒和新能力。团队赋能模式旨在提升团队的整体素质和执行效率,使团队能够更好地适应市场变化和业务需求。以确保团队能够在市场中的角色地位,自我优势等,形成高效协作、创新思维和持续学习。

在平台化过程中输出的能力,包括如下:

  • 提供标准化接口和定制化方案;
  • 提供团队基础研发能力、数据治理能力、大模型Agent能力等;
  • 业务服务结合数字化创新解决方案;
  • 提供技术支持和项目解决方案支持;
  • 提供过程技术指导和落地方案;
  • …..

进行业务赋能,团队智能体模型管理,结合业务形成最新的业务模式。业务赋能模式旨在提升企业的核心业务能力和竞争力,使团队能够在市场竞争中脱颖而出。

这可能包括优化业务流程、引入新技术、开拓新市场等方面的工作,以实现业务的持续增长和发展。

通过团队智能体模型管理,结合业务形成最新的业务模式,企业可以更好地适应市场需求,提高运营效率和创新能力。例如,一家零售企业可以利用数据分析和智能营销模型,个性化推荐产品,结合大模型聊天模型,提升销售额和客户忠诚度。

其它

基础能力的建设类似于基建,在新的高速,能源模式下达到快速通罗马的效果,在这个过程中,结合自身的业务特点,能力等形成自己的产品线。基础平台的建设也是类似,规避掉基础为零的东西。

新平台产品架构设计是一个高度自动化、智能化和自我演化的平台产品方向。这不仅能够提高运维效率,还能为团队和业务提供强大的支持,快速跟进新一代的技术,为团队和业务线赋能,这个是基础平台的价值意义点。

我在运维服务结合大模型的产品升级设计

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

概述

针对的背景是中小项目运维管理,前期的产品研发上在运维体系上,已集成自动化操作和可视化监控,比如k8s/promethes/jenkins/ansible等自动化工具,并结合设计出对应的运维套件,包括流程化和数据治理工具,devops/chatops体系等,结合开源的工单工具形成运维的标准化管理和流程。

在大模型的新技术的产出上,将进一步为运维提升,达到整体运维产品体系往上升一级的目标,以更为智能化,更贴近于人性化目标。

前期在开源平台产品运维阶段会遇到一些突出类的问题,比如:

  1. 系统问题的分析:缺少初步分析的结果,系统横向知识多,问题分析过分依赖经验和高工,分析深度不足,排查过程长。
  2. 数据和知识库归纳:工单和分析结果,问题场景和问题现场维护丢失,形成经验沉淀太多,查找困难,重复性问题出现等。
  3. 数据的分析报告:在全链路的监控下,分析的支撑繁琐,运维数据的治理和后期的总结分析依据,对人工依赖,运维数据治理不足;
  4. 处理报告结果分析:针对会议或者结果性报告输出内容较多,对报告性编写有一定要求,会议或者报告类输出问题依据说明有些情况说不清;
  5. ….

注:这里不涉及项目资金和客户沟通层面,比如运维费用依据,只做辅助类设计。

总会有一种好像不难解决或者可以解决(可解决),但过程就是不是特别顺的情况,在标准的执行上总会有一种可以有更优化的依赖工具自我感觉。在升级设计思路,从新技术结合的思路进行阐述:

  1. 运维Agent员工的设计和概念介入
  2. 结合数据分析的形成运维数据资产
  3. 结合大模型的数据分析报告输出

以上与ChatOps的概念相类似,在交互和输出上将会更加的达到精细化的解决思路,以供相关人员的排查和处理。每个产品设计和架构方案思路不一,以供参考与交流,我有我思.

设计思路

设计是基于原有的开源平台产品上的进一步升级,从初步的探索和目前大模型的成熟来结合,结果会控制一定的发散性,初期以达到可用为目标。

运维Agent员工的设计和概念介入

将进一步的设计出智能体员的概念,大模型Agent员工的介入,在特定阶段或者消耗时间阶段设计出处理角色,以切入运维工具和管理流程,形成初步的Agent运维团队,以解放部分人力思考分析过程。

这里设计的角色比如:

  • K8S分析工程师:分析k8s问题并得出初步的解决思路,包括执行命令,解决思路;
  • SpringBoot分析工程师:分析java应用异常并得出初步的配置方式,并给出对应建议;
  • 报告分析工程师:分析问题结果,并结合处理内容,与当前模板结合,得到处理过程分析报告;
  • 安全分析工程师:分析异常链接,然后得出相应的解决思路;
  • ….

参考: 结合的k8s运维的产品示例自定义k8s运维Agent插件:仿k8sGPT设计.

这些Agent员工的设计会形成初级的运维团队,结合大模型的经验分析,知识库内容等得出初步结果给工程师,减少初步的排查及初级的问题处理,在沙箱环境进行验证。当然也可以结合工作流,但是带有操作风险,毕竟是生产,需要过一步人工。

结合数据分析的形成运维数据资产

单纯的自动化管理体系还有可视化,并不能将整个运维过程闭环激活,它需要反馈和成长机制,以解决当前的问题和规避未来出现的可能性。运维结合大数据,会达到更优化的效果。

在自动化运维工具套件中,已经可以采集到全链路的过程数据,这些数据一般的系统难以承接,统一导入大数据套件进行管理,形成运维特定的数据资产,从而形成运维的知识库。

基于数据治理套件的实时、离线、清洗、分析等工具,将进一步的得到应用的生命状态,系统的健康状态,每个微服务,每个应用的健康评分,常见问题和后期开发的重点处理内容,形成数据的反馈闭环,从而在研发过程中进一步的完善规范,在DevOps流程中进一步的添加检测。

这些也是提供给Agent员工的数据接口来源。也可以结合业务数据一起,这里是平台性的运维,偏向的系统型数据,但流程管理是一致。便于在后期的管理中,包括商务沟通等形成一定的依据,还可以在处理过程中,处理后还原问题现场,这些都需要大数据套件的存储和治理。

如果有资源,同样也可以结合机器学习进行算子优化,这里不涉及机器学习内容。

结合大模型的数据分析报告输出

运维工单处理,问题解决方案和思路,沉淀方式形成知识库体系,而不同于传统知识库层面的是,结合大模型的知识库会更好的体验,大模型聊天机器人当前也比较普遍。

在前期的数据和Agent工员结合下,通过指定的模板分析,比如ChatPPT工具,形成统一的分析报告,形成会议的相关依据初始稿,再由工程师进一步的做加减法处理,比如:

  • 系统运行的日报/周报/月报,异常处理,处理方式还有建议思路。
  • 工单的处理结果报告分析,处理思路归纳归档,更完善的说明描述等。
  • 结合知识库进行相关材料的编写,比如部署方案、资源配置等
  • 需要根据具体情况进行的分析和处理,以确保运维工作的高效性和质量。
  • …..

写报告过程就会发现,即使在特定的模板之下,初中级工程师在这块上偏向于短板,同时每个输出过程需要一定的工作量,还有过程QA/PM等审核,再出现在会议上,这个过程可以解决,但周期长短不一,沟通多,总有一种不是特别顺的感觉。也许分析内容未必达到要求,但已经相当于出了初稿,可以更快的投入到解决思路的讨论评审中。

其它

以上为在前期做平台产品基础上的进一步升级优化方案及思路,在运维工具的选型中,针对于中小型项目或者团队的比较多,前期通过多次的整合形成的devops/chatops/自动化标准及流程,
在大模型的切入下,提升更好的思路和解决方案,当前已在结合验证,同时也是下一步产品优化的方向。

期望给一些同学参考,也期望有兴趣的同学可以一起讨论,分享经验。