vault backup: 2026-08-08 19:01:04
This commit is contained in:
@@ -0,0 +1,197 @@
|
||||
---
|
||||
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 工作流设计]]
|
||||
- [[上下文工程与记忆管理]]
|
||||
- [[沙箱权限治理]]
|
||||
Reference in New Issue
Block a user