从 Context Engineering 到 Graph Engineering：读懂 AI Agent 的四层工程

最近半年，围绕 AI Agent 出现了越来越多带有 Engineering 的词：

Prompt Engineering
Context Engineering
Harness Engineering
Loop Engineering
Graph Engineering

单独看每个词都不难，放在一起却很容易混乱：

• Context Engineering 是不是把 Prompt 写得更长？
• Harness 是一个新框架，还是 Agent 外面的工具箱？
• Loop 是让模型不停重试吗？
• Graph 出现以后，单 Agent 和 Loop 是否已经过时？

我的理解恰好相反：这些概念真正有用的地方，不是创造了一条追逐新名词的路线，而是帮助我们定位 Agent 到底缺了哪一层。

这篇文章是一篇前置概念课。它不会深入讨论状态所有权、并发隔离和图调度算法，而是先建立一张基础地图：

Context 决定模型这一刻能看见什么；Harness 决定它能在什么环境里行动；Loop 决定行动如何持续并收敛；Graph 决定多个局部循环如何协作。

为了避免停留在定义上，全文会反复使用一个基于此前博客后台现象简化出的例子。它用于解释系统分层，不复盘或虚构当时的具体根因：

博客后台的“分类”下拉框没有选项，请让 Codex 找到原因并修好。

我们会逐层观察：只给一句 Prompt 会发生什么，补充 Context 有什么变化，Harness 怎样让模型真正动手，Loop 如何完成验证，最后为什么这个任务通常根本不需要 Graph。

先说明边界

Context Engineering 和 Harness Engineering 已经进入多家模型厂商的工程讨论；Loop Engineering 与 Graph Engineering 的使用方式仍更偏社区实践标签。不同团队会把其中一部分合并到“Agent architecture”“orchestration”或“runtime”里。

因此，本文提供的是一张便于理解和排错的地图，不是在宣布统一术语。

一分钟概览

如果只记住六句话，可以保存下面这些：

1. 模型不会自动知道你的项目；它只能根据当前推理请求中可见的信息做判断。
2. Prompt 是 Context 的一部分，Context 还包括规则、文件、历史、工具说明、实时证据和中间状态。
3. Harness 不是更长的 Prompt，而是围绕模型搭建的运行环境、工具接口、权限边界、状态与反馈设施。
4. Loop 是 Harness 中反复发生的“推理 → 调工具 → 读取结果 → 再判断”，必须有验证和停止条件。
5. Graph 不会替代 Loop；它负责组织多个 Agent、函数、验证器和人工节点，其中很多节点内部仍在运行 Loop。
6. 遇到失败先判断缺的是信息、行动能力、反馈闭环还是协作结构，不要一开始就增加 Agent 数量。

图 1：四层分别增加信息、执行、时间和拓扑控制。它们是包含与协作关系，不是四代互相淘汰的技术。移动端可点击图片放大。

先用一位新同事来理解

如果把模型想成一位刚加入项目、能力不错但不了解现场的新同事：

• Model
  
   是他的通用知识与推理能力；
• Context
  
   是这次任务摆在桌上的需求、代码、规范和现场证据；
• Harness
  
   是电脑、账号、工具、权限、工作区和反馈系统；
• Loop
  
   是“查看现状、动手、检查结果、继续修正”的工作节奏；
• Graph
  
   是多人协作时的职责、交接、依赖和审批关系。

新同事再聪明，没有项目材料也会猜；材料再完整，没有工具和权限也只能提建议；能动手但从不检查，就会把半成品当成完成；只有任务真的需要多人分工时，才值得建立更复杂的协作图。

全文可以先用两个简化公式定位：

Agent ≈ Model + Context + Tools + Loop + Guardrails

Graph ≈ Nodes（Agent / Function / Human）
      + Edges + Shared State + Routing + Gates

公式不是框架定义，只是提醒我们：Agent 已经是模型与运行系统共同形成的行为；Graph 又是在更高一层组织多个执行单元。

1. 先从最小单位开始：一次模型调用

理解这四层之前，要先把“模型”和“Agent”分开。

一次简化的模型调用可以写成：

输入信息 + 模型参数 → 推理 → 文本或工具调用

模型的参数里包含训练得到的通用能力，但它不会凭空知道：

• 你的博客源码放在哪个目录；
• 当前分支是否有未提交修改；
• “分类下拉为空”对应哪个组件；
• 浏览器控制台刚刚报了什么错；
• 项目规定不能直接修改生产数据库；
• 上一次工具调用到底返回了什么。

这些都必须通过当前请求、可访问环境或工具结果进入它的可见范围。

这里有一个常被忽略的事实：Agent 应用可以保存会话和文件，模型本身每次做判断时，仍然只能使用这一次推理实际收到的上下文。

OpenAI 在拆解 Codex agent loop时展示了这个过程：Harness 先组织 instructions、工具定义、用户输入、环境信息和历史结果，再把它们发送给模型；模型要求调用工具后，Harness 执行工具，把结果追加到后续输入，再次请求模型。

所以，模型能力很重要，但“这一轮到底给它看了什么”同样重要。这就是 Context Engineering 的入口。

2. Context Engineering：决定模型此刻看见什么

Anthropic 对 Context Engineering 的定义可以概括为：为模型的下一步推理，策划和维护一组最合适的信息。它不是简单地把所有资料塞进上下文窗口，而是持续做选择。

2.1 Prompt 只是 Context 的一个子集

用户输入：

修复博客后台分类选择没有选项的问题。

这是 Prompt，但它还不是一份足够的工作上下文。

一个编码 Agent 在执行任务时看到的 Context 可能包括：

因此：

Context ≠ Prompt

Context = 指令 + 任务材料 + 项目知识 + 工具定义
        + 实时观察 + 历史结果 + 当前状态

2.2 好 Context 不是“越多越好”

上下文窗口有限，更重要的是注意力也有限。

把整个仓库、所有聊天记录和几十页规范一次性塞进去，会出现三个问题：

1. 相关信息被淹没。
   
    真正决定 Bug 的三段代码与数百个无关文件拥有相似的视觉权重。
2. 旧信息与新事实冲突。
   
    文档说分类来自静态配置，代码已经改成数据库查询。
3. 过程噪声不断累积。
   
    每次失败的完整日志都被保留，后续判断越来越困难。

所以 Context Engineering 的核心动作不是“添加”，而是下面这组循环：

选择 → 组织 → 注入 → 使用 → 压缩或丢弃 → 再补充