ReAct Agent 运行时动态干预机制研究

研究课题：让 AI Agent 在执行复杂任务过程中，能够实时接收人类指令并调整策略，无需中断当前执行流程

创建日期：2026-07-07

---

一、问题定义

1.1 核心痛点

当前主流 ReAct Agent 架构（Thought → Action → Observation 循环）在执行复杂多步任务时，存在一个根本性的交互缺陷：

用户在 Agent 执行过程中产生的新想法、新需求、方向调整，无法被正在运行的 Agent 接收和处理。

具体表现：

• Agent 开始执行任务后，用户只能等待完成或终止重来


• 中途改变方向意味着：终止当前会话 → 重新描述需求 → AI 重新理解上下文 → 重新规划执行路径


• AI 的推理上下文（已积累的思考链、中间结果、工具调用状态）被完全丢弃


• 大量已完成的计算和推理被浪费

1.2 理想状态

用户在 Agent 执行任务的任意时刻，可以向其注入一条消息（指令、修正、补充信息），Agent 在不中断当前执行流的前提下，将新信息融入正在进行的推理过程中，实时调整后续策略。

类比：副驾驶轻拍飞行员肩膀 → 飞行员接收到信息 → 在不改变当前飞行状态的前提下调整航向。

1.3 问题边界

---

二、当前技术现状

2.1 已有方案分类

按成熟度和实现方式，现有方案可分为四个层级：

层级一：中断-恢复（Interrupt & Resume）

代表：LangGraph interrupt() + Command(resume=...)

核心机制：

1. Agent 执行到预设断点时，调用 interrupt() 暂停图执行


2. 当前 State 通过 Checkpointer 落盘（内存/SQLite/Postgres）


3. 中断信号（__interrupt__）返回给调用方，前端展示给用户


4. 用户做出决策后，通过 Command(resume=value) 恢复执行


5. 从断点处继续，State 无缝加载

# LangGraph 中断-恢复示例

from langgraph.types import interrupt, Command



def confirm_node(state):

    # 暂停执行，等待用户确认

    decision = interrupt({"question": "是否批准发送邮件？", "preview": state["email_content"]})

    if decision == "approve":

        return {"status": "approved"}

    return {"status": "rejected"}



# 恢复执行

graph.invoke(Command(resume="approve"), config={"configurable": {"thread_id": "xxx"}})

优点：

• 状态持久化成熟，支持跨会话恢复


• 断点精确，可预测


• 社区生态完善

局限：

• 只能在预设断点暂停，不能在 Agent 推理的任意时刻注入


• 恢复后是从断点重跑节点，不是"在思考中途插入新信息"


• 本质上仍是"暂停 → 等待 → 继续"，而非"边跑边调整"

参考来源：

• LangGraph 中断恢复与超时策略实战


• LangGraph Tutorial - Lesson 13: Human-in-the-Loop

层级二：运行中注入（Runtime Injection / Steer）

代表：OpenClaw /steer 命令

这是目前最接近用户理想状态的实现。

核心机制：

1. Agent 正在执行任务（active run）


2. 操作员通过 /steer <message> 向当前会话注入实时指导


3. Agent 在执行过程中接收到指导信息，融入当前推理


4. 会话状态、已积累的上下文、进行中的工具调用全部保持完整


5. Agent "不带节拍地"调整方向

# OpenClaw steer 命令

/steer 优先处理数据库迁移部分，报告生成可以延后

/steer 不要用 REST API，改用 gRPC

/subagents steer 3 改变搜索策略，聚焦2025年后的论文

关键特性：

• Steer vs Queue：/steer 用于即时航向修正（当前 run）；/queue steer 改变未来消息的默认行为


• 子 Agent 精准定向：/subagents steer <id> <message> 可单独纠正某个子 Agent，不影响主会话或其他子 Agent


• ACP 会话支持：外部编排工具通过 /acp steer --session 也能进行航向修正

优点：

• 真正实现了"不打断、不重启、实时调整"


• 保留了完整的推理上下文


• 支持多 Agent 场景的精细控制

局限：

• OpenClaw 生态相对小众


• 注入时机取决于 Agent 何时"读取"注入的消息（可能在当前步骤完成后）


