我现在给 Codex 或者 Claude Code 交代一个 Coding 任务，通常只会说清楚几件事。

我想实现什么目标，有哪些潜藏的风险，怎样才算做完。

至于应该先读哪些文件，修改哪部分代码，什么时候跑测试，测试挂了以后又该从哪里继续查，我一般会让 Agent 自己决定。

但刚开始使用 Coding Agent 的时候，我完全不是这样。

那时候我会先把任务拆得很细，把自己想到的实现方法和执行步骤一股脑写进去。Agent 每做完一点，我就去确认一下，再决定后面怎么继续。

现在回头看，不是当时的 Prompt 写得不够好，而是我还没有真正相信模型外面的那套系统。我虽然把敲代码的动作交给了 Agent，但任务的规划、执行和验证，依然牢牢攥在自己手里。

这个变化没有发生在某一次特别炸裂的任务里。它就是一点点发生的，少交代一个文件路径，少规定一个执行步骤，慢慢变成只给目标、风险和验收标准。

直到今年，Harness Engineering 和 Loop Engineering 这两个词突然被越来越多人提起，我才反应过来，原来真正发生变化的，不只是模型能力，也不只是 Prompt 写法。

是中间的过程，开始被系统接走了。

从 Prompt 到 Loop，是四层进化？

网上有一种很流行的说法，说 AI 工程正在经历四层进化。

从 Prompt Engineering，到 Context Engineering，再到 Harness Engineering，最近又走到了 Loop Engineering。

四个词排得整整齐齐，像大模型修仙的四个境界。Prompt 是练气，Context 是筑基，Harness 好不容易结个丹，Loop 直接元婴出窍了。。。

听着很顺。

但我盯着这套说法看了半天，越看越觉得不太对。

因为今天的 Agent 里，这四样东西明明同时存在。没有谁消灭谁，也没有谁把谁彻底替代。

更重要的是，它们根本不在同一个抽象层面。

Prompt Engineering

事情还得从那个熟悉的对话框说起。 很多朋友应该见过这样的提示词。

你是一名专业的英文翻译，请将用户提供的中文翻译成自然、准确的英文，保持原文语气，不要逐字直译，也不要添加原文中不存在的信息。

或者是这样的。

你是一名拥有 10 年招聘经验的简历优化专家，请分析我的简历，找出表达不清楚、缺少量化结果以及与目标岗位不匹配的地方，然后给出修改后的版本。

角色、能力、任务、步骤、限制、输出格式，全都要塞进一个对话框。

有些 Prompt 能写几千字，前面告诉大模型是谁，中间教它怎么思考，后面再规定表格格式，恨不得从入职培训一直写到年终绩效。

愚钝如我，当时也收藏过不少，甚至还安了很多插件保存 Prompt。

我拿翻译和简历举例，只是因为它们太有代表性。早期用过 ChatGPT 的人，大概率都见过这种角色扮演式 Prompt。

现在回头看，这种做法非常合理。因为 Chat 模式能提供给我们的，真的就只有一个输入框。

模型不知道你正在做什么，不知道文件放在哪里，也看不到任务以外的环境。它没有终端，没有代码库，没有测试，更不会在回答完以后自己确认结果对不对。

所以我们只能用一大段文字，临时给它搭出一个工作世界。

Prompt Engineering 解决的，是这一轮应该怎么对模型说。

Context Engineering

但很快大家就发现，只把指令写清楚还不够。

模型需要相关资料，需要记住之前发生过什么，需要知道有哪些工具，也需要从一堆信息中拿到当前真正有用的部分。

于是 Context Engineering 开始流行。

这个词主要是在 2025 年被推到台前的。Cognition、Tobi Lütke、LangChain、Andrej Karpathy 和 Anthropic 都讨论过它。大家的表达不完全一样，但说的事情差不多，模型再强，如果拿到错误的上下文，或者真正重要的信息被淹没在几十万 Token 里，它照样能一本正经地胡说八道。

Context Engineering 关心的，是下一轮应该让模型看到什么。

不过，这个名字虽然新，背后的工作并不新。RAG、记忆、工具描述、历史消息压缩，早就在处理同一类问题。

然后 Agent 来了。

我第一次使用 Codex 和 Claude Code 的时候，仍然带着非常强的 ChatGPT 习惯。

我会先自己分析任务，把方法想完整，再一步一步告诉 Agent 应该怎么做。

先打开哪个文件。 再找到哪个函数。 然后按照什么方式修改。 改完执行哪条命令。 如果报错，我再把报错读一遍，自己判断问题，然后告诉它接下来怎么处理。

表面上，是 Agent 在写代码。其实吧，我只是把敲键盘这件事外包了。任务怎么拆，问题在哪里，下一步做什么，结果怎么检查，还是我在负责。

