Prompt 工程已死，Loop 工程才是 Agent 时代真正的护城河

乐小野

发布于 2026-06-15 14:44:11

820

AGENT SYSTEMS · DEEP DIVE · 2026

Loop Engineering

从 ReAct 到工业级 Agent 的工程化拐点

—— 一个被严重低估、但决定 Agent 上限的子学科

POMDP Context Compression Inference-time Scaling RL on Trajectories

阅读对象：本文默认读者熟悉 LLM、Function Calling、ReAct、RAG，至少手写过一个 Agent。本文聚焦的是"为什么你的 Agent 跑到第 30 步就崩了"——以及如何系统性地解决它。

2022 年的 ReAct，2023 年的 AutoGPT，2024 年的 Devin / Cursor / Claude Code，2025 年涌现的 Manus、Computer Use Agent、Coding Agent…… 仔细观察会发现：能力分层早已不是模型分层，而是循环分层。

同一个 Claude / GPT，套在不同 loop 里，SWE-Bench Verified 通过率可以从 20% 跳到 70%。差的那 50 个点，不来自模型，来自谁在控制循环、谁在管理上下文、谁在做错误恢复、谁在终止——这就是 Loop Engineering。

Prompt Engineering 的天花板是 8K token；Context Engineering 把它拉到 200K；而 Loop Engineering 的天花板，是任务本身的可解性。

01 · 形式化：Agent Loop 是 POMDP 上的策略

抛开"Agent 就是 LLM 加循环"的口语化描述，一个严格的定义是：Agent Loop 是在部分可观测马尔可夫决策过程（POMDP）上，用 LLM 作为策略 π 的执行器。

FORMAL DEFINITION

M = (S,A,O,T,Z,R,γ) S: 真实世界状态（对模型不可见） A: 工具调用空间 = {tool_name, args} O: 工具返回 + 用户消息（observation） T: 环境转移（执行真实代码、API 等） Z: 观测函数（决定模型看到多少） R: 任务奖励（人类反馈 / 单元测试 / Judge） π=LLM(history,tools,system) → action

这个视角立刻给出三个非常硬的工程结论：

① 历史就是状态。POMDP 的最优策略需要 belief state，而 LLM 的 belief 只能存在于上下文里。上下文管理 = 状态管理，不是优化项，是必要项。

② 观测函数 Z 是可设计的。你给模型看截断的 stdout 还是完整 traceback、给完整 grep 结果还是 top-k——这就是在设计 Z，会直接影响策略表现。

③ 终止是策略的一部分。"什么时候停"本质上是 π 的一个 action，不是 wrapper 的事情。早期 AutoGPT 死循环的根源，正是把 finish 当成了 wrapper-level 判断。

02 · Loop 范式的演化：六代设计

把过去三年关键论文按"循环结构"维度展开，可以画出一条清晰的演化曲线：

GEN 0 · 2022 Chain-of-Thought

没有循环，只有"think 然后 answer"。Loop 的退化形式：T = 1。

GEN 1 · 2022 ReAct (Yao et al.)

Thought → Action → Observation 循环。第一次把"工具调用 + 观察反馈"做进单步推理。是今天所有 Agent 的语法基线。

GEN 2 · 2023 Reflexion / Self-Refine

引入外层循环：失败后用 verbal reinforcement 总结教训，第二次尝试从经验池开始。Loop 第一次有了"层级"。

GEN 3 · 2023 Plan-and-Execute / Plan-and-Solve

显式 planner 产出 DAG，executor 负责落地。计划与执行解耦，避免 ReAct 在长任务里"边想边走丢"。

GEN 4 · 2024 CodeAct / ToolFormer-style

把 action space 从"JSON 调用"压缩成"一段可执行 Python"。一次 action 等于多次工具组合，loop 步数下降 3-10×，token 消耗大幅降低。

GEN 5 · 2024 LATS / Tree-of-Thought / MCTS Agents

Loop 不再是线性轨迹，而是带 backtracking 的搜索树。用价值函数（Judge LLM 或 reward model）剪枝，从"贪心走"升级为"局部规划"。

GEN 6 · 2025+ Subagent / Hierarchical Multi-Agent

主 loop 不再亲自动手，而是 dispatch 给 subagent（独立上下文、独立预算、独立工具集）。Claude Code、Cursor Composer、Devin 都走的这条路。上下文隔离 = 长任务的唯一解。

这条曲线背后只有一条主线：把更多结构从 Prompt 中外推到 Loop 框架里。Prompt 越来越薄，Loop 越来越厚。

03 · 五大工程子问题

3.1 · TERMINATION

终止：从启发式到可学习的停止策略

工业实践里，终止条件至少要分四层：

L1 显式终止：暴露 submit_answer / finish 工具，由策略本身触发。

