Agent--对话驱动协作机制

之前我们提到过多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很可能就能提高完成复杂任务的成功率