目前看到的和碰着的大模型交互大部分都是谈天佑理类，另一种是类似斯坦福AI小镇或是AutoGPT模式的，其他的可能便是运用型嵌入，还有观点视频类。在利用过程中创造，不稳定性，不愿定结果等，很难达到自己想要的生产稳定形式。斯坦福AI小镇和AutoGPT类型原来是自己最为期望的效果，但是生产上落地还有一定的间隔。
也期望可以理解同行多一些实用性案例。
概述原来打仗大模型本身是为理解决本身碰着的问题，本身的AIGC能力和推理能力刚好符合自身的需求，这里结合了AIGC、交互、推理、自动化、大数据、RAG、微做事等作为根本，有结合AutoGen、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、AutoGen平台的缘故原由，做可控自定义平台的缘故原由，紧张不是推翻现有业务，而是提升现有业务，场景过多和繁芜，须要针对业务场景多、细、稳。
超级自动化或是全自动化这也是对下一步的愿景和期望。
总结以上为打仗大模型为理解决本身碰着的问题的整合思路和产品设计思路，每个设计师有自己的设计思路，以上为个人履历分享，期望有兴趣的同学可以多互换。