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

Agent、Loop、Graph一篇文章把你需要知道的都讲清楚大多数人用 AI基本都是同一个节奏问一句读回答发现问题修改再问一次。当然这种方法能用。但它也是效率最低的一种用法。其实还有一种更快的方式。它由三个部分组成一个能自己规划、自己行动而不是等你一步一步带着走的Agent一个会一直运行直到任务真正达到要求才停下来的Loop以及一个由多个 Worker 并行工作的Graph专门处理那些单靠一个 Prompt 根本做不完的事情。Claude 这三种能力其实都能做到。只是大多数人从来不知道。不是因为这些东西有多复杂。而是因为一直没人把这三样东西放在一起完整地讲清楚。看完这篇文章你会真正明白 Claude 到底能做到什么。你会知道Agent、Loop 和 Graph 分别是什么它们是怎样一步一步发展起来的什么时候值得用什么时候反而是在给自己挖坑以及怎么用今天就能上手的 Prompt 和代码把这三套东西自己搭出来。Agents1——Agent 到底是什么让 Claude “总结一下这篇文章”这还不叫 Agent。这只是一次普通的聊天。但如果你告诉 Claude“找出这个领域引用次数最多的三篇论文提炼每篇论文的核心观点把它们互相交叉验证最后给我写一份一页纸的简报。”然后从头到尾你什么都不用插手它自己把这些事情全部做完——这才叫 Agent。真正的区别不在模型本身。而在于围绕这个模型搭起来的那套结构。一个 Agent比普通聊天多了三样东西。第一它可以自己调用工具。搜索、文件系统、代码执行、外部 API这些都可以。它不会等着你去找信息而是自己去找。第二它有能跨任务保留下来的记忆而不是只记得当前这一轮对话里的内容。它知道自己已经试过什么什么方法奏效过之前做了哪些决定。第三它有一个持续运行的 Loop。它会一直做下去直到任务真正完成而不是生成一次回答就算结束。它不会每走一步就把工作重新丢回给你。当这三样东西都具备之后Claude 就不再只是一个“你拿来聊天的 AI”。它开始变成一个真正替你干活的东西。2 - The levels of agentic work2——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. 把任务拆成 34 个真正值得回答的具体问题 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 里的那些信息始终都在那里。Loop1——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 didnt pass, find the weakest part and fix it STOP - when it passes, or when a hard limit is reachedPLAN —— 先搞清楚这个任务到底需要什么 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 yourself3——自己做一个 Loop你第一次做 Loop根本不需要服务器、不需要 Scheduler也不需要搞什么复杂配置。整个东西一个 Prompt 就能装下。直接把下面这段扔给 Claude再把方括号里的内容换成你自己的任务。一直循环工作直到输出满足下面的所有标准。 不要提前结束。 GOAL [准确描述你最终希望得到什么] CRITERIA——必须具体不允许模棱两可 - [什么样才算好必须可以衡量] - [什么样才算好必须可以衡量] - [什么样才算好必须可以衡量] 每一轮 1. DRAFT —— 生成或改进当前结果 2. SCORE —— 按照每条标准给结果打 110 分而且要严格 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 很可能已经比你自己做还贵了。Graph1——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(taskf研究{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。, inputf, fresh_contextTrue) for f in findings ])) if verdict keep ] # SYNTHESIZE——最后由一个 Agent 根据通过验证的结果写报告 return agent( task写一份最终报告按置信度排序并附上来源。, inputsurvivors )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.mdMulti-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你就不再只是靠自己“更努力地干活”去解决问题而是开始学会设计一个更好的工作系统。