从 Prompt 到 Loop 再到 Graph：AI 工程范式演进

人工智能

如今，AI 工程师的职位描述里，有三个术语正在争夺同一个位置。Prompt engineering 是已经确立的概念。Loop engineering 于 2025 年末进入 AI 领域的词汇体系，并在 2026 年 6 月之前主导了开发者社区的讨论。大约六周后，Graph engineering 也随之出现。

它们经常被混为一谈。真的应该如此吗？

这三者并不是相互竞争的技术，而是三个层层叠加、彼此不同的控制单元。prompt 控制模型的一次响应；loop 控制一个 Agent 的行为周期；graph 控制多个 Agent 的组织方式。每一层都会保留下方的层级。在 prompt 外围构建 loop 后，prompt 并不会消失，只是不再需要由人手动输入。

本文将厘清这三者：每一层具体需要设计什么；公开资料如何描述更高层级在什么情况下值得投入；以及哪些地方理应保持怀疑。

在进入厂商文档之前，这一演进过程中的每个阶段，都已经先在实践中获得了自己的名称。

Prompt engineering 涵盖为单次调用编写和组织指令。Anthropic 的建议是，将 system prompt 拆分为带标签的不同部分——背景信息、指令、工具使用说明和输出描述——并使用 XML 标签或 Markdown 标题划定边界。建议提供能够完整说明预期行为的最小信息集合。最小并不意味着简短。

随后出现的是 Context engineering。Anthropic 将其描述为 Prompt engineering 的自然演进。问题从“如何找到正确的措辞”，转变为“究竟应该把哪些 token 配置到 context window 中”。Context 是一种有限资源，而工程问题在于：如何在模型约束之下，优化这些 token 的效用。

Harness engineering 涵盖单个 Agent 运行所处的环境：文件、工具、memory 和反馈。

Loop engineering 位于 harness 的上一层。2026 年 6 月，一篇关于建筑工程中 agentic AI 系统 Buildrix 的 arXiv 论文，明确提出了同样的四步演进路径——先是 prompt，然后是 context、harness，最后是 loop——最上层定义了系统如何反复观察、行动、验证并从失败中恢复。

Graph engineering 是最新出现、定义也最不稳定的标签。一篇面向企业的文章指出，这个术语的来源尚无定论，而且会与更早使用同一词汇的 knowledge graph 概念发生冲突。不过，其背后的实践——基于 graph 的编排——在 multi-agent systems 研究中已有清晰可考的演进脉络。

第一层：Prompt Engineering

这一层的核心假设是：每次迭代都有人参与。人编写 prompt，模型给出响应，人判断输出结果，再修改 prompt。

真正失效的正是这个假设。调用量很大、任务包含多个步骤、没有人能够评估输出结果，或者结果会自动进入下一步——只要出现其中任何一种情况，仅靠 prompt 就不再足够。

并不是 prompt 本身变差了，而是它所处的外部条件发生了变化。

进入更高层级后，Prompt engineering 也不会消失。Anthropic 关于 multi-agent 研究系统的文章指出，Prompt engineering 是解决协调失败问题的主要杠杆。早期版本会为简单查询创建 50 个 sub-agent，而解决方案是调整 prompting，并非改变系统拓扑。

第二层：Loop Engineering

其基本观点是，coding agent 是一种通过蛮力寻找解决方案的工具。真正的工程技艺在于设计目标、工具与 loop，而不仅仅是设计 prompt。

2026 年 6 月，一篇广为传播的文章提出，工程师应该停止直接 prompting coding agent，转而设计那些负责 prompting Agent 的 loop。此后，Loop engineering 进入了开发者社区的主流讨论。同一周，Anthropic 的 Claude Code 团队也在台上描述了这一转变。

目前最详尽的公开分析列出了五种基本构件，以及将它们串联起来的第六个要素：

• Automations：按照计划或事件触发，在无人监督的情况下执行信息发现与分类处理

• Worktrees：提供隔离，避免并行运行的 Agent 编辑相同文件

• Skills：把项目知识一次性写入 SKILL.md，而不是每个 session 都重新解释

• Plugins 和 connectors：基于 MCP，访问 issue tracker、database 或 staging API

• Sub-agents：将 maker 与 checker 分开，因为编写代码的模型往往会过于宽松地评价自己的代码

• State：存放在 conversation 之外的 Markdown 文件或看板，因为模型会遗忘不同运行批次之间的信息

另外，还有两个非常重要的 session 内功能。/loop 会按照指定的时间间隔重新运行。/goal 则会持续运行，直到书面定义的条件真正成立；每轮结束后，都由另一个独立的小模型执行检查，因此编写代码的 Agent 不会同时负责评价自己的结果。Claude Code 和 Codex app 都提供了对应功能。

循环本身并不是最困难的部分，停止条件才是。一个无法通过机械方式区分“已经完成”和“陷入停滞”的 loop，并不会发出明显的失败信号，只会继续消耗 token。

第三层：Graph Engineering

2026 年 7 月，讨论焦点从 loop 转向了 graph。Loop 让 Agent 的行为变得可编程，graph 则让 Agent 的组织方式变得可编程。

最容易被忽视的结构性要点在于：生产环境中的 multi-agent systems 会同时运行两张 graph。

