8 分钟讲清楚 Agents、Loops 和 Graphs

AI 生成的配图

让 Claude 从等待提示词变成自主完成工作的三部分系统

三部分系统示意图

**大多数人使用 Claude 时，只有一种固定节奏：**提出问题，阅读答案，修正错误，再次提问。这当然可行，但也是使用这个你已经付费的工具最慢的方式。

同一个产品里其实已经内置了一套更快的用法，它建立在三个概念之上：

Agent：围绕目标采取行动，而不是等待你逐步下达指令。
Loop：持续工作，直到结果达到标准，而不是生成一次回复就停下。
Graph：同时运行多个任务，而不是一个接一个地执行。Claude 已经支持这三种结构。

大多数人从来没有使用过它们。这不是因为概念复杂，而是因为很少有人把三者放在一起，解释每一种结构什么时候值得使用。

Agents

Agent 示意图

让 Claude 总结一篇文章，不算 Agent，那只是聊天。

让它找出某个主题下被引用次数最多的论文，提炼每篇论文的核心论点，互相核对，然后交给你一页纸的简报，而且整个过程中你一次都不需要介入，这才是 Agent。

区别不在于底层模型，而在于你围绕模型搭建了什么结构。

Agent 比普通聊天多了三样东西。第一，它可以自行调用工具，搜索文件、编写代码、访问外部系统，而不是等你先去获取信息。第二，它能在任务之间保留记忆，不只是记住当前对话，因此知道自己已经尝试过什么。第三，它会循环运行，直到工作完成，而不是生成一条回复就结束。

**并不是每个任务都需要完整的 Agent，因此可以把 Agent 想成不同层级。**带有工具、会在回答前主动搜索的 Claude，已经有了一点 Agent 的特征，因为这是它自行决定的。给它一个目标，让它自行拆分步骤，而不需要你卡在每个步骤之间，就又上升了一个层级。

如果让它按计划运行，整个过程不需要人类检查或介入，你就到了最完整的形态。不同层级之间的差异，来自你围绕同一个模型搭建的结构，而不是底层换了一个更聪明的模型。

下面这段系统提示词可以把 Claude 变成一个真正工作的研究 Agent，而不只是一个碰巧能搜索网页的聊天工具：

You are a research agent. Find what matters, not just what exists.

1. Break the task into 3-4 specific sub-questions
2. Search each one independently
3. Keep only findings that directly answer a question
4. Flag contradictions instead of picking a side
5. Say so explicitly if you can't find a reliable answer

Agent 最容易出问题的地方，通常是记忆。

任务运行时间一长，最初的目标可能会悄悄脱离上下文。或者你关闭了标签页，下一次会话只能从零开始。两种情况的解决方法是一样的。停止之前，让 Claude 写下自己的检查点，包括已经完成的工作、已经做出的决定和剩余任务。这样下一次会话就能接着做，而不是重新开始。

Loops

普通提示词交给 Claude 一条指令，然后等你决定下一步做什么。Loop 则交给它一个目标，让它自行决定如何实现。

每个 Loop 都会运行同一个五步循环：

Loop 的五步循环示意图

其中有两步决定了这个 Loop 是否真正有效。检查必须是可以明确失败的东西，例如测试、与阈值对比的分数，或包含硬性标准的评分表，而不能只是凭感觉。停止条件也必须有明确上限，不能只有一个终点。否则 Loop 会在一个无法解决的问题上不断运行，持续产生费用。

只有四个条件同时满足时，才值得搭建 Loop。你会定期重复运行这项任务，而不只是今天做一次；这项工作可以在不需要你盯着的情况下自行评估。

你交给它一个目标，而不是亲自照看每一步；终点是一个事实，例如测试通过，而不是只有你才能做出的主观判断。四个条件中少一个，自己完成这项任务反而更划算。

只用一条提示词就能搭建一个可运行的 Loop，不需要调度系统或基础设施：

Work in a loop until the output clears every criterion. Do not stop early.

GOAL: [what you want produced]
CRITERIA: [specific, measurable standards]

Each pass: draft, score 1-10 against each criterion, list what's weak,
fix the weakest gap. Call it DONE only when every score clears 8.

运行前需要知道一件事：Loop 并不便宜。每一轮都会重新发送完整上下文，包括目标、上一次输出、评分和失败原因，因此上下文会随着迭代不断变大。你应该记录最终保留下来的输出数量，而不是只看用了多少 Token。一个运行十轮、最后得到四个可用结果的 Loop，成本已经高于手动完成任务。

