TL;DR

从 Prompt 到 Loop，四个工程阶段一路演进，每一步都在用更多的 token 购买更高的可用性。这不是模型变聪明了，而是工程在替模型偿还先天缺失的能力。

一、从“像会”到“真做完”

不得不承认的是，LLM 让许多人产生过相同的错觉：它看起来无所不能。

让它写代码，它动笔；让它调试 bug，它剖析；让它规划任务，它罗列。这种行云流水的流畅性，制造了一个假象——只要模型足够强大，剩余的事情它自己就能完成。

但“像会”和“真做完”之间，横着一道很深的鸿沟。

模型的单次输出可以很漂亮，然而一个任务要真正落地，通常需要经历这些步骤：记住上一步发生了什么、把结果写到正确的位置、验证输出是否符合预期、在失败时知道该如何重来。你看，这些能力模型天生就薄弱：上下文记忆短、状态无法持久、执行闭环缺失。

因此工程应运而生。目的不是把模型变聪明，而是补上它先天不擅长的那些环节。

每一层工程补丁，最终都以 token 的形式，挤进了上下文窗口：更多的指令、更完整的历史、更详细的工具描述、更多的验证轮次。可用性是真实的，代价也是真实的。

这就是接下来要讲述的四个阶段——从 Prompt Engineering 到 Loop Engineering，一条用 token 换取可用性的进化之路。

二、Prompt Engineering：人在链路里

最早的工程答案很简单：把需求说清楚。

Prompt Engineering 的核心假设是，模型的能力已经摆在那里，只缺一把正确的钥匙。于是工程师们开始研究措辞——如何描述角色、如何给出示例、如何分步骤引导、如何用「think step by step」让它慢下来推理。

这一阶段的 token 消耗极低。一次对话，几百到几千个 token，换来一次有用的输出。

但它有一个根本性的缺陷：人始终在链路中。

每一次任务都需要人来启动——构建输入、判断输出、决定下一步。模型是工具，人是操作员。任务越复杂，人的介入就越多；没有人盯着，系统就停摆了。

这不是 Prompt 写得不够好，而是这个范式本身的天花板：它从未打算让模型独立完成一件事，只是让模型更好地回答人的每一个问题。

可用性有限，但成本也最低。这是起点。

三、Context Engineering：喂给大模型的信息

Prompt Engineering 很快撞到了一堵墙：光靠措辞，驯化不了复杂任务。

问题不在于“怎么说”，而在于“给模型看什么”。模型能发挥的上限，往往不依赖它的参数规模，而取决于进入上下文窗口的信息——是否够准、够全、够干净。

Context Engineering 的核心工作，就是设计这条信息管道。

RAG（检索增强生成）是最典型的形态：不把所有知识塞进 Prompt，而是在运行时检索相关片段，动态注入。问代码库的问题，先搜索相关文件；问产品细节，先查阅文档。模型看到的就不再是“凭空”的问题，而是带着充分背景的问题。

除了 RAG，这一层还包括：对话历史的管理（保留哪些、丢弃哪些）、记忆的检索与压缩、工具描述的精心设计、少样本示例的动态选取。

token 在这一阶段，第一次因为工程结构本身而增加——不是因为任务更复杂了，而是系统主动往窗口里放了更多内容。每一次检索、每一段注入的背景、每一个工具的描述，都是成本。

但收益是立竿见影的：模型开始在正确的信息上工作，而不是在空白上猜测。幻觉减少了，输出质量提高了。

不过人还没有退出。检索策略如何设计、注入什么粒度的信息、上下文满了如何裁剪——这些决策仍需要工程师来做。系统更复杂了，但还不能自主运行。

四、Harness Engineering：让单次执行可靠

Context Engineering 解决了“模型看什么”，但还有一个更大的问题未解：模型的单次输出，根本不足以完成一件真实的任务。

写代码需要读文件、改文件、跑测试、处理报错；回答问题需要搜索、汇总、验证、再搜索。这些都不是一次生成能完成的，需要模型和外部世界之间有一套稳定的接口——工具、权限、重试、状态管理。

