Context Engineering 的热度还没散，Loop Engineering 刚被写进几家大厂的技术博客，Graph Engineering 又开始刷屏了。
但你多看几个人怎么用这个词，会发现一件麻烦事：大家嘴里的"图"，根本不是同一个东西------有人说图是人画出来的流程，有人说图是系统攒下来的记忆。
更尴尬的是，就在我们争论多智能体该怎么编排的时候，有人把 prompt 里的 {ticket} 改成了 {ticket_id}，过了 code review，过了单元测试，把线上搞挂了。
名词一年换四个，地基好像一块砖都没砌。这事得掰开说说。
一、先数数这一年换了多少个词
现在流行的叙事大概是这么一条线：
Prompt Engineering 解决"怎么跟模型说话"。
Context Engineering 解决"给模型看什么"。
Loop Engineering 解决"让它自己跑几轮"。
Graph Engineering 解决......嗯，这就是分歧开始的地方。
有人给这四段配了四个动词：沟通、理解、执行、学习。听起来很顺，顺到你几乎不会停下来问一句：前三段，真的都"做完了"吗？
每一个新名词的出现，都默认了上一个名词已经被解决------可现实是，上一个连版本管理都还没有。
二、同一个"图"，两种完全不同的东西
这是最该先说清楚的一条。同样打着 Graph Engineering 的旗号，你按第一种理解去实现第二种方案，会做出一个四不像。
| | 图 = 流程编排 | 图 = 系统记忆 | | --- | --- | --- | | 图是什么 | 控制流 | 记忆层 | | 谁来画 | 人 | 系统自己长 | | 解决的问题 | 这一次怎么跑 | 下一次别从零跑 | | 典型载体 | LangGraph / 状态机 | 知识图谱 / 执行日志 |
第一种：图是人画出来的路径
这一派把三层分得很干脆：prompt 工程优化的是单次模型调用，loop 工程优化的是智能体的迭代循环，而图工程管的是一群智能体之间的协作。
关键区别在于谁做主。在 loop 里，你只定义目标和及格线，剩下让 AI 自己去探索、执行、验证，不达标就再来一轮。而在图里，路径是人设计的。
拿写文章这件事举例最好懂。只用 loop，就是"写→评→改→再评"转圈。但用图，你可以规定------质量不达标退回写作节点；如果是选题方向本身错了，那要退得更远，回到调研和结构设计阶段。
这两种"不合格"，处理路径根本不一样。loop 表达不了这种区别，图可以。
按这套主张，一张图要定义的东西是一串：节点、边、状态、产物、权限、观测、评估、变更历史。用 LangGraph 落地大致长这样（示意）：
bash
from langgraph.graph import StateGraph, END
g = StateGraph(AgentState)
g.add_node("understand", understand_node) # 拆解意图
g.add_node("retrieve", retrieve_node) # 取上下文
g.add_node("generate", generate_node) # 产出草稿
g.add_node("judge", judge_node) # 质量评估
g.set_entry_point("understand")
g.add_edge("understand", "retrieve")
g.add_edge("retrieve", "generate")
g.add_edge("generate", "judge")
# 判定不过就回炉重写；但必须带退出条件，否则死循环烧钱
g.add_conditional_edges(
"judge",
lambda s: "generate" if (not s["passed"] and s["retries"] < 3) else END,
)注意最后那个 retries < 3。做图工程的人最先学会的不是怎么连边，是怎么让它停下来。
第二种：图是系统攒下来的记忆
另一种定义的出发点完全不同。它不关心这次任务怎么编排，只盯住一句话：每一次执行都从零开始。
典型场景是这样的：AI 排查一次线上故障，翻仓库、理依赖、读文件，花五分钟得出结论。一个月后类似问题再来，同一个 Agent 把这五分钟一模一样地重走一遍，烧掉成千上万个 token，得出几乎相同的结论。
这不是智能的问题，是记忆的问题。
顺着这个思路，图被拆成三张，每张回答一个问题：
知识图（Knowledge Graph）------我的系统是怎么连起来的？装的是仓库、服务、API、数据库、基础设施、团队、归属关系、依赖链路。
执行图（Execution Graph）------以前跑过什么？装的是用户请求、规划决策、检索到的上下文、工具调用、代码改动、测试、模型响应、部署步骤。
反馈图（Feedback Graph）------那次到底管不管用？装的是人工审批、PR 评审、线上事故、回滚记录、客户反馈、评估分数、成功指标。
三张图串进一条链路：用户请求 → 规划智能体 → 查知识图和执行图 → 组装上下文 → 调 LLM → 执行工具 → 评估引擎 → 写回反馈图 → 图更新服务。
这里有个容易被忽略的设计要点：图是执行组件，不是检索源。
我知道很多人读到这已经在想"这不就是知识图谱加 RAG 吗"。区别就在这句话上。RAG 里，检索是给模型喂料的一个前置步骤；而在这套架构里，规划智能体本身要读执行图来决定这次该怎么走------图参与的是决策，不是补充材料。
一个具体场景：React monorepo 里有人报"登录成功后认证弹窗立刻关闭"。系统不去重新搜代码、重建分析，而是直接从执行图里捞出------以前处理过的相似流程、当时改了哪些文件、哪个 PR 合了、有没有现成的回归测试。
省钱的逻辑也顺着这条：它不让推理变便宜，它让不必要的推理根本不发生。
说白了就一句话：一个 Agent，不该把同一个问题解两遍。
所以到底该用哪个？
这不是二选一。它们在架构上根本不在一个位置：一个是运行时的控制流，一个是跨执行的持久层。你完全可以用 LangGraph 编排流程，同时用另一套图存记忆。
但你得知道自己在建哪个。把控制流的图和记忆的图混成一个，是这波概念热潮里最容易踩的坑。
三、什么时候压根不需要图
图不是越多越好，边界其实很清楚。
不需要图：任务只有一个目标、工具很少、分支不多、也不需要中途断点续跑。这种直接用 loop，加一层图只会徒增复杂度。
才值得上图：跨多个部门、多个智能体、执行周期长、有并行分支、需要审批、需要留审计痕迹。
正面例子是重构支付系统------API 兼容、数据迁移、前端改造、测试、安全评审、发布协调，六件事互相牵制，有先后依赖，有必须卡住的审批点。这种任务，你不画图就是在赌。
对照一下你手上的活儿。如果它更像"写篇文章"而不是"重构支付系统"，那你现在需要的不是图。
四、最扎心的一层：我们连一个字符串都没管住
前面两种图都在讨论多智能体协作和跨执行记忆。把视线拉回地面，有件更小的事更值得警惕。
一句话概括：prompt engineering 已经解决了，prompt management 没有。
事故长这样：
bash
# prompts.py ------ 有人把变量名改得更"规范"了
TRIAGE = "请处理工单 {ticket_id}，输出优先级和负责人。"
# handler.py ------ 调用方没跟着改
TRIAGE.format(ticket=ticket.id) # 💥 线上 KeyError: 'ticket_id'一次纯粹的重命名。Git 提交正常，代码评审通过，单元测试全绿。然后到了生产环境，KeyError。
为什么四道关卡一道都没拦住？
类型检查器不管。 mypy、pyright 检查的是类型，字符串里的占位符对不对得上，不在它们的职责范围内。
单元测试不管。 因为测试里 LLM 调用是 mock 掉的------mock 掉的那一层，恰恰就是 .format() 真正会炸的那一层。
代码评审不管。 三五个文件时人眼能看出来，几十个 prompt、上百个调用点时，谁都看不出来。
Schema 库能管，但代价是重构。 为了一个变量名把整套 prompt 结构推倒重来，没人愿意。
已经有人把这套检查做成了工具（promptctl），思路是三遍扫描：
-
PromptDiff ：用 Python 的
ast和string.Formatter找出 prompt 文件里变量的变化 -
契约校验 ：检查所有
.format()调用点，是不是都提供了必需的变量 -
影响面分析：标出哪些文件引用了这个 prompt
工具本身没什么魔法------纯标准库，零依赖，全量分析大约 3 毫秒。用 JSON 快照存"上一次被批准的 prompt 状态"作为基线，通过返回 0、失败返回 1，直接卡进 CI。
它的边界也很清楚：不评估 prompt 质量和模型行为、处理不了动态拼出来的键名、只认 Python 文件里的 prompt、合并后基线不会自动更新。
但真正值钱的不是这个工具，是它背后那个心智模型------
改一个 prompt，本质上是一次数据库 schema 迁移，不是一次字符串编辑。
你不会随手把生产库的列名改掉就直接上线。那为什么 prompt 就可以？
五、把这几层放在一起看，真正的问题浮出来了
单看每一层，都挺有道理。叠在一起看，问题就露出来了：
抽象层在疯狂往上堆，但每一层的工程规范都是空的。
我们从 prompt 跑到 context，从 context 跑到 loop，从 loop 跑到 graph，一年四级跳。但回头看：
-
prompt 层------没有契约校验，改个变量名能炸线上
-
context 层------没有标准的评估方式，好坏全靠感觉
-
loop 层------退出条件基本靠人肉写
retries < 3 -
graph 层------连这个词指什么，业内都还没谈拢
每一层都在自己被工程化之前，就被下一层宣布"已解决"了。
这不是说新概念没价值。三张图的划分很有洞察，图工程和 loop 的边界也划得清楚。但概念的迭代速度，正在远远甩开工程规范的建设速度，这才是真正的风险。
这波热潮里最清醒的一种声音是：图工程这个词，几个月后大概率会消失。
我信。但更重要的是后半句------词会没，任务拆解、并行、决策卡点这些东西不会没。
这句话可以直接套到前面所有名词上。
六、如果你明天就要动手，只做这三件事
第一，先判断你要不要图。 单目标、工具少、分支少、不需要断点续跑，loop 就够了，别硬上。真到了跨部门、长周期、要审批要审计的场景，再画图不迟。
第二，想清楚你建的是哪种图。 控制流的图解决"这次怎么跑"，记忆的图解决"下次别从零跑"。可以都要，但别混在一个东西里。想省 token 就先建执行图，想让复杂流程可控就先建状态机。
第三，不管你在哪一层，先把 prompt 当 schema 管起来。 版本、契约、迁移、CI 卡口。这是唯一一件今天就能动手、而且明年还不会过时的事。
前两件事取决于你的业务复杂度，第三件事没有例外。
下一个新名词大概三个月后就会来。到时候值得问的不是"这词什么意思"，而是"上一个词，我们真的做完了吗"。
你手上的 Agent，现在是每次都从零开始，还是记得住上一次？评论区聊聊。
希望这篇文章能为您带来一些帮助。如果有任何疑问或建议，请在评论区留言，我们将尽力回答！
欢迎后台私信加入组织共同交流！
让我们一起探索并推动前沿技术发展！🚀💻
祝好运！😊✍️