Loop Engineering 深度解析
从定义、设计决策到与 Harness/Context/Hermes Engineering 的全面对比，深入理解 2026 年最火的 AI Agent 工程范式
Loop Engineering（循环工程）：定义与核心思想
Loop Engineering 是 2026 年 6 月第一周爆火的概念，核心推手包括：
- Peter Steinberger（PSPDFKit 创始人，后加入 OpenAI）：“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”
- Boris Cherny（Anthropic Claude Code 负责人）：“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”
- Addy Osmani（Google 工程师）在 Substack 发表长文《Loop Engineering》，系统性阐述了这套方法论，是目前最权威的参考。
- Cobus Greyling 建了 GitHub 参考仓库
cobusgreyling/loop-engineering，含 6 种生产级 pattern、跨工具矩阵、CLI 审计工具。
定义
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
一个 loop 是一个递归目标：你定义一次目的，Agent 反复迭代（通常带子代理、验证、外部状态），直到目标完成。
核心架构：五大构件 + 记忆
| 构件 | 职责 |
|---|---|
| Automations / Scheduling | 按节奏自动发现和分诊工作（/loop、cron、hooks） |
| Worktrees | 并行 Agent 不踩脚（git worktree 隔离） |
| Skills | 项目知识的持久化表达（SKILL.md 格式），让 Agent 不用每次从零推导 |
| Plugins & Connectors | 通过 MCP 把 Agent 接入真实工具链（GitHub、Linear、Slack…） |
| Sub-agents | 制造者 / 检查者分离——写的和检查的不是同一个 Agent |
| + Memory / State | 持久状态（markdown 文件、issue board），跨对话存活在磁盘上 |
流程
graph TD
A["Automation 触发 (cron / hook / /goal)"]
B["Triage Skill 发现工作 → 写入 STATE.md"]
C["为每个任务开启独立 Worktree"]
D["Sub-agent A (Implementer) 实现变更"]
E["Sub-agent B (Verifier) 检查变更"]
F["Connectors 开 PR、更新 ticket"]
G["下一轮 Automation 读取 STATE.md 继续未完成的工作"]
A --> B --> C --> D --> E --> F --> G设计哲学
- 杠杆点转移：从”写好一个 prompt”转移到”设计让 Agent 自运行的系统”
- 人类不消失：验证、理解、判断仍是人类的责任。Loop 放大好的判断力，也同等放大坏的
- Maker-Checker 分离：写代码的 Agent 不能自我评分，必须由另一个独立 Agent 验证
- 状态在磁盘不在上下文：模型跨 session 忘记一切，但 repo 不会
- 工具无关性：Addy Osmani 在原文里点破——Codex app 与 Claude Code 的六块积木能力形状几乎一样，Steinberger 的清单「几乎原样映射到 Codex app，再几乎原样映射到 Claude Code」。一旦看出形状相同，就不再争论用哪个工具，而是设计「换哪个工具都能跑」的 loop。
什么任务适合 Loop Engineering
核心判据：任务的验证标准是否可以被形式化描述，使得 Agent 自己能判断”做完了”或”做错了”。
适合的
| 类型 | 为什么适合 | 例子 |
|---|---|---|
| 有确定性验证的任务 | linter/type check/测试/编译 能给出二元判定 | 代码实现（有测试套件）、配置迁移（有 schema 验证） |
| 有明确完成状态的管道 | 每一步都有可观察的输出 | PR → Review → Merge → Deploy，每步都有 API 状态 |
| 重复性批量工作 | 同构任务，模式可复用 | 批量重构、全仓库 API 迁移、批量文档生成 |
| 监控响应型 | “条件满足时触发动作”天然就是循环 | cron 巡检、日志异常检测并修复、issue triage |
不适合的
| 类型 | 为什么不适合 |
|---|---|
| 开放式创意任务 | 没有客观的”完成”标准——设计好不好、文案优不优，Agent 自己判断不了 |
| 需要领域判断的决策 | “这个架构选型对不对”需要人类经验，Agent 无法自验证 |
| 一次性简单查询 | 一问一答，没有循环的必要，强行 loop 反而引入复杂度 |
| 高后果 irreversible 操作 | 删除数据库、合并到 main、发送生产通知——这些必须人类确认 |
灰色地带
最有趣的是灰色地带：可以设计 loop，但需要人类介入作为验证节点。 比如：
- 代码实现 → 自动跑测试 → 测试通过 → 人工 code review → 合并
- 文案生成 → 人工审阅 → 反馈修改 → 人工确认 → 发布
这仍然算 Loop Engineering，只是 loop 的终止条件里有”人类审批”这个 gate。
如何设计一个 Loop
不是玄学，本质是一个控制流设计问题。分五个设计决策：
决策 1：触发方式
# 三种触发模式
cron/hook → 定时或事件驱动
/goal 命令 → 人类给一个目标，系统自己跑到底
文件/状态变化 → watchdog 检测到变化后启动选择依据：任务是被动的（等人触发）还是主动的（自己发现工作）？
决策 2：状态持久化
这是 Loop Engineering 的核心区别。普通 Agent 调用是无状态的（prompt → response，结束）。Loop 需要状态跨轮存活：
<!-- STATE.md — 最简单的持久化方式 -->
# Current Goal
Migrate all API endpoints from v2 to v3
## Progress
- [x] GET /users
- [x] POST /users
- [ ] PUT /users/:id
- [ ] DELETE /users/:id
## Blockers
- PUT /users/:id 返回 500，需要先修复 auth middleware
## Next Step
Fix auth middleware, then retry PUT /users/:id没有这个，就不是 Loop，只是多次独立调用。 关键特征是：Agent 崩溃或对话结束后，新 session 能从 STATE.md 恢复进度。
决策 3：验证策略
# 三种验证模式，从弱到强
1. 自验证（最弱）
Agent 自己判断"我完成了吗" → 容易自我欺骗
2. 工具验证（中等）
跑测试/linter/编译 → 客观但只能验证语法/正确性
3. 独立 Agent 验证（最强）
Sub-agent B 审查 Sub-agent A 的产出 → Maker-Checker 分离Addy Osmani 的核心主张：写代码的 Agent 不能自我验证。 这是 Loop Engineering 最被低估的设计原则。
决策 4：终止条件
# 一个合理的终止条件设计
while not done:
result = agent.step()
if result.all_tests_pass and result.no_lint_errors:
done = True # ✅ 成功完成
elif result.iterations >= MAX_ITERATIONS:
done = True # ⚠️ 超时，需要人类介入
elif result.same_error_repeated(3):
done = True # 🔄 卡住了，需要人类介入
# 否则：agent 利用上一步的错误信息继续迭代决策 5：错误恢复
# 三级恢复策略
Level 1: 重试同一策略（工具调用超时 → 直接重试）
Level 2: 换策略（同一方法失败 3 次 → 换一个工具/方法）
Level 3: 降级求援（所有方法失败 → 记录到 STATE.md，通知人类）核心边界：有反馈 = Loop Engineering 吗？
不是。 关键区分：
只是”带反馈的 Agent” ≠ Loop Engineering
# 这只是带反馈的单次 Agent 调用
while not llm_says_done:
response = llm.chat(messages)
messages.append(response)
if tool_call:
result = execute_tool(tool_call)
messages.append(result)这是 ReAct loop——标准的 Agent 执行循环，几乎所有 Agent 框架都有。这不叫 Loop Engineering。
Loop Engineering 需要的额外特征
| 特征 | 带 feedback 的 Agent | Loop Engineering |
|---|---|---|
| 人退出循环 | 人还在写 prompt、看结果、决定下一步 | 人定义目标后离开，系统自己运行 |
| 状态持久化 | 状态在对话上下文里，对话结束就没了 | 状态在磁盘（文件/DB），跨 session 存活 |
| 工作发现 | 人告诉 Agent 做什么 | Agent 自己发现和分诊工作 |
| 多 Agent 协作 | 单个 Agent | Implementer / Verifier / Trier 分离 |
| 递归目标 | 每次一个指令 | 一个大目标拆成子目标，循环直到全部完成 |
一条判断线
如果关闭对话窗口后，系统还能继续推进同一个目标，这就是 Loop Engineering。如果不能，它只是带反馈的 Agent 调用。
与 Harness Engineering、Context Engineering、Hermes 的对比
Harness Engineering（驾驭工程）
出处：
- Mitchell Hashimoto（HashiCorp 联合创始人）在《My AI Adoption Journey》中把 “Engineer the Harness” 列为关键一步，是早期重要推动者（注意：不是唯一首创者）
- OpenAI 2026-02-11 发布官方文章《Harness Engineering: Leveraging Codex in an Agent-First World》（Ryan Lopopolo），是迄今最完整的实践总结
- Addy Osmani（agent-harness-engineering）与 Martin Fowler（harness-engineering-memo）也各自撰文——所以更准确的说法是 “多人共构的概念、2025 年底成型”，而非一人首创
- LangChain 团队：仅通过优化 harness（不改模型）在 Terminal Bench 2.0 上从 52.8% 提升到 66.5%
OpenAI 那篇文章给出了迄今最硬的落地数据：3 个工程师、5 个月、约 1500 个 PR、百万行代码、平均 3.5 PR/人/天，且人类没亲手写一行代码。其可复制的核心机制是——AGENTS.md 当 “目录而非百科全书”（约 100 行，只做指针）、docs/ 目录当 system of record、定期派 “doc-gardening agent” 扫描陈旧文档开修复 PR、把技术债当 “垃圾回收” 持续小额偿还而非攒到大重构。
定义：
不优化模型本身，而是优化模型运行的环境。 核心哲学：人类掌舵，智能体执行（Human Steer, Agent Execute）。
“Harness”（马具）——缰绳、马鞍、嚼子——不是马本身，而是控制马怎么跑的那套装备。
| 层面 | 说明 |
|---|---|
| Architectural Constraints | 模块边界、数据结构、架构决策记录（ADR） |
| Feedback Loops | 闭环：追踪失败 → 聚类错误 → 反馈到 harness → 修复永久化 |
| Verification & Guardrails | 确定性工具（linter、type checker）+ AI 驱动的验证混合 |
| Lifecycle Management | 仓库脚手架、CI/CD、文档、可观测性 |
| Entropy Control | 定期”垃圾回收”——重构 Agent 清理 cruft |
Context Engineering（上下文工程）
出处：
- Andrej Karpathy（OpenAI 联合创始人）在 2025 年中造了这个术语，Shopify CEO Tobi Lütke 也公开力推
- Gartner 于 2025-07-28 正式宣布 “Context engineering is in, and prompt engineering is out”
定义：
设计系统，动态地将正确的信息、工具和机构知识组装进 Agent 的工作记忆。
四大支柱：
| 支柱 | 说明 |
|---|---|
| Write | 编写高质量的 system prompt、skill 文档、工具描述 |
| Select | 从海量信息中检索相关内容（RAG、文件选择） |
| Compress | 历史压缩、摘要、token 预算管理 |
| Isolate | 上下文隔离——不同任务不互相污染 |
Hermes Engineering（Hermes Agent）
出处：
- Nous Research（Hermes 系列开源模型团队）于 2026 年 2 月 25 日开源发布 Hermes Agent v0.1.0
- 2 个月内 GitHub 星标破 5 万
- Arize 评价为 “one of the most complete open-source agent harnesses available today”
Hermes 是一个具体的开源 Agent 框架，不是抽象方法论。它实现了 Harness Engineering 的理念，并加入了独特的自进化机制。
| 特性 | 说明 |
|---|---|
| Learning Loop（自学习闭环） | 完成复杂任务（5+ 工具调用）后自动复盘，提炼经验生成/优化 Skill 文档，无需人工干预 |
| 双层记忆 | 热记忆（SQLite FTS5）+ 冷记忆（Markdown：MEMORY.md / USER.md），跨会话持久 |
| Provider 抽象 | 统一驱动 OpenAI、Anthropic、Codex、Bedrock 等多种后端，工具调用格式归一化 |
| Session as Infrastructure | 会话被当作基础设施对待，不是一次性对话 |
| Context Compression（血统压缩） | 旧轮次用辅助模型摘要，保留血统（lineage）而非重写历史，head/tail 段受 token 预算保护 |
| Curator（技能策展人） | 后台自动维护技能库：stale → archived，LLM 审查合并重复技能 |
| 轻量部署 | 内存 ~400MB，$5/月 VPS 可跑，支持 Docker |
官网（hermes-agent.nousresearch.com）把这些能力对外包装成六项，正好和上表对应：Connect（Telegram / Discord / Slack 等）/ Remember（持久记忆 + 自动生成 skill）/ Schedule（自然语言定时任务）/ Delegate（独立 subagent，自带终端与 Python RPC）/ Search（联网与浏览器自动化）/ Experiment（五种沙箱后端：local / Docker / SSH / Singularity / Modal）。其中 Remember 那句 “learns your projects, auto-generates skills, and never forgets how it solved a problem” 正是上表 Learning Loop 的产品印证。
四者分层关系
Addy Osmani 原话：“I wrote before about the cousin of this, agent harness engineering, which is making the environment one single agent runs inside. Loop engineering sits one floor above the harness.”
graph TD
subgraph Layered["四层工程分层关系"]
L["Loop Engineering（你不在时系统自运行）<br/>调度、编排、多 Agent 协作"]
H["Harness Engineering（Agent 的运行环境）<br/>工具、权限、反馈回路、约束"]
C["Context Engineering（每轮给 LLM 看什么）<br/>信息组装、检索、压缩"]
P["Prompt Engineering（单次调用的措辞）<br/>最底层，最基础"]
end
L --> H --> C --> P四者对比总表
| Loop Engineering | Harness Engineering | Context Engineering | Hermes Engineering | |
|---|---|---|---|---|
| 是什么 | 方法论 / 设计范式 | 方法论 / 工程学科 | 方法论 / 技能 | 具体的开源框架/产品 |
| 层级 | 最高层——编排调度 | 中间层——运行环境 | 最底层——信息管理 | 实现层——具体产品 |
| 核心问题 | “Agent 怎么自运行？” | “Agent 在什么约束下运行？” | “Agent 每轮看什么？” | “一个自进化的 Agent 长什么样？” |
| 关注点 | 调度、多 Agent 协作、终止条件、记忆持久化 | 工具边界、权限、反馈回路、熵控制、可观测性 | prompt 组装、RAG 检索、历史压缩、token 预算 | 自学习闭环、双层记忆、provider 抽象、技能策展 |
| 代表人物/团队 | Steinberger, Cherny, Osmani | Mitchell Hashimoto, OpenAI (Lopopolo) | Andrej Karpathy | Nous Research |
| 时间线 | 2026 年 6 月爆火 | 2025 年底提出，2026 年成型 | 2025 年中提出 | 2026 年 2 月开源 |
| 类比 | 设计工厂的流水线 | 造工厂的车间和安全围栏 | 准备工人的工作台资料 | 雇了一个会自我学习成长的工人 |
| 关系 | 驾驭 Harness | 包含 Context Engineering | 被 Harness 和 Loop 使用 | 实现了 Harness + 自带 Learning Loop |
一句话总结
Context Engineering 管信息，Harness Engineering 管环境，Loop Engineering 管编排。Hermes 是一个同时实现了这三层（尤其是 Harness + 自进化 Loop）的具体 Agent 框架。
主要参考：Addy Osmani《Loop Engineering》(Substack)、OpenAI《Harness Engineering: Leveraging Codex in an Agent-First World》(Ryan Lopopolo, 2026-02-11)、Cobus Greyling loop-engineering (GitHub)、agent-engineering.dev《Harness Engineering in 2026》、Nous Research Hermes Agent Docs、Arize《How Hermes implements an open source agent harness architecture》