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

概述

DeepseekR1使用之后，发现推理能力效果比较突出，费用也比较低，之前是基于普通大模型的推理方式估计也要升级，这里写的是前期的设计思路，留个复盘稿。

推理过程主要使用的是ReAct和Cot两个方式，另外加上交互形式使用约定思维修改模式（Thinking Claude开源项目），也达到一定的推理效果，Cot相对比较简单，这里主要介绍的是ReAct的结合，从下面的维度和例子进行阐述：

1.对话结合方式和Prompt设计
2.框架设计和代码设计及工具设计
3.频道对话效果演示

原来基于一些论文和开源项目的参考，每个架构师设计不一，我有我思。

设计思路

这里考虑到通用型，不会使用过多的大模型特性FunctionCall，只是基于Prompt和大模型的推理，前期也会有一些的限制（解析准确性），但是目前的模型发展、推理能力的加强和使用情况，基本上限制微乎其微。

对话结合方式和Prompt设计

看过crewAI的同学会看到使用的是langchian，开始也是考虑使用这个，但是发现langchian4j这方面机制还不怎么成熟，另外解析方式也不是自己想要的类型，基于 java和groovy自己写了框架，主要是：

1.对话解析
2.工具使用
3.对话结合

下面是对话的Prompt设计，初始模版稿：

过程会根据对话结果进行不断的内容调整，以下为处理逻辑：

思考模式放在through字段，以finalAnser作为结果字段输出，循环按约定次数或是自定义次数。
工具也一样的解析注解形式，通过groovy编写工具然后提交给Prompt，下面是工具的例子：

大部分目前基本上都是类似，只是说使用哪种语言作为主要设计语言和方案。
那最后结合起来的方式，形成角色设计界面，做目标和初始设计，然后结合自定义工具。

在这个过程，基本上可以定义好我们想要的角色。到这步很多情况下对话推理已经达到了。
但考虑更偏向于人类思维，结合了Claude开源项目的约束设计，这里主要放在 promp的system中，这个是一个固定的模式，达到接近于人类的思维逻辑，加与不加效果目前没做过对比，是先加上。

框架设计和代码设计及工具设计

下面是一些设计的思路和代码，会包含有chatbox框，还有ReAct的解析类，还有工具类的设计约束。工具类的注解类设计，还有方式设计：

一个关于查询订单、演示demo，客户时间预约的工具类的例子，下面是客户预约的代码：

角色过程中还会接入记忆能力和知识库，这个是跟其他有些不一样的地方，关于记忆处理方式，这里不做过多的介绍。

这里偏向设计，代码部分不做过多的阐述。

频道对话效果演示

我们这里设计了两个角色：

• 通用查询的角色：可以通过搜索引擎来查询实时内容，比较常见的例子。
• 产品导购的角色：引到客户预约演示和查询订单的角色，也是通用型场景。

下面是通用查询的角色的查询方式，会自动去网络查询内容并返回结果分析：

定义了两个角色之后，把他们拉到一个频道做验证，下面是角色拉入频道 ，下面是导购的交互模拟：

从演示效果上的情况看，这个基本上能达到交互的效果，也有推理的场景，对话上还是有一定的推理体现。

总结

目前在使用的是qwen大模型，在测试过程中使用的是最为通用plus版本的模型能力，但是查看目前的o1和deepseek R1明显会有更好的效果，目前在研究接入和适配，也同样基于开源项目Agents-Flex（类似SpringAI）二次开发调试，以方便接入大模型规范。

以上为学习和研究大模型推理的应用场景和设计的一些思路参考，精力和思路有限，也期望有兴趣的同学可以互相交流。

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

临时笔记，会有一些口语化。

术语

• ReAct是结合推理和行动以提升智能体决策能力的框架，
• Handoffs机制是指多Agent系统中任务在不同Agent之间平滑转移的过程

概述

最近会遇到跟dify或是fastGPT的对比问题，会同类对比，AIP是目前在维护的开源多Agent平台，类似于crewAI平台。

每个设计师思路不一，Agent平台的概念容易与同类产品类比，其实不然。这里为了方便AI助手或是应用统称为Agent。这也是为什么会从零搭建Agent的原因，而不是使用现有dify或是fastGPT，前期设计大概以下几个场景：

