点击下方卡片，关注 「魔方AI空间」 公众号

「具身智能」交流群 ->>

写在前面
【从零走向AGI】旨在深入了解通用人工智能（AGI）的发展路径，从最基础的概念起，逐步构建完整的知识体系。

项目地址🔗：https://ai-mzq.github.io/From-Zero-to-AGI/

过去做大模型应用，大家最熟悉的是 Prompt Engineering：把提示词写清楚，让模型这一次回答得更准一点、更稳一点。

但到了 Agent 时代，问题变了。

一个 Coding Agent 修 bug，不会回一句“我知道了”就结束。它要读代码、改文件、跑测试、看报错，再继续修。

一个 Research Agent 写报告，也不会一口气生成完。它要检索资料、判断来源、调整提纲、补引用，最后还要校对。

到了 Agent 这里，难点已经从“这一轮答得好不好”，变成了“这一整件事能不能做完”。

落到工程上，会变成几个很具体的问题：

• • 能不能持续推进任务？
• • 能不能根据反馈修正？
• • 能不能知道什么时候该停？
• • 能不能避免重复试错？
• • 能不能把成功路径沉淀成可复用流程？

这些问题加在一起，就指向最近被频繁讨论的 Loop Engineering。

Prompt Engineering 关心这一轮怎么答，Loop Engineering 关心系统怎么一轮一轮把任务做完。

这篇文章会按一条技术演进线来讲：

01 什么是 Loop Engineering？

Loop Engineering（循环工程），说白了，就是专门设计 Agent 执行循环的一套工程方法。

它不只关心模型下一句话怎么说，更关心 Agent 下一步怎么做、做完怎么检查、失败怎么修、什么时候停。

一个最基本的 Agent Loop 长这样：

看起来像一个普通的 while 循环。

但真正难的地方不在这句 while not done，而在循环里的规则：

• • 什么时候继续？
• • 什么时候停止？
• • 什么时候重试？
• • 什么时候回滚？
• • 什么时候请求人类确认？
• • 什么时候拆分子任务？
• • 什么时候压缩历史？
• • 什么时候把成功路径固化成 workflow 或 skill？

这也是为什么到 2026 年，Loop Engineering 会被 AI 工程圈放到台前。

它背后是开发方式的变化：开发者不只是在给模型写下一句 prompt，还在设计一个能持续推理、执行、检查、修正的工作闭环。

Loop Engineering 的核心，是把 Agent 的自主执行变得更可控。

02 为什么 Prompt Engineering 不够了？

Prompt Engineering 当然有价值。

它解决的是一次交互里的输出质量：让模型答得更准确、更稳定，也更符合格式。

比如：

• • 让模型按 JSON 输出。
• • 让模型扮演某个专家角色。
• • 给模型几个示例，提升输出一致性。
• • 明确告诉模型不要编造、要引用来源。
• • 规定回答结构，比如“背景、方法、结论、风险”。

这些都属于 Prompt Engineering，目标是提升单次生成质量。

但 Agent 做的是多步任务。

例如你让 Agent 修一个 bug，过程可能是这个样子的：

到了这里，关键就不再是某一句 prompt 写得多漂亮，而是整个过程能不能稳定跑完。

Prompt 可以告诉模型“遇错重试”，但它不能解决：

• • 历史状态怎么保存？
• • 工具返回结果怎么进入下一轮？
• • 重试几次算够？
• • 报错后该换策略还是继续原路线？
• • 任务完成如何验证？
• • 模型跑偏时谁来拉回来？

所以 Prompt Engineering 是第一层，但 Agent 需要往上再叠几层工程能力。

03 Context Engineering：让模型每一轮看对信息

任务进入多轮执行后，第二个问题很快会冒出来：

模型每一轮到底应该看到什么？

同一句 prompt，放在不同上下文里，结果可能完全不同。

比如模型收到一句：

继续修复测试失败的问题。

如果上下文里有完整报错、最近改过的文件、已经试过的方案、当前分支状态，模型就可能继续正确定位。

如果上下文里只有这句话，它很可能重复犯错，甚至回到已经失败过的路径。

这就是 Context Engineering（上下文工程）。

