软件工程师罗小东，多年架构和平台设计经验，以下为大模型交互设计，带有一定编码设计。

前言

这里针对的场景是中小型团队，尽可能低成本运用大模型提升效率的，另一个是中小团可以使用智能体团队结合业务。

目前看到的和遇到的大模型交互大部分都是聊天助理类，另一种是类似斯坦福AI小镇或是AutoGPT模式的，其他的可能就是应用型嵌入，还有概念视频类。在使用过程中发现，不稳定性，不确定结果等，很难达到自己想要的生产稳定形式。斯坦福AI小镇和AutoGPT类型原来是自己最为期望的效果，但是生产上落地还有一定的距离。

见识有限，也期望可以了解同行多一些实用性案例。

概述

原来接触大模型本身是为了解决本身遇到的问题，本身的AIGC能力和推理能力刚好符合自身的需求，这里结合了AIGC、交互、推理、自动化、大数据、RAG、微服务等作为基础，有结合ChatOPS设计思路，整合到一个频道里面。以下结合单智能体和多智能体交互通过进行整合。阐述从交互例子到智能体角色来进行说明：

1. 智能体角色定义和输入输出设计
2. 单个智能体交互和产出
3. 多智能体之前交互和产出
4. 智能体角色开发模式和例子
5. 下一步的愿景和规划设计

例子和代码统一上传到github基线，有兴趣同学可以互相交流。我有我思。

https://github.com/alinesno-infrastructure

智能体交互设计

原来设计的思路是需要灵活的设计能力满足不同场景，能结合现成的业务提升，满足自身工作需求，另一个是把自我抽取出来。

以下会结合【我】这个个体来进行例子编写，以达到更好的表达效果。

这里的我只是通用型例子

1. 智能体角色定义和输入产出设计

角色设计是基础，思想以辅助人的设计为主，形成个人的经验团队，体现超级个体的初期。

目前设计的智能体主要能力包括：

1. 针对业务场景自动生成和推理能力
2. 输入输出还有交互能力
3. AIGC的内容可以支持修改调整
4. 执行能力和输出能力
5. 长期和短期记忆还有反思能力
6. 业务频道场景调用结合能力

自动生成和推理主要是结合Prompt工程，团队RAG能力，结合LLM一起，这部基本上属于市面上比较成熟技术。

这里生成内容可以修改，明确的输入和输出，这样节点之间才可以互相通信和交互，这也是麻烦点（不是难点）之一，为了确保结果一定可用，同步需要可以修改。

执行和输出能力本身属于智能体的内部和外部的交互，这里主要是做产出设计，也是结果的体现。

角色的设计基本上大同小异，每个智能体都有自己的知识库，这里叫做记忆库，长期的保存向量库，短期保存数据库，这里还加了全文检索库。短期库会定时做反思保存长期库。

业务场景是必须项，结合解决自己或是业务场景的能力，才能真正用起来。这里增加频道的结合，可以针对这个聊天频道进行结果输出，每个频道也有自己的知识库或是记忆库。

2. 单个智能体交互和产出

单个角色的交互以结合培新题目作为例子，来进行一个简单的演示。

业务场景：

我需要出面试题目、业务题目、还有技术题目给对应的人员参考然后各个负责人做为参考，以提升团队能力。

工作痛点：

题目收集难，历史题目材料多，我找麻烦，给新人不知道在哪儿，而且一般经验人员还无法出符合不同团队，不同水平，不同经验的题目，还需要结合市场或是新的政策出题目，出来之后评审困难，文件整理麻烦，一般来来去去需要周期长，单独开发个系统过于鸡肋。

愿景期望：

1. 想要大部分都可以做这个工作
2. 快速产出结果进入评审阶段

智能体需求：

1. 能结合团队业务知识库
2. 生成各种场景题目和答案
3. 导出Excel然后下载

下面演示例子，假设我们已经导入智能体知识库，然后进一步提问智能体。

开发这里不做过多阐述，后面章节会提到

提问智能体角色，这里使用json作为交互媒介，这也是为什么说麻烦的地方，后期考虑过界面优化以体验更好一些。

