前言

当模型不再只是回答问题，而是自己规划工作、编写代码、调用工具、审查证据、跨会话恢复时，“怎么写 Prompt"已经不再是瓶颈。2026 年，AI 工程的焦点从"模型内部"转向了"模型周围”——而 Loop Engineering 与 Hermes Engineering（Harness Engineering），正是这一转向中最受瞩目的两条路径。

一、背景：从 Prompt Engineering 到"模型之外的工程"

要理解这两个技术为什么火，先得看清楚这条演进线：

年份	时代	你做什么	你的角色
2024	Prompt Engineering	写好一条提示词，得到一个好输出	操作员
2025	并行智能体	不再盯着一个对话，同时跑多个 Agent	管理者
2026	Loop / Harness Engineering	构建运行 Agent 的系统本身	系统设计师

Claude Code 的创造者 Boris Cherny 和 OpenClaw 的创造者 Peter Steinberger 都公开提到：他们有些早晨已经不再亲手写 Prompt 了——另一个模型在写，而他们在同时管理数百乃至数千个 Agent。Andrew Ng 也在 2026 年 6 月的 Batch 信件中专文讨论了"Loop Engineering"这一概念。

这背后的含义很直接：如果你不再是那个在每一步之间按回车的人，那就必须有"别的东西"来决定工作什么时候算"够好了"。 这"别的东西"，就是 Loop Engineering 和 Hermes Engineering 各自试图解决的核心问题，只是它们切入的角度截然不同。

---

二、Loop Engineering：设计 Agent 运行的"轨道"

2.1 核心理念

Loop Engineering 是一门设计 Agent 运行循环（Loop） 的工程学科——关注的是 Agent 在两次工具调用之间做什么、什么时候检查自己的工作、如何判断"完成了"——而不是手写每一条 Prompt。它是 2026 年 Prompt Engineering 的继任者。

用一句话概括：你不写 Prompt，你写系统。

一个 Loop 的本质是四个动作的循环：

发现（discover）→ 规划（plan）→ 执行（execute）→ 验证（verify）→ 重复，直到满足停止条件

过去，你就是那个 Loop——站在 Agent 的每一步之间，读输出、抓错误、决定下一步、让它重试。Loop Engineering 就是让你从内层循环中"走出来"和"走上去"，去设计 Agent 运行的轨道。

2.2 验证器才是瓶颈，不是生成器

这是 Loop Engineering 最核心的洞察，也是它区别于过去两年所有 AI 工程实践的根基。

每个 Loop 都有两半：

• 生成器（Generator）：产出工作成果，也就是模型本身——而模型现在已经非常强大。
• 验证器（Verifier）：判断这些成果是否"够好"。

在循环中，生成器可以近乎免费地反复运行。真正决定所有这些运转是否产生价值的，是验证器。一个验证器很弱的循环不会大声报错——它会自信地、数百次地生产垃圾。

Karpathy 从他的"生成-验证循环"中得出同样的结论：生成变便宜了，所以循环的速度只取决于验证那一半。Addy Osmani 也反复指向同一个转变：瓶颈从"写代码"转移到了"证明代码能跑"。在这个世界里，你的品味（taste）不再是软技能——它是奖励函数（reward function）。

2.3 开环 vs 闭环

接受"验证器是关键"之后，工程决策就变得清晰了。每个循环都处在两极之间：

维度	开环（Open Loop）	闭环（Closed Loop）
定义	给定目标和宽松条件，让 Agent 在广阔空间中探索	提前锁定成功标准，每步评估，定义明确停止点
优势	能产出真正新颖、令人惊喜的方案	预算可控、可预测、可放心放手
劣势	烧 Token，标准松了很快退化为"垃圾制造机"	不会给你惊喜，只做你指定的
生死取决于	验证器（比闭环更需要）	验证器

实际的工程决策只有两步：

1. 为这个具体任务选择开环还是闭环——你需要多少新颖性，愿意承担多少预算风险？
2. 写一个匹配的验证器——闭环需要硬性的、可检查的通过条件；开环需要更好的验证器，因为它是探索与垃圾之间唯一的屏障。

2.4 Andrew Ng 的三层循环模型

循环是可以嵌套的。Andrew Ng 在 2026 年 6 月提出了清晰的三层模型：

循环	节奏	谁在跑	决定什么
智能体编码循环	每几分钟	Agent	写代码、测试、迭代到无 bug 且满足规范
开发者反馈循环	几十分钟到几小时	你	审查产品、引导 Agent、更新规范
外部反馈循环	几小时到几周	真实世界	Alpha 测试、A/B 测试、生产数据反馈到规范

