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

概述

做开发久了，发现身体的变化管理也是开发工程师的一个部分，貌似很难脱离这个话题，做了一下笔记。

三个月指的是23年9月到12月期间，原很早想记录做下笔记，过于零散，刚好跟新年的电影有类似（电影角色100斤的掉秤是很厉害的）。便做了梳理记录输出，下面以程序员的角度进行的阐述。

起因是行业的快速发展，会导致方向感的缺失而产生迷茫感，方向定位的不明确，在思考但是无法找到自我破局的方法， 干脆不思考进入机械式的生活，

大致是对生活缺少激情，处事机械式，不愿意思考，也不愿去讨论… 带来的负面就是会消极，失眠，夜宵，抽烟，熬夜，精神不振 … 除了躺着，对很多事情缺失兴趣。前期有过一些心理准备，但略微超出预期，带来了182斤的体重 … 开始进入胖子大军行列。

经过2-3个月的调整，大概减重33+斤左右，进行的整体改造的变化（第一张是减前的变化，第二张是减后的变化）：

好吧，最大号的T恤也被撑满了 :-(

计划是23年9月底，这里的改变会带来一些侧面的生活改变，属于积极的一面。大概有2-3个月的调整，改造的前提是自己在把控体质还有习惯，还有部分坚持方面自己可以把控，前期是带有一定的信心，也觉得是可行，每个人的体质和习惯不一样的，这里给出一些经验的参考。

调整方面

这里调整的方面，主要从几个角度来进行的进行的整体调整，包括以下的方面:

• [运动]生活节凑
• [运动]饮食情况
• [方向]衣服外表

以下是主要调整的内容点，细节较多，这里主要描述主要点。

生活节凑调整

一定要动起来，尽量(只能说尽量)正常作息。

职业还有本能的习惯，会在长期的电脑面前，还有各类电子设备，包括多种思考处理问题都在电脑面前，这导致一个非常明确的问题是不知不觉的熬夜，大脑会长期处于高度集中的状态，再加”来一根烟”，一下就到凌晨，自然而然的外卖就点了 …

再看时间已经到凌晨1-2点，但是大脑还没有休息的意愿，带来的结果就是第二天的精神不振，后期的注意力可能不集中，体现的外在就是皮肤、眼圈、形态、体重、沟通、思维等等方面的问题等 … 会有一种感觉怎么休息总不够，动的方面就不太好说了。

这并不是一个良性的习惯。

在9月底的前一个星期，主要调整的就是作息，所谓的作息就是尽量早睡，控制在电脑面前的时间段，晚上处理不完的，放到第二天早上，解决生物钟的问题，将身体机能恢复到正常的生物状态。这个过程大概是一个星期左右，你会发现精神会好很多，早上6-7点会自然醒，皮肤会好很多的，当然，这个过程主要是想把身体的代谢以恢复到正常状态，这个是减下去的关键。

运行方面，每天早上10-15分钟的运动，跑步就可以，先动起来，自己开始只是5分钟不到就累得不行不行的感觉，后面慢慢到20分钟，有个过程，这里因为前期有规划，在节凑上并不是特别的着急，按计划。甚至时间方面，在放下手机、电脑、早起的时候，会发现，时间会多很多，因为熬夜少，上床的时间早，早上一般是6点半到7点左右自然醒，跑步运动回来再洗个澡，也不到8点这样。

这个重点还是在于计划和坚持上面，有个过程。

饮食情况调整

尽量不要点外卖，能自己带就自己带。

吃的方面是重点，自己走的比较极端的路线，原来的计划是快速减体重，再保持，再塑身。前面两个月基本上严格控制:

• 水煮菜、鸡蛋、晚餐不吃或者说在6点前吃，吃也是水果蔬菜
• 大部分情况是早上吃1-2个鸡蛋，再加一个水果，有时候是瘦肉和荞麦面
• 中午还是两个鸡蛋，晚餐不吃或者一个鸡蛋，不吃米饭
• 饮料不喝带颜色的，只喝热水或者温水，保持肠胃的正常
• 每周吃一个大餐，就是那一天你想吃什么都可以，下馆半只文昌鸡
• 其它特殊情况较少，并不会影响

重点说明，这里需要根据每个人的体质去做调整，看视频一直听说这样会伤身，还有抑郁的可能，但是个人并没有什么感觉，而且会发现精神状态会好很多，不会带有以前外卖暴饮暴食的那种压力感，除了前一两周会晚上肚子特别饿以外，其它还好。

运动外加饮食的调整，这个基本上每天会按减1斤的步子走下去。好了，这便是想要的效果，找到减下来的方式，按每天1斤，这样第1个月基本上达到20+斤左右的减下来，开始会体现衣服的已经宽松了很多。

在第二个月的时候，中下旬已经达到近30斤的效果，下面的就是慢慢调整饮食到正常，还有保持运动下去，这个过程基本上饮食需要慢慢进入正常，对油腻的食品已经没有什么欲望，明显会感觉胃小了很多，吃饭可以达到七八分饭，对所谓的美食基本上只是觉得是一个份正常的餐饮，也不会特别强的食欲。

在第二个月底的时候，基本上达到预期，后面的几斤上下基本上就没啥感觉了，整个过程大概是2个月的时间。

后面一个月是预留下来的计划，想看一下1个月的情况是怎么样的，是否会反弹，还有如何自我控制，是否能控制。目前效果还比较理想，体重保存到144左右，有上有下，但是并不影响。

衣服外表调整

注意一下外表，除了爱自己也是尊重别人

在减到差不多35+斤的时候，你会发现，各个方面都会有较好的情况，包括心态、思维、还有生活等，特别是信心的提升。

下面是运动前后的形态对比，第一张是运动前的，大脸，眼神空洞，精神不振。另一张是调整后的，会体现干净和少年感。

好吧，状态确实不好，跟长期没睡眠似的 :-(

运动之后精神会好很多，而且脸型棱角也会体现，合适的衣服会让人更加立体，选择合适发型很重要，适当做好定型。

会体现一些少年感，进行外表的一些改造，原来是考虑走一些干练的路线。

• 衣服方面：尽量减T恤换成合适自己的，定制和买一些符合自己的西服，整个人会立起来，旧的衣物需要替换掉
• 发型方面：选择好合适自己的发型，做一下定型处理，定期或者每月进行一次修理，以干净即可
• 鞋子方面：基本把以前的鞋子都做了替换，选择合适自己的鞋子，这样结合上衣服，会立体很多，至少看起来
• 其它方面：比如生活不邋遢，经常倒垃圾等，这些看个人习惯

以上主要的调整方式效果还算较为理想，以前可能做一些连自拍的角度都找不到，现在还可以给自己留下一些自己的回忆纪念。

调整前后的对比

会出现各种心态的变化，这里改变的主要从体重身材、思维心态、生活状态等，从这几个维度来进行一些阐述和对比的状态其实还是达到预期的，而且各种方面会有一些负面的影响:

• 体重身材：身高不高，体重在182左右，三高开始出现，类似于你每天扛着三十几斤的肉在身上
• 思维心态: 带有一种习惯性的操作，很多操作都带是前期经验的习惯性，思考性的比较少
• 生活状态：比较消极，圈子也比较少，带有比较大的焦虑感，易燥情绪把握感并不是特别强
• 其它: 结构化思维不突出，出差或者沟通层面上略有疲倦感，缺少说服力
  …..

后期的改变状态，效果略带有明显，效果还是达到预期:

• 体重身材：体质恢复正常，144左右，各项指标开始回到正常，类似于把三十几斤肉从身上去掉
• 思维心态: 心态上会较为平稳，急燥的心态很少出现，同时在新设计方案和思路上会比较稳些
• 生活状态：会更加积极，结合经验会做好更好的自己规划还有落实，心态上会更偏于平衡
• 其它: 会更乐于沟通和交流，对外展示一些生活方面
  …..

上面的内容点身边遇到的人很多都遇到，毕竟圈子氛围比较明显，一些调整的经验，以做为参考。

总结

这个是在三个月的自我调整和改造，原来很早想做一下笔记，调整后会前期是带来一些生活的自信，每个人的体质和习惯不一样的，需要针对性做一些定制计划，这里给出一些经验的参考。

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

概述

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

遇到问题

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

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

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

输出内容

输出部分主要是针对以上问题的解决方向，结合大模型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工具，参考其插件思路

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

回顾

上一篇梳理到我在平台与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活动中做过一些分享，这里表达得更加细化，也期望可以给做这方面的同学一些参考，也欢迎提供更好的思路和经验。