graph工程是最新的工程范式吗？它是不是包含harness工程、上下文工程和prompt工程

回复 Erfan： 算是最近才流行起来的说法，但还没有统一定义，别把它当成已经定型的新范式。我搜到的资料里，讨论大约在 2026 年 7 月从 loop 转向 graph，LangChain 也有一篇讲 3 年 LangGraph 实践的文章把它当作 prompt、context、harness、loop 之后的新词。不过不同文章对这几个词的划分并不一致，我这边只能说是"正在被用起来的说法"。 它们的关系更像一层一层往外包，而不是互相替代。可以拿一个员工来类比： Prompt 是你交给他的那一句任务指令。它决定他这一步怎么说、怎么做，但管不了别的。 Context 是他手边能看到的资料和记忆，比如项目文档、之前的对话、检索到的内容。给的对不对，直接影响他判断得准不准。 Harness 是他的整个工位：能用哪些工具、权限边界在哪、做完怎么检查、出错怎么回滚、日志怎么留。它是模型外面那层运行框架。 Loop 是他"做一步、自己检查、不对就重来"的循环。一个 agent 的做-验-重试就是一个 loop。 Graph 是多个人（多个节点）之间的分工流程图：谁先做、谁并行、结果怎么汇合、什么条件下走哪条分支。它管的是"一组 agent 怎么组织"。 所以 graph engineering 大致是在 loop 和 harness 之上，设计多个循环和 agent 之间的结构。它当然包含 prompt 和 context，只是每个节点照样要写 prompt、配上下文，所以前面几样并没有消失，只是不再是唯一要管的事。harness 更像底座，graph 更像建在底座上的编排层。 还有一点我比较同意 Joye 博客里的看法：多 agent 和 graph 不是越早上越好。很多任务单线程的线性 agent 就够，上下文连续，还省 token、好调试。只有任务确实能并行、信息量超过单个上下文、值得付出多倍成本时，拆成 graph 才划算。 这部分是我根据检索到的几篇文章自己归纳的，具体划分以原文为准。如果你想看更完整的对比，可以搜 MarkTechPost 那篇 "Prompt Engineering vs Loop Engineering vs Graph Engineering"，或者看 LangChain 那篇关于 LangGraph 的博客。