人，才是那个真正的 Agent。 或者更准确一点。 人既是 Harness，也是 Loop。 是我把模型的回答复制到终端，是我把报错复制回输入框，是我决定什么时候继续，什么时候停下。我站在模型和真实世界之间，负责把一次次孤立的对话串成一个能工作的过程。

Harness Engineering

随着 Claude Code 和 Codex 的不停迭代，对用户来说会明显感觉到能力变了。

文件系统、终端、权限、Git、测试、日志、状态保存，这些东西开始被装进模型外面的运行环境。Agent 不只可以告诉我代码怎么改，它真的可以自己改。

这个运行环境，就是 Harness。

很多人会把工具调用归进 Context Engineering。这个理解不算完全错，因为工具描述、参数和返回值确实会进入上下文。 但如果只用 Context 解释，就会漏掉很关键的一半。

Context 关心模型看见什么。 Harness 关心模型看完以后可以做什么，不能做什么，做错了会发生什么，系统又怎么知道它做错了。

工具调用让 AI 获得行动能力。 测试和反馈让 AI 获得交付能力。 这两件事看起来只差一步，实际差得非常远。

一个只会改文件的 Agent 当然也很酷，但你还是得盯着它。看看它有没有改错，有没有破坏原来的功能，有没有把一个 Bug 修成三个 Bug。 一个会主动运行测试、阅读报错、重新检查假设并继续修复的 Agent，才开始值得被委托。

注意，我说的不是它从此不会犯错。 Codex 会犯错，Claude Code 也会，而且有时候错得特别自信。Harness 的价值从来不是让模型完美，而是让错误有机会被发现，让失败能够反馈，让任务可以恢复。 这才是工程。

但写到这里，如果把 Harness 当成故事的终点，也不对。 因为 Harness 解决了 Agent 能不能行动，却还没有完全回答另一个问题。 谁来决定下一步？

Loop Engineering

在我刚开始使用 Coding Agent 时，答案仍然是我。 Agent 改完一轮代码，我去看结果。测试失败了，我分析原因，再告诉它应该怎么继续。Harness 已经存在，但工作流还是被我的一次次 Prompt 推动。

而现在，越来越多的下一步，开始由系统自己产生。

Agent 执行命令，拿到结果，更新状态，判断离目标还有多远，然后决定要不要继续调用模型。模型的输出不再直接回到人类面前，而是先成为下一轮行动的输入。

这就是 Loop Engineering 真正让我觉得有意思的地方。

今年 6 月，Peter Steinberger 写过一句传播很广的话，他说不应该再亲自 Prompt Coding Agent，而应该设计那些会去 Prompt Agent 的 Loop。Anthropic 的 Boris Cherny 也表达过很相似的感受，他现在的工作越来越像是在写 Loop，让 Loop 去推动 Claude。

随后 Addy Osmani 又把 Loop Engineering 系统地写了出来。自动化、外部状态、技能、连接器、子 Agent、验证和停止条件，被组织成一套可以持续运行的工作方式。

这个词为什么突然打中了很多人？

我觉得不是因为循环刚刚被发明。 2022 年的 ReAct 已经在研究推理、行动和观察之间的循环。后面的 Reflexion 和 Self-Refine 也在做反馈、反思和迭代。Agent 从出现的第一天开始，就离不开 Loop。

真正改变的，是谁在负责这个 Loop。

以前是人读完结果，再决定下一步怎么继续。 现在是系统读取状态，再生成下一次调用。 人类从循环内部，一点一点退到了循环外面。

我不觉得 Loop 有资格成为 Harness 之上的独立一层。但我也不觉得它只是一个可以随手略过的新名词。

它不是新的能力容器，却是一种非常重要的工作方式。 Harness 像一间装备完整的工坊，里面有工具、有材料、有安全规则，也有检查台。 Loop 则像工坊里的工作流，它决定拿到结果以后做什么，什么时候重新加工，什么时候检查，什么时候结束。

没有 Harness 的 Loop，就是让一个人赤手空拳在房间里反复转圈。转得再快，也可能只是把同一个错误生成 20 遍，然后非常勤奋地消耗你的 Token。。。 但只有 Harness，没有 Loop，也像一间设备齐全却一直等人按门铃的工坊。每做完一步，都要人类回来告诉它下一步干什么。

Harness 提供能力。 Loop 组织时间。 它们不是上下替代的两层，而是互相咬合的两部分。

并不是四层进化

所以，回到最开始的四个词，我更愿意这样理解。

Prompt 处理任务如何被表达。Context 处理信息如何被组织。Harness 提供真实的行动环境。Loop 则负责让行动、反馈和下一次调用持续发生。 它们共同存在，也没有一个简单的四层进化。

