AI Agent 演进的隐秘主线：从 Prompt 到 Loop Engineering 的控制论密码

AI Agent 演进的隐秘主线：从 Context 到 Loop Engineering 的控制论密码

如果你在过去几个月里持续开发或跟进前沿的 AI Agent 架构，你会发现业界的叙事正在快速从“调教 Model”转向“构建 System”。

Anthropic 的 Claude Code 负责人 Boris Cherny 前不久公开表示：“我已经不再直接 Prompt 模型了。我现在的工作是编写 Loop（循环），让 Loop 去 Prompt 模型。”

从最初的 Prompt Engineering（提示词工程），到 Context Engineering（上下文工程）、Harness Engineering（驾驭工程），再到如今最热的 Loop Engineering（循环工程），各种新概念层出不穷。作为天天和 Agent 打交道的开发者，我们很容易觉得这是大模型时代特有的“新发明”。

然而，当我们跳出 AI 圈子的炫酷名词，深入到 Agent 频繁陷入死循环、越改越乱、上下文爆炸等具体痛点时，会发现一个耐人寻味的规律：今天 AI Agent 领域正在解决的工程问题，本质上是在重演已经有百年历史的“自动控制理论（Automatic Control Theory）”。

在这套视角下，我们面对的不是一个无所不能的“超级大脑”，而是一个包含不确定性、时滞和噪声的物理世界。本文将从一个 AI Agent 开发者的视角，借助控制工程的黑话，重新拆解 Agent 架构的演进，并聊聊为什么未来的 Agent 终局一定会走向控制回路的闭环设计。

---

一、 AI Agent 架构演进：一段被 Bug 逼出来的血泪史

作为工程师，我们构建 Agent 架构的演进史，并不是在一张白纸上做顶层设计，而是一段被各种具体 Bug 逼着不断打补丁的血泪史。

一切的起点，是我们遇到了单次 Prompt（提示词）的天花板。 早期我们直接调用 API，为了让模型输出完美的格式，在 Prompt 里写满了 SOP 和 Few-shots。这种 Prompt Engineering（提示词工程） 在处理简单生成任务时非常有效，但它本质上是“开环”的无状态盲盒。一旦面对像“排查生产环境 Bug”这样长线、多步骤的复杂任务，单次请求的模型必然会“断片”或丢三落四。我们意识到，模型必须拥有记忆。

为了让模型拥有记忆，我们进入了 Context Engineering（上下文工程）。 既然单次调用搞不定，我们就引入多轮交互。如果模型写出的代码跑出了编译报错（如 Traceback），最直观的做法就是把报错信息全量塞回历史记录里让它重试。 然而，灾难很快降临：如果不加处理，几次尝试后上下文里就会堆满垃圾报错信息，模型彻底“迷失”在脏数据中，忘记了最开始的任务，甚至陷入重复犯错的死循环。这就逼迫业界提出了 Context Engineering。正如 LangChain 等框架的业界定义：Context 并非只是 Prompt，而是艺术般地在 LLM 推理时，将最精确的信息动态填入上下文窗口的工程。只有做好了信息卸载（Offload）和降噪压缩，模型才能保持清醒。

可是，一个清醒的“大脑”仍是不安全的，我们需要 Harness Engineering（驾驭工程）。 当记忆不再混乱后，我们面对的是下一个棘手问题：模型在生成文本时极其自信，常常表现出“达克效应”，凭空捏造（幻觉）出不存在的 API 或危险指令。如果直接把它连入生产系统，它可能会无意中执行 rm -rf /。 为了解决这个安全隐患，我们给模型打造了一套坚固的执行脚手架。著名架构师 Addy Osmani 对此给出了权威定义：“Harness 就是除了模型之外的所有代码、配置和执行逻辑。裸模型不是 Agent，只有当 Harness 赋予它状态维护、沙盒执行、安全联锁和反馈通道时，它才成为 Agent。” 业内由此达成了共识：Agent = Model + Harness。Harness 用底层的物理脚手架托底了模型不可控的概率输出。

当模型既聪明又安全后，终极目标呼之欲出：Loop Engineering（循环工程）。 现在，我们有了一个记忆清晰、装备齐全且处在安全沙盒中的模型。最后一步，自然是摆脱人类“保姆式”的单步指令，让系统自主接管执行流程。 业界对此的定义是：设计能够自行 Prompt、检查、重试并知道何时终止的自治迭代闭环系统。为了实现这个自治系统，我们写出了如下的 while 循环状态机：

