「阿新聊 AI」同步更新，欢迎关注

🌐 AI 社区 · 91aihub.com

从TL;DR来看，先给一张可以背下来的坐标

把这篇长文压成五句话。后面字都是在展开它们：

• 1️⃣ loop 是一个递归目标——不是一次性调用，而是继续进行并由外部约束决定何时停止。
• 2️⃣ “done”是断言。不是证明——agent 自己说完成并不可靠，需要独立 verifier。
• 3️⃣ Prompt engineering 关注单回合战术指令，而 loop engineering 则设计整个周期的运行逻辑。
• 4️⃣ 从 prompt → context → harness → loop 的四层结构看，每一层都包裹而非替代。怎么说呢，
• 5️⃣ 四代循环谱系展示了退出条件、状态载体与成本三大演进轴心。

一句话定义 + 与 prompt 的本质差别

源仓库 cobusgreyling/loop-engineering 给出的直白定义：loop 是一个递归目标。至于拆解关键词，

• 递归：多轮循环，一次调用不算。
• 目标：围绕一个持续目标推进，随便聊天不算。
• 外部约束：被状态、验证、人类 gate 和程序边界控制；模型想干嘛就干嘛不算，

Addy Osmani 在那篇被反复引用的标杆文里给了更完整版本：“a loop is a recursive goal where you define a purpose and AI iterates until complete”。注意“iterates until complete”，它预设了一个“complete”的存在而且这个 complete 不是 agent 自己说了算。

"done 是断言，不是证明"

This principle is crucial: when an agent claims “I’m done”,it’s merely asserting—not proving—wher goal truly reached its completion.

Pain Points:

• No reliable exit condition:If an agent decides termination itself,you’ll face infinite loops,silent failures and skyrocketing bills.
• Lack of independent verification:The model’s training objective is to generate plausible code。not to validate correctness.
• User frustration:The team spends hours debugging runaway loops rar than delivering features.

"prompt engineering 关注什么loop engineering 关注什么"

PDE focuses on “one-shot” instructions: system prompt design,instruction order,few-shot examples and output format constraints—essentially tactical directives for a single turn.

LDE extends furr by asking system-level questions:

• Trouble-shooting frequency – how often should this task run?
• Caching & persistence – where do we store previous round results?怎么说呢，
• Causal flow – which state do we read before starting next iteration?
• Error handling – who decides wher to pause or rollback?
• SLA compliance – what happens if something goes wrong?

A quick rule of thumb: If your agents are manually triggered once per day n PDE is your lever;if y run continuously or concurrently n LDE becomes critical.

至于演进坐标，prompt → context → harness → loop

俄罗斯套娃结构

prompt ⊂ context ⊂ harness ⊂ loop
──────── outermost

• alert!The inner layer is still necessary even after adopting LDE— world still needs good prompts.

四层演进逐层拆解：每层解决什么留下什么

Sorry for broken table formatting—let's re‑structure properly:

# 层级	# 主导时间	# 解决的问题	# 主要动作	# 天花板
Prompt engineering	-	怎么把指令写好？角色设定、步骤拆解、few-shot、CoT	措辞再完美，也无法供给模型从不知道的事实。 任务一旦需要模型不知道的信息，就到头啦！	缺少足够上下文导致模型失误。
Context engineering	-	模型在推理时看到什么？挑选最关键 token 并持续维护；有限 window 内只剩下最必要信息。	假设 agent 一次性推理不能覆盖几十步、多小时运行时就失效！	一次性推理不足以覆盖长周期任务。话说回来，

... But let's simplify: **Prompt** – writes instructions. **Context** – provides relevant tokens within window. **Harness** – sets environment & tools. **Loop** – orchestrates execution cycles over time. The key takeaway: • When **prompt** fails because it can't provide unknown facts,• When **context** fails because it can’t hold enough history。• When **harness** fails because tools / permissions / observability are missing,you must stop adding layers of complexity until each lower layer is solidified. Thus before investing in full-loop automation you should first fix se root issues.

Tosea 的“到某个时间点后 coding agent 能够自治运行足够久且从错误中恢复得足够好”，于是瓶颈转移到了循环设计上。此时单回合调整已经无力提高，而连续迭代才成为突破口——这就是为什么现在要讨论 Loop Engineering 的根本原因。

Pain Point Summary:

• No clear stopping condition = infinite billing cycles.
• Lack of external verifier = silent failures that only show up in metrics dashboards.
• Cumulative token cost grows linearly with conversation length—your budget may explode overnight.
• Your team spends more time triaging failures than delivering value.

