AI 写代码总是不稳定？Loop Engineering 可能是下一步解法

最近围绕 OpenClaw 作者引发的 “Loop Engineering” 讨论，表面上是在谈 AI Coding 的新玩法，实际上更像是在重新发现 Kubernetes 社区十几年前已经走过的一条路：用持续反馈的控制循环，让系统不断逼近期望状态。

如果把过去两年 AI 编程工具的发展串起来，可以看到一个清晰的迁移路径：从 Prompt Engineering，到 Context Engineering，再到 Loop Engineering。最初大家关心如何写好 prompt，后来发现真正影响 Agent 表现的是上下文、工具、记忆和环境。再往后，问题又变成了：即便上下文足够，Agent 仍然不稳定，怎么办？

答案不是让模型一次性“想对”，而是让它在观察、行动、验证、修正的循环里逐步收敛。

这正是 Kubernetes 的基本世界观。

从一次调用到持续循环

真实的软件开发从来不是一次推理。它通常是这样发生的：

1. 读代码。
2. 理解目标。
3. 修改实现。
4. 编译或运行测试。
5. 发现偏差。
6. 继续修正。
7. Review。
8. 再修复。
9. 直到达到可接受状态。

这不是 “prompt -> answer”，而是 “goal -> loop -> evaluation -> feedback”。Loop Engineering 的价值就在这里：它不再把 AI Coding 理解成自动生成代码，而是理解成自动逼近目标。

早期的一些实践已经很接近这个方向。比如用一个循环不断唤起 Claude Code，让它从仓库、计划文件和 Git 状态里重新读取现状，再推进一个小任务。这里有一个很关键的经验：Agent 会忘，仓库不会忘。对话历史是不可靠的，落盘状态才是下一轮循环可以依赖的事实。

Kubernetes 已经证明过这套模式

很多人把 Kubernetes 理解成容器编排平台，但它更深层的贡献，是把控制论带进了软件工程。

Kubernetes controller 做的事情可以概括成四步：

1
2
3
4
5

Desired State
  -> Observe
  -> Compare
  -> Act
  -> Repeat

也就是 Reconciliation Loop。Controller 反复检查实际状态是否等于期望状态。如果不一致，就继续调节。

比如你声明：

1

replicas: 3

你并不告诉 Kubernetes “启动第一个 Pod、再启动第二个 Pod、再启动第三个 Pod”。你只声明期望状态。至于当前有几个副本、哪些 Pod 死了、是否需要补齐，都是 controller 自己在循环中处理。

AI Coding 正在形成类似结构。你不再一步步命令 Agent 打开某个文件、修改某个函数、添加某个测试，而是声明一个目标：修复这个并发问题，并确保测试通过。Agent 负责观察仓库、修改代码、运行验证、读取反馈，再继续下一轮。

Prompt 正在变成 Spec。

Loop Engineering 的组件

一个可用的 Loop Engineering 系统，通常会包含几类东西：

• 自动触发：定时器、cron、webhook、GitHub Actions，让循环不依赖人工按钮。
• 隔离工作区：通过 Git worktree 等方式，让多个 Agent 并行工作而不互相踩踏。
• 项目知识：用 SKILL.md、AGENTS.md、规范文档和任务文件，把经验固化成可重复读取的上下文。
• 工具连接：通过 MCP、插件、CI/CD、Issue 系统和数据库，让 Agent 能观察真实环境。
• 子 Agent：把 maker、checker、reviewer 拆开，避免模型自己给自己打分。
• 外部状态：用 Markdown、Issue、Git 提交或任务板记录进度，让循环可以被杀死、重启和接续。

这些组件合在一起，很像 AI 时代的控制平面。模型只是执行器，真正决定系统能力的是循环如何组织、状态如何保存、反馈如何进入下一轮。

相似之外，差异更重要

Loop Engineering 和 Kubernetes controller 结构相似，但二者并不等价。最关键的差异在于：Kubernetes 控制的是相对确定的系统，而 LLM 循环控制的是概率系统。

Kubernetes 创建一个 Pod，动作结果通常是可预测、可观测、可重试的。LLM 接到同一句“修复支付系统并发问题”，今天可能这样改，明天可能那样改；Claude 和 GPT 也可能给出完全不同的方案。

这带来几个难题：

