别再追“新词”了！从 Graph Engineering 破局，彻底搞懂 AI Agent 的底层内核 Loop Engineering

記億揺晃着的那天

25人浏览 · 2026-09-14 17:20:21

記億揺晃着的那天 · 2026-09-14 17:20:21 发布

AI 圈的造词速度快得令人窒息。

从最早的 Prompt Engineering（提示工程），到后来的 Context Engineering、Harness Engineering，再到 Loop Engineering（循环工程）。前段时间，圈内又被 Graph Engineering（图工程）刷屏了。

如果你追着各种概念跑，很快就会陷入“学不完，根本学不完”的焦虑。但如果剥开这些包装，你会发现：Graph 不是什么新救世主，它只是 Loop 的集合；真正决定 AI Agent 系统上限的，依然是单个 Loop 的控制力。

本文将带你跳过名词炒作，厘清两者的本质关系，并为你梳理一份攻克 Loop Engineering 的核心技术体系与学习路线。

01. 一场吐槽引发的“新概念狂欢”

事源于 OpenClaw 创作者 Peter Steinberger 在 X（原 Twitter）上发的一条动态：

“Are we still talking loops or did we shift to graphs yet?”

（我们还在聊 loops 吗？还是说大家已经转向 graphs 了？）

随即，AI 研究员 Hamel Husain 顺水推舟写了一篇调侃文章《Loop Engineering Is Dead. Enter Graph Engineering》。

二人本意是吐槽 AI 行业改名成瘾的习惯，结果不到 48 小时，社区里就铺天盖地涌现出了各种“Graph Engineering”课程、路线图和新工具链。

在这里插入图片描述

02. 剥开迷雾：Loop 与 Graph 的真实关系

要透彻理解这两者，首先需要明确它们的定义与边界：

什么是 Loop（循环）？

Loop 是一个自主运行的控制闭环。在此模式下，Agent 无需人类在每个步骤重复提示（re-prompting），即可自动完成“规划（Plan）— 执行（Act）— 验证（Verify）”的循环。

典型案例：Linear 的自动化 Loops 功能，能够在后台按定时器或触发器运行，自动完成 Bug 分类、文档更新等。

什么是 Graph（图）？

Graph 将这个思想向上提了一层：它将多个 Loop 编排在一起。在 Graph 架构中，节点（Nodes）代表独立的 Agent 或任务，边（Edges）代表状态传递与控制流。

代表框架：LangGraph、Microsoft AutoGen、Google ADK。

两者的核心推论

Loop 是 Graph 的基本单元：Loop 不是 Graph 的对立面，一个 Loop 就是 Graph 中的一个 Node。
多 Agent 拼不出好的单 Agent：如果单个 Loop 的执行逻辑是混乱的，把它们串成 Graph 只会得到一个更加庞大且无法调试的复杂系统。
架构演进原则：从单一 Loop 开始，把它推到能力的极限。只有当单个 Loop 无法承载复杂业务时，才是引入 Graph 的正确时机。

03. 核心干货：Loop Engineering 的 5 大控制维度

要写出稳定可用、不死循环、不逃逸的商业级 Agent，你需要将 Loop 视为一个控制系统（Control System）来设计。

在这里插入图片描述

1. 控制闭环与确定性终止 (Deterministic Termination)

千万不要写 while(true) { llm.call() }！Agent Loop 必须依靠确定性验证判断是否终止，而不是让 LLM “自评是否完成”。

Sensors（感知）：读取单元测试结果、API 返回码、Lint 错误。
Goal（目标）：通过代码断言（Assertions）或硬性 Schema 匹配来定义完成状态。

2. 状态与上下文管理 (State & Context Management)

随着迭代代数（Iterations）增加，Prompt 上下文会快速膨胀。

Context Sliding Window：滑动窗口裁剪旧历史。
State Persistence：步骤状态实时落盘，保证系统 crash 后能原地 Resume。

3. 两种核心循环模式

ReAct 模式：Reasoning $→\rightarrow$ Acting $→\rightarrow$ Observing $→\rightarrow$ Next Reasoning.
Evaluator-Optimizer 模式：Generator 生成答案 $→\rightarrow$ Evaluator（打分/运行测试） $→\rightarrow$ 给出反馈 $→\rightarrow$ Generator 修正。

4. 边界控制与安全熔断 (Guardrails & Bounding)

Budget Limit：限制最大迭代次数（Max Iterations）、Token 消耗上限与超时时间。
Oscillation Detection（震荡检测）：检测 Agent 是否在 A 和 B 两个状态间反复跳脚（例如修了 Bug A 导致 Bug B，修了 Bug B 又引发 Bug A）。