• 对于正在执行的 LLM 推理（token 生成中），注入可能需要等到下一个推理周期

参考来源：

• OpenClaw’s New Steer Command

层级三：过程级自动纠偏（Process Reward Model）

代表：SWE-PRM（Process Reward Model for Software Engineering）

核心机制：

1. Agent 在 ReAct 循环中执行任务


2. PRM 每 N 步（如每5步）分析最近 K 步的执行轨迹


3. 基于分类法检测三类非效率：
   
   
   
   • 规范错误：忽略任务需求、重复动作
   
   
   • 推理错误：误判问题、选错工具
   
   
   • 协调错误：任务脱轨、验证失败
   
   
   
   


4. 生成自然语言反馈注入 Agent 上下文


5. Agent 在下一步推理中自动吸收反馈，调整策略

关键发现：

• 在 SWE-bench Verified 上，PRM 将解决率从 40.0% 提升到 50.6%（+10.6pp）


• 额外推理成本仅 $0.2


• 基于分类法的 PRM 优于无指导或显式动作处方型变体

与用户想法的关系：

• PRM 是"自动化的人类干预"——它替代了人类在过程中纠偏的角色


• 说明了一个关键可行性：在 Agent 执行过程中注入信息是技术上可行的


• 局限：PRM 的反馈是自动生成的，不支持人类实时输入

参考来源：

• When Agents go Astray: Course-Correcting SWE Agents with PRMs

层级四：AbortController 模式（可中断循环）

代表：手写 ReAct Loop + AbortSignal

核心机制：

1. Agent 主循环每步检查 signal.aborted


2. LLM 请求和工具调用都接收 signal 参数


3. 外部可随时调用 controller.abort(reason) 中断


4. 中断后做"干净退出"：补齐未完成的 tool_result，保持 messages 自洽


5. 下次恢复时，模型看到的是完整的对话历史

// 可中断 ReAct Agent 核心逻辑

async run(input: string) {

    this._abortController = new AbortController();

    const signal = this._abortController.signal;

    try {

        while (true) {

            if (signal.aborted) { return; }  // 检查点1：每步开头

            const resp = await this.client.chat.completions.create(..., { signal });

            this.messages.push(assistant);

            if (!assistant.tool_calls?.length) { return; }

            if (signal.aborted) { return; }  // 检查点2：工具调用前

            const toolMsgs = await Promise.all(...);

            this.messages.push(...toolMsgs);

        }

    } catch (err) {

        if (signal.aborted) {

            this._finalizeOnAbort(reason);  // 补齐孤儿 tool_call

            return;

        }

    }

}

优点：

• 实现简单，不依赖特定框架


• 中断粒度可控（步骤级、工具级）

局限：

• 只是"停止"，不是"注入新指令后继续"


• 需要额外实现消息注入 + 恢复逻辑

参考来源：

• 从零实现一个 ReAct Agent Loop - 可中断、可流式

层级五：Harness 工程优化（编排层动态演化）

代表：Hugging Face LAB — Don’t Train the Model, Evolve the Harness

这是 2026 年 7 月 Hugging Face 发布的一项实证研究，核心发现是：不修改模型权重，仅优化 Agent 的外部编排层（Harness），就能将 SWE-bench Verified 通过率从 3.5% 提升到 80.1%。这一结论与本文的研究方向高度相关——Agent 的运行时编排层本身就是一个可独立优化的"干预接口"。

Harness 的定义：

Harness（编排框架）是 Agent 与外部世界交互的完整基础设施层，包括：

实验数据：

关键发现：

1. 
   

   Harness 优化可跨模型迁移：同一套优化后的 Harness，从 DeepSeek-V3 迁移到 DeepSeek-V4-Flash 后，得分额外提升 +14.4 分，说明 Harness 层的改进具有通用性。

   
   


2. 
   

   成本优势显著：优化后的 Harness + 开源模型达到与 Claude Sonnet 4.6 相当的性能，但 API 成本仅为 1/7。

   
   


3. 
   

   优化过程本身可自动化：Hugging Face 使用自动化流程进行了约 22 轮迭代，每轮分析上一轮的失败案例，针对性改进 Harness 组件。这意味着 Harness 优化可以不依赖人工手动调试。

   
   


