我对智能体产品整体设计思路

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

背景

智能体平台是从原来的研发平台，再到超自动化平台演化而来的，在新产品升级设计超自动化过程中，结合LLM技术而进而定位。

阐述主要是给对应的合作伙伴更加的了解AIP产品的使用场景，新来的团队成员更加清楚这个是做什么的。

概述

智能体让原来的平台进行自动的演化成长，基础能力包括以下部分：

感知能力：通过传感器或其他方式获取环境信息。
决策能力：基于获取的信息和内置算法进行决策。
行动能力：根据决策结果采取相应行动。
学习能力：从经验中学习，不断优化自身的行为策略。
适应性：能够适应环境变化，调整自己的行为模式

新的智能体思路相近，为了更加明确和定位，进而形成智能体平台方向发展。以下为智能体平台的整体产品架构：

这里结合了平台思想、数据治理、技术研发、自动化运维等一系统平台结合起来。

针对场景和愿景

主要定位还是在中小微型团队，中小微团队情况比较多的是有开发能力和商务能力，给团队提供基础平台建设、架构设计和解决方案能力，以提升市场竞争能力。

业务上赋能上层业务智能体化，可结合业务定制化多种场景的智能体，在原来的业务智能化，提升业务的服务能力。

智能体平台产品设计

产品设计主要包括几大模块，用于不同的场景使用：

智能体平台
1. 智能体交互
2. 管理平台
技术底座平台
1. 开发平台
2. 数据治理
3. 运维管理
4. AI平台
5. 运营管理

产品设计原型

整体的管理面貌，理解与智能体交互需要不断的匹配场景的工具。

智能体平台

我们先定一下术语：

频道：多智能在一起是一个频道，类似于群的概念
ChatBot：聊天交互界面

智能体交互是对外的最终体现，也是与人交互的方式，界面相对比较简单，这里只设计了三个界面：

频道市场
智能体市场
聊天交互

以下原型界面，这里参考了扣子的界面设计，集成多智能体交互：

这里主要还是参考的其他平台的界面设计，再点击最后进入交互界面。

智能体管理平台

这里用和管理分开。

场景是内部团队和企业，智能体的定义由管理员（或是部门/成员）进行管理。

形成统一归纳，统一建设，统一使用。

管理平台主要是智能体的设置和管理，这里跟互联网产品有些不一样，定义智能体以专业人员或是管理员为为主，每一个智能体进行优化处理。

一定要以解决业务场景为主（有用才行）。

智能体的管理由内部研发团队做管理或是外部人员管理，对团队或是企业内部以实用为主。

每个智能体会带有以下特点：

明确细分场景
明确输入输出

这样以形成交互，另外形成内部有效管理，规避发散和不统一性。

以下是智能体管理平台，包含智能体的Prompt定义和流程定义，这里主要还是以Groovy脚本为定义，还有多引用自定义工具为主，这里主要考虑的是针复杂的综合业务场景，可能更加灵活：

技术底座平台

底座机智来支撑智能体平台运作，这里涉及数据、技术、工具等，出来的智能体需要符合团队，场景，能提升效率，解放人力，提高服务水平。

底座的产品设计：

底座的设计集成包括

技术平台设计
中台架构设计
数据治理设计
智能AI集成
DevOps设计
微服务设计等。

以简单为主，容易为辅，高扩张性。行情因素，同时支持国产，信创路线。

技术平台设计

开发平台是无法缺少的，这个主要是用于结合业务场景的对接框架，编程接口，智能体需要与各个综合治理业务系统衔接，整合。

数据治理平台

企业数据的处理，知识库，还有系统数据，业务数据等，数据服务输出，需要数据治理管理思维，形成企业数据资产，提供业务、智能体平台进行使用。

运维管理平台

系统运维管理，自动化运维机制，智能体交互，年报周报，报表，工单等，由智能体进一步的优化提升过程问题处理，处理质量，处理建议，问题自动处理等，提升服务体验。

AI平台

这里主要是对数据采集，流媒体、NLP、OCR、开发平台等多个数据识别采集，做一些模型训练使用，便于统一管理，同时提供物理世界上的交互，比如流媒体识别，空间识别，包括一些用户画像等。

运营管理平台

整个智能体平台运营管理，使用管理还有各种文档输z出，教程材料等，使用情况，产品的对外综合管理等，用于平台的总体输出管理。

总的来说，底座平台提供了智能体平台的感知能力、数据能力、执行能力、反思能力、自动化能力等，综合为上层提供能力。

总结

从最初的研发平台逐步演变，并引入了先进的LLM技术，为用户带来了前所未有的智能化体验。这一平台的核心在于通过感知、决策、行动、学习以及适应等基础能力的构建，实现了平台自身的不断进化与发展。

专为中小微型团队量身定制，提供了一套完整的解决方案，从基础平台建设到架构设计，再到具体的业务场景应用，均覆盖其中。通过赋能上层业务，平台不仅能够实现业务流程的智能化改造，还能显著提升服务质量，增强企业的市场竞争力。

平台以其灵活的设计，为中小企业提供了提升效率、降低成本、优化服务的有效途径。它不仅是一个工具集，更是推动企业向智能化转型的重要力量。

我对多智能体交互与开发设计方案

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

前言

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

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

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

概述

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

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

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

https://github.com/alinesno-infrastructure

智能体交互设计

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

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

这里的我只是通用型例子

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

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

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

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

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

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

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

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

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

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

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

业务场景：

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

工作痛点：

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

愿景期望：

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

智能体需求：

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

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

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

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

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

最后生成Excel下载：

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

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

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

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

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

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

业务场景

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

工作痛点

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

愿景期望

运维部分已经自动化

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

智能体需求

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

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

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

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

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

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

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

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

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

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

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

交互
修改
执行

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

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

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

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

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

这步还在验证阶段

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

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

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

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

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

总结

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

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

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

前言

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

概述

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

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

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

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

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

场景结合

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

业务场景结合设计方案

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

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

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

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

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

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

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

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

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

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

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

设计说明：

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

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

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

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

智能体产品设计方案

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

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

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

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

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

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

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

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

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

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

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

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

智能体门户设计，包含管理入口，SaaS化管理和组织管理。

推理管理平台，形成模型的管理和角色推理逻辑和分析。

数据治理体系，针对于中小型团队的数据治理方法论的落地和实践。

数据资产服务，提供数据资产管理和服务管理。

软件开发体系，技术研发框架和自动化设计。

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

以下为智能体团队：

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

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

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

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

总结

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