本文来自微信公众号： AIGC从0到1 ，作者：王零壹
一、AI Agent真正的战场已经上移
最近一群做Agent的人突然开始密集讨论一个新词：Graph Engineering。
他们说，真正决定一个Agent能不能稳定跑起来、敢不敢交给真实业务用的，不是你把提示词写得多精妙，而是更高一层的架构设计。从Prompt到Context，再到Harness、Loop，最后到Graph，这被描述成一场“分层觉醒”。
另一边，也有人冷冷回怼：我差点把系统重构成Graph，结果发现只是让事情更复杂了。最好的架构不是最聪明的那个，而是坏了以后你还能调试的那个。
这两种声音同时出现，恰恰说明一件事：Agent正在从“能演示”走向“能上线”，而工程认知也到了必须升级的临界点。
二、五层到底在说什么？
这套分层的核心，不是再发明几个新术语，而是引入了一个更有用的问题：当前的工作单元（unit of work）是什么？
Prompt Engineering
对应的是一次请求。模型每次调用都从空白开始，你需要把角色、指令、例子、输出格式一次性给齐。
Context Engineering
对应的是记忆。长运行系统不可能把所有东西永远塞进窗口，必须决定什么该留、什么该压缩、什么该丢弃。
Harness Engineering
对应的是机器本身。大模型只会生成文本，真正让它变成Agent的，是包裹在外面的那整套东西：工具调用、结果验证、子代理委托、错误重试。
Loop Engineering
对应的是整次执行。一次调用往往不够，系统需要自己判断要不要继续、何时停止，以及有没有真正达成目标。
Graph Engineering
对应的是协调。当多个Loop或多个Agent需要一起工作时，谁先跑、谁并行、谁依赖谁、结果如何汇合，就成了关键。
支持方最有说服力的一点在于：调试时不要默认去改Prompt。Prompt是最容易改的，所以经常被错怪。真正坏掉的，往往是三层之外的工作单元。
三、为什么有人觉得这是进步？
线性链条（step1等step2，step2等step3）在短任务里没问题，一旦任务变长、变宽，问题就会集中爆发：Agent做到一半就自称完成（agentic laziness）、自己检查自己时偏向自己的输出（self-preferential bias）、长对话后原始约束逐渐丢失（goal drift）。
更隐蔽的是不必要的串行等待——很多步骤其实完全独立，却被硬生生排成队。
Graph的价值，就是把工作拆成真正有数据流动的节点和边。独立的事情可以并行（fan-out），需要汇总时再合并（barrier），关键判断可以单独验证，失败可以被隔离。模型也可以分级使用：便宜的做提取和分类，强的只做最终综合。拓扑本身成了成本和速度的最大杠杆。
从“让单次调用正确”，到“让长期运行正确”，再到“让多Agent协作正确”，这确实是一条自然的演进路径。当模型能力快速拉平（今天开源模型已经能打得很接近闭源头部），真正拉开差距的，开始变成你如何组织工作。
四、另一边的冷静声音
但批判同样尖锐，而且往往更接地气。
有人直接说：我上周差点把一个跑得好好的Agent重写成Graph。现有的结构很简单——触发、执行、验证、不通过就重试。它已经满足业务需求。拆成更多节点、状态和转换之后，系统更难推理，协调成本上去了，可靠性和性能却没有明显提升。
更根本的质疑是：Prompt→Context→Harness是真正的演进（从模型内部走向外部系统），而Loop和Graph本质上只是控制Harness的方式，并不构成更高一层的“新学科”。每隔几个月换一个“XX Engineering”，很容易变成新一轮术语崇拜。
Anthropic自己也提醒过：大多数任务并不需要一堆reviewer。Graph必须“赚回”它的协调成本，否则就是过度工程。假边（本来独立的步骤被硬串）、默认同步等待、用Agent去做本该用代码完成的扁平化和去重、停止条件设计不当导致的无限循环——这些都是常见陷阱。
五、给实践者的判断框架
真正有用的，不是站队，而是有清晰的决策标准。
优先用简单Loop的情况：
任务边界清晰、步骤不多、不需要大量并行、验证逻辑相对直接、团队对系统可调试性要求高。此时Trigger→Execute→Validate→Repeat往往是最优解。
值得上Graph的情况：
真正存在可并行的独立工作、需要强验证（尤其是对抗性验证）、证据集很大、长周期开放式发现、多角色必须协作、或者对失败隔离和成本控制有明确要求。
无论选哪条路，有三件事永远比架构花哨更重要：
结构化的输出合同、独立于执行者的验证器、以及明确可衡量的停止条件。
Agent工程正在从“提示词手艺”走向“系统设计”。这本身是好事。它意味着我们终于开始认真对待生产环境里的可靠性、成本和可维护性。
但成熟的标志，从来不是所有人都会喊最新的术语，而是知道什么时候该喊，什么时候该闭嘴，老老实实用最简单、自己还能调试的那个方案。
在模型能力快速拉平、开源与闭源差距不断缩小的当下，真正稀缺的不是更复杂的架构，而是克制地使用复杂度的判断力。尤其是在对成本、稳定性和落地速度更敏感的环境里，这种克制，可能比盲目跟进更有竞争力。
毕竟，能跑起来的系统，永远比看起来高级的系统更有价值。