Harness Engineering 的任务，就是搭建这套接口。从 Claude Code 泄露的源码里，可以提炼出四类核心基础设施：

记忆与上下文管理：三层记忆架构——常驻的精简索引、按需加载的主题文件、磁盘上的完整历史；后台自动去重压缩；四级上下文压缩机制应对窗口溢出。

工作流编排：Explore-Plan-Act 三段权限递进（先只读探索，再讨论方案，最后才写文件）；专职子 agent 各自持有独立上下文和工具权限；并行工作区（Parallel Worktrees）让多个 agent 同时推进，互不污染。

工具与权限控制：默认只激活少数工具，按需扩展；每个工具独立配置 allow/ask/deny；用专属工具替代通用 shell，减少意外副作用。

生命周期钩子：25 个以上的钩子点（PreToolUse、PostToolUse、SessionStart……），把必须执行的操作从 Prompt 迁移到系统层，不再依赖模型“记得去做”。

但无论实现形式怎么变，往下挖，有三条绕不过去的原则，没有例外：

可见性——Agent 看不见的信息等于不存在。关键决策散落在群聊里、口头沟通里、老工程师脑子里，对模型来说就是不存在。所有上下文必须显式存在、版本控制、放进仓库。

状态持久化——AI 没有记忆，你得替它设计。每次新 session 从零开始，不知道上次做到了哪里、踩过什么坑。progress.txt、标准化 git commit、暂存记录——形式不同，本质是同一件事：设计跨 session 的信息载体。

质量门禁——不能靠 Agent 自评。Agent 评价自己的输出会系统性偏正。linter 不通过就不开 PR，阈值不达标就整个重来——完成标准必须明确、可执行、机械化，否则 AI 自己决定什么叫完成，而它的标准往往比你想的低得多。

每一条原则最终都以 token 的形式落地：更多的规范文档、更长的进度记录、更多的验证调用。Token 在这里不再线性增长，而是随着系统复杂度，结构性地抬高基线。

代价换来了真实的稳定性——单次执行，第一次变得基本可靠。

五、Loop Engineering：退出循环，让系统自己跑

Harness Engineering 解决了单次执行的稳定性，但还有一件事未解决：你还在那里盯着。

每次任务开始，你触发；每次输出出来，你判断；每次需要下一步，你决定。哪怕 agent 执行得越来越顺，驾驶员的位置始终是你。

Loop Engineering 的核心转变只有一句话，引用 Addy Osmani 的原话：不是你提示 Agent，而是你设计循环，循环提示 Agent。

一个循环的基本结构是：发现 → 规划 → 执行 → 验证 → 重复，直到终止条件触发。最简单的形态就是所谓的 Ralph 模式——把 agent 的停止信号拦截掉，检查终止条件（测试通过 / 完成标签），没过就把更新后的上下文重新喂给 agent，继续跑。最朴素的死循环，但结构上已经是 Loop Engineering 了。

但 Loop Engineering 真正困难的地方，不是怎么触发循环，而是告诉循环什么叫完成。

这里出现了这个阶段最关键的角色分离：每个循环都由两部分构成，生成器（负责产出）和验证器（负责判断）。模型作为生成器越来越便宜、越来越强；但验证器才是瓶颈，而且几乎所有介绍 Loop Engineering 的文章都跳过了这一点。

一个验证器弱的循环，在出错时不会明显地暴露问题——它会非常自信地持续产出垃圾，跑很多轮，每次都报告“成功”。

对比两种做法，差距立刻就清楚了。

弱验证器（开环）：

“把这个模块的代码质量改好，一直迭代。”

结果：重构了 6 个版本，每版都说“已优化”，代码变长还是变短说不清楚，bug 有没有引入也不知道。烧了大量 token，原地打转。

强验证器（闭环）：

