该内容为自助投放广告,真伪自辨
立即入驻

如何为 AI 智能体设计‘反思’环节:通过自我修正提高复杂推理任务的准确率

广告也精彩

复杂任务里,AI 常见的问题不是“完全不会做”,而是第一版看起来合理,却漏掉边界条件、前后矛盾或任务要求。把结果直接交付,容易让这些问题一路保留下来。Reflection(反思)机制的做法,是让智能体先执行,再按明确标准检查,最后根据检查结果修正。

智能体执行、评估与修正的反思闭环示意图

反思不是让模型“再想一遍”

只对模型说“请仔细检查并改进”,通常不够。它可能重复原来的判断,也可能为了显得谨慎而改动本来正确的内容。关键是把反思拆成三个有明确职责的环节:

  • 执行:根据任务要求生成初稿。

  • 评估:逐项核对初稿是否满足要求,指出问题及依据。

  • 修正:只处理已经识别的问题,再检查修订结果是否仍符合原始要求。

这个闭环最好保留原始任务和约束。否则,模型在修订时可能只盯着评估意见,却忘记用户最初要求了什么。

可以先用这段通用提示词搭建基础链路:

你需要完成以下任务。

【任务】
{任务描述}

【必须满足的约束】
{格式、范围、受众、禁止事项等}

请按以下顺序工作:

一、执行
先按任务要求生成初稿。

二、评估
对照任务与约束检查初稿。
只报告具体问题,并说明:
- 问题出在哪里
- 它违反了哪条要求,或可能导致什么结果
- 修正方向是什么

如果没有发现问题,明确说明“未发现需要修正的问题”,不要为了显得认真而虚构缺陷。
不要重写初稿,也不要引入任务中没有提供的事实。

三、修正
根据已确认的问题修改初稿。
保留原稿中符合要求的部分,不要无理由扩大范围或改变表达方向。

四、交付
仅输出修订后的结果。
若缺少完成任务所必需的信息,先指出缺口,不要自行编造。

这段结构把“挑错”和“改稿”分开,减少评估意见直接混进最终答案的情况。若工作流支持不同节点,可以把执行、评估、修正分别放进不同提示词;若只能使用一个提示词,也可以要求模型按顺序完成,但最终只交付最后结果。

代码生成:检查逻辑与边界条件

代码任务的检查标准应从需求里来,而不是只问“代码有没有问题”。例如,要求生成一个处理输入数据的函数,评估环节就应核对输入格式、异常情况、返回结果和任务边界。只要需求没有提到某种功能,就不要把它当成必须实现的要求。

可将下面这段作为代码任务的评估提示词:

你是代码审查者。请只根据原始需求、约束和候选代码进行检查。

【原始需求】
{需求}

【约束】
{语言、输入输出要求、禁止事项}

【候选代码】
{初稿}

请检查:
1. 代码是否覆盖了需求中的每一种明确情形?
2. 输入边界或异常输入是否可能导致错误结果?
3. 实际行为是否与函数说明、返回格式一致?
4. 是否存在偏离需求的额外行为?
5. 哪些判断可以通过运行、测试或其他外部结果验证?

输出“问题—依据—修正建议”。没有依据的问题不要列出。
如果有可用的执行或测试结果,请把它作为证据;如果没有,不要声称代码已经运行或验证。

以“生成一个处理输入列表并返回指定结果的函数”为例,单次生成可能只覆盖常见输入。反思环节则应追问:空输入如何处理?数据类型不符时会怎样?返回值是否符合约定?这些检查能把模糊的“看起来没错”转成与需求逐条对照的审查。

修订时,别让模型整段推倒重写。可以明确要求它只改已指出的问题,并在代码后简要列出修改点。若有测试或执行环境,应把结果反馈给评估环节;没有外部验证时,模型自检不能等同于代码已正确运行。

长文写作:核对要求,而不是重复润色

长文的风险通常不是单个句子,而是整体偏题、漏掉必写内容、前后说法不一致,或者越过允许范围。写作任务的评估提示词应对应 brief 和边界,不要只让模型检查语句是否流畅。

你是文章审稿者。请对照下面的任务要求检查初稿。

【文章任务】
{目标读者、写作角度、必写内容}

【范围边界】
{允许讨论与禁止扩展的内容}

【初稿】
{文章}

请依次核对:
- 是否回应了目标读者的实际问题?
- 必须覆盖的内容是否遗漏?
- 是否出现超出范围的段落?
- 各部分之间是否有矛盾、重复或缺少必要解释?
- 是否把未经提供的信息写成了确定事实?
- 标题和列表是否确实有助于阅读?

只列出能指出具体位置的问题,并给出修改方向。
不要把个人偏好包装成事实错误,也不要为了增加篇幅而添加新内容。

例如,长文要求介绍一套可复用的操作方法。单次生成可能把重点写成原理概述,却没有给出可使用的步骤;反思环节可以据此检查“是否有明确操作指令”,并指出缺失位置。若文章涉及事实资料,还应检查每个具体说法是否有输入依据;不能确认的内容应删除或改成谨慎表述,而不是用流畅措辞掩盖不确定性。

代码和长文都能使用同一闭环,但评估尺度不同:代码更关注行为是否符合需求、边界输入是否处理妥当,以及是否有外部验证;长文更关注范围、内容覆盖、事实依据和结构连贯。把两类标准混在一份泛泛的“请检查质量”提示词里,往往会得到宽泛却难以执行的意见。

代码生成与长文写作中的反思检查场景对比

让闭环有边界,避免越改越远

反思会增加处理步骤,也可能引入新错误。评估标准过于宽泛时,模型容易反复润色;修订指令没有保留原始约束时,改稿也可能偏离任务。实际搭建时,可以把握三个原则:

  1. 标准具体且可核对。 用“是否包含指定部分”“是否符合输入输出约定”替代“是否足够优秀”。

  2. 问题必须有依据。 要求评估者指出对应要求或初稿位置,避免无端挑错。

  3. 修订范围受控。 保留正确内容,只修改已确认的问题;当检查未发现问题时,允许直接交付。

如果任务涉及事实、计算或代码运行,优先把可获得的外部结果交给评估环节。单靠模型自评,不能保证它一定发现自己的错误;反思机制更适合充当有标准的复核流程,而不是正确性的担保。

搭建时可以先从一轮“执行—评估—修正”开始,观察评估意见是否具体、修订是否真正解决问题。若意见总是空泛,先改评估标准;若修订经常偏题,先补全原始约束并缩小修改范围。做对这两点,反思才是可复用的工作流环节,而不是在提示词末尾追加一句“再检查一下”。

© 版权声明

相关文章

暂无评论

none
暂无评论...