Peter Steinberger那条推文为何炸了整个AI工程圈Graph Engineering 系列课程 · 第1章第1节 · 课程导览这是 127 篇 Graph Engineering 系统课程的第一篇。我们从一个真实的故事开始——一条推文如何重新定义了 AI 工程的下一个范式。本文导航一、一条推文引发的地震二、Peter Steinberger 是谁他凭什么说这句话三、五层演进一部 AI 工程的断代史四、关键洞察组合不是替代五、Graph Engineering 到底在做什么六、为什么是现在七、这个课程要带你去哪里八、给不同背景的读者一、一条推文引发的地震2026 年 7 月 18 日一个普通的周五。我那天正在刷 Twitter/X突然看到一条推文像病毒一样刷屏了——“Are we still talking loops or did we shift to graphs yet?”—— Peter Steinberger (steipete)就这么一句话22 个英文单词没有任何技术细节没有任何代码截图甚至连个链接都没有。结果呢72 小时内 57.5 万次浏览1.2 万次转发评论区直接炸了。Andrej Karpathy 来点赞了。LangChain 的 Harrison Chase 转发了。LlamaIndex 的 Jerry Liu 在评论区写了一段长文。整个 AI 工程圈的顶流几乎都来打卡了。我当时看到这条推文的第一反应是这哥们到底在说什么第二反应是他说的好像是对的。第三反应是如果这是对的那我们过去半年做的所有事情都需要重新理解了。我随手翻了一下评论区好家伙简直是 AI 工程圈的百家争鸣。有个做 Agent infra 的老哥说“I’ve been building multi-agent systems for 8 months and kept feeling like I was using the wrong mental model. This is it. We need graph thinking.”——他说他做了 8 个月的多 Agent 系统一直觉得自己的思维模型不对现在终于找到了就是图思维。还有个搞学术的研究员回复说其实 multi-agent orchestration 在分布式系统领域早就有人研究了只不过之前不叫 Graph Engineering叫 workflow orchestration 或者 DAG-based execution。Peter 的贡献在于他用一个简洁的术语把这个概念带进了 AI 工程的语境里。当然也有反对的声音。一个做 LLM 研究的大 V 说“This is just another buzzword. Next month it’ll be something else.”——他说这就是又一个buzzword下个月又会有新词。但我觉得他错了。因为 buzzword 的特点是听起来很酷但没有实质内容。而 Graph Engineering 背后有真实的工程痛点、有具体的技术方案、有已经在跑的生产系统。它不是凭空造出来的词它是从实践中长出来的概念。你想想2026 年 6 月初的时候整个社区还在疯狂讨论 Loop Engineering——怎么让 Agent 跑起来一个observe → reason → act → inspect → repeat的循环怎么让 LLM 自己检查自己的输出怎么把单 Agent 的 loop 做到极致。结果才过了 6 周Peter 一句话就把话题推到了下一个维度别光盯着 loop 了该想想 graph 了。这不是在否定 Loop Engineering这是在一个更高的维度上提出了一个新问题。我当时就放下手机打开笔记本开始整理思路。因为我知道这不仅仅是一条推文这是 AI 工程范式演进的又一个信号弹。二、Peter Steinberger 是谁他凭什么说这句话先聊一下这个人因为不了解背景的话你可能会觉得这又是一个标题党。Peter SteinbergerTwitter 上的 ID 是 steipeteiOS 开发圈的老炮了。他创办了 PSPDFKit这家公司做了全球最流行的 PDF SDK 之一几乎每个 iOS 开发者都用过或者见过他们的产品。后来他把 PSPDFKit 卖了创办了一个新项目叫OpenClaw方向是 AI-native 的开发工具。关键点来了——Peter 不是那种只发推不写代码的 KOL。他是真正在生产环境里跑 AI Agent 的人。他的团队在做的事情是用 AI Agent 来自动化整个软件开发流程从代码审查到自动修 bug 到生成测试用例。他在做这些事情的过程中遇到了一个非常具体的问题当你只有一个 Agent 的时候loop 就够了。但当你的系统里有 5 个 Agent、3 个工具、2 个外部 API它们之间还有依赖关系和条件分支的时候loop 这个模型就不够用了。你需要一个更高级的结构来描述这些 Agent 之间的关系、数据流、控制流。你需要的是一个图Graph。所以 Peter 那条推文不是拍脑袋想出来的概念炒作而是他在实际工程实践中撞到了天花板之后发出的一个真实感叹。这也解释了为什么那条推文能引发这么大的共鸣——因为很多人已经在实际工作中感受到了同样的瓶颈只是没有人用一句话把它说出来。我后来在 Hacker News 上看到有人评论说“This is exactly what I needed to hear. I’ve been trying to explain to my team why our multi-agent system feels so wrong, and now I have the vocabulary for it.”——他说他一直在试图跟团队解释为什么他们的多 Agent 系统感觉哪里不对现在终于有了描述它的词汇。这就是好概念的力量。它不是告诉你怎么做而是给你一个思维框架让你重新审视自己正在做的事情。三、五层演进一部 AI 工程的断代史要理解 Graph Engineering 为什么会出现我们需要先回顾一下 AI 工程这个领域是怎么一步步走到今天的。我用一个比喻来讲这个故事。想象你有一个非常聪明但失忆的实习生。他智商极高理解力超强但每次你跟他说话他都像第一次见你一样。这就是最原始的 LLM。第一层Prompt Engineering —— 塑造指令最开始我们做的事情很简单想办法把问题说清楚。你给 LLM 一段文字它给你一段回答。你的工作就是把问题描述得尽可能精确让它给出最好的回答。这就是 Prompt Engineering。那段时间社区里到处都是100 个 ChatGPT 提示词模板、让 GPT 输出质量翻倍的 10 个技巧之类的文章。说实话现在回头看那些东西大部分都是在术的层面打转。但 Prompt Engineering 确实解决了一个根本问题它让我们学会了如何跟 LLM 说话。这就像你教那个实习生一样首先得学会怎么把任务描述清楚。你不能说帮我搞一下那个东西你得说帮我把这份 Excel 里的 A 列数据按日期排序然后生成一个柱状图。Prompt Engineering 塑造的是指令Instruction。第二层Context Engineering —— 塑造知识很快我们发现了一个问题光把问题说清楚还不够。那个实习生虽然聪明但他不知道你们公司的业务逻辑不知道上周开会讨论的结论不知道这个项目的技术栈是什么。你得给他提供上下文。于是 Context Engineering 出现了。RAGRetrieval-Augmented Generation、向量数据库、文档检索、对话历史管理……这些技术本质上都是在解决同一个问题怎么让 LLM 在回答之前先看到它需要看到的信息。2025 年中期“Context Engineering” 这个词开始被广泛使用。Andrej Karpathy 发了一条很有影响力的推文大意是Prompt Engineering 只是冰山一角Context Engineering 才是真正重要的部分。这条推文也火了。因为它说出了很多人的心声——你花 80% 的时间在准备上下文只花 20% 的时间在写 prompt。Context Engineering 塑造的是知识Knowledge。第三层Harness Engineering —— 塑造基础设施有了好的指令和充足的上下文你会发现下一个问题LLM 不是一个人在战斗。它需要调用工具函数调用、API 调用需要跟外部系统交互数据库、文件系统、浏览器需要处理各种格式转换JSON Schema、结构化输出需要管理 token 预算和成本。这些围绕着 LLM 的基础设施就是 Harness Engineering 要解决的问题。你可以把 Harness 理解为 LLM 的驾驶舱——LLM 是飞行员Harness 就是仪表盘、操纵杆、导航系统、通信设备。飞行员再厉害没有好的驾驶舱也飞不了长途。这个阶段各种框架如雨后春笋般冒出来LangChain 的 tool calling、OpenAI 的 function calling、Anthropic 的 tool use、各种 middleware 和 wrapper……它们本质上都是在做 Harness Engineering。Harness Engineering 塑造的是基础设施Infrastructure。第四层Loop Engineering —— 塑造运行时到了 2026 年中期一个关键的认知突破出现了。大家开始意识到LLM 不是一锤子买卖。你不能只是把 prompt 丢进去等一个回答然后结束。你需要让 LLM循环起来——观察Observe看看当前状态是什么推理Reason分析情况决定下一步做什么行动Act执行操作调用工具、生成代码、发送请求检查Inspect检查行动的结果判断是否达到目标重复Repeat如果没达到目标回到第一步继续这就是 Loop Engineering。Claude Code、Cursor Agent、Devin、OpenHands……这些 2026 年最火的 AI 编程工具核心架构都是一个 loop。它们不是问一次答一次而是持续运行一个循环直到任务完成。Loop Engineering 的革命性在于它把 LLM 从一个函数变成了一个进程。函数调用一次就返回进程可以一直运行。那段时间社区里到处都是关于 loop 的讨论怎么设计更好的 loop怎么让 loop 更稳定怎么处理 loop 里的错误恢复怎么让 loop 自己决定什么时候停下来Loop Engineering 塑造的是运行时Runtime。第五层Graph Engineering —— 塑造系统然后Peter Steinberger 发了那条推文。因为当你真正在生产环境里跑多个 Agent 的时候你会发现一个 loop 是不够的。你的系统里可能有一个负责代码生成的 Agent它有自己的 loop一个负责代码审查的 Agent它也有自己的 loop一个负责测试的 Agent同样有自己的 loop一个负责项目管理的 Agent它不写代码但它决定哪个任务分配给哪个 Agent各种工具、API、数据库它们被多个 Agent 共享这些 Agent 和工具之间的关系不是一个简单的 loop 能描述的。它们构成的是一个图Graph——有节点Agent、工具、数据源有边数据流、控制流、依赖关系有条件分支如果代码审查不通过回到代码生成有并行执行测试和文档可以同时进行。Graph Engineering 就是设计和构建这种多 Agent 系统的工程学科。它关注的不是单个 Agent 怎么运行那是 Loop Engineering 的事而是多个 Agent 怎么组织、怎么协作、怎么通信、怎么容错、怎么扩展。Graph Engineering 塑造的是系统System。Prompt Engineering塑造指令Context Engineering塑造知识Harness Engineering塑造基础设施Loop Engineering塑造运行时Graph Engineering塑造系统四、关键洞察组合不是替代讲到这里我必须强调一个非常重要的点因为这个点被太多人误解了。这五层是组合关系不是替代关系。我们发现了 Context Engineering 之后并没有停止写 Prompt。我们构建了 Loop Engineering 之后也没有丢掉 Context。每一层都是在下一层的基础上构建的它们层层叠加形成一个完整的工程体系。Graph Engineering └── 包含多个 Loop Engineering └── 每个 Loop 有自己的 Harness Engineering └── 每个 Harness 提供 Context Engineering └── 每个 Context 里包含 Prompt Engineering这就像 Web 开发的演进一样你有了 HTML 之后并没有丢掉它去做 CSS。你有了 CSS 之后也没有丢掉它去做 JavaScript。它们是层层叠加的每一层解决不同的问题。“We didn’t stop prompting when we found context. We didn’t drop context when we built loops.”这句话是我在整理这个框架的时候写下来的也是整个课程最核心的一个理念。当你进入 Graph Engineering 的世界你依然需要写好每一个 Agent 的 promptPrompt Engineering依然需要给每个 Agent 提供正确的上下文Context Engineering依然需要为每个 Agent 搭建好工具链Harness Engineering依然需要让每个 Agent 跑起自己的循环Loop Engineering。Graph Engineering 不替代前面任何一层它解决的是前面四层都解决不了的问题多个 Agent 怎么协同工作。五、Graph Engineering 到底在做什么说了这么多抽象的概念来点具体的。Graph Engineering 在实际工程中到底做什么我举几个例子。场景一AI 驱动的软件公司假设你要构建一个 AI 驱动的软件公司它有这些部门产品经理 Agent接收用户需求拆解成技术任务架构师 Agent根据技术任务设计系统架构前端 Agent写前端代码后端 Agent写后端代码测试 Agent写测试用例跑测试运维 Agent部署上线这些 Agent 之间的关系就是一个图产品经理 → 架构师 → [前端, 后端] → 测试 → 运维 ↑ | └── bug修复 ───┘怎么定义这个图怎么管理节点之间的数据传递怎么处理某个节点失败后的回退怎么支持动态添加新节点这些都是 Graph Engineering 要解决的问题。场景二用代码描述一个 Graph在 Python 里一个简化的 Graph 定义可能长这样fromdataclassesimportdataclass,fieldfromtypingimportCallable,AnyimportasynciodataclassclassAgentNode:图中的节点一个 Agentname:strhandler:Callable# Agent 的核心处理函数next_nodes:list[str]field(default_factorylist)condition:Callable|NoneNone# 条件分支函数dataclassclassAgentGraph:多 Agent 组成的图nodes:dict[str,AgentNode]field(default_factorydict)entry_point:strdefadd_node(self,node:AgentNode):self.nodes[node.name]nodeasyncdefexecute(self,input_data:Any)-Any:执行图从入口节点开始按拓扑关系执行currentself.entry_point resultinput_datawhilecurrent:nodeself.nodes[current]print(f[Graph] 执行节点:{node.name})resultawaitnode.handler(result)# 决定下一个节点ifnode.condition:currentnode.condition(result)elifnode.next_nodes:# 并行执行多个下游节点tasks[self._execute_subgraph(next_name,result)fornext_nameinnode.next_nodes]resultsawaitasyncio.gather(*tasks)resultself._merge_results(results)currentNone# 并行执行后结束else:currentNonereturnresultasyncdef_execute_subgraph(self,node_name:str,data:Any)-Any:递归执行子图nodeself.nodes[node_name]returnawaitnode.handler(data)def_merge_results(self,results:list)-list:returnresults这段代码展示了一个核心思想Graph 不是 loop 的升级替代而是 loop 的组织结构。每个 AgentNode 内部可以有自己的 loop但 Graph 负责的是这些 Node 之间的编排关系。场景三现实中的 Graph 框架目前社区里已经有一些框架在做 Graph Engineering 的事情了LangGraphLangChain 团队做的用图结构来编排 Agent支持条件分支、循环、并行CrewAI多 Agent 协作框架定义了 Agent 之间的角色和协作关系AutoGen微软多 Agent 对话框架Agent 之间可以互相发消息OpenAI Swarm轻量级的多 Agent 编排框架这些框架的共同点是它们都不再满足于单个 Agent 的 loop而是在更高层次上组织多个 Agent。这就是 Graph Engineering 的雏形。六、为什么是现在你可能会问多 Agent 系统的概念又不是新的为什么 2026 年才提出 Graph Engineering好问题。原因是之前没有这个需求。2024 年之前LLM 的能力还不够强单 Agent 都跑不稳定谈什么多 Agent2024 年到 2025 年大家在解决单 Agent 的可靠性问题——怎么让 Agent 不跑飞、不幻觉、能正确调用工具。这就是 Loop Engineering 和 Harness Engineering 的阶段。到了 2026 年单 Agent 的技术基本成熟了。Claude Code 可以连续工作几个小时不跑飞Cursor Agent 可以自动完成大部分编码任务Devin 可以独立处理一些简单的开发需求。当单 Agent 不再是瓶颈的时候多 Agent 的编排就成了下一个瓶颈。这跟软件工程的演进规律是一样的当单机性能不够的时候你想办法优化单机单 Agent 优化当单机优化到极限的时候你开始搞分布式多 Agent 编排Graph Engineering 就是这个分布式阶段的方法论。说个我自己的亲身经历。今年 4 月份的时候我接了一个项目客户想用 AI Agent 来自动化他们的内容审核流程。一开始我觉得很简单一个 Agent 加一个 loop 就搞定了——读文章、判断是否违规、输出结论。结果客户说不行我们有三种内容类型文字、图片、视频每种类型的审核规则不一样而且还需要一个仲裁 Agent来处理边界 case还需要一个统计 Agent来汇总每天的审核数据。我一算这至少需要 5 个 Agent它们之间还有复杂的依赖关系。用 loop 来描述根本描述不了。最后我是硬编码了一堆 if-else 来编排这些 Agent代码写得跟意大利面一样。当时我就想要是有个更好的方式来组织这些 Agent 就好了。两个月后Peter 发了那条推文。我看到的时候差点从椅子上跳起来——对就是图我需要的就是图所以对我来说Graph Engineering 不是一个抽象的学术概念它是一个我亲手撞到的工程问题然后被一个更聪明的工程师用一句话点破了。七、这个课程要带你去哪里好了故事讲完了来说说这个课程。这是我花了大半年时间整理的一套Graph Engineering 系统课程一共127 篇从基础概念到生产实践从单点技术到完整架构覆盖 Graph Engineering 的方方面面。我会按照下面的结构来组织第一部分认知篇第 1-10 篇把整个演进脉络理清楚让你知道我们从哪里来、要到哪里去。第二部分基础篇第 11-30 篇Graph 的基本概念、节点设计、边设计、状态管理、数据流……这些是基本功。第三部分框架篇第 31-50 篇深入分析 LangGraph、CrewAI、AutoGen 等主流框架的设计思路和实现细节。第四部分模式篇第 51-80 篇常见的 Graph 设计模式Pipeline、Fan-out/Fan-in、Hierarchical、Blackboard、Marketplace……第五部分实战篇第 81-110 篇从零构建一个完整的 Graph Engineering 项目包含代码审查、自动化测试、持续部署。第六部分进阶篇第 111-127 篇性能优化、可观测性、安全、成本控制、生产环境最佳实践……每一篇都会有代码示例每一篇都会讲为什么而不只是怎么做。我的目标是读完这个课程你就能设计和构建生产级的多 Agent 系统。不是玩具 demo不是 PPT 架构是真正能跑在生产环境里、能扛住真实业务负载的多 Agent 系统。八、给不同背景的读者如果你是资深开发者/架构师你会发现 Graph Engineering 跟你之前学过的分布式系统设计、微服务编排有很多相通之处但又有本质的不同——因为你的服务是有自主决策能力的 AI Agent。如果你一直在做 Prompt Engineering不要慌你的技能不会过时。Prompt Engineering 是 Graph 里每个节点内部的基本功。但你需要往上走一层理解节点之间的关系。如果你在做 Loop Engineering同样的道理loop 不会消失它会被嵌入到 Graph 的节点里。你需要学习的是怎么把多个 loop 组织起来。如果你是技术管理者这个课程会帮你理解团队未来的技术方向。多 Agent 系统不是遥远的未来它已经在一些前沿团队里落地了。小结让我们回到开头那条推文。Peter Steinberger 说的那句话——“Are we still talking loops or did we shift to graphs yet?”——不是在否定 Loop Engineering 的价值而是在提醒我们AI 工程的复杂度在持续增长我们的工程方法论也必须跟着进化。从 Prompt 到 Context从 Harness 到 Loop再到 Graph这五层演进不是后者替代前者而是后者包含前者。每一层都在解决上一层解决不了的问题每一层都建立在前一层的基础之上。Graph Engineering 不是终点。它只是当前阶段的最新认知。也许过不了多久又会有人发一条推文提出下一个层次的概念。但在那之前Graph Engineering 是我们能给出的最好的答案。而这个课程就是要帮你把这个答案变成你的工程实践。下节预告第 1 章第 2 节《一张图看懂Graph Engineering节点、边、状态与拓扑》范式讲完了下一节我们直接开拆图本身。节点、边、共享状态、失败路由——四大核心构件我用一家餐厅后厨的比喻给你讲透再配一张值得打印出来贴在显示器旁边的主图最后用 30 行 LangGraph 代码跑通你的第一张图不用 API Key零成本可运行。如果说这一节是开胃菜下一节就是第一道硬菜。互动区如果这篇文章对你有帮助请点赞 收藏 ⭐ 关注三连支持一下这个系列会持续更新 127 篇每一篇都是干货不水字数。有任何问题或者想法欢迎在评论区留言讨论。特别是已经在做 Agent 开发的同学你们在实际工作中遇到的多 Agent 编排问题都可以聊聊——说不定你的问题就是下一篇文章的素材。我们下篇见。顺便说一句如果你已经在做 Agent 相关的项目强烈建议你先通读一遍整个系列的大纲心里有个全局地图然后再回来从第一篇开始精读。这样效果最好至少我自己是这么学的。作者简介资深架构师多年分布式系统开发经验现专注于 AI Agent 系统架构设计与 Graph Engineering 工程实践。系列导航Graph Engineering 系统课程 · 共 127 篇 · 持续更新中关键词Graph Engineering、多Agent系统、AI工程化、Loop Engineering、Agent编排