大多数构建者仍把AI agent设计成一条直线：先研究、再写作、再审核、最后发布。每一步都在等前一步结束，即使其中一半根本不需要前序结果。系统不会分支，不会并行，不知道如何恢复，只是不停往同一个上下文窗口里塞内容，直到agent变慢、变糊涂或变贵。

问题已经不在提示词，而在工作本身的形状。这正是图工程要解决的事。

我起初以为把提示写得更长、把循环做得更聪明就够了，后来真正把生产级多agent系统拆开之后才发现：一个循环帮单个agent改进自己的工作，一张图则协调多个循环变成完整系统。

把线性agent想成单车道高速公路最贴切。所有车都必须排队，前面一辆慢了后面全堵。图工程则像城市路网：节点是路口、边是允许通行的方向和携带的数据，系统自己决定哪些路段可以同时跑、哪里需要汇合、哪里出故障只影响局部。

图工程的核心是把agent工作流变成显式执行地图。节点可以是agent、工具调用、确定性函数、验证器或人工审批；边声明下一步允许运行什么、数据如何跨边界。图决定哪些循环运行、顺序、分支、汇合与恢复路径。

停止把每个“然后”都当成依赖。大多数工作流之所以线性，只是因为人们习惯按指令书写。序列不等于依赖。如果B并不消费A的输出，就没有理由让B等待。图工程的第一个问题很简单：下一步是否真的读取上一步的结果？如果答案是否，直接切断那条边。这一步往往就能把慢链条变成快并行图。

给每个节点一份合同。无法精确描述的节点，就无法路由、测试或替换。有用的节点必须具备四件事：唯一职责、明确输入、结构化输出、清晰失败状态。自由文本逼迫下一个节点去猜发生了什么；结构化输出把模型响应变成图可以信任的东西。合同不变，模型、提示或工具都可以随时替换。

把边当作数据合同，而不是箭头。边不该只是“B在A之后”，而应是“A产出了B被允许消费的数据”。大部分工作流管道其实不需要再调一次模型：展平数组、去重、过滤空值、检查状态、合并记录都是确定性操作。把模型调用留给判断，把管道留给代码。每条边都是另一个agent的图，其实是在为自家布线付token。

几乎所有生产图都由四种形状组合而成。链条用于每一步真的需要前序输出，简单可预测却往往过慢；菱形把一个任务拆成独立分支并行运行再合并，是研究、代码审查、尽职调查和市场扫描的主力；路由器检查状态后只走任务真正需要的路径，小任务保持便宜，高风险任务走更深图；受控循环只在证据表明结果不完整时重复，每次都必须有硬停止、预算和收敛规则。

独立工作先扇出，再有意汇合。五个节点独立就一起跑，一个分支失败不该毁掉另外四个。但不要在每个阶段后都设屏障。汇合只在下一步需要完整集合时才值得等待——跨源去重、给所有候选排序、比较替代方案、判断覆盖是否完整。如果每个项目可以独立继续，就让图保持流式。并行并不自动等于快，拓扑决定系统在哪里等待。

让路由可检查。模型可以做判断，图应该强制这个判断允许触发什么。分类器是概率性的，允许的路由是确定性的。这给了模型灵活性，却没给它无限控制系统的权力。OpenAI的可视化Agent Builder已经把这种转变变得直观：agent行为越来越被设计成可检查的工作流，而不是隐藏的提示链。

把验证放在边上。图里杠杆最高的节点往往是那个不产出新内容的节点，它的工作是阻止弱结果往下游流动。验证器可以检查：每条主张是否有来源、引用来源是否真的支持主张、代码是否通过测试、结果是否匹配请求的schema、另一条独立路径是否得出相同结论。不要让同一个agent在同一个上下文里生成、批准并发布自己的工作。角色分离、提示分离、失败边界分离。Anthropic的生产研究系统在更大尺度上遵循同一逻辑：主agent协调并行子agent，发现被合成，专门的引用阶段在结果到达用户前挂上证据。

状态是大多数图里被隐藏的部分。框和箭头看起来干净，直到系统需要在崩溃后恢复。生产图需要持久状态。不要在节点间移动巨大转录，而是移动对产物的引用。研究节点应存储报告并返回路径、ID或结构化摘要；审核者应直接读取产物，而不是通过三个agent接收压缩复述。这减少上下文丢失，并让每次转换可审计。图在任何时刻都应该能回答：当前状态是什么、已完成哪些、下一步可以安全做什么。答不上来，它还只是演示。

只在收敛时加循环。循环在工作量事先未知时有用——bug发现、深度研究、迭代修复都是好例子。但“重复直到好”不是停止条件。使用可测量的收敛，并记住系统已经见过的一切：它应该对所有已见内容去重，而不仅仅是通过验证的发现。否则被拒绝的想法会反复回来，图永远在为同一条死胡同付费。每个受控循环都需要完成测试、最大轮数、token或成本预算、先前尝试记录，以及收敛失败时的升级路径。

把失败设计成局部事件。在链条里，一个坏步骤可以冻结整个工作流；在图里，失败应留在尽可能小的边界内。每个节点都需要策略：昂贵节点后做检查点、写入幂等以便重试不重复副作用、并行工人修改文件时用隔离工作区、记录每个路由决策及产生它的状态。可靠性不来自希望每个节点都成功，而来自决定当某个节点不成功时图该做什么。

拓扑就是你的成本模型。图并不自动比单agent便宜，如果每个任务都派出舰队，它可能烧掉远更多token。形状同时控制延迟和成本。用更便宜的模型做有界提取、分类和格式化，用更强模型做分解、合成和困难验证。简单任务走短路径，完整图只留给真正赚回成本的工作。Anthropic报告多agent研究在广度优先工作上能显著超过单agent，但也消耗远更多token。这就是权衡。图工程不是最大化agent数量，而是只在并行、专业化或独立验证能创造足够价值的地方花协调成本。

一个实用的研究与发布图可以这样运转：范围节点定义问题、受众和完成标准；分解节点创建独立研究车道；研究节点用独立上下文并行运行；确定性代码去重并规范化来源；草稿节点从结构化证据写作；检查器验证主张、引用、风格和缺失部分；失败检查只把相关部分路由回修复；人工在最终产物发布前审批。这不是一个假装成团队的巨型agent，而是拥有明确所有权、状态和权限的系统。

图并非永远正确。任务短、一个上下文能装下所有相关信息、没有独立分支、失败便宜、人能快速审核最终结果时，保持单agent单循环。当工作可以并行、不同节点需要不同工具或权限、输出需要独立验证、任务必须在中断后恢复、多个循环需要共享状态、成本和权限必须由路由控制时，再转向图。先从一个循环开始，只有依赖迫使你时才画图。

发布前先问：每个节点是否有明确合同？边是否只携带真正需要的数据？失败是否被局部化？拓扑是否匹配成本和延迟目标？最后一个问题如果答案是否，就删节点。

提示工程改进指令，上下文工程控制模型看见什么，Harness工程构建模型周围的环境，循环工程让一个工作单元通过反馈改进，图工程协调整个任务。模型只是一个节点，产品是它周围的系统。提问者让agent做更多，架构师重新设计图，让系统能更安全地做更多。

真正拉开差距的从来不是让单个agent更聪明，而是让整个工作流的形状从一开始就正确。

你下次再设计一个agent流程时，不妨先画出节点和边，然后问自己：这里的“然后”真的是依赖，还是只是习惯？

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。