• 类似 Agent来协助或承担工作，而不仅仅是聊天窗口而是工作台，需要针对很多场景的AI助手；
• Agent之间可以交互，过程可以审核，一定可以在生产业务结合解决问题；
• 跟现有业务的Agent场景闭环，从数据/工具/业务/推理形成闭环，业务高度定制化；
• 通过积累形成类似于业务自动驾驶，对某个业务场景的自动处理，形成业务超自动化；
• …

这些定位上，跟dify或是fastGPT会有比较大的设计差异，虽然在某些部分上，看起来类似，但总的差异还是比较大，每个产品的设计不一样，针对场景不一样，我有我思。

差异阐述

我所理解的Agent，是可以结合和解决到生活方方面面的，而不仅仅是chatbox（也许现阶段是这样），比如家居，会有一个家庭管家来管理生活方方面面。工作场景，应该是类似工作管家，根据我的情况完成我的工作。目前的AI结合貌似还不能达到这样，那退而求次，使用多个Agent来处理，下面我们从上往下阐述，体现差异点：

1.多个Agent来协助我的工作

可以使用现成平台来形成多个Agent角色，通过ReAct或是flow等方式，或是特定场景插件，比如Cursor，形成比较强的自动化，他可以分担我一部分工作了，下面形成Agent团队能力。

比如写文案得出初稿，市场分析，代码编写之类的，形成一版本，你会发现，你开始形成大量的prompt，提升效能，按使用体验来说，如果使用熟练的，从个人或是团队角度，这个时候效能已经提高很多。
可以透过聊天窗口，调用Agent角色完成工作，然后再进一步的结合自动化一起。

2. Agent之间可以交互

再建立很多Agent之后，角色开始变得很多。会发现有重复的或是需要协作，另一个是结果的不准确性，需要结合工作流审批，人工确认等，这个时候希望它可以进一步交互，类似Swarm的handoffs 机制（交接），让对话之间可以转移，还可以有上下文，但是又不能过于自由，因为我想交接到指定角色，就会发现有审批修改需求，如果能融入现有工作流就更好。
这个时候会发现，类似产品的无法形成上面的工作，或是比较难，他的设计场景不是为了这个而设计的。
这里的处理方式是拉入到同一个频道中，多Agent间共享上下文，另外可以相互交互。

我们需要融合业务场景，需要开发工具给Agent或是提供对应的API接口，在业务场景上来说，就需要很多定制化开发，能结合很多场景，这里给每个Agent保留了对话、审批、执行接口，可以根据业务灵活定制处理场景需求。
比如下面的Agent编写文案，然后内容重写、扩写场景：

上面的Agent修改和调整还是为同一个，这样内容更为灵活和自定义，结合业务起来更加方便。

3. 需要感知业务环境推理执行

环境的感知执行是Agent能力体现之一。

前期一直疑惑Agent跟城市大脑的区别，城市大脑需要N多的感知数据，触点采集，给模型推理，结果之后给人做参考执行，前期城市大脑、小脑的方法论，业务场景都比较全面，这里参考同样的设计。
LLM的推理能力相对于以前的城市大脑AI能力已经是非常超越，可以运用在各个场景下面形成大脑推理模块。
同类的，我们给每个业务场景都加一个大脑，会不一样，会形成每个行业业务场景都有一个贾维斯，即钢铁侠的人工智能，这将是一个行业格局的改变，有可能么？个人觉得还是有可能的。
好了，如何做这个推理大脑套件，类城市大脑设计，做了压缩版本或是轻量级的，如下图：

这里我们统一叫工作区，从业务的数据感知-推理-工具执行形成一个套件，这样在很多业务场景结合大脑推理套件，提高业务服务能力。
模块式分开的，非耦合性，大模型在这里的作用是推理能力，协调各个业务线进行。按理解，大模型的能力还为提高，类似o1，不断提升，后期业务也会随着科技的发展，AI的发展更加智能。

4.形成业务超级自动化

类似于一种期望，但是实现路径比较明确。

我们发现，结合Agent能力的业务场景，它会不断的学习（如果有LLM DevOps结合就更好），感知，成长。随着业务数据和推理的成熟，每个业务场景自动化智能化总会有最优点或是最高点，Agent在这个业务场景下的数量也同样有范围，形成一套Agent角色来支撑业务的运行。

这个时候达到超自动化的水平，或者换另一种说法，更接近于AGI，虽然不太喜欢这个词，但是概念上会更好符合场景，这个也是一个愿景和方向。
按当前的AI发展，推理能力的不断增强，业务场景的不断切入，路径会更加清晰，类似于汽车的L4级别发展历程，相对于汽车，业务场景上的成本会低很多，开发路线也会明确很多。