越往外，循环越慢，验证器越"人"。内层循环可以用测试自我验证，外层循环必须靠你。Ng 的关键观点是：人的贡献不是"品味"（听起来天生且不可教），而是 “上下文优势（context advantage）”——只要人知道某些 AI 不知道的东西，就需要人在循环中注入这些知识。这恰好告诉你该把什么编码进验证器。

2.5 LoopEngineer：Agent 循环的控制平面

LoopEngineer（GitHub: MC-and-his-Agents/LoopEngineer）是上述理念的一个具体开源实现——一个 Agent 循环控制平面（control plane）。它不是 Prompt 库，不是工作流清单，而是一个让 Agent 循环在复杂场景下保持可靠的工程层。

它提供六大控制平面能力：

能力	解决的问题
Context（上下文控制）	长任务中上下文膨胀导致溢出；大消息发送前先做预算检查
Routing（循环路由）	不是每个任务都需要调度器，按风险路由到最轻量的足够配置
Orchestration（编排）	多角色协作：Router / Worker / Scheduler / Watcher / Audit
Evidence（证据消费）	"Agent 说做完了"不等于完成，必须有被消费的证据才能转状态
Audit（审计与恢复）	在 Agent 从无效状态继续之前检测循环漂移
Cost（协调成本）	过度编排也是一种失败，目标是"最小可靠循环"

它定义了显式角色和路由配置：

路由配置（从轻到重）：
direct → worker_lite → scheduler_lite → scheduler_full → watcher_full → incident_recovery

角色分工：
Router   选择执行配置
Worker   执行有界范围，写报告
Scheduler 协调 Worker，消费报告，掌管门禁
Watcher  管理 Scheduler 池、共享通道和生命周期
Audit    检查循环是否仍可安全继续

三条铁律：

没有上下文检查通过，不发大消息。
没有被消费的报告，不转状态。
没有证据，不算完成。

核心原则包括：构建循环而非仅写 Prompt；让简单工作保持简单；不要把聊天历史当数据库；让完成可验证；用定位符而非载荷；从事实恢复而非从臃肿对话历史恢复。

---

三、Hermes Engineering：构建会成长的 Agent 本体

3.1 核心理念——Harness Engineering

Hermes Engineering 背后的工程哲学叫 Harness Engineering（驾驭工程学/赋能工程学）。其核心思想是：

将大型语言模型（LLM）视为一种新型的、可编程的计算资源，通过构建系统化的框架、工具和流程，来"驾驭"或"赋能"这些模型，使其能够稳定、可靠、持续地完成复杂任务，并融入现有的软件工程体系。

这与 Prompt Engineering 形成对比：Prompt Engineering 侧重于单次交互的优化，而 Harness Engineering 强调构建一个可持续运作的智能体系统——具备状态管理、工具调用、记忆存储、技能传承和自主进化能力。

Hermes 由 Nous Research 开发，是一个开源的、本地优先（local-first）、模型无关（model-agnostic）的 Agent 框架。它不仅仅是一个让 LLM 调用工具的封装器，更是一个具备持久记忆和自我进化能力的智能体。

3.2 两大核心能力

持久记忆（Persistent Memory）

Hermes 能将交互历史、学到的知识、项目上下文以结构化方式保存到本地数据库（向量数据库如 ChromaDB，或 SQLite/PostgreSQL）。下次交互时主动"回忆"相关背景，实现跨会话的连续协作。这解决了 LLM 的"金鱼记忆"问题。

技能自进化（Skill Self-Evolution）

这是 Hermes 最强大的能力。Agent 可以通过与你的交互，自动将成功的操作流程、解决问题的模式，抽象、总结并固化为可复用的 技能（Skill）。这些技能被存储起来，未来遇到类似问题时自动调用或组合，甚至创造新技能，实现能力的迭代增长。

简单来说：你是在培养一个专属的、会成长的 AI 助手，而不是每次从头教一个"新手"。

3.3 三层架构

Hermes 的结构完整性依赖于严格的分层架构，将接口、智能和执行分离：

层级	名称	职责
第一层	Surfaces（表面层）	交互入口：CLI、TUI、Telegram、Slack 等消息网关
第二层	Agent Core（智能体核心）	"大脑"功能：循环、记忆检索、技能激活
第三层	Execution Backend（执行后端）	实际运行代码的沙箱：本地 Shell、Docker 容器、Modal/Daytona 等无服务器基础设施

3.4 Agent 循环：run_conversation()

Hermes 的核心是 run_conversation() 函数——不是一个简单的请求-响应触发器，而是一个有状态的循环，管理"思考→行动→观察"的复杂过程。

• IterationBudget：线程安全的迭代预算，追踪工具调用和推理步骤，防止成本失控或无限递归。
• 退款机制：execute_code 工具在成功完成后退还迭代次数，奖励效率。
• 预算宽限：预算即将耗尽时，注入警告并允许最后一次 _budget_grace_call 来总结进度。
• Context_compressor：压缩对话中间轮次而非截断，确保 Agent 保留功能性理解而不溢出上下文窗口。

