PE 到 Graph 换了五轮词，本质是上一层的失败太贵了

社区大概每隔半年到一年，就会蹦出一个新词。Prompt Engineering 那阵子，我天天在改 system prompt，改到怀疑人生。后来 Context Engineering 接棒，Karpathy 一句话把风向拽了过去。再后来是 Harness，Agent = Model + Harness 被讲成了公式，到处贴。接着轮到 Loop——有人开始说自己已经不写 prompt 了，只写循环。到了 2026 年年中，Graph 又摆上了桌面：多节点、共享状态、可恢复执行。

我一开始也追这些词，追到后来发现一件事：表面看是名词接力，但底下其实是同一件事在反复发生。

不是新词更好听，是上一层的失败变贵了，工程杠杆被迫外移。

五月我写过从 Prompt 到 Harness，六月写过循环工程，七月写过 Harness 自我迭代。那几篇分别钉住的是单层。这篇我只做一件事：把五层串成同一条因果链，然后回答一个实际问题——你现在卡在哪一层。

五层不是升级路线图，是嵌套楼层

我见过太多人把这五个词当成「升级路线图」：PE 过时了上 Context，再上 Harness，一直叠到 Graph。我每次看到这种理解都想拍桌子。它们是嵌套楼层，前后层互相包含，谈不上互相作废的版本号。

还有一句我得先钉死：这是瓶颈叙事，跟严格编年史有差别。ReAct 的 loop（2022）和 LangGraph（2024）在日历上早于 context/harness 的正名潮（2025–2026），命名一直滞后于实践。我踩过的坑就是：2024 年我在项目里已经用了状态图做编排，但当时我管它叫"工作流引擎"，因为"Graph"这个词还没被社区正式认领。

Prompt 是 Context 的一部分；Context 管道是 Harness 的子系统；Harness 撑起一次 Loop；Loop 往往只是 Graph 里的一个节点。

每一层都在替上一层的硬伤买单

PE：把话说清楚，然后撞上「窗口外没有事实」

Prompt Engineering 解决的是采样分布层面的问题：角色设定、few-shot、输出格式、拒绝边界。我实测下来，同一个模型，换个说法，输出能差出十万八千里。它的天花板也很干净：措辞再完美，也变不出上下文里没有的事实。

任务一旦从「写一段文案」变成「拿我的代码库、工单、合同办事」，瓶颈立刻从「表达」换成了「信息」。PE 没有死，它只是从主角退成了外层系统里一个被管理的对象。Harrison Chase 的说法更直：PE 是 context engineering 的子集。我认同这个判断，因为我自己的 system prompt 现在就是被 harness 动态拼装出来的，手写的部分越来越少。

Context：把对的东西喂进去，然后撞上「长了会烂」

Karpathy 在 X 上那句被反复引用的话，把风向说得相当白：

I really like the term "context engineering" over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM. —— Andrej Karpathy

Anthropic 写得更硬：context 是有限且有成本的注意力预算；窗口拉得越长，越容易 context rot，表现为召回与专注的渐变衰减，一步到位的断崖倒没有。原则也很土：去找尽可能小的高信号 token 集合。出处：Effective context engineering for AI agents。

这一层的进步，是把「写一句 prompt」升级成了「每一次 inference 都重新策展：什么进窗、什么压缩、什么落盘、什么按需检索」。CLAUDE.md、git 状态、按需读文件，本质都是 context 工程。我自己项目里的做法是：把 CLAUDE.md 控制在 80 行以内，超出部分走按需检索，效果比硬塞一整个 README 好太多。

但 Context 仍有硬伤：输入再干净，执行过程也没人盯着。我遇到过一次，第 1 步对、第 7 步漂、第 20 步在错误上盖楼，最后自信地宣布「做完了」。这套毛病，靠「再喂两段文档」治不了。

Harness：给一次运行上缰绳，然后撞上「你还是那个启动按钮」

LangChain 把这个公式写得很干净：

Agent = Model + Harness。 If you're not the model, you're the harness. —— The anatomy of an agent harness

Harness 涵盖模型之外的一切：工具注册与校验、权限门、状态与记忆、compaction、重试与恢复、日志与可观测性。模型负责提议，Harness 负责执行、观察，并决定这一轮能不能继续。

Anthropic 在长程 agent 的文章里点名了几类真实失败：一上来就想 one-shot 整个项目、跨 session 失忆、过早宣布完成。他们的应对很工程化——initializer 先搭环境和 feature list，coding agent 每次只啃一块，用 progress 文件和 git 做交接，验收靠真实的端到端检查，自评数不算。出处：Effective harnesses for long-running agents。

这一层回答的是：一次 run 能不能持续做对。天花板同样清楚：再完美的 harness，默认管的仍是「这一次」。启动、看结果、决定要不要再开一轮，人还在回路里。高 stakes 的单次任务，这样没问题；一旦工作变成每天的 issue triage、每周的报表刷新，你就活成了 cron。我自己就活成了 cron，每天早上手动点"继续"，点了三周才想通该上 loop。

Loop：把自己从循环里抽出来，然后撞上「单专长装不下」

Loop 层的公开信号已经相当明确。OpenClaw 作者 Peter Steinberger 给的方向是：别再一条条 prompt coding agent，去设计那些替你 prompt 它们的循环。Claude Code 负责人 Boris Cherny 更直：自己已经不再亲自 prompt 了，有一堆 loops 在跑，活儿就是写 loops。LangChain 随后把 loop engineering 收成可叠加的几层：agent loop、verification loop、event-driven loop、hill-climbing loop。出处：The art of loop engineering。

