AI Agent 运行时动态干预的思考

几周前的一个深夜，我盯着终端里狂奔的 Agent 日志，急得想砸键盘。它正按部就班地生成一份市场分析报告，已经跑了十几分钟，拉取了大量数据、画了图表，眼看就要收尾——我突然意识到，需求里漏了一个关键维度：“别按地区分，按用户年龄段分”。如果我此时打断它，之前所有的上下文、中间结果、工具调用状态全都得丢弃，重头再来。如果不打断，它很快就会产出一份我需要花同样时间手动修改的错误报告。

那一刻我深刻感受到，现有的绝大多数 AI Agent 架构，对待人类干预的方式，还停留在"红灯停、绿灯行"的阶段。它们不懂得如何在奔跑中调整姿态。

一个被低估的根本缺陷

我们总在谈论 Agent 的自主性、工具调用、长程规划，却很少正视一个事实：一旦 Agent 开始执行复杂任务，它就成了一场无法叫停也不能改剧本的舞台剧。用户只能在开场前把戏说清楚，然后在落幕时验收，中途你冲台上喊"换个演法"，演员完全置若罔闻。

这是一种协作方式的根本缺失。在真实的脑力协作中，副驾驶会轻拍飞行员肩膀，工程师会在同事写代码时递上一条新信息，领导会在项目进行中说"优先级变了，先放下手里这个"。这些干预不需要推倒重来，而是将新信息融入正在流淌的思考里。

而 Agent 的思维是一个闭合的 ReAct 循环（Thought → Action → Observation），没有为外界注入留出接口。主流的应对方案只有两个：等它跑完，或者杀掉重来。

我理想中的 Agent 应该像一位经验丰富的同事：在我抛出"改用 gRPC，别用 REST"这句话的下一秒，它不会手足无措，而是默默地将这条约束融入后续推理，该保留的保留，该调整的调整。实时、无缝、上下文不丢失。

问题边界也需要厘清。我关心的不是在模型训练时提升基础能力，也不是把提示词写得更巧妙，而是在 Agent 运行时，对于 ReAct、Plan-and-Execute、甚至多 Agent 协作这类架构，如何构建一套通用的干预机制。干预类型包括方向修正、需求补充、紧急叫停、局部回滚等，但不包括从根本上改造 LLM 本身。

现有方案都踩在了哪些点上

我开始系统性地翻看业界已有的尝试，梳理出一个光谱——从最简单的"中断-恢复"，到运行时注入，再到编排层优化。每一种解决了一部分问题，也都留下明显的盲区。

层级一：中断与恢复——更像存档读档，而非真实干预

LangGraph 的 interrupt() 加 Command(resume=...) 是这一模式的典型代表。它在预设节点暂停，把 State 落盘，等用户决策后再从断点继续。这解决了状态持久化和跨会话恢复的问题，适合"审批"、“确认"这类可预期的交互点。

但它致命的局限在于：你只能在写代码时就预设好的地方打断。用户想在 Agent 推理到一半、根本没设置断点的位置插话，这套机制毫无办法。而且所谓的"继续”，是重跑当前节点，而不是"把你刚才那句话揉进此刻的思考中"。本质上仍是停止-等待-继续。

层级二：运行时注入——目前最接近理想态

看到 OpenClaw 的 /steer 命令时，我心里一动。操作员在 Agent 活跃运行期间，直接通过 /steer 把一句指导注入当前会话，Agent 会顺势调整方向，不中断，不重启，上下文全部保留。甚至可以对子 Agent 精准定向，说"子 Agent 3，改变搜索策略"。

这是我目前见到最接近"轻拍肩膀"体验的实现。它证明了两件事：在工程上做到持续运行中接受并消化外部指令完全可行；上下文和工具状态的维护能做到顺滑不丢。但它仍有一个微妙的延迟：消息注入后，Agent 要等到当前工具调用结束、进入下一轮思考时才会"看见"它。如果你正在等待一个长达几十秒的 API 调用，这条修正指令就只能在队列里干等着。