Org graph 是稳定的。长期运行的 Agent 拥有明确命名的角色，各自负责一个区域，并随着时间积累 context。它只会在重新部署时发生变化。

Work graph 是临时的。任务节点只会在工作存在期间存在。边会拆分形成并行路径，在结果汇合时合并，并在证据表明某条分支已无必要时消失。

Org graph 回答“谁来做”。Work graph 回答“眼下要做什么”。

围绕这一标签的质疑是合理的。具有明确用途的 sub-agent 本身就已经构成了一张 graph，而且相关技术早于这套词汇出现。早在 Graph engineering 这个术语出现之前，LangGraph 就已经发布了 graph API。Anthropic 于 2024 年 12 月提出的五种 workflow 模式——prompt chaining、routing、parallelization、orchestrator-workers 和 evaluator-optimizer——本质上就是用文字描述的 graph topology。真正的新变化，是人们为这些框架一直要求开发者做出的决策找到了一个共同名称：节点是什么、边是什么、state 中保存什么。

具体产物值得了解。在 LangGraph 中，StateGraph 基于 state schema 声明。节点通过 add_node 注册，边通过 add_edge 和 add_conditional_edges 连接。标记 START 和 END 后，再编译 graph。节点就是普通函数：接收 state，并返回局部更新。除非有一条边负责传递 context，否则 context 不会跨越节点边界。最后这一点，概括了整个系统的失败模式。

如何选择层级

按照顺序逐一回答下面的问题。通常，遇到的第一个“否”就是答案。

每项输出在触发后续操作之前，是否都会由人阅读？如果是，prompt 层就足够了。Loop 带来的是无人监督的执行，而不是 autonomy。

“完成”能否由人以外的方式判断？例如测试、schema、rubric 或第二个模型。如果不能，就不存在停止条件——只有预算上限。

任务能否容纳在单个 Agent 的 context 和单一领域之内？如果可以，就构建 loop。单一 reasoning trace 是保持假设一致性成本最低的方式。

是否需要同时运行彼此独立的分支？如果需要，这就是一个 graph 问题：声明节点、边、shared state 和失败路径。如果不需要，应先扩展 loop 的工具，再考虑增加 Agent。

2026 年 7 月，一篇关于 coding-agent loop 的 arXiv 论文准确描述了两者之间的关系。Loop 是在外围加入 scaffolding 后重复运行的 prompt，Loop engineering 是 Prompt engineering 的补充，而不是替代。再向上一层也是如此：graph 由 loop 构成，loop 则由 prompt 构成。

最后需要警惕的不是架构，而是操作者。两名工程师可以构建完全相同的 loop，却得到截然相反的结果。其中一人借助它，在自己深入理解的工作上加快速度；另一人则用它逃避对工作的理解。系统无法判断二者之间的区别。这正是更高层级的设计比 prompt 更难、而不是更简单的原因。

这是三个控制单元，而不是三种相互竞争的方法：prompt 控制一次响应，loop 控制一个 Agent 的行为周期，graph 控制多个 Agent 的组织方式。

Loop 的质量取决于它的停止条件——如果没有能够机械判断“完成”的检查机制，无人值守的运行最终会因为耗尽 token 预算而终止，而不是因为结果正确而结束。

生产环境中会同时运行两张 graph：一张稳定的 org graph，用来回答谁负责什么；以及一张面向单个任务的 work graph，它会随着证据的到来进行拆分、合并和取消。

公开数据揭示了它的代价：内部研究评测提升了 90.2%，但 token 消耗约为普通 chat 的 15 倍，而且仅 token 开销一项，就解释了结果差异中的 80%。

大多数任务永远不需要抵达这套技术栈的最顶层：对于以写作为主的工作，反例依然成立，因为分散的决策会产生彼此冲突的假设。

anthropic.com/engineering — AI Agent 的高效 Context Engineering

anthropic.com/engineering — 构建高效的 Agent（2024 年 12 月）

anthropic.com/engineering — 我们如何构建 multi-agent 研究系统（2025 年 6 月 13 日）

simonwillison.net — 设计 Agentic Loop（2025 年 9 月 30 日）

addyosmani.com — Loop Engineering（2026 年 6 月 7 日）

firecrawl.dev — Loop Engineering

explainx.ai — Graph Engineering（2026 年 7 月 18 日）

truefoundry.com — Multi-Agent Systems 的 Graph Engineering

aibuilderclub.com — 2026 年 Graph Engineering 指南

cognition.com — 不要构建 Multi-Agent（2025 年 6 月）

langchain.com — 如何以及何时构建 Multi-Agent Systems

docs.langchain.com — LangGraph Graph API

arXiv — Buildrix · 别再手把手指导你的 Coding Agent

Asif Razzaq 是 Marktechpost Media Inc. 的 CEO。作为一名富有远见的企业家和工程师，Asif 致力于发掘 Artificial Intelligence 造福社会的潜力。他最近创办了 Artificial Intelligence 媒体平台 Marktechpost。该平台以深入报道 machine learning 与 deep learning 新闻而脱颖而出，其内容既具备可靠的技术基础，也能让广泛的读者群体轻松理解。该平台每月浏览量超过 200 万，体现了它在读者中的受欢迎程度。