它关心的不是提示词本身，而是模型每次推理时“看见了什么”。

一个 Agent 的上下文通常包括：

• • 用户目标
• • 当前任务状态
• • 可用工具
• • 系统规则
• • 最近工具结果
• • 历史失败记录
• • 检索内容
• • 长期记忆
• • 状态摘要
• • 文件和 artifact 变化

但 Context Engineering 不等于“把所有东西都塞进去”。

上下文太多，模型会被噪声干扰；上下文太少，模型会忘记关键状态。

更好的做法是：每一轮只给模型当前决策所需的最小充分状态。

这也是 Reflexion^[1]、Generative Agents、Remember, Don't Re-read 等工作的共同方向：

• • Reflexion：把失败经验写成语言反思，放进后续循环。
• • Generative Agents：通过记忆、反思、计划维持长期行为。
• • Remember, Don't Re-read：用持久状态保存关键历史，减少每轮重新读取完整上下文。

Prompt 决定模型怎么答，Context 决定模型根据什么来答。

04 Harness Engineering：让模型安全行动

Context 解决“模型看什么”。

Harness 解决“模型能做什么、怎么安全做”。

Agent 和 Chatbot 最大的区别是：Agent 不只输出文字，它会行动。

它可能：

• • 读文件
• • 改代码
• • 跑测试
• • 调 API
• • 查数据库
• • 搜网页
• • 创建任务
• • 提交 PR

模型从“回答器”变成“行动者”后，风险就变大了。

回答错一句话，通常只是答案不准；执行错一个命令，可能删文件、污染数据、浪费成本，甚至带来安全问题。

所以需要 Harness Engineering。

Harness 可以理解为 Agent 外部的运行底座。它把模型的动作放进一个有边界、能验证、可恢复的环境里。

一个典型 Harness 包括：

• • 工具接口：Agent 能调用什么。
• • 执行环境：命令在哪里跑。
• • Sandbox：危险操作如何隔离。
• • 权限策略：哪些动作需要确认。
• • Session Log：过程如何记录。
• • 验证器：测试、检查、评分。
• • 恢复机制：失败后怎么回滚。
• • Human-in-the-loop：什么时候交给人。

OpenAI 的 Harness Engineering^[2]、Anthropic 的 Building Effective Agents^[3]、Managed Agents^[4]、Effective Harnesses for Long-running Agents^[5]，其实都在回答同一个问题：

模型不能直接裸奔执行任务。它需要工具、边界、验证和恢复机制。

这里要区分 Harness 和 Loop：

• • Harness 是运行底座：提供工具、环境、权限、验证。
• • Loop 是控制过程：决定每一轮如何继续、停止、修正。

没有 Harness，Loop 会放大风险。

没有 Loop，Harness 只是工具箱。

05 Loop Engineering：让 Agent 在反馈中持续完成任务

把 Prompt、Context 和 Harness 放在一起看，Loop Engineering 的位置就清楚多了。

Prompt 让模型答好，Context 让模型看对，Harness 让模型安全行动。

Loop 负责把这些能力串起来，让 Agent 在反馈中继续推进任务。

一个工程化 Agent Loop 通常包含 7 个环节：

   
   
   1. 读取状态
2. 制定计划
3. 调用工具
4. 观察结果
5. 评估反馈
6. 更新记忆
7. 继续、停止或升级处理

ReAct^[6] 是这条路线的经典起点：模型在“思考-行动-观察”之间反复切换，不再停留在一次性回答。

OpenAI Agents SDK^[7] 把 Agent Loop 做成 SDK 能力：工具调用、结果回传、继续运行、handoff、guardrail、tracing 都成为开发者可配置的系统能力。

LangGraph^[8] 则把 Agent Loop 进一步显式化为状态图，让长期任务可以持久化、恢复、观测。

Loop Engineering 并不只是“让 Agent 多跑几轮”。

它真正要管的是：

• • 循环有没有目标？
• • 每轮有没有反馈？
• • 失败有没有恢复？
• • 成本有没有预算？
• • 是否会无限重复？
• • 结果是否可验证？
• • 成功路径是否可复用？

