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

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

概述

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

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

智能体模型设计

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

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

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

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

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

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

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

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

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

解决方案编写示例

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

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

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

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

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

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

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

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

结尾

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

说明

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