2026 年中AI 工程圈掀起了一轮密集的造词运动。Prompt Engineering 还没讲完Context Engineering 就来了Context Engineering 还在消化Harness Engineering 冒出来了Harness 刚搞明白Loop Engineering 和 Graph Engineering 又开始打架甚至有人喊出Loop Engineering 已死。看起来眼花缭乱但这五个概念之间不是并列关系而是一条清晰的演进链路从优化一次对话的指令到编排一群 Agent 的协作图。每一步都在解决上一步的瓶颈。这篇笔记把五个工程的概念、边界、核心技术和它们之间的递进关系一次梳理清楚。一、演进全景五个工程不是并列是递进先给结论这五个工程的关系可以用一个公式概括Agent 系统 Graph(节点编排) 节点 Loop(自循环) 循环宿主 Harness(运行时) 运行时核心 Context(上下文) 上下文入口 Prompt(指令)从外到内每一层包裹着下一层层级工程核心问题工作单元类比L1Prompt Engineering怎么跟模型说话单条指令给 CPU 发一条指令L2Context Engineering给模型看什么整个上下文窗口往 RAM 里装什么数据L3Harness Engineering让模型在什么环境下跑Agent 运行时操作系统L4Loop Engineering让一个 Agent 自己跑到目标执行-验证-修正循环一个工位上的老师傅自己琢磨L5Graph 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_REFLLM 是 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只保留最近几轮的原始内容。摘要本身也可以由模型自动生成。检索注入RAGRetrieval-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应用程序Agent4.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 HarnessMarkdown/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 ActionsHooks事件触发的指令如提交前自动检查代码规范上下文工程压缩历史轮次、结构化当前上下文工具访问通过 MCP 等协议让 Agent 操作外部系统WorktreesGit 工作树让多个 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、CamundaBPMN 流程图就是 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 EngineeringGraph Engineering管辖范围单个 Agent 内部多个执行单元之间解决问题怎么让一个 Agent 反复思考、自检、修正怎么拆任务、谁先做谁后做、怎么并行汇合典型形态一个 Agent 跑到目标达成为止后端前端测试三路并行跑完合并验收类比一个工位上的老师傅自己琢磨整条流水线的调度员一个 Loop 就是一个极简的 Graph——只有一个节点边往自己身上拐。反过来Graph 里那些 Agent 节点内部跑的还是 Loop 的那套思考循环。两者是单兵与编队的关系不是替代关系。6.4 什么时候该上 Graph只有当任务满足可拆分 有依赖关系 需要并行或人工卡点这三条里的至少两条才值得动用 Graph 编排 $TRAE_REF场景特征用 Loop用 Graph任务线性、步骤明确合适过度设计能拆成互相独立的子任务要压总耗时不合适合适不同环节要不同模型/工具/权限不合适合适干活节点可写、审查节点只读中间必须人工审批才能继续勉强合适跑断了要能从断点续跑、单独返工某一路难合适靠状态存档强行给一个一下午能干完的活儿上 Graph 编排等于一个人能做的事非要开个项目启动会。6.5 落地工具Graph Engineering 是设计方法不是某个框架的专利LangGraphLangChain 开源的 Agent 编排框架用节点、边、状态三件套把多个 LLM 调用串成可执行的图AutoGen微软的多 Agent 对话框架Google ADKGoogle 的 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 自主修复一个复杂 BugLoop 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 协作从优化指令到编排系统这条演进路线是确定的。