4. 
   

   冻结模型权重 ≠ 冻结能力：在模型完全不变的情况下，仅通过优化外部编排层，就能实现 23 倍的性能提升（3.5% → 80.1%）。

   
   

与本课题的关系：

Harness 工程本质上就是"运行时干预的基础设施"。Harness 中的上下文管理、动态摘要、错误处理、状态管理等组件，正是实现"运行时动态干预"所需的底层能力。这个实验从实证角度说明：

• Agent 的运行时层是一个独立且高价值的优化维度，不需要每次都等模型升级


• 编排层的改进可以系统化、自动化，不必完全依赖人工经验


• 同样的 Harness 改进可迁移到不同模型，说明编排层的抽象是通用的


• Harness 的 12 个核心组件可以作为"运行时干预机制"的设计蓝图

这也为本文提出的"方向五：基于 PRM 的混合架构"提供了工程验证——PRM 负责检测偏移，Harness 负责执行纠偏，两者协同就是一个完整的"自动干预 + 人工干预"双层系统。

参考来源：

• Don’t Train the Model, Evolve the Harness — Joel Niklaus (Hugging Face)

2.2 方案对比

---

三、核心待解决的技术挑战

3.1 消息注入时机问题

问题：Agent 正在执行一个不可分割的操作（如 LLM 推理中、工具调用中），此时注入的消息何时生效？

可能的策略：

• 等前步骤完成后注入：当前 tool call 返回后，将新消息插入 messages，下一轮推理时 LLM 看到


• 强制中断当前操作：abort 当前 LLM 请求/工具调用，注入消息后重新推理（浪费当前步骤的计算）


• 双通道并行：LLM 推理和工具调用通过异步队列，支持随时追加 system/user 消息

研究问题： 哪种策略在延迟、资源浪费、用户体验之间取得最佳平衡？

3.2 上下文一致性问题

问题：注入的新指令可能与 Agent 已经做出的决策/产出的中间结果矛盾。

例如：

• Agent 已决定使用 MySQL，用户注入"改用 PostgreSQL"


• Agent 已完成数据收集阶段，用户注入"数据范围缩小到2025年"


• Agent 已生成了3个子任务，用户注入"第2个任务不需要了"

需要解决的子问题：

• 如何检测注入消息与已有上下文/中间结果的冲突？


• 冲突检测后，如何决定回滚范围？（全部重做？部分回滚？仅调整后续步骤？）


• 回滚的粒度如何控制？（工具调用级？子目标级？阶段级？）

3.3 状态管理复杂度

问题：Agent 执行过程中的状态比传统程序更复杂——包含 LLM 对话历史、工具调用状态、中间文件/数据、子 Agent 状态等。

• Checkpointer 需要快照哪些状态？


• 部分回滚时，如何确定状态的"一致切面"？


• 多 Agent 场景下，一个 Agent 的方向调整如何传播到依赖它的其他 Agent？

3.4 LLM 的"注意力竞争"问题

问题：在已经很长的对话历史中注入新指令，LLM 可能"忽略"或"弱化"新指令的重要性。

• 长上下文中的"注意力稀释"：新指令可能被淹没在历史对话中


• 指令优先级冲突：system prompt 说"按原计划执行"，新注入的 user message 说"改变方向"


• 模型差异：不同模型对后注入指令的遵从度不同（研究表明 Claude 系列对 system prompt 的优先级遵循更严格）

可能的解决方向：

• 注入时使用特殊的"高优先级消息"格式（类似 system 级别）


• 在注入点做上下文压缩：总结已完成部分 + 突出新指令


• 注入后强制 Agent 输出"我理解的当前任务调整是…"的确认

3.5 安全与权限控制

问题：允许运行时干预打开了新的攻击面。

来自 Agent长程攻击研究 的警示：

• 意图劫持：通过多轮对话逐步改变 Agent 目标


• 目标漂移：在外部信息中嵌入隐蔽指令


• 任务注入：在主任务旁添加附带任务

运行时干预机制需要：

• 区分"合法用户干预"和"恶意注入"


• 对干预权限分级（某些操作不允许中途修改）


• 记录完整的干预审计日志

---

四、可能的解决方向

方向一：消息队列 + 步骤间隙消费

