企业官网建设流程全解析

Agent、Loop、Graph：一篇文章把你需要知道的都讲清楚

大多数人用 AI，基本都是同一个节奏：问一句，读回答，发现问题，修改，再问一次。

当然，这种方法能用。

但它也是效率最低的一种用法。

其实还有一种更快的方式。

它由三个部分组成：

一个能自己规划、自己行动，而不是等你一步一步带着走的Agent；

一个会一直运行，直到任务真正达到要求才停下来的Loop；

以及一个由多个 Worker 并行工作的Graph，专门处理那些单靠一个 Prompt 根本做不完的事情。

Claude 这三种能力其实都能做到。

只是大多数人从来不知道。

不是因为这些东西有多复杂。

而是因为一直没人把这三样东西放在一起，完整地讲清楚。

看完这篇文章，你会真正明白 Claude 到底能做到什么。

你会知道Agent、Loop 和 Graph 分别是什么，它们是怎样一步一步发展起来的，什么时候值得用，什么时候反而是在给自己挖坑，以及怎么用今天就能上手的 Prompt 和代码，把这三套东西自己搭出来。

Agents

1——Agent 到底是什么

让 Claude “总结一下这篇文章”，这还不叫 Agent。

这只是一次普通的聊天。

但如果你告诉 Claude：

“找出这个领域引用次数最多的三篇论文，提炼每篇论文的核心观点，把它们互相交叉验证，最后给我写一份一页纸的简报。”

然后从头到尾，你什么都不用插手，它自己把这些事情全部做完——

这才叫 Agent。

真正的区别不在模型本身。

而在于围绕这个模型搭起来的那套结构。

一个 Agent，比普通聊天多了三样东西。

第一，它可以自己调用工具。

搜索、文件系统、代码执行、外部 API，这些都可以。

它不会等着你去找信息，而是自己去找。

第二，它有能跨任务保留下来的记忆，而不是只记得当前这一轮对话里的内容。

它知道自己已经试过什么，什么方法奏效过，之前做了哪些决定。

第三，它有一个持续运行的 Loop。

它会一直做下去，直到任务真正完成，而不是生成一次回答就算结束。

它不会每走一步，就把工作重新丢回给你。

当这三样东西都具备之后，Claude 就不再只是一个“你拿来聊天的 AI”。

它开始变成一个真正替你干活的东西。

2 - The levels of agentic work

2——Agent 化工作的几个层级

当然，不是所有人第一天就需要一个完全自主的 Agent。

真正值得知道的是，Agent 化的工作其实有不同层级，而且哪怕只是低一级，也已经比大多数人平时使用 AI 的方式强得多。

Level 1——Chat。

你问，Claude 答，然后会话结束。

没有工具，没有记忆，也没有持续进行的目标。

你才是整个过程的发动机，Claude 只是你手里的工具。

Level 2——Claude + Tools。

当 Claude 会在回答之前主动搜索网页、读取文件，或者运行代码来检查自己的结果时，它其实已经开始具备 Agent 的特征了。

因为这些事情并不是你一步一步告诉它去做的——

而是它自己判断出“我需要这个工具”。

Level 3——多步骤工作流。

你只给它一个目标。

Claude 自己把目标拆成若干步骤，依次执行，再检查结果，最后把完整的结果交给你。

整个过程中，你都不用在中间插手。

Level 4——完全自主。

Agent 可以按照固定时间或者触发条件自动运行，持续监控输入，调用外部服务，并在没有人工介入的情况下完成复杂任务。

你只需要设定一次目标，然后回来检查结果。

Level 1 和 Level 4 的差别，并不是因为换了一个模型。

真正拉开差距的，是模型周围有没有工具、记忆和 Loop。

一个一个加上去，你就会从一个层级走到下一个层级。

3——今天就能自己搭出来的三个 Agent

你要做什么类型的 Agent，决定了你应该给它什么样的 System Prompt。

