先回顾标准 ReAct：Thought → Action → Observation 循环，每一轮 Agent 做决策时，把全部历史（之前所有 Thought、Action、Observation）拼到 Prompt 里一起喂给模型。

设：

$n$ = 循环轮次
单轮产出（Thought+Action+Obs）平均 token 长度 = $L$ （近似常数）
第1轮推理：读取历史长度 ≈ $L$
第2轮推理：读取历史长度 ≈ $L+L = 2L$
第3轮推理：读取历史长度 ≈ $3L$
…
第 $n$ 轮推理：读取历史长度 ≈ $nL$

总累计读取量（所有轮次加起来）

S = L + 2L + 3L + \dots + nL = L\cdot \frac{n(n+1)}{2} \approx \frac{L}{2} n^2

👉 这就是二次方增长的根源：每一轮都重读全部过往历史。

注意区分两个概念：

单轮输入长度： $O(n)$ （线性）

累计缓存读取量（每轮都读一遍历史，累加）： $O(n^2)$ （二次）

这是原生 ReAct 最经典的效率问题，和Loop Engineering 痛点直接对上：Loop 跨轮持续跑的时候，成本、延迟会快速失控。

补充：什么时候会偏离严格二次方？

如果 Observation 非常长（比如工具返回大文档）， $L$ 不再是常数，二次方会变成更糟；
如果做了简单截断：到最大上下文窗口后丢弃最早记录，累计读取会变成有界的线性增长，但代价是丢失早期信息，Agent 容易失忆、违背前期约束。

如何降低这个增长（按流派分类，贴合 Agent Loop / Graph 工程视角）

核心思路只有一句话：打破“每一轮都重读全量历史”这个前提。下面从轻量改造到架构级方案依次列出：

1. 摘要压缩（Summary / Rolling Summary，最常用）

每经过 k 轮，把前面 k 轮历史压缩成一段摘要，不再保留原始 Thought/Obs 原文。

策略：滑动窗口摘要、分层摘要、遇到关键节点（任务分支、审批点）才摘要
复杂度变化：原始 $O(n^2)$ → 控制为 $O(n\cdot C)$ ， $C$ 是摘要固定长度，变成线性
缺点：摘要会丢失细节，容易引入摘要幻觉；关键信息丢失会导致任务失败。

Loop 工程里常用：在循环的“校验完成节点”触发摘要。

2. 检索式历史（RAG / 向量检索，按需读取，不预加载全部）

不再把全部历史塞进 Prompt，改成：本轮决策时，根据当前问题/目标，只检索相关历史片段。

不再固定读取 1~n 全部历史；读取量和相关性挂钩，而不是和轮次绑定
复杂度：理想情况下接近 $O(n\cdot K)$ ， $K$ 是每次检索召回片段数量（常数）
痛点：时序依赖、隐性约束很难被向量检索命中（比如“之前约定的审批规则”）；适合信息检索型任务，不适合强时序依赖的长流程。

3. 状态机 / 显式结构化状态（Graph Engineering 的方案）

这是 Graph 工程的核心解法：把历史里的“有效状态”和“过程日志”拆开

结构化状态（state）：变量、标志位、依赖、中间结果、审批状态，用 JSON/Protobuf 持久化，固定大小
过程日志：原始 Thought/Obs，存入外部存储，默认不读；只有异常回溯、人工排查时才读取
Agent 每一轮决策只传入【当前结构化状态 + 最近少量交互】，而不是全量日志
复杂度： $O(n)$ ，且常数项很小；状态大小基本不随轮数膨胀

对比： ReAct 原生：历史 = 日志，决策必须读全部日志 Graph 编排：状态是一等公民，日志只是审计附件

4. 分层记忆 / 分离短期记忆 + 长期记忆

短期记忆：最近几轮原始交互，直接放进 Prompt（小窗口）
长期记忆：重要结论、约束、已完成子任务，写入独立记忆库；非相关轮次不加载
典型：MemGPT 这类架构；本质是窗口截断 + 重要信息抽取写入长期记忆的组合。

5. 断点式、事件驱动的循环（改造 ReAct 循环本身）

原生 ReAct 是每一步都调用模型决策；改成：只有事件发生（工具返回异常、分支切换、人工审批到达）才触发模型思考；普通确定性步骤直接走硬编码路由，不进入 ReAct 思考轮次。 👉 减少模型调用次数 n，从源头压低累计读取量；这也是 Graph 编排里“确定性节点不进Agent循环”的设计。

6. 增量式上下文、差分输入（Diff Prompt）

只向模型传递从上一轮到本轮发生变化的部分，不变的历史不再重复传入。

适合状态变化很小的循环；缺点是模型需要理解差分，很多模型原生不友好；校验成本高。

7. 遗忘策略（选择性丢弃）

规则化丢弃：已经确认完成的子任务、失效的临时信息，标记为可丢弃，不再参与后续 Prompt。适合有明确子任务边界的任务；风险是没有回溯能力，出错后无法复盘。

方案对比 & 选型（贴合 Loop / Graph 工程视角）

方案	复杂度改善	信息损失	适合场景
原始 ReAct	$O(n^2)$	无	短轮次 Demo
滚动摘要	$O(n)$	有（摘要丢失细节）	长循环、创意类、分析类 Loop
向量检索按需加载	接近 $O(n)$	隐性时序约束容易丢	信息查询、知识库类 Agent
显式结构化状态（Graph）	$O(n)$ ，常数极小	日志和状态解耦，状态永不膨胀	业务流程、审批、多Agent编排、持续自主Loop（优先推荐）

一句话总结架构视角： ReAct 的二次方开销，本质是把过程日志当成了状态； Graph Engineering 的解法就是把状态显式抽出来，日志降级为审计，从根源规避二次方。

延伸思考题

Loop 工程是持续自主运转，天然 n 很大；如果仍然用原生 ReAct，成本随轮数爆炸，所以 Graph 工程才会提出显式执行图、结构化状态持久化，本质就是为了解决这个 $O(n^2)$ 的读取开销问题。

注意：本文归作者所有，未经作者允许，不得转载

ReAct 循环：为什么缓存读取量随轮数近似二次方（$O(n^2)$）增长