总结

以上为从设计到建设还有后期方向的说明，包括产品形态等，会跟当前的社区类Agent平台有一定的差异，当前在研发感知服务能力上，也就是上面的第3点，同时做Agent的优化。

每个设计思路不一，以为上个人设计的一些思路参考，有兴趣的同学欢迎交流。

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

背景

此内容为继续针对于(我使用Multi-Agent运营AIP的规划设计)章节的产品运营团部分。

团队建设

针对AIP项目对外内容输出，需要设立AIP产品内容运营团队，这些内容团队用于产品动态、对外宣传、SEO、视频、音频（电台），可以更好进行项目推广。

内容输出与公众号和博客不同，这两项是针对于个人心得体会，属于经验和心得型。内容团队主要针对于特定的AIP产品输出，偏于营销层面，后期由内容团队对产品品牌进行管理。

Agent团队建设：

• 数据采集专员：针对于数据内容环境数据的采集和管理，包括不限于节日数据热点事件、热点文案、电影等数据采集。
• 内容策划专员：确保内容定位和目标受众、内容类型还有方向等。
• 培训教程编写专员：针对于某个技术特点编写培训教程文案，提高技术文案输出。
• 产品动态文案专员：根据产品进度输出内容，让更好的对外表达产品进度和功能。
• 故事品牌专员：策划产品品牌故事，提升产品形象，加深对品牌认知和情感链接，海报设计提升品牌形象设计，还有海报的输出内容。
• 电台广播专员：广播电台，对话电台的形式内容，输出mp3。
• 内容发布专员：负责将生成内容发布到目前自家的CMS网站，统一对外出口

目前的设计先出第一版本，先做输出，后面根据情况添加或是删除，上面作为初始团队。

集成情况

以下为团队建设的基础，有这些基础，然后再进一步的升级，添加管理者智能体（或是路由agent）分配角色工作，运营团队主要是解决AIP产品自动运营的问题。

以下为集成效果，将多个角色拉到一个频道，角色之间的信息交互，包括品牌故事，形成小红书文案，产品更新内容，产品动态等。

集成发布内部管理平台，由多个角色交互，还有产品动态等。比如发布小红书，形成对外渠道之一，下面是小红书界面：

触发事件处理，针对于定时任务，由观察者智能体来获取到目前的信息，包括节假日、各种信息情况等，处理是否往下，还有做初步的处理，以下为流程图：

目前团队还是基层组织，定位于辅助人还有完善阶段。还在集成其他自媒体平台，包括CSDN、简书等，计划成立AIP产品自己的电台，发布到喜马拉雅形成AIP自己的电台频道。

后期计划，在现有运营团队的情况下进一步更加稳定，后续添加管理者来进一步的协调，包括圆桌计划。另外会考虑流量截取还有热点话题的克隆，当然，这个是在整个流程比较成熟的时候，再进一步的优化。

总结

这是AIP的运营初始团队，AIP本身是一个开源的项目，缺少公司级别的专业运营，智能体团队以用来解决社区团队缺少运营人员的问题，涉及到的技术包括RAG、智能体、RPA等，目前是智能体团队试运行阶段，也期望有兴趣的同学互相交流。

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

此为当前设计及往下编码的手稿方向，为临时记录，避免后期遗忘

术语

这里定义智能体记忆与知识库的区别:

• 智能体记忆：存储智能体个人经历和学习到的信息，帮助它根据过去的经验做出决策。记忆是动态的，可以随时间更新或遗忘。
• 知识库：包含结构化的通用知识和规则，提供给智能体或其他系统查询使用。知识库内容较为静态，旨在为决策提供支持，不直接参与学习过程。

输入输出架构

目前AIP的集成的智能体模型，包括配置的Prompt模板也以下面的模型为基础框架，如下：

基于上面的智能体模型，对智能体记忆模块进行重构设计，使得更符合真实场景，以下为设计思路。

记忆能力场景

为了能更方便的进行智能体角色的复制转移，这里将涉及到智能体本身关联的信息分为感知记忆、关联记忆、临时记忆、短期记忆、长期记忆、静态记忆等。

