↓
  1. SecurityClaw 学习笔记/

12 规划、执行与循环：Agent 如何基于证据迭代

·1146 字·3 分钟
安全研究 Security Securityclaw Agent Planning Loops React

结论先说：一次规划永远执行，那叫脚本；能根据证据改计划，才叫 Agent #

真正的 Agent 循环，不是“先生成一个完美计划，再照着跑”。

它更像这样：

先给出一个当前最合理的计划
  -> 执行一步
  -> 看结果是否支持原计划
  -> 如果不支持，就调整计划

也就是说，规划不是静态蓝图，而是动态假设。

一、先分清三种常见模式 #

1.1 ReAct #

  • 边想边做
  • 每一步都在 reasoning 和 acting 之间来回
  • 灵活，但控制难

1.2 Plan-and-Execute #

  • 先出完整计划
  • 再按计划执行
  • 结构清楚，但对计划质量依赖高

1.3 图式编排（Graph-Orchestrated Loop） #

  • 规划、执行、评估、恢复分成显式节点
  • 每一步由状态和边共同约束
  • 最适合可恢复、可审计的系统

SecurityClaw 最终偏向第三种。不是因为它“更高级”，而是因为它更适合安全场景下的可控迭代。

二、一个可用的规划循环至少有哪三层 #

# 伪代码：证据驱动的迭代循环
while not stop(state):
    plan = planner(state)          # 当前假设
    step_result = executor(plan)   # 执行一步
    evidence = evaluator(step_result)
    state = update_state(state, plan, step_result, evidence)

这里有三个关键对象：

  1. plan：下一步假设
  2. step_result：执行结果
  3. evidence：对结果的解释

如果系统里只有 plan 和 result，没有 evidence，那它其实很难真正“学会调整”。

三、为什么“执行结果”不能直接当成“下一步规划输入” #

很多简化实现会写成：

messages.append(tool_result)
plan = llm(messages)

这在小 demo 里能跑，但在真实系统里会很快失控，因为：

  • 原始结果可能很长
  • 结果可能混杂噪音
  • 模型不知道应该从结果里提取什么

所以中间必须有一层评估 / 摘要：

evidence = {
    "status": "partial",
    "coverage": 0.42,
    "reasoning": "当前证据不足，需要扩大查询范围",
    "next_hint": "switch_data_source"
}

真正推动下一轮规划的，不是“原始结果本身”，而是“对原始结果的结构化解释”。

四、为什么循环一定要有刹车 #

任何规划循环如果没有停止系统，都会在某个失败路径里开始无限转。

必须至少有三类刹车 #

4.1 成功停止 #

if evidence.sufficient:
    return stop

4.2 预算停止 #

if step_count >= max_steps or token_budget <= 0:
    return stop

4.3 恢复失败停止 #

if recovery_attempts >= max_retries:
    return stop

你如果只做“成功停止”，那系统一旦失败，就只能在坏路径里循环。

五、重复计划保护：为什么这个细节重要 #

如果规划器连续三轮都生成相同计划，而结果也没变化，那系统基本已经卡住了。

if plan == last_plan and evidence.status == last_evidence.status:
    repeated_plan_count += 1
if repeated_plan_count >= 2:
    return stop_or_recover

这个保护的重要性在于：

  • 它不等模型承认失败
  • 它从运行轨迹里直接判断系统已经陷入自我重复

这比单纯看 error_count 更聪明，因为有时候系统没有报错，只是在“没进展地重复成功”。

六、为什么图式编排比普通 Plan-and-Execute 更稳 #

普通 Plan-and-Execute 的问题是：

  • 计划和恢复混在一起
  • 停止条件通常藏在一个大循环里
  • 很难为每一类失败定义不同转移边

图式编排的好处是：

flowchart TD
    Plan[Plan] --> Execute[Execute]
    Execute --> Evaluate{Evidence sufficient?}
    Evaluate -->|yes| Finish[Finish]
    Evaluate -->|no| Recover{Need recover?}
    Recover -->|yes| Plan
    Recover -->|no| Stop[Stop]

一旦你把边显式写出来，很多过去靠“经验”处理的问题就能被测试了。

七、这一篇真正要记住的框架 #

规划循环最该记住的一句话：

Agent 不是“不断计划”，而是“不断用证据修正计划”。

你可以把它记成：

plan
  -> act
  -> observe
  -> evaluate
  -> replan / recover / stop

这就是多步 Agent 和脚本式自动化真正的分水岭。

八、验证命令 #

pytest tests/ -k "plan or loop or retry or replan" -v