思路： Agent 的 ReAct 循环每步之间，检查一个消息队列。如果有新的用户消息，消费它并注入到 messages 中。

┌─────────────────────────────────────────────┐

│                Agent Loop                    │

│                                              │

│  ┌──────────┐   ┌──────────┐   ┌──────────┐ │

│  │ Think    │──▶│ Act      │──▶│ Observe  │ │

│  └──────────┘   └──────────┘   └──────────┘ │

│       ▲                               │      │

│       │         ┌──────────┐          │      │

│       └─────────│ Check    │◀─────────┘      │

│                 │ Inbox    │                  │

│                 └────┬─────┘                  │

│                      │                        │

│               ┌──────▼──────┐                │

│               │ User Msg    │                │

│               │ Queue       │                │

│               └─────────────┘                │

└─────────────────────────────────────────────┘

实现要点：

• 在 Thought → Action 和 Action → Observation 的间隙检查 inbox


• 新消息以 user 角色注入 messages 数组


• Agent 下一轮 Thought 时自然看到新消息


• 可选：注入时附带 priority 标记，高优先级消息触发上下文摘要

优点： 实现简单，与现有 ReAct 架构兼容

局限： 粒度为"步骤级"，不能中断正在执行的单个工具调用

方向二：双通道 LLM 推理（Hot Swap Context）

思路： LLM 推理过程中，支持"热替换"上下文——abort 当前推理，用注入的新信息重建上下文，重新推理。

用户注入 "改用gRPC" 

         │

         ▼

┌────────────────────────────────┐

│  1. Abort 当前 LLM 请求        │

│  2. 保留已完成工具的结果         │

│  3. 在 messages 中注入新消息     │

│  4. 可选：压缩历史上下文         │

│  5. 重新发起 LLM 推理           │

└────────────────────────────────┘

优点： 响应最快，注入后立即生效

局限： 浪费当前推理的计算；需要处理 abort 的边界情况

方向三：分层状态管理 + 选择性回滚

思路： 将 Agent 的执行状态分层管理，支持按层级回滚。

层级结构：

├── L0: 全局目标（用户原始需求）

├── L1: 阶段目标（规划出的大步骤）

├── L2: 子任务（每个阶段的具体操作）

└── L3: 原子操作（单次工具调用）



干预策略：

- 修改 L0 → 回滚到起点，全部重新规划

- 修改 L1 → 回滚到当前阶段起点，重新规划后续阶段

- 修改 L2 → 回滚到当前子任务起点，重新执行当前子任务

- 修改 L3 → 取消当前工具调用，换一种方式执行

实现要点：

• 每个层级有独立的 checkpoint


• 回滚时恢复到目标层级的最近 checkpoint


• 已完成且不受影响的下级状态保留

方向四：Multi-Agent 路由 + 动态任务图

思路： 将单 Agent 的执行拆分为多个子 Agent，通过动态任务图管理。用户干预触发任务图的实时重编排。

                    ┌─────────────┐

                    │ Supervisor  │ ◀── 用户干预入口

                    │ (任务编排)   │

                    └──────┬──────┘

                           │

              ┌────────────┼────────────┐

              ▼            ▼            ▼

        ┌──────────┐ ┌──────────┐ ┌──────────┐

        │ Worker A │ │ Worker B │ │ Worker C │

        │ (搜索)    │ │ (分析)   │ │ (生成)   │

        └──────────┘ └──────────┘ └──────────┘

干预场景：

• 用户说"不需要分析了"→ Supervisor 取消 Worker B，通知 Worker C 跳过分析结果


• 用户说"搜索范围缩小"→ Supervisor 向 Worker A 注入新约束


• 用户说"增加一个验证步骤"→ Supervisor 创建 Worker D，挂在 Worker C 之后

参考： OpenClaw 的 /subagents steer <id> 就是这个方向的实践。

方向五：基于 PRM 的混合架构（自动纠偏 + 人工干预）

思路： 结合 SWE-PRM 的自动检测和人工实时干预，构建双层干预系统。

┌──────────────────────────────────────────────┐

│                  Agent Loop                   │

│                                               │

│  Step N ──▶ [PRM 检测] ──▶ 正常继续           │

│                  │                            │