# 一个典型的朴素 Agent 自治循环
while not task_completed and steps < max_steps:
    # 1. 计划与推理 (Plan)
    action = llm.generate_action(clean_context)
    
    # 2. 物理执行 (Act)
    observation = harness.execute(action)
    
    # 3. 评估与重试 (Observe / Adjust)
    success = verify(observation)
    if success:
        task_completed = True
    else:
        # 降噪后追加到上下文，并重试
        clean_context.update_belief_state(observation)
        steps += 1

然而，正是这个看似完美的闭环，将我们推向了纯软件工程的死胡同。 当我们满怀期待地看着这个自治系统运行后，却绝望地发现它像个喝醉的司机：面对小错和大改都用同一套沉重的循环（成本极高）；经常在改对 A 导致 B 报错、修好 B 导致 A 报错之间来回跳跃（高频震荡）；连续失败几次后，即使是有降噪的上下文也会被执念填满，导致智商暴跌（积分饱和）。

这让我们彻底醒悟：把几个工程模块（Prompt, Context, Harness）简单地套上一个 while 循环，并不能自然拼凑出一个稳定收敛的自治系统。 要解决这种高频震荡、状态发散和死锁，纯粹的软件设计思维已经不够用了。我们需要跨界寻找一套专门对付不确定性和反馈震荡的数学工具。

---

二、 顿悟时刻：如何用控制理论重新理解 Agent？

当我们翻开大学教材，看到自动控制理论中描述动态系统的**状态空间方程（State-Space Equations）**时，迎来了堪比“破案”般的顿悟时刻：

初看公式，满屏的数学符号可能会让程序员感到头大。但试着想象一个极其经典的工程场景：冰雪路面上的自动驾驶汽车。汽车（物理系统）有自己的惯性，路面极滑（高方差环境），传感器有延迟和误差（观测噪声）。控制器的任务，就是根据带有噪声的仪表盘数据，不断输出刹车或油门的指令，把这辆随时会失控的车开到终点。

如果把这个场景与我们每天 Debug 的 Agent 系统对齐，一次极其震撼的“语义重构”就发生了：

控制理论概念	对应 Agent 系统要素	开发者视角的具体解释
被控对象 (Plant)	代码库与工作区 (Codebase)	那辆容易打滑的“车”。也就是我们想要改造的物理世界（状态包含代码逻辑、Bug 分布等）。
系统状态 ()	代码的真实状态 (Actual State)	代码在磁盘上的真实内容以及隐藏的关联 Bug。这通常是个黑盒，模型无法一次性全部看清。
设定值 (Reference )	用户的 Feature/Bug 需求	自动驾驶的“目的地”。例如“修复登录接口的 Traceback 报错”。
控制器 (Controller)	Agent 运行时 + 大模型 (Loop + LLM)	行车电脑。它负责读取传感器数据，计算与目的地的差距，并决定下一步踩油门还是打方向盘。
控制输入 ()	LLM 产生的动作 (Tool Calls)	模型输出的具体执行指令（比如修改了第 42 行代码，或运行了一条 Shell 命令）。用来改变被控对象的状态。
观测值 ()	终端输出 / 测试报错	行车电脑仪表盘上的带噪数据。我们只能通过编译输出、测试结果来评估当前代码的好坏，而这些日志经常是被截断或带有 Flaky 噪声的。
控制器信念状态	LLM 上下文窗口 (Context Window)	电脑对当前车况的“记忆”。如果 context 里堆满了历史的脏日志，相当于电脑内存溢出，决策必然撞车。

这个映射揭示了一个被很多人误解的关键本质： 在 AI 工程中，大模型（LLM）本身并不是那辆需要被我们控制的“车”；大模型是控制器（Controller）核心的决策芯片，而它吐出来的那些 Tool Calls，就是控制输入（）。我们要开的那辆“车”（被控对象），其实是存放在沙盒里的代码库。

如果作为核心芯片的大模型在生成代码时存在“自回归惯性”（Autoregressive Inertia），一旦上下文里塞满了它自己写错的代码，它就会顺着上文继续产生幻觉。这在控制论中，叫做正反馈导致系统发散（Divergence）——简单来说，就是行车电脑死机了，并且一脚把油门踩到底。

---

三、 盲人摸象：用新视角重新审视我们的“发明”

有了这套从控制论借来的“黑话”，我们再回过头去看之前辛辛苦苦手搓的 Context、Harness 和 Loop，就会哭笑不得地发现：我们其实是在“盲人摸象”般地重新发明经典的控制论组件。

1. Context Engineering = 状态估计与卡尔曼滤波

在自动驾驶中，如果雷达把打在摄像头上的雨滴、杂波直接传给决策芯片，电脑瞬间就会死机。为了解决这个问题，控制工程发明了卡尔曼滤波器（Kalman Filter）：用算法比对系统原有的状态和新收到的杂乱观测值，剔除冲突和噪声，提炼出一个干净的、最接近真实的“当前状态（Belief State）”，再喂给控制器。