层级三：过程级自动纠偏——让人工干预退居二线

SWE-PRM 这篇论文给了我很大启发。它不依赖人的介入，而是在 ReAct 循环中每隔几步就让一个过程奖励模型（PRM）检测执行轨迹是否偏离。如果发现规范错误、推理错误或协调错误，就自动生成自然语言反馈注入上下文，Agent 在下一步吸收并纠偏。实验数据很漂亮：SWE-bench 解决率提高了 10.6 个百分点，额外成本才 0.2 美元。

这个思路的高明之处在于，很多偏移是人在执行过程中没注意到的，或者懒得纠正的。让一个自动化的监督员来搞定，人只需要在严重偏差时介入。它揭示了一个关键可行性：运行时注入不光是人的特权，也能由系统自主触发。这与我的最终构想——“自动纠偏 + 人工干预"双层架构——完美吻合。

层级四：AbortController 模式——简单粗暴的紧急制动

如果只是想让 Agent 能随时停下来，基于 AbortController 的手写 ReAct 循环并不复杂。每一步检查 signal，外部随时 abort，再补齐未完成的 tool_call 让消息历史自洽。实现成本极低，不依赖任何框架，但它的定位非常窄：只是终止，不是"注入新指令后继续”。把 Agent 叫停之后怎么办，它不管。

层级五：编织 Harness——编排层的巨大潜力

Hugging Face 的研究《Don’t Train the Model, Evolve the Harness》展示了另一种思路。他们在不改变模型权重的前提下，仅通过迭代优化 Agent 的编排层（Harness）——包括上下文管理、错误处理、动态摘要、历史压缩、结果路由等 12 个组件——就把 SWE-bench 的通过率从 3.5% 拉升到 80.1%，翻了 23 倍。而且这套优化后的 Harness 换一个模型还能直接涨分。

这带来一个认知跃迁：Agent 的运行时编排层本身就是一个独立且高价值的干预接口。我们追求的"动态干预"，其实就是在动态地、智能地修改 Harness 的行为。上下文压缩能为注入新指令腾出注意力空间，状态管理和分层回滚能让修改精准且不破坏已完成的工作，动态摘要能解决长上下文中的"注意力稀释"问题。Harness 的这 12 个组件，几乎就是实现完整干预体系的工程蓝图。

几个真正棘手的核心挑战

摸完现有方案后，我开始意识到真正的困难不在于"能不能把消息塞进去"，而在于塞进去之后发生的一连串连锁反应。这里有五个问题，是现阶段绕不过去的。

1. 注入时机之痛：等一等，还是强行切断？

Agent 此刻正在调用一个工具，耗时 30 秒。我的新指令是"马上停掉这个调用，改用另一个 API"。如果等到当前调用返回，这 30 秒内 Agent 仍在浪费资源做错事，并可能产生副作用。如果强行 abort，就要扔掉这一轮的计算，还得处理好半路中断的状态一致性问题。有没有可能设计一个双通道机制，让 LLM 推理主通道保持畅通，同时有一个高优先级侧通道可以随时插话？

2. 上下文一致性走钢丝：新指令与已完成步骤的冲突

我刚说完"用 PostgreSQL"，Agent 之前已经连好了 MySQL 并查了一些表。这些中间结果还能不能复用？如果部分回滚，回滚到什么层级？全抹掉太浪费，不抹又自相矛盾。我们需要一种分层状态与选择性回滚的能力：只让受影响的局部失效，保留未受污染的部分。就像多米诺骨牌，只推倒必要的几张，而不是整条链。

3. LLM 的注意力稀释：新指令被淹没在长上下文中

在多轮对话里，Agent 已经积累了巨量的思考过程和工具输出。此时插入一句"别忘了，数据只取 2025 年以后的"，极有可能被 LLM 当作一条普通 remark 而忽略，尤其当它与 system prompt 产生微妙冲突时。我们或许需要一种高优先级注入格式，比如在注入时强制附带上下文摘要，把已完成部分压缩，让新指令占满注意力焦距，甚至让 Agent 复述一遍它对修正的理解。

