反思与自我纠正

共 17 题
📑 题目列表 17 题
#
★★★

1. ReAct 循环中 Thought→Action→Observation 的失败如何被 Agent 自察

在 ReAct 循环中,当 Thought→Action→Observation 的推理-行动-观察链条出现失败时,Agent 如何自我察觉失败并据此调整下一步行为?

  • ReAct 循环的分步结构与失败发生的环节
  • 失败自察的信号来源(工具报错、Observation 异常、结果不一致)
  • 感知失败后如何调整:换工具、改参数、改策略或放弃

ReAct 的循环是 Thought(推理)→ Action(行动)→ Observation(观察)反复迭代。失败自察的核心是"Observation 与原计划/期望不符"这个信号。常见失败类型包括:工具调用报错(超时、异常、格式错误、参数非法)、Observation 为空或返回异常值、Action 直接失败(如 API 404)、以及 Observation 与上一轮 Thought 的假设相矛盾。Agent 需要在 Prompt 中显式要求"如果 Observation 异常,先分析原因而非盲目继续",配合工具层的结构化错误码(区分永久错误与可重试错误)让模型能读懂失败原因。自察后 Agent 应进入"纠错分支":改用备选工具、重试、修正参数、简化目标,或最终升级。关键局限是:如果 Observation 本身看起来正常但语义上是错的(如返回了错误但格式合法的数据),模型无法通过"格式"自察,需要额外的校验器或事实核对。

自察的本质是把"失败"变成可被模型消费的信号,而不是让模型在黑盒里碰运气。因此工程上要做的不是让模型"更聪明",而是把失败信息结构化为 Observation 的一部分(错误码、错误层级、可重试标志),并让循环具备明确的纠错与终止路径。

def react_loop(agent, task, max_steps=10):
    observation = ""
    for step in range(max_steps):
        thought, action = agent.plan(task, observation)
        if action.get("type") == "finish":
            return action["answer"]
        try:
            observation = execute_tool(action)  # 可能抛异常
        except ToolError as e:
            observation = f"TOOL_ERROR[{e.kind}]: {e.message}  (recoverable={e.recoverable})"
            if not e.recoverable:
                return escalate_to_human(task, observation)
    return {"status": "gave_up", "reason": "max_steps_exceeded"}
#
★★★

2. Reflexion 框架如何让 Agent 基于环境反馈做语言化反思并改进

Reflexion 框架如何让 Agent 基于环境的反馈(如测试结果、工具错误)进行"语言化反思"(verbal reflection),并把这些反思持久化以改进后续尝试?

  • Reflexion 的三要素:actor、evaluator、self-reflection
  • 语言化反思(verbal memory)与隐式权重更新的区别
  • 反思如何写入 memory 并在下一轮决策中复用

Reflexion 的核心思想是不用梯度微调,而是让模型"用语言描述自己哪里错了、下次该怎么做",把错误经验存成可读的反思文本(verbal memory),在后续尝试中重新注入上下文。它由三个模块组成:actor(执行任务,通常是 ReAct 风格的 agent)、evaluator(判断结果是否成功,如跑测试、LLM 评判)、self-reflection(生成反思文本)。流程是:actor 执行一轮→evaluator 评分→若不通过则生成反思(如"我在第 3 步错误地调用了 X API,下次应先用 Y 校验参数")→反思写入 memory→下一轮 actor 带着历史反思重新执行。因为没有权重更新,架构简单、可适用于任何 LLM,且反思文本可解释、可审计。局限是反思质量依赖 LLM 本身,且每轮都读全部反思会占用上下文。

Reflexion 的价值在于把"失败经验"显式物化为语言,从而让训练成本为零、可复用性强。它适合任务可评判、可多轮重试的场景(代码生成、问答、决策),而"评估器"质量直接决定反思质量——评估器不准,反思就会错。