在 Agent 开发中，直接把 500 行 Traceback 和十几轮的对话历史丢给 LLM，就等于“把雷达噪点直接喂给芯片”。这也是为什么业内强调 Context Engineering 必须做“降噪压缩”。 我们原以为自己只是在写一些提取报错关键信息的正则脚本，但实际上，我们是在手搓一个低配版的大模型卡尔曼滤波器：

// 经过“状态估计”过滤后的干净上下文状态
{
  "target_goal": "Fix database connection timeout",
  "completed_milestones": ["Checked environment variables", "Located config file"],
  "current_hypothesis": "The host configuration is hardcoded to localhost",
  "active_errors": ["ConnectionRefusedError on port 5432"],
  "failed_attempts": [{"action": "modify port in db.py", "result": "Failed with same error"}]
}

每次迭代时，通过一个小模型过滤掉无关的 Traceback 细节，只更新这个结构化的 JSON。LLM 每次收到的都是去噪后的“状态估计”，这才是解决记忆漂移的治本之策。

2. Harness Engineering = 物理联锁（Interlock）与传感器融合

我们在前面提到，Harness 的作用是把模型关进沙盒。但用控制论的视角来看，Harness 解决的其实是**传感器融合（Sensor Fusion）与安全联锁（Safety Interlocks）**的问题。

不论自动驾驶算法（大模型内部的推理逻辑）表现得多么确信前方没有障碍物（幻觉），只要物理防撞雷达（本地的 AST 语法解析器或 Linter）检测到红线，底层的硬联锁必须无条件截断控制信号，实施强制刹车。 这正是著名架构师 Addy Osmani 所描述的真谛：只有当 Harness 在底层赋予了模型安全联锁与物理反馈通道时，裸模型才真正跨越了生成文本的边界，成为了具备执行力的 Agent。面对随时会发疯的概率大脑，不要试图和它讲道理（Prompt），而是用 Harness 的物理规则去硬性托底。

3. Loop Engineering = 破烂的 P 控制器

现在，让我们回到那个导致系统失控的朴素 while 循环。为什么它会把代码改得一团糟？因为用 PID 控制的视角来看，这个 while 循环本质上只是一个缺失了关键阻尼机制的初级比例（P - Proportional）控制器。

       ┌────────────────────────┐
r ───> │        Controller      │ ─── u_t ───> [ Codebase (Plant) ]
       │  (LLM + Context Loop)  │                     │
       └────────────────────────┘                     │
                   ▲                                  ▼
                   └─────────── y_t (Test/Linter) ────┘

1. 比例项（P - Proportional）：误差有多大，动作就有多猛

   • 在代码里：这就是 if compiler_error: feed_error_to_llm()。
   • 开发者的痛：只用 P 控制极易引发高频震荡（Chattering）。模型改了 A 行修复了一个 Bug，结果引发了 B 行的报错；为了修 B 又去改 C，最后又绕回了 A 的报错。这就是典型的因为缺乏阻尼而在两个误差间来回横跳。

2. 积分项（I - Integral）：历史误差的阴魂不散

   • 在代码里：为了让模型吸取教训，我们把过去 5 轮的失败记录都保留在 Context 中。
   • 开发者的痛：这引发了经典的积分饱和（Windup）。由于失败记忆在 Context 中的 Attention 权重越积越大，模型彻底被过去的挫折感“洗脑”了。它的决策空间被污染，变得无比固执，哪怕此时你只需要改一个拼写错误，它也看不到了。

3. 微分项（D - Derivative）：对未来的预判

   • 在代码里：在修改前预测这个改动会导致什么趋势。
   • 开发者的痛：我们手写的 while 循环里根本没有 D 控制！模型修改底层类库时，丝毫不会预判“这会导致上游 10 个模块全部飘红”，缺乏“提前踩刹车”的预见性。

---

四、 预见未来：从修补走向真正的工程演进

既然发现当前的 Loop 只是个破烂的 P 控制器，那么要想让 Agent 真正稳定地运行在生产环境，下一步该怎么走？答案就藏在现代控制论的高阶武功里。在未来 1-2 年内，为了解决当前的痛点，AI 架构大概率会演化出以下核心特征：

1. 自适应控制：根据智商切换步长（Online System Identification）