目标：重构 UserService，提升可维护性。完成条件（全部通过才算）：- 所有现有单元测试通过，覆盖率不低于改前- 无新增 lint 错误- 每个公共方法不超过 30 行- 无循环依赖引入循环：提一个改动 → 跑全部检查 → 全过才保留 → 5 轮后还没全绿则汇报剩余问题

这个差距不是 Prompt 写得好不好的问题，而是有没有把“完成”的定义编码进系统。写验证器，是 Loop Engineering 里的新 Prompt Engineering。你的判断力不再是软技能，它就是奖励函数。

当多个循环组合起来，系统开始产生真正的复利效应。一个实际案例：4 个循环共享同一套数据——支持循环每 30 分钟处理一批工单，发现摩擦点写进 signals/ 目录；SEO 循环每天拉数据、选题、生成页面；产品增长循环从 signals/ 里提炼实验任务；内容循环按排期发布。四个循环各自独立触发，但读写同一批共享文件夹，信息在循环之间流动积累。这不再是一个 agent 解决一个问题，而是多个循环互相喂数据、共同收敛。

Token 在这里的消耗模式彻底变了。不再是一次对话几千 token，而是持续运行的系统底座：每次触发的上下文加载、各个隔离工作区独立维护的上下文、规范知识跨 session 注入、子 agent 各自的上下文副本、验证回合的额外调用。Token 不再是对话成本，而是运行成本——更像服务器的 CPU 时间，而不是单次 API 费用。

但三个问题在这个阶段变得更难，而且 token 解决不了它们。

偏移积累：上一层的质量门禁只拦得住单次执行的显式错误，而循环里积累的方向偏移——假设悄悄变了、状态被污染了、边界条件逐渐被侵蚀——需要独立的、主动的评估器架构，而不是生成器顺手做的自我检查。

认知断层：当系统复杂到你说不清它为什么这次跑错了，工程师和系统之间就出现了认知鸿沟。可观测性从锦上添花变成必须工程——不是因为系统脆弱，而是因为你必须能看进去。

判断缺席：最隐蔽的风险。你逐渐不再追究输出的对错，开始默认“AI 应该没问题”。这不是 AI 的问题，是人主动退出了判断席位。失去的不只是某次任务的质量，而是掌控权本身。而一旦掌控权丢失，再好的验证器也只是掩盖问题的速度更快。

六、这条路通向哪里

回头看这四个阶段，有一条隐藏的主线：人在链路里的比例，一直在下降。

这不是一个“模型越来越聪明”的故事。模型的能力基本没变，变的是工程愿意为它铺多厚的地基。

每一层地基的成本，最终都算进了 token。可用性不是模型免费赠送的，是工程一点点买出来的。

但这条路的终点并不是“token 无限涨”。

任何工程学科的成熟都遵循同一个节奏：先不惜代价让它能用，再系统性地把代价压下来。LLM 工程也走到了这个拐点。当 Loop Engineering 的架构基本跑通，下一个阶段的命题开始反转：怎么用更少的 token 维持同等可用性。

这个命题已经开始浮现。上下文压缩，把冗长的对话历史蒸馏成紧凑的摘要，而不是原样保留；状态外置，把跨 session 需要记住的信息从上下文窗口里搬出去，放进数据库或文件，用时再精准取回；稀疏调用，不再默认触发所有工具，只在真正需要的时候才发起检索或执行；结构化记忆，用有组织的外部知识索引替代“把所有上下文塞满”的暴力做法。

每一项优化，都是在用架构的精确度换 token 的节省——和当年数据库从全表扫描到索引查询，是同一类工程问题。

但有一件事不会被优化掉：判断。

验证器需要人来定义什么叫好；循环需要人来设定终止条件；掌控权需要人来主动持有。这些不是 token 的问题，是人愿不愿意留在系统里负责的问题。工程可以让模型跑得更远、更便宜、更稳——但它跑的方向对不对，始终需要人来回答。

从 Prompt Engineering 到 Loop Engineering，工程师退出的是重复劳动，不是判断本身。

这是这条路真正的终点。

参考资料

[1] Addy Osmani: https://x.com/addyosmani/article/2064127981161959567