class ReflexionAgent:
    def __init__(self, actor, evaluator, reflector):
        self.memory = []  # 反思文本列表
    def run(self, task, max_trials=3):
        for trial in range(max_trials):
            result = self.actor.run(task, self.memory)
            feedback = self.evaluator.evaluate(result)
            if feedback.passed:
                return result
            reflection = self.reflector.reflect(task, result, feedback)
            self.memory.append(reflection)  # 语言化反思持久化
        return result
#
★★

3. Self-Correction 在代码生成中如何避免"越改越错"的循环

在代码生成场景中,Agent 根据测试反馈进行自我修正时,如何避免反复修改却越改越差("越改越错")的循环?

  • 越改越错的成因:错误反馈被误读、改动引入新 bug、发散式修改
  • 防止发散的手段:版本比对、改动最小化、失败快照
  • 收敛机制:依赖测试结果而非仅凭模型自评

"越改越错"通常源于:模型把一次失败反馈过度解读、没有保留失败基线就大改、或修改只针对表面符号而未触及根因。工程上防止发散的策略包括:①每次修改前先保存当前版本的快照和测试结果,逐轮对比"这轮是否比上一轮更好",若测试通过数下降则回退到上一版;②限制修改幅度,要求模型只做最小必要改动并说明理由;③用测试结果作为唯一收敛判据,而非模型"感觉变好了";④设置最大修正轮数,超出即放弃并保留最好的版本;⑤对失败的测试用例做回归隔离,防止新改动破坏已有通过的用例。核心是让"修正"成为有可验证反馈的闭环,而不是无锚点的自由发挥。

越改越错本质是"缺乏稳定的收敛锚点"。把每次修改放到版本控制的框架里(快照、diff、回退、用测试衡量进步),就能让自我修正有方向、可度量、可回退,从而避免无休止的坏循环。

let best = snapshot(version, testResults);
for (let i = 0; i < maxIter; i++) {
  const candidate = llmFix(version, failingTests);
  const results = runTests(candidate);
  if (results.passed >= best.passed) {
    best = snapshot(candidate, results);
    version = candidate;
  } else {
    // 本轮更差,回退到 best,不采纳
  }
  if (results.passed === totalTests) break;
}
return best.code;
#
★★

4. 多轮反思的收敛判据如何设计以避免无谓的 Token 消耗

多轮反思(multi-turn reflection)循环的收敛判据应如何设计,才能在保证质量的同时避免无谓的 Token 消耗?

  • 收敛判据的类型:结果稳定、无改进、置信达标、预算耗尽
  • 判定"无改进"的方法:连续多轮结果一致或评估分数不再上升
  • 预算控制:Token 上限、轮数上限、时间上限

收敛判据应同时涵盖"质量达标"和"收益递减"两类信号。质量达标指:验证器通过(测试全绿、校验命中)、评估分数达到阈值、或连续 N 轮输出彼此一致(一致性收敛)。收益递减指:连续 K 轮评估分数不再上升或仅微幅波动,此时继续反思只是浪费 Token——应停止并以历史最优结果为准。预算控制是兜底:设置最大轮数、最大 Token 数、最大耗时,三者任一超限即强制停止。实践中常组合使用:先看是否达标,再看是否稳定,最后看预算。关键是"停止并返回最优而非最后一轮",因为最后一轮不一定最好。

多轮反思的价值边际递减,设计收敛判据本质是"用收益递减信号做早停"。把"无改进"量化为"连续 K 轮分数不动"或"输出一致",再叠加硬性预算,就能在质量与成本间取得平衡,避免无限循环吞 Token。

#
★★

5. Agent 何时该放弃重试并升级给人类,而非无限自我修复

Agent 在什么情况下应该放弃自动重试和自我修复,转而把任务升级给人类处理,而不是无限循环地自我修复?

  • 升级触发条件:确定性错误、预算耗尽、风险超限、多次失败
  • 区分可重试错误与不可重试错误
  • 升级时机与升级内容(附上下文摘要)