• 感知记忆(perceptual): 短暂存储通过世界接收到的信息，如视觉或听觉刺激，持续的时间并不长。
• 对话记忆(conversation): 记录交流互动的内容，包括言语、语气和情感状态，支持上下文相关的对话理解。
• [重点]观察记忆(observation): 通过分析对话记录形成的记忆，帮助记住物体的位置、动作序列和社会行为规则。
• [重点]反思记忆(insight): 涉及从观察中获得的深刻理解和顿悟，指导未来的决策和行为。
• [重点]长期记忆(longterm): 能够长时间保留信息的记忆，涵盖事实性知识技能和经验，具有较大的容量和持久性。

以下为应用架构的设计，包括推理服务与记忆模块的集成设计：

上面有三个平台结合：

• 专家服务: 定义Prompt工程还有角色的平台，提供对应的IM交互平台
• 记忆服务: 用于数据保存还有记忆保存的平台，还有RAG,ReRank等
• 资产服务: 针对不同的场景并通过DataOps流程出来的数据内容

为了更好的设定智能体的角色，同时更方便理解，按以下流程进行描述设计思路，也方便阐述：

• 记忆采集: 数据采集方式和使用的技术方式
• 记忆处理: 当中推理处理的过程及输出、保存到向量数据库的过程
• 记忆查询: 角色在调用过程中针对不同的场景查询过程

当前的设计为总体的方向设计，后期会进一步进行优化处理，但是整体的设计不变，会不断优化过程，每个设计师思路不一，我有我思，期望有兴趣的同学一起交流学习。

记忆处理设计

这里是设计的整体细节。

记忆采集

数据采集之前需要先设计记忆模型，便于了解需要采集哪些数据项，这里的模型参考MemoryScope项目的模型，以下为模型实体类，以下模型会由LLM形成树或者图关系，通过向量库形成初步记忆能力。

数据模型

MemoryNode 类字段说明

• memoryId：记忆节点的唯一标识符，使用UUID生成。用于区分不同的记忆记录。
• userName：表示记忆所属的用户名称。
• targetName：记忆的目标或对象名称，可能是指特定的人物、事物或事件。
• metaData：用于存储记忆的相关信息的映射表，如时间、地点等附加信息。
• content：记忆的内容文本。
• vector：记忆的向量表示，可能与keyVector有区别，具体视业务逻辑而定。
• key：记忆的键，可以存在多个键，具体作用视业务逻辑而定。
• keyVector：记忆的向量表示，主要用于向量搜索和相似度计算。
• value：记忆的值，与键（key）相对应，存储具体的记忆数据。
• memoryType：记忆的类型，用于分类记忆。
• actionStatus：记忆的当前动作状态，默认为”none”，其他可能的状态包括 “new”, “content_modified”, “modified”, “deleted”。
• storeStatus：记忆的存储状态，默认为”valid”，表示记忆是否有效或已被删除等。
• timestampGenerator：静态的时间戳生成器，用于为每个记忆节点分配唯一的时间戳，确保在系统中是唯一的。
• timestamp：记忆节点的时间戳，由timestampGenerator生成，确保每个记忆节点的时间戳唯一。
• dt：记忆的日期时间字符串，格式为”yyyy-MM-dd”，便于按日期查询记忆。
• obsReflected：观察到的记忆被反射次数，用于记录记忆被引用或重现的频率。
• obsUpdated：观察到的记忆被更新次数，用于记录记忆内容被修改的频率。
• latitude：位置的纬度坐标。
• longitude：位置的经度坐标。
• scoreRecall：记忆的召回分数，用于衡量记忆被检索出来的可能性。
• scoreRank：记忆的排序分数，用于对记忆进行排序时参考。
• scoreRerank：记忆的重排序分数，在某些情况下用于重新调整记忆的顺序。

重点说提到几个字段：

• key: 会存在多个key实体信息，用于关联查询出涉及到当前key其它记忆信息，对key向量化，key相对于实体信息来说，将不同事件或信息片段链接起来的记忆，支持模式识别和因果关系的理解。(比如通过A关联到A以前相关的信息)

模型放到一张数据表中，便于后期的记忆数据迁移还有模型的复制。

采集数据

采集数据从几个方面的采集，主要包括聊天消息记录的采集，角色设定的采集，外部知识库的采集等。

