-UyNj.png)
一、九个词引爆的范式讨论
2026 年 7 月 18 日，OpenClaw 创始人 Peter Steinberger（江湖人称"龙虾之父"）在 X 上发了一条推文，只有九个词：
"Are we still talking loops or did we shift to graphs yet?" （我们还在讨论循环，还是已经转向图了？）
两天内 260 万浏览，评论区一半困惑一半会心。
微妙的是时间点——仅仅六周前（2026 年 6 月），他刚用另一条推文（840 万浏览）引爆了"循环工程（Loop Engineering）"的讨论：
"你该停止亲自给编程 Agent 写提示词了。你该设计循环来替你提示 Agent。"
社区刚给这套实践起了名字、写了博客、办了大会——结果"保质期"只有一个月。
但这真的只是又一个流行词的诞生与速朽吗？不是。这条推文之所以能引发如此强烈的共鸣，是因为它踩中了整个 AI 工程领域一条已经静悄悄演进了四年的主线——每一次被"工程化"的对象都在上移一层。
本文试图把这条主线完整拆解：从 Prompt 到 Context，从 Context 到 Harness，从 Harness 到 Loop，再到此时此刻正在发生的从 Loop 到 Graph 的转折。同时，我也把本周（2026-07-18 ~ 2026-07-24）AI 领域最重要的事件做一个汇总——这周很可能是会被后续写进 AI 工程史的一周。
二、一条清晰的演进主线
第〇层 · Prompt Engineering（2022–2024）
核心问题：怎么让模型一次回答得更准确？
这是大多数人与 AI 的第一次亲密接触。2022 年底 ChatGPT 横空出世，整个行业学到的第一个技能就是"写提示词"。角色设定、Few-shot 示例、Chain-of-Thought 引导、输出格式约束——这些今天看来基础得不能再基础的手段，在当时就是决定模型"能回答"和"回答得好"之间的全部差距。
关键人物：没有明确的命名者，这是整个社区在黑暗中摸索出的第一条路。OpenAI 后来发布的《Prompt Engineering Guide》系统化了这套方法论。
贡献：让模型输出从"随机鹦鹉"变成了"可控生成"。角色设定让模型知道自己是客服还是分析师；CoT 让它在复杂推理中保持条理；few-shot 让它在零训练成本的条件下学会新任务的格式。
天花板：
信息孤岛——模型不知道你的业务数据。你再怎么优化措辞，模型也不知道你的退款政策是什么。
无记忆——每一轮对话从零开始。上一轮的洞察全部丢失。
人是瓶颈——Agent 的吞吐量等于人的带宽。你手动触发一次，它执行一次。
一句话总结：Prompt Engineering 教会了 AI "按你说的回答"，但没有教会它"知道你不知道的"。
第一层 · Context Engineering（2025）
核心问题：怎么让模型在正确的信息环境下做决策？
2025 年 6 月，Andrej Karpathy 发了一条简短推文：
"I'm actually more of a fan of 'context engineering' than 'prompt engineering'."
这条推文引发了行业层面的范式转移讨论。三个月后，Anthropic 发布了《Effective Context Engineering for AI Agents》工程博客，给出了正式定义：Context Engineering 是策划和维护最优 token 集（信息）的策略集，包括 prompt 之外落入 context 的所有其他信息。
关键转变：问题从"怎么说"变成了"模型看到什么"。
核心技术手段：
RAG（检索增强生成）：不把整个知识库塞给模型，而是语义检索最相关的文档片段
MCP（Model Context Protocol）：Agent 通过统一接口连接外部数据源和工具
Message History 管理：滑窗、摘要压缩、优先级排序来维持 context 质量
Tool Schema 精简：只暴露当前任务需要的工具子集
关键人物：Andrej Karpathy（概念倡议者）、Anthropic（正式定义并发布工程指南）
贡献：Agent 从"通用对话"变成了"业务助手"。接入了企业知识库后，它的回答不再是通用常识，而是基于具体业务数据的有依据回答。
天花板：
"手"不受控——Context Engineering 管的是输入侧（模型看到什么），但模型看到正确信息后仍可能做出错误行动：调错 API、输出不合规代码。
错误不会自愈——Agent 犯了错，没有机制发现和纠正它。同样的错误下次还会出现。
仍依赖人工触发——Agent 是更聪明的工具，但你仍然握着它。
一句话总结：Context Engineering 让 AI "知道你不知道的"，但没教会它"在知道的基础上做正确的事"。
第二层 · Harness Engineering（2026 年 2 月）
核心问题：怎么让 Agent 在运行环境中结构性不可犯错？
2026 年 2 月 5 日，HashiCorp 联合创始人、Terraform 缔造者 Mitchell Hashimoto 发表了博客《My AI Adoption Journey》，正式提出了"Harness Engineering"这个概念。他的定义只有一句话：
"Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future." （每当 Agent 犯了一个错误，你就花时间去工程化一个解决方案，让它再也不会犯同样的错误。）
Harness（马具/挽具） 这个词用得极其精准——就像驯马不是限制马的能力，而是让马的能量能被有效引导。Harness Engineering 不是限制 Agent，而是通过积累约束让 Agent 更可靠。
六天后，OpenAI 发布了实践报告：一个 3-7 人小团队，在五个月内用 Codex Agent 构建了约一百万行代码——零行手写代码。核心发现掷地有声：
"Early progress was slower than we expected, not because Codex was incapable, but because the environment was underspecified." （不是模型不行，是环境没配好。）
LangChain 用一个公式做了最简洁的凝练：
Agent = Model + Harness
Harness 的五大核心组件：
核心人物：Mitchell Hashimoto（概念命名与定义）、OpenAI Codex 团队（实践验证）、Martin Fowler 团队（跟进深度分析）
贡献：把"确定性约束"引入 Agent 工程。不再是概率性地"希望"模型遵守规则，而是通过 linter 封死错误写法、通过 test gate 阻止不合格输出。
天花板：
仍无人值守——Harness 解决的是单次运行的可靠性，但启动它的仍然是人。
缺少目标层面的闭环——Agent 能做到"这次做对"，但做不到"下次做得更好"。
任务发现仍是手工的——谁来决定 Agent 下一步做什么？还是人。
一句话总结：Harness Engineering 给 AI 装上了"马具"，让它跑得又快又稳，但缰绳还在人手里。
第三层 · Loop Engineering（2026 年 6 月）
核心问题：怎么设计一个系统，让 Agent 自己驱动自己直到目标达成？
这是过去六周最热的 AI 工程话题。
故事要从 2025 年 7 月说起。软件工程师 Geoffrey Huntley 提出了一种被他称为 "Ralph" 的方法——一个简单的 Bash 循环：
while :; do cat PROMPT.md | claude-code ; done
核心思想：绕过上下文窗口的限制。每次用全新上下文启动 Agent，将已完成的工作以"压缩"形式（日志、更新后的计划）持久化到文件系统。Huntley 用这个方法从零构建了一门编程语言。
这个方法在 2026 年更强模型出现后，开始在开发者圈子里病毒式传播。
关键引爆事件：2026 年 Anthropic 开发者大会。Claude Code 创始人 Boris Cherny 站在台上说：
"I don't prompt Claude anymore. I run loops that prompt Claude and decide what to do next. My job is to write loops." （我不再提示 Claude 了。我设计循环来提示 Claude，然后判断下一步做什么。我的工作是设计循环。）
紧接着，Peter Steinberger 发文呼应：
"Monthly reminder: you should no longer prompt programming agents yourself. You should design loops that prompt agents."
前 Google 工程师 Addy Osmani 随后写了一篇专题文章《Loop Engineering》，正式总结了这套方法论。
产品化落地：2026 年 4-5 月，Codex、Claude Code、Hermes 相继推出 /goal 命令，将手工编写的循环产品化为一条指令。Codex 文档对其描述是：
"A regular prompt says: do this next. A Goal says: keep working until this outcome is true."
（普通 prompt 说：下一步做这个。Goal 说：持续工作直到这个结果为真。）
一个典型的 Loop：
触发（定时器/事件/上一轮产出）
行动（Agent 读取上下文、使用工具、产生输出）
验证（测试通过？条件满足？人工批准？）
决策（不满足 → 带着新上下文重试；满足 → 退出）
贡献：让 Agent 从"执行一个任务"进化到"自主推进一个目标"。人彻底退出执行环节，只保留目标设定和验收权。
天花板——四个结构性失效：
状态不透明——循环的状态就是一个不断膨胀的消息数组。出错了只能翻对话记录。
无检查点——跑到第 40 分钟崩溃，从头再来。
爆炸半径无限——循环理论上可以调用任何工具。安全团队想要的是"系统能做什么的显式地图"。
人机交互尴尬——为等一个三天审批而暂停 while 循环？没有一等语义的恢复机制。
一句话总结：Loop Engineering 让 AI "自己推动自己直到目标达成"，但当目标复杂到需要多人协作时，单一的循环开始力不从心。
第四层 · Graph Engineering（2026 年 7 月 — 进行中）
核心问题：怎么设计多个 Agent 之间的协作结构？
这就是 Peter Steinberger 本周推文引爆的新范式。
核心洞见：循环（Loop）适合描述单个 Agent 如何反复执行——"观察→计划→行动→验证→重试或结束"。但真实任务很少永远保持单线程。一次线上故障可能同时需要查日志、核对数据库、回滚版本、通知业务。任务会分叉、汇合、暂停，也会因为新证据而改变方向。
社区最佳评论来自 Luis Catacora：
"Loops are forgiving. Graphs force you to admit how much of the workflow you haven't actually modeled yet." （循环是宽容的。图迫使你承认自己还有多少工作流程根本没建模。）
一个循环让你推迟架构决策——一个 Agent 处理一切，直到它处理不了。一张图要求你提前声明结构：谁负责什么、依赖关系是什么、分支失败时怎么办。
两张图，不是一张图
Google 高级 AI 产品经理 Shubham Saboo 给出了最清晰的结构分解：
组织图（Org Graph）——长期存在的 Agent 组成，各自负责固定领域，保留该领域的上下文、专业能力和工具权限。相对稳定，类似公司的组织架构。
工作图（Work Graph）——针对当前任务动态生成，定义"现在要做什么以及任务如何流转"。随着新证据出现，可以拆分、合并、重排序或直接取消。
这两张图运行在不同的时间尺度上。组织图被预先设计并部署，工作图针对每项任务动态生成、任务完成后即丢弃。
Graph 的核心原语：
节点：每个节点是一个 Agent，运行自己的循环
边：定义数据流和依赖关系
类型化状态：Pydantic 模型或 TypeScript 接口，而非消息 blob
检查点：事件溯源快照，支持"时光旅行"调试
中断与恢复：一等公民，支持人类审批介入
关键基础设施：
LangGraph 1.0（2025 年 10 月 GA，12.6 万+ GitHub 星）
微软 Agent Framework（AutoGen + Semantic Kernel 整合）
Mastra（30 万+ 周 npm 下载量）
工作图生成器：根据输入任务动态生成工作图
"Loop 对 Graph" 是个伪命题。 图里面本来就包含循环——循环只是图里"修复→测试"之间的重试路径。图是整张地图，循环是地图上的一小段。
三、五层演进的全景对比
关键认知：这五层是嵌套关系，不是替代关系。
每新的一层不取消旧层，而是在旧层之上增加新的工程维度。没有好的 prompt，Context Engineering 就是无源之水；没有 Context，Harness 就管不住一个信息不足的 Agent；没有 Harness 的检查机制，Loop 就会越跑越偏；没有 Loop 的自驱力，Graph 里每个节点都不会自己转。
四、对开发者的实际启示
1. 别被术语带走
Graph 不是全新的东西。工作流 DAG、状态机、Actor 模型已经存在多年。真正的新鲜事是——模型能力足够强了，强到这些经典工程结构在"每个执行步调用 LLM"这个新前提下需要被重新审视。
2. 决策树很清晰
Andrew Ng 的框架依然实用：
✅ 单域自主任务 → 一个 Loop 就够了
✅ 多 Agent、分支逻辑、跨会话持久状态 → 上 Graph（LangGraph 或等价的图运行时）
✅ 定时/事件触发的后台工作，有界范围 → Linear Loops 模型
3. 先走下去，再走上去
如果你们的团队还在 Prompt Engineering 阶段，不用焦虑。把 prompt 写好、把 RAG 搭好已经能创造大量价值。但要知道，每一层都在解决上一层的瓶颈——当你发现 Agent"该知道的都知道了，但还是会犯同样的错"时，你就知道自己该向上走一层了。
4. "Loop 和 Graph 只会共存，不会替代"
这是本周讨论中我最认同的一个判断。循环是图里"修复→测试"之间的重试路径。图是整张地图，循环是地图上的一小段。绝大多数场景下，你的系统需要的是"装了 Graph 骨架的 Loop 系统"，而不是二选一。
五、结语与预告
Peter Steinberger 的九个词之所以能引爆行业，不是因为它发明了什么，而是因为它精准命名了一个每个人都在隐隐感觉到的转折点。
从 Prompt 到 Context，从 Context 到 Harness，从 Harness 到 Loop，再到此刻的 Graph——AI 工程的"能力重心"在持续上移。开发者越来越不需要关心如何与单个 Agent 对话，越来越需要思考如何设计 Agent 之间的协作结构。而下一步（已经有人在讨论了），是动态 Agent 组织——运行时系统自行改写自身的架构。
正如 Karan Singh 在评论区中精辟所言：
"Sub-agents with a defined purpose is a Graph. But yeah lets confuse everyone and call it a net new thing." （有明确目的的 Sub-agent 就是 Graph。不过好吧，让我们把它叫成一整个新东西来制造混乱。）
他没错——底层概念不是新的。真正新的是执行层：模型已经强到可以在图结构中可靠运行，框架已经成熟到可以把它们拼在一起，而实践者社区已经大到能形成共享的工程词汇。
这不是 Instagram 滤镜式的概念更替。这是一场正在发生的工程范式转移。
本文基于以下来源综合撰写：Peter Steinberger (@steipete) X 推文及评论区讨论；Mitchell Hashimoto《My AI Adoption Journey》；OpenAI《Harness Engineering: Leveraging Codex in an Agent-First World》；Anthropic《Effective Context Engineering for AI Agents》及 Claude Code 相关文档；ExplainX.ai 系列分析文章；InfoQ/36氪/TonyBai/掘金社区报道；Luis Catacora、Shubham Saboo、Karan Singh 等 X 讨论贡献。