• 执行器不确定：同一输入不保证同一输出。
• 收敛不可证明：循环可能反复修改、原地打转，甚至把已经修好的东西改坏。
• 完成判断不可靠：模型说“任务完成”，不代表真的完成。
• 目标常常模糊：“优化支付系统”到底优化性能、稳定性、安全性，还是可维护性？
• 验证成本很高：测试通过不等于没有性能回退、安全漏洞或架构债务。

所以 AI Coding 比 Kubernetes Operator 更难。它不仅需要 reconcile，还需要更强的 goal definition 和 evaluation system。

Maker-Checker 像 Admission Controller

为什么现在越来越多 Agent 系统要拆成 maker 和 checker？原因很简单：不能完全相信执行器。

写代码的 Agent 可能会自我确认。它会说“已经修复”，但测试没跑全；它会说“方案更简洁”，但实际引入了新风险。于是需要另一个独立角色来审查它：运行测试、检查 diff、做安全扫描、读日志、判断是否真的满足目标。

这和 Kubernetes 里的 Admission Controller、Validating Webhook 有相似的工程直觉：不要让执行动作直接进入系统，要先经过策略、验证和约束。

未来的 Agent 系统大概率会越来越多层：

1
2
3
4
5

Maker
  -> Checker
  -> Reviewer
  -> Policy Engine
  -> Human

这不是把流程复杂化，而是在概率执行器外面补控制系统。

真正的上限在 Goal 与 Evaluation

Loop Engineering 的核心不只是设计循环。更深一层看，它真正要解决的是 Goal 和 Evaluation。

Kubernetes 之所以能稳定工作，是因为 Desired State 被形式化了。replicas: 3 的完成条件非常清楚：实际副本数等于 3。这里没有审美判断，也没有“差不多完成”。

AI Coding 最大的问题恰好在这里。很多目标是模糊的：

• “帮我优化这个系统。”
• “重构用户模块。”
• “修复线上稳定性问题。”
• “让这段代码更好维护。”

这些目标如果不被拆成可观察、可验证、可停止的条件，循环就很难收敛。Agent 不知道什么时候该继续，也不知道什么时候该停。

更合理的写法应该接近这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

goal:
  description: "修复支付系统的并发问题"
  metrics:
    correctness:
      unit_test_pass_rate: "100%"
      integration_test_pass_rate: "100%"
    performance:
      latency_p99: "< 100ms"
      throughput: ">= 1000 tps"
    safety:
      critical_vulnerability: 0
      data_race: 0

evaluation:
  layers:
    - unit_test
    - integration_test
    - e2e_test
    - benchmark
    - static_analysis
    - security_scan
  judge:
    model: "independent-checker"
    threshold: "all_layers_pass"

loop:
  max_iterations: 20
  strategy: "exponential_backoff"

到了这一步，大家写的就不再是 prompt，而更像 Agent CRD。真正重要的字段也不是选 Claude 还是 GPT，而是 goal.metrics 和 evaluation.layers。

软件工程师会更像控制系统工程师

这场变化不一定意味着 AI 会直接替代工程师。更可能发生的是，工程师的工作重心发生迁移。

过去，工程师主要写代码。未来，工程师会更多设计目标、验证、状态和反馈：

• 把模糊业务意图翻译成可收敛的目标。
• 设计多层 Evaluation Pipeline。
• 把 Agent 的记忆从对话里移到仓库、任务板和持久化状态里。
• 设计 maker、checker、reviewer 的边界。
• 定义终止条件和失败重试策略。
• 判断什么必须交给人类最终确认。

Prompt Engineer 可能会逐渐退场，不是因为 prompt 没用，而是因为写 prompt 这件事本身会被系统化。更稀缺的能力会变成 Goal Engineering 和 Evaluation Engineering。

结语

Loop Engineering 并不是凭空出现的新概念。它更像控制论、状态机、反馈系统、Kubernetes controller 和 Operator Pattern 在 AI Coding 时代的一次复活。

理解这场变化，可以分成四层：

1. 结构相似：Loop 类似 Operator。
2. 实现相似：Agent 类似 Controller。
3. 本质相似：Goal 类似 Spec，Evaluation 类似 Status。
4. 最重要的一层：AI Coding 不是自动化写代码，而是自动化逼近目标。

一切自动化逼近目标的系统，最终都会回到控制论：目标是否清晰，状态是否可观察，反馈是否准确。

所以，未来十年 AI Native 软件工程最值得研究的问题，可能不是“哪个模型更强”，而是：当软件开始自己修改自己时，我们该如何设计那个约束它、验证它、纠正它，并最终决定是否信任它的控制循环。