最近半年，围绕 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。
| 项目 | 说明 |
|---|---|
| 内容类型 | AI Agent 基础概念与系统原理 |
| 适合读者 | 会使用 ChatGPT、Codex 或 Claude，但还分不清 Context、Harness、Loop 和 Graph 的读者 |
| 前置要求 | 不要求会写 Agent 框架，不要求了解 LangGraph |
| 阅读时间 | 速读约 8 分钟，完整阅读约 15-20 分钟 |
| 跟做时间 | 约 20-30 分钟 |
| 可带走产物 | Agent 四层诊断卡、Context Packet、Loop Contract 和升级决策表 |
| 资料核对日期 | 2026-07-24 |
| 事实范围 | OpenAI、Anthropic 与 LangGraph 官方资料用于解释已有实现；四层模型是本文的教学整理，不是行业标准 |
先说明边界
Context Engineering和Harness Engineering已经进入多家模型厂商的工程讨论；Loop Engineering与Graph Engineering的使用方式仍更偏社区实践标签。不同团队会把其中一部分合并到“Agent architecture”“orchestration”或“runtime”里。因此，本文提供的是一张便于理解和排错的地图，不是在宣布统一术语。
一分钟概览
如果只记住六句话，可以保存下面这些：
- 模型不会自动知道你的项目；它只能根据当前推理请求中可见的信息做判断。
- Prompt 是 Context 的一部分，Context 还包括规则、文件、历史、工具说明、实时证据和中间状态。
- Harness 不是更长的 Prompt，而是围绕模型搭建的运行环境、工具接口、权限边界、状态与反馈设施。
- Loop 是 Harness 中反复发生的“推理 → 调工具 → 读取结果 → 再判断”，必须有验证和停止条件。
- Graph 不会替代 Loop；它负责组织多个 Agent、函数、验证器和人工节点，其中很多节点内部仍在运行 Loop。
- 遇到失败先判断缺的是信息、行动能力、反馈闭环还是协作结构，不要一开始就增加 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 组成 | 在这个 Bug 中的例子 |
|---|---|
| 系统与项目规则 | 不能覆盖用户现有修改；修改后必须运行 Lint |
| 用户目标 | 恢复分类下拉选项 |
| 当前环境 | 工作目录、操作系统、当前分支 |
| 项目知识 | AGENTS.md、目录结构、数据模型 |
| 任务文件 | 下拉组件、分类 API、表单状态代码 |
| 实时证据 | 页面截图、控制台错误、网络请求响应 |
| 工具说明 | 如何搜索文件、控制浏览器、运行测试 |
| 过程状态 | 已排除哪些假设、刚修改了什么、测试是否通过 |
因此：
Context ≠ Prompt
Context = 指令 + 任务材料 + 项目知识 + 工具定义
+ 实时观察 + 历史结果 + 当前状态
2.2 好 Context 不是“越多越好”
上下文窗口有限，更重要的是注意力也有限。
把整个仓库、所有聊天记录和几十页规范一次性塞进去，会出现三个问题：
- 相关信息被淹没。 真正决定 Bug 的三段代码与数百个无关文件拥有相似的视觉权重。
- 旧信息与新事实冲突。 文档说分类来自静态配置，代码已经改成数据库查询。
- 过程噪声不断累积。 每次失败的完整日志都被保留，后续判断越来越困难。
所以 Context Engineering 的核心动作不是“添加”，而是下面这组循环：
选择 → 组织 → 注入 → 使用 → 压缩或丢弃 → 再补充
图 2：Context Packet 不是资料仓库的副本，而是为“下一步决定”筛选出的最小充分信息。
我会用五个问题检查一份 Context：
| 问题 | 判断标准 |
|---|---|
| 相关吗 | 它会改变下一步判断吗？ |
| 够用吗 | 是否缺少做出决定所需的关键证据？ |
| 新鲜吗 | 它描述的是当前代码和当前状态吗？ |
| 可信吗 | 是运行结果、官方规范，还是未经验证的猜测？ |
| 节省吗 | 能否用摘要、索引或按需读取代替整份注入？ |
2.3 Context Engineering 解决不了什么
即使把相关组件、API 响应和错误日志都给模型看，它仍然可能只能告诉你：
“可能是请求没有触发，建议检查
useEffect的依赖。”
它还没有真正打开文件、修改代码、运行测试或重新操作浏览器。
Context 让模型看得更清楚，但不自动给它手、工作台和安全边界。
这就进入 Harness Engineering。
3. Harness Engineering：给模型一套可行动的工作环境
Harness 原本就有“把能力连接、约束并投入使用的装置”这一含义。在 Agent 语境中，可以把它理解成模型外面的运行系统。
OpenAI 的 Harness Engineering 实践强调了几类工作：让仓库知识对 Agent 可读，提供可以直接使用的工具和可观察信号，用规则与测试机械地约束边界，并把失败反馈重新编码进环境。
一个简化 Harness 通常包含：
Context Builder 选择本轮给模型什么
Tool Registry 定义模型能调用什么
Executor 真正执行命令、浏览器操作或 API 调用
Sandbox/Approval 限制能读写哪里，何时需要人工批准
State Store 保存会话、计划、中间产物和检查点
Observation 把文件、日志、截图和测试结果返回给模型
Compaction 控制长任务中的上下文增长
Tracing/Evals 记录过程，并判断系统是否真的变好
图 3：模型负责在当前 Context 下做决定；Harness 负责准备输入、执行动作、限制权限并返回真实观察。
3.1 Harness 不是工具数量
给 Agent 接入 100 个工具，不等于 Harness 设计得好。
一个有用的工具至少要做到：
- 名称和描述能让模型判断什么时候调用；
- 输入输出有稳定结构，而不是难以解析的一大段文本；
- 失败时返回可恢复的信息；
- 权限范围明确；
- 结果能再次进入 Context；
- 高风险动作不能只靠模型“自觉谨慎”。
回到分类下拉 Bug，一个最低可用的编码 Harness 可能只需要：
读文件、搜索代码、修改文件
运行开发服务器和测试
控制浏览器并查看页面
读取控制台与网络请求
限制工作目录
保留 Git diff
工具不算多，但已经形成了完整工作面。
3.2 Context 与 Harness 的关系
这两个概念会重叠，因为 Harness 负责构建和维护 Context。
可以这样区分：
Context Engineering 关心：下一次判断应该看见什么？
Harness Engineering 关心：谁来准备这些信息，怎样行动，边界在哪里？
例如：
AGENTS.md的内容属于 Context；- Harness 负责发现并按作用域加载
AGENTS.md； - 测试输出属于 Context；
- Harness 负责执行测试、截断噪声并返回退出码；
- 浏览器截图属于 Context；
- Harness 负责启动页面、控制浏览器和保存截图。
3.3 Harness 仍然不等于任务完成
现在 Agent 已经有工具了，但如果运行方式是：
看一眼代码 → 修改一个文件 → 宣布完成
它依然可能没有复现 Bug，也没有确认修复是否有效。
工具只是能力。要让能力围绕目标持续工作，还需要 Loop。
4. Loop Engineering：让行动获得反馈并收敛
Agent Loop 是 Agent 最核心的运行机制之一。
OpenAI 对 Codex Loop 的简化描述是：
用户输入
↓
模型推理
↓
输出最终回答，或请求工具调用
↓
Harness 执行工具
↓
工具结果进入新的模型输入
↓
继续推理
这个过程可能在一次用户对话回合中重复很多次。
但从工程角度看，“模型还在调用工具”只是最小循环。一个可靠的任务 Loop 还应该有目标、状态、验证和停止条件：
Observe → Decide → Act → Observe → Verify
↑ ↓
└── Retry ──┘
↓
Stop / Escalate
图 4：Loop 的价值不在“多跑几轮”，而在每轮都获得新证据，并能够通过、重试或升级给人工。
4.1 一个可收敛的 Bug 修复 Loop
分类下拉问题可以被组织成：
- Observe： 在浏览器复现下拉为空，记录控制台和网络请求。
- Decide： 根据证据定位数据是否没有请求、请求失败或渲染被过滤。
- Act： 做最小修改。
- Observe： 重新加载页面，读取新的请求与 DOM。
- Verify： 分类选项可见；已有分类能正确回显；Lint 与构建通过。
- Stop： 验收条件全部满足。
- Retry： 若失败，只根据新证据修正假设。
- Escalate： 需要生产数据、账号权限或产品决策时交还给人。
这里最重要的不是步骤数量，而是每轮必须产生信息增量。
4.2 四种看似在循环、实际没有进展的情况
重复同一个猜测。
没有新增日志、文件或测试结果，只是换一种说法再次尝试。
用作者身份自我验收。
同一段上下文刚写完代码，马上说“看起来没问题”，却没有运行真实检查。
没有停止条件。
即使验收已经通过，仍继续重构和润色；或者连续失败后也不升级给人。
把动作次数当成质量。
调用了 30 次工具不代表比 5 次更可靠。关键是证据是否减少了不确定性。
因此，一个简单的 Loop Contract 应该提前写出：
goal: 分类下拉恢复可选项
observe:
- 页面 DOM
- 控制台错误
- 分类接口响应
act:
- 只修改与根因直接相关的文件
verify:
- 至少出现一个分类选项
- 编辑已有文章时分类正确回显
- lint 和 build 通过
stop:
success: 所有 verify 条件通过
failure: 连续两轮没有新证据
escalate:
- 需要生产数据库权限
- 现有产品规则互相冲突
4.3 Loop Engineering 解决不了什么
单 Loop 很适合目标明确、上下文相对统一、修改范围可控的任务。
但如果任务变成：
同时检查前端表单、后台分类 API、历史数据迁移和线上权限配置；各部分要独立验证，最后才能发布。
一个 Agent 把所有内容塞在同一段历史里，会开始面临：
- 不同子任务互相污染上下文；
- 有些工作可以并行，却被迫串行；
- 同一个角色既实现又验收；
- 发布必须等待多个真实依赖；
- 某个分支失败后，不清楚应该重跑哪里。
这不是“再循环几轮”就一定能解决的问题。此时才需要考虑 Graph。
5. Graph Engineering：组织多个局部 Loop
Graph Engineering 关注的不再只是一个 Agent 下一步做什么，而是：
有哪些独立职责？
它们之间的真实依赖是什么？
每个节点读取和写入什么状态？
谁负责验证？
失败后重跑哪个局部？
哪个动作必须等待人工批准？
一张 Agent 工作图可以包含：
- 会调用模型和工具的 Agent 节点；
- 只执行脚本的确定性函数；
- 测试、静态分析和策略校验器；
- 等待人工判断的批准节点；
- 多个节点之间传递的结构化状态；
- 节点内部各自运行的 Loop。
图 5：Graph 增加的是职责与依赖结构。研究、实现和验证节点可以各自有局部 Loop，发布仍由明确闸门控制。
5.1 Graph 不是“多开几个 Agent”
假设我们把分类 Bug 拆成三个 Agent：
Agent A：检查前端
Agent B：检查 API
Agent C：检查数据库
如果三个 Agent：
- 收到完全相同的模糊任务；
- 不知道彼此输出格式；
- 下游不消费上游结果；
- 最后由第四个 Agent随意拼接；
这只是并发聊天，不是一张工程化工作图。
Graph 至少要把依赖写清楚：
Reproduce
├── Frontend diagnosis ─┐
├── API diagnosis ──────┼── Root-cause verifier
└── Data diagnosis ─────┘
↓
Minimal fix
↓
Browser + CI verify
↓
Human release gate
而且，这个图是否值得存在，要由任务决定。
对于一个只涉及前端状态初始化的小 Bug，单 Agent Loop 通常更简单、更快。只有当检查确实独立、上下文需要隔离、依赖必须显式管理或风险需要独立验证时，Graph 才开始提供净收益。
5.2 Graph 与 Loop 的准确关系
可以把二者想成时间控制与结构控制：
Loop：同一个职责怎样随时间反复行动，直到停止。
Graph：多个职责怎样按依赖、路由和权限互相连接。
所以，不要把二者理解成：
错误：Graph 比 Loop 更高级，因此应该取代 Loop。
更准确：
Graph = 节点与依赖的组织结构
+ 节点内部的局部 Loop
+ 确定性函数、验证器和人工节点
简单任务完全可以只有一个 Loop，没有 Graph；Graph 中也并非每个节点都需要模型。
6. 把四层放回同一张系统图
现在可以给四层一个更精确的位置：
| 层 | 主要控制对象 | 核心问题 | 常见产物 | 典型失败 |
|---|---|---|---|---|
| Context | 信息 | 下一步该看见什么 | Prompt、Context Packet、索引、摘要、记忆 | 缺信息、信息过期、噪声过多 |
| Harness | 执行环境 | 怎样安全地观察和行动 | 工具、Sandbox、Approval、状态、Trace、Evals | 工具不可用、权限失控、结果不可读 |
| Loop | 时间与反馈 | 怎样持续行动并停止 | 状态机、重试、验证器、停止条件 | 无限重试、无验证、没有信息增量 |
| Graph | 职责与依赖 | 多个局部过程怎样协作 | 节点、边、共享状态、路由、人工闸门 | 假依赖、写入冲突、并发污染、成本失控 |
这四层不是严格的代码目录。实际框架常把它们混在一起：
- Codex CLI 的 Harness 内部实现 Agent Loop，也管理 Context；
- LangGraph 用 State、Node 和 Edge 表示工作流，但每个节点内部仍可调用一个完整 Agent；
- Claude Code 的工具、权限、Skills 和上下文压缩属于 Harness 的不同部分；
- 一个普通脚本也可以成为 Graph 节点，不需要模型参与。
文章把它们拆开，是为了排错时能问对问题。
7. 同一个 Bug，四层分别做了什么
下面把分类下拉 Bug 从头走一遍。
只有 Prompt
修复分类下拉没有选项的问题。
模型只能依据常见经验猜测。输出可能合理，但没有项目证据。
加入 Context
目标：恢复分类下拉选项。
页面：/admin/posts
现象：下拉展开后只有搜索框，没有选项。
相关材料：截图、表单组件、分类接口响应、项目规则。
验收：已有分类可选择，编辑文章能正确回显。
模型可以形成更贴近项目的判断，但仍可能只给建议。
放进 Harness
Agent 现在能够：
- 打开真实页面；
- 搜索组件和 API；
- 读取请求结果；
- 修改工作区文件；
- 运行 Lint 和构建；
- 在越权或生产操作前请求批准。
模型从“顾问”变成能在受控环境中行动的执行者。
运行 Loop
Agent 按“复现 → 定位 → 修改 → 重新加载 → 验收”循环，直到通过或触发停止条件。
任务开始具备闭环。
是否升级 Graph
先问：
- 是否真的有多个能独立推进的子任务？
- 是否需要上下文隔离？
- 是否存在必须等待的真实依赖？
- 是否需要独立验证或人工发布权？
如果答案都是否，停在单 Loop 就够了。
这一步很关键：四层地图不是让你每次都把系统搭到第四层，而是帮助你停在刚好够用的位置。
8. Agent 失败时，先诊断哪一层
看到 Agent 失败，很多人的第一反应是换模型、重写 Prompt 或增加 Agent。可以先用下面这张诊断卡。
症状一：回答偏题、遗漏约束、引用旧版本
优先检查 Context：
- 关键文件是否真的进入可见范围；
- 指令是否互相冲突；
- 当前状态是否被旧对话淹没；
- 是否应该按需检索，而不是一次加载所有资料。
症状二：知道该做什么，却无法复现或验证
优先检查 Harness：
- 是否缺浏览器、日志、数据库只读查询或测试工具；
- 工具输出是否稳定可解析；
- 工作目录和权限是否正确；
- Agent 是否能看到真实运行状态。
症状三：改一次就停，或者反复试却不收敛
优先检查 Loop：
- 是否有明确 Verify；
- 每次失败是否带来新证据；
- 是否设置最大轮次、超时和成本；
- 什么时候应该停止并交还给人。
症状四：多个子任务互相覆盖，合并后才发现冲突
优先检查 Graph：
- 边是否代表真实数据依赖；
- 节点是否有清晰输入输出；
- 是否有唯一写入者；
- 验证器是否独立；
- 并行工作区是否隔离。
症状五：信息、工具、循环和结构都合理，结果仍不稳定
这时才更有理由检查：
- 模型是否具备任务所需能力；
- 任务是否本身缺少可判定标准；
- 环境是否存在不可观察的外部状态；
- 是否需要人工专业判断。
框架不能弥补不可判定的问题，更多 Agent 也不会自动创造事实。
9. 三种任务，应该停在哪一层
| 任务 | 建议层级 | 原因 |
|---|---|---|
| 总结一篇已经提供全文的文章 | Prompt + Context | 输入固定，不需要外部行动 |
| 修复一个可本地复现的前端 Bug | Context + Harness + 单 Loop | 需要读代码、改文件、运行与验证 |
| 跨前端、后端和数据迁移完成一次高风险发布 | Graph + 多个局部 Loop + Human Gate | 存在独立职责、真实依赖和不可逆动作 |
还可以用一个更保守的升级顺序：
一次模型调用
↓ 缺少任务信息
补 Context
↓ 需要观察或改变外部世界
加 Harness
↓ 需要根据结果继续行动
设计 Loop
↓ 出现多个独立职责、依赖或治理边界
设计 Graph
每次升级都会带来成本：
| 升级 | 新收益 | 新成本 |
|---|---|---|
| 更多 Context | 判断更有依据 | Token、噪声、过期信息 |
| 更强 Harness | 可以真实行动 | 权限、安全、维护、可观测性 |
| 更长 Loop | 可以纠错和验证 | 时间、费用、漂移、停止困难 |
| 更复杂 Graph | 并行、隔离、治理 | 调度、状态、合并、调试复杂度 |
如果说不清新增收益，就先不要升级。
10. 四个可以直接复用的最小模板
10.1 Context Packet
# Task Context
## Goal
最终要改变什么？
## Current State
现在观察到了什么？
## Relevant Sources
哪些文件、日志、接口或文档直接影响判断？
## Constraints
哪些内容不能改？权限和风险边界是什么？
## Acceptance
用什么真实信号证明完成？
## Open Questions
还缺哪些信息？哪些只是猜测？
10.2 Harness Checklist
- [ ] Agent 能读取必要输入
- [ ] Agent 能观察真实运行状态
- [ ] 工具输入输出稳定且可解析
- [ ] 写入范围受到限制
- [ ] 高风险动作需要批准
- [ ] 每个动作都能返回结果
- [ ] 日志和 Trace 不泄露敏感信息
- [ ] 失败可以恢复或安全停止
10.3 Loop Contract
Goal:
Observe:
Decide:
Allowed Actions:
Verify:
Retry With New Evidence:
Success Stop:
Failure Stop:
Escalate To Human:
Budget:
10.4 Graph Upgrade Questions
1. 是否有至少两个真正独立的职责？
2. 并行是否能带来可测量收益？
3. 下游是否真的消费上游输出？
4. 是否需要隔离上下文或工作区？
5. 是否需要独立验证器？
6. 是否存在必须由代码或人工掌握的权力？
7. 单 Agent Loop 的基线问题是什么？
如果第 1、3、7 题都答不清楚，通常还不适合升级 Graph。
11. 五个最常见的概念误区
误区一：Context Engineering 就是长 Prompt
长 Prompt 只是更多文本。Context Engineering 还包括按需检索、状态维护、来源选择、工具结果、压缩和遗忘。
误区二：接入 MCP 就完成了 Harness Engineering
MCP 可以提供工具和资源接口，但 Harness 还要处理执行、权限、状态、反馈、停止、日志和评估。连接能力只是其中一部分。
误区三：Agent 多调用几次工具就是可靠 Loop
如果没有验收标准、预算和信息增量，多轮只是更昂贵的随机游走。
误区四：Graph Engineering 必然等于多 Agent
Graph 节点可以是普通函数、测试、检索、人工审批或单个 Agent。很多可靠工作图会刻意把确定性判断留给代码。
误区五：层级越高，系统越先进
一个稳定的单 Loop 往往比一张依赖不真实、状态不清楚的多 Agent 图更可靠。复杂度只有在解决具体约束时才有价值。
12. 20 分钟练习：给自己的任务画四层地图
选一个你最近真的会交给 Codex 或 Claude Code 的任务，例如：
给博客增加文章搜索
修复登录后的跳转问题
整理一份带引用的行业调研
把重复发布流程做成 Skill
然后完成四步。
第一步：只写 Context
列出目标、当前状态、相关资料、约束和验收标准。
删除所有“看起来有用、但不会改变下一步判断”的材料。
第二步：画 Harness 边界
写出 Agent 必须观察和调用的工具，以及明确禁止的操作。
至少保留一个真实验证信号。
第三步：写 Loop Contract
明确每一轮怎样获得新证据，什么情况通过、失败或升级给人。
把最大轮次或时间预算写出来。
第四步：尝试不使用 Graph
先问单 Agent Loop 能否完成。
只有发现上下文隔离、真实并行、独立验证或权限治理需求时，才画节点和边。
练习完成后，你应该能用一句话解释自己的系统：
我给 Agent 的 Context 是 ______；
Harness 允许它 ______，禁止它 ______；
Loop 通过 ______ 判断继续或停止；
目前不需要 / 需要 Graph，因为 ______。
如果这四个空都能填清楚，概念就已经从名词变成了设计判断。
13. 收藏清单
最后把全文压缩成一张检查表。
Context
- 模型是否看到了完成下一步所需的最小充分信息？
- 信息是否相关、当前、可信，并且没有被噪声淹没？
Harness
- Agent 是否有观察、行动和验证所需的工具？
- 权限、Sandbox、批准和敏感信息边界是否明确？
Loop
- 每轮是否产生新证据？
- 是否有验证、预算、停止和人工升级条件？
Graph
- 是否存在真实独立职责和依赖？
- 节点输入输出、写入权、验证器和人工闸门是否清楚？
总原则
缺信息，先修 Context。
不能行动，检查 Harness。
不能收敛，设计 Loop。
协作失控，再考虑 Graph。
如果你已经能分清这四层，下一步可以阅读更深入的《Graph Engineering：从单 Agent 循环到可验证的工作图》。那篇文章会继续讨论真实依赖、Diamond Pattern、共享状态、独立验证器、预算、并发隔离和人工闸门。
参考资料
官方资料
- Anthropic：Effective context engineering for AI agents
- Anthropic：Building effective agents
- OpenAI：Unrolling the Codex agent loop
- OpenAI：Harness engineering: leveraging Codex in an agent-first world
- OpenAI：Unlocking the Codex harness
- LangChain：Context engineering in agents
- LangGraph：Graph API overview
延伸说明
- 本文四层模型是为了教学和故障定位做的归纳，不是上述厂商共同发布的标准。
Graph Engineering的术语来源、社区讨论和框架映射，已经在进阶篇中单独整理。