Agentic Loops for Knowledge Workers

这个夏天，高级AI用户之间最热门的话题之一就是循环或循环工程这个概念。

简单来说，这个概念就是思考我们与AI互动的方式，不是去提示它、告诉它该做什么，而是创造一种环境，让AI或者说智能体可以一遍又一遍地循环运作，努力完成一个特定的任务，并且有一个可衡量的输出结果，AI可以对照这个结果来自我检查，一直运行到根据这个可衡量目标完成任务为止。

循环首先在软件工程领域站稳了脚跟，因为那里任务的性质比较清晰，成功与否也很明确。

把循环应用到知识工作领域，有时成功标准不那么清晰，这确实更具挑战性，但如果有合适的工具来设计你的知识工作任务，使其适应这种智能体化的工作方式，也并非不可能。

今天的节目是一场与Nufar Gaspar一起的网络研讨会，我们正是要探讨这个问题，节目马上开始。

《AI每日简报》是一个每日更新的播客和视频节目，讨论AI领域最重要的新闻和讨论。

好的朋友们，在开始之前先简单说几个通知。

最后，提一下：我现在正在旅行，过劳动节和我的生日。

所以如果发生了什么惊天动地的事，而你在纳闷为什么收到的是这个关于智能体循环的分享，那就是原因。

当然，如果事情真的大到一定程度，我还是会临时插进来讲一下的。

那么现在，就让我们深入探讨知识工作者的智能体循环这个话题吧。

今天我们要讲一些我认为非常重要的话题，关于循环、图谱，以及如何利用最先进的技术让智能体自主运行并协同工作。

我想把话筒交给Nathaniel，让他先来介绍一下我们今天为什么要聚在这里。

太好了。

目前一个非常有趣的动态是，大家已经基本过了那个阶段——就是当你听到有人说自己在做vibecoding，或者用Claude Code做点什么时，不会再认为你作为一个知识工作者，突然就想转行当软件工程师了。

很明显，我们现在正处于一个探索阶段，就是弄清楚如何让代码、软件工程风格的流程和这一套工具，进入工作的其他领域，并影响这些工作是怎么完成的。

就在几周前，OpenAI发布了最新的使用统计，数据显示AI的消费和使用方式，已经从辅助型大幅转向了智能体型。

你们屏幕上看到的那张图表就是来自这些数据。

可以看到，在大约四月、五月的时候，我们跨越了一个分水岭——AI总token消耗量的主体，从那种ChatGPT辅助的范式，变成了智能体范式。

值得注意的是，伴随着这种更高级的使用方式，那些以这种新的智能体方式使用AI的公司和个人，正在逐渐拉开差距。

他们——他们与其他人之间的差距，至少在token消耗量上——当然这是一个很粗略的指标，但至少从这个指标来看，他们与平均水平之间的差距越来越大。

真正困难的地方，我相信很多人都有同感，就是如何把这些源于软件工程的概念，转化到其他类型的知识工作中，这个过程可能很艰难。

它可能很抽象。

它可能涉及多个抽象层次。

所以我们想组织这次网络研讨会，因为这种使用智能体进行循环、不再只是提示、而是设计循环之类的想法，已经成为AI早期采用者圈子里热议的话题好几个月了。

但我认为，对于知识工作者来说，它到底意味着什么，仍然是很抽象的。

所以这次活动的目标，就是带领大家进入与AI互动的新方式。

我很期待看看我们能走到哪一步。

好的。

那么，一个循环基本上就是一个工作岗位，而一个图谱就是一个组织。

这其实是你自己在播客里说过的话。记住这一点，我们一会儿会带你过一遍。

但如果让我用三句话给你总结一下我们在做什么。

首先，AI工具——你们大多数人都在用的那些智能体工具——已经在后台使用循环来完成任务了。

一旦你学会给它们一个具体且可验证的最终目标，它们就会持续工作直到任务真正完成，不需要你反复催促，也不会让你因为可能平庸的结果而沮丧。

这就是那个巨大的承诺，明白吗？

当单个循环和单个智能体不够用时，你总可以把多个循环组合成智能体团队。

这就是社交媒体上那些关于图工程噪音和讨论背后的全部思路。

这里面是有实质内容的。

这一点非常重要。

所有这些想法都诞生于软件工程领域。

所以如果你有这方面的背景，或者你的公司里有计算机科学家之类的，那么图对他们来说并不是什么新鲜事，AI工程师们用这些概念已经构建了好几年，尤其是最近几个月对智能体关注很多，但正如Nathaniel所说，几乎所有的实践都非常聚焦于编码，而我们会尽量向你展示它的优缺点、陷阱，以及如何最好地将其应用于其他类型的工作，也就是知识工作。

最后还有一点要提前说明。

因为你日常做的大部分工作可能只需要——我们称之为——常规的智能体执行。

只有在某些情况下你可能才需要循环。

图和更复杂的东西应该用于特殊场合，也就是说我希望你保持简单，只在必要时才进入循环、图和多个智能体协调。

所以我希望你在保持简单的同时，也要意识到现代技术可以带你走多远。

快速说一下社交媒体上发生了什么，对于那些不总是泡在Twitter/X回声墙里的人。

七月份，OpenClaw的创始人说了六个字。

他基本上是在说，我们不再谈循环了，我们谈的是图。

很快，获得了数百万的浏览量。

他半开玩笑，但很快就有人为循环工程写了讣告。

这主要是一个命名事件。

但我认为这个玩笑之所以站得住脚，是因为它指向了更真实的东西。

