全新Agent框架，将知识图谱从知识获取来源直接升级为Agent编排引擎。

蚂蚁集团推出muAgent，兼容现有市面各类Agent框架，同时可实现复杂推理、在线协同、人工交互、知识即用四大核心差异技术功能。

这套框架目前在蚂蚁集团内多个复杂DevOps场景落地验证，同时可通过快速搭建的创新AI文本游戏“谁是卧底”游戏快速感受一下。

站在当前视角，LLM大模型能很好的解决通用单步任务（如SQL生成）、单步工具使用（如天气查询），但实际现实中的场景却是复杂多步骤的，尤其面向严谨专业私有领域，LLM只能给出泛泛而谈的答案（包括ChatGPT），面向C端体验用户可能问题不大，面向B/P端实际生产时却往往用处不大。

蚂蚁团队认为大模型就像才毕业的名校博士，具备优秀的基础素养，但却无法面向特定领域进一步学习，能够面向特定领域给出完善的任务规划决策。LLM能逐步协助人来解决问题或者Agent能实际解决问题，核心在于PLANNER推理能力。

人面向专业复杂事务处理具备丰富的经验，人的经验从哪里来？两部分：

• 老人带新人，特定问题、手把手教=>教会新人面向问题该如何处理

• 自我的摸索，文档阅读、交互探索，最终形成一条成功路径存于脑中

muAgent基于LLM+EKG（Eventic Knowledge Graph行业知识承载）驱动，协同MultiAgent、FunctionCall、CodeInterpreter等技术，通过画布式拖拽、轻文字编写，让大模型在人的经验指导下帮助你完成各类复杂多步任务。

muAgent整体架构

为了实现复杂多步流程SOP（Standard Operating Procedure）自动化，先来看SOP的构成。拆开抽象，任何任务流SOP的推进本质由三部分组成“经验”+“工具”+“人物”，衔接LLM推理，实现整体三者的有机结合。

经验：面向特定专业领域，复杂任务是如何操作处理？流程步骤是什么？
工具：在流程推进中，周边工具的使用，使用什么工具？如何使用工具？
人物：在流程推进中，周边人物的咨询，找谁（人、智能体）？问什么？

为此，muAgent整体的架构大图如下，和业界Agent框架定义对标，包含Planner、Memory和ActionSpace三大核心模块，以及Diagnose的调试监控和Interface的产品界面。

• Planner即之前提及的“经验”

• Memory结合Planner即“人物”

• ActionSpace结合Planner即“工具”

为方便理解，接下来通过“谁是卧底”这一AI文本游戏串联整个流程的介绍。通过简易画布拖拽加上轻文字编写，即可实现这一游戏的快速体验。中间的流程即刚才提及的“经验”，下方深紫框即“工具”，上方浅篮框即“人物”。

muAgent中的经验模块

面向不同行业、不同类型的工作流/SOP，该如何抽象统一，能够比较好地设计schema来存储经验知识？古语有云“授人以鱼不如授人以渔”，即应该设计存储“过程经验”，而非“结果经验”。相比存储状态结果，更应该告诉大模型如何来做一件事获得结果。例如相比于僵化的告知大模型今天天气如何，更合适的做法是教会大模型如何去查询天气。muAgent设计了“场景意图+事件流程+组织人物+统一工具”四大类节点，可满足不同场景所需的SOP经验承载。如下图所示。

由于任务流通常天然呈现为图或者树结构，因此muAgent采取图数据库来承载经验的存储。相比传统的RAG，或者微软的GraphRAG—-更多的是把知识图谱KG作为一个数据的来源—-muAgent直接把KG升级作为编排引擎。通过“拖拉式”“轻文字”编写实现特定领域复杂SOP的沉淀以及SOP的自动化。

有了经验的存储设计，就像有了人脑，接下来要解决知识的获取构建问题。muAgent提供两种经验构建能力。第一种是刚才提及的通过产品侧画布式轻文字编写；第二种是面向海量的存量文档，muAgent具备自动化抽取的能力，能将普通文本和流程图自动抽取转换为图谱结构。对于抽取的部分信息错误或者信息缺失，通过简易的编辑调试即可获取完善的SOP经验。

由于图谱的引擎设计自然继承了图谱的能力实现，在承载经验的同时，muAgent提供“经验拆分”和“经验合并”的能力。

我们期望模型具备一定的泛化能力，而不是告诉什么回答什么（类似DiFY固定僵化的任务流，同时不同于AutoGPT纯随机发散的推理），举个例子，当沉淀了“杭州旅游行程规划”后，那么应该抽象出“旅游行程规划”，在面对“北京旅游行程规划”的Query问题时，也应该能很好的作答。再发散一点，抽象原子经验“酒店订购、车票订购、餐饮选择”，那么在面对“北京差旅行程规划”时也能利用好原子经验进行回答！类似于告诉人一个特定问题的解决思路的时候，他会举一反三，我们期望拥有原子经验的模型也具备这一能力。为此muAgent提供“经验拆分”，通过“现象-任务-判断-结论”这一四段论的形式，结合下一小节的推理能力，实现在人的经验指导下的发散推理。

