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

概述

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

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

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

电子书地址：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协议)地址:

• ACS alinesno-cloud-service
• ACP alinesno-cloud-platform
• AIP alinesno-infrastructure-platform

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

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

重构设计的方向

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

为什么要重构？

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

所谓的重构设计，不仅仅是将前期的经验和产品设计融合在一起，而在针对的是未来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/自动化标准及流程，
在大模型的切入下，提升更好的思路和解决方案，当前已在结合验证，同时也是下一步产品优化的方向。

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

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

背景

内容针对的是社区产品建设新人切入的指导性思路，目标是打开自我思维，有基础，能设计，能思考，能实践，会自我价值体现。合理利用社会资源工具，将时间和精力放在最有价值的地方，创造价值，提升价值。

产品是以开源状态进行开发管理，当前社区团队在接纳新人，有部分还是大二大三学生，有一些可能没有接触过设计体系这块，考虑更系统的体现基础层，这里进行阐述说明。针对于新人来说需要一些方向的引导，以快速的进入状态，跟上梯度成员，便于他们有方向的成长和学习方向，也是规避迷茫，缺少方向感，导致负面和误导，消耗无谓的时间。

当前维护的社区团队非常小，还是兼职，自动化和低成本的基础设施对团队来说，会比较看重，应用最少的人力去维护好产品，同时为了更方便的办公。工具的使用，可以让新人和加强的技术理解、架构思维、使用场景、解决能力、还有方案输出等能力。

设施包含

这里的基础设施工具，主要是使用开源和常用的SaaS化工具来进行平台产品研发的管理，以减少成本和学习路线，可以有大量的学习内容让团队可以快速解决问题，如下图中的这张架构内容。

基础层主要是包括【基础设施、代码级、模块层、应用级】，这个主要是基础环境设施，上面系统级主要是软件服务应用。在基础层，基本上使用的都是免费工具类型，包括免费服务器，免费的DevOps套件、免费的代码检测、安全检测等。每个人都可以使用，开个账号就可以学习，可以使用一些效能工具更快的提高自己的效率。

有一部分是现成的，有另一部分的自己设计的，总的来说，类似于PaaS层，但是又高于PaaS层，最大化的贴近于应用层，以减少底层的建设，确定好规范之后，外加GPT的加持，会更加提高效率和输出服务能力。

这里主要的内容包括几个主要部分：

1. 基础PaaS层：阿里云ECS服务器、Kubernetes、阿里云ECS网络安全、阿里域名
2. DevOps套件：Github、GithubAction、阿里云效Maven私服、阿里云ACR镜像
3. 中间件层：Redis、阿里云MySQL、七牛云存储、Clickhouse存储、Kafka消息、Nacos等
4. 基础服务层：Infra核心包、Infra单点登陆、Infra代码生成器、Infra权限引擎、Infra网关服务等
5. 质量管理层：SonarCloud、GithubSecurity、墨菲安全、ApiFox
6. 自动化层：GithubAction、Ansible
7. 项目管理层：阿里云效项目管理、阿里钉钉、WPS、腾讯会议
8. 项目预警层：Prometheus、Ansible、阿里钉钉
9. AI智能层：Hugging face、百度飞浆、阿里云AI系列
10. 数据治理层：阿里云DataWorks、Infra数据治理套件
11. LLM大模型层：ChatGPT、星火大模型、百川AI、Infra智能体服务

这些大部分社区工具和云服务平台，作为入门的基础内容，难度系数并不高，要求只是基础能接入使用就可以，另一部分是基础架构里面进行补充的内容(以Infra开头)，这些都提供出对应的接口和使用说明文档。当中有一部分会混着用，比如数据治理层，后期做为平台型产品会做一些场景进行针对性替代的研发。

上面这些，在这进里统一规划层基础设施层，这些会考虑使用低成本的方式去运营管理，方便产品的正常开发和演示运营，同时确保可以新人更好的针对性的自我学习。

学习路线

在工具选定之后，针对新人来说，怎么接触练习，这个可能来说，先对比较简单一些，对于线上可以注册的工具，基本可以自己学习就可以，学习主要通过以下路线，先熟悉工具，在进行应用层服务的开发。

学习路线主要是下面：

1. 了解开源工具：账号的注册和示例的学习，了解这个工具是做什么的。
2. 了解服务能力：了解Infra组件提供的基础能力有哪些，怎么使用当前的服务模板。
3. 熟悉研发流程：了解产品的项目管理流程，敏捷开发流程，知道从哪步到哪步。
4. 创建服务能力：能根据需求自主创建出服务并提供出服务能力，价值体现。

学习工具主要是了解怎么使用，这里使用的层面就是自己注册跟学习了，然后自己关联自己的demo进行学习。这个过程看个人，不合适人员并不会要求往下，合适人员接触起来，其实也比较容易，大部分就是看教程或者视频操作。

这也是进入产品维护的一个简单门槛，基本工具使用的还是helloworld级别，深入会过程再慢慢沉淀这样。在长期接触过程中，其实大部分场景都是可以满足，即使不满足，也不会达到多难的程度。

这里除了编码层面的，其他都是自动化，编写一套之后，留着自动任务执行就可以，根据预警情况，看是否需要处理，其他的，出问题再需要人工介入。

编码层面的，这里主要是通过结合代码生成器，GPT和定制的Prompt来进行，因为是产品型和服务型应用，逻辑还是先出一般本，先可以看到，然后后续根据产品功能，进一步的完善。先用起来为主，这部分对一般没怎么接触过的人员，先做一个功能就可以上手，因为规范都统一化，这些入门成本会比较低，参考着复制粘贴就可以。

另外就是Agent智能体服务的，这个整合起来就是调用GPT的接口外加基础服务的接口，当然，这个需要一些规范，前期已经解决了这个问题，目前主要是根据规范，结合工具API接口写Agent插件就可以，集成架构也已经集成。

能力输出

这部分重点还是在需求和设计上面，到进入服务输出来说，到这步已经很容易了，服务能力的输出，才是最贴近业务层的，这里会把精力放在这块上面，时间成本最大的，也是在这块上面。这部分可以花时间在需求和设计上面，后期通过AI编程和微调整来实现，另外就是参考其它网上代码或者开源项目。

自我能力提升，还有AI的引用也是在这块上，这块要考虑的编码，但是更多的期望可以使用现成的代码，可以复制或是开源的，符合的拿过来就可以，没有的，使用GPT协助建设也可以。这部分偏于码农路线，但是我们能做但是不代表一定需要做。

时间精力放在优化，某个框架深入，思维的理解，场景的运用，解决方案沟通上，这个是目前团队特别关注也是重视的。

总结

上面是当前产品研发过程中，使用的基础设施工具，有部分是使用现成的，有部分是结合开源项目进行的研发，有部分是自主开发，通过设计整合起来的基础设施能力，为上层服务建设提供良好的条件，也可以让新人更专注于场景解决方案和业务能力分析设计上面。

这里提出了一套基于开源工具和社区资源的学习和实践方法，强调了基础设施、代码级、模块层、应用级的基础知识，以及使用免费或低成本的工具和服务的重要性。并给出了一个学习路线，包括了解开源工具、了解服务能力、熟悉研发流程和创建服务能力等步骤。强调了能力输出的重要性，包括业务能力、AI引用、编码能力、优化能力、框架深入理解、思维理解和解决方案沟通等方面。