5. 人工降级通道 (Human-in-the-Loop)

当 Loop 连续重试达到上限，或判定置信度低于阈值时，自动打包上下文日志，挂起任务并主动拉人接管。

04. 极简实战：手写一个带熔断与验证的 Python Agent Loop

不依赖 LangChain / LangGraph，用几行原生代码看看真实的 Loop 如何工作：

import os
import subprocess
import time

class AgentLoop:
    def __init__(self, target_file: str, test_file: str, max_iters: int = 5, max_tokens: int = 10000):
        self.target_file = target_file
        self.test_file = test_file
        self.max_iters = max_iters
        self.max_tokens = max_tokens
        self.accumulated_tokens = 0
        self.action_history = []  # 用于震荡检测

    # 1. Sensors (感知器)：确定性获取真实环境状态
    def _run_verifier() -> tuple[bool, str]:
        """运行 pytest 单元测试，返回 (是否通过, 错误日志)"""
        result = subprocess.run(["pytest", self.test_file], capture_output=True, text=True)
        is_success = (result.returncode == 0)
        output = result.stdout if is_success else result.stdout + "\n" + result.stderr
        return is_success, output

    # 2. Circuit Breaker (熔断机制)：多维度硬性拦截
    def _check_circuit_breaker(self, current_iter: int, last_action: str) -> tuple[bool, str]:
        if current_iter >= self.max_iters:
            return True, f"熔断：已达到最大迭代轮数 ({self.max_iters} 次)"
        if self.accumulated_tokens >= self.max_tokens:
            return True, f"熔断：已超出 Token 预算消耗 ({self.accumulated_tokens}/{self.max_tokens})"
        
        # 震荡检测：检测 Agent 是否在原地打转或陷入死循环
        self.action_history.append(hash(last_action))
        if len(self.action_history) >= 3 and self.action_history[-1] == self.action_history[-3]:
            return True, "熔断：检测到状态震荡（Agent 正试图进行重复的无效修复）"
            
        return False, ""

    # 3. Decision & Actuators (推理与执行循环)
    def run(self):
        print(f"🚀 [Loop Start] 目标文件: {self.target_file} | 测试套件: {self.test_file}")

        for current_iter in range(1, self.max_iters + 1):
            print(f"\n--- Iteration {current_iter}/{self.max_iters} ---")

            # 步骤 A：验证门控 (Verifier Check)
            passed, logs = self._run_verifier()
            if passed:
                print("✅ [Verifier Pass] 所有单元测试通过！Loop 正常退出终止。")
                return True

            print("❌ [Verifier Failed] 单元测试未通过。观察到环境报错...")
            
            # 读取当前有 Bug 的代码上下文
            with open(self.target_file, "r") as f:
                code_context = f.read()

            # 步骤 B：构建 Prompt 模拟推理与决策 (Reasoning)
            # 在实际工程中，此处替换为 client.chat.completions.create(...)
            mock_llm_response = f"# Fixed in iter {current_iter}\ndef add(a, b):\n    return a + b\n"
            self.accumulated_tokens += 150  # 模拟耗用 Token 计数器

            # 步骤 C：熔断校验 (Circuit Breaker Check)
            should_fuse, reason = self._check_circuit_breaker(current_iter, mock_llm_response)
            if should_fuse:
                print(f"🚨 [System Escalation] {reason}")
                print("🛑 任务已从 Loop 中中断，正在打包运行日志并触发 Human-in-the-Loop 人工接管机制...")
                return False

            # 步骤 D：执行修改 (Actuator Execution)
            with open(self.target_file, "w") as f:
                f.write(mock_llm_response)
            print("📝 [Actuator] Agent 已完成对代码文件的覆盖写入。准备进入下一轮验证...")

        return False

# 运行验证
if __name__ == "__main__":
    loop = AgentLoop(target_file="math_utils.py", test_file="test_math_utils.py")
    loop.run()

05. 总结：工程化落地的理性回归

无论技术圈炒作的概念叫 Prompt Engineering、Loop Engineering 还是 Graph Engineering，AI 工程化的底层难题从未改变：

始于单 Loop：在项目初期，尽量把所有的控制集中在一个确定性高的 Agent Loop 内部，建立清晰的感知、执行与软硬验证。
推至破裂点：不断向单个 Loop 压入边界情况，观察它是在上下文长度上崩溃，还是在权限/上下文隔离上失效。
按需重构为 Graph：只有当单 Loop 的状态机无法支撑业务复杂度时，才根据失败的具体模块，将其拆分为独立的 Node，并用 Graph 进行连线和状态编排。

记住：能用一个干净 Loop 解决的问题，绝对不要引入 Graph 的复杂性。