一千个人读哈姆雷特有一千个看法，如同盲人摸象，录入承载的经验更像是一个抽象类的具象化，更好的做法是将不同共建的经验合并来提供事物本质的模样。以旅游车票订购为例，距离较远的人会沉淀经验“车票订购-飞机”，距离较近的会沉淀“车票订购-高铁”，本地游的会沉淀“车票订购-地铁”，将这几个经验对齐合并，才能完整的形成原子经验“车票订购”。

有了经验的知识存储，接下要解决知识的利用推理问题。推理方面muAgent整体包含两大模块：

面向多层意图，支持“顺序+直接”意图定位；面向不同问题，支持意图分类（执行OR咨询）；面对模糊意图，支持反问用户以得到信息补充。

顺序OR直接定位：面向多层意图不同场景所需，可逐层顺序意图找寻，也可向量匹配+模型精筛直接匹配定位（面向意图描述设计不清场景）

执行OR咨询确认：不同场景Query意图不同。以天气查询为例，当用户问“帮我查一下杭州天气”时，muAgent会执行整个任务流，以获取最终的结果给出输出；当用户问“如何查看杭州天气”时，muAgent只会返回任务节点的流程步骤，而不做实际的经验执行，这一实现也可广泛应用于日常业务中老人带新人和答疑咨询等场景

基于用户沉淀经验，协同FuncCall，面向不同类型用户问题，多路推理（执行OR问答）。

游走推理：针对用户Query，LLM大模型按照节点文本描述、关系链接和属性配置实际执行任务节点（包括和工具、人物交互），并针对不同结果输出决策：是否本节点继续任务执行或者往下游节点推进（支持多分枝和循环）

发散推理：针对用户Query，自我编排推理。给予拆分出的原子经验，针对当前现象选择类似经验参考决策执行（支持Few-shot发散），并面向输出结果/新现象，循环思考执行（新的原子经验参考）

图谱问答：针对用户Query，大模型基于已经沉淀的图谱数据，自动检索相关内容，并以自然语言的形式回答用户问题（即KGQA,KnowledgeGraphQuestionAnswer）

muAgent中的人物模块

在任务流/经验推进的过程中，避免不了和“人物”的交互。muAgent中对人物的构成整体上可以分为三类：“智能体”、“用户人”、“企业人”。在谁是卧底的场景中，我们已经感受到了“用户人”和“智能体”，在这统一做下介绍和说明。

• 智能体：在谁是卧底游戏中只是简易的Prompt+LLM，在实际场景应用中，可以多层嵌套。Agent本身即是一套由muAgent构建的，赋予经验、工具和人物的能力；方便于企业级的团队协作场景，比如开发智能体、测试智能体、运维智能体等，在外还有一层整体任务流控制智能体。

• 用户人：设计之初主要面向于需要人参与体验互动的流程推进，比如AI文本游戏中的玩家。也可用于在线指导教学等场景，需要“用户人的输入”才可继续流程推进。

• 企业人：主要面向企业流程设计，包含“企业员工”和“组织架构”两部分。在实际中，不是所有能力都能被抽象量化为API接口，很多场景（比如任务审批流）还是需要人的参与审核、沟通，企业人的纳入，即需要咨询特定的人给出明确回复后才能继续推进。组织架构的纳入主要服务于人员变动，可以往上进一步追溯咨询。

什么是多Agent/MultiAgent框架？核心在于多Agent信息交互的实现。多Agent信息交互即多Agent讨论模式。

基于人类交流讨论的模式，muAgent抽象归纳出8种讨论模式，可同时满足不同场景信息隔离诉求（全部/部分/单独可见）。

• 公开咨询：由主持人公开咨询不同Agent回答

• 公开通知：由主持人公开通知不同Agent信息

• 私下咨询：由主持人私下咨询不同Agent回答

• 私下通知：由主持人私下通知不同Agent信息

• 顺序发言：由主持人触发Agent顺序公开回答

• 同时发言：由主持人触发Agent同时公开回答

• 自由讨论：由主持人触发Agent自由公开讨论

• 私下讨论：由主持人触发Agent自由私下讨论

这里又可以归结为两大类问题，信息通信（我能、应该看到什么信息？）和信息加工（我如何能更好的看到信息？），muAgent可通过属性的简单配置和边的链接来实现不同的场景需求。接下来，我们将通过谁是卧底的案例带大家整体认知下不同的信息通信模式。

公开通知：座位分配环节每个人都知道对方的座位在哪，由主持人统一分配，同时不需要针对分配结果给出回复。muAgent通过任务节点-信息隔离属性的“公开”设置实现。

私下通知：单词分配环节每个人只知道自己分配到的单词，主持人统一分配且知道每个人的单词，针对分配单词不需要给出回复。muAgent通过任务节点-信息隔离属性的“私有”设置实现。