3.5 闭环学习循环（Closed Learning Loop）

Hermes 的"杀手锏"是它能架构自己的能力——即程序性记忆（Procedural Memory）：

1. 尝试与记录（Attempt & Log）
   在真实工作区执行初始操作，检测编译错误或权限阻塞

2. 纠正与精炼（Correct & Refine）
   分析错误回溯，编写补丁，顺序重测，直到执行验证通过

3. 标准化（Standardize）
   将成功流程保存为自定义技能（Skill），成为未来任务的可复用蓝图

当 Agent 完成一个非平凡任务（通常涉及 5 次以上成功工具调用）后，触发反思阶段。通过 skill_manage 工具，将成功执行序列蒸馏为可复用的、基于 Markdown 的技能文件（带 YAML 前置元数据）。

程序性记忆从根本上优于巧妙的 Prompt；一个能编写自己运行手册的 Agent，是一个每天都在增值的 Agent。

3.6 三层记忆系统

层级	名称	特征
Layer 1	工作记忆（Working Memory）	临时会话上下文
Layer 2	情景记忆（Episodic Memory）	跨会话回忆，基于 SQLite 的 FTS5 全文搜索索引
Layer 3	程序性记忆（Procedural Memory）	自动创建的技能，存储为可移植的 Markdown 文件

为控制 Token 用量，Hermes 采用**渐进式披露（Progressive Disclosure）**策略：

• Level 0：技能名称和简短描述（~20 tokens），加载进每个系统提示
• Level 1：完整 SKILL.md 内容，仅在 Agent 决定激活技能时加载
• Level 2：引用的文件和脚本，仅在技能体明确请求时加载
• Level 3：完整执行步骤和工具调用序列（~1000+ tokens）

此外，Hermes 对核心身份和事实使用**冻结快照（frozen-snapshot）**模式：每次会话开始时读取 USER.md（偏好）、MEMORY.md（长期事实）和 SOUL.md（不可变核心身份），且仅读一次以保持前缀缓存稳定性。这是长期部署中大幅节省成本的关键技巧。

3.7 安全与本地优先

Hermes 采用"分层防御"策略：

• Tirith：基于 Rust 的外部扫描器，检测终端注入攻击和危险模式
• Smart Approval：LLM 评估命令潜在影响的风险评级系统，低风险自动批准，高风险需人工授权

Hermes 是模型无关的，优化了通过 Ollama 的本地优先执行（支持 Llama、Mistral、Qwen-2.5 等开源模型），确保数据永不离开本地网络。它甚至可以在 $50 的树莓派 4（8GB RAM）上运行数月不崩溃。

---

四、核心对比：Loop Engineering vs Hermes Engineering

4.1 设计哲学对比

维度	Loop Engineering	Hermes Engineering
一句话定位	设计 Agent 运行的循环轨道	构建会成长、会记忆的 Agent 本体
工程哲学	把"循环"本身当作工程对象	把 LLM 当作可编程计算资源来"驾驭"
核心问题	“怎么让循环可靠、可恢复、成本可控”	“怎么让 Agent 记住一切、持续进化”
关注层次	控制流层——编排、验证、路由、审计	智能体层——记忆、技能、进化、持久化
瓶颈论	验证器是瓶颈，不是生成器	记忆与技能积累是复利来源
Prompt 的角色	模型自己写 Prompt，人写验证器	Agent 自己写技能，人提供反馈和环境
状态管理	用工件（artifact）和定位符，不把聊天历史当数据库	用三层记忆系统（工作/情景/程序性）+ 向量数据库
完成判定	证据驱动：“没有被消费的报告，不转状态”	技能驱动：“成功流程蒸馏为可复用技能”
多 Agent	核心能力——Router/Worker/Scheduler/Watcher 显式编排	通过生成子 Agent 实现，但不是设计重心
成本控制	一等公民——"协调成本"是显式设计关切	通过本地模型 + 渐进式披露 + 冻结快照降本
恢复策略	从事实（git/状态根/交接清单）恢复，非对话历史	从持久记忆和技能库恢复，跨会话连续
部署模式	循环可长可短，按需路由到不同重量级配置	本地优先、7×24 持续运行、模型无关
开源实现	LoopEngineer（控制平面插件，Python）	Hermes（Nous Research，模型无关框架）

4.2 它们解决的是不同层次的问题

打个比方：

