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 量级Prompt Engineering全程操作员百~千Context Engineering信息管道设计者千~万Harness Engineering系统搭建者偶尔介入万~十万Loop Engineering循环设计者系统自己跑十万~持续运行这不是「模型越来越聪明」的故事。模型的能力基本没变变的是工程愿意为它铺多厚的地基。每一层地基的成本最终都算进了 token。可用性不是模型免费赠送的是工程一点点买出来的。但这条路的终点并不是「token 无限涨」。任何工程学科的成熟都遵循同一个节奏先不惜代价让它能用再系统性地把代价压下来。LLM 工程也走到了这个拐点。当 Loop Engineering 的架构基本跑通下一个阶段的命题开始反转怎么用更少的 token 维持同等可用性。这个命题已经开始浮现。上下文压缩把冗长的对话历史蒸馏成紧凑的摘要而不是原样保留状态外置把跨 session 需要记住的信息从上下文窗口里搬出去放进数据库或文件用时再精准取回稀疏调用不再默认触发所有工具而是只在真正需要的时候才发起检索或执行结构化记忆用有组织的外部知识索引替代「把所有上下文塞满」的暴力做法。每一项优化都是在用架构的精确度换 token 的节省——和当年数据库从全表扫描到索引查询是同一类工程问题。但有一件事不会被优化掉判断。验证器需要人来定义什么叫好循环需要人来设定终止条件掌控权需要人来主动持有。这些不是 token 的问题是人愿不愿意留在系统里负责的问题。工程可以让模型跑得更远、更便宜、更稳——但它跑的方向对不对始终需要人来回答。从 Prompt Engineering 到 Loop Engineering工程师退出的是重复劳动不是判断本身。这是这条路真正的终点。