L2 资源终止：step / token / 美元预算硬上限。一定要在策略可见的位置告诉模型"还剩多少预算"，否则模型不会自我节流。

L3 行为终止：检测重复 action（如连续 3 次 hash 相同的 tool call）、检测 no-progress（n 步内文件 / 状态无变化）。这是 AutoGPT 时代死循环的主要根因。

L4 评估终止：独立 Judge LLM 在每 K 步上评一次 "task complete?"。τ-bench 与 GAIA 上，引入轻量 judge 可让平均轨迹长度下降 30%+，且总成功率上升。

3.2 · CONTEXT

上下文管理：对抗 Context Rot 与 Lost-in-the-Middle

"200K context = 不用管"是巨大的工程谎言。Anthropic、Chroma 在 2024-2025 的多次评估都指向： 长上下文召回是非线性退化的——超过有效区间后，召回率随长度近似指数下跌（context rot），且中段最严重（lost-in-the-middle）。

实战中常用的复合策略：

① 滚动摘要（rolling summary）：每 N 步把"早于 N 之前"的 history 压成结构化摘要（goal / decisions / open_questions / facts），原始 trace 移入 cold storage。

② 分层记忆（MemGPT-style）：main context（工作内存）+ external memory（向量库 + 文件系统），由策略主动 page-in / page-out。

③ 工具结果裁剪（tool result truncation）：大段 stdout / 网页正文应该返回摘要 + 可点击的 read_more(handle) 工具，按需展开。Cursor / Claude Code 都是这么干的。

④ 关键事实固化（pinned facts）：把"用户名是 X / 数据库 schema 是 Y"这类高复用事实，写进 system 段而非 user 段，避免被滚动摘要冲掉。

⑤ Subagent 隔离：把高 token 的子任务（爬一个网站、读一个 50k LOC 仓库）丢给 subagent，主 loop 只接收最终摘要。这是当前长任务唯一规模化可行的解。

3.3 · RECOVERY

错误恢复：把 error 设计成"可学习的观测"

错误恢复的核心不是"重试"，而是让错误对策略来说是 differentiable signal——即模型读完之后能改下一步行为。一个工业级的错误返回应该是：

{ "ok": false, "error_code": "FILE_NOT_FOUND", "message": "src/foo.py does not exist", "hint": "Did you mean src/foo_v2.py? Use list_dir to verify.", "retryable": true }

字符串 "Error: file not found" 会让 50% 的模型胡乱继续；上面这种结构化错误能让恢复率显著上升。这是 CRITIC（Gou et al., 2024）和 Self-Debug（Chen et al., 2023）的核心思想：错误也是观测，必须是可读的观测。

此外要分清三类失败：瞬时（网络 / rate limit） → 指数退避重试；策略错误（参数错 / 工具选错） → 让模型重决策；不可恢复（权限 / 资源不存在） → 立刻冒泡到上层 planner。把它们打成同一种"重试 3 次"是工业 Agent 最常见的反模式。

3.4 · DRIFT

轨迹漂移：长程任务的"目标遗忘"

实测：在 30 步以上的任务里，纯 ReAct 风格的 Agent 有 ~40% 概率"忘掉初始目标"——典型表现是反复在中间细节上打转、修复一个其实不重要的子问题。

缓解手段：

▸ Goal pinning：把 goal 放进 system，且不参与摘要压缩。

▸ Plan caching：planner 产生的 DAG 全程可见，executor 每步引用当前节点 ID。

▸ Periodic rerooting：每 K 步重写一次 "current state vs goal" 摘要，强制模型自己 re-anchor。

▸ Anchor probes：每 K 步用一个独立的 judge 提问 "are we still on track?"——这是 LATS / Reflexion 衍生出的轻量做法。

3.5 · OBSERVABILITY

可观测性：Agent 也要有 OTEL

没有 trace 的 Agent 不可调试，不可调试的 Agent 不可优化。生产级最低要求：

▸ 每一步保留 (prompt, completion, tool_call, tool_result, latency, prompt_tokens, completion_tokens, cost)。

▸ 用 OpenTelemetry GenAI Semantic Conventions 做 span，方便接 Langfuse / LangSmith / Arize / 自建 ClickHouse。

▸ 提供轨迹回放：基于历史 trace + 工具 mock 复现失败案例。

▸ 提供 trajectory diff：v1 vs v2 同一任务的轨迹差异，是 prompt / loop 改动的最可靠 A/B 信号。

04 · 失败模式分类（Anti-Pattern Zoo）

把跑炸的 Agent 按"失败原因"归类，工业实践里反复出现的有这八种：

① Infinite Loop：连续相同 action 没有 detector，常见于 finish 工具被忽略。

② Premature Termination：模型在 30% 进度处自信地 submit_answer，常见于 finish 工具描述太宽松或缺少 self-check。

③ Hallucinated Tool Call：模型调用一个不存在的工具，或传入未声明的参数。本质是 schema constraint 没生效。