Graphs

这里说的 Graph，不是图表，而是一张描述哪些任务需要执行、以及它们分别依赖什么的地图。

Graph 示意图

整个结构由两部分组成。节点是一个边界清晰的工作单元，有一个输入和一个输出，规模足够小，可以独立发挥作用。边只有在第二个节点确实需要第一个节点的产出时，才连接这两个节点，而不是因为你在脑中恰好按这个顺序排列了它们。

第二部分正是大多数工作流浪费时间的地方。把每一步都画成一个方框，再画一条箭头指向下一步，然后逐条询问：下一步真的需要这一步产生的数据吗？

如果需要，就保留这条边。如果不需要，就删掉它。两个步骤之间没有真实关系，可以同时运行。大多数工作流中都藏着两三条这样的虚假依赖，每一条都是一段本来不必等待的延迟。

删掉虚假依赖后，最常见的一种结构就会出现：多个相互独立的任务并行运行，最后都把结果交给一个汇总步骤。

三个研究任务互不依赖，因此可以同时运行。

综合步骤确实需要这三个任务的结果，所以必须等待，而这就是整个系统中唯一需要等待的地方。线性版本会完成一个任务，再开始下一个，完成第二个后再开始第三个。并行版本只需要等三个任务中最慢的那个。

还有一个环节能让整个流程更可靠。负责产出发现的 Agent，往往最不适合判断自己的结论是否正确，因为它看不见自己的盲点。应该在工作节点和最终步骤之间加入一个独立检查器。这个检查器要使用全新的上下文，从未见过它正在评判的工作，并且只执行一个范围明确的任务：尝试证伪每一项发现，而不是改进它。

在 Claude 中，一个词就能改变这类提示词的处理方式：workflow。没有它，步骤会一个接一个运行。有了它，Claude 会自行寻找没有依赖关系的节点，并行运行它们：

workflow: competitive-research

Claude workflow 示意图

设计这类工作流时，只需要理解 depends_on 这一行。没有依赖，就并行运行。有依赖，就等待。

大多数人会犯的错误

常见错误示意图

最常见的错误，不是选错了概念，而是在手动验证之前就直接开始自动化。如果一项任务在一次普通对话中都无法稳定完成，那么让它进入 Loop 或按计划运行并不能解决问题，只会让它更快失败，而且每次失败的成本都更高。

第二个错误，是让工作节点检查自己的输出。模型给自己的作业打分，往往会漏掉第一次犯下的同样错误，因为它用来检查的推理方式和用来生成结果的推理方式相同。检查只有在背后有一个全新、独立的上下文时才有意义。

第三个错误，是把执行顺序和依赖关系混为一谈。你按某种顺序输入步骤，并不代表第二步需要第一步的产出。大多数工作流里本来就存在真正的并行空间，只是大多数人从来没有停下来找过。

三个概念，底层是同一个模型。

Agent 把逐步指令换成了一个目标。Loop 把一次性草稿换成了经过真实标准检查的结果。Graph 把任务队列换成了并行工作，只在确实无法避免的地方等待。

它们都不需要换一个模型，只需要围绕你已经拥有的模型搭建结构。一旦你能看出一项任务需要三者中的哪一种，就不会再只是在聊天窗口里更加努力，而是开始围绕任务设计系统。

核心要点

Agent 就是普通聊天加上三样东西：可以自行调用的工具、贯穿任务始终的记忆，以及持续运行到工作完成的循环，而不是生成一条回复就停下。
Loop 只有在具备一个真正可能失败的检查和一个明确的停止上限时，才算真正的 Loop。缺少其中任何一个，它都只是生成草稿的昂贵方式。
Graph 只有在区分真实依赖和仅仅因为输入顺序恰好如此的步骤后，才值得搭建。大多数工作流都藏着没人发现的免费并行空间。
不要让同一个上下文检查自己的输出。检查器需要看到发现结果，但不应该看到产生这个结果的推理过程。
在自动化任何任务前，先在一次对话中手动测试。如果任务无法稳定完成，Loop 或定时任务只会让它更快、更昂贵地失败。
这些结构都不需要换一个模型，只需要围绕已有模型搭建结构。

Agent、Loop 还是 Graph：快速决策矩阵

Agent、Loop 和 Graph 的决策矩阵

参考文献

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023).
Huang, J., Chen, X., Mishra, S., Zheng, H. S., Yu, A. W., Song, X., & Zhou, D. (2024).

**注：**本文所有图片均由 AI 生成。

下面是一篇与本文标签相关的文章。