2026 年过半，Prompt Engineering 的热度还没退，Loop Engineering 和 Graph Engineering 已经先后冲上了 AI 编程圈的热搜。这篇文章试图用最接地气的方式，讲一下这两个概念。
一、Prompt Engineering
打开 IDE，敲一句"帮我写个接口"，AI 甩我们一段代码。我们扫一眼觉得还行，然后再说"加个参数校验"，它再改一段。我们说一句，它动一下。我们不说话了，它就搁那儿等我们。
这套交互模式叫 Prompt Engineering。过去两年，整个行业都在卷这个——谁写的 prompt 更精准、谁的 few-shot 例子更到位、谁能让模型少犯一次蠢。卷到最后我们会发现一个尴尬的事实：我们根本不是"用 AI 编程"，我们是"手把手教 AI 编程"。 它就是个打字速度比我们快十倍的实习生，脑子还是我们的。
今年 6 月份，Claude Code 的作者 Boris Cherny 在一个访谈里说了一段让圈内沉默的话：
"I no longer prompt Claude directly. I have a bunch of loops running that are prompting Claude and deciding what to do next. My job has become writing loops."
"我已经不亲自写提示词了。我写了一堆循环，是这些循环在写提示词、在判断下一步该干什么。我的活变成了——写循环。"
差不多同一时间，OpenClaw 的作者 Peter Steinberger 也在 X 上发了条推：
"You shouldn't write prompts for coding agents. You should design loops that prompt your agents for you."
"你不该给编程 Agent 写提示词了。你应该设计一套循环机制，让这些循环替你去提示 Agent。"
这俩人是真在一线干活的，不是贩卖焦虑的。他们指向了同一件事：Loop Engineering（循环工程）。
但事情还没完。到了 7 月，Peter 又发了一条灵魂拷问：
"Are people still talking about Loops or have we moved on to Graphs?"
"你们现在还在聊 Loop，还是已经转向 Graph 了？"
好家伙，Loop 还没玩明白，Graph 又来了。
这篇文章想做的事很简单：用最朴素的语言，把 Loop 和 Graph 到底是什么、它们分别解决什么问题、以及用 Qoder CLI 怎么实操.
二、Loop：让 AI 自己干活，我们别管它
从我们最熟的场景讲起
我们写过单元测试对吧？流程大概是：写一个 test_xxx() → 跑一下 → 红了 → 看报错 → 改代码 → 再跑 → 还是红的 → 再看 → 再改 → 终于绿了。
这个"跑 → 看 → 改 → 再跑"的循环，我们每天不知道做了多少次。我们的大脑就是一个 Agent：观察当前状态（测试红了），做出决策（应该是第三行参数类型不对），执行动作（改代码），检查结果（再跑一次）。
Loop Engineering 做的事情，就是把"我们"换成 LLM。
我们不用站在旁边逐句指挥："你看报错说第三行有问题，你改一下，对就是那个参数类型不对。" 我们只需要在开始的时候告诉它三件事：目标是什么、工具有哪些、什么时候算完成。然后它自己循环去。
六行代码看懂 Agent Loop
还是直接看代码最清楚。下面这 6 行就是一个能跑的最简版 Agent Loop：
messages = [system_prompt, user_task]
while True:
response = llm.call(messages, tools=TOOLS)
if response.stop_reason == "end_turn":
break # AI 觉得搞定了，停
result = execute_tool(response.tool_call)
messages.append(result) # 把结果喂回去，下一轮继续每一轮循环的逻辑：模型自己决定"要不要继续"。要继续就调工具（读文件、改代码、跑命令），工具执行结果塞回对话上下文，下一轮模型参考这个新信息再做决策。如此往复，直到它自己判断"没啥可做的了，目标达成了"。
这就是 ReAct 循环（Reasoning + Acting），本质上跟我们边写代码边调 bug 的工作方式一模一样——只不过执行者换成了 LLM。
Loop 爽在哪
省心。 我们不需要提前规划"第一步读文件、第二步检查语法、第三步修 Bug、第四步跑测试"。我们只需要一句话——"修好所有 Bug，让测试通过"。
AI 自己会拆步骤，自己会调整策略，自己会回头补漏。遇到我们没预料到的依赖问题，它自己发现、自己解决。这才是 Boris 说的「我的活变成了写循环」的真正含义：我们的角色从"手把手教"变成了"定目标和验收标准"。
Loop 的四个致命伤
但 Loop 从来不是万能的。用多了我们会遇到几个让人血压升高的问题：
1. 出错了找不到根。 所有执行过程都堆在聊天历史里。Loop 跑了 40 轮，每轮几千 token，累积了几万字的"思维过程"。如果在第 38 轮做了一个错误决策，后面结果全歪了——我们翻聊天记录翻到手软也定位不到那个关键拐点。
2. 崩了就得重来。 跑了 40 分钟，网络抖了一下，或者上下文窗口超长了——对不起，全部重跑。没有 checkpoint，没有断点续跑，没有"从第 25 轮继续"。跟我们在文档里写到一半没保存一样酸爽。
3. 不可控。 我们觉得"这段代码别动，它故意写成这样的"，但 AI 读不懂我们的潜台词。它可能会顺手"优化"掉一个我们精心设计的边界处理，而我们只能在最后发现——因为中间的决策过程我们根本没看。
4. 没法等人。 Loop 的设计哲学是"持续前进直到目标达成"。它没有内置"暂停，等老板审批再继续"的机制。我们只能在旁边看着，要么相信它，要么随时打断从头来。
一句话总结：Loop 让 AI 能动起来，但过程是我们不可控的。
Qoder CLI 里的 Loop
在 Qoder CLI 中，Loop 的核心入口就是一个命令：
/goal set 我们的目标比如：
/goal set 修复所有失败的单元测试，直到 python -m pytest 全部通过设好之后 Qoder 就开始自己干了——读文件 → 跑命令 → 分析报错 → 改代码 → 再跑 → 循环，直到目标达成。我们可以用 --turns 30 限制最大轮数防止空转烧 token，用 /goal status 查看进度，用 /goal pause 中途暂停。
三、Graph：从"一个人死磕"到"组个团队"
我们平时真的是一个人写代码吗？
Loop 讲完了，我们可能会想：这不就是让 AI 多跑几轮吗，本质上还是"一个 Agent 在单干"，有什么本质变化？
确实，Loop 本身没多复杂。但我们想一个更根本的问题：我们平时干活，真的是一个人从头写到尾吗？
我们写代码的实际流程是：想清楚了就写 → 写完自己先跑一下 → 觉得差不多了提 PR → 找同事 review → review 有意见就改 → 改完再提 → 通过了合并。这不是一个循环，这是一个流程。里面有人、有规则、有交接、有回退。
Graph Engineering 就是把"流程"这个概念带到了 AI Agent 系统里。
从一个小故事开始
假设我们要做一个 AI 周报生成器。用 Loop 的搞法就是：从头到尾让一个 AI 自己干——搜新闻、读原文、核对数据、写稿、检查错别字。所有环节都在同一个上下文里完成。
干了几天我们会发现：
搜新闻的时候上下文里塞了几十篇内容，到写稿时前面搜到的关键数据已经被"遗忘"（注意力稀释）
两个数据源给的信息不一样，它随便信了一个，后续整段结论都建立在错误前提上
我们分不清它到底是认真在检索新信息，还是在同一个无效链接上反复重试
开头有一处事实错误，结尾的推演和结论全部作废——链式反应，一条错到头全白费
这个困境，和一个公司只有一个程序员（既要写前端又要写后端又要做运维又要修 bug）一模一样——不是不能做，是复杂项目根本撑不住。
自然的解法是：组个团队，分工协作。 找资料的人专门找，核实的人专门核实，写稿的人拿到的是已经验证过的材料，审稿的人只管挑刺。分工不但让每个人做得更好，更重要的是——每个环节的输出是可检查的。
三个核心概念：Node、Edge、State
Graph 工程化地描述了"一个团队怎么协作"。它只有三个核心零件，理解了这三个，就看懂了整个 Graph：
Node（节点） = 一个岗位
它可以是任何东西：
一个 LLM Agent（负责思考决策）
一段确定性代码（去重、格式化、运行测试）
甚至是一个人工审批点（"此处暂停，等老板点同意"）
Edge（边） = 交接规则
定义"活从谁手里交到谁手里"，以及"什么条件下走哪条路"。
比如：
验证通过 → 交给写作节点
验证不通过 → 退回资料员节点重新查
重试超过 3 次 → 走异常通道，标记人工介入
State（状态） = 共享任务单
不再是散装的聊天记录，而是一份结构化的数据：
state = {
"目标": "生成AI行业周报",
"当前阶段": "事实校验",
"已收集资料": [...],
"冲突数据": [...],
"审阅结果": "待审",
"重试次数": 2
}关键点：State 在磁盘上。 崩溃了可以从断点恢复，上一条边的输出直接作下一条边的输入，中间不需要人肉搬运上下文。这是 Loop 在设计上就做不到的事——Loop 的所有状态都封在对话窗口里，窗口一关，什么都没了。
最实用的两个 Graph 模式
模式一：Fan-out + Fan-in
最常见的 Graph 形状是一个菱形：
┌→ 读官方文档 ─┐
拆任务 → ─┼→ 读 X 原文 ─┼→ 去重合并 → 验证 → 输出
└→ 搜社区讨论 ─┘查官方文档、读 X 原文、搜社区讨论——这三件事互相没有依赖，完全可以同时跑。等三条分支全查完了，汇总去重，交给验证节点检查。
这个模式在日常开发里太常见了。我们让 AI 同时分析前端代码和后端 API 文档——两个任务是独立的，凭什么要等一个跑完另一个才开始？Fan-out 就是用来回答这个问题的。很多 Agent 系统慢，不是因为模型慢，而是因为所有任务被写成了 A→B→C→D 的串行链条，前一个不结束，后一个绝不开始。
模式二：Reviewer——独立的质检
这是 Graph 最精妙的设计，值得单独拎出来讲。
Reviewer 节点不看 Worker 的推理过程。它只拿到两样东西：最终输出，和规则手册（检查清单）。然后它只回答一个问题：这个输出有没有违反规则？
为什么要刻意屏蔽推理过程？因为人类和 LLM 都有一个认知偏差——当我们看过一个人详细的解题过程后，我们会不自觉地倾向于接受它的答案。一个先看了推理过程的 Reviewer，打分的时候已经在潜意识里带有倾向了。一个发现不了问题的质检等于摆设。
更进一步，如果我们用两个互相不知道对方存在的 Reviewer 同时审查同一个结果：
结论一致 → 放心，这个输出确实过了两把独立的尺子
结论不一致 → 恭喜，我们找到了规则手册里的模糊地带——不是修复这次输出，而是修复规则本身
Graph 没有取代 Loop
这是一个常见的误解。Graph 不是 Loop 的下一代，它们是嵌套关系。
一张 Graph 里面，到处是 Loop。"搜索资料"这个节点内部，Agent 在不断搜、看、判断资料够不够——这是一个完整的 Loop。但这个节点的输出不是散装的对话片段，而是一份结构化的报告，交给下一个节点作为输入。
Loop 让一个人把局部活干完；Graph 让一群人的局部活拼成可交付的东西。
Qoder CLI 里的 Graph：Subagent 系统
Qoder CLI 实现 Graph 的方式是 Subagent（子代理）。核心能力对比如下：
配置方式也很直观：输入 /agents 进入面板 → 用自然语言描述角色 → Qoder 自动生成配置（存在 .qoder/agents/ 目录）→ 编排时直接在 Goal 里说"先用 A 分析，再用 B 修复，最后同时启动两个 C 做独立审查"。
四、动手：Qoder CLI 实操
理论说再多不如跑一遍。本节用同一个有 Bug 的项目，分别用 Loop 和 Graph 两种思路来修。代码不复杂，重点是看工作方式的差异。
环境准备
New-Item -ItemType Directory -Path loop-graph-demo -Force; Set-Location loop-graph-demo
@'
# 任务管理器 —— 带 Bug 版
import time
tasks = []
def add_task(title):
tasks.append({"title": title, "done": False, "created_at": time.time()})
def mark_done(title):
for t in tasks:
if t["title"] = title: # Bug 1: = 是赋值而非比较
t["done"] = True
return
def get_summary():
done = len([t for t in tasks if t["done"]])
return f"完成: {done}/{len(tasks)}"
add_task("学习 Loop Engineering")
add_task("学习 Graph Engineering")
mark_done("学习 Loop Engineering")
print(get_summary())
'@ | Set-Content -Path app.py -Encoding UTF8
这个文件有 3 个 Bug，预期输出是 完成: 1/2，但实际跑起来输出肯定是乱的。
Demo 1：Loop 模式 —— 全部交给 AI 自己修
启动 Qoder CLI：
qodercli进入 TUI 后，设定目标：
/goal set 修复 app.py 中所有 Bug，让 python app.py 输出 "完成: 1/2"。
流程：先运行看结果 → 分析代码 → 逐一修复 → 重新验证 → 直到正确。设完之后我们可以去休息。Qoder 会自动做这些事：
执行
python app.py，发现输出异常
读源码，定位到
=赋值 vs===比较的经典 Bug
修复，再跑——发现输出还不对
继续排查，定位下一个 Bug
再修，再跑
重复直到输出变成
完成: 1/2
自己判断目标达成，自动停止
这是qoder cli的截图
这是修改后的代码
整个过程我们只干了一件事：设定目标。 至于中间要做几步、每步做什么、遇到意外怎么调整——全是 AI 自己的事。
这个模式适合什么？适合我们不知道全部步骤的任务。我们不知道有几个 Bug，不知道每个 Bug 在哪，不知道中间会遇到什么——Loop 帮我们探索。
但如果修到一半，我们突然想加一个约束——"修复之前，必须先通过独立的代码审查"——Loop 做不到。它的世界里只有一个 Agent，无法内建制衡。
Demo 2：Graph 模式 —— 带独立审查的团队协作
现在换一种搞法：同一个任务，加上分工和独立质检。
第一步：创建三个 Subagent
在 Qoder 中输入 /agents，切到 Project 标签页，创建三个 agent。配置文件在 .qoder/agents/ 目录下：
分析员 —— .qoder/agents/code-analyzer.md
---
name: code-analyzer
description: 分析代码质量，找出 Bug 和潜在问题。需要审查代码时用。
tools: [Read, Grep, Glob, Bash]
disallowedTools: [Write, Edit]
permissionMode: acceptEdits
maxTurns: 10
timeoutMins: 5
color: blue
---
你是资深代码审查。职责：
1. 读代码，找所有 Bug 和潜在问题
2. 输出结构化报告：位置、原因、严重程度
3. 只分析，绝不修改代码注意 disallowedTools: [Write, Edit]——从工具层面禁掉了修改能力，比一百句"请不要改代码"都管用。
修复员 —— .qoder/agents/code-fixer.md
---
name: code-fixer
description: 根据 Bug 报告逐一修复代码。有明确 Bug 清单时用。
tools: [Read, Edit, Write, Bash]
permissionMode: acceptEdits
maxTurns: 15
timeoutMins: 10
color: green
---
你是代码修复专家。职责：
1. 按严重程度从高到低修 Bug
2. 每改一处就跑 python app.py 验证
3. 不引入新 Bug，不"顺手"重构
4. 修完汇报：文件、行号、改了什么、为什么审查员 —— .qoder/agents/code-reviewer.md
---
name: code-reviewer
description: 独立审查修复后的代码，确保 Bug 全部修好。需要质检把关时用。
tools: [Read, Bash]
disallowedTools: [Write, Edit, Agent]
permissionMode: acceptEdits
maxTurns: 8
timeoutMins: 5
color: red
---
你是独立审查员。职责：
1. 对照 Bug 报告逐项检查
2. 跑 python app.py 验证输出
3. 只给结论：通过 / 不通过 + 理由
关键：你只拿代码和分析报告，不接触修复员的推理过程。
你不可以修代码——你的工具箱里根本没有写文件的能力。审查员的 disallowedTools 里不光禁了 Write 和 Edit，连 Agent 都禁了——防止它绕道派另一个 agent 去改代码。从工具层面锁死，不是靠 prompt 约束。创建完毕后执行 /agents reload 刷新。
第二步：编排执行
/goal set 修复 app.py 的所有 Bug，协作流程：
第一步：用 code-analyzer 分析 app.py，输出 Bug 报告
第二步：用 code-fixer 根据报告逐一修复
第三步：同时启动两个独立的 code-reviewer，各自审查修复结果
第四步：两个审查员都"通过" → 目标完成
任一不通过 → 退回 code-fixer 重修复，最多 3 轮
3 轮后仍未通过 → 停止，标记需人工介入
验收标准：python app.py 输出 "完成: 1/2"我们应该注意的四个细节
第一，上下文真的隔离了。 每个 Subagent 有自己独立的上下文窗口。分析员的推理过程不会泄漏给修复员，修复员的思考也不会影响审查员的判断。这和 Loop 的"所有东西都堆在一个窗口里"有本质区别。
第二，"只读"是真的只读。 当审查员试图改文件时，Qoder 直接拒绝执行——因为它根本没有 Write 工具。不是"被 prompt 说服了不要改"，而是物理上改不了。这种安全约束比任何措辞精妙的 system prompt 都有效。
第三，审查不通过是真的退回。 不通过之后不是"算了，我帮你顺手改一下吧"——而是把状态退回上游节点，重新进入修复流程。这是 Graph 基于 State 的回退机制，和 Loop 的"继续往下一步走"完全不同。
第四，有熔断。 3 轮修不好就停，不会无限循环烧 token。这是个生产级的保护——很多 Agent 项目在 demo 阶段看起来很酷，上生产就死于无限空转，Graph 的 maxTurns 就是为了解决这个问题。
两种模式对比一览
五、从理解到行动：我们现在就可以做的事
怎么选？一个实用的判断树
这个任务一句话就能说清楚，不需要多轮交互？
→ 别折腾，直接让 AI 一次搞定。我们不需要 Loop 也不需要 Graph。
这个任务是固定几步的流水线，每次流程一样？
→ Workflow 就够了。把步骤写死，确定性最高。
步骤不固定，中间需要探索和动态调整？
→ 用 Loop。让一个 Agent 自己探索、迭代、修正。
需要分工协作、并行执行、独立审查或人工审批？
→ 上 Graph。建 Subagent，定义流程和规则。关键是别一步到位上 Graph。第一次做一个新类型的任务时，我们也不知道最佳流程是什么。先用 Loop 跑通一遍，把手动纠正的每一步记下来——那些纠正动作，就是我们下一轮的 Graph 规则。
三条实用原则
1. 先跑 Loop，再建 Graph。 把 Loop 当成"勘探阶段"，把纠正过程记录下来当成"工程图纸"。下一轮照着图纸建 Graph。
2. 先定义验收标准，再让 AI 执行。 如果我们自己都说不清楚"什么样算做对了"，AI 更不可能知道。验收标准不是"代码看起来不错"，而是一条可以自动化验证的断言——比如 python app.py 的输出必须精确等于某个字符串。
3. 修规则，别修个案。 当我们在第三个文件的第三处位置发现了同一类问题——别手动改。回头修规则手册里的那一句话，然后重跑整个流程。我们不会希望靠人力来保证 AI 产出的质量一致性。
明天就可以干的三件事
在我们正在开发的项目目录下启动
qodercli，设一个简单 Goal：把项目里所有console.log找出来。感受一下"定目标就行"是什么体验。
用
/agents建一个 Subagent，哪怕功能简单到"检查 PR diff 里有没有硬编码的 API 密钥"——这是我们第一次设计 Graph 节点。
下次做重复性的开发工作时，问自己：我能把"分析 → 修复 → 审查"这三个步骤，变成三个 Subagent、一套可重复执行的流程吗？
写在最后
AI 编程工具的发展，正在经历一个微妙的拐点。2023-2025 年，主旋律是"让 AI 更好地理解我们"——卷 prompt、卷 few-shot、卷 RAG。而进入 2026 年，主流声音变成了"我们不需要理解 AI，我们只需要设计它工作的方式"。
Loop 和 Graph 不是两个高深莫测的学术概念，而是两种朴素的工作流抽象。 Loop 对应"一个人死磕一件事"，Graph 对应"一群人按流程协作"。这两种模式我们每天都在用——只是以前用在人身上，现在用在 AI 身上。
核心思想其实就一句话：
以前我们给 AI 写提示词，现在我们给 AI 设计工作方式。我们的角色从"打字机操作员"，变成了"工程师"。
我们修的从来不只是某一行代码，而是生产代码的那套流程。
文中引用的 Boris Cherny 访谈、Peter Steinberger 的推文以及 Loop/Graph Engineering 的行业讨论均来源于公开资料，详见下方参考列表。
参考资料
掘金 - Loop Engineering 深度解析与实战指南（徐小夕）
掘金 - 提示词工程已死，Loop Engineering 称王（程序员鱼皮）
掘金 - Graph Engineering：具有自我审查能力的 Agent（微尘）
掘金 - Agent 工程的下一层：Graph Engineering（Pursue_LLL）
掘金 - Loop 还没玩明白，Graph Engineering 又火了（cxuanAI）