1. 感知数据：主要从数据资产中采集到数据，同步给智能体，并针对于当前环境的感知情况，生成新的记忆，并保存到向量数据库中，通过时间来做一定的聚合限制。
2. 对话记忆: 采集方式通过聊天Event事件的形式，进行推理处理，每个事件会生成一个MemoryNode实体，最终生成新的记忆，并保存到向量数据库中。
3. 观察记忆: 通过对话记忆的进一步提取，然后获取到最新的信息，形成新的记忆，并保存到向量数据库中。
4. 反思记忆: 定时任务形式的通过一段时间的观察记忆进行提取和总结，生成新的记忆能力，确保记忆片段不矛盾和重复
5. 长期记忆：通过数据资产提供技术知识能力，获取到最新的记忆，包括更新前期的记忆生成新的记忆，并保存到向量数据库中。

以下为主要的两个采集说明，一个是对话，还有长期记忆。

1. [会话]对话方式临时的数据会先保存到推理服务的，用于当前会话交流，获取到的记忆主要为前期的记忆模式，通过Event事件传递到记忆服务。
2. [分析]记忆服务将事件进行队列中进行消化处理，进行推理分析，获取到对话数据、反思记忆、观察记忆、长期记忆，并进行持久化存储。
3. [分析]数据资产会不断的采集场景下的数据，并推送到记忆服务，进行推理分析，然后获取到技能、知识库等，形成长期记忆。

记忆处理

记忆的处理包括两部分，一部分是解析记忆信息，另一个部分是记忆持久化。

解析记忆信息

这里的解析使用LLM进行解析处理，这里并不涉及到角色，只需要针对性的提取信息，设置以下Prompt。

当前只是设计阶段，所以Prompt暂时未设置，主要是参考Mem0和MemoryScope的Prompt的处理。

• 感知数据解析Prompt
• 对话信息解析Prompt
• 反思记忆解析Prompt
• 观察记忆解析Prompt

说明:

• 长期数据目前暂时不用配置解析，这部分通过数据资产进行采集，然后进行推理分析，获取到长期记忆。
• 反思数据会根据定时任务来进行解析，如果已经解析过的任务，会添加标识，使用。

主要解析以下的信息字段：

• key: 关联的key信息，用于关联查询出涉及到当前key其它记忆信息，对key向量化，key相对于实体信息来说，后期通过key来进行索引

解析之后，生成新的MemoryNode实体，然后进行向量数据库的持久化存储。 解析的方式会先放到队列中进行缓存，目前设定的记忆的数据是允许有丢失的情况，以内存队列的形式进行处理。

智能体交流记忆信息

解决的记忆内容：观察记忆(observation)和反思记忆(insight)

下面是跟AIP导购销售专员的对话过程，对话信息:

AIP导购销售专员: 你好，我是AIP产品导购销售，很高兴认识你
软件工程师罗小东: 你们有哪些产品，简单介绍一下

AIP导购销售专员: AIP是我们推出的一款智能体平台系统，旨在推动企业的超级自动化转型和创新发展。它提供了Agent管理、智能体开发工具、测试环境、运行平台和协作工具等功能，帮助企业提高竞争力、降低成本、支持创新和业务拓展，并提升团队协作效率。如果您有兴趣了解更多详情或有任何疑问，欢迎留下您的联系方式以便我们后续跟进。
软件工程师罗小东: 我是做传统业务的，智能体对我有什么好处

AIP导购销售专员: 请问您的传统业务具体是什么？这样我可以更精确地说明智能体技术如何帮助您的业务。
软件工程师罗小东: 做的社保的管理系统，但是技术比较老旧，我怎么样才可以使用智能体技术创新的，你们的产品能提供哪些帮助

AIP导购销售专员: 我们理解您希望通过智能体技术创新来改进现有的社保管理系统。AIP产品可以为您提供一系列服务，包括但不限于智能体开发工具、测试环境、运行平台和协作工具等。这些功能可以帮助您实现自动化流程、提高数据处理能力、优化管理决策等目标。为了更好地满足您的需求，请具体说明您希望在社保管理系统中实现哪些方面的创新。
软件工程师罗小东: 我想在社保管理系统中添加自动能力，还有AI人工智能能力

AIP导购销售专员: 为了更好地帮助您实现社保管理系统的自动能力和AI人工智能能力的集成，我们需要先了解您具体的需求。比如，您希望利用AI进行数据分析预测还是自动化处理某些业务流程？请允许我们记录您的联系方式，以便我们能够为您提供更详细的信息和后续的支持服务。
软件工程师罗小东: 这个是我的联系方式 小东 12345678901

AIP导购销售专员: 请问您的全名是什么？以便我为您保存相关信息。
软件工程师罗小东: 罗小东