• Loop Engineering 像是设计一条铁路系统——信号灯（验证器）、调度规则（路由）、应急方案（恢复）、成本核算（协调成本）。它关心的是"列车怎么跑才不出事"。
• Hermes Engineering 像是造一列会自我进化的列车——它记住每一条跑过的线路（情景记忆），把成功经验固化成驾驶手册（程序性记忆/技能），越跑越聪明，而且可以在你自己的铁轨上跑（本地优先）。

两者并非竞争关系，而是互补的：

• Loop Engineering 回答：“多个 Agent 协作时，循环怎么不崩？”
• Hermes Engineering 回答：“单个 Agent 怎么越用越强、永不遗忘？”

4.3 循环结构的对比

Loop Engineering 的循环（控制流视角）：

用户目标
  ↓
循环路由器（选择最轻量足够配置）
  ↓
协议配置（direct / worker_lite / scheduler_full / ...）
  ↓
上下文守卫（预算检查）
  ↓
Worker / Scheduler / Watcher 执行
  ↓
工件化报告（写入文件，线程只带定位符）
  ↓
报告消费
  ↓
门禁 / 审计 / 交接
  ↓
下一所有者 / 下一动作

Hermes 的循环（智能体视角）：

会话开始 → 读取冻结快照（USER.md / MEMORY.md / SOUL.md）
  ↓
思考 → 行动 → 观察（IterationBudget 约束）
  ↓
工具调用成功？ → 是 → 累计成功调用
  ↓
≥5 次成功？ → 是 → 反思阶段
  ↓
skill_manage 蒸馏为 Markdown 技能
  ↓
技能存入程序性记忆（Level 0-3 渐进披露）
  ↓
会话结束 → 新记忆/技能供下次会话使用

4.4 对"完成"的定义不同

这是两个范式最深刻的分歧：

	Loop Engineering	Hermes Engineering
"完成"意味着	验证器通过 + 证据被消费 + 门禁通过	任务执行成功 + 经验被固化为技能
失败的后果	循环漂移，进入恢复模式	技能未生成，但记忆仍保留
价值沉淀方式	工件文件 + 结构化状态面	技能库 + 三层记忆
复利效应来源	可恢复的循环 + 可审计的证据	越积越多的技能和记忆（“智能护城河”）

---

五、如何选择？

5.1 选 Loop Engineering（LoopEngineer）当你：

• 需要编排多个 Agent或多个线程协同工作
• 任务长时间运行，可能跨会话，需要恢复能力
• 关心上下文窗口溢出问题，需要系统化管理
• 需要可审计、可验证的完成判定（如代码审查、门禁、合并就绪）
• 想避免过度编排的成本——让简单任务保持简单
• 团队需要证据驱动的工作流，"说做完了"不算数

5.2 选 Hermes Engineering（Harness Engineering）当你：

• 想要一个7×24 持续运行、永不遗忘的专属 Agent
• 重视数据主权，希望完全本地化运行（Ollama + 开源模型）
• 需要 Agent自我进化——把成功经验固化为可复用技能
• 任务是个人效率助手、项目上下文专家、自动化工作流等长期陪伴型场景
• 愿意花 90 天培养一个"越来越聪明"的 Agent，享受复利效应
• 需要跨 Telegram/Slack 等多渠道与 Agent 交互

5.3 两者结合的想象空间

最令人兴奋的可能性是两者结合：

• 用 Hermes 构建底层 Agent 本体——具备持久记忆和技能进化的"大脑"
• 用 Loop Engineering 设计上层循环控制平面——多 Agent 编排、验证器、审计恢复

这样你同时拥有了一个"越来越聪明"的 Agent（Hermes）和一套"永不崩坏"的循环系统（Loop Engineering）。

---

六、总结

	Loop Engineering	Hermes Engineering
核心隐喻	设计铁轨系统	造会进化的列车
一句话	把循环当工程对象，验证器是瓶颈	把 LLM 当计算资源，记忆与技能是复利
解决	多 Agent 可靠编排与恢复	单 Agent 持久记忆与自我进化
代表性实现	LoopEngineer（控制平面）	Hermes（Nous Research）
关键人物	Boris Cherny、Karpathy、Andrew Ng、Addy Osmani	Nous Research
适用场景	长时多 Agent 工程、审查门禁、恢复	本地优先持续 Agent、个人助手、技能积累
关系	互补——控制流层	互补——智能体层

2026 年的 AI 工程正在从"Prompt"走向"系统"。Loop Engineering 让你设计 Agent 运行的轨道，Hermes Engineering 让你打造一个会成长的 Agent。两者一个向外看编排，一个向内看进化——合在一起，才是下一代 AI 工程的完整图景。

更少的 Prompt 膨胀，更多的循环控制。       ← Loop Engineering
更少的遗忘，更多的技能复利。               ← Hermes Engineering
更少的神秘状态，更多可恢复的工作。          ← 两者的共同目标