如何实现多Agents协同？

引言：
Agents可以实现群聊了？多个Agents，多种技能，如何实现能协同工作？

GPT曾经上线了一个@的功能，可以通过@的方式来让不同的GPTS在同一个会话中回复用户的问题。乍一看，这是要往群聊的方向走了吗？
其实，在GPT上线这个功能之前，我们正在开发着多Agents“群聊”的功能，我们将这种类型的助理叫“智能协作”。
顾名思义，智能协作，就是让多个Agents通过协作的方式来解决用户问题的。用户无需单独找某个助理回答问题，也无需@某个助理处理。而是自动调度到能处理该问题的助理来为用户解答。

一、背景

大家都在做单助理回复问题，我们为什么做多助理共同体呢？
最初的原因就是，我们领导希望有一个万能的助理，可以处理所有问题。不管你问什么，不管你要处理什么，这个助理十八般武艺样样精通，只要你敢问，我就敢答。
……
这需求，简直是难为我们的开发团队了。
不过好在，有这种想法的不是只有我们的领导。
不知道大家对去年（2023年）比较热门的AutoGPT有没有印象呢。AutoGPT可以自动化和优化业务流程，生成测试用例，调试代码，甚至还能产生新的业务创意。将AI进程推向了新高度——自主人工智能。不过或许因为太自主了，不太受控制，问题还是非常大的，要实际应用，还是有一定距离的。
我们技术团队提出了另外一个解决方案：微软的Autogen。

二、了解Autogen

AutoGen是一个框架，可以使用多个代理进行对话，以解决任务。AutoGen代理可以进行定制，交谈，并且可以无缝地允许人类参与。它可以在使用LLM模型、人类输入和工具的各种模式下运行。AutoGen能够通过多代理对话构建下一代LLM应用程序，简化了复杂LLM工作流的编排、自动化和优化。它支持各种复杂工作流的对话模式，并提供了不同复杂度的工作系统。此外，AutoGen还提供了增强的LLM推理功能，包括API统一和缓存，以及高级用法模式，如错误处理、多配置推理和上下文编程。AutoGen由微软、宾夕法尼亚州立大学和华盛顿大学的研究项目共同支持。

简而言之，Autogen就是一个可以实现多Agents协同工作的框架。
我们需要做的是通过Autogen来将多个助理连接起来，共同工作，共同解决问题。
就相当于通过一个“领导”来“指挥”多个助理进行协同工作。

作为Agents框架，AutoGen有四个重要的优点：

1. 它简化了复杂LLM工作流程的编排，实现了自动化。
2. 借助可自定义和可对话的代理，它支持复杂工作流程下的对话模式。
3. 它提供了具有不同复杂性的工作系统的集合。这些系统涵盖了来自各个领域和复杂性的广泛应用。
4. AutoGen 提供了 openai.Completion 或 openai.ChatCompletion 的高级替代。作为增强型推理 API。
5. 它允许性能调优，API统一和缓存等实用程序，以及高级使用模式，如错误处理，多配置推理，上下文编程等。

三、实现过程回顾

说实在的，多个助理协同，实现“超级助理”共同体的做法，我们心里也没谱。领导的期望很大，我们心里很慌，技术团队就更慌了。连一些大大厂也是通过选择对应的助理来“工作”，我们却希望选择助理的这个操作交给系统或者大模型来实现，用户只是面对一个助理，在使用上无感。
虽然是确定使用Autogent的方式来实现了，但是效果怎样，谁都没有谱。既然决定做了，那就硬着头皮也得往上干了。
一开始，我们技术团队想着通过多个助理进行对话，最终由负责调度的助理进行汇总，并返回给提问者。

• 优点：多个不同助理之间进行协同，集成了多个助理的“智慧”，得到的结果更加丰富，更加智能。
• 缺点：消耗大，时间响应时间长，实现难度更大，结果不可控。

最终，我们采用的的方案是：智能协作助理通过助理描述和技能描述，直接指派给对应的助理进行回答。回答的助理是明确的，不存在多个助理同时工作的情况。

• 优点：消耗更少，实现难度小，响应时间更快，回复的结果可控（只需要把控回复的这个助理即可）
• 缺点：回复内容单一