为了具体说明正在发生的事情，或者说这个有一定实质内容的命名阶梯，我们就是这样走到今天的。

而这，我认为，讲述了过去一两个月甚至一两年里智能体和AI的演变故事。

一开始我们非常痴迷于你对模型说了什么。

那是提示工程。

我们都学会了如何有效地与模型对话。

后来我们痴迷于模型知道什么。

那就是我们广泛讨论过的上下文工程。

然后我们开始讨论它在哪里运行，以及它能接触哪些工具。

这就变成了围绕harness engineering的讨论。

今年，我们越来越开始讨论模型和agent能自主运行多长时间。

这就是loop engineering。

最后，我们开始问，需要多少个它们协同工作才能完成任务。

而这正是现在被称为graph engineering的核心。

如果你注意到这个发展方向，每一次演进都是为了让AI在更大规模上获得更多自主性。

这就是我们的方向。

甚至有些人说，这不过是随着技术能力提升而自然演进的重新包装而已。

而且因为这个领域和从业者大概每隔几个月就会增加新的术语和技能演进，追逐这些会让人精疲力尽。

我认为更重要的是本质，是知道如何让agent高效工作，以及如何编排它们。

这个技能大概能在每一次改名和社交媒体上的各种热潮中存活下来。

归根结底，我们只是想把工作做好，并且对我们能做的事情抱有雄心。

好了。

以上就是背景。

最后一个数据点，我认为它证明了loop的重要性。

就在三周前，杰夫·迪恩（Jeff Dean）——我认为他是现代技术史上最著名的工程师之一——离开谷歌时，他基本上是去创办了一家名为Discovery Loop的公司。

这家公司将致力于利用loop进行科学发现。

所以，能够以loop方式运行AI，以逐步获得更好的结果，这是有价值的。

好。

所以这就是背景。

现在我想确保我们对什么是loop以及在哪里能找到loop达成共识。

你需要明白一点：你使用的每一个agentic工具，无论是Cowork、ChatGPT Work、Codex、Cursor，还是任何其他agentic工具，其底层实现的已经是一个loop了。

这就是harness在做的事，只是有效程度各不相同。

基本上，它运行一个迭代过程：规划如何完成任务，行动（通常使用工具），检查从工具获得的结果是否足够好，然后进行调整。

问题是，这些agentic工具背后的公司所实现的loop，其质量取决于他们的实现。

而且一般来说，它们相当通用。

这就是为什么尽管这些工具很棒，我们也能从中获得很好的结果，但在很多情况下，我们注意到，如果我们希望它们加倍努力，或者在停止之前对某件事进行多次迭代，我们就需要稍微推动它们，或者非常主动地提示它们。

这不是那些公司已经实现的原生loop会为你做的事情。

但要理解的一点是，在底层，总有一个loop。

那问题来了，到底什么是这个时髦词，或者说我们说的循环、高级循环指的是什么？

今天要聊的循环，本质上是让你来掌控最终目标的循环。

我们要找的是一种循环，它发生在你扩展工具本身已有的原生循环时。

扩展的方法就是利用特定的命令。

在大多数工具里，它叫做 /goal 命令。

在 Cursor 里，它直接就叫 loop 命令。

这个命令的全部目的——就是给工具一个具体的最终目标，并确保这个目标高度可验证，同时保证工具能逐步自我检测是否完成。

明白吗？

这就是我们今天要聊的全部内容。

如果你想掌握这个，有两件事特别重要：首先，你需要知道什么时候该创建这种特殊循环——也就是你控制最终目标，并且鼓励工具反复运行直到结果完成的那种循环。

第二件要知道的事，就是正确设定终点线。

对于想在日常工作中利用这个的知识工作者来说，这是最重要的技能。

这里还有两点补充。

第一，循环不等于定时任务。

定时任务回答的是“什么时候运行”的问题。

这个“什么时候”，可以是基于时钟的。

也可以是当某件事发生时，比如有邮件发出去的时候。

那是自动化或定时任务。

循环回答的是“直到”的问题，它会在工作达到标准时停下来，不管花了多久，或者遵循你给的其他约束条件。

我一会儿会展示这些约束条件。

所以这两者承诺的东西完全不同。

好，所以别把循环和自动化搞混了。

它们的用途不一样。

另外，之前提到过，因为循环源自编程，它们对知识工作的优化还不够，毕竟程序员是为自己和代码编出来的。

而编程有一个非常明显的超能力，不是所有知识工作都具备的。

那就是验证，编程有大量可执行的验证手段。

代码要么编译通过，要么编译不通过。

测试要么通过，要么失败。

相对来说非常容易。

如果现场有程序员，我不是说你们的工作简单，但在验证代码方面，我们有内置的机制，使得“一直运行直到满足某个条件”这件事更可行得多。

好的。

那么当我们谈知识工作的时候，很多时候，我们自己没有一个内置的裁判。

这份报告够不够好，可以拿去给管理层看？

这个分析够不够深入？

没有人家的编译器来帮你回答这些问题。

所以当有人跟你说，直接把它放在循环里跑就行，他们就忘了，作为程序员他们是有免费验证手段的，而我们，或者说你们，没有这些。

好消息是，这也是我们今天要说的核心点，就是知识工作的验证是可以由你自己设计的。

这比程序员做起来要稍微困难一点，但你可以自己造出一个裁判，来决定工作做完了没有。

而这就是你需要做好的事情。

如果你设计不出一条非常清晰、可验证的终点线，那就干脆别用循环。

明白吗？

那我给你一些具体的判断标准，看看手头的任务值不值得用循环，能不能用循环。