Harness 和 Loop 只是今年才被冠名

今年真正有趣的事情，是 Harness Engineering 和 Loop Engineering 几乎同时从幕后走到了台前。 但这两样东西，其实也都不是今年才出现。

2024 年的 SWE-agent 已经提出 Agent-Computer Interface，研究交互界面怎样影响软件工程 Agent 的表现。 2025 年，Anthropic 已经在讨论支持长时间运行 Agent 的 Harness，包括进度记录、Git 历史和跨上下文接续。 今年 2 月，Mitchell Hashimoto 明确说，他开始把这类工作称为 Harness Engineering。几天后，OpenAI 也用一篇同名文章，分享了他们怎样围绕 Codex 建设环境、规则、测试和反馈机制。

Loop 也是一样。

ReAct、Reflexion、Self-Refine，还有后来大量自主 Agent 的实践，都已经在循环。到了今年，大家才开始把「不再亲自提示 Agent，而是设计提示 Agent 的系统」这件事，集中叫作 Loop Engineering。

先有实践，后有名字。

我一直觉得，一个领域开始给某件事命名，往往不是为了制造新概念，而是因为那件事已经重要到不能继续躲在角落里了。

以前大家评价 Codex 或者 Claude Code，最喜欢问背后用了哪个模型。现在大家会慢慢追问，它能访问什么环境，怎样管理状态，任务失败后能不能恢复，验证结果从哪里来，它能否在我离开以后继续推进。

关注点从一次回答，移动到了一个持续工作的系统。

从关心大模型到关心围绕大模型设计的新系统

这让我突然想起经济史里经常被讲起的一个故事。

电力刚进入工厂的时候，很多工厂只是把原来的蒸汽动力换成电动机，生产方式并没有立刻改变。真正的生产力提升，是后来的人开始围绕电力重新设计机器的位置、生产流程和工厂组织。

不是发动机不重要。 而是只有发动机，没有围绕它重新设计的系统，新的能力释放不出来。 今天的大模型也有点像这样。

Prompt 在告诉发动机去哪里。Context 在给它地图。Harness 造出了车身、方向盘、刹车和仪表盘。Loop 则让这辆车不需要每走 100 米，就停下来等人重新点火。

模型当然还是发动机。 但我们终于开始设计整辆车了。 这也在反过来改变我们怎么写 Prompt。

以前的 Prompt 像操作手册。你是一名什么专家，你要按照哪几步完成，你必须使用什么方法，你应该输出什么格式。

现在给 Agent 的 Prompt，更像任务合同。 我要什么结果。 哪些风险不能发生。 怎样才算完成。

中间那些「先做什么，再做什么」，开始被 Harness 里的 Loop 接管。

所以 Prompt 并没有消失。 它只是发生了两次迁移。 一部分被固化进 Harness，变成系统提示、工具定义、仓库规范、权限机制和测试规则。另一部分被放进 Loop，由系统根据执行结果和当前状态，动态产生下一次调用。

我们没有停止做 Prompt Engineering。 我们只是从逐轮推动模型，走到了设计任务如何被产生、被执行、被验证。 坦率的讲，我觉得这才是从 Prompt 到 Loop 最值得写的变化。

不是四个新词排队上场，也不是旧方法被新方法打死。真正发生的，是控制权在移动。 Chat 模式里，人负责表达任务，也负责准备上下文、执行动作、观察结果和继续追问。 Coding Agent 出现以后，Harness 接走了执行环境。 Loop 继续接走了下一步的判断和调度。

能力跃迁发生在 Harness。 工作方式的变化，则在 Loop 里彻底展开。

人的控制权并没有消失

当然，我也不想把持续运行的 Agent 吹成什么自动化真神。现在的 Codex 和 Claude Code 离真正可靠还差得远。Loop 跑得越久，错误也可能积累得越深。目标定义不清、验证规则有漏洞、上下文开始漂移，都会让一个看起来非常勤奋的 Agent 在错误方向上狂奔。

所以人并没有消失。 我们只是从负责每一步，慢慢变成负责目标、边界、风险和验收。

以前我们写 Prompt，是教模型怎么做。 以后我们设计 Loop，是决定一个系统怎样知道自己还没做完。 回头再看那句熟悉的话。 「你是一名专业的英文翻译。」 它还在那里。 只是以前，整个工作世界都要由我们亲手写进输入框。现在，角色和规则进入了 Harness，执行结果进入了 Context，后续调用也开始由 Loop 根据状态自动推进。

真正改变 AI 的，可能不是某一句更聪明的 Prompt。 而是我们终于学会怎样让一条指令之后的事情，继续发生。

大时代啊，朋友们。