AI 工程的五个层级：从 Prompt 到 Graph，一次完整的范式跃迁

不瘦80斤不改名

356人浏览 · 2026-07-28 15:26:59

不瘦80斤不改名 · 2026-07-28 15:26:59 发布

2026 年中，AI 工程圈掀起了一轮密集的造词运动。Prompt Engineering 还没讲完，Context Engineering 就来了；Context Engineering 还在消化，Harness Engineering 冒出来了；Harness 刚搞明白，Loop Engineering 和 Graph Engineering 又开始打架，甚至有人喊出"Loop Engineering 已死"。

看起来眼花缭乱，但这五个概念之间不是并列关系，而是一条清晰的演进链路：从优化一次对话的指令，到编排一群 Agent 的协作图。每一步都在解决上一步的瓶颈。这篇笔记把五个工程的概念、边界、核心技术和它们之间的递进关系一次梳理清楚。

一、演进全景：五个工程不是并列，是递进

先给结论，这五个工程的关系可以用一个公式概括：

Agent 系统 = Graph(节点编排) > 节点 = Loop(自循环) > 循环宿主 = Harness(运行时) 
           > 运行时核心 = Context(上下文) > 上下文入口 = Prompt(指令)

从外到内，每一层包裹着下一层：

层级	工程	核心问题	工作单元	类比
L1	Prompt Engineering	怎么跟模型说话	单条指令	给 CPU 发一条指令
L2	Context Engineering	给模型看什么	整个上下文窗口	往 RAM 里装什么数据
L3	Harness Engineering	让模型在什么环境下跑	Agent 运行时	操作系统
L4	Loop Engineering	让一个 Agent 自己跑到目标	执行-验证-修正循环	一个工位上的老师傅自己琢磨
L5	Graph Engineering	让一群 Agent 协作	节点+边+状态	整条流水线的调度中心

每一层都不是"替代"上一层，而是吸收上一层。Prompt Engineering 没有死，它变成了 Context Engineering 的一个子组件；Context Engineering 没有死，它变成了 Harness Engineering 的一个支柱；Loop 没有死，它变成了 Graph 里的一个节点。

理解了这条递进链，就不会被"XX Engineering 已死"这种标题带偏。

二、Prompt Engineering：与模型对话的最小单元

2.1 定义

Prompt Engineering 是通过设计单次或少数几轮对话的输入指令，让 LLM 准确理解并执行任务。工作单元是一条消息或一对消息。

核心技术手段：

角色赋值：你是一位资深 Python 后端工程师...
Few-shot 示例：给模型几个输入-输出对作为参考
Chain-of-Thought：请一步步思考...，引导模型展示推理过程
结构化输出：请以 JSON 格式返回，包含 title、summary、tags 三个字段
约束声明：不要使用任何第三方库、代码注释用中文

2.2 为什么它被"吸收"而不是"死亡"

Prompt Engineering 关注的是上下文窗口中大约 5% 的内容——那条用户输入的指令。但随着模型能力增强，一个反直觉的现象出现了：Anthropic 将 Claude Code 的系统提示词精简了 80%，编码评测性能未出现明显下滑 $TRAE_REF。模型能力越强，越不需要保姆式的指令堆砌。冗长的规则不仅消耗 Token，还可能产生负面效果——模型在过多约束中反而"不知道该听哪条"。

这并不意味着 Prompt Engineering 失去了价值。一个粗糙的系统提示词仍然会拖垮整个系统的表现。但它的定位变了：从"调教模型的全部手段"变成"上下文工程中的一个组件"，就像写一个干净的函数是软件架构中的一个基础组件。

三、Context Engineering：从一条指令到整个信息环境

3.1 定义

Context Engineering 是设计模型在生成响应前所感知的完整信息包的学科。工作单元是整个上下文窗口。

一个形象的类比 $TRAE_REF：LLM 是 CPU，上下文窗口是 RAM。Prompt Engineering 是"你现在告诉 CPU 做什么"，Context Engineering 是"你往 RAM 里装了什么数据"。

上下文窗口里装的远不止用户的一条 Prompt：

