之前我们提到过，在ReAct中，agent会在输出结果后先观察结果，判断是否符合人物标准，不符合就重新进行一轮操作，直到输出令agent满意的答案为止，关于这个反思机制，具体的如下。

有时候，即使提示词里写清楚了规则，Agent还是会出现问题，可以写一些兜底逻辑，比如提示词里写着输出时直接写参数值，不要带引号，但是实际输出时还是可能会有这种情况出现，就需要在输出的逻辑里提前清楚引号 ####轮次限制 写ReAct框架时，需要限制最大轮次，可能有的人会担心这样会不会打断了正在优化的部分，但是实际上，Agent实际在迭代时要不了这么多次，次数多起来，很有可能是陷入了死循环，为了防止

之前我们提到过，多agent之间的信息流是以自然语言为基础的多轮对话，这里要明确的一个点是，对话在这里并非是辅助功能，可能会有人在接触到这个概念时以为对话是辅助agent理解文件、代码、任务等信息的方式，这个思考角度是把agent理解为了工具，而不是一个会“思考”的智能体。

一个函数最会骗人的时刻，往往不是它报错的时候。而是它看起来完全正确的时候。变量名清楚，逻辑顺滑，样例也能跑通。你把它贴进项目里，心里甚至会冒出一点轻松感：这次模型写得还不错。直到一个空列表、一个重复元素、一个边界阈值突然出现，代码才露出真正的裂缝。这就是代码生成和自然语言生成最大的不同。一段回答写得像人话，不代表它有事实；一段代码写得像工程师，不代表它能通过执行。代码世界里，漂亮不是证据，测试才是

最好的方式是按照需求去写，如果是项目要求，就直接针对模块设计就好，如果是做的通用工具，就需要想好一般用到工具时的思路便可，也就是说，关键是在于将工具函数封装为Agent容易理解和选择的单元，这也符合“工具”的设计初衷，适合、好用的才是最好的。虽然工具函数由代码构成，很多人喜欢像写注释一样把其描述形式往自己理解的方向靠，但是事实上，工具描述的最好是写成：这个工具能做什么，什么时候要调用，参数填写说明

在实际的应用中，一般是用FSM做宏观上的决策，而细节则是用图编排来做，这样既能确保每个子任务的质量，出现错误就回滚，让agent自行优化或者人工介入，在具体任务上，则是通过灵活的控制流，根据需求来完成任务，使得不是一味死板地解决问题，不用纠结agent分配的任务过粗过细，思考的程度是否偏颇，同时做到保证可维护性和可扩展性。所以，工程化对于多agent来说，可以说是必然的一种变化，不仅可以让流程更清

memory对agent来说，就像记忆对人类的作用一样，日常的每一件事，如果跟记忆里有对应上的话，相应的事情都会弹出来。memory就是agent在处理时，会自动检测是否会跟存储的数据对应，就跟人类一样会记得刚才的对话，曾经做过的事，也会累计经验，如果曾经有的事做错了，后续知道了正确的处理方式，就会记住它并在下次遇到类似的事时避免错误记忆分为短期、中期、长期记忆。

上一节我们提到，多agent之间的信息流主要是由自然语言进行的，但多agent的协作模式却不止像团队分工那样只有一种讨论的形式，实际上主要分为四种：结构化协作：ReAct扩展；反思式协作：团队互查；开放式协作：并行众议；流程化协作：严格调度。这四种模式基本就囊括了绝大部分的情况，下面我们来分别讲讲他们的结构和区分。

前一节我们提到，记忆写入的方式策略主要有即时写入（用户说自己不喜欢太死板的文字格式，或者说自己不喜欢喝牛奶，想要早餐推荐，这类记忆就需要及时存储下来），延迟写入（开始说每次对话完生成摘要，就需要等到明确的会话结束信号或者窗口达到上限才会生成摘要并存储记忆）和反馈写入（用户说把某个项目记为a，就出发逻辑，判断并将其写入长期记忆）。但是这三种策略，如果全用即时写入，会一次性引入大量的噪声，影响存储质量

那么如果真的要维护的话（毕竟不管怎么样，维护的核心逻辑不会变），比较常见的是构建双索引并定期重构索引：构建一个主索引一个增量索引，主索引的内容比较全，且更新频率比较慢，每周或每月更新一次；然后在查询时合并两个索引的结果再去重，这样就可以保证搜索到原来的内容的同时，还能搜索到更新后的内容。不过这样做的缺点是增量索引更新时不一定能真的做到实时同步，有延迟，但是实际应用时依然会这么做，理由很简单，只需要