自由对话带来的问题
之前我们提到过，多agent的协作模式中有一个GroupChat模式，即几个agent可以同时发言，由一个ChatManager来统筹他们的思考，从而进一步促进idea的诞生。但是如果面对复杂度较高的问题，这个协作模式就会暴露出三个问题：
-
安全性问题：agent之间的自由对话缺乏限制，难以保证输出内容的准确性，同时由于可以自由决定调用工具，系统很难明确行为边界，一旦出现问题，很可能导致连锁反应，而不仅仅只是一次运行失败，需要重头再来；
-
稳定性挑战：多agent往往涉及多轮对话，但自由对话会导致无法设置合理的轮数限制以及终止条件，可能限制了这个aegnt，但另一个还在对话，依旧影响结果；
-
可控性缺失：多agent的自主对话，会使得系统的运转过程变成一个黑箱，人工很难介入去修正一些错误，一旦偏离预期，就需要从头开始。
所以，工程化对于多agent来说，可以说是必然的一种变化，不仅可以让流程更清晰，可追溯，也能大大提高系统的可维护性，这样系统才会让人信任，为多agent走进生产环境打下基础。
有限状态机（FSM）
这个结构会为每个aegnt设置一个状态，每个状态都会有一个测试条件，测试通过了才会进入下一个状态，进度的先后顺序是：规划状态→执行状态→检查状态，如果测试通过就结束，否则就进入修复状态，直到修复成功或达到修复次数上限。达到上限后，就进入人工介入状态，而不是让agent随机尝试修复。
FSM的关键就在于其错误恢复的机制，当某个agent被检测到测试失败时，会被标注为错误，FSM会自动将流程导回到该agent进行修正，这种回滚自动修复的机制可以减少消耗很多token，避免偏离任务方向，同时建立局部优化的机制。毕竟不管设计多完美，多精细的系统，都避免不了出错，这种状态的设计能让多agent根据具体问题进行调整，大大提高了容错。
图驱动编排
尽管线性的结构可以做到有条理，但这还不够，很多时候复杂任务是需要agent一边查资料，一边调用工具，调整决策，是处于多线路并行的状态的，如果还是强行按照线性流程去走，那么就需要增加很多条件来满足任务需求，会显得很繁琐，还会增加agent的认知负担，需要其思考走哪一条路，而不仅仅是专注于做自己的任务。
这种结构不仅仅是能做到并行，甚至可以做到等满足某一个条件后，再去进行下一步，使整个流程更加清晰，严谨，就可以让agent的模型能力全部投入到输入输出里，条件的判断交由编排的结构来解决。
在实际的应用中，一般是用FSM做宏观上的决策，而细节则是用图编排来做，这样既能确保每个子任务的质量，出现错误就回滚，让agent自行优化或者人工介入，在具体任务上，则是通过灵活的控制流，根据需求来完成任务，使得不是一味死板地解决问题，不用纠结agent分配的任务过粗过细，思考的程度是否偏颇，同时做到保证可维护性和可扩展性。