---
tags: [ai/agent, react-loop, self-reflection, convergence-criteria]
create time: 2026-08-08 18:43
update time: 2026-08-08 18:43
---

# 循环状态机在Agent中的应用

## 概述

简单的 while loop 只能让 Agent "做一件事直到成功"，缺乏对执行过程的结构性理解。基于状态机的循环——特别是 ReAct（Reasoning + Acting）模式——为 Agent 引入了可推理、可观测、可终止的执行框架。这是构建自主智能体的基础架构模式。

## 详解

### ReAct 循环：思考→行动→观察

ReAct 的核心思想是让 LLM 在执行任务时交替进行"推理"和"行动"，每步行动后观察结果并据此调整下一步策略。这与人类解决问题的过程高度一致。

```mermaid
stateDiagram-v2
    [*] --> Start

    state ReActLoop {
        [*] --> Reason["思考\n分析当前局面"]
        Reason --> Act["行动\n调用工具或生成答案"]
        Act --> Observe["观察\n获取工具返回结果"]
        Observe --> Evaluate{"结果是否满足目标?"}

        Evaluate -->|"否"| Reason
        Evaluate -->|"是"| Done["完成"]
        Evaluate -->|"迭代超限"| Timeout["超时/失败"]
    }

    Start --> ReActLoop
    ReActLoop --> Done
    ReActLoop --> Timeout
    Done --> [*]
    Timeout --> [*]
```

**三轮 ReAct 的完整展开：**

```
Round 1:
  Thought: 用户问「Golang GC 的改进」，我需要先搜索相关信息
  Action: GoogleSearch("Go 1.21 GC improvements")
  Observation: 返回 3 篇文档摘要...

Round 2:
  Thought: 搜索结果包含三色标记法和并发 Mark-Stack 的信息，但缺少具体代码变更
  Action: WebFetch("https://go.dev/doc/gc-change")
  Observation: 提取到关键改动点列表...

Round 3:
  Thought: 综合两轮信息可以形成完整回答
  Action: 生成最终答案
  Observation: (无，直接交付)
```

### 自反思修正（Self-Reflection）

Self-Reflection 是在每次 Observate 之后额外增加一步自我评估，判断当前进度是否足以完成任务，以及是否需要改变策略。

```mermaid
graph TB
    A["思考"] --> B["行动"]
    B --> C["观察"]
    C --> D["反思评估\n• 已完成多少?"]
    D --> E{"置信度 ≥ 阈值?"}
    E -->|"是"| F["生成最终答案"]
    E -->|"否"—>|继续下一轮| A
    D --> G["诊断问题根源\n• 缺什么信息?"]
    G --> H["调整策略\n• 换搜索词/切工具"]
    H --> A
```

**反思 Prompt 模板：**

```
请评估当前进展：
1. 我已经获得的信息是什么？
2. 这些信息是否足够回答问题？
3. 如果不够，还缺少什么信息？
4. 下一步应该做什么来补充缺失？

输出格式：
{
  "confidence": 0.75,
  "sufficient": false,
  "missing": ["具体的benchmark数据"],
  "next_action": {"tool": "search", "query": "Go benchmark results"}
}
```

> [!NOTE]
> Self-Reflection 不是可有可无的——它让 Agent 从"盲目重试"升级为"有策略地迭代"。没有反思的循环就是蛮力，有反思的循环才是智能。

### 收敛条件设计

无限循环是最危险的 agent bug。必须设置明确的终止条件：

| 条件 | 实现方式 | 典型值 |
|------|---------|--------|
| 最大迭代次数 | 计数器达到上限 | 5-10 次 |
| 连续无改善 | 最近 N 次 iteration 结果无提升 | N = 3 |
| 置信度阈值 | 自评 confidence ≥ 设定阈值 | 0.8 |
| 时间预算 | 总耗时超过 budget | 30s |
| Token 预算 | 累计消耗 tokens 超限 | 根据模型限制 |

```go
// Go 示例：带收敛条件的 ReAct Loop
type ReActLoop struct {
    maxIterations   int
    noImproveLimit  int
    confidenceThresh float64
    timer           *time.Timer
}

func (r *ReActLoop) Run(ctx context.Context, goal string) (*Result, error) {
    var history []Step
    noImproveCount := 0

    for i := 0; i < r.maxIterations; i++ {
        // 检查时间预算
        select {
        case <-ctx.Done():
            return nil, ctx.Err()
        default:
        }

        // 执行一轮 ReAct
        step := r.executeOneRound(ctx, goal, history)
        history = append(history, step)

        // 收敛判断
        if step.Confidence >= r.confidenceThresh {
            return step.Result, nil // 满意，提前退出
        }

        if step.SameAsPrevious(history) {
            noImproveCount++
        } else {
            noImproveCount = 0
        }
        if noImproveCount >= r.noImproveLimit {
            break // 反复无效，停止
        }
    }

    // 未达最优但已达上限，返回最佳尝试
    return bestOf(history), nil
}
```

### 与简单 Loop 的区别

| 维度 | 简单 Loop | ReAct 状态机 |
|------|----------|-------------|
| 决策依据 | 固定规则 | LLM 推理 + 工具反馈 |
| 状态感知 | 无 | 携带完整历史上下文 |
| 策略调整 | 不支持 | 支持，每轮可换策略 |
| 终止条件 | 仅一个布尔条件 | 多条件复合判断 |
| 可解释性 | 差 | 好，每步都有 Thought trace |
| 适用场景 | 确定性重复任务 | 探索性、模糊性问题 |

> [!WARNING]
> 不要给 ReAct 过大的最大迭代次数。实验表明，超过 8 轮后错误率开始反弹——因为早期的错误被不断累积进历史，污染了后续推理。8-10 轮是经过验证的黄金区间。

### 防无限循环技巧

除了硬性的 max_iterations，还可以加入更智能的保护：

1. **Token 用量监控**：如果单轮 token 消耗突增 3 倍，说明 LLM 可能陷入冗长循环，强制中断
2. **去重检查**：如果当前 Step 的 Action 和前两轮完全相同且结果也一样，说明卡死，换工具或重试
3. **Entropy 监测**：计算 Thought 文本的 perplexity，长期过高表示 LLM 失去方向感
4. **人工介入网关**：超过一定复杂度自动请求 human-in-the-loop 确认下一步

## 实践场景

**ThumbUP 项目中的迭代优化：**

ThumbUP 的缓存策略选择就是一个典型的 ReAct 决策过程：
1. Thought: 单一缓存层在高 QPS 下有击穿风险
2. Action: 调研业界方案
3. Observation: 二级缓存 + HeavyKeeper 热点探测是主流做法
4. Thought: 需要验证多级缓存的一致性开销
5. Action: 模拟测试
6. Observation: 一致性协议增加了 15ms 延迟
7. Reflection: 权衡后发现利大于弊，采用该方案 → 达成结论

这个过程中，每一步都依赖上一步的观察结果做出调整，而非预先写死的流程分支。

## 扩展阅读

- [[Eino DAG 工作流设计]]
- [[上下文工程与记忆管理]]
- [[沙箱权限治理]]