┌─────────────── 上下文窗口 ───────────────┐
│  系统提示 (System Prompt)                 │
│  对话历史 (Conversation History)           │
│  检索到的文档 (Retrieved Documents)        │
│  工具定义 (Tool Definitions)              │
│  工具返回结果 (Tool Outputs)              │
│  安全约束 (Safety Constraints)            │
│  用户指令 (User Prompt)  ← Prompt Eng 的领地│
└──────────────────────────────────────────┘

Prompt Engineering 优化的只是最底部那一小块。Context Engineering 负责的是整个窗口的组装逻辑——什么信息放进去、什么信息挤出去、以什么顺序排列、怎么压缩历史、怎么注入检索结果。

3.2 核心技术

上下文压缩：长对话中，每轮的历史消息不能全部保留。常见策略是对早期消息做摘要（Summarization），只保留最近几轮的原始内容。摘要本身也可以由模型自动生成。

检索注入：RAG（Retrieval-Augmented Generation）的本质就是 Context Engineering 的一种实现——从外部知识库检索相关文档，注入到上下文窗口中，让模型"看到"它训练时没见过的信息。

多上下文提示：在超长会话中，将上下文分成多个窗口分别处理，再合并结果。这类似于操作系统的分页机制——RAM 不够用时把数据换出到磁盘，需要时再换入。

结构化上下文：用 Markdown 标题、XML 标签等方式组织上下文结构，帮助模型区分不同来源的信息。Anthropic 的实践表明，结构良好的上下文比扁平的文本堆砌效果显著更好 $TRAE_REF。

3.3 Context Engineering 的工程挑战

上下文窗口是有限且昂贵的资源。每多注入一个 Token，就多一份推理成本，也可能稀释关键信息的注意力。Context Engineering 的核心矛盾是：在有限的窗口内，提供刚好够用的信息，不多不少。

这与内存管理的逻辑完全一致——RAM 是有限的，你需要决定什么常驻、什么换出、什么预加载。不同的是，内存管理的对象是字节，Context Engineering 的对象是语义信息，"什么是相关的"本身就是个模糊判断。

四、Harness Engineering：让 Agent 可靠运行的一切外部系统

4.1 定义

Harness（缰绳/控制框架）是围绕 AI Agent 构建的一套完整基础设施系统，负责管理 Agent 的整个生命周期：它能访问哪些工具、遵守什么约束、如何自我纠正、人类如何监控它的行为 $TRAE_REF。

核心公式：

Agent = Model + Harness

模型提供推理能力，Harness 提供一切使其可靠执行的环境和约束。Harness 不是 Agent 本身，而是让 Agent 可靠运行的一切外部系统。

来自 Philipp Schmid 的类比：

计算机概念	AI Agent 对应
CPU（原始处理能力）	模型
RAM（有限工作记忆）	上下文窗口
操作系统（管理资源、调度任务）	Harness
应用程序	Agent

4.2 六大核心支柱

支柱	解决什么问题	关键实践
上下文架构	模型上下文窗口有限且跨会话遗忘	摘要、多上下文提示、`AGENTS.md`/`CLAUDE.md` 注入
工具编排	工具选择过多导致混乱	Vercel 移除 80% 工具后任务完成率反而提升
状态管理	多会话多步骤的进度持久化	跨会话状态存档、任务队列、依赖管理
验证与纠错	模型会犯错且自己意识不到	自动测试套件、自我验证循环、失败时反馈而非重试
人机协作	Agent 需要人类监督但不能事事打扰	分级审批：低风险自动执行，高风险需确认
生命周期管理	Agent 从启动到完成的系统化管理	启动/暂停/恢复/终止、多 Agent 编排、检查点

4.3 一个关键洞察：约束即能力

Vercel 在构建 v0 编码 Agent 时，移除了 80% 的可用工具，结果反而显著提升了任务完成率 $TRAE_REF。更多工具 = 更多困惑 = 更多失败。

工具编排的本质不是"给 Agent 更多能力"，而是"在正确时机提供正确的能力"。这与人类的工作直觉一致——给你一张写满 100 个按钮的控制面板，不如给你 5 个常用按钮加一个"更多"入口。

4.4 Harness 的三种形态

类型	描述	代表
代码型	用编程语言实现的完整运行时框架	LangGraph、OpenAI Codex Harness
Markdown/Prompt 型	将编排指令嵌入系统提示或 Markdown 文件	Anthropic 的 `CLAUDE.md` / `AGENTS.md`
混合型	结合代码运行时与自然语言规则	Claude Code、Cursor

