吴恩达的 Loop Engineering 三层循环,我在 AI Agent 上落地了
从一篇公众号文章引发的思考,到两个闭环的工程实践
缘起
前两天看到一篇文章,讲吴恩达(Andrew Ng)对 Loop Engineering 的理解——当 AI 能够自主写代码之后,软件开发开始变成三种不同时间尺度的 Loop 同时运转:
- L1 - Agentic Coding Loop:AI Agent 自主写代码 → 跑测试 → 发现 Bug → 修改,形成分钟级闭环
- L2 - Developer Feedback Loop:开发者负责方向决策,把模糊 Vision 翻译成 Spec
- L3 - External Feedback Loop:真实用户反馈修正产品判断,最慢但最重要
读完后我问了自己一个问题:
Loop Engineering 在 Hermes Agent(我日常使用的 AI 编码助手)上是否同样有意义?
答案是:非常有意义,且 Hermes 的架构本身就是 Loop Engineering 的绝佳实践平台。
六种方案
沿着吴恩达三层循环的思路,我梳理了 Hermes Agent 中可以落地的 6 种 Loop Engineering 方案:
| 方案 | 对应层级 | 核心思想 |
|---|---|---|
| L1 - 工具调用自优化循环 | Agentic Coding Loop | 工具调用异常时自动尝试 3 种替代路径 |
| L2 - Skill 自我进化循环 ✅ | 混合 | Skill 使用中自动发现坑点并 patching |
| L3 - Cron 双层循环 | Developer Feedback Loop | 任务执行 + 质量审计双层闭环 |
| L4 - Subagent 反馈聚合循环 | Agentic Coding Loop | 多子智能体交叉验证 |
| L5 - 编码行为循环增强 ✅ | Agentic + Developer Loop | 自动化代码审查反馈到编码规则 |
| L6 - 全链路文章发布复盘 | External Feedback Loop | 数据驱动的内容策略优化 |
其中标 ✅ 的两个方案——方案二(Skill 自我进化) 和 方案五(编码行为循环增强)——性价比最高,我决定先从它们开始落地。
方案五:编码行为循环增强 🛡️
现状
Hermes 有一套 coding-conduct skill,定义了 4 条编码行为准则:
- Think Before Coding — 动手前先说话
- Simplicity First — 最少代码原则
- Surgical Changes — 只改必须改的
- Goal-Driven Execution — 目标驱动,结果验证
但这 4 条规则是静态的。不管项目遇到什么新坑,规则本身不会进化。
增强:加入事后审计层
核心思路是引入 自动化代码审查 作为反馈闭环:
编码 → 提交(git commit) → 自动化代码审查 → 高频问题 → 更新编码规则
↓
下次编码自动遵循
具体实现:
- 每轮编码任务完成后,调用
code_review_workspace()(基于open-code-review等工具)自动审查 - 审查结果中检测重复出现的违规模式
- 如果一个规则被违反 ≥3 次,自动沉淀到
coding-conduct的 Pitfalls Log - 下次编码时 Agent 加载 skill,直接受益
## Pitfalls Log
| 日期 | 来源 | 坑点 | 对应规则 |
|------|------|------|----------|
| - | - | — 持续积累,由实际编码和审查驱动 — | - |
这样,编码规则不再是抽象的教条,而是与项目实际痛点同步进化的活文档。
代码示例
# 任务完成后,调用自动化审查
code_review_workspace(repo_path="/path/to/repo", concurrency=4)
# 审查结果中的高频问题,手动评估后沉淀到 Pitfalls Log
skill_manage(
action='patch',
name='coding-conduct',
old_string='| (当前 Pitfalls Log 表头行) |',
new_string='| 2026-07-01 | Code Review | 某高频违规模式 | 规则 X |\n| (原表头) |'
)
方案二:Skill 自我进化循环 🔄
核心思想
Skill 不应是静态文档。 每次使用后,Agent 应自动检查是否有未覆盖的边缘情况,发现后自动 skill_manage(action='patch') 追加到 Pitfalls 区。
闭环流程
① 加载 Skill → 按步骤执行
② 执行中遇到坑/未覆盖的边缘情况
③ 评估:这是通用坑点还是本次特例?
├─ 通用 → ④
└─ 特例 → 跳过(不污染 Skill)
④ skill_manage(action='patch') 追加到 Pitfalls Log
⑤ 下次加载 → 直接受益
触发条件
以下情况必须触发自我进化检查:
- 使用 Skill 过程中遇到错误/异常
- 用户纠正了你的做法 — 最高优先级
- 发现 Skill 中未描述的特殊场景
- Skill 中的命令/路径/配置已过时
- 自动化审查中发现了重复违规模式 ≥3 次(与方案五联动)
判断标准
| 通用坑点(需沉淀) | 本次特例(跳过) |
|---|---|
| 跨项目/跨环境都会遇到 | 只此一次的特殊配置 |
| 命令本身的行为差异 | 手误打错字 |
| API/工具的版本迁移问题 | 网络临时波动 |
| 特定 OS/平台的兼容性 | 已修复不会再碰的 bug |
| 同一个坑被审查抓到 ≥3 次 | 一次性的边缘 case |
实现
我创建了一个独立的 skill-self-evolution skill,封装了这个机制的标准流程:
# 示例:使用 Skill 后自动 patching
skill_manage(
action='patch',
name='some-skill',
old_string='| 日期 | 来源 | 坑点 |',
new_string='| 日期 | 来源 | 坑点 |\n| 2026-07-01 | 用户纠正 | ... |'
)
两层循环如何协同工作
方案五和方案二不是孤立的,它们互相增强:
方案五(编码行为循环) 方案二(Skill 自我进化)
│ │
▼ ▼
Code Review 发现违规模式 ──────→ 沉淀到 coding-conduct 的 Pitfalls Log
│
▼
coding-conduct 自身进化
│
▼
Agent 下次编码自动遵循新规则
│
▼
更少的违规 → 更干净的审查结果
方案五提供外部反馈(自动化代码审查),方案二提供内部进化机制(Skill patching)。 两者结合,形成一个完整的「编码 → 审查 → 进化 → 编码更好」的增强循环。
最终效果
落地这两层循环之后,Hermes Agent 从「听话的工具」进化为**「会自我进化的编码伙伴」**:
| 维度 | 之前 | 之后 |
|---|---|---|
| 编码规则 | 4 条静态规则 | 规则 + Pitfalls Log 持续进化 |
| 代码审查 | 需要手动检查 | 自动化审查 + 反馈闭环 |
| Skill 维护 | 发现坑点需要人工通知 Agent | Agent 自动发现并 patching |
| 长期退化 | 规则越来越脱离实际 | 越用越准,与项目同步进化 |
总结
吴恩达说,三层 Loop 中,最慢的那一层往往最重要。
在 AI Agent 的工程实践中,让编码规则「自我进化」这件事本身就是一个 Loop——它不快,不能立刻看到效果,但它决定了 Agent 长期使用的质量天花板。
如果你的 AI 编码助手还在用固定的 prompt 模板、从未根据你的实际项目痛点和坑点进化过,不妨也试试这个思路:
- 加一层外部反馈 — 用自动化代码审查(如
open-code-review)发现重复违规 - 加一层自我进化 — 让 Skill/Prompt 在使用中自动积累 Pitfalls
- 两层形成闭环 — 反馈驱动进化,进化减少违规
这是我目前落地效果最好的两个 Loop Engineering 实践。后续还会继续落地其他方案,欢迎持续关注。
更多推荐

所有评论(0)