4. 状态管理的复杂维度

Agent 的状态远不止一段文本对话历史。它包括检查点文件、内存中的变量、外部工具的副作用状态、子 Agent 的进行状态等。如何给这个复杂的状态集拍一张一致的快照？回滚时又如何只针对特定维度操作？多 Agent 场景下，一个 Agent 的航向修正要不要同步给依赖它的其他 Agent？这些都需要比普通程序事务复杂得多的状态治理方案。

5. 安全边界：干预本身成为攻击面

允许中途任意注入指令，无异于给 Agent 的"大脑"开了一个后门。恶意攻击者可能通过伪装成合法干预，逐步劫持 Agent 目标，或者注入隐蔽任务。我们必须建立严格的干预鉴权、权限分级和完整的审计日志，确保这条动态通道不会变成最大的安全隐患。

我正在尝试拼凑的解决图景

我不再寄希望于某个银弹方案，而是开始构建一个组合式的、分层的干预架构。下面是我目前设想的混合方案，融合了前面提到的多种思路。

第一层：异步消息队列 + 步骤间隙消费

在 ReAct 循环的每个步骤间隙——“思考之后、行动之前"或者"观察之后、再思考之前”——检查一个消息队列。如果队列里有用户的新消息，就以 user 角色注入 messages，让 Agent 在下一轮自然消化。这保证了在不打断当前原子操作的前提下，干预在最短的间隔内生效。粒度是"步级"，在绝大多数场景下已经足够好。

第二层：分层状态与选择性回滚

给 Agent 的执行状态分层：全局目标层、阶段目标层、子任务层、原子操作层。每层独立 checkpoint。当注入的新指令与某一层产生冲突时，只回滚到该层的上一个一致点，其下不受影响的细粒度工作全部保留。比如"改用 gRPC"可能只让当前子任务回滚到工具选择前，而之前的数据收集和用户意图分析不用重做。

第三层：PRM 作为自动保镖，降低人工干预频次

把 SWE-PRM 的思路融入进来。在 Agent 跑任务时，内置一个轻量级的 PRM 做实时轨迹检测。轻度偏移自动反馈纠偏；中度偏移标记出来，待用户确认；只有重度偏移才触发暂停，强制等待人工介入。用户始终保有主动注入的能力，不必等系统报警。这就形成了"自动纠偏兜底，人工干预按需介入"的双保险。

第四层：双通道推理与注意力强化注入

对于需要极低延迟的修正，可以研究 abort 当前 LLM 推理后热替换上下文，重新推理。注入的消息采用特殊的格式化标记，甚至压缩已完成的历史并摘要，把新旧指令的优先级清晰化。Agent 在收到注入后，被强制要求输出"我已理解的最新方向是……"，确保对齐。

第五层：借鉴 Harness 工程，让系统自我进化

Hugging Face 的 Harness 研究告诉我们，编排层的优化可以是自动化且可迁移的。把干预机制的每一次失败案例（注入后 Agent 忽略、回滚过头、状态不一致）都记录下来，用类似的自动化流程来迭代优化注入时机、回滚策略、上下文修剪等组件。让干预系统本身也成为一个可以持续演进的活系统。

写在最后

这套思考远未结束。但有一点已经清晰：Agent 的运行时动态干预，不应该只是一个功能补丁，而应被视作 Agent 架构的一等公民。 它关乎人机协作的流畅度，关乎智能体的真正可用性。Harness 工程的实验已经告诉我们，编排层的潜力超乎想象——在模型不变的情况下，我们仍有巨大的优化空间。下一代优秀的 Agent 框架，其核心竞争力会体现在对"过程"的掌控力上，而不仅仅是"结果"的惊艳。

路还很长，但方向已经亮起。如果你也在思考同样的问题，或已经在自己的项目中动手尝试，我非常希望能与你交流。这项探索，注定不能只靠一个人闭门造车。