下面这三个类型，基本已经覆盖了大多数人真正会用到的场景。

找到最符合你需求的那个，改改细节，直接放进 System Prompt 里就行。

Research Agent（研究型 Agent）

你是一个研究型 Agent。你的工作是找出真正重要的信息，而不只是罗列“有什么”。 接到研究任务后： 1. 把任务拆成 3～4 个真正值得回答的具体问题 2. 分别独立搜索每一个问题 3. 对每条发现都问自己： 它是在直接回答问题，还是只是和问题沾边？ 4. 只留下真正能回答问题的信息，其余全部舍弃 5. 最后输出结构化总结： 核心发现、每条发现对应的来源，以及哪些信息没有找到 规则： - 每一个结论都必须有来源，没有例外。 - 如果两个来源互相矛盾，就明确指出来，不要替任何一边站队。 - 如果找不到可靠答案，就直接说找不到，不要为了填空白而硬编一个答案。

Data Analysis Agent（数据分析型 Agent）

你是一个数据分析型 Agent。你的工作是找出数据到底在说明什么，而不只是把数据里有什么描述一遍。 拿到数据集或一组数字后： 1. 先判断这是什么类型的数据，以及它到底能回答哪些问题 2. 找出其中的模式、异常值和趋势，而不只是看看平均数 3. 对每一个发现都问自己： 这是一个有意思的发现，还是一个一眼就能看出来的常识？ 显而易见的东西直接删掉。 4. 把所有看起来不对劲的地方标出来： 缺失值、异常尖峰、不一致的数据等 5. 最后按重要性输出发现，而不是按它们在原始数据里出现的顺序来排 规则： - 永远不要只是描述“数据里有什么”，而要解释“这些数据意味着什么”。 - 如果某个数字特别反常，要解释它为什么反常。 - 如果这份数据根本回答不了用户的问题，就直接说，不要硬往上套解释。 - 每次分析最后都用一句话回答： 这份数据最重要地说明，你接下来应该做什么？

Code Agent（代码型 Agent）

你是一个代码 Agent。你的工作是写出真正能运行的代码，而不是看起来“应该能运行”的代码。 接到编程任务后： 1. 在写代码之前，先说明你对需求的理解，以及程序到底应该完成什么 2. 写出解决方案，并用清楚的注释解释各个部分 3. 找出可能把程序搞崩的边界情况 4. 如果发现错误，先自己调试，再考虑求助 规则： - 代码要整洁，变量名要有明确意义 - 始终做好错误处理 - 如果需求存在不明确的地方，就做一个合理假设，说明这个假设，然后继续，不要卡在那里 - 任何代码交付之前，至少自己完整地走一遍逻辑，确认它真的成立 发现 Bug 时： 先用一句话解释这个 Bug 是怎么产生的，然后把它修掉。 不要什么都不说，直接把 Bug 悄悄改掉。

4——记忆问题，以及怎么解决

Agent 最容易出问题的地方，其实就是记忆。

而且通常会出现三种情况。

1. 任务拖得太久，Agent 把开头忘了。

最初的目标、之前做过的决定、你设置的限制条件……这些东西都会慢慢被挤出 Context Window。

Agent 表面上还在继续工作，

实际上它已经悄悄忘了自己到底是在为什么目标努力。

2. 你关掉当前会话，再开一个新的。

Agent 直接从零开始。

上一次运行留下的一切，全没了。

3. Agent 做到一半被打断。

等你回来之后，它不知道自己做到哪里了，不知道之前试过什么，也不知道哪些方法已经失败。

这三种问题，其实都有同一个解决办法：

让 Agent 自己把记忆写下来。

做到一半时，粘贴下面这段，让它留下进度记录：

在我们继续之前，先写一个进度检查点： 1. 到目前为止，你完成了什么？ 2. 做出了哪些决定？为什么？ 3. 现在还剩下什么没做？ 4. 如果我要在一个新会话里继续，你需要哪些信息？ 控制在 150 个单词以内。 一定要具体——模糊的进度记录一点用都没有。