一个任务要值得用循环或者适合用循环，首先它得是那种长期运行的，也就是说不是你用一个提示就能搞定、结果还不错的那种。

现在的模型，很多时候单次就够了。

我建议你如果能一次搞定，就尽量一次搞定。

第二个条件，而且这些条件得同时满足，就是你得能检查结果够不够好，或者进展方向对不对。

这是最重要的一组条件。

第二个条件是你找那些可能或者你可能想让它跑一整晚的事情，也就是说你想让它全自动运行，哪怕只是吃个饭的工夫。

不一定非得跑一整晚。

最后回来看到的是完成的结果，而不是草稿。

那可能说明用循环是合适的。

另外，我们也想要那种一直跑直到达到某个标准，或者一直不停地监视某个东西的任务。

那些也说明适合用循环。

还有一点，从经验来看，我们也想要那种你试过 Opus、Fable、GPT Sol 等等你能拿到的最智能的模型。

但结果就是不够好。

单次执行达不到标准。

还有就是，当你想让模型更努力一点，而不是像默认那样礼貌地只跑一次的时候，也适合用循环。

比如你让模型去做研究，我们马上就会演示一个这样的例子。

通常它会跑一次像样的网络搜索，然后把结果整合一下，就这样了，除非你非常严格地去提示它。

很多时候，它不会自动多次迭代来提高结果的质量和丰富度，除非你用很客气的语气或者不太客气的语气去要求它。

最后，我们想要一个能自然重试和改进的东西。

明白吗？

就是可以先出个草稿，然后通过多次迭代变得更好。

顺便说，这也是为什么我觉得Jeff Dean会在研究和科学领域这么做，因为在这里，随着实验越来越多，通常最终你会找到正确的方向。

另一方面，这也很重要：如果任务很短，一步就能搞定，那你的判断本身就是实际工作，你不能把判断权交给一个裁判。那么，和你的智能体正常对话就是正确的选择，选这个才是明智之举，不是偷懒。

明白吗？

最后要说的是，循环是你用智能体工具时最耗token的执行方式之一。

所以要注意，把token花在真正重要的事情上。

不要什么事都循环。

我们只在有价值的地方用循环。

好了，下面是一些具体案例，说明人们做哪些知识工作时会利用循环。

我先说说我第一次尝试用循环的经历。

有点讽刺的是，我决定用循环来深入研究token效率的最佳实践。

这个我待会儿也会演示一下。

我知道，用最浪费token的方法来找token效率，是有点讽刺，但这确实是个很好的应用场景，你可以试试。

比如做研究时，你希望智能体深入又广泛地搜集信息，进行综合，确保得到你想要的结果。

另一个很有力的例子是很多人用循环来做广告和活动优化。这是一个高度可验证的场景，因为你总是可以用非常具体的数据来测试点击率和其他数字营销指标是否真的提升了。

通过反复尝试多种方案，让智能体在循环中工作——有时不限次数，有时设个上限——你可以大大改进结果。

还有其他一些结果，比如竞争分析或扫描。

对内容进行审核、验证结果、做合规检查，等等。

不需要用循环的地方是那些需要人类判断并且不能完全自动化的事情。

所以如果高管沟通需要你的判断，那就不是循环。

同样道理，招聘和战略这类事情也一样，因为最终自主性本身没有味道，你可能需要亲自在场。

做最后的拍板。

好了，这就是人们在循环中使用的一些例子。

如果非要总结一下构建循环的三个条件，那第一是：可检查的终点线。

知识工作只有在你能设定一个非常枯燥、非常可检查的终点线时，才能成功用循环。

顺便说，这里说“枯燥”是夸奖的意思。

举个例子，说“我要200个经过验证的数据点”，这听起来很枯燥，但非常具体，机器也完全能检查。

每个竞争者都要覆盖到，每个主张都要注明来源，摘要不超过150字——很枯燥，但很好检查。

你可以想想你自己领域里类似的事情，而且实验部分还会鼓励你去做这个。

像“让它有洞见”这种东西就是没法检验的。

智能体根本没法在“让它有洞见”这件事上达成一致。

我们要找的是智能体自己能衡量的东西。

第二点我们要做的是尽量给它一个受限的沙箱环境。

在这个空间里，循环出错的代价很小。

打个比方，回到广告活动或者数字营销优化的例子，不要在最重要的项目上就让智能体乱跑，除非你不在乎结果。

但是，比如说在沙箱里做研究，或者在沙箱里跑一个特定的实验，如果有错误，代价也不大，因为我们只是停留在草稿模式或者一个受限的区域里，那才是更适合跑这个循环的地方。

最后一点，我们想要一个能收尾的任务。

所以我们想要的是那些有不同路径、经过不同潜在关卡的使用场景。

我们实际上是在一点点接近完成的状态。

研究就是一个能收尾的任务。

更多来源、更少空白会让它变得更好，又回到那一点上了。

永远没完就不是收尾，智能体会陷入无限循环。

它会一直问自己：够好了吗？

不知道。

我再试试。

够好了吗？

不知道。

我再试试。

所以，如果一个任务定义不明确而且没法收尾，我们就不会让它循环。

那么你怎么定义——这就像底线——你怎么定义这个循环的目标？

从概念上讲，你应该把它看作设计一个目标卡片，这些是你设置目标卡片时要配置的东西。

这些也是你在实际执行循环命令之后要附加的内容。

所以它从一个具体清晰的目标开始。

好。

目标应该非常明确，非常机器可读。

