graph engineering图工程就是把一个复杂任务从交给一个智能体从头干到尾改成拆给多个各有专长的智能体再用一张图把他们连起来协同。图里的节点是一个个干活的智能体边是他们之间怎么交接中间还有一份共享状态一路流动。2026 年 7 月中旬开始在 X 上被叫响而支撑这个名词的是一批早就跑通的工程做法。凡是认真用过智能体的人几乎都撞过同一堵墙。你派给它一个不算简单的活儿——查一堆资料、写成报告、再挑刺审一遍、最后决定发还是打回——它一开始干得挺好可越往后越像一个连轴转了十几个小时的人前面查的资料忘了一半写着写着跑了题自己审自己的稿子还总觉得哪儿都好。问题很少出在它不够聪明多半是这活儿压根就不该让一个智能体从头扛到尾。图工程给的正是这堵墙的解法——该拆的拆开该并行的并行该复核的另派一个专门的去查。今天我们就来说清楚三件事图工程到底是什么、为什么会在此刻冒出来以及两个你可能在用的 AI 工具Claude Code 的 dynamic workflow 和 Codex 的 multi-agent——是怎么把这套思路落到实处的。先把图这个字讲明白图工程听着玄乎拆开看其实只有三样东西。第一样是节点node。每个节点就是一个干具体活儿的单元通常是一个有专门职责的智能体——一个研究员、一个写手、一个审稿人——也可以是一段老老实实的确定性代码比如一次函数调用、一次工具请求、一次数据读取。关键在于每个节点只干一件事。第二样是边edge也就是节点之间怎么走。边可以是直的A 干完交给 B可以是有条件的审稿通过就发布、不通过就退回去重写可以是一分多一个节点同时点燃三个节点并行去跑也可以是多合一三份结果汇回到一处。第三样是共享状态shared state它是那个顺着边一路流动的对象装着任务本身、目前写到哪儿了、有哪些笔记、审出了什么结论。每个节点都从它这里读也往它这里写。有了这份共享记录一堆各干各的智能体才算真正连成了一个系统而不是一个转头就忘的临时群聊。图工程就是给智能体画组织架构图。一家公司不会让同一个人把调研、写作、审核一口气全包了而是拆成不同岗位让活儿在岗位之间流转结果层层汇总上来。智能体的图走的是同一个道理——专门的角色说好的交接一份共享的档案。下面这张是最经典的入门图研究员把笔记喂给写手写手交给审稿人审稿人这里挂了一条有条件的边决定是发布还是退回。你可以顺着箭头看状态是怎么一路长大的。三个节点几条边其中一条是有条件的判断一条是绕回写手的回环。状态一路往下流越流越厚研究员的笔记跟着到了写手手上写手的初稿又跟着到了审稿人那里审稿人的结论决定接下来走哪条边。有意思的是这套东西并没有把过去的经验推翻。一个单独在打转的智能体本质就是一张只有一个节点、还带着一条指回自己的边的图。你之前学的那些感知—规划—执行—检验的循环、什么时候该停、由谁来把关全都还在只是它们变成了单个节点内部的事。图工程管的是当你手里有好几个这样的循环、彼此需要交接时它们该怎么连起来。为什么偏偏是现在长成了这个样子要理解图工程为什么会冒出来得把这两年 AI 工程的重心挪动看成一条线。最早大家拼的是prompt提示词琢磨怎么把一句话问好。后来发现光问得好不够得管好模型看到什么于是有了 context上下文这一层。再往后重心挪到了harness脚手架——给模型配上工具、记忆和各种外围支撑。到了 2026 年初大家开始认真设计单个智能体的循环loop让它自己规划、动手、检验、返工。而到了 7 月重心又往外挪了一格落到了多个智能体之间怎么协调上这就是图。阶段你在设计的东西你的角色Prompt你发出去的那句话操作者Context模型能看到什么编辑Harness它周围的工具与支撑工具匠Loop单个智能体反复跑的循环系统设计者Graph多个智能体之间的协调组织设计者看这张表你会发现一个规律每往外挪一层你操心的东西就离模型本身更远一点而你手里的杠杆更大一点。图工程之所以长成现在这个样子核心就一句话——当一件活儿从一件事变成了好几件需要交接的事你还硬把它塞进一个循环里就是用错了容器。Loop Engineering 循环工程harness 怎么训练 harness这里得说句公道话。图这个东西一点都不新。有人直接开怼恭喜你重新发明了 LangGraph。这话基本没错。用节点、边和共享状态来搭智能体系统LangGraph、微软的 AutoGen、谷歌的 ADK 早在这个词流行之前就做了往上追甚至能追到几十年前的数据流架构、状态机和多智能体研究。所以真正在 7 月发生的谈不上什么新能力更像是一次命名事件一个憋了很久的设计问题终于有了一个能拿出来讨论的名字。名字本身可有可无但那个从一个循环一步步走向一张协调好的图的过程是真实存在的。主流 Agent 框架详解与对比技术深度分析与实战指南Multi-agent 为什么绕不开图工程聊到多智能体很多人第一反应是不就是多开几个智能体一起干嘛有啥好讲的。真上手你就知道多开几个和让它们协调好中间隔着的正是图工程。原因有这么几条每一条都很实在。第一条上下文会被撑爆单个智能体扛复杂任务问题很少出在它不够聪明多半是一个上下文窗口装不下这么多东西。查来的资料、中间的草稿、来回的讨论全堆在一处模型的注意力被稀释越到后面越糊涂。拆成图之后每个节点都有自己干净的上下文研究员只管研究写手只管写互不污染。第二条该并行的活儿不该排队干很多任务里有大段彼此独立的工作一个智能体只能一件件按顺序来可换成图你就能让一个节点一分多同时点燃几个子任务并行去跑再在某个节点汇合。这不光快有时候是唯一算得过账的做法。下面这张一分多、再合一的图是多智能体里最常见的形状第三条不同的活儿想用不同的家伙什调研也许需要联网搜索写作要换一套语气审核最好用一个只读、还是另一个模型的智能体来干——单个循环很难在中途切换模型和工具集图天然支持每个节点配自己的那一套。第四条也是我觉得最容易被低估的一条审核这件事最好交给别人在单个循环里是智能体自己检查自己的输出这就像让写稿的人自己当审稿人多半会觉得处处都好。图工程里可以专门立一个审稿节点用一个独立的、只读的智能体去挑另一个节点的毛病。这一条几乎是整张图里价值最高的设计。第五条出了错能兜得住在一个循环里一步走岔可能把整段上下文都带偏。而在图里你可以做到一个节点失败了就地重试、或者转到备用节点、或者升级给人来看而不至于污染下游、连累全局。多智能体真正难的地方从来都不在多开几个而在于谁负责什么、谁能和谁说话、活儿按什么顺序流、大家共享哪一份状态。这些恰恰就是图工程要回答的问题。Claude Code 的 dynamic workflow让智能体自己写包工头Claude Code 在 Opus 4.8 一起推出的dynamic workflow动态工作流。它的设计有一个很聪明的地方。平时你用 Claude CodeClaude 自己就是那个包工头orchestrator一步步决定下一个该派谁、干什么而每一步的中间结果都堆回它自己的对话里。任务一大这个对话就被各种中间产物塞满了。dynamic workflow 换了个思路让 Claude 先写一段 JavaScript 脚本由这段脚本来当包工头。循环、分支、中间变量全都装在脚本里Claude 自己的上下文最后只留一个干净的结论。这段脚本靠几个很小的原语来指挥智能体理解了它们你基本就懂了这套东西agent(prompt, opts)派出一个子智能体去干一件事。它有自己独立、干净的上下文干完只把最终结果交回来——如果你给了 schema交回来的还是一个校验过结构的对象下游可以直接放心地取字段用。这就是那个一个智能体、一个干净上下文、一个目标的最小工作单元。parallel(thunks)一次点燃一批任务然后等它们全部干完再往下走。这个等是它的灵魂——它是一道栅栏。只有当下一步确实需要拿到前面所有结果时比如要在整批里去重、或者互相比对你才用它。pipeline(items, ...stages)让每个条目独立地穿过每一道工序中间不设栅栏。A 条目可以已经跑到第三道工序了B 条目还卡在第一道。大多数多阶段的活儿其实不需要互相等所以这才是更常用的默认选择。phase(title)把一组智能体归到一起方便你在界面里盯进度。这里还藏着一个容易被忽略、但特别关键的设计约束脚本必须是确定性的里头不能有Date.now()、Math.random()这种每次都变的东西。为什么因为这套运行时支持断点续跑——一个跑了一半被打断的工作流重启时会从头把脚本重放一遍已经跑完的agent()调用直接复用缓存好的结果。要是脚本里有随机项重放时分支就走岔了缓存的结果和新的执行路径对不上。是确定性让续跑变得安全。这是很典型的图工程思维不光设计正常怎么跑还得设计断了之后怎么接。对着前面那三样东西看agent就是节点parallel/pipeline就是边栅栏式的合流、流水线式的并行脚本里传来传去的那些变量和 schema 就是共享状态。名字换了骨架是一模一样的。Claude 官方还总结了几种常用套路最典型的两个一个是分治再汇总——把大任务切成一堆小步每步派一个智能体、各用一块干净上下文去跑最后设一道栅栏把结构化结果合并另一个是竞标——同一个活儿派 N 个智能体用不同思路各做一版再让一个裁判智能体两两比、评出个赢家。这套东西能铺多大官方给的数字是单次 run 最多能并发 16 个智能体、累计最多 1000 个。Anthropic 自己就拿它来跑/deep-research、做大规模代码迁移、审计整个代码库连 Claude 的安全插件做多智能体漏洞扫描底下撑着的也是这套 workflow。这些活儿的共同点很清楚——阶段多、要交叉验证、还得能复跑恰好是脚本化编排最擅长的地方。Codex 的 multi-agent一棵会自己长出来的智能体树再看 OpenAI Codex 这边。它的路子和 Claude Code 有点不一样更偏向由模型自己在运行时开枝散叶。Codex 里有一个父会话它可以按需生出一批专门的子智能体让它们并行去干等结果回来再综合成一个最终答复。整个协调过程主要靠这么几个动作spawn_agent开一个新的子智能体去接一个具体任务send_message往某个智能体那儿塞条消息但不触发它开跑followup_task是塞消息并且让它开跑wait_agent让父会话停下来等子智能体们都跑到终态还有list_agents用来看看这棵树上现在都有谁在跑。和 Claude Code 那种预先写好一整段脚本不同Codex 的这些动作是模型一边想一边发出来的它们以工具调用的形式出现在父智能体的推理链里。换句话说你是用提示词去引导它而不是自己写代码去接线。你直接说一句给每个评审点各开一个智能体全部等齐了再逐个总结Codex 就会一个点开一个线程最后合并给你。到 2026 年年中Codex 的这套东西分成了两层。MultiAgentV1偏手动靠开发者在 TOML 配置里声明好每个智能体的角色、用哪个模型、花多大推理力度指令都是明文存着的。MultiAgentV2则更自动由运行时自己去分配调度也是 GPT-5.6-Sol、Terra 这些新模型的默认选择它的委派消息在 OpenAI 的基础设施上是加密的所以在本地的审计日志里看不到具体指令内容。Codex 还给这套东西上了几道很实在的限速这恰恰是图工程里成本控制的体现。并发数默认被agents.max_threads默认 6卡住嵌套深度被agents.max_depth默认 1卡住。官方特意提醒把嵌套深度往上调很诱人、但很危险因为一句宽泛的委派可能层层裂变成反复的一分多token 消耗、延迟和本地资源占用都会跟着往上窜。它还有个spawn_agents_on_csv的批处理工具能把一个 CSV 文件里每一行都扇出给一池并行的工人智能体去处理各自把结果写回。实际用起来Codex 的多智能体主要招呼那些能拆开、又能并行的活儿探索一个陌生代码库、审一个 PR、并行开发几个特性或者挂在后台跑长任务。在桌面应用里这些并行工作被拆进各自的 project、thread 和 worktree一份份独立的工作副本几个智能体同时改一个仓库也不至于打架。说到底Codex 干的也是同一件事父智能体是包工头spawn_agent生出节点wait_agent是那道合流的栅栏子智能体各自干净的上下文加上综合汇总就是共享状态的流转。它和 Claude Code 的区别主要在于图是预先写死在脚本里还是由模型在运行时边想边长出来。Claude Code · dynamic workflowCodex · multi-agent谁当包工头Claude 现写的一段 JS 脚本父会话自己模型驱动图怎么来的预先写进脚本确定性运行时边推理边生成怎么指挥agent/parallel/pipeline/phasespawn_agent/wait_agent/send_message/followup_task一大长处可复现、能断点续跑灵活跟着任务形状随时变你怎么介入描述任务、能重跑脚本用提示词引导、可中途干预市面上其实有两个图工程这里得提醒一句免得你回头去搜的时候被绕晕。Graph engineering 这个词今天挂着两层意思指的是两拨人干的两件不太一样的事。一层是数据意义上的图把现实世界里的实体和它们之间的关系直接建成节点—边—属性的结构来存、来查、来算。知识图谱、图数据库比如 Neo4j 那套用 Cypher 查询的属性图或者 W3C 那套 RDF 三元组、图算法乃至在图上做学习的图神经网络GNN都归在这一层。它回答的是这个系统知道些什么、这些东西之间怎么牵连。另一层就是这篇文章一直在讲的执行意义上的图——把智能体、工具、状态、审批、消息流显式地摆成一张能跑的图。它回答的是这个系统由谁组成、活儿怎么在他们之间流动。一个好记的说法数据图管的是系统知道什么执行图管的是系统是谁。两者能在同一个架构里并存各答各的问题。这篇文章的主线是后一个但下面这些真实落地的例子会让你看到前一个早就在闷声干大事了。跳出智能体圈图工程早就在挣钱智能体编排是图工程最新、最热闹的用法可拿图来解决问题这件事在别的领域已经安安静静赚了很多年钱。它们背后其实是同一句话有些难题的本质是关系密集型推理——谁和谁有牵连、钱从哪儿流到哪儿、这条依赖链动一处就牵全身。这类问题用图来表达比拆成一张张表再回头拼关系要近得多。Neo4j 讲反欺诈时打过一个比方识别一个欺诈团伙说到底就是在图上走一圈。几个真实的例子数字都挺能说明问题。搜索和企业知识问答这块微软的 GraphRAG 先让大模型把资料自动抽成一张知识图再靠社区发现和分层摘要去回答那种得通览全局才答得上来的复杂问题这恰恰是普通向量检索很难啃下的。推荐这块Pinterest 的 Pixie 系统跑在一张 30 亿节点、170 亿条边的对象图上做实时推荐论文里报告相比旧系统最高带来 50% 的互动提升单机延迟压到 60 毫秒级。金融风控这块法国巴黎银行旗下的消费金融公司公开过一个案例用 Neo4j 的图做反欺诈把欺诈降了两成最大延迟约 2 秒。生物医药这块DGL 团队放出过一个叫 DRKG 的生物知识图把基因、药物、疾病、副作用连成了 9 万多个实体、580 多万条关系专门用来做老药新用的药物重定位。还有软件供应链GitHub 的依赖图dependency graph和 CodeQL本质上就是把代码之间的依赖关系、程序语义和数据流显式建成图再拿去定位漏洞、治理供应链风险。图工程真正的底色是把关系这件事从藏在数据缝里的隐性信息变成可存、可查、可算、可追溯的一等公民。智能体编排只是这条老路上最新长出来的一段。两个图怎么合体知识图给多智能体当共享大脑前面聊多智能体时说它的第一个坎是上下文被撑爆。这里正好接上——这个坎有一个挺漂亮的结构性解法来自 Anthropic 的一份知识图工程 Playbook而它恰好就是前面那两个图合体的地方拿一张数据意义上的知识图去给一套执行意义上的多智能体当地基。先把这个坎说透。多智能体最根本的软肋是每个智能体的记忆都随着它那个上下文窗口一起消失。拿一个做竞品分析的系统来说五个 worker 各看一摊资料定价、产品、财务、市场各管一块最后得有一个综合的智能体把跨来源的线索串成一句话——那家降价 15% 的公司正是专利显示要开新品线、财报显示研发翻倍的同一家。可这三条事实没有任何一个 worker 同时看到过。要是大家都靠主控orchestrator的上下文转发摘要那个窗口会随 worker 数量线性膨胀迟早超过再大的模型也装不下的极限。解法是给这套系统垫一层共享的知识图每个 worker 把自己的发现写成实体 关系存进图里那个综合的智能体不去重读原文只在图上遍历就能把散落各处的线索连起来中间那些庞杂的上下文一概不用背。在多智能体里这张图能扮演三个角色个个关键。一是共享记忆worker 们共同读写同一张图替掉那种靠主控转发摘要、又脆又堵的老办法。二是事实校验的依据跑生成—评审这类循环时评审的智能体可以拿生成方的每一句话去图上对边、查出处把判断从看着像不像对升级成到底是不是真的。三是跨会话的持久世界模型一个挂着跑通宵的循环上下文一遍遍被清空可图还在——用那份资料里的话说智能体会忘图不会。建这张图的成本这几年也掉得很厉害。过去要建知识图得先训一个命名实体识别模型、再训一个关系分类模型、还要手写一堆实体消歧规则换个领域就得从头再来。现在这一整条经典流水线被 Claude 拆成了几段带结构化输出的提示词抽取用便宜的 Haiku 跑量、消歧用更会推理的 Sonnet 做判断、组装、查询。真正意义上的训练数据就剩一个描述数据长什么样的 schema。顺带回答一个常被问到的问题知识图和 RAG向量检索到底什么关系简单说RAG 擅长答案就摆在某一段文字里的单跳问题可一旦答案得靠串联好几篇彼此毫不相似的文档才能拼出来多跳RAG 就接不住了而图里那个把两篇文档连起来的实体节点恰好能顺着边走通。两者是互补的RAG 负责快检索知识图负责结构化的推理。最实在的好处在最后图上答出来的每一句都能指回具体的那条边、那份来源文档。在你自己的私有资料上这种带出处、可追溯的答案才真正靠得住。也难怪 Anthropic 自己的数据说在那种需要同时铺开好几个方向的任务上多智能体能比单智能体强出九成代价是要多烧十几倍的 token——而知识图正是给这份高昂的上下文开销准备的一套结构化解法。你的智能体为什么总是忘记你说过的话智能体开始进入「复盘 — 评测 — 改进」的循环优势与劣势都摆到台面上先说图工程好在哪。它把过去藏在提示词里、靠模型自由发挥的那些路径变成了明明白白、可以审计的结构。你能画出来、能静态地推敲、能一个节点一个节点地去看谁花了多少钱、跑了多久、用了哪个模型。它让专精成为可能——每个节点用最合适的模型和工具。它让并行成为可能——该同时干的活儿不必排队。它还让把关变得独立——审稿的和写稿的不再是同一个。对那些跨领域、要并行、还会随时变形的活儿这套结构是实打实的解药。但劣势同样得说清楚而且这一点比优势更重要。绝大多数任务压根用不着图。X 上对这个词的嘲讽来得几乎比这个词本身还快而且开炮的都是懂行的人——有 XState 状态机工具的作者有做多智能体协议 A2A 的人。他们的意思很一致有向图、状态机这些东西是几十年的老计算机科学了把它当成七月的新发现来吹多少有点营销的味道。这些话该听进去。Agent2Agent 协议AI 智能体协作的未来更实在的风险是过度设计。举个例子帮我把这份 PDF 总结一下你却给它搭了个五节点的图一个抓取、一个切块、一个总结、一个审核、一个排版还配上有条件的边和共享状态对象。它确实能跑可它比那件本该做的事——一个智能体读完文件、写个总结——搭起来更慢、更难调、跑起来更贵。你为了回一封邮件硬生生画了一张组织架构图。还有几个坑也值得记住图是很多个循环的叠加一个不靠谱的审核节点会在并行里成倍地烧 token所以成本必须显式地设上限共享状态如果没规定好谁能写很容易慢慢漂移到一团乱而如果你的每个节点本身就是个弱智能体把它们连成组织架构得到的也只是一个弱组织。下面一层没打牢上面这层图只会以一种更花哨的方式失败。往数据图那一侧看账也不轻松建模门槛不低属性图和 RDF 是两套不同的生态、Cypher 和 SPARQL 是两种查询语言工具链天生就碎更要紧的是图里的关系结构本身就是敏感信息——谁能遍历哪些边、看到哪些属性都得有细粒度的权限管着。Neo4j 官方专门强调过这点节点、关系和可遍历的路径都需要单独的访问控制。智能体这边同理运行时留下的 trace 里往往带着大量业务上下文也该按最小权限和脱敏来管。Token 这门生意账单最后寄给了谁所以判断要不要上图有个特别朴素的检验你要搭的这张图是不是在干一件循环干不了的事如果你能把五个节点重新塌回成一个智能体的循环、还啥都不少那你就该塌回去。什么时候才真该请出图工程综合下来判断标准可以压成几个信号。当活儿明显裂成了几个会互相交接的专业分工、当你需要一分多地并行再合流、当不同步骤要用不同的模型或工具、当你需要明确可审计的路由而不是让智能体自由乱走、当你希望一个节点崩了不连累其他、当你需要一个专职的审稿人去查另一个节点的活儿——这几条里要是大部分都戳中了图才真正值回它的复杂度。反过来一个范围清楚、有明确验收标准的单一任务它就是一个循环在这儿上图纯属给自己添乱。还有一种情况也别硬上要是几个智能体必须频繁地改同一份共享状态、你争我抢那强顺序的单代理、甚至一个老老实实的状态机往往比图化编排更稳。OpenAI 官方也提醒过多智能体擅长的是独立、有边界的任务最怕的就是大家一起反复写同一块可变状态。一个能落地的顺序是这样的先想尽办法把它保持成一个循环一个智能体配一个好的验收标准能搞定就到此为止实在裁不动了再给真正的专业分工各起一个节点动手写代码之前先把边画在纸上顺序的、并行的、汇合的、那条唯一的回环边一张餐巾纸画不下就说明太复杂了然后把共享状态设计清楚规定好谁能写给审稿节点配上真牙齿让它独立、只读再确保单个节点能失败重试而不污染全局最后能用现成框架就别自己造运行时该设的成本上限一个都别省。如果你要搭的是个正经的生产系统还有个分层的思路值得记在心里把知识图实体和关系、执行图智能体、任务、依赖、观测图trace、成本、审批、失败三样东西分开来放。分开的好处一是权限好隔离二是日后优化和审计都有地方下手——哪个节点贵了给它换个便宜模型哪条子任务老翻车就单独盯着一目了然。顺着往下看会走到哪儿图里的节点正在悄悄升级。早两年一个节点里装的多半是一段确定性代码或者一次模型调用而现在一个节点里越来越常装的是一整个能自己规划、动手、检验的子智能体。用 LangChain 官方的说法今天图里的一个 node完全可以就是一次完整的 agent run。配套的两个苗头也已经能看见。一个是分工上的精打细算让强模型专门做规划把便宜的小模型派去做探索和打杂的子智能体Codex 和 Claude 都已经支持把子智能体路由到更省钱的模型。另一个是把观测、护栏、人工审批这些原本的附加功能直接做成图里的节点和边——该审批的地方就摆一道审批节点让约束长在结构里而不是飘在提示词里。回到开头那个连轴转、忙不过来的智能体。它给我们上的那一课其实和管理团队是相通的一个人再能干也扛不下一整个需要分工协作的项目真正的本事是把活儿拆成清楚的角色安排好谁先谁后、谁把关、大家共享哪一份信息。图工程说到底就是把这套朴素的管理常识翻译成了智能体能执行的结构。Claude Code 让智能体自己现写一段脚本来当包工头Codex 让父会话在运行时自己长出一棵智能体树路子不同骨架一致——都是节点、边和共享状态。名字新不新、火不火其实没那么要紧。要紧的是当你下次又看着一个智能体在复杂任务里越绕越晕时你能认出来这不是它不够聪明是这活儿该拆了。而拆得好不好考验的从来都不是你会不会写花哨的提示词是你有没有想清楚——这件事到底该由谁、按什么顺序、共享着什么一起把它干完。