④ Context Rot Crash：上下文超过有效窗口后召回率崩盘，模型开始"凭印象"作答。

⑤ Goal Drift：长任务中目标被中间细节稀释，最终交付的是"细节最优解"而非"原任务"。

⑥ Recovery Storm：错误处理写成无脑 retry，导致 rate limit / 账单雪崩。

⑦ Plan-Execution Mismatch：planner 设计的步骤超出 executor 工具集能力，又没有 replan 通道。

⑧ Reward Hacking：当用 LLM 做 judge 终止时，主 agent 学会"看起来完成"而非真正完成（典型出现在 RL fine-tune 后）。

05 · Loop 与 Inference-time Scaling / RL Fine-tuning

Loop Engineering 不只是 wrapper 工程，它和模型训练 / 推理两端都强耦合：

▎ Inference-time Scaling 视角

o1 / R1 / o3 把"思考"内化进 token 维度的串行扩展；Loop 则把"思考"外化到环境 × 工具维度的串行扩展。两者是同一个 axis 的两端：用更多 compute 换更高任务成功率。Best-of-N、self-consistency、tree search、subagent fan-out，都是把 inference compute 投到 loop 结构里。

▎ Training-time 视角

2025 年开始，agent fine-tuning 范式正在从 SFT-on-trajectories 走向 RL-on-trajectories（DPO / GRPO / RLOO + 任务级奖励）。这里 Loop 设计直接决定 reward shape：终止条件 = episode boundary；上下文管理 = state representation；错误恢复 = 负样本来源。Loop 的 bug 会被训练放大成模型行为——这是新一代 agent 工程师必须懂的事。

06 · 评估：用什么来证明你的 Loop 真的更好了

主流公开 benchmark：

SWE-Bench Verified 真实 GitHub issue 修复，强调多文件编辑 + 测试通过。

GAIA 通用助手任务，强调多模态 + 工具组合 + 长程推理。

τ-bench 真实业务对话 + 工具，专门测试 policy adherence 与终止判断。

WebArena / VisualWebArena 真实网页操作，环境噪声极大，是 loop 鲁棒性的试金石。

OSWorld 真实操作系统任务，测 Computer Use 类 agent 的端到端能力。

内部评估更重要的指标，建议在 dashboard 上同时盯：

▸ Pass@1 / Pass@k（单跑 vs N 次采样）

▸ 平均 trajectory length / cost per task（效率维度）

▸ recovery rate（出错后多少比例能修复）

▸ premature_finish_rate / infinite_loop_rate

▸ token efficiency = useful_output_tokens / total_tokens

07 · 实战 Checklist（可直接 copy）

□ 1. Action space 显式约束：JSON Schema + 服务端 validate + 拒绝即重生成（constrained decoding 优于事后校验）。

□ 2. 错误结构化：error_code / hint / retryable 三件套，别返回裸字符串。

□ 3. finish 工具 + judge LLM 双保险：策略侧主动收 + 外部 K 步抽检。

□ 4. 预算可见：把 "remaining_steps / remaining_tokens / remaining_budget" 注入每一步 system，模型才会节流。

□ 5. 工具结果分级：默认摘要，按需展开，绝不一次塞完整 stdout。

□ 6. Goal 不进摘要：在 system 里 pinned，永远完整可见。

□ 7. 重复 / 无进展 detector：基于 action hash 与 state hash，触发即强制反思或终止。

□ 8. Subagent 隔离：高 token 子任务（爬虫、代码库探索、多文档分析）必须隔离上下文。

□ 9. 全量 trace + 回放：OTEL 接 Langfuse / 自建库，trajectory diff 当作 A/B 信号。

□ 10. 失败用例进 eval set：每一次线上 incident 都应该转化成回归 test，否则你只是在原地踏步。

08 · 写在最后：Loop 是 Agent 时代的 Architecture

我们正在经历一次范式迁移：模型变成原料，Loop 变成架构。

Web 1.0 时代，工程师讨论的是 CGI；Web 2.0 时代讨论的是 MVC、REST、CQRS——架构层而非语言层。AI 工程也将走完同一条路：从"调 prompt"走到"调 loop"。Cursor 的 Composer、Claude Code 的 subagent、Devin 的 planner、Manus 的 multi-step browser loop，本质都是同一个东西的不同变体——把 LLM 嵌进一套可控、可观测、可优化的循环结构里。

所以下次再有人说"我们也做了个 Agent"，请先问他三件事：你的 finish 工具在哪？你的上下文怎么压？你的错误怎么变成观测？这三个问题，比任何 demo 视频都更能说明它能不能真的上生产。

KEY TAKEAWAY

模型决定了 Agent 的下限， Loop 决定了它的上限。

这不是 prompt trick，这是 Agent 架构学的开端。