比如说，在我要马上触发的研究中，我想创建一份截至今天、也就是2026年8月的权威版token效率手册。

你应该定义一下循环的输出是什么。

在我们这里，输出会是一个文件，但对你来说可能就不一样了。

这一点决定了成败，因为这是你定义初始判断标准和停止条件的方式。

在这个例子里，我的要求是超过200个独特的数据点。

每个数据点都要有URL、日期和类型。

我想要一个具体的混合比例：至少40份供应商文档、40份实践者内容、20个基准测试，而且不能有重复。

这就是我试图给机器一个非常具体的目标，说明这个循环的目的是什么。

一旦所有这些条件都满足了，agent就会停止工作。

所以你的技能就在于知道如何精确配置这些条件。

如果你很难定义‘什么时候算完成’，也就是说你找不到一个非常清晰、毫不含糊的标准，那你就会遇到困难，循环可能跑得太短或者太长。

那就不是正确的方向了。

你可以选择配置阶段，比如具体指定agent要经过哪些关卡或执行哪些类型的操作。

这不是必须的。

有时候你想管理这些。

有时候你其实不想这样做，因为你希望给agent足够的判断力，让它自己决定如何通过这些停止条件来实现目标。

而且在所有工具中，你还可以添加额外的——我们称之为‘保险’或‘后备’机制——来避免循环无限运行。

比如在这里，为了确保互联网上可能确实没有200个独特数据点，而agent会一直不停地跑下去，除非我给它另一个停止条件。

所以我可以告诉它，最多尝试30轮，并且只在沙盒里操作，也就是说不要跑到外面去执行操作。

你也可以用时间上限来限制。

而且根据你使用的具体工具，有时还可以添加其他约束，以确保万一这个循环无法收敛，你还有另一种机制让它收敛。

拥有这个后备机制其实非常重要。

所以这就是正确的目标。

我们快速演示一下。

回到我的用例，我想做token效率的研究。

我现在在Claude Code里面。

在Claude Code里，这个循环叫做/goal。

看看我这里的卡片。

当以下所有条件都成立时，研究就算完成了。

我想要的artifact，就是这个文件。

我想要执行摘要、数据等等。

我给它具体的标准，并给它一个配额。

它包含至少200个关于agentic AI工作中token效率的独特数据点。

不能有两个点陈述同一个事实。

收据、每个数据点等等等等，都会生成一个 URL。

这就是我要求的混合内容，正如说明的那样，而且我还要求一份日志。

我要求一份日志是为了向你展示这个 loop 是如何工作的，但我实际上认为，当你在运行一个 loop 时，让模型稍微啰嗦一点，大声说出它在做什么以及当前是第几个循环，这样你就能看到进展，这是一个非常好的做法。

如果你想监控，尤其当你刚开始使用 loops 时，这会是一个很好的习惯。

我不打算用 Fable。

我打算用 Opus，而且我会切换到自动模式，确保它真的在运行。

当然我们不会坐在这儿等它跑完，我估计起码得等上二十分钟到三十分钟甚至更久。

但你可以看到，目标已设定，然后它开始反映解读情况。

它会开始反映各个循环的变化。

为了不让你干等，我之前已经跑过完全相同的命令了，你现在看到的就是结果。

来看看跑得怎么样。

完全相同的命令。

你看这里，第一个循环检查了工作空间，这不重要。

第二个循环，它找到了 200 个中的 56 个。

它检查了各种来源。

第三个循环时，它达到了 200 个中的 90 个，以此类推。

有意思的是，它超出了 200 个。

在其他一些执行中，它甚至一路跑到了 300 个。

所以它并不总是那么守规矩，不过好在我们设了 30 个循环的上限，所以不会超过那个数。

那就是终点线，它创建了一个产物。

它还给了我一些东西，如果大家感兴趣的话可以展示给你们看。

这就是在这里运行一个 loop 的方法。

另一个 loop 正在后台运行。

我们稍后可以查看。

但这正是全部的目的所在。

那些就是 loops。

现在我想确保你明白 loops 可能会失败，而且可能失败得很惨。

第一个是资源消耗问题，它会一直跑下去。

第一个就是消耗跑道，它会一直跑下去。

这就是为什么我们有硬上限，也是为什么我说它非常关键。

我见过有些人让循环无限制地跑下去，或者跑的时间比他们预期的要长得多。

还有一种循环会卡住，陷入没有进展的死循环。

有时候只是因为无法收敛，或者某些条件不满足。

如果发生这种情况，我们需要手动停止执行。

不同的工具里也有专门的命令，或者如果我们知道这是一种容易卡住的循环（因为你试过），我们可以让它停下来报告。

有时候循环是完成了，但结果非常平庸。

这很隐蔽，因为它可能满足了你的终点定义的字面要求，但结果仍然很平淡。

所以你要做的首先是承认，这不是循环的失败。

这很可能是你目标定义的问题。

如果它逐字满足了你的目标定义，但你对结果不满意，那就说明你需要更好地定义终点线或者评审标准。

而且在很多情况下，这会涉及质量和品味这些比较难配置的东西，但这是需要注意的一点。

最后，有时候我们只是把本来不适合循环的东西放进了循环里跑。

所以如果是这种情况，设置轮次上限是最好的办法。

每一集我都会聊 OpenAI、Anthropic、xAI、Google 和 Meta 之间的竞争。

如果你听了一段时间，你可能有自己偏爱的公司。

也许你觉得 OpenAI 和 Anthropic 能保持领先，或者 Meta 的开源策略最终会胜出。