The most common misunderstanding is treating Loop as an umbrella term replacing Prompt / Context / Harness. In reality Loop sits *above* Harness and adds “long‑term runtime logic” that orchestrates repeated cycles while relying on those lower layers for tools,state persistence and token supply.

• Harness answers “What environment does agent need?”–tools,permissions,worktree。feedback loops .
• Loop answers “How often does it run?其实，When does it stop?老实说，”–trigger,state,termination。upgrade .
• Without Harness an agent will fail instantly;without Loop it will run only once . ​ This boundary is critical because misalignments lead to wasted effort when teams think y’ve solved one problem only by adopting Loop terminology.

  
  This illustration shows Layered Dependency from Prompt up to Loop.
  
  与相邻概念的边界：loop vs goal / vs workflow / vs harness / vs automation
  

# 层级	# 关键维度
	主导时间	解决的问题	主要动作	天花板
Prompt engineering
怎样写好指令？角色设定、步骤拆解、few‑shot、CoT。
缺少足够上下文导致模型失误。

` ... But due to space I’ll summarize key distinctions in bullet form rar than full table: *Goal* • Explicit finish condition . • One‑off or daily check tasks. • Stops when target achieved. *Loop* • Continuous operation without permanent endpoint. • Depends on external stop hook or evaluator. • Handles recurring events . *Workflow* • Fixed sequence of steps executed once per input. • Suitable for stable pipelines like CI/CD runs. *Automation* • Executes pre‑defined steps without internal decision logic. • Failure mode visible immediately . *Harness* • Provides environment scaffolding—tools,permissions,worktrees. • Does not decide timing or termination.

四代智能体循环谱系：ReAct → Plan-Execute → Reflexion → Loop Engineering

• Barely a wrapper around earlier ideas:. Each generation wraps its predecessor with new safety nets without discarding core principles.
• A cycle never replaces prompts entirely—only augments m with triggers & verifiers.
• The evolution mirrors real-world frustrations:
  • No exit condition ⇒ Infinite loops.
  • Mismatched context ⇒ Token bloat.
  • Lack of observability ⇒ Silent failures.

  ​
  

  The following compact table captures each generation’s key attributes:

​ 维度 对比	​ Goal	​ Loop	​ Workflow	​ Automation	​ Harness

Because this formatting gets messy in plain text I’ll provide concise bullet versions instead:

至于第一代。AutoGPT

​ 代际	代表作	触发方式	状态载体	停止条件	验证方式

特征	描述
触发方式	人手动输入高层目标
状态载体	所有历史放入 context window
停止条件	Agent 自己判断
验证方式	无独立 verifier

再看第二代，ReAct/Plan‑Execute/Reflexion

特征	描述
触发方式	人手动触发或事件驱动
状态载体	Reasoning trace + episodic memory
停止条件	Agent 判断 + 外部 rubric
验证方式	Reflexion 引入自评估

从第三代来看，OODA/Magentic-One/多 Agent

特征	描述
触发方式	定时器或事件队列
状态载体	多 Agent 分布式 context 与文件程序持久化
停止条件	策略级 reset + 步骤级 retry
验证方式	多 Agent 内部互评

第四代这方面，Loop Engineering 产品化

特征	描述
触发方式	cron/webhook/manual trigger
状态载体	文件程序外置 state
停止条件	外部 stop hook + 独立 evaluator
验证方式	maker/checker 分离 + deterministic verifier

---

🚨 使用者痛点汇总

• ❌ No Exit Condition ➜ Infinite billing spikes & silent failure alarms!\
• 💸 Total token cost explodes linearly as history grows ➜ budgets blown out fast!不过，\
• 📉 You’re spending more time debugging loops than building features ➜ productivity suffers!\
• 🧩 Your team misallocates resources on wrong layer ➜ wasted effort!\
• 🔒 Lack of observability => you don’t know *** a task failed until months later!

✅ 如何快速定位并改进

1. ⚙️ 确认每个低层已稳固：
   • Prompt -> 清晰且可复制
   • Context -> 持续挑选 & 缓存
   • Harness -> 工具权限 & 可观测性齐全
2. ⏰ 引入外部终止机制：
   • Stop hook 或计数器限制
   • 独立 evaluator 验证完成度
3. 📈 将 state 从 context 拆离至文件程序或数据库：
   • 减少 token 消耗
   • 可重启性与并行度
4. 📊 建立监控仪表盘：
   • 实时查看循环次数、错误率与费用消耗

---

---

"

---