AI-Agent工程四层演进
AI Agent 工程四层演进：从 ReAct 到 Loop Engineering
梳理 Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering 的因果链条、核心突破与结构性问题。
一、源头：ReAct 与四大顽疾
ReAct（Reasoning + Acting）是 Agent 架构的起点——三行代码定义了一个时代：
Thought → Action → Observation → (重复)
每一步的 Thought、Action、Observation 被追加到对话历史，模型基于不断膨胀的上下文决定下一步。
四大结构性顽疾
| 顽疾 | 描述 | 关键数据 |
|---|---|---|
| 误差累积 | 每步正确率 95%，20 步后整体成功率仅 36%，40 步后仅 12% | 概率铁律，非靠「优化」可解 |
| 死亡循环 (doom-loop) | 失败 → 重试 → 再失败，无外部机制打断 | 2026 年初真实事故：40 分钟重启 200 次 |
| 上下文爆炸与污染 | 每步产出的中间产物累积进上下文，稀释注意力 | 3×15 条消息会话比 1×40 条更快更准 |
| 无独立验证 | Observation 只反馈工具执行结果，不反馈「任务是否在朝目标前进」 | 连续 10 步工具成功，整体方向可能是错的 |
共同根因： ReAct 把推理、决策、观察、状态全部塞进同一个上下文窗口，没有隔离、分层、独立验证和外部中断。
二、四层演进总览
Loop Engineering (2026.6+)
└── 内部跑着 Harness Engineering (2026 Q1-Q2)
└── Harperness 的每一步在做 Context Engineering (2025) 的拼装
└── Context 拼装好后，喂给模型的是一个 Prompt (2022-2024)
不是替代关系，是包含关系。
三、第一层：Prompt Engineering（2022–2024）
本质
模型是函数 P(下一个 token | 前面所有 token)。每条 prompt 不是「指令」，而是条件——把采样空间挪到训练数据中对应语境附近。
核心技巧
- Few-shot：用样本锚定输出格式，比抽象描述约束力强
- Chain of Thought：显式生成推理 token，给最终答案提供更强的条件路径
- 角色设定、分隔符：收窄采样方差
致命天花板
Prompt 是静态文档。 写进去的知识在写的那一刻就是上限。政策更新了、代码库变了、场景超出预想——prompt 全不知道。
Prompt 控制的是「怎么说」，控制不了「能看到什么」。
控制面：消息层
四、第二层：Context Engineering（2025）
转折点
2025 年，行业共识：模型能力是常量，上下文是变量。当变量比常量更能决定结果时，工程重心转移。
Karpathy +1, Shopify CEO Tobi Lütke 提出, Simon Willison 论证。正式定义：「用恰到好处的信息填充上下文窗口的精细艺术与科学。」
核心方法
- RAG：向量检索 → 召回 → rerank → 拼装上下文
- 关键原则：无关上下文是负债，不是中性的。它不仅浪费 token，还主动稀释注意力。
- 记忆管理、渐进式披露、上下文压缩
解决和引入的问题
- 解决了：Prompt 无法感知动态信息 ✓
- 引入了：模型看到了正确的信息，却做了错误的决策 ✗
- 案例：代码审查 Agent 推理完全正确，但擅自执行了数据库迁移
看到正确的数据 ≠ 会做正确的决定。后者需要的是行动约束。
控制面：会话层
五、第三层：Harness Engineering（2026 Q1–Q2）
定义
Mitchell Hashimoto: Agent = Model + Harness
Martin Fowler 正式定义：「设计系统、约束和反馈循环以围绕 AI Agent 构建使其在生产中可靠的学科。」
六层架构
| 层次 | 组件 | 解决的问题 |
|---|---|---|
| 引导层 (Guides) | System Prompt、AGENTS.md、ADR | 告诉 Agent 该做什么、不该做什么 |
| 感知层 (Sensors) | 评估器、验证器、测试套件 | Agent 行动后检查对错 |
| 工具层 | 文件读写、Bash、搜索、Web | Agent 可调用的能力集合 |
| 权限层 | allow/ask/deny 规则、路径白名单 | 防止 Agent 做不该做的事 |
| 生命周期层 | Hooks、Checkpoint、恢复、超时 | 管理会话和状态 |
| 记忆层 | CLAUDE.md、TODO.md | 跨会话知识沉淀 |
核心发明：maker-checker 分离
干活的和验收的不是同一个 Agent。用确定性的验证（编译、测试、lint）去锚定概率性的生成（LLM 输出）。
关键数据
- 同一模型，不同 Harness 配置，解出率相差 6 倍（12% vs 2%）
- Stripe 每周通过 Harness 生成 1,300 个 AI PR
- Anthropic 工程师日代码产出提升 8 倍
术语归位
- MCP：Harness 工具层的 USB 标准
- Skills / SKILL.md：程序性知识的可维护模块
- Ralph Loop：
while true; do claude -p "$(cat PROMPT.md)"; done——每次迭代新上下文窗，无污染无衰减 - 16 Agent 并行构建 C 编译器：结论：Agent 循环的架构决定行为，而非模型身份
结构性盲区
Harness 能约束 Agent 在执行任务时的每一个动作——但不会主动检查「这个任务之外还有没有其他事需要考虑」。
Claude Code 自己的 npm 发布事故（51.2 万行源码泄露），$12,847 账单故事——Agent 每一步都「合法」，但没人让它「停下来」。
控制面：系统层
六、第四层：Loop Engineering（2026 年 6 月起）
引爆点（72 小时）
- Peter Steinberger（OpenClaw/PSPDFKit 创始人）推特：「你不应该再给编程 Agent 写提示词，你应该设计让 Agent 自己提示自己的 Loop。」（1500 万浏览）
- Addy Osmani（Google Chrome 工程负责人）命名并系统化
- Boris Cherny（Anthropic Claude Code 负责人）：「我的工作已经不是写提示词了，我的工作是写循环。」
本质：收敛控制系统，不是 while 循环
五部件缺一不可：
| 部件 | 职责 | 产品化 |
|---|---|---|
| 目标/终止条件 (GOAL) | 「所有测试通过且覆盖率 >90%」——必须可机器判定 | 你设计 |
| 驱动 (DRIVE) | 用当前状态构造 prompt 调用 Harness | /goal、Automations |
| 执行 (HARNESS) | 工具调用、验证闸门、权限检查 | 第三层已有 |
| 独立裁判 (CHECKER) | 判断目标是否达成（maker ≠ checker） | Outcomes 的 grader |
| 安全闸门 (GATES) | 最大迭代/预算/连续无进展检测 | 你设计 |
**真正的战场是 目标 + 裁判 + 闸门。**循环体已经有人做好了。
为什么 checker 必须独立
Anthropic Outcomes 系统：grader Agent 运行在全新上下文窗口，只能看到评分标准和产物，看不到原始推理路径。独立 grader 比同模型自我评估，任务成功率提升 10 个百分点。
Loop vs Cron
| 维度 | Cron | Loop |
|---|---|---|
| 触发 | 时间到了就跑 | 状态/目标驱动 |
| 终止 | 跑完一次结束 | 目标条件判定 |
| 反馈 | 无，每次全新开始 | 差距喂给下一轮 |
| 验证 | 无内建 | 独立裁判闸门 |
| 失控保护 | 无 | 预算/轮次/无进展 三道闸门 |
| 核心设计 | 时间表达式 | 终止条件 + 验证标准 |
Cron = 定时开关电暖气；Loop = 恒温空调。
控制面：时间层
第一条军规：先写怎么停，再写怎么跑。
七、失效模式速查表
| 症状 | 问题在哪一层 | 怎么修 |
|---|---|---|
| Agent 答非所问、输出格式不对 | Prompt 层 | 改 prompt 目标和示例 |
| Agent 自信地编造事实、引用不存在的东西 | Context 层 | 优化检索质量、更新知识库 |
| Agent 做不该做的事、跳过验证流程 | Harness 层 | 搭 maker-checker、检查权限配置 |
| Agent 在无人值守时烧光预算 | Loop 层 | 设终止条件、预算上限、无进展检测 |
大多数翻车是第二层或第三层的问题。但你大多数时候在用第一层的方法修——把 prompt 改得更详细。这就是你总觉得 AI「不够聪明」的原因。