验证不跑，改 prompt 也没用：agent 栈四层，harness 在最外层
Prompt、context、loop 和 harness 工程是四个不同的层。本指南绘制这组栈，说明每个杠杆位于哪里，并指向 Claude Code、MCP（Model Context Protocol）与生产级 agent 设计的深入材料。
Context engineering、Loop engineering、Harness engineering = 对“Prompt engineering”的升级。
它们不能互换。它们是同一栈的四个层，每层的工作单元、失败模式和工具都不同。
Prompt engineering 问：我该如何措辞这条消息？
Context engineering 问：这次调用中模型能看到什么？
Loop engineering 问：哪个自主工作流会重复直到目标达成？
Harness engineering 问：什么代码可靠地运行循环、工具和验证？
混淆它们代价很高。如果 harness 没有验证步骤，团队再怎么重写 prompt 也永远修不好静默失败循环。如果团队构建了复杂 harness 却目标模糊，就会一直烧 token。
同一个模型在不同 harness 下也可能消耗截然不同的 token 总量，但 token 数本身不是质量分数。
本指南绘制完整栈——包含图示、诊断和详细视觉材料。
01. 速览——四层一览
嵌套规则：Harness 实现循环 → 每个循环步骤组装上下文 → 上下文包含 prompt。
02. 栈图
Boris Cherny 谈自验证循环：
Boris Cherny：“Claude Code 里两个最强大的功能：/loop 和 /schedule”：
Andrej Karpathy 谈“上下文工程”：
可以像 Web 开发那样理解：
03. 第 1 层——提示工程（最内层）
Boris Cherny：“我很惊讶，人们居然惊讶我就是这样给 Claude 写 prompt 的。”
定义：优化单条消息的文本，通常是 system prompt 和当前用户轮次，以引导模型产生更好的行为。
技术：思维链、少样本示例、角色设定、JSON schema 指令、temperature 和采样控制、system prompt 结构。
工作单元：一个消息对（system + user），或聊天中的一轮。
示例——提示层修复：
当正确的文档已经在上下文中时，这会改善单次调用。
什么时候提示工程就够了：
- 一次性翻译、分类或格式化
- 在还不知道工作流形状之前的早期原型
- 失败明显是误解指令，而不是缺文件
什么时候不够：
- 模型“不知道”你的代码库 → 上下文问题
- 任务需要 40 次工具调用 → 循环问题
- 工具调用挂起或重复写入 → harness 问题
上下文工程 vs 提示工程：
04. 第 2 层——上下文工程（每次调用）
定义：为每次 API 调用设计模型所依据的完整包。
2026 年中，Karpathy 普及了一个观点：真正的挑战在于策展上下文窗口：
上下文包里有什么
四个上下文杠杆
- 内容选择 = 这个 token 是否配得上它的位置？
- 结构与排序 = 约束优先；文档在用户消息之前
- Token 预算 = 为可变内容保护预算
- 缓存放置 = 稳定前缀（system + tools）放在缓存断点之前
示例——上下文层修复（同一用户消息）
用户消息故意很平淡。质量来自它周围的东西。
上下文工程在 Claude Code 中的体现：
完整栈拆解：
什么时候上下文工程占主导
- RAG（检索增强生成）管线和代码库问答
- 超过约 10 轮的会话（历史污染）
- 工具选择错误（暴露了太多工具）
- 成本/延迟（本该 40k 的 200k 上下文）
05. 第 3 层——循环工程（工作流）
定义：设计自主工作流，决定何时调用模型、必须满足什么目标，以及如何在不靠你逐轮输入的情况下知道运行已完成。
Addy Osmani 在 2026 年 6 月普及了循环工程，建立在 Anthropic 的 Boris Cherny 之上：
“我不再给 Claude 写 prompt 了。我有循环在跑。它们才是给 Claude 写 prompt 并决定做什么的东西。我的工作是写循环。”
Addy Osmani 的指南：
循环里仍然包含 prompt = 每次迭代都有东西生成它们。你不再当那个东西。
循环的五个组件
示例——循环规格（不是 prompt）
没有巧妙的措辞——工作流架构
循环工程 vs 提示工程：
循环失败时（而且不是 prompt 的问题）
06. 第 4 层——Harness 工程
定义：构建或配置执行循环的编排代码：解析模型输出、安全调用工具、管理重试、每轮组装上下文，并强制执行退出条件。
Boris Cherny 和 Anthropic 工程师用 harness 工程来指那些迭代地给 Claude 写 prompt 的系统：观察、计划、行动、反思 => 持续数小时。
Addy Osmani 的指南：
agent harness 是具体的产物：
Harness 组件
为什么在基准测试上 harness 能胜过模型升级
LangChain 的 Deep Agents 团队报告，仅靠 harness 改动就在 Terminal-Bench 2.0 上获得提升 → 底层模型相同。这个模式可以推广：
同一模型上的更好 harness > 更好模型上的同一 harness——对许多 agentic 任务而言
原因：模型只能看到 harness 组装出来的东西，也只能得到 harness 允许的重试。
产品即 harness
07. 这些层如何在一个真实任务中交互
任务：“把我们的 auth 模块迁移到 Clerk，并让所有测试通过。”
Prompt 层：
对玩具仓库有效。对 monorepo 一次性完成会失败。
+ Context 层
加载 CLAUDE.md，包含包管理器、测试命令、auth 文件地图
只通过 grep 检索 apps/web/lib/auth/*——不是整个仓库
只暴露 Edit + Bash(test) 工具
agent 的每次迭代都看到合理的包
+ Loop 层
agent 运行到验证通过 → 而不是直到它说“done”
+ Harness 层
沙箱 bash；阻止 rm -rf
每次编辑后 hooks 运行 lint
每 10 轮 checkpoint git stash
重试瞬时 API 失败
记录每步 token 使用
编辑生产环境文件前人工门禁
生产发布需要四层齐备
08. 诊断——哪一层坏了？
当 agent 表现不佳时用这个：
在层内自底向上修，跨层时先修外层：如果验证从不运行，改 prompt 也没用。
09. 2026 职业地图
提示工程是入场券 → 就像做后端要会 SQL
上下文工程对任何读取你数据的 agent 都是必需的
循环工程在你想要以小时而非秒衡量的自主性时是必需的
Harness 工程在失败有代价时是必需的 → 金钱、数据、声誉
10. 实用学习路径
底线
Prompt、context、loop 和 harness 工程不是同一件事的四个名字。
它们是一个栈的四层：
- Prompt = 消息措辞
- Context = 每次调用的组装
- Loop = 自主工作流
- Harness = 可靠执行
Karpathy 命名了上下文危机。Cherny 命名了循环转变。生产团队在基准提升却没有新模型时，命名的是 harness。
当有人在长运行 agent 上说“我们需要更好的 prompt”时，问：“到底是哪一层在失败？”
答案决定你是改一段文字、重新设计检索、重写目标规格，还是修重试逻辑。
先把层搞对 → 再向内优化。