智能体开发流程规范及示例

前言

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

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

也期望可以了解同行多一些实用性案例。

概述

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

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

例子和代码统一上传到github基线，方便有兴趣同学可以互相交流，每个设计是思路不一，我有我思。

智能体交互设计

原来设计的思路是需要灵活的设计能力满足不同场景，能结合现成的业务提升，满足自身工作需求，另一个是把自我抽取出来。以下会结合【我】这个个体来进行例子编写，以达到更好的表达效果.

注：这里的我只是通用型例子。

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

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

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

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

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

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

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

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

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

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

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

业务场景：

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

工作痛点：

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

愿景期望：

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

智能体需求：

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

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

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

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

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

最后生成Excel下载：

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

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

好了，我们发现单个智能体已经可以做标准输出，多个智能体交互通信就方便了。也考虑过类似AI小镇自然语言的进一步识别，但是考虑稳定性效率成本等

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

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

业务场景

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

工作痛点

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

愿景期望

运维部分已经自动化

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

智能体需求

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

这里主要为了演示多Agent效果，这里虚拟出项目管理的角色、数据库备份的角色、代码备份角色、k8s巡检角色这4个。先将多个角色拉入到同一个频道中。先理解意图获取到指定的项目：

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

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

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

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

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

前面两步各有差异，这里不做阐述。先在智能体平台设置角色，包括基础信息，还有知识库等。

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

• 交互
• 修改
• 执行

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

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

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

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

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

到这步，会发现，单个和多个智能体就已经可以结合起来，也同步可以运作。我的角色变成了设计规划，还有任务安排，还有审核角色等，到这步会发现，这个更加类似于OA审核。 如果集成层智能体是执行，那下一步建设和形成的目标就是上层智能体角色，用于整体智能体角色的协调。

在多个角色场景形成自动化之后，下一步就是集成类似的智能体产出计划和任务安排给多个智能体执行，输出到结果汇合到OA系统，回退和集成。 这也是为什么不用三方类似dify、AutoGen平台的原因，做可控自定义平台的原因，主要不是推翻现有业务，而是提升现有业务，场景过多和复杂，需要针对业务场景多、细、稳。

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

总结

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