提示词正在消失，大多数人还停在第一层

Andrej Karpathy在一段124分钟的视频里说了一句话："Prompting is going away. Delete everything, keep Graph." 提示词正在消失，删掉一切，留下图。

这话听着绝对。但把视频看完，再读Livsun那篇《Prompt → Context → Harness → Loop → Graph: The 5 Levels of AI Engineering》，会发现他讲的重点不是提示词没用了。提示词早不是瓶颈。

大多数人用AI的方式还停在第一层：开个对话框，打一句话，看回答，再打一句更好的。模型答得不好，怪模型，等下一个版本。模型已经迭代了好几轮，人的用法没变过。

Livsun把AI工程拆成五层。每一层都在回答同一个问题：模型到底能拿到什么？

第一层，你给它一句话。
第二层，你给它一个窗口。
第三层，你给它一个环境。
第四层，你给它一个排程，你不再敲键盘。
第五层，你给它工作的形状，一群agent来跑。

新模型每隔几周就出一个，这五层不动。上层的每一层都包着下面那层，不会在下个发布日过期。

第一层：提示词工程，你自己就是那个循环

你写指令，模型回答，你判断，你改写，再来一遍。这是所有人都熟悉的方式。它也能用。但这是用AI最慢的方式，因为系统里最慢的部件是你。模型几秒钟就答完了，你读、想、重打，好几分钟。每次重试都在等人。

困在这一层的标志：你最得意的技巧是一个魔法短语。"Think step by step.""你是一位世界级专家。"一个存满模板的笔记文件，你复制粘贴再微调。

这些短语还有一点用。但没有任何一句话能给模型它没有的事实、它调不动的工具、或者一个检查自己工作的办法。

第二层：上下文工程，填窗口，不是句子

2025年6月，Shopify CEO Tobi Lütke说比起prompt engineering，他更喜欢"context engineering"这个词，因为它更准确地描述了核心技能：为目标提供足够上下文，让LLM有理由把事做成。

Andrej Karpathy回了一个"+1"，然后写了后来被到处引用的定义：上下文工程是"把刚好够的信息填进上下文窗口，为下一步服务的细腻艺术和科学"。

最后四个字是整个第二层。模型不知道你的项目、你的规则、你上周的决定、昨天哪里坏了。它只知道这个步骤里窗口里有什么，别的什么都不知道。

所以你把打磨指令的时间拿去分配窗口：永远不变的规则，系统提示词和一个类似CLAUDE.md的项目文件；描述清楚、让模型能分辨和挑选的工具；从之前工作里带过来的决策和状态；检索材料，给三个重要的文件，不是三百个都塞；任务本身放在最后，读的时候其他东西已经在了。

这一层的天花板很安静但很硬。上下文是模型能看到的一切，但它还是一次调用，你还是那个手工组装它的人。你想让模型动起来，跑代码、开文件、查结果、再试一次，得有人去造那台机器。

那台机器是第三层。

第三层：Harness工程，模型是引擎，harness是车

Harness是模型周围一切让它变成agent的东西：把工具结果喂回去的循环、工具本身、权限、沙箱、记忆文件、事件触发钩子、发生过什么的轨迹。

Claude Code是一个harness。Codex CLI是一个harness。同一个模型放进两个不同的harness，出来就是两个不同的agent。

2026年2月，OpenAI发了一篇"Harness engineering: leveraging Codex in an agent-first world"。他们的设置是：一个仓库五个月长到大约一百万行，Codex负责写，工程师负责设计它工作的世界。

4月，复旦和北大的研究者把数字摆了出来。论文叫《Agentic Harness Engineering》，让一个agent只干一件事：不断编辑另一个编码agent的harness，每次编辑都对照预测来检查。

十轮之后，Terminal-Bench 2 pass@1从69.7%升到77.0%，比人类设计的Codex-CLI harness的71.9%还高。冻结下来的harness在SWE-bench Verified上少用了12%的token。增益来自工具、中间件和长期记忆，不是系统提示词。

最后那句值得再读一遍。大多数人把所有时间花在的那个部分，恰恰是最不重要的部分。

今天就能做的第一个harness动作：给agent一个它绕不过去的闸门。Claude Code里，每次agent想结束都会跑一个Stop hook。退出码2阻止结束，把错误送回给模型。

现在"做完了"的意思是测试通过，不是模型觉得自己做完了。

第三层的天花板：再好的harness也在等你。每次运行都从人敲一个任务开始。你不再是运行里的那个循环，但你还是触发器。

第四层：循环工程，别再当那个敲提示词的人