Agent 应升级给人类的情形包括:①遇到不可重试的确定性错误(如权限不足、参数与 schema 永久不匹配、业务规则明确拒绝);②重试达到上限(如连续 N 次失败或固定轮数耗尽)仍无进展;③风险或成本超出阈值(如涉及大额资金、涉及医疗/法律决策、代价过高)需要在行动前由人确认;④出现模型无法判断的歧义(如两个合理选项冲突);⑤自我修复后评估结果仍不满足要求。升级设计中应区分"可重试错误"(重试可能成功)与"不可重试错误"(重试必然失败),后者直接升级以省 Token。升级时携带结构化上下文(目标、已尝试步骤、失败原因、当前状态),让人能快速决策。关键原则是"有限自我修复 + 明确升级路径",避免无限循环。

无限自我修复是资源黑洞,也是安全隐患。设计时把"失败的分类"和"升级的阈值"作为第一等公民:可重试的有限重试,不可重试或高风险的立即升级,并给升级动作配好上下文摘要,让人类能接管而非从头再来。

#
★★

6. Agent 反思(Reflection)的触发条件,何时值得二次推理,成本如何控制?

Agent 反思(Reflection)应在什么条件下触发(即何时值得做二次推理),以及如何控制二次推理带来的成本?

  • 触发条件设计:低置信、验证失败、高风险、关键步骤
  • 成本控制手段:只对关键步骤反思、限制反思轮数、用轻量模型
  • 反射的"选择性"——避免对每个输出都反思

反思不应无差别触发,而应"选择性"触发,以控制成本。值得触发二次推理的条件包括:①模型置信度低于阈值(不确定性高);②外部验证器未通过(测试失败、校验不通过);③任务风险高或影响大(金融、医疗、关键决策);④处于关键步骤(下游依赖强,错了代价大);⑤输出涉及需要事实核对的陈述。成本控制手段:只对低置信/高风险片段做反思而非整段;限制反思轮数(如 1-2 轮);用轻量/廉价模型做初筛、用强模型做关键反思;设定反思的总 Token 预算;对已验证通过的结果直接跳过反思。核心是"把宝贵的二次推理留给最值得的地方"。

反思的成本是"额外的推理 + 时间延迟",收益是"质量提升"。只有触发条件与风险的收益匹配,才划算。所以设计上要定义"哪些情况值得反思"并配置预算,本质是质量与成本的多级权衡。

#
★★

7. 自我纠正的"验证器"设计,工具结果校验、规则校验与模型自评如何分层?

自我纠正场景中的"验证器"应如何设计?工具结果校验、确定性规则校验与模型自评如何分层配合?

  • 分层验证:确定性规则→工具结果→模型自评
  • 各层特点:确定性校验可靠、模型自评灵活但不可靠
  • 分层顺序与短路原则

验证器应分层设计,由"确定性"向"概率性"逐层递进,让可靠且便宜的校验先行。第一层是确定性规则校验:schema 校验、类型/枚举/金额/日期校验、正则、单元测试——这些可精确判定,成本低、可重试,用来拦截低级错误。第二层是工具结果校验:检查工具返回是否成功、是否为空、是否在合理范围、是否与预期一致(如调用外部 API 后校验响应码与字段)。第三层是模型自评(LLM-as-Judge):处理语义、逻辑、事实、风格等无法用规则表达的问题,灵活但可能失败、有偏好。分层的关键是"短路":能让确定性规则拦截的,就不必动用模型自评,节省成本并提高可靠性;模型自评主要用于规则覆盖不到的语义层,且需配合校准与抽检。各层失败处理不同:规则层失败可立即重试或纠正,模型层失败需结合人类抽检或置信阈值。

分层验证的本质是"用最可靠的工具处理能确定的问题,把不可靠的模型留给语义问题"。确定性规则优先、模型自评兜底,既保证校验效率和准确性,又控制成本。

#
★★

8. Agent 的反思机制,Self-Refine、CRITIC 与自我评判?

常见的 Agent 反思机制 Self-Refine、CRITIC 与自我评判(self-evaluation)各自是什么?它们有何区别与联系?

  • Self-Refine 的生成-反馈-修正循环
  • CRITIC 的"批判"与外部工具验证
  • 自我评判(self-score)的局限