不管你怎么看，每家 AI 实验室都创造了不同的投资机会。

好了，我们网络研讨会的循环部分就讲完了。

简单总结一下，我们谈到了循环本身就是一个你正在使用的任何智能体框架都会执行的周期。

但循环命令或者 /goal 命令，它的全部目的是确保你可以通过一个可验证的目标，让工具更努力、更长时间地工作。

我们还区分了调度和循环。

它起源于编程领域，所以我们所有人都需要更努力地创建在知识工作中合理的终点线，或者如果可能的话不使用循环。

这里的关键技能是这两点：识别使用场景，配置目标卡片，并且始终加上上限和安全沙箱，以确保它能正常工作。

现在，我想从循环转到组织结构图，因为到目前为止讲的都是单个工作者。

是一个智能体独自通过循环工作直到完成。

整个领域的进展就在这里。

好的。

我们都是从左边开始的，或者如果你还没开始构建智能体，你应该已经在那个阶段了。

然后我们现在讲了在相关且适当的情况下进行循环操作。

下一站就是工作本身开始分裂的时候。

基本上，我们有多个agent。

每个agent负责一块，在它们之间传递工作、传递信息。

那会形成一个walk graph，而且它是为某一个任务构建的，明白吧？

最后一站就是当那些agent不再是临时的，而变成你的常驻团队，也就是有时所说的org graph。

所以，一个agent只工作一次，或者一个agent在loop里工作，只有当我们觉得有必要、有真正的需求时，才会把工作拆成多个agent。

这个后面还会再讲。

最后，如果我们意识到想要完成的工作远不止一件事，那我们就可以构建一整个agent组织，作为一个know graph来让它运作。

所以有一点要说清楚，不是说你一定要达到第四级。

对。

你不需要非得升到那里。

很多任务用第一级就足够了，等等。

但在某些情况下，如果要解锁结果的质量和规模，就必须一路走到构建完整的agent团队并高效协调它们。

所以我们只在有理由的时候才升级，但在某些情况下，这里能获得巨大的价值。

好，为了保持简单和具体，我想解释一下什么是graph。

graph基本上就是点和箭头。

就这么简单，明白吧？

这些点叫做节点（nodes）。

对我们来说，一个节点就是一个agent或者一个需要完成的任务。

箭头叫做边（edges），边里包含流动的工作或信息。

当箭头有方向时，比如研究流向写作agent，我们就说这个graph是有向的。

还有一个很有意思的细节，同时给在座的计算机科学爱好者或者好奇的人，看最下面那行，对吧？

如果我们有一个节点，箭头指向它自己，那就是教科书上loop的定义。

所以loop和graph不是不同的东西。

loop可能是graph最简单或者最小的一种形式。

明白吧？

所以真正的问题一直就是，你的工作值得多少个节点？

计算机科学已经这样工作50年了，所以这并不新鲜。

但对当今时代来说，新的是AI让画图这件事变得可操作了。

今天你可以画出来，然后它真的能为你运行。

好的。

所以，这就是重点，对吧？

这可不是你在计算机科学101里学到的什么理论东西。

这是你可以实际执行的东西。

另一个需要澄清的概念，因为同一周这个话题火了，LinkedIn上有一半的人，还有X上当然，也在讨论知识图谱。

我见过非常聪明的人把三个不相关的东西混成一个词。

所以我们有知识图谱。

那些是存储事实的图，我们知道的以及它们如何连接。

这是一种非常漂亮的技术，完全不同，跟我们这里讨论的没什么关系。

我们还有LangGraph，你可能听工程师提过。

这是一个开发者框架。

这是一个用代码构建代理系统的工具，它利用了图的力量，是一种非常强大且优秀的技术。

而今天我们关注的是工作图。

它——这是关于工作的执行。

具体来说，针对知识工作，我们关注的是谁做什么、按什么顺序、以及它们之间流动什么。

好了，这些就是概念。

尽量不要把它们搞混。

我不碰计算机科学工程那边，我主要讲图和工作，其他先放一边。

我们来聊聊在AI和代理出现之前我们有什么。

实际上每个组织都有过的主要图是组织架构图。

而组织架构图，它最大的问题就是它基本假装工作只朝一个方向流动。

从上到下，对吧？

经理说点什么，CEO说点什么，然后就传到组织其他部分。

我们就假装工作是这样完成的。

根本不是。

我们都知道工作会分叉、会循环、会横着走、会横向交接、会跳过层级，偶尔还会在晚上11点直线上传。

尤其是在董事会会议之前。

所以，工作不是那样完成的。

组织架构图是权力的图示。

它从来都不是，也永远不会是工作如何完成的图示。

但是图呢，就是那种点和箭头跟着实际工作走的方式，才更贴切，也是我们需要给智能体画出来的图，好让它们跟踪工作流程。

刚才说了，有两种类型：一种是相对固定的组织图，另一种是按请求或任务变化的工作图。

好，那我们来聊聊到底什么变了，行吧？

因为怀疑论者会说，工程师们早就把智能体接到图里了，都好几年了。

我们之前就聊过 LangGraph。

那为什么我们现在又对图这么兴奋，不只是社交媒体上的热度？

变化的关键是节点，因为以前节点就只有一个脆弱的 LLM 调用，也就是 AI 调用。

很多时候，效果并不怎么样。

要想用那样的方式协调整个图来做复杂任务，可行性不高，或者说得费很大劲才能让它跑起来。

现在呢，一个节点就是一个完整的智能体，一个你可以交给它任务的工作者。

这个工作者有两种运行模式。