模型可替换，Harness 才是产品。 两个使用相同 Claude/GPT 模型的团队，仅因 Harness 质量差异，任务完成率可相差 40 个百分点 $TRAE_REF。

五、Loop Engineering：让 Agent 自己跑到目标

5.1 定义

Loop Engineering 是设计智能体工作流（循环）的实践，让 AI Agent 迭代地朝用户定义的目标推进，最小化人工干预 $TRAE_REF。

Prompt Engineering 是人工编写提示词、评估结果、再写下一轮提示词。Loop Engineering 是设计自动化系统，让 Agent 自己提示自己、评估自己的工作，直到达成目标。

5.2 循环的四阶段

┌──────────────────────────────────┐
│         ① 目标 (Goal)             │
│  递归评估：是否达成？未达成则继续    │
└──────────┬───────────────────────┘
           ▼
┌──────────────────────────────────┐
│         ② 行动 (Action)           │
│  生成代码 / 运行测试 / 修复 Bug    │
└──────────┬───────────────────────┘
           ▼
┌──────────────────────────────────┐
│       ③ 观察 (Observation)        │
│  CI 测试通过？编译成功？输出正确？  │
└──────────┬───────────────────────┘
           ▼
┌──────────────────────────────────┐
│       ④ 调整 (Adjustment)         │
│  根据反馈修改方法，回到 ①          │
└──────────┬───────────────────────┘
           │
           └────→ 循环直到目标达成

关键设计点：目标必须包含可验证的终止条件。"让网站加载更快"是模糊的，"当代码通过所有单元测试且满足需求时停止迭代"是可验证的 $TRAE_REF。

5.3 循环的核心组件

组件	作用
自动化/调度	确定循环的节奏，如 cron job、GitHub Actions
Hooks	事件触发的指令，如提交前自动检查代码规范
上下文工程	压缩历史轮次、结构化当前上下文
工具访问	通过 MCP 等协议让 Agent 操作外部系统
Worktrees	Git 工作树，让多个 Agent 并行不冲突
Skills	任务特定的项目知识，可跨项目复用
Subagents	主 Agent 委派专用子 Agent（研究、实现、验证）
Spine	持久化状态/记忆，跟踪项目进度，防止错误重复

5.4 Maker/Checker 模式

好的 Loop Engineering 不让干活的人自己验收。典型模式是派一个实现 Agent 写代码，再派一个独立的验证 Agent 审查代码。虽然多花 Token，但独立验证 Agent 有自己的指令上下文，质量保证效果远好于自我检查 $TRAE_REF。

5.5 循环的风险：四种"认知陷阱"

IBM 在 Loop Engineering 的讨论中提出了四个值得警惕的概念 $TRAE_REF：

未验证代码（Unverified Code）：检查器仍然是 Agent，人类对最终交付的代码负有责任
理解债（Comprehension Debt）：系统中代码总量与人类理解程度之间的差距，随着 Agent 写的代码增多而被动积累
意图债（Intent Debt）：如果不显式记录开发意图，Agent 可能朝错误的目标优化
认知投降（Cognitive Surrender）：人类不加质疑地接受 Agent 的输出，将判断力外包给 AI

这四种风险都需要 human-in-the-loop 机制来对冲。

六、Graph Engineering：让一群 Agent 稳定协作

6.1 定义

Graph Engineering 是用"节点 + 边 + 状态"来编排多个 AI Agent 协作的方法论 $TRAE_REF。节点负责执行任务，边决定下一步走哪个节点，状态记录整个流程的进度和产物。

6.2 本质：工作流编排的 AI 化

如果做过后端，这套东西并不陌生 $TRAE_REF：

工作流引擎（Activiti、Flowable、Camunda）：BPMN 流程图就是 graph——节点是审批环节或服务调用，边是流转条件，状态是流程实例的上下文
DAG 任务调度（Airflow、DolphinScheduler）：任务依赖关系就是有向无环图，Fan-out（一个任务分出多个并行子任务）和 Fan-in（多个子任务汇合）
微服务编排（Saga 长事务、Spring StateMachine）：把复杂流程拆成节点，用边控制走向