• 诊断：同一个模型，面对熟悉的 CRUD 代码智商高达 120，面对底层 C++ 内存泄漏智商瞬间跌到 80。用死板的 Loop 应对时高时低的智力，效率极低。
• 架构进化：引入在线系统辨识（Online System Identification）。控制器会实时监控 LLM 当前的成功率。
  • 高信心区 (小偏差)：如果连续几次修改都一次通过，系统判定当前在“舒适区”，自动切换大步长，下放宏观指令，减少中间打断以节省 Token。
  • 低信心区 (高失误区)：一旦 Harness 发现模型在一个 bug 上连续摔倒 2 次，系统辨识出“已超出模型能力边界”。此时自动降低控制增益，切入强流程的“窄步长模式”——强制模型先写单测、每次只准改一行、引入人类介入审批。用外部的高阻尼规则托底智力滑坡。

2. 级联控制：将高频噪声隔离在内环（Cascade Control）

• 诊断：少写一个括号导致的 Syntax Error，这种毫无营养的垃圾日志一旦流入全局上下文，就会挤占模型宝贵的注意力，导致宏观规划全盘崩溃。
• 架构进化：借鉴化工厂“外环控制慢变量（如温度），内环控制快变量（如阀门）”的思路，Agent 必须走向**级联控制（Cascade Control）**的双环架构。

graph TD
    User([用户需求 r]) --> OuterLoop[外环: 慢速/长上下文宏观决策器<br>如 GPT-4o / Claude 3.5]
    OuterLoop -->|下发局部修改指令 r_inner| InnerLoop[内环: 快速/短上下文微观执行器<br>如 Deepseek / Qwen Coder]
    InnerLoop -->|Tool Call u_t| Sandbox[沙盒与编译器 Plant]
    Sandbox -->|本地编译/语法反馈 y_inner| InnerLoop
    Sandbox -.->|全局测试通过状态 y_outer| OuterLoop

• 外环 (Slow Loop)：昂贵的大模型扮演“架构师”，只看去噪后的信念状态，负责宏观规划（“重构 utils.py”）。
• 内环 (Fast Loop)：便宜且快速的小模型扮演“码农”。遇到漏括号、变量未定义等高频噪声，全部由内环自己原地消化重试。只有当内环把代码跑通了，才向外环汇报“任务完成”。通过双环隔离，彻底斩断局部报错对全局状态的污染。

3. 模型预测控制：基于“世界模型”的滚动推演（MPC）

• 诊断：传统的 Tree of Thoughts (ToT) 是“开环”的盲目规划。它在脑海里推演 100 步，但在非线性的代码世界里，第 2 步只要有一个文件读写失败，后面 98 步的推演就全作废了，算力极其浪费。
• 架构进化：引入工业界大放异彩的模型预测控制（Model Predictive Control, MPC）。 MPC 的精髓在于滚动时域（Receding Horizon）：模型在脑海中预测未来 3 步的动作和代价，但在现实沙盒中，它坚决只执行第 1 步。执行完拿到真实的终端反馈后，基于最新的现实状态，再重新预测未来的 3 步。这种“走一步看一步、时刻校准”的机制，完美兼顾了长远规划与现实中的突发报错。

4. 鲁棒控制：构筑数学底线的强制回滚（Robust Control）

• 诊断：概率模型永远有概率发疯。有时它会把原本运行完美的代码改得面目全非。
• 架构进化：引入李雅普诺夫稳定性（Lyapunov Stability）。 为了确保系统永远不会彻底崩溃，底层的 Harness 会在物理层强制定义一个“误差能量函数”（例如 ）。 在模型每一次尝试修改后，Harness 会立刻计算 。
  • 只要 （误差在减小），随它怎么改。
  • 一旦连续出现 （越改越烂，以前过的测试现在挂了），系统将停止与模型“讲道理”，直接触发硬件级的 git reset --hard 回滚到上一个能量最低的安全不变集（Invariant Set）。用确定性的物理底线，去镇压 AI 的软性发散。

---

结语：从炼金术士到系统架构师

回看那条简洁的状态空间方程：。

在这个公式的启迪下，我们终于明白，作为一个 AI Agent 开发者，我们整天在绞尽脑汁写的那些 Context 降噪器、Harness 沙盒、Loop 状态机，其本质并不是在拔高 LLM 这个单体模型的智商上限。

我们真正在做的，是利用控制工程的智慧，构建精妙的反馈补偿器和降噪观测网，将一个充满方差、高度非线性、极度不可靠的概率决策大脑（LLM），努力封装成一个近似于稳定、收敛、输出确定性的复杂软件系统。

AI Agent 的上半场，属于以调教 Prompt 为核心的“语言学炼金术”。 而正在到来的下半场，必将属于状态估计、级联双环、滚动预测与鲁棒收敛等自控技术交织的“现代工程科学”。在不确定的概率浪潮中，亲手建立起确定性的控制回路——这，才是下一代 AI 开发者完成身份蜕变的系统级密码。