一种是快速的一次性任务，像通常那样；另一种是完整的循环，一直跑到完成为止。

所以任何一种都可以作为一个节点，而循环就是你那些处理重活的节点，这样你就大概明白整体怎么拼起来了。

真正新的一点是，智能体已经足够可靠，能作为这些图里的构建块了，这是一个很大的突破。

所以今年夏天并没有什么全新发明。

只是技术变得更普及了，而且进步到能让我们真的在小白板上画出这个图，并让它高效运转起来。

最后一点很重要，我们只在单个工作者，也就是你构建的那个单智能体搞不定的时候，才去编排或组合这些包含多个智能体和多个节点的图。

你对得到的结果不满意了。

好吧。

那你怎么知道某个任务用单个智能体执行不好，需要多个智能体和图来协调呢？

有时候，两种选项都可行。

回到我做研究的例子，很多时候，一个好的研究智能体，不管带不带循环，就足够了。

你看到了吧，大概跑了八轮之后，对吧？

我们得到了一份很有意思的报告。

所以在某些情况下，这就够好了。

但如果我想做得更全面，或者发现按我的意图和目的来说分开做更好。

我可以把同样的研究做成一个图，也就是说，用多个需要协调的智能体来做。

比如，我可以派多个并行的智能体去研究我感兴趣的不同角度。

一个可以研究 Vendo，一个可以研究从业者怎么说，还有一个可以研究基准测试。

因为这些任务是独立的，我很容易就能让多个智能体并行跑起来。

然后我可以把结果输到合成器里，再转给一个引用验证器，希望它没有被之前所有操作干扰，能成为一个客观的验证器。

要么让人来验证，要么我可能会想在发布之前让另一个 agent 再跑一遍验证。

我还可以加一个 agent——事实上我会这么做——让它按我喜欢的样式设计输出。

那么，什么时候用多个更好呢？

首先，就像我一开始说的，我希望你保持简单。

如果一个 agent 就能工作得很好，那也不错。

我希望你在几种场景下考虑扩展到多个 agent。

第一种场景，我称之为“橡皮图章”。

你的 agent 或循环说“好了，一切检查通过”，但你却不断发现它本应该能抓到的问题。

在很多情况下，自我检查并不是好办法，尤其是处理关键任务的时候。

也有很多研究表明，模型倾向于赞同自己。

如果你用同一个模型来验证它自己的结果——比如 GPT 验证 GPT——它大概率会说结果正确，而用 Claude 验证 GPT 效果就不一样。

所以很多情况下，我们希望扩展开来，形成一个由多个 worker 组成的图。

当我们意识到验证不太可靠的时候。

另一种场景是发现上下文溢出，比如一个 agent 身兼太多角色，开始混淆了。

比如你既是客观的研究员，又是非常富有创意的设计师。

于是研究员可能开始产出一些很有创意的结果，因为它过早地试图表现创意。

所以当你发现是这种情况，最好就扩展到多个节点或多个 agent。

还有一种情况是，你不想坐在那里等着工作串行完成，而实际上可以分发给多个 agent 并行去做。

我知道在这个时代我们都很耐心，愿意等好几分钟甚至几小时来拿到结果。

但如果我们能让工作并行，通常就应该这么做。

另一个信号是，终点线在运行过程中不断变化。

也就是说，你一边工作一边不停地重写目标卡，因为实际上这是一张卡里藏着两份工作。

所以如果你意识到这个目标本质上是一个 if-else 或 if-then 结构，底下隐藏着两个不同的目标和两项不同的工作，那你就该把它们拆分开。

最后一种情况是，尽管你尽了最大努力，无论怎么尝试，质量太早就停滞不前了——也许是因为缺少上下文，或者架构本身就不对。

那你可能就需要引入第二个视角，或者至少再增加一个 agent。

明白了吗？

如果以上情况都不符合，那就留在循环里，或者就用一个 agent，别把事情搞得太复杂。

好的。

到目前为止，听起来前景很光明。

我们会构建多个 agent，它们会在一个 graph 里工作，我们会描述脑子里想到的一切，然后它就会工作。

但关键问题是：你怎么实际构建一个 graph？

你需要做什么？

我觉得有时候跟从业者聊起来，这事儿听起来特别复杂，但实际上复杂程度是渐进的，而且每种复杂度都能用。

只不过不同的能力和需求决定了怎么做而已。

所以我认为，你要做的第一件事，也是很好的起点，就是把它画出来——拿张纸，或者白板，你就把流程草图勾出来。

这一步非常关键，因为你得清楚怎么把事情搞定。

在白板上画出来，能让你直面所有那些定义不清晰的地方。

在很多组织里，很多事情就是定义不清楚的。

直到你能对某个工作流程达成共识，你才能把它自动化。

所以这是你能做的第一件事。

而且，如果你能画出来，那意味着你甚至可以直接拍张照片，给任何一个 agentic tool 看，它就能帮你构建起来。

所以我认为这不仅仅是一个入门方法，而是一种具体的操作方式。

另一件你可能已经在做却没意识到的事——或者你注意过——就是 agentic tool 在你给它一个任务时，尤其是复杂任务，它会即时生成一些小的工作 graph，因为现代的那些工具框架就是这样工作的。

你可能见过某些工具，比如 cursor 或别的，它会说“我要派生出几个 subagent 来干不同的事情”，或者“让我分而治之”之类的话。

所以在后台，工具会根据你的提示为你创建一个工作 graph。

这不在你的控制之下，但它是做事的另一种方式。

另外，Cowork 和 ChatGPT 也是这样做的。