不符合再进一步修改和调整，假如完成90%，也可以自己手动修改达到目标。

最后生成Excel下载：

这个时候你会发现，这些过程就会变成了一个节点，智能体他代替了我的部分工作角色。当然，如果结果不错可以给个好评，这个结果会影响到智能体反思的部分。

3. 多智能体之前交互和产出

好了，我们发现单个智能体已经可以做标准输出，多个智能体交互通信就方便了。

也考虑过类似AI小镇自然语言的进一步识别，但是考虑稳定性效率成本等

多智能体交互需要环境（可以理解成世界），频道的定义就是类似于这个环境，它一样有自己的知识库，再结合智能体本身知识库一起，也可以上传资料库。

这里的演示以自动化运维场景作为例子。

业务场景

我平时需要运维管理项目的发布，还有数据库备份，代码备份，查看项目运行情况，还有统计项目等有了这些之后，每周客户例会还要汇报各种结果，每日运行情况等。

工作痛点

项目Jenkins任务多，上千个任务项目需要找，另一个是文档导出麻烦格式编写不一，问题处理建议和历史工单需要很高经验工程师才能结合。

愿景期望

运维部分已经自动化

1. 可以理解意图，自然语言获取到制定的项目
2. 结合经验导出相关文档和处理建议

智能体需求

1. 获取到想要处理的项目
2. 获取到制定报表
3. 历史工单经验结合

这里主要为了演示多Agent效果，这里虚拟出项目管理的角色、数据库备份的角色、代码备份角色、k8s巡检角色这4个。

先将多个角色拉入到同一个频道中。先理解意图获取到指定的项目：

将任务提交给不同的角色执行，获取到报告结果

多智能体交互主要依赖json标准格式，上下文内容上需要设定和输出，其他的自动化能用原有的就使用原有的。

4. 智能体角色开发模式和例子

智能体角色开发，这里针对的场景是偏向于多业务场景。目前大概做的流程和方式：

1. 合适的业务场景梳理和细化
2. 数据采集整理
3. 智能体角色开发

前面两步各有差异，这里不做阐述。

听过智能体平台设置角色，包括基础信息，还有知识库等。

角色的开发定义了三个方法，每个角色开发类继承一个主类，下面是定义的方法类：

1. 交互
2. 修改
3. 执行

实现对应的方法即可，以下为例子：

每个场景写好自己的角色包既可以，最后进行界面调试。

每个智能体角色也可以单独对外引用，作为客服之类的，比如：

这个开源的官网集成的例子，在开源代码库中也可以找到。

5. 下一步的愿景和规划设计

这步还在验证阶段

到这步，会发现，单个和多个智能体就已经可以结合起来，也同步可以运作。我的角色变成了设计规划，还有任务安排，还有审核角色等，到这步会发现，这个更加类似于OA审核。

如果集成层智能体是执行，那下一步建设和形成的目标就是上层智能体角色，用于整体智能体角色的协调。

在多个角色场景形成自动化之后，下一步就是集成类似的智能体产出计划和任务安排给多个智能体执行，输出到结果汇合到OA系统，回退和集成。

这也是为什么不用三方类似dify等平台的原因，做可控自定义平台的原因，主要不是推翻现有业务，而是提升现有业务，场景过多和复杂，需要针对业务场景多、细、稳。

超级自动化或是全自动化这也是对下一步的愿景和期望。

总结

以上为接触大模型为了解决本身遇到的问题的整合思路和产品设计思路，每个设计师有自己的设计思路，以上为个人经验分享，期望有兴趣的同学可以多交流。

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

前言

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

概述

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

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

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

阐述从这几个维度进行，分别是【业务_智能体_产品_原型】这样的思路：
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来进行管理。 过程设计每个模块会设计成单独的服务，也就是这样的，方便形成积木类似的软件组合，其他缺少的，按接口和规范引入即可。

以下为智能体团队：

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

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

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

总结

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

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

概述

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

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

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

电子书地址：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能力等；
• 业务服务结合数字化创新解决方案；
• 提供技术支持和项目解决方案支持；
• 提供过程技术指导和落地方案；
• …..

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

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

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

其它

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

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