Graph Engineering 干的事，本质就是把这些后端工作流编排的思路套到 AI Agent 协作上。LangChain 在《3 Years of Graph Engineering with LangGraph》中指出，他们三年前就在做这件事——只是那时还不叫这个名字。

6.3 Loop 与 Graph 的关系

“Loop Engineering 已死"是 AI 圈的标准开场白，别急着焦虑 $TRAE_REF。Loop 没有死，它从"整个系统"缩小成了"图里的一个节点内部”：

维度	Loop Engineering	Graph Engineering
管辖范围	单个 Agent 内部	多个执行单元之间
解决问题	怎么让一个 Agent 反复思考、自检、修正	怎么拆任务、谁先做谁后做、怎么并行汇合
典型形态	一个 Agent 跑到目标达成为止	后端+前端+测试三路并行，跑完合并验收
类比	一个工位上的老师傅自己琢磨	整条流水线的调度员

一个 Loop 就是一个极简的 Graph——只有一个节点，边往自己身上拐。反过来，Graph 里那些 Agent 节点内部，跑的还是 Loop 的那套思考循环。两者是单兵与编队的关系，不是替代关系。

6.4 什么时候该上 Graph

只有当任务满足"可拆分 + 有依赖关系 + 需要并行或人工卡点"这三条里的至少两条，才值得动用 Graph 编排 $TRAE_REF：

场景特征	用 Loop	用 Graph
任务线性、步骤明确	合适	过度设计
能拆成互相独立的子任务，要压总耗时	不合适	合适
不同环节要不同模型/工具/权限	不合适	合适（干活节点可写、审查节点只读）
中间必须人工审批才能继续	勉强	合适
跑断了要能从断点续跑、单独返工某一路	难	合适（靠状态存档）

强行给一个"一下午能干完的活儿"上 Graph 编排，等于一个人能做的事非要开个项目启动会。

6.5 落地工具

Graph Engineering 是设计方法，不是某个框架的专利：

LangGraph：LangChain 开源的 Agent 编排框架，用节点、边、状态三件套把多个 LLM 调用串成可执行的图
AutoGen：微软的多 Agent 对话框架
Google ADK：Google 的 Agent 开发套件
Claude Code subagent + workflow：通过内置的 subagent 充当节点，hook 强制检查，workflow 拆任务

七、五个工程的递进逻辑：每一步都在解决上一步的瓶颈

回顾这五个工程的演进，每一步的诞生都有明确的驱动力：

Prompt Engineering
  │ 瓶颈：只优化了上下文窗口的 5%，其余 95% 无人管理
  ▼
Context Engineering
  │ 瓶颈：上下文管理好了，但 Agent 在生产环境中还会崩溃（工具误用、权限越界、无限循环）
  ▼
Harness Engineering
  │ 瓶颈：Agent 有了可靠的运行时，但只能执行单次任务，无法自主迭代到目标
  ▼
Loop Engineering
  │ 瓶颈：一个 Agent 跑得再好，任务一大就需要并行、需要分工、需要断点续跑
  ▼
Graph Engineering

这个演进链路的底层逻辑是：模型的推理能力已经足够强，瓶颈从"模型能不能做"转移到了"工程能不能让模型可靠地、大规模地、协作地做"。

OpenAI 的实践印证了这一点：他们用 AI Agent 零人工编写代码，5 个月内构建了超过 100 万行生产级应用 $TRAE_REF。这 100 万行代码的背后，不是模型有多聪明，而是 Harness、Loop 和 Graph 工程把模型的产出可靠地组织成了产品。

八、实践选型：不要追概念，看场景

你的场景	该用什么
写一个一次性的 SQL 查询生成器	Prompt Engineering
构建一个 RAG 知识库问答系统	Context Engineering（检索注入 + 上下文压缩）
开发一个能在生产环境运行的 AI 编码助手	Harness Engineering（工具编排 + 验证循环 + 人机协作）
让 Agent 自主修复一个复杂 Bug	Loop Engineering（目标 → 行动 → 观察 → 调整）
多 Agent 协作开发一个完整功能（前端+后端+测试并行）	Graph Engineering（节点拆分 + 并行调度 + 断点续跑）