Self-Refine 是"生成→自我反馈→再生成"的迭代框架,模型先生成初稿,再生成对初稿的反馈(指出问题),然后基于反馈生成修正版,循环数次。它只用模型自身,不依赖外部工具,优点是简单、通用,缺点是反馈可能同源、自我评价有偏差。CRITIC 强调"批判性验证",让模型扮演批评者,结合外部工具(如代码执行、检索、运行测试)来检验输出,利用外部证据纠正错误,比纯内省更可靠。自我评判(self-evaluation/self-score)指模型对自己的输出打分或判断,通常作为触发进一步修正的信号,但存在过度自信、自我偏好偏差,需要校准或外部证据交叉验证。联系上,三者都属反思/自我纠正范畴,可以组合:Self-Refine 提供迭代框架,CRITIC 用外部验证增强反馈可靠性,自我评判作为触发条件。区别在于"反馈来源"——纯内省(Self-Refine/自评)vs 外部证据(CRITIC),后者通常更可靠。

反思机制的核心差异在于"反馈从哪里来"。纯模型内省成本低但可能自欺,引入外部工具(CRITIC)能提供更客观的证据,但成本更高。理解这个轴,就能按场景选择或组合。

#
★★

9. 反思的实现,多轮采样与自评(self-verification)?

反思的另一种实现方式——多轮采样(multiple sampling)与自评(self-verification)——是如何工作的?

  • 多轮采样生成多个候选答案
  • 自评/自验证机制挑选候选
  • 多数投票(self-consistency)与自评判分

多轮采样与自评是"反思"的另一种实现思路:不在一轮生成后反复修正,而是先生成多个独立候选(多次采样,温度可稍高以增加多样性),再用自评或自验证从候选中选出最好的。自评(self-verification)指模型对每个候选打分或判断其正确性,选出置信度最高者;自我一致性(self-consistency)则是多数投票——多个采样中答案一致者更可能正确。这类方法比"单轮生成+修正"更能抵抗单次采样的随机性和模型偏见,且因为没有多次迭代修正,常更省时间。局限是多次采样成本是单次的 N 倍,且自评打分本身可能不可靠。实践中常与验证器、外部工具结合来提高选择质量。

多轮采样+自评把"反思"从"纵向修正"转为"横向择优",用多样性+投票/打分来逼近更优解。当任务难以用单次自省修正时,横向采样往往更有效,代价是采样成本。

#
★★

10. 反思的元认知设计,模型何时应拒答(承认不知道)而非反思重试,如何用校准阈值与评估集调参?

在反思的元认知设计中,模型何时应"拒答"(承认不知道)而非继续反思重试?如何用校准阈值与评估集调参?

  • 拒答 vs 反思重试的分界
  • 校准阈值(calibration threshold)的作用
  • 用评估集调参与观察拒绝率

元认知的关键是让模型学会"区分不知道与暂时没答对"。当模型置信度低、且重试多轮仍无法验证或产出稳定答案时,应拒答并说明"信息不足/无法确认",而不是编造或盲目重试。实现上,用校准阈值作为分界:模型对答案的置信度或概率低于阈值且重试后仍无改善,则触发拒答。阈值宜通过带标注的评估集调参——评估集包含"已知答案"与"未知/信息不足"两类样本,调参时观察不同阈值下的拒答率、正确率与覆盖率,找到"误拒少、漏拒也少"的折中。校准本身可结合温度采样、多次采样的置信度统计、或让模型输出其不确定度。目标是让拒答在实际无把握时发生,不让模型在"应该拒答"时强行作答。

拒答是反思的"另一条出路"——不是所有低置信都要重试,有的应直接承认不知。通过校准阈值把"置信度"变成"是否拒答"的决策信号,并用评估集调参,让拒答行为可度量、可调优,避免模型过度自信或过度拒答。

#

11. 反思日志如何持久化以便同类任务复用历史教训

反思日志(reflection log)应如何持久化保存,以便在同类任务中复用历史教训?

  • 反思日志的结构化存储(数据库/向量库)
  • 按任务类型/语义检索复用
  • 教训的去重与时效管理

