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（节点拆分 + 并行调度 + 断点续跑） |
核心原则：用能解决问题的最小复杂度。一个 Loop 能搞定的任务不要上 Graph，一个 Prompt 能搞定的任务不要上 Context Engineering。过度工程化的代价是维护成本和调试难度。
九、行业趋势：模型可替换，工程是壁垒
2026 年的 AI 行业有一个越来越清晰的共识：模型之间的性能差距正在缩小，工程能力的差距正在拉大。
头部模型的性能差距已经在 1% 以内，但两个使用相同模型的团队，仅因 Harness 质量差异，任务完成率可以相差 40 个百分点 $TRAE_REF。模型是公共资源，工程是私有壁垒。
这意味着技能重心的转移：从"怎么写好提示词"到"怎么构建让 Agent 可靠运行的环境"。对于组织而言，与其追逐最新的模型，不如投资工程能力——Prompt、Context、Harness、Loop、Graph，这五个层级构成了 AI 工程的完整技能栈。
名字可能还会变。按 AI 圈这个造词速度，再过两个月可能又冒出一个新词。但背后的思想不会消失：从单次对话到多 Agent 协作，从优化指令到编排系统，这条演进路线是确定的。
