之前我们提到过,多agent之间的信息流是以自然语言为基础的多轮对话,这里要明确的一个点是,对话在这里并非是辅助功能,可能会有人在接触到这个概念时以为对话是辅助agent理解文件、代码、任务等信息的方式,这个思考角度是把agent理解为了工具,而不是一个会“思考”的智能体。
对话是多agent运作的核心机制,agent之间通过结构化或者半结构化的多轮对话来理解任务、共享上下文、提出建议并输出结果,这个对话管理的质量很大程度上决定了整个多agent系统能否稳定、高效地运行并完成任务,这个很好理解,假如一个团队在协作完成项目时,沟通紊乱,输出信息不完整,彼此之间用的语言不同,给出的结果的形式也不同,就会极大阻拦推进任务。
在这种机制中主要体现出来的就是任务拆解,统一的消息结构。
任务的拆解与理解
在开始任务前,不管是单agent还是多agent,都需要先理解任务是什么,要做什么,才能去规划后续的行动。区别在于,单agent的自我规划相当于列任务清单,且如果其中一个子任务断开,很可能会使整个逻辑链条断开而导致需要重新再来;而多agent的任务拆解,则是把不同的子任务分配给不同的agent,如果其中有一个子任务失败了也不会影响到整体,只需该agent重新跑就好。 任务拆解的关键在于,其中拆解的颗粒度需要根据任务的性质来调整,不然拆解过细,会浪费许多agent的算力,拆解过粗,则可能会需要跑多几轮来完成这些子任务甚至导致结果偏离任务目标。并且拆解时就能明确哪些子任务需要哪个agent来负责,需要哪些信息来完成任务。
统一结构化消息的重要性
可能很多人会想,既然不同agent之间的职能不一样,那么为什么还要做统一信息结构这一步骤呢,这样子不是相当于是在浪费token吗?其实不然,的确,不同功能的agent,适配的消息结构天然就不可能相同,但是假如任务是模糊的,那每个agent都会根据自己的理解去选择输出格式,那么这样的消息结构再去被其他agent去理解的话,那就相当于每个agent接收到的信息是上一个agent所理解的,而不是同样在任务拆解时分配的,容易导致信息偏差;而在某些领域,结构化的信息,可以让agent省去读取上下文这一步骤,直接根据接收到的结构化信息就能够完成任务,提升效率的同时还能节省token。
终止条件
一般设计好的多agent系统,都会设置好明确的终止条件和轮数限制,轮数限制一般在5-8轮;常见的终止条件有:反馈审查agent不再提出任何问题或异议,代码成功运行并且满足所有测试用例,任务拆解时的所有子任务均已完成等。
值得一提的是,多agent系统还能做到局部的优化迭代,也就是说,很多时候可以改一个agent,很可能就能提高完成复杂任务的成功率