举个例子：
1、方案1：假如在AIGC产品团队中，A熟悉LLM大模型，B熟悉向量化，C熟悉Function calling，D熟悉Autogen。当用户向leader提问时，团队leader把AIGC产品团队中的ABCD召集起来进行内部沟通，每个人都根据自己熟悉和擅长的领域各抒己见，经过多次讨论后，leader对沟通的结果进行汇总，然后再回复用户的提问。这个方案相当于“民主制”，大家讨论着来完成工作，共同决策。
2、方案2：假如E产品经理的综合能力较强，尤其擅长AIGC相关的内容，当用户向leader提问时，领导直接指派E产品经理来为用户解答，整个过程中，leader没有参与具体的工作，也没有进行内部沟通，而是直接指派给其中一个同事来解答。这个方案相当于“家长制”，由一个助理负责决策和调度，被指派到的助理独立负责执行。

四、产品设计及实际应用

4.1 产品设计

界面还是相对简单的，主要是连接多个助理，支持选择多个助理，并支持配置助理和技能。
实现智能调度的核心在于助理描述和技能描述。
因此，助理描述和技能描述的重要性就不言而喻了，能不能准确调度到对应的助理来解决问题，就看描述的是否准确了。

由于该智能协作助理只是调度，不参与具体工作（实际上是我们技术团队限制了其工作范围仅仅是“分配调度”，不让其参与更多的工作，避免出现幻觉或者发生其他幺蛾子），因此，后续的数据回流、标注该怎么处理？聊天记录的数据属于智能协作助理还是实际工作的助理？
因为面向用户的是智能协作这个负责“分配调度”的“领导”，因此，聊天的数据，它是保存了的。同时，如果要做数据回流和标注优化，那具体的数据还是得同步到具体执行的助理那里才行，而且数据集（向量数据）也是归属于执行的助理的。同样的，点赞点踩的数据也是智能协作的助理保存了，并同步给了实际执行的助理。

4.2 实际应用

我们在实际应用的时候，助理充当智能客服，为用户解答问题，回复的内容是公司内部的知识库。因此，一开始我只配置了一个文档类型的技能。
结果，在内测的时候，由于大家并不是处于具体场景下解决具体问题的真实用户，因此他们提问的问题可谓是千奇百怪。智能协作助理由于无法找到适合的助理来回复，因此，频繁回复“无法找到可用的助理”，给参与内测的伙伴的感觉就是——不精准、无法解决问题、回复太生硬。
我自我反思并且找技术沟通了一番，发现存在三个问题：①助理和技能的描述不精准，所以很难匹配到适合的助理；②通过描述来匹配助理，不够精准，还得非常熟悉助理所负责的业务以及数据集中的内容，要调得比较精准还是比较难的；③只开启了单个技能，一旦数据集中没有对应的内容，助理就会回复找不到助理，回复生硬。
后来我做了一些调整，用来提高调度助理的准确率，并且显得更友好，还能回复非数据集中内容。对用户来说会更友好。
主要调整如下：
1、同时开启了妙语、文档、联网、天气函数这四个技能；
（妙语负责非数据集内容的回复，文档负责数据集内容的回复，联网则负责最新动态或者询问日期的回复，天气则负责回复用户提问天气的问题）
2、助理描述描述调整，更加细致得描述该助理；
3、技能描述，分别对所开启的四个技能填写了详细描述。
经过调整后，由于助理拥有了更多的技能，用户在提问问题时，就不会“一问三不知”了，不管问到的是数据集中的内容还是非数据集的内容，抑或是实时内容或者天气的内容，该助理都能够对其进行回复。
经过调整后，用起来的体验就更好一些了。

五、总结

多助理协同，以一个“超级助理”实现更多问题处理的方式是一个不错的方式，我们希望减少用户的“选择恐惧”，让用户在无感的情况下得到更好的体验。
随着业务复杂性的增加，谁也不知道它能有多精准，而其影响因素也是非常多的：①助理提示词；②技能提示词/函数；③数据集质量；④数据集权限；⑤召回参数及数量配置；⑥大模型质量；⑦大模型参数；⑧助理描述；⑨技能描述。
由于影响因素较多，因此，一旦不够精准的时候，需要排查、调整和调试的地方也非常多。
要用好这个工具，路或许还有点长，但是只要方向不错，总是能越走越好的。况且AI大模型领域的变化日新月异，发展迅猛，说不定哪天就有更好的技术和解决方案了。

作者丨叶凌锋
原创文章，转载请注明来源“做产品经理”，并保留文章链接。