好的 Agent Loop，会继续，也会停；会重试，也会换路。

06 自反馈循环：让 Agent 会修正自己

最基础的 Agent Loop 是：

   
   
   观察 -> 行动 -> 再观察

但真正能干活的 Agent，还要能处理失败：

   
   
   行动 -> 失败 -> 反思 -> 修正 -> 再试

这就是自反馈循环。

典型代表有三类：

Self-Refine：生成、批评、修改

Self-Refine 的思路很直观：

   
   
   生成初稿
  -> 给出反馈
  -> 修改结果
  -> 重复迭代

它说明：即使不训练新模型，也可以靠推理时的反馈循环，把结果一步步改好，相关思路可以看 Self-Refine^[9]。

Reflexion：把失败写成记忆

Reflexion^[1] 不更新模型参数，而是让 Agent 把失败经验写成语言反思，放进后续尝试。

Reflexion 真正想解决的，是让下一次尝试别再按上一次的方式错。

RefineRL：用执行结果训练更好的自修正

在代码任务里，反馈尤其明确：测试通过或失败，报错在哪里，都能直接告诉模型。

RefineRL 这类工作把代码执行反馈和强化学习结合，让模型学会更有效地修正自己。

不过，自反馈也有风险。

如果反馈本身不可靠，Agent 会越改越偏；如果没有停止条件，Agent 会陷入无限修正。

因此，自反馈循环必须配验证器、预算和终止规则。

自我修正不是一直反思，而是把反馈放进一个可验证的改进闭环。

07 状态循环：长任务不能每轮都从零开始

短任务可以靠上下文硬撑。

长任务必须靠状态。

一个长任务 Agent 会产生大量中间信息：

• • 已经读过哪些文件
• • 尝试过哪些方案
• • 哪些命令失败过
• • 哪些测试通过了
• • 用户后来补充了什么要求
• • 当前任务推进到哪一步
• • 是否需要恢复到某个 checkpoint

如果这些都塞进上下文窗口，问题会越来越严重：

• • token 成本变高
• • 历史噪声变多
• • 模型容易忘记重点
• • 失败路径反复出现
• • 状态难以恢复

长任务 Agent 因此需要显式状态。

这也是 Effective Harnesses for Long-running Agents^[5]、Remember, Don't Re-read、Voyager、Generative Agents 等资料共同指向的方向：

• • 用 state 保存当前任务进度。
• • 用 memory 保存长期经验。
• • 用 session log 保存完整轨迹。
• • 用 checkpoint 支持失败恢复。
• • 用 skill library 沉淀可复用能力。

好的 Loop Engineering，会让 Agent 记住该记住的东西，而不是每一轮从头读世界。

08 图执行：把黑盒循环变成可控流程

早期 Agent 常见写法很简单：

   
   
   while not done:
    ask model what to do
    run tool
    append result to context

这个方式做 Demo 没问题。

但一放到生产任务里，问题很快会冒出来：

• • 依赖关系藏在上下文里。
• • 失败恢复没有边界。
• • 每次运行历史都不同。
• • 很难复现。
• • 很难审计。
• • 很难知道哪一步该重跑。

于是 Agent Loop 开始往 Graph / Workflow / Lineage 方向走。

可以简单理解：

• • Loop：模型动态决定下一步。
• • Graph：把节点、边、状态显式画出来。
• • Workflow：把稳定流程固化下来。
• • Lineage：记录产物之间的依赖关系。
• • Replay Skill：把成功轨迹变成可重复执行的技能。

LangGraph^[8] 是这个趋势的代表之一。它把长期 Agent 任务建成可持久化、可恢复、可观测的状态图。

From Agent Loops to Structured Graphs^[10]、From Agent Loops to Deterministic Graphs 这类工作也在说明同一件事：生产级 Agent 不能一直靠隐式循环，很多控制流都要摆到明面上。

LOOP Skill Engine 则给出一个很有意思的方向：第一次执行由 LLM 完成并记录轨迹，后续重复任务通过 deterministic replay 执行。

Loop Engineering 走到后面，很可能会把跑通的循环沉淀成更可靠的图、工作流和技能。

09 观测与评测：看最终答案不够，要看循环轨迹

