其实，

Context Engineering 的热度还没散。Loop Engineering 刚被写进几家大厂的技术博客，Graph Engineering 又开始刷屏了。

但你多看几个人怎么用这个词，会发现一件麻烦事：大家嘴里的“图”。根本不是同一个东西——有人说图是人画出来的流程，有人说图是程序攒下来的记忆。

更尴尬的是就在我们争论多智能体该怎么编排的时候。有人把 prompt 里的 {ticket} 改成了 {ticket_id}过了 code review、过了单元测试，却把线上搞挂了。

名词一年换四个，地基好像一块砖都没砌。这事得掰开说说，说起来，

一、先数数这一年换了多少个词

现在流行的叙事大概是这么一条线：

• Prompt Engineering 解决“怎么跟模型说话”。
• Context Engineering 解决“给模型看什么”。不过，
• Loop Engineering 解决“让它自己跑几轮”。
• Graph Engineering 解决…，嗯，这就是分歧开始的地方。

有人给这四段配了四个动词：沟通、理解、执行、学习。听起来很顺，顺到你几乎不会停下来问一句：前三段，真的都“做完了”吗？

每一个新名词的出现，都默认上一个名词已经被解决——可现实是上一个连版本管理都还没有。

二、同一个“图”。两种完全不同的东西

说到痛点1，你是不是因为对“图”的定义不清楚而导致方案落地失败？

从第一种来看。图是人画出来的方法

再看痛点2，你是否因为手工绘制方法而遇到循环死锁或逻辑错误？话说回来，

This派把三层分得很干脆：prompt 工程调整的是单次模型调用。loop 工程调整的是智能体的迭代循环，而图工程管的是一群智能体之间的协作。

至于痛点3，你想让 AI 自动探索却被硬编码方法束缚了吗？那就考虑 Loop，若想完全掌控流程，则要手绘 Graph。按理说，

from langgraph.graph import StateGraph
g = StateGraph
g.add_node # 拆解意图
g.add_node # 取上下文
g.add_node # 产出草稿
g.add_node # 质量评估
g.set_entry_point
g.add_edge
g.add_edge
g.add_edge
# 判定但是就回炉重写；但必须带退出条件，否则死循环烧钱
g.add_conditional_edges(
"judge",lambda s: "generate" if else END。)

注意最终那个 s : 做图的人最先学会的不是怎么连边，是怎么让它停下来。

第二种这方面。 图是程序攒下来的记忆

从痛点4来看，你是否因为每次任务都从基础开始而浪费大量 token 与时间？那就用记忆型 Graph 来避免重复计算。

• Knowledge Graph:    装的是仓库、服务、API、数据库等实体关系。
• Execution Graph:    记录使用者请求、规划决策、检索结果、工具调用与模型响应等执行细节。
• Feedback Graph:    保存人工审批、PR 审核、线上事故及客户反馈等结果，以供后续改进。

This三张图串进一条链路：

• User request → Planner → Knowledge + Execution → Context assembly → LLM call → Tool execution → Evaluation engine → Feedback graph update → Service refresh.

关键设计要点这方面。

• "**Graph 是执行组件，不是检索源**"
• "**规划智能体本身要读执行图来决定这次该怎么走**"
• "**省钱逻辑在于不让推理变便宜，而是让不必要推理根本不发生**"
• 再看"**一句话，一个 Agent，不该把同一个问题解两遍。**"

到底该用哪个？

"这不是二选一"。它们在架构上根本不在同个位置——控制流与持久层互补。务必知道自己在建哪个，否则会踩坑。

"什么时候压根不需要图"

• 痛点5：你的任务只需要一次性完成。没有并发或审批环节，那 loop 就够用了。加上无意义的 Graph 会增加维护成本！ No 图： # 单目标 + 少工具 + 少分支 + 无断点续跑 # 场景示例：“
• # 值得上 Graph： # 跨部门、多智能体、多阶段并行、有审批审计需求时才值得画完整流程表格或状态机

"最扎心的一层：我们连一个字符串都没管住"

• 前面两种讨论都很宏观。但最小的问题往往最致命 ：prompt 本身就像数据库 schema，需要严格版本和契约校验。当 Prompt 中变量名改错时一切都能瞬间炸掉，而 CI 或测试根本拦不住。“我改了一下 {ticket} -> {ticket_id}，没想到上线 KeyError。” 那么为什么 Git 提交通过却能在线下崩溃呢？因为类型检查器只关注类型；单元测试常用 mock 而非真实 format 调用；代码评审也容易漏掉占位符差异。话说回来，需要专门工具来做 PromptDiff/契约校验/影响面分析。提示语管理应该像数据库迁移一样严谨，而不是随手敲字。