另一种方式是你直接提示这个 graph。

基本上就是告诉工具：“并行研究这五个竞争对手，每个用单独的 subagent，然后让一个用全新上下文的评审员根据这个评分标准检查合并结果。”

这只是简单的一句话，但后台描述的是一个 graph：派出 5 个 subagent 做不同的研究，再加一个来验证。

你刚刚用语言构建了一个 7 节点的 graph。

恭喜你。

另一件你能做的事情是创建持久化的 worker。

你可以创建 subagent 文件，或者我称之为“文件夹 agent”的东西。

我不会深入讲所有细节，因为内容太多了，但会展示一些例子。

你基本可以创建这些 agent 作为持久的 worker，按需召唤到对话中。

在此基础上，如果你想做成可复用的东西，可以创建一个 skill；或者你也可以临时让工具指向你创建的特定 subagent。

我们也可以选择使用像 n8n 之类的自动化工具来创建画布，让你能可视化地构建 graph。

最后，我们总能用代码来实现。

所以有很多工具和包能让你通过代码来创建这些图谱和编排流程。

这就是五个层级。

再说一次，这不是比赛谁能爬到最高层。

这只是把所有你能用多个智能体替你干活的方式来构建这些工作图谱的方式列了出来。

对于我们大多数需要做的知识工作，你可能就待在这些层级里，而且完全够用。

我们来给你看一些具体例子。

首先，我们回到之前做过的执行流程。

结果出来之后我做了一件事，我对Claude说了这么一句：把剧本交给引用验证子智能体。

我待会儿给你展示。

确保它是全新的上下文。

它完全不知道文档是怎么生成的，而文档会包含所有内容，它检查那里的一切，随机抽取10个数据点，然后把每个智能体跟它的真实URL做验证。

然后它统计总数和来源构成，我还给它一个类似柱状图的东西。

这就是我拿循环结果，让Claude再添加一个节点。

就是手动通过提示词加了一个引用验证的节点。

你可以看到Claude非常配合。

它冷启动地传递出去。

验证器拿到文件路径和柱状图，没有文档是怎么构建的信息，以免污染。

验证器的结论是：可以发布，但有一个必改项，已经应用了。

它还给了我样本验证结果和总数。

所以你可以看到我的研究进入了另一个节点。

然后我又加了一个节点。

我想把它做得视觉上更吸引人。

于是我让它交给报告可视化子智能体。

从输出构建一个漂亮的自包含HTML页面，诸如此类。

它的视觉语言和归属规则都写在角色文件里，保存为输出文件等等。

然后就完成了。

所以这是一种方法，让你在已有的循环或已有的流程里添加额外的工人。

也许是最简单的方法之一。

我也可以在白板上画一幅图，叫研究扫描。

这就是我设想的研究流程的样子。

从现在开始。

就像我说的，我可以直接把这张图给Claude，Claude就能很好地实现它。

但关键在于，我能画出这张图，就意味着我可以用多个智能体来自动化这个流程。

所以这是我一个非常重要的能力。

另一个我能做的事情是，我可以构建持久化的工作助手。

好的，现在我展示的是我为研究专门创建的子智能体。

我有一个基准收集器。

这是一个专门收集关于基准测试相关研究的智能体。

我有一个引用验证器。

引用验证器这个智能体的全部任务就是验证引文。

就是你在Claude里看到的那个。

还有报告可视化器，它能精确描述我希望如何呈现数据等等。

如你所见，我可以临时把它们召唤到对话中，也可以创建一个技能。

这个技能本质上描述了工作流图。

看一下，万一我想以同样的方式反复运行研究。

这是一个研究技能，附带工作流图文件。

我告诉它如何执行流程，给它划分阶段，并指定在每个阶段要召唤哪些工作助手进入对话。

顺便说一下，你可能已经注意到了，作为智能体的一部分，我还可以配置使用哪个模型。

所以任何在座懂得如何使用Claude、知道如何构建像你刚才看到的那些子智能体卡片、以及知道如何创建技能的人，都可以非常有效地编排多个智能体，并且有很多控制手段。

而且它支持任何智能体工具。

这基本上就是第三级。

还有两件事我想给你看。

具体来说，我选择了N8n，不过只是为了视觉上更清晰——如果你想创建一个工作流图，这是另一种方式。

好的。

在这个N8n的工作流中，我按计划触发，为不同的事情设置了收集智能体。

我有一个合成器智能体。

注意，理想情况下我可能想让合成器用一个更强的模型，而收集器则不一定需要很强。

我有一个引用验证器，它绝对需要尽可能使用不同的模型。

我可以把所有这些东西放在一个循环里，直到达到某个质量标准。

在这个案例中，我加入了一个人工验证环节。

最后，我有一个报告可视化工具和一个电子邮件。

所以，如果你熟悉那种更像画布的工具，或者你习惯那种工作方式，它的好处在于非常直观，你可以很清楚地看到工作在图上的流转，并且可以验证它。

所以对我们大多数人来说有些大材小用，但也是一个选择。

顺便说一下，如果你想看输出结果，那就是我们从资源那里得到的报告。

我会把这个分享给你们。

它既提供了执行摘要，也提供了大量关于如何更好使用 token 的数据点。

对，抱歉，还有最后一点，LangGraph。

LangGraph 基本上就是代码。

如果你想在 LangGraph 中创建工作流图，那本质上就是代码。

就是这个样子。

不过 LangGraph 还有一个好处，就是它自带可视化功能，由 LangGraph 生成。