过去评测大模型，很多时候看最终答案就够了。

但 Agent 的失败，经常藏在过程里。

它可能最后完成了任务，但中间调用过危险工具。

它也可能最后失败了，但原因不一定是模型能力不够，反而可能是工具返回格式不清、状态丢失、恢复策略不对，或者循环一直在重复同一条失败路径。

所以 Loop Engineering 要重视 Trace。

要看：

• • 每一轮模型看到了什么上下文？
• • 它为什么选择这个工具？
• • 工具返回了什么？
• • 状态如何变化？
• • 是否重复尝试同一路线？
• • 是否超过预算？
• • 是否触发人工确认？
• • 失败发生在模型、工具、状态还是 Harness？

Evaluating Deep Agents 强调，长时 Agent 评测不能只看 final answer，还要看 trajectory，也就是执行轨迹。

Unsupervised Cycle Detection 关注的是另一个常见问题：Agent 在隐藏循环里原地打转，持续消耗资源却不报错。

Agentic Harness Engineering^[11] 则更进一步：用观测数据发现 Harness 和 Loop 的问题，再反过来改进系统。

Loop 是 Agent 的运行方式，Trace 是 Loop 的调试界面。

10 多 Agent Loop：关键在协作

很多人一听多 Agent，就想到“几个模型互相聊天”。

但真正的多 Agent 工程，难点是多个循环怎么协作。

一个多 Agent 系统至少要回答：

• • 每个 Agent 是什么角色？
• • 谁负责规划？
• • 谁负责执行？
• • 谁负责检查？
• • 共享状态在哪里？
• • 任务如何交接？
• • 冲突如何解决？
• • 什么时候终止？

AutoGen 代表了 multi-agent conversation loop。

OpenAI Agents SDK^[7] 的 handoffs 说明，Agent 之间需要明确交接协议。

Swarm Skills 和 S-Agents 进一步把问题推进到多 Agent 协调、角色分工、自组织协作。

可以这样理解：

单 Agent 主要是执行循环，多 Agent 还要处理协调循环。

11 实践清单：如何设计一个可控 Agent Loop？

如果你要设计自己的 Agent Loop，可以先问 10 个问题。

再压缩一点，可以记住 6 个关键词：

   
   
   状态
工具
反馈
验证
停止
复用

成熟的 Agent 不能只会“继续执行”。

它还应该会：

• • 停止
• • 回滚
• • 换策略
• • 请求人类
• • 压缩历史
• • 固化成功路径

12 最后：给自主性加上控制

Loop Engineering 为什么重要？

因为 Agent 的能力，已经不只来自模型本身。

它还来自模型如何读取状态、采取行动、接收反馈、修正自己，以及如何在这个过程中不失控。

四层工程可以这样理解：

接下来，Agent 工程会越来越关注这些东西：

• • 隐式 loop -> 显式 graph
• • 短上下文 -> 持久状态
• • 人工调试 -> 轨迹观测
• • 即兴执行 -> hardened workflow
• • 成功循环 -> replay skill
• • 单 Agent -> 多 Agent 协调

所以，Loop Engineering 的价值，在于给 Agent 的自主性加上边界、状态、反馈、恢复和评测。

未来 Agent 工程的重点，是让循环可观测、可验证、可复现、可复用。

引用链接

[1] Reflexion: https://arxiv.org/abs/2303.11366
[2] Harness Engineering: https://openai.com/index/harness-engineering/
[3] Building Effective Agents: https://www.anthropic.com/engineering/building-effective-agents
[4] Managed Agents: https://www.anthropic.com/engineering/managed-agents
[5] Effective Harnesses for Long-running Agents: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
[6] ReAct: https://arxiv.org/abs/2210.03629
[7] OpenAI Agents SDK: https://openai.github.io/openai-agents-python/
[8] LangGraph: https://docs.langchain.com/oss/python/langgraph/overview
[9] Self-Refine: https://arxiv.org/abs/2303.17651
[10] From Agent Loops to Structured Graphs: https://arxiv.org/abs/2604.11378
[11] Agentic Harness Engineering: https://arxiv.org/abs/2604.25850