反思日志的本质是"结构化、可检索、可复用"的经验资产。持久化时建议:①结构化字段化存储——任务类型、失败原因、采取的修正、教训文本、时间戳、是否已验证有效,便于按类型/diff 检索;②用向量库按语义检索,在同类任务启动时把相关历史教训注入上下文;③建立去重与沉淀机制,相似教训合并,避免重复教训反复注入;④考虑时效——旧教训可能不再适用,需定期清理或降权;⑤与跨会话记忆打通,让历史教训在新会话中延续。持久化后,同一类任务的新 Agent 就能"站在前人教训上",不必重复踩坑,也便于审计与复盘。

反思若只存在于单次会话内存,就失去学习价值。持久化的核心是把"经验"变成可检索的知识资产,让同类任务复用、让教训可维护、可审计。

#

12. 反思循环的终止条件,最大迭代次数、置信阈值与成本上限如何设置?

反思循环的终止条件应如何设置?包括最大迭代次数、置信阈值与成本上限分别如何取值?

  • 最大迭代次数作为硬性上限
  • 置信阈值作为质量达标条件
  • 成本上限(Token/时间)作为兜底

反思循环的终止条件通常由三层构成:①质量达标——置信度评估或验证器分数达到阈值,即提前终止;②最大迭代次数——硬性上限,防止无限循环,通常按任务复杂度取 2-5 轮;③成本上限——累计 Token 数、耗费时间或金额达到上限即强制停止,作为兜底。三者优先级建议:先判断是否达标(最优退出),再判断是否超预算(强制退出),最后判断是否超轮数(兜底退出)。阈值与轮数应结合任务价值、单轮成本与质量收益设定:高风险高价值任务可放宽轮数与预算,低价值任务应严格收紧。停止时返回历史最优结果而非最后一轮。

终止条件本质是"质量目标"与"资源约束"的折中。达标退、超预算退、超轮数退,三层兜底,既保证质量又控制成本,是反思循环工程化的关键。

#

13. 反思的代价,多轮生成的延迟、Token 成本与质量收益应如何权衡

反思带来的代价(多轮生成的延迟、Token 成本)与质量收益应如何权衡取舍?

  • 反思的代价构成:延迟、Token 成本、时间
  • 质量收益的量化
  • 不同场景的权衡策略

反思的代价主要是多轮生成的 Token 成本与端到端延迟(尤其对实时交互场景影响大),质量收益体现在输出正确率、用户满意度与返工率下降。权衡的关键是"按场景定价":对延迟敏感的场景(在线聊天、实时搜索),应限制反思轮数或用轻量反思;对质量敏感、可异步的场景(代码生成、报告撰写、长任务后台),可允许多轮反思。同时要量化收益递减——通常第一轮反思收益最大,后续轮次边际收益递减,当增量收益低于新增成本时应停止。可以用 A/B 或评测集对比"有反思 vs 无反思"的正确率与成本,用(质量提升/成本增量)作为决策指标。还要考虑缓存与并行:多次采样可并行以压缩延迟。

反思是"用成本换质量"的工程选择,不是越多越好。区分场景的重要性(延迟敏感 vs 质量敏感)、量化收益递减,用性价比指标做决策,才能把握"投入产出"的平衡。

#

14. 自我纠正的边界,何时该停止、何时该求助?

自我纠正的边界在哪里?Agent 应在何时停止自我纠正、何时该向人类求助?

  • 停止自我纠正的信号
  • 求助的触发条件
  • 边界设定的原则

自我纠正的边界由"停止条件"与"求助条件"共同界定。停止的条件包括:验证器通过、输出达到质量阈值、连续多轮无改进、预算或轮数耗尽。求助的条件包括:遇到不可重试的确定性错误、多次尝试仍失败、风险或影响超出阈值、出现模型无法判定的歧义、需要人类授权的动作。边界设定的原则是"低成本纠正自己解决,高成本/高风险/不可解交给人类":能通过验证和有限重试解决的自己解决,无法在可控成本内解决的及时求助。同时要防止两类失衡——过度纠正(在无望时白耗资源)与求助过少(把失败硬扛或兜底,风险外溢)。设计上建议把"求助"作为一等动作而非最后手段,并给求助附上结构化上下文。