2026年6月7日，Addy Osmani给这一层起了名字。他的文章"Loop Engineering: Designing loops that prompt coding agents"一句话定义："循环工程是把自己替换成那个给agent写提示词的人。"

他把这层放在harness的上一层。

离工具最近的人先到了这里。Peter Steinberger说："你不该再给编码agent写提示词了。你该设计给agent写提示词的循环。"Boris Cherny，Claude Code的创造者，说："我不再给Claude写提示词了。"他现在的活，用他的话说，是写循环。

Osmani拆解一个循环：按计划醒来找活分活的自动化；worktree，让并行agent不碰彼此的文件；skill，装着agent需要时自己加载的项目知识；插件和连接器，接到你已经在用的工具；子agent，把提出的人和检查的人分开；一个状态存储，一个markdown文件或者看板，说清楚什么做完了、下一步是什么。

今晚就能起一个。Claude Code有/loop：给一个间隔和一个任务，它就重复跑。不给间隔，模型自己定节奏。

陷阱在这里。一个基本的agent循环只有一种结束方式：模型不再要工具。把它放到定时器上，你就造了一台能整夜花钱的机器。每个值得跑的循环都有刹车：一个在模型外面跑的完成检查；预算，最大运行次数、最大token、最大金额；一个空转规则，两轮没找到新东西就停；每一步之后写状态，崩溃之后接着跑，不是从头来。

Osmani说得很清楚，循环不是完全自主：检查工作、保住你自己的判断，仍然是你的活。循环去掉的是打字，不是思考。

最后一个天花板：循环还是一条轨道。一个agent、一个队列、一次一件事，重复。当活是宽的，审40个文件、查12个来源、审计每一条路由，循环只会更慢地做。

最顶层改变的是形状。

第五层：图工程，画出工作的形状

到第五层，你不再按步骤想，开始按节点和边想。一个节点是一个有边界的工作，有清楚的输入和输出。一条边只存在于一个节点的输出喂给另一个节点的输入的地方。

大多数"第一步、第二步、第三步"的agent都是塞满假边的图。一半步骤根本不读彼此的输出。它们没理由地排着队。

删掉假边，线变成菱形：split，一个节点把活拆成独立的部分；fan out，多个agent同时做这些部分，各自在干净的上下文里；verify，一个闸门试图在每个发现被放行前杀掉它；merge，一个节点只看幸存下来的，写出答案。

这不是理论了。Claude Code的动态工作流（6月以来的研究预览）让Claude把计划写成一个JavaScript脚本，用一群子agent来跑，一个会话里几十到几百个。

路由住在代码里，所以每次都一样地跑，agent之间的接线是普通代码，不是又一次模型回合。

一个图要快、要便宜，两条规则：只在节点真的同时需要所有结果的地方等所有结果，去重、排序。其他地方让每一项直接流到下一个节点。给模型分层，重复的fan-out节点用便宜的模型，判断和合并用你最强的模型。

你在第几层？30秒测试

你反复改同一句指令直到它管用：第一层。

每次任务前你加载一个项目文件、对的文件和例子：第二层。

你的agent跑工具、有钩子、检查不通过就不能说做完了：第三层。

活在你什么都不敲的情况下开始：第四层。

一个请求散给很多agent，被验证，再合回来：第五层。

本周可以做的五件事，一层一件

提示词：把你最常用的提示词里所有"你是一位专家"删掉。换成一段优秀输出的例子。
上下文：写一页纸的项目文件：规则、技术栈、决定、做完了什么。每次会话前加载，数一下你少改了多少次。
Harness：加上第三层的Stop hook。测试不过，agent不能结束。
循环：把/loop放到你的待办清单或收件箱上，带上预算和状态文件。让它跑一夜，早饭时读状态文件。
图：搭一个菱形。把一个审查任务拆到多个文件上，散出去，让一个怀疑者agent攻击每一个发现，把幸存者合并成一份报告。

结尾

写提示词的人写句子。第五层的工程师写工作的形状，句子自己写出来。

模型会继续换：新的Claude、新的GPT、新的Gemini、每两周一个开源大模型。每一个都只是引擎。你围绕它建的那些层级，不会在发布日过期。

大多数人会继续在第一层打磨那句话。

少数往上爬的人，在别人还在打字的时候，已经跑起了一支舰队。

（引用：Livsun的文章《Prompt → Context → Harness → Loop → Graph: The 5 Levels of AI Engineering》，Andrej Karpathy，Tobi Lütke，Addy Osmani，Boris Cherny，Peter Steinberger，OpenAI的Harness engineering文章，复旦和北大的《Agentic Harness Engineering》论文。）