Agent 的反思模块如何设计？

核心回答

反思模块应是依据目标和实际反馈找出偏差，再给出可执行修正，不是每步都让模型写一段“我反思了”。我会把它拆成触发器、证据收集、评估诊断、修正建议和采纳验证，并给出调用预算。

规则能确定的问题先用规则检查；需要理解任务目标、资料充分性或方案合理性时再用模型。反思可以同模型完成，也可以使用独立模型；是否用小模型取决于真实用例的准确性、误报和成本，而非模型越大越好。

模块的输入与输出

输入包括用户目标与约束、当前计划、相关执行轨迹、工具结果、产物以及已经做过的检查。重点是提供实际证据，避免只让模型看自己上次的解释。

输出可组织为：发现的问题、对应证据、影响范围、建议动作和是否需要重规划。动作区分继续执行、局部修补、重新检索、重规划或停止；指出“哪条条件未满足、下一步改什么”，比一个总分更能驱动执行。

例如研究报告缺少某项结论的来源，反思应提出补查这项证据，而不是重新生成整份计划。代码测试失败则应引用失败用例和异常位置，帮助执行器定位修复。

什么时候触发，怎样避免频繁推翻计划

工具报错、检查失败、连续无进展、新证据否定关键前提、到达重要阶段或准备交付时都可以触发。简单可确定的步骤无需每次调用大模型评审。

修正应与偏差范围对应：字段错误局部改，子任务路线不可行才替换对应步骤，全局前提改变才重规划。重规划前说明新证据为何使旧计划失效，保留已验证产物和仍有效的约束；不要只因“还有更优方案”就反复推倒。

限制反思次数、额外工具调用和总预算，记录每次修改是否带来可验证进展。同类建议反复出现但无改善时停止循环，回传具体阻碍或切换处理方式。

模型与数据怎样选

可以先用强模型辅助整理失败类型和评价维度，再用人工确认的案例训练或评估小模型。数据应包含真正错误、正确但不完美、无需重规划和新前提改变等边界样本，避免反思器学成“总能挑出问题”。

比较同模型、独立模型与小模型时，固定执行任务和输入轨迹，检查问题识别、误报、修正后的实际成功、延迟和成本。独立模型仍可能与执行器犯相似错误；生成反馈不等于修复有效。

反思与自进化的区别

本轮反思用于修正当前任务；只有经过验证、具备复用价值的经验，才适合进入长期记忆或技能候选。Reflexion、Self-Refine等方法提供了反馈与迭代思路，但不会保证每次修改单调变好。技术亮点是让反思建立在外部证据上，并控制修正范围与收益。

对应教程

参考资料