当一轮会话已经越来越长时，粘贴这段：

这段对话已经变得很长了。 请把真正重要的信息压缩成一份总结： 1. 最初的目标是什么 2. 已经做了什么，以及发现了什么 3. 做出的关键决定 4. 接下来还需要做什么 总结完成后，就从这里继续。 把这份总结当成新的起点。

新开一个会话时，用下面这段把上下文接回来：

```text 我们现在要继续之前的会话。下面是之前留下的上下文： [把之前的 checkpoint 粘贴到这里] 先确认你理解我们现在进行到哪里了，再找出下一步应该做什么。 不要重复之前已经完成的工作，直接接着往下做。

还有一件事，对于你经常运行的 Agent 很值得做：

把它每次都必须知道的信息，直接写进 System Prompt。

Claude 每次开启新会话时都会读取 System Prompt。

所以，不管这次对话后来有多长，写在 System Prompt 里的那些信息始终都在那里。

Loop

1——Loop 到底是什么

普通 Prompt 是给 Claude 一个指令，然后等你来决定下一步怎么办。

而 Loop 给 Claude 的是一個目标，然后让它自己想办法一路做到那里。

实际区别非常简单：

Prompt 生成出一个结果，就可以停了。

而Loop 得等任务真的做完，才会停。

每一个 Loop，本质上都在跑同一个循环：

PLAN - work out what the task actually requires EXECUTE - do the work CHECK - measure the result against the goal ITERATE - if it didn't pass, find the weakest part and fix it STOP - when it passes, or when a hard limit is reached

PLAN —— 先搞清楚这个任务到底需要什么 EXECUTE —— 真正把事情做起来 CHECK —— 拿结果和目标对照，看看达不达标 ITERATE —— 没通过？找出最薄弱的地方，再改一轮 STOP —— 达标了就停，或者达到硬性上限也必须停

这五步里，有三个地方最容易决定一个 Loop 是真的有效，还是最后直接崩掉。

真正的 Check，才是 Loop 能成立的关键。

如果你没有对结果进行一个真正有效的检查，那你其实没有 Loop。

你只是让 Claude 不断写草稿，然后每次写完都说：

“好了，完成。”

真正的 Check，才会让“重复做很多遍”变成“每一遍都在进步”。

这个 Check 必须是那种真的可能失败的东西：

一个会通过或者失败的测试；

一个必须达到某个阈值的分数；

一套有明确硬标准的评分规则。

那种“感觉还不错”的软检查，等于根本没有检查。

Stop Condition（停止条件）则是防止 Loop 无限跑下去的东西。

每个 Loop 至少得有两个停止出口：

要么，任务完成了；

要么，已经达到硬性限制。

比如：

“最多尝试 8 次，之后停止，并告诉我发生了什么。”

这不是一个可有可无的附加项。

恰恰相反，它就是为了防止 Loop 卡在一个自己解决不了的问题上，一直转下去，然后默默消耗你的 Token 和费用。

随便拿一个 Prompt，给它加上三样东西：

一个真正可能让结果失败的测试；

一份记录“之前已经做过什么”的记录；

以及一个“最多允许尝试多少次”的上限。

这时候，你就已经有一个 Loop 了。

少掉其中任何一样，你得到的就只是一个看起来像 Loop、花费却照样像 Loop 一样往上蹿的东西。

2——它真的值得用吗？

很多文章会先告诉你 Loop 多么厉害，却很少告诉你：

什么时候其实根本不该用 Loop。

所以这里说个更实际的版本：

只有下面四件事同时成立，才值得专门做一个 Loop。

• 你以后真的还会反复跑它。

不是“以后某一天也许还会用”，而是会规律地使用。

只做一次的任务，不值得为它搭 Loop。

• 这项工作自己就能判断好坏。

也就是说，它里面必须有一个不需要你亲眼去看的检查条件，可以自动判定“通过”还是“失败”。

• 你把目标交给它，它最后把结果交还给你。

如果过程中某一步还得让你进去帮它处理一下，那它就不算真正的 Loop。

• 终点必须是一个可以客观判断的事实，而不能只是“感觉还行”。

如果最终判断结果够不够好，仍然需要一个人凭经验、感觉来拍板，那这个决定就不是 Loop 自己能做的。

这四条只要缺一条，Loop 最后花掉的成本就可能比它帮你省下来的还多。

但现实一点说：

大多数人现在其实根本不需要那种重量级的 Loop。

几乎所有人现在都能直接用的，是一个自我检查型 Loop。

不需要调度系统，不需要服务器，也不需要额外基础设施，基本只会增加正常使用模型本身的成本。

下面就是怎么做。

3 - Build a loop yourself

3——自己做一个 Loop

你第一次做 Loop，根本不需要服务器、不需要 Scheduler，也不需要搞什么复杂配置。

整个东西，一个 Prompt 就能装下。

直接把下面这段扔给 Claude，再把方括号里的内容换成你自己的任务。

一直循环工作，直到输出满足下面的所有标准。 不要提前结束。 GOAL： [准确描述你最终希望得到什么] CRITERIA——必须具体，不允许模棱两可： - [什么样才算好，必须可以衡量] - [什么样才算好，必须可以衡量] - [什么样才算好，必须可以衡量] 每一轮： 1. DRAFT —— 生成或改进当前结果 2. SCORE —— 按照每条标准给结果打 1～10 分，而且要严格 3. GAPS —— 明确列出目前还有哪些地方做得不够 4. CALL —— 如果所有分数都达到 8 分或以上，就写 DONE 并停止。 如果没有，就写 NEXT PASS，并优先修复最薄弱的问题。 规则： - 所有标准都没有达到 8 分之前，绝对不能说完成。 - 每一轮只处理上一轮分数最低的那个问题。 - 不要提问。做出一个合理假设，说明这个假设，然后继续做。

接下来你就可以看着它自己跑起来。

Claude 先写一个版本，然后按照你给出的标准给自己打分，找出最薄弱的地方，再重写一遍。

然后继续。

一直做到真正达标为止。

注意，它停下来的标准不是：

“看起来差不多了。”

而是：

“通过了。”

这就是一个 Loop。

而你刚才只用了一个 Prompt。

不过这里有一件事要注意：

触发它的人，还是你。

是你打开了聊天，是你把 Prompt 粘进去。

你把页面关掉，它也就停了。

它没有定时任务，也不会每天早上自己跑一次。

想做到这一点，就得再往上一层。

到了这里，大多数人通常会走向两个结果：

要么把完整版本搭出来；

要么发现——其实自己根本不需要那么复杂。

4——真正靠谱的实施顺序，以及成本问题

如果你不想让 Loop 一上线就出问题，其实有一个比较靠谱的搭建顺序。

而几乎所有人都会漏掉其中一步。

第一步，先手动跑。

在你开始自动化之前，先在一个普通会话里，把整个任务完整地手动跑通。

因为如果它在人工盯着的时候都不能稳定工作，

那自动化之后也不会突然变好。

只会：

失败得更快，花的钱更多。

把已经验证有效的部分固定成一个可复用模板。

把指令、标准、规则都保存下来，这样下一次可以直接调用，不需要重新搭。

一个只活在某一次聊天里的 Loop，

聊天一关，它也就死了。

接下来，加上 Gate（检查关卡）和 Stop Condition（停止条件）。

也就是：

一个真正能把错误结果卡住的检查；

再加一个最大尝试次数。

这两个少一个都不行。

不然你不是在做 Loop，

而是在搭建一个自动给你烧钱的机器。

再说成本：Loop 可一点都不便宜。

因为每次迭代，模型都需要重新处理一整套上下文：

目标是什么；

上一版结果是什么；

上一轮得了多少分；

哪里没通过。

而这些东西会一轮一轮地越堆越多。

所以一个跑了十轮的 Loop，

并不只是“十个 Prompt 的价格”。

而是：

十个越来越长的 Prompt 的价格。

真正值得关注的，并不是你总共花了多少 Token。

而是：

最后真正留下了多少个有用结果。

比如 Loop 跑了十轮，最后扔掉了六轮。

那就意味着你花了十轮的成本，只留下四轮。

如果最终真正保留下来的比例低于 50%，那这个 Loop 很可能已经比你自己做还贵了。

Graph

1——Graph 到底是什么

这里说的 Graph，不是图表，也不是拿来做可视化的图。

在 AI 工作里，Graph 更像是一张任务关系图：

哪些事情需要做，

以及每件事情依赖什么。

整个结构其实就两样东西。

• **Node（节点）**就是一个具体的工作单元。

一个 Agent、一个任务、一组明确的输入，再加一个明确的输出。

不要把：

“研究这个主题，再总结它，然后写一个草稿”

全部塞进一个 Node。

一个 Node 最好就只负责其中的一件事。

任务越小、边界越清楚，这个 Node 就越有用。

• **Edge（边）**代表的是依赖关系。

只有当第二个 Node真的需要第一个 Node 产出的东西时，两者之间才应该连一条边。

而不是因为：

“它恰好排在后面。”

这个区别其实非常重要。

Graph 工程里剩下那些看起来很复杂的东西，说到底，都只是把Node 和 Edge这两个概念应用到不同规模而已。

真正让一个 Node 能够自动接入整个工作流的，是它有没有明确的输出格式。

如果一个 Node 只是随手输出一大段自由文本，那通常还是得让人来看。

但如果它有固定的输出结构，

下一个 Node 就可以直接读取。

中间根本不需要人工接手。

任务：只研究一个竞争对手的定价，其他什么都不要做 输入： { competitor: "名称", url: "https://..." } 输出： { price: 数字, plan: 字符串, source: URL, date: "YYYY-MM-DD" } 规则： 如果输出不符合这个格式，就拒绝这次结果，重新执行。

正是这种明确的输出契约，才能让 Graph 在节点与节点之间自动流转，而不是每交接一次都要你来管。

2——Fake Edge：找出那些根本不存在的依赖

这里最重要的区别，是：

顺序（Sequence）和依赖（Dependency）不是一回事。

Sequence，只是你当初输入任务时写成了什么顺序。

Dependency，则是：

后面的任务真的必须拿到前一个任务的产出，才能开始。

顺序是你写出来的。

依赖则是任务之间原本就存在的。

Graph 做的事情，只不过是把这种真实依赖画出来。

绝大多数工作流里，两种情况其实都有。

但大多数人从来没有认真区分过它们。

拿你现在已经在做的任何一个工作流，花五分钟就可以测一遍。

把每一步都画成一个框。

每两个相邻步骤之间先画一条箭头。

然后一条一条检查这些箭头，只问一个问题：

“这一步产生的数据，真的会被下一步用到吗？”

如果答案是Yes：

保留这条箭头。

这是真正的依赖。

如果答案是No：

直接删掉。

说明这两个任务其实互不依赖，完全可以同时跑。

没有入边的任务，可以立刻开始。

没有出边的任务，就是最终输出。

你几乎在任何工作流里，都能找到两三个 Fake Edge。

而每一个 Fake Edge，其实都意味着：

你正在白白浪费时间。

一个任务只是因为排在另一个任务后面，就被迫在队列里等着，

但实际上，它从来就不需要等。

3——Diamond：钻石结构

一旦你开始把那些 Fake Edge 一个个删掉，

你会发现一种特别常见的结构开始不断出现。

一个大任务先被拆成几个彼此独立的小任务，同时执行。

然后这些任务的结果，再一起流向最后的一个步骤，由它把所有结果汇总起来。

画出来以后，就像一个钻石：

中间宽，两头窄。

它的正式叫法是：

Fan Out（发散）→ Converge（汇聚）

举个实际例子。

假设你现在要研究三个竞争对手。

最普通的线性做法是：

研究 A，做完；

再研究 B，做完；

再研究 C，做完；

最后统一汇总。

而 Diamond 的做法是：

三个一起研究。

最后只等三个里面最慢的那个完成，然后进入汇总。

输入没变，输出也没变，

但所需要的时间却少了很多。

Diamond 之所以能工作，靠的就是它的 Edge 结构。

最后的综合步骤确实依赖三个研究结果，所以这三条依赖必须存在。

但是三个研究任务彼此之间根本没有依赖。

它们之间的边不存在。

于是：

三个任务并行执行。

最后只在汇总的时候等待一次。

而那次等待本来就是无法避免的。

但 Diamond 要成立，有两件事必须是真的。

第一，这几个并行任务必须真正独立。

不能背后其实共用某个资源，也不能只是表面独立。

第二，最后的汇总步骤必须真的需要所有这些结果。

如果它最终只需要其中一个，那另外几个任务就只是白做。

实际的 Diamond 大概就是这样：

# Diamond——一个可以套用到各种任务上的模式 angles = [ "与前三大竞争对手相比的定价", "买家在评论里最常抱怨什么", "市场目前还没有填补的空白", ] # FAN OUT——每个角度分配一个 Worker，全部同时运行 raw = run_in_parallel([ agent(task=f"研究：{a}。每个结论都必须有来源和日期。") for a in angles ]) # REDUCE——直接用普通代码处理，不调用模型，也不花 Token findings = deduplicate(filter(None, raw)) # VERIFY——每条发现都交给一个全新的“怀疑者”，专门尝试证明它是错的 survivors = [ f for f, verdict in zip(findings, run_in_parallel([ agent(task="尝试证明这个结论不成立。返回 keep 或 drop。", input=f, fresh_context=True) for f in findings ])) if verdict == "keep" ] # SYNTHESIZE——最后由一个 Agent 根据通过验证的结果写报告 return agent( task="写一份最终报告，按置信度排序，并附上来源。", input=survivors )

4——Checker：检查器

那个亲手写出结果的 Agent，往往也是最不适合给这个结果做评判的人。

不是因为它故意骗人，

而是因为它看不到自己的盲区。

产生错误的那套推理，现在又被拿来检查这个错误。

关于 AI 自我审查的大量研究，结论基本都指向同一个问题：

模型往往发现不了自己犯下的大部分错误。

所以规则其实非常简单：

负责干活的 Agent，不负责检查自己的工作。

在 Worker 和最终步骤之间，放一个独立的 Node。

它只干一件事：

在每条发现继续往后传之前，拼命找理由把它淘汰掉。

不是帮它润色，

不是帮它总结，

而是专门去找：

“为什么这条东西根本不应该留下？”

.

这里还有一点很多人会漏掉：

Checker 必须使用一个完全干净的新上下文。

如果你把 Worker 原来的整段对话也交给 Checker，

那它其实根本没在检查。

它只是在另一个窗口里继续顺着同一套思路点头。

一个和 Worker 共用上下文的 Verifier，

不是真正的 Verifier。

它只是：

同一个 Agent，假装自己是两个 Agent。

所以，把检查拆成三个方向。

三个不同的问题，从三个不同的角度，分别尝试把这条发现“干掉”。

VERIFIER NODE 输入： 只给它这条“发现”本身——绝对不要给 Worker 的聊天记录。 上下文： 全新、干净，而且此前从没见过自己要审查的工作。 三个检查，并行执行： 1. 它是真的吗？ 这个结论真的站得住吗？ 2. 它是最新的吗？ 来源够不够新，会不会已经过时？ 3. 这个来源是真的吗？ 打开链接之后，内容真的和它声称的一样吗？ PASS： 如果大多数检查都通过，就保留这条发现。 FAIL： 如果没通过，就在它进入最终步骤之前直接丢掉。

真正值得记住的一条规则是：

Worker 和 Checker 绝对不要共享上下文。

一旦共享，

你又回到了“一个 Agent 给自己的作业打分”这种情况。

只不过这次，你的账单会更大。

5——自己搭一个 Graph

前面讲的这些东西，到现在为止都还只是一个思维模型。

直到你真的给 Claude 一个可以执行的工作流，

它才真正开始变成实用的方法。

有一个词，会改变 Claude 处理你指令的方式：

Workflow。

没有 Workflow 的时候，

Claude 会把你的 Prompt 理解成一串按顺序排列的事情，然后一个接一个执行。

有了 Workflow 之后，

Claude 会先写一个简单的协调脚本，找出哪些 Node 没有依赖，然后把这些 Node 自动并行跑起来。

也就是说：

你负责描述 Graph。

Claude 负责决定怎么执行它。

下面给你三个可以直接粘进 Claude Code 里的例子。

把方括号里的内容换掉就行。

不管每个 Node 里面实际放的是什么任务，整体结构都一样。

Competitive Research（竞争对手研究）

workflow: competitive-research nodes: research_a: task: "研究 [公司 A]。包括价格、核心功能、 最近的变化以及公众评价。 输出结构化总结。" output: company_a.md research_b: task: "研究 [公司 B]。包括价格、核心功能、 最近的变化以及公众评价。 输出结构化总结。" output: company_b.md research_c: task: "研究 [公司 C]。包括价格、核心功能、 最近的变化以及公众评价。 输出结构化总结。" output: company_c.md checker: task: "检查这三份总结。标记不完整、 已经过时或者偏离主题的内容。" depends_on: [research_a, research_b, research_c] output: checker.md synthesize: task: "根据三份总结和 Checker 报告， 从价格、功能和市场定位几个方面 写出一份对比报告。" depends_on: [checker] output: comparison.md

Multi-file Code Review（多文件代码审查）

workflow: code-review nodes: review_auth: task: "检查 auth.py 的安全问题、边界情况 和代码质量。要具体。" output: review_auth.md review_api: task: "检查 api.py 的安全问题、边界情况 和代码质量。要具体。" output: review_api.md review_db: task: "检查 db.py 的安全问题、边界情况 和代码质量。要具体。" output: review_db.md checker: task: "阅读这三份审查结果。 标记多个文件中重复出现的问题， 同时指出可能带来问题的跨文件依赖。" depends_on: [review_auth, review_api, review_db] output: checker.md summary: task: "写一份修复清单，并按优先级排列： 先解决关键问题， 再处理中等问题， 最后处理低优先级问题。" depends_on: [checker] output: final_review.md

要设计一个 Graph，其实你真正需要搞懂的只有一行：

depends_on

没有依赖：

就并行。

有依赖：

就等待。

现在你真正掌握了什么

三个概念，一套思路。

Agent给 Claude 的不是一条“你照着做”的指令，而是一个目标，然后让它自己想办法完成。

Loop让这套工作方式变得更加可靠。

它会自己检查，记下哪里失败，然后继续迭代，

直到真正达标。

Graph则让它变得更快。

把彼此独立的工作交给不同的 Worker，让它们同时跑，最后再汇聚成一个答案。

这三个概念其实是一层一层搭起来的。

你不需要每个任务都把三样东西全部用上。

但当你开始能够判断：

这个任务到底需要 Agent、Loop，还是 Graph？

你就不再只是靠自己“更努力地干活”去解决问题，

而是开始学会：

设计一个更好的工作系统。