边界得钉死：

Loop 真正难啃的，是 verifier 和终止条件，画圆反而是容易的。弱验证的无人 loop，后果远不止「给个坏答案」——它会整夜自信地生产垃圾，还按 token 计费。我在循环工程里写过：循环不难设计，难在养得起。今天再补一句：

Loop 的瓶颈往往不是模型，是裁判。

单 loop 的天花板也在这：它擅长的是一个专长的重复。当研究、写作、评审、测试天然需要不同上下文、不同工具、不同成功标准时，一个 loop 就会开始什么都沾一点，什么都做不稳。我试过把代码审查和文档生成塞进同一个 loop，跑了两周，两边质量都掉了。

Graph：把多个节点织成组织，然后撞上「分布式系统税」

Graph 这个词，2026 年之前就有，谈不上凭空发明。LangGraph 的定位一直是：面向长程、有状态 agent 的编排运行时——节点做功、边负责路由、共享 state 在图上流动，同时强调 durable execution、human-in-the-loop、失败后可恢复。出处：LangGraph overview。

一个 loop，本质上是「单节点 + 自环」的最简图。Graph 这种结构，要等你需要 fan-out / fan-in、条件回环、确定性步骤与 agentic 步骤混跑、显式审计路由的时候，才真正必要。它要解决的是：多专长如何可靠协同。

它引入的新税也是真的：状态契约、失败回边、并发冲突、职责污染、可观测性。我上一家公司试过一次，过早上了 Graph，结果排障时间翻倍，智能程度没上去，纯粹多了一堆分布式系统的经典问题。

公开信号在收敛：大家其实都在修同一栋楼

近一两年的高信号材料，表述各不相同，结构却很像：Karpathy 在推 context engineering，Anthropic 写注意力预算和 long-running harness，LangChain 钉死了 Agent = Model + Harness、把 loop 叠成 agent / verification / event / hill-climb 几层，LangGraph 管状态图和可恢复执行。

Claude Code、Cursor、OpenAI Agents SDK 走的路线不同，但 harness 要管的东西在趋同：loop、工具、状态压缩、权限门、恢复与可观测。OpenAI 更偏显式的 multi-agent handoff，Claude Code / Cursor 更偏强单 agent 加深集成，组织级的复杂交付，才会真正需要图和状态机。

模型在变强，但拉开差距的，越来越是模型周围那套系统能不能撑过第 50 步。

我对比过两套用同一个模型的 pipeline，唯一区别是 harness 和 loop 的设计，端到端完成率差了一截。评估 agent 时只报模型名，几乎不可复现，得把完整的壳一起报出来。这是我的经验，不是理论。

一张诊断图：别再拿「模型不行」当万能背锅侠

日常真正有用的，是标楼层：

多数「模型能力不够」的吐槽，我拆开看是这样的：指令含糊；该看的没进窗，不该看的噪声倒进了窗；没有独立验收，全靠模型自评；人还在当启动器和质检员；过早把一个团队级问题塞进一个大脑。

我自己做产品时的默认顺序，也很土：先把单任务的 context 和 harness 做扎实，再写带 verifier 的 loop，最后确实在需要的时候才拆 graph。

这和 Anthropic「先找最简单的解法」是同一条纪律，也和我在 Skill / Workflow / Agent 里说的「能降级就降级」同构：路径能画清、要审计的，上 Workflow + Skill；路径写不全、环境动态的，用小范围 Agent 加强 harness；要无人值守重复的，用 Loop；要多专长并行与汇合的，才上 Graph。

Graph 该不该上：三个问题比口号管用

Graph 最容易被包装成「更高级」。我见过太多 PPT 里画了六七个 agent 的漂亮拓扑，实际跑起来全是串行。我更建议拿三个问题过一遍：

• 任务是不是天然多专长？研究、写作、评审、测试要不要不同的工具集和成功标准？同一类活反复做，单 loop 通常更稳。
• 要不要显式路由与审计？合规、财务、发布闸这类场景，边和状态的分量比「让模型自由发挥」大。确定性节点，该手写就手写。
• 有没有独立的 verifier 节点？没有裁判的多 agent，干的是把错误复利从串行改成并行。生成是便宜的，判定够不够好才是贵的那一环。

三个问题里你哪个都答不硬，却已经在画六七个 agent 的漂亮拓扑，那就停一下。你多半在给自己制造分布式系统，编排谈不上。反过来，若单 agent 的上下文互相污染、串行太慢、关键步骤必须可回放，Graph 就有必要，跟炫技没关系。

收个尾

压成五句话：

• 跟 buzzword 接力没关系——这是失败成本上移之后，杠杆被迫外移
• 五层是嵌套关系，互相替代谈不上——烂 prompt 照样能毒死一张漂亮 graph
• 公开材料已经在收敛——Karpathy / Anthropic / LangChain / LangGraph 修的是同一栋楼
• 先标楼层再施工——听不懂、缺事实、长跑漂、等人启动、多角色打架，各自的手术方案不同
• 上 Graph 要克制——多专长、要审计、有独立 verifier，三条齐了再上；凑不齐，单 loop 更诚实

模型是发动机，但发动机自己赢不了比赛，车能。2026 年拉开差距的，是谁先把「失败变贵」的那一层，工程化成壳、循环与图。

公开参考：Karpathy、Anthropic context、Anthropic harness、LangChain harness、Loop engineering、LangGraph。

新词总会过时，失败账单不会。先找准自己卡在哪一层，再决定是改一句话，还是改整张图。