自我纠正的边界本质上是对"自己解决的成本"与"求助的代价"做比较。明确停止信号与求助信号,让 Agent 在可控范围内自主、在可控范围外升级,是可靠性与效率的平衡点。

#

15. 反思的评测,修正率与过度修正的平衡?

反思的评测应如何设计?如何平衡"修正率"(真正把错误修正的能力)与"过度修正"(把本来正确的改错)?

  • 修正率(正确率提升)与过度修正(正确率下降)的度量
  • 评测集设计:含正确与错误样本
  • 用净收益评估反思价值

反思评测要同时看"修对了多少"和"改坏了多少"两个方向。修正率指原本错误的输出被反思修正的比例;过度修正(破坏率)指原本正确的输出被反思改错的比例。若只优化修正率,模型可能倾向于激进改动,破坏率高;若过度保守,则修正率低。评测设计上,评测集需同时包含"正确样本"与"错误样本",分别统计修正率与破坏率,并计算净改善(修正的错误数 - 被改坏的正确数)。理想反思策略应"修正率与破坏率都优",或至少净改善为正。可用不同反思策略/轮数做 A/B,看净改善曲线——当某轮后破坏率陡增或净改善为负,说明该停止反思。指标可结合"是否有反思"的对照组来量化解耦收益。

反思是双刃剑——可能修对也可能改坏。评测必须双向度量,避免"只在乎改对"而忽略"改坏"的代价。用净改善做决策,用破坏率做风险护栏,才能设计出真正有益的反思。

#

16. 反思的停止条件,置信度阈值与预算控制?

反思的停止条件应如何设置?置信度阈值与预算控制各起什么作用?

  • 置信度阈值触发提前停止
  • 预算控制作为硬性兜底
  • 两者如何配合

反思的停止条件由"软性质量条件"与"硬性预算条件"组成。置信度阈值是软性条件:当模型对输出的置信度或验证器分数达到阈值,说明质量达标,可提前停止反思,避免浪费 Token。预算控制是硬性条件:最大轮数、Token/时间上限,防止反思无限进行。二者配合:先查置信度阈值(达标即停),再查预算(超限即停),两者结合保证"质量优先、成本兜底"。停止时返回历史最优结果而非最后一轮,因为最后轮不一定是最好。阈值与预算需按任务价值与风险调参——高风险任务可放宽预算、提高阈值要求。

反射停止的"双条件"设计——置信度阈值负责"够了就停",预算负责"说不出也停"——是质量与成本双约束的标准做法,避免单一条件的缺陷。

#

17. 反思的工程化实现,LangGraph 中反思节点的状态设计、循环控制与成本上限?

在 LangGraph 中实现反思功能时,反思节点的状态设计、循环控制与成本上限应如何配置?

  • LangGraph 图与状态(State)设计
  • 反思节点的循环边与条件边
  • 循环控制:最大迭代、终止条件

在 LangGraph 中实现反思,关键是用图(Graph)表达"生成→评估→反思→再生成"的循环。状态(State)设计上用 TypedDict 定义共享状态,如 messages(对话/生成历史)、evaluation(评估结果)、reflection_text(反思文本)、iteration_count(当前轮数)、budget(已用 Token/成本)。循环控制用条件边(conditional edge):评估节点返回 pass→ 走"结束"边;返回 fail 且 iteration_count < max_iterations → 走"反思"边继续;否则→走"终止/升级"边。成本上限在状态里维护已用 Token,超限时条件边强制走终止路径。这样把"反思循环"建模为图上的条件路由,每个节点可独立开发、测试、观测,也便于加日志与审计。

LangGraph 把反思的"循环"从代码里的 for 循环变成图上的条件边,状态显式化、流程可视化、可观测性与可扩展性大增。成本上限也可作为状态字段参与条件路由,实现一体化控制。