2023 年大家研究提示词，怎么开头、加什么咒语、给几个例子。2025 年年中，说法换成了上下文工程。2026 年 2 月出现 Harness 工程，到 6 月又有了 Loop 工程。三年换了四个名字，每换一次，网上都有一批文章宣布上一个过时了。
我读下来的看法是，这四个词说的是同一件事的四层。最里面是你写的那段话，外面依次是模型某一步能看到的全部内容、模型外面的运行环境、驱动整个过程的外层循环。
┌──────────────────────────────────────────── Loop ─┐
│ 谁来发起、什么时候发起、怎么判断结束、失败了怎么办 │
│ ┌───────────────────────────────── Harness ─┐ │
│ │ 工具、权限、沙箱、钩子、验证、记忆文件 │ │
│ │ ┌────────────────────────── Context ─┐ │ │
│ │ │ 这一步模型能看到的全部 token │ │ │
│ │ │ ┌──────────────────── Prompt ─┐ │ │ │
│ │ │ │ 你写下的那段指令 │ │ │ │
│ │ │ └──────────────────────────────┘ │ │ │
│ │ └─────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────┘新的一层出现，是因为模型变强以后，卡住的地方挪到了更外面。里面那层的活并没有消失，给智能体的每一句说明仍然得写清楚。
先是怎么问
2022 年前后的模型指令遵循能力有限，同一个问题换种问法，答案能差很多。那时确实有技巧可学。Google 的研究者在 2022 年发现，让模型先写出推理过程再给答案，多步推理题的正确率会明显上升，后来连一句「一步一步思考」都管用。给几个示例也比用文字描述格式可靠。
用法基本是一问一答。人写一段话，模型回一段话，人把代码复制进编辑器，再自己去跑。能打磨的只有那段话，所以叫提示词工程。
这些技巧现在大多不灵了。推理已经做进了模型，前沿模型对措辞也不再那么敏感，需求讲清楚就够。剩下有用的部分其实就是写作，把背景、目标、约束和验收标准交代明白，和写一份需求文档没什么两样。
然后是给它看什么
模型开始被放进带工具的多轮任务以后，麻烦换了地方。它自己读文件、跑命令、看报错、改代码，修一个 bug 可能要几十次工具调用，每次的结果都堆进对话历史。
到第 37 步，窗口里装的是相关源码，还是三千行跟问题无关的测试日志？你开头交代的「不要改公共接口」还在不在它注意得到的位置？这些比开头那几句话写得多漂亮更能决定结果。
2025 年 6 月，Andrej Karpathy 公开说他更喜欢「上下文工程」这个叫法，意思是把恰好合适的信息放进上下文窗口。9 月，Anthropic 发了一篇长文《Effective context engineering for AI agents》，把它看作提示词工程往前走的一步。文章把上下文当成一笔有限的预算，塞得越满，模型对每一部分的注意越稀。
这一层的手段大多是使用习惯。一个任务开一个会话，快满了主动压缩，搜索和大量读文件交给子智能体去做，只把结论带回来。养成这些习惯花不了多少时间。
再往外是它在什么环境里干活
智能体能稳定跑完几十步，人们就开始交给它更大的活，又碰到一批改提示词、调上下文都解决不了的问题。
Anthropic 在 2025 年 11 月的一篇文章里记过一个现象。让 Claude 连续多个会话做一个大项目，它常常跑完单元测试，或者用 curl 试一下接口，就把功能标成已完成，没在浏览器里真正点过一遍。后来他们让它用浏览器自动化工具像用户一样测试，结果才好起来。
这类问题要靠模型外面那套系统来管，给它哪些工具和权限，在什么沙箱里跑，改完代码自动做哪些检查，项目知识以什么形式放着。这套系统英文叫 harness，原意是马具。Claude Code 的官方文档就用这个词称呼自己，模型负责推理，工具负责行动，Claude Code 是包在模型外面、提供工具并管理上下文的那一层。
这个词流行起来是在 2026 年 2 月。Mitchell Hashimoto（Terraform 和 Ghostty 的作者）2 月 5 日写文章回顾自己怎么开始用 AI，其中一个阶段叫 Engineer the Harness。他的做法是，每发现智能体犯一个错，就花时间从系统上做点什么，让它以后不再犯。六天后 OpenAI 发了《Harness engineering》，讲一个小团队花五个月做出一个内部产品，代码全部由 Codex 生成，人负责设计环境和反馈。
Hashimoto 提到的补救办法大致两类。一类是往 AGENTS.md 里补一句说明，下次会话它就能读到。另一类是写成实际的工具，比如截图脚本、只跑相关测试的脚本。前一种是提醒，它多数时候会照做，偶尔也会漏。后一种写进了流程，每次都会执行。两种都能用的时候，我更愿意选后一种。
最外面是谁来按回车
harness 够好以后，智能体在一次会话里已经相当可靠，排队等着的变成了人。任务要人来发起，结果要人来看，下一步做什么也要人来定。
2025 年 7 月，Geoffrey Huntley 在博客里贴过一行 Bash。
while :; do cat PROMPT.md | claude-code ; done同一个提示词文件被反复喂给智能体。每一轮都是新会话，读规格和待办清单，挑一件事做完，跑测试，提交，退出，下一轮从头再来。他给这个做法起名叫 Ralph，取自《辛普森一家》里那个有点傻的小孩。
一年后的 2026 年 6 月，Addy Osmani 写了《Loop Engineering》，主张别再亲手给智能体写提示词，去设计替你写提示词的那个循环。任务从哪来、做完谁检查、进度记在哪、什么情况下停，都由循环决定。
产品也在往这个方向走。Claude Code 有一个 /goal 命令，设好完成条件后，每个回合结束都由另一个小模型判断条件达成没有，没达成就自动开始下一回合。官方文档建议条件里写清可度量的终点和检查方式，比如测试退出码为 0，再加上一个回合数上限。前面提到的 Anthropic 那篇文章里，智能体要对照一份 JSON 格式的功能清单干活，每项都有测试步骤，它只能改每项的「是否通过」，不许删改条目。团队选 JSON 而不用 Markdown，是因为发现模型不太会乱改 JSON 文件。
这两个例子的共同点是，做完没有由干活的模型自己说了算，而且什么时候停有明确的规则。缺了这两样，循环只会把错误成批地生产出来。
四层放在一起看
| 提示词工程 | 上下文工程 | Harness 工程 | Loop 工程 | |
|---|---|---|---|---|
| 工程对象 | 一段指令 | 模型某一步能看到的全部 token | 模型之外的运行环境 | 驱动智能体的外层流程 |
| 要回答的问题 | 意图说清楚没有 | 这一步该看到什么 | 能做什么，做完怎么检查 | 谁发起，何时停，谁判定 |
| 时间尺度 | 一次调用 | 一次会话，几十到几百步 | 跨会话，长期积累 | 持续运行，按小时或天 |
| 主要产物 | 系统提示词、任务描述 | 压缩和检索策略、记忆文件 | 工具、权限规则、钩子、测试、lint | 调度、任务队列、验证器、停止条件 |
| 出错时的样子 | 答非所问 | 前面的约束被忘掉 | 同样的错反复犯 | 死循环、账单失控、结果没人看 |
越往外，出错越不容易被发现，代价也越大。提示词写得不好，答案当场就不对。循环设计得不好，可能半夜在死循环里烧掉几百美元，第二天早上才有人看到账单。
有些东西横跨好几层。CLAUDE.md、AGENTS.md 这类项目说明，内容是提示词，每次会话自动加载进窗口这件事归上下文管，决定项目知识写进仓库、由谁来维护，又是 harness 的事。测试代码属于 harness，测试失败后把报错自动喂回去再跑一轮，就成了循环的一部分。归到哪层，看你当时在解决哪个问题。
精力先放在哪
刚开始用 AI 编程，我的建议是从里往外做，但别停在里面。
提示词能说清楚就够了，不必去收集万能模板。上下文主要靠习惯，用一两周就有感觉。
harness 是回报最高的地方。每次它又犯了同一个错，就补一行说明、加一条 lint 规则、写一个测试，或者做一个 Skill。这些改动对之后每一次会话都生效，一直累积下去。
循环最好放到最后。现在不少文章把 Loop 工程说成未来，容易让人跳过前面直接搭自动化。可循环里最要紧的验证和停止条件，都得靠 harness 先提供可靠的检查手段。智能体在你看着的时候还做不稳，就别让它在你不看的时候接着做。
这个系列的其他文章
四层各有一篇展开，提示词工程讲哪些技巧过时了、哪些原则还在，上下文工程讲上下文为什么会越用越乱，Harness 工程讲工具、权限、验证和项目知识，Loop 工程讲循环的组成和常见的坏法。
另外三篇讲基本概念，智能体是什么、Agent Skills 是怎么设计的 和 MCP 是怎么设计的。
文中提到的几篇原文。