所以即使对于你们这些使用代码的人来说，LangGraph 也有内置的方法来可视化生成的代码。

所以即使是最高级的方式，实际上也没那么可怕。

对。

在进入提问环节之前，还有几个要点。

区分有效 agent 编排或图与非常昂贵的编排或图的6个习惯。

其中一些在前面已经间接提到了。

你要让节点、模型与节点相匹配。

这里部分决策在于为哪个 worker 或哪种类型的工作使用哪个模型。

当然，对于更机械的步骤和是/否的判断，你想要便宜且快速的模型；而在需要判断的地方，则需要更强的模型。

理想情况下，每个节点只应该获取相关的上下文。

不同节点之间传递的是契约。

所以你需要非常谨慎且有意识地决定节点之间传递什么。

可能是一份草稿和一份评分标准，或者以某种格式呈现的发现。

我们——你永远不需要传递整个对话。

在大多数情况下，这不是正确的工作流转方式。

接下来我想说的是，要在验证有回报的地方投入精力，意思是如果你要分发给多个 agent，那是有 token 成本的。

如果你需要在节点之间进行总结，那会有所帮助。

如果你能限制每个节点的轮次，那也有帮助。

但一定要非常慎重，因为像那样的漂亮图很容易变成巨大的 token 消耗者。

比如说，如果你用某些工具自带的深度研究功能，它们可以轻松消耗数百万个token，眼睛都不眨一下。

所以你要小心这一点。

我希望你尽早验证，所以加上这些验证节点，并设定清晰的边界，不管是因为你跑了循环还是只是作为你走的图的一部分。因为，特别是你的图越复杂，错误的累积就越昂贵。

而且至少到目前为止，人类仍然是需要的，而且在大多数情况下比机器更强。

所以我们在合适的位置设置了人工介入。

也许是在最后，也许是在早期来批准计划，但应该有意地将人类加入到图中。

最后一点，我想再次提醒你。

很多人设计工作图的时候，他们想的完全是当前人类工作的方式。

而人类今天的工作方式往往受到人类局限性的高度约束——注意力持续时间、时间、带宽、同时精通多件事的能力。

这些局限性很多对你的智能体和工具来说并不是相关的限制。

所以我不希望你只是把今天人类之间工作交接的方式原封不动地搬到机器上。

这不是正确的做法。

你需要通过测试或了解工具的局限性，来理解如何更好地配置工作，因为在很多情况下，这些工具比人类更不容易混淆或疲劳。

在很多情况下，这需要一点激进思维，思考什么是底线，什么是需要完成的任务，而不是当前人类做工作的流程，这样才能设计出最优质的图。

我稍后会跟你分享，但这些是人们在使用的不同工具的具体命令。

也就是循环和使用子智能体的具体命令。

因为事情变化太快了，总是要进行网络搜索或咨询手头的工具，了解最佳方式，因为有时他们会废弃命令——你可能某天早上醒来发现命令不见了，而且不同的模式也有区别。

比如说，在Claude code中，子任务只能在命令行界面中使用，不能在桌面版中使用。

所以不要以为存在某个命令，就认为它在你具体使用的界面上也能运行。

我认为，如果你比较循环和图，那么循环更宽容，因为图有点像对你工作流程的一种坦白。

谁真正拥有什么，质量真正在哪里决定。

顺便说一句，这就是为什么你在这方面可能比大多数工程师做得更好，因为你整个职业生涯都在学习你专注的具体工作是如何在组织中流动的。

而这正是成为技术技能的知识——知道如何将自己的领域专长注入到设计这些正确系统的过程中。

如果我要把这一小时的内容总结到一张幻灯片上，而且它只在2026年8月这个时间点有效，因为这个东西可能到冬天还会继续发展，要么出现新的流行词，要么我们到时有了新技能。

但知识工作中最优秀的实践者，他们掌握了全部这四项。

他们理解智能体，也理解在框架中实现的基础循环。

他们知道如何定义具体的智能体工作流程。

他们知道如何配置循环，让工具自主良好运行，也知道如何配置智能体团队，使其作为一个任务或整体有效地实施整个组织的工作。

这就是截至2026年8月你需要掌握的技能组合。

在进入问答环节之前，我先快速打个广告。

NLW，你想补充几句吗？

我是说，还有什么好说的呢？

我觉得这个时刻之所以重要，部分原因在于我们已经从AI技能只是有用的新工具，变成了它们实际上是基本的工作原语转变。

我的意思是，很久以前我们刚创办Superintelligent时，平台的第一版就是教人怎么用Midjourney、怎么写提示词。

这些东西当时很有价值。

它们算是锦上添花的技能。

能让你事半功倍。

但咱们做事的方式还没彻底改变。

现在呢，我们越来越发现，以前做的一大部分工作——

反而，咱们的工作变成了管理智能体去完成它们。

这是一个过渡的过程。

不会一蹴而就。

也不是说所有任务都这样，但咱们现在某种程度上都在探索管理智能体到底意味着什么。

所以我觉得，我看这些事情的视角是：咱们都像是一点一点在给自己修一个智能体管理的MBA。

它会不断地迭代和演变。

但我认为啊，咱们之所以会抓住工作流、图工程这些概念不放，很大程度上是因为它们开始更像是核心原语，而不只是昙花一现的技能。

所以呢，就像你不会指望自己在一节课、一个实验或者几天里就精通高级管理技巧一样，这事儿也是同理。

需要亲手去做，不断试错。

而且这方面没有专家，我以前也说过，只有经验更多的人。

所以光是来到这儿，我觉得你就已经领先了。