顺序发言：分享讨论环节，主持人根据分配座位号，以及现场存活的人员，制定接下来发言的顺序，然后实际发起每个人的分享（需回复），每个人知道其他人的回复。这里新增一个工具使用模式的设置，将在工具章节详细介绍。

有了良好的信息通信的实现保障不同场景所需，接下来的问题就是怎么让人更好的看到信息。举个大家都会遇到的场景，突然被拉入一个群聊被艾特一个问题，需要从很长的历史长下文中梳理出我到底要干什么？那么有没有更好的方式，直接把上下文总结提炼好了从而一眼就能知道我要干什么？这就是信息加工模块存在的必要性。这里提供3种信息加工的模式（通过属性设置来实现），分别如下：

信息检索：找寻历史对话和当前Query相近消息，具体分为规则检索（如K邻信息）和模型检索（如向量检索）

信息加工：通过总结精炼历史对话信息实现信息快速理解，具体分为模型总结、信息精排（支持Prompt设置）

全局变量：通过全局变量的维护，方便快速知道变量当前状态来更好的服务规划决策，举个例子，谁是卧底里面当前存活的人员，或者狼人杀中女巫的毒药解药（如果不设置，当模型推理能力不强且游戏多轮后，经常容易搞错）

muAgent中的工具模块

介绍完经验和人物，还剩流程推进中的最后一环-工具。先从工具使用方式出发来介绍。目前业界整体的工作可以归纳为3种思考使用方式：

• 没有思考：针对问题直接给出单步决策，优势是速度快，面向固定场景能快速执行，缺点是不方便做单节点多步任务；通过任务节点-执行方式“单次”的属性设置实现。

• 谋定后动：针对问题直接给出完整的Plan计划，然后针对这个计划去实际执行，方便于限定场景，可实现多步任务执行，但不能根据中间执行结果的偏离做调整，通过“计划”和“并行”/同时执行的属性设置实现。

• 边想边做：即现在主流的ReAct模式，下一步的决策依赖上一步的结果输出。缺点是速度最慢，优势是可以灵活的根据中间步骤调整。通过“交互”属性的设置来实现。

• 工具注册方式：业界的实现基本上基于OpenAI定义的协议和规范，muAgent也不例外。muAgent遵循简化Swagger协议，方便不同的API工具快速接入。

• 工具注册管理：从大模型实际欠缺的能力出发，定义了5大类工具范畴（如大模型数值计算薄弱，对此提供沙箱执行环境，方便代码编写执行），分门别类管理，便于大模型工具选择使用。

随着以ChatGPT为首的闭源模型和Qwen等开源模型的迅速发展，去年研究火热的垂类模型或者定制微调（LoRA）在不断的弱化，很可能训练了很久都不如外部新版本迭代来的效果好。但面向工具场景，muAgent主打预置插件/工具，相同的模型见过的工具（微调）肯定比没见过的模型效果好，尤其是企业内部复杂的API工具。为此，团队搭建了多Agent自动化数据构建链路，实现给定插件，自动化数据构建（Q+A），模型微调服务。保障在专业场景工具使用效果的准确性和稳定性。

muAgent四大核心差异

基于上述的架构设计介绍，回看最开头提及的muAgent框架，相比现有市面各类Agent框架，四大核心差异体现在如下几个方面：

• 复杂推理：现有市面框架的推理逻辑有两大类，以AutoGPT为代表的纯模型推理（PureLLM），以及以DiFy为代表的固定推理（FixFlow），前者稳定性较差、同时面向专有领域无法服务，后者灵活性较差、和工程实现没有本质差别。muAgent采用图谱作为编排引擎承载知识，同时通过原子经验的设计以及图谱的发散推理，可友好的实现让大模型在人的经验/设计指导下做事。整体灵活可控，面向未知局面能自由探索，也将成功探索经验总结/图谱沉淀，从而面向相似问题可少走弯路。整体流程唤起支持平台对接（规则配置）和自然语言触发，能满足各类诉求。

• 人工交互：基于人物节点的设计（智能体、企业人、用户人）、不同信息通讯和加工方法，muAgent可以灵活的处理企业任务流的知识承载，让人能加入到流程的推进；同时又可灵活应用于多人文本游戏的创新场景研发。

• 知识即用：通过场景意图、事件流程、统一工具、组织人物四部分的统一图谱设计，muAgent能满足各类SOP场景所需知识承载，简易拖拉拽轻文字编写即可直接可用；同时面向海量存量文档（通用文本、流程画板等），muAgent支持文本智能解析、一键导入，以及经验拆分合并泛化。

• 多人协同：通过虚拟团队构建、场景意图划分，让你体验在线文档VS本地文档的差别；同时，文本语义输入的节点使用方式，让你感受有注释代码VS无注释代码的差别，充分体现在线协同的优势。

同时muAgent还提供调试运行功能。图谱编辑完成后，通过可视调试，能快速发现流程错误、进行修改优化。同时面向调试成功路径，可关联配置自动沉淀，从而减少模型交互/开销、加速推理流程；此外，在线运行中，muAgent提供全链路可视化监控，让排查和维护更加方便。