│                  ├── 轻度偏移 → 自动提示 Agent │

│                  ├── 中度偏移 → 标记待用户确认  │

│                  └── 重度偏移 → 暂停等用户干预  │

│                                               │

│  用户干预入口 ──▶ [注入队列] ──▶ 下一步消费     │

└──────────────────────────────────────────────┘

优点：

• 小问题自动解决，不打扰用户


• 大问题及时暂停，等用户决策


• 用户也可以主动注入，不必等 PRM 报警

---

五、参考资源

核心论文

• SWE-PRM: When Agents go Astray: Course-Correcting SWE Agents with PRMs — 运行时轨迹纠偏的过程奖励模型


• Inherited Goal Drift: Inherited Goal Drift: Contextual Pressure Can Undermine Agentic Goals — 上下文如何悄悄改写 Agent 目标


• Harness Engineering: Don’t Train the Model, Evolve the Harness (Joel Niklaus, Hugging Face, 2026-07) — 仅优化编排层实现 3.5%→80.1% 的性能跃升，证明 Harness 是独立于模型的高价值优化维度

工程实践

• LangGraph: interrupt() + Command(resume=…) + Checkpointer 中断恢复体系


• OpenClaw /steer: 运行时实时注入指导命令（最接近理想方案）


• ReAct Agent Loop 可中断实现: AbortController 模式 + 干净退出


• Hugging Face LAB Harness: 12 组件编排框架（流程编排、工具调用、分层存储、上下文管理、错误处理、压缩历史、屏蔽旧输出、动态摘要、文件处理、Schema验证、结果路由、状态管理），支持自动化迭代优化

对话修复

• Rasa Conversation Patterns: 对话修复策略（修正、取消、重启、澄清）


• Conversation Repair Manager: 误解检测 + 修复策略选择 + 上下文保留

安全与风险

• Agent 长程攻击研究: 5种攻击模式（意图劫持、工具链串联、目标漂移、任务注入、记忆投毒）


• Agent 防漂移机制: 目标锚定 + 漂移检测 + 自动修正/回滚

相关概念

• Human-in-the-Loop (HITL): 人在回路的通用范式


• Process Reward Model (PRM): 过程级奖励模型，每步评估而非仅结果评估


• Goal Drift: 目标漂移，Agent 行为逐渐偏离原始目标的现象


• Context Window Governance: 上下文窗口治理，管理长上下文中信息的权重和优先级

---

七、核心观点总结

1. 
   

   这是一个已被识别但尚未完美解决的问题。 业界已有多种方案，但每种都有明显局限。

   
   


2. 
   

   OpenClaw 的 /steer 是目前最接近理想状态的实现，但它仍然受限于"注入的消息在 Agent 下一个推理周期才被消费"的延迟。

   
   


3. 
   

   Harness 层是独立于模型的高价值优化维度。 Hugging Face 的实验（3.5% → 80.1%）从实证角度证明：不修改模型权重，仅优化 Agent 的外部编排层（Harness），就能实现 23 倍的性能提升。这意味着运行时干预机制的建设本身就有巨大价值，不必依赖模型升级来解决问题。Harness 的 12 个核心组件（流程编排、工具调用、分层存储、上下文管理、错误处理、压缩历史、屏蔽旧输出、动态摘要、文件处理、Schema验证、结果路由、状态管理）可以作为运行时干预系统的工程蓝图。

   
   


4. 
   

   Harness 优化 + PRM 检测 = 完整的干预闭环。 PRM 负责检测执行偏移，Harness 负责执行纠偏动作。两者协同就是一个"自动干预 + 人工干预"的双层系统。Hugging Face 的自动化 22 轮迭代优化流程，也为 PRM 的自动反馈机制提供了工程参考。

   
   


5. 
   

   核心技术挑战不是"能不能注入消息"，而是：

   
   
   
   
   • 注入后如何保持一致性（不回滚太多也不回滚太少）
   
   
   • 注入后 LLM 如何正确理解新指令的优先级
   
   
   • 多 Agent 场景下干预如何传播
   
   
   
   


6. 
   

   安全是这个方向必须同步解决的问题。 允许运行时干预 = 打开了新的攻击面。

   
   

---

本文档为开放研究课题，持续更新。

---