AIP导购销售专员: 感谢您提供的联系方式，罗小东先生。我们已经记录了您的信息，后续会针对您的需求提供更多关于AIP产品的详细资料，并解答您的任何疑问。

上面的场景针对的是[AIP导购销售专员]需要保留这段记忆，下面是记忆的处理流程。

明确提出的一点，这里信息是[AIP导购销售专员]对[软件工程师罗小东]的记忆信息，提取出[软件工程师罗小东]的信息，保存到[AIP导购销售专员]insight记忆里面，按以下流程处理：

• 从ObservationWorker中获取到[罗小东]基本信息，放到观察记忆里面
• 从InsightWorker中获取到[罗小东]的更深层信息，放到反思记忆里面

总结出来的[AIP导购销售专员]对[罗小东]的记忆信息是:

软件工程师罗小东的联系方式是12345678901
软件工程师罗小东希望在社保管理系统中添加自动能力和AI人工智能能力
软件工程师罗小东是一名软件工程师
软件工程师罗小东的技术比较老旧。
软件工程师罗小东的业务是做社保的管理系统。
软件工程师罗小东希望通过智能体技术创新来改进现有的社保管理系统。
软件工程师罗小东希望利用AI进行数据分析预测和自动化处理某些业务流程。
AIP产品可以帮助软件工程师罗小东实现自动化流程、提高数据处理能力、优化管理决策等目标。

后续根据关键字进行关联查询。

长期记忆

解决的记忆内容：感知记忆和长期记忆，这里也可以理解成知识库，为了更好管理，我们统一划分到记忆体系中。

同样针对的是AIP导购销售专员，他需要知道一些知识，比如：AIP是什么？ AIP能做什么？为了初期的方便，这里内容统一由官网提供数据。通过数据治理体系处理，这个过程相对就比较简单一些。

以下为ETL处理过程:

清理之后获取到数据资产信息，放到资产平台，也方便其它服务后缀使用。从数据到数据资产形态，这个过程为单独的流程，针对于业务场景需求， 感知数据的处理也类似，也会转换成数据资产，方便其它智能体直接获取。
单独建立一个流程将数据导入到智能体长期记忆中， 以下为数据资产到长期记忆和感知记忆流程。

后续可能会还有其它的数据资产接入，比如团队信息，这里统一在角色的流程里面进行调整。为了数据隔离还有数据的访问权限控制，在智能体[雇佣]时，数据抽取流程不会被复制过去。

总结

智能体的记忆模块的重新设计会更加的符合业务场景，还有相对拟人的角色思考过程， 这些只是初步的设计方案，感觉并不是特别完美，还有一定的优化空间，比如MemoryBank模式的考虑，另外是否使用图数据库等，这些都可进一步优化，目前来说，在技术预演过程中有一定的效果，也期望有兴趣的同学可以多流程。

鸣谢

主要参考以下项目

• MemoryScope
• Mem0
• ai-town
• GraphRAG

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

术语

这个是相对于人才市场，工作和团队场景来说。

• 智能体人才市场：类似于人才市场
• 智能体员工：类似于组织内部员工

比如政务部门多组织内部，信息技术部门给业务部门建立智能体或是共享智能体。

概述

这个是针对于内部团队的场景，在当前组织里面有很多场景和角色，其他组织也想体验，面对这样的情况，需要建立一个交流机制，用于促进智能体角色的交流。

为了更好的阐述和概念理解，类比人才市场做的功能设计：

• 可以到智能体人才市场选智能体
• 可以分享智能体员工给其他组织
• 可以私下推送智能体给指定组织

这个设计的场景是为了更加贴近工作或是业务场景模式，每个设计师思路不一，我有我思。

场景设计

通过创建智能体市场，个人用户或组织能够发布并管理自己开发的角色。管理员可通过后台系统对这些智能体进行分配和管理。

一旦某个智能体被录用到组织，它将自动成为默认组织的一部分，用户可以在不同的频道中选择和使用相应的智能体员工。

自己个人新建立的角色可以分享如下所示：

从组织管理员后台进行分配管理，以下是智能体市场：

每个组织添加之后，会自动加入到默认组织，在频道里面可以选择对应的智能体员工。

总结

智能体人才市场结合工作场景设定，便于角色的共享和交易，包括团队内多组织的配合，从多角度连接的工作环境。

以上为我对智能体人才市场的设计，每个设计师思路不一，这里提供参考，期望有兴趣的同学多交流。