上周在部署一个多步骤推理Agent时，遇到了一个典型问题：Agent在解析用户查询“统计上季度华东区销售额并生成折线图”时，连续三次返回了错误的日期范围。日志显示它把“上季度”理解成了“当前季度前三个月”，而非实际的“上一完整季度”。更麻烦的是，Agent在收到“日期不对”的反馈后，依然用同样的逻辑重复尝试，陷入死循环。

这个场景让我意识到：传统链式调用就像一段没有异常处理的硬编码流程，错了就直接崩，或者原地打转。真正的智能体必须能“意识到自己可能错了”，并且知道“怎么调整策略”。

二、反思机制的本质：让Agent拥有“检查点”

反思（Reflection）不是让Agent写检讨，而是在关键决策点插入一个“检查点”（Checkpoint），让Agent对自己的输出做一次元评估。这里常见的误区是直接让Agent问自己“我答得对吗？”——这往往没用，因为模型会倾向于肯定自己。

有效的做法是构造一个批判性提示模板，强制Agent从特定维度审视自己的输出。比如针对数据查询场景，我会要求Agent按这个模板自检：

# 注意：下面这个模板是给Agent看的提示词，不是代码
你刚生成了一个查询结果，请按以下顺序检查：
1. 日期范围：是否与用户描述的“上季度”“上周”等逻辑一致？用当前日期2024年7月验证。
2. 数据字段：结果中是否包含用户明确要求的“销售额”“折线图”等要素？
3. 异常值：如果结果数据比去年同期增长超过500%，标出需要二次核实的标记。

关键点：模板必须具体、可操作。别用“检查正确性”这种模糊指令，要拆解成模型能直接比对的具体条目。

三、修正循环的设计：避免无限递归陷阱

有了反思，下一步是修正。最简单的实现是“反思-重试”循环：

def agent_with_reflection(query, max_retries=3):
    for attempt in range(max_retries):
        response = generate_response(query)
        reflection = self_reflect(response, query)  # 反思环节
        
        # 这里踩过坑：别直接问“是否通过”，要检查反思结果中是否有问题项
        if "需要修正" not in reflection:
            return response
        
        # 修正环节：把反思和原问题一起喂给模型
        query = f"{query} [上次输出问题：{reflection}]"
    
    # 重试超限后的降级处理
    return fallback_response(query)

但这里有个暗坑：如果反思环节本身判断失误，可能把正确结果改成错的。我们在金融报表场景中遇到过，Agent因为“增长率超过500%”的反思标记，把正确的暴涨数据改成了平滑值。经验是：反思规则尽量用“存在性检查”（比如“是否包含某字段”），慎用“合理性判断”（比如“数据是否异常”），后者需要更复杂的验证机制。

四、多步任务中的动态规划修正

对于生成代码、分步计算等多步任务，更好的策略是在每个步骤后做局部反思，而不是等最终结果错了再重头来。比如在“爬取数据-清洗-可视化”流水线中：

steps = ["数据源解析", "日期过滤", "聚合计算", "图表生成"]
execution_context = {}

for step in steps:
    result = execute_step(step, execution_context)
    
    # 步骤级反思：检查这个步骤特有的问题
    reflection = step_specific_reflection(step, result)
    
    if reflection.has_issue:
        # 只回滚到前一个检查点，不是全流程重试
        rollback_to_last_checkpoint()
        # 调整这个步骤的参数重新执行
        result = retry_step_with_fix(step, reflection)
    
    execution_context.update({step: result})

这种设计类似事务的“保存点”，牺牲部分效率换取更高的容错率。实际测试中，一个包含6个步骤的数据处理任务，在第二步和第四步注入错误，传统流程成功率12%，加入步骤反思后提升到89%。

五、经验性建议

1. 反思模板要领域化：通用反思效果很差。做数据分析就聚焦日期、字段、格式；写代码就检查语法、API版本、边界条件。模板越贴近业务，检出率越高。

2. 控制反思成本：别每一步都反思。在易错点（如日期解析、单位换算、API调用）设置检查点，稳定步骤直接过。

3. 给修正设边界：最大重试次数建议设3次，超限后必须降级（如返回中间结果+错误说明）。见过有人设10次，结果Agent在第一个简单问题上循环超时。

4. 记录反思日志：这是宝贵的调试数据。我们曾从日志发现80%的修正都发生在“日期解析”环节，于是专门优化了该模块的提示词，整体错误率下降40%。

5. 人类介入接口：关键业务流留一个“反思后仍不确定”的出口，转人工处理。完全自治的修正系统在现阶段还是理想状态。

六、最后一点思考

Agent的自我修正能力，本质是在不确定环境中构建“感知-决策-验证”的闭环。当前基于提示词的反思还比较初级，更像是给模型装了一套预定义的校验规则。下一步值得探索的是让Agent从错误中学习，动态更新自己的反思策略——那会是另一个层面的挑战了。

调试那晚的问题，最终是通过给日期解析模块添加“季度计算逻辑说明”解决的，Agent在反思时能依据明确规则发现自己的推算错误。这让我想起早年写嵌入式程序时，用看门狗定时器复位异常状态的场景。技术范式不同，但设计哲学相通：好的系统不是永不犯错，而是错了能自己爬回来。