感谢 HubSpot 赞助本期视频。那是昨天凌晨 1 点左右，我们的代码库中不断涌入大量拉取请求（PR）。这并非因为我们工作极其努力，而是各种智能体循环（agent loops）在自动发现问题并接手工作。我甚至有一个 Go 语言循环已经连续运行了两天，每天都能输出 20 到 40 页极高质量的页面，这些页面在我不加干预的情况下为我的公司带来流量。这正是我今天想讨论的主题：Loop Engineer（循环工程师）。这是上周每个人都在谈论的最热门话题，你不再需要提示编码智能体，而是设计能够自动提示智能体的循环。

在这段视频中，我想解释 Loop Engineer 到底是什么，它的核心组件是什么，以及如何确保循环有效工作的技巧，以及我的团队如何设计循环以实现复利效应。在深入之前，我想快速提及一些有用的信息，特别是如果你从未构建过任何智能体，因为我今天谈论的“循环工程”、“共享内存”听起来可能有点高级。但归根结底，基本模式其实相当简单。每个智能体最终都回归到三件事：编程语言智能体循环、记忆层和工具访问。

HubSpot 有免费的视频课程，以非常实用的方式引导你掌握基础。它展示了如何使用不同类型的工具从头构建智能体，包括读取电子邮件并检查日历的个人助理智能体，以及连接到真实业务流程的支持风格智能体。通过这些例子，你能更好地理解智能体记忆是如何工作的，以及如何有效地管理上下文。因此，如果你从未构建过智能体，或者仍在尝试理解普通自动化与真正 AI 智能体之间的区别，我认为这是一个很好的起点。

因为一旦你理解了基本模式，我在本视频中谈论的内容就会变得容易理解得多。我已在下方描述中放入了链接，你可以免费查看。再次感谢 HubSpot 赞助本期视频。现在，让我们回到 Loop Engineer 到底是什么。在过去一年中，出现了许多新术语，可能会让人感到困惑，但实际上，每个术语都是针对不同级别的大语言模型使用而引入的技术集群。

如果我们回到 2023 年，当 GPT-3.5 或 4 API 刚刚出现时，我们让大语言模型执行的大部分任务都非常简单。那主要是任务完成。你给它 API 输入，并使用大语言模型基本上输出文本，所以它可以用于提取结构化数据或编写代码块。模型的本质是不确定的，这就是“提示工程”（prompt engineering）这个术语出现的地方。它基本上是关于如何在大语言模型调用中构建正确的上下文以引导行为的技巧。

比如，你可以告诉它总是以全大写字母返回文本，那么它就会以某种特定风格撰写文章。但很快，随着我们进入 2024 年中，模型不仅变得更聪明，而且上下文窗口也变得更大了。当时，上下文窗口大约在 4,000 左右。当 128k token 出现时，这是一个令人惊叹的进步。随后，谷歌将门槛提高到每个模型默认拥有 100 万 token 的上下文窗口。

更大的上下文窗口意味着我们使用大语言模型的方式发生了变化。我们开始构建那些模型配备不同工具（如 MCP）的系统，以便它决定做什么。我们将工具调用和工具响应都包含在对话中，这样大语言模型可以继续这个循环，直到它认为任务完成。真正改变的是，随着模型能够执行越来越多的任务，上下文窗口实际上被消耗得越来越多。

众所周知，即使它有 100 万的上下文窗口，有效窗口大约在 128k 到 200k 之间。你是否能在该上下文窗口内直接提供最有相关的信息，直接影响智能体的性能。这就是人们开始围绕此引入大量技术的原因，例如在系统提示中保留什么以更好地触发提示缓存，以及如何通过压缩策略处理长对话。还引入了“技能”（skill）等新概念，作为在不使上下文窗口膨胀的情况下扩展智能体能力的方法。

但在 2025 年底，随着我们推进，真正发生变化的一件事是，我们让模型执行更长、更大的任务。从今年年初开始，人们一次性使用云端代码完成 30 分钟甚至 2 小时的工作量变得很常见。这也是我们开始大量实验循环和工作流的时候。起初，人们尝试粗糙的循环，即简单的 while 循环，使用相同的提示无限运行云端代码。

后来，云端代码引入了“Go”的概念，以及循环和推理工作流。而且，正如我指出的，我们正在让模型执行这种跨会话的工作。这意味着我们不再只是让一个智能体完成整个任务。相反，我们可以拥有多个不同的智能体会话，每个会话处理一个任务，并在循环中运行，直到一切完成。这意味着我们需要一种方法来跟踪这些不同会话之间的状态或类似文件系统的结构。

这样，每个智能体会话实际上都能理解事情进行到了哪里，并持续进行工作。这些事情实际上发生在智能体运行时之外，但也包括智能体运行的环境。这就是“智能体框架”（agent harness）概念引入的地方。它最初由 LangChain 提出。当时的定义相当直接。基本上，框架意味着任何非模型的东西。

这就是为什么框架概念如此令人困惑，因为它包含了太多不同的东西，从提示工程、你如何管理上下文，到那些编排逻辑和钩子。但在我脑海中，一种有用的方式是将优化分为两部分。一部分是智能体循环本身，如果你构建自己的 Pi 智能体，可以是云端代码或 Codex。你可以进行大量优化。

但所有这些技术都是关于如何确保当你给智能体一个任务时，它能很好地完成任务。另一方面，还有一堆技术不仅仅是关于如何让智能体很好地完成任务，而是关于如何让整个智能体系统……

系统决定哪些工作应该被处理。而这一外层部分正是我们目前讨论的“循环工程师”（Loop Engineer）。它更像是一种你正在搭建的环境，既用于触发智能体的运行时，又用于跟踪状态和日志，从而使其能够持续改进。之所以说这至关重要，是因为它实际上让你从直接提示智能体本身中解脱出来。智能体可以变得更加自主，并由我们不同的事物触发。

它可以由 Cron 作业触发，也可以由另一个智能体触发，甚至是由服务器上发生的事件触发的 Webhook 触发。所有这些都可以触发智能体，让它交付有意义的工作成果，而无需你的参与。这是循环工程师的核心机制：你将设置正确的触发器，以便智能体能够在随机时间和场景中醒来。

每次通常智能体会进行某种形式的调查和行动，这将产生一份待办事项列表或想法，主智能体可以据此进行优先级排序，并在必要时将任务分配给其他智能体。因此，下次它可以进行回顾和学习。让我们举一个例子。假设你正试图为处理客户支持的智能体创建一个循环。

你实际上可以构建一个简单的循环，每 30 分钟智能体就会由 Cron 唤醒，以审查所有支持工单，回复那些尚未自动处理的问题，并记录摩擦点和想法。这样你就可以将其作为产品改进的参考。这个循环本身绝对是有价值的。更强大的是，如果它不仅仅是记录这些想法和摩擦点，而是触发一个编码智能体直接实施其中一些想法，那会怎样？

这样你就可以监控性能，甚至告诉客户这些修复措施已经到位，并监控是否还有其他人遇到此类问题。这两个循环都提供了巨大的价值。第二个循环要强大得多。根据我个人的经验，如果你能定义一个好的日志系统，你实际上可以定义多个相互叠加的不同循环。

这些就是我所在公司实际发生的循环。我们有一个支持循环，每 30 分钟触发一次，让智能体处理所有支持工单，并将摩擦点和想法记录到一个我们称为“信号”（Signals）的文件夹中。“信号”就像一个文件夹，它会捕捉产品想法、发现的摩擦点或我们可能错过的机会。

例如，在一轮中，它可能发现几个人都询问如何导出文件。然后它会创建一个关于“将导出文件隐藏为 MD 文件”的信号。在这个 MD 文件中，它会记录哪些用户遇到了该问题，并且每次看到此问题时，它都会记录并添加到同一个文件系统中。

同样，我们还有一个正在运行的 SEO 循环。每天早上 9:00，它会拉取所有数据并研究主题，然后发布相关的 SEO 页面。但在数据分析过程中，它可能会发现有趣的见解，比如某页面实际上获得了大量点击，但该漏斗的转化率却不足。然后它可以为该特定路由添加一个“转化差距”信号。

它真正做的是确保每个智能体循环都从这些共享文件夹系统中读取和写入数据。因此，我们将循环设置在之前，它只是观看事后会话和分析，以优先排序并构思一些增长实验。但由于我们有了共享文件系统，它不仅会分析数据，还会查看其他不同循环或部门已识别的所有其他信号。

这样它就可以优先处理被报告了几次的错误，或者抓住营销或 SEO 团队正在优化的机会。同样，如果广告循环发现某个关键词实际上有很高的点击率，但我们周围没有有机内容，这些信号信息也可以反馈给 SEO 循环，使其意识到这种情况并优先优化该特定关键词的有机内容。

所有这些不同的循环每小时或每天发生，共享同一个大脑。这就是复利效应真正开始发挥作用的时刻。人们也在推文中写道，日志系统本身就可以是智能体，这听起来与我在这里看到的非常相似。但你如何为你的业务开始着手这些疯狂的叠加循环呢？

因此，所需的核心组件或原料是：第一，你需要设置触发器。正如我所提到的，它可以是多种不同类型的触发器。第二，也是最重要的一点，是文件结构的设计。我会分享一些最佳实践带你了解，但你确实需要给智能体不同的工具和连接器，以便它们能进行有意义的工作。

第四点实际上是最重要的一点，也是很多人忽略的一点。你要确保你的代码库或环境设置得当，允许并行和自主工作发生，使许多不同的智能体可以同时工作，并且各自验证自己的工作。我将快速带你了解每一项的设置。

首先，你如何设置代码库框架，以便智能体可以编写环境来自主工作？这里的核心要点是，你要确保你的代码库实际上是“可读的”（legible），这意味着智能体可以轻松理解在哪里更改什么。它还应该是“可执行的”，以便智能体可以轻松地在本地启动开发服务器，以及使用正确的工具来验证其工作。

首先，可读的代码库实际上并不复杂。OpenAI 保持其 agents.md 文件被索引，大致指向它们拥有的各种其他文档系统，智能体可以逐步发现信息。我相信你们中的许多人都已经在做这两件事了。但还有一部分我认为非常有用，那就是你可以设置自定义链接，因为你不能真正依赖智能体为各种不同任务找到相关信息。

但你实际上可以将这些规则注入到程序化链接检查中。因此，每当智能体没有正确做事时，警告就会自动浮现。例如，在我们的案例中，我们有一个相当复杂的单体仓库（monorepo），我们不希望智能体使用某些仓库。因此，每当智能体从那些遗留文件夹导入文件时，它就会浮现出这类错误。

可能有一系列自定义链接可以嵌入到你的代码库中。但这里的核心思想是，你要为你的智能体进行上下文工程，这样它就不总是依赖自己去寻找完成任务的相关信息。第二点是要确保你的代码库是

可执行文件，这意味着你的智能体应该开始与刚刚启动的开发服务器协同工作。理想情况下，这不应消耗任何令牌或认知负荷，以便它能专注于工作。在我们的代码库中，我们有一个 dev.local 脚本，编写该脚本是为了让智能体只需运行脚本即可启动整个开发服务器。同时，你还希望确保代码库实际上是工作树友好的，这样当有五个不同的并行智能体时，它们都在各自的工作树上工作。你仍然可以启动开发服务器并进行测试，而不会相互冲突。

理想情况下，你还可以设置一些有用的脚本，允许智能体跳转到特定状态，如所有状态或所有状态，以测试特定场景。所有这些操作都是为智能体提供捷径，使其更容易验证工作。最后一点是可验证性。你基本上希望给智能体正确的工具来实际测试并记录结果。我发现最好的方法是 Playwright CLI。它不仅允许智能体有效地使用浏览器，还可以录制视频片段，这些片段可以上传并附加到 GitHub PR 中。因此，你很容易审查事情是否正常运行。

此外，还有一些针对关键流程的端到端测试，这些流程是我们真正关心并希望确保永远不会出错的，比如升级流程、注册流程，或者在 Supermetrics 案例中有效创建设计。我们还提供了一个 PR 技能，定义了智能体在提交 PR 之前必须执行的一系列步骤。这里重要的一点是，不要让智能体自我验证其工作，因为通常效果不佳。这就是为什么在我们的 PR 技能中，我们总是告诉智能体生成一个带有详细规范的只读验证器智能体。

如果你感兴趣，我创建了一个名为“设置代码库测试环境”的技能，封装了我为自己代码库所做的关键设置。因此，你可以将其提供给你的 Cloud Code 或 Codex。它们将设置那些有用的脚本和文档作为技能。这样，你的代码库将更加对智能体友好。我在下方的描述中发布了一个链接，你可以免费试用。如果你想更深入地了解，我在 AI Builder 双人工作坊中逐步 walkthrough 了整个从零开始的设置过程。因此，你也可以点击并跟随。

你应该做的第一件事是确保你的代码库处于智能体可以自我验证工作的状态。即使你不编写循环，这也将有所帮助。我将快速讲述的第二部分是我发现的一些关于文件和日志系统的最佳实践。我认为有三个主要类型的文件具有良好的抽象级别。第一种是工件（artifacts）。这些是每个智能体工作的输出或发现。这就像共享的知识层。

可以有许多不同类型的工件，如文档、信号、任务，或与循环相关的许多其他类型的工件。例如，如果我运行广告，它甚至可能将活动作为工件，我们可以用来记录和跟踪活动表现。在我的特定设置中，我们有 SEO 循环、iS 循环、在定价本身上运行的产品增长循环以及红循环。因此，对于每个工件，我都有自己独立的工件文件夹，在工件文件夹中定义了一个自述文件，清楚地解释什么包含在内，什么不包含在内，添加新项目的流程以及该工件的模式。

然后，对于每个起草的红命令，它只有这个元数据前置内容以及关于内容本身的主干，以及记录我们对此工件所做任何更改的时间线。相同的逻辑可以应用于信号，在我们的案例中，这就像产品反馈、想法，任何循环观察到的内容。它们可以创建一个信号并链接到不同的来源，详细说明原始客户反馈，甚至支持支持套件工件。这些工件的目的是它们成为共享库或共享文件，任何循环都可以直接读取和写入。

我们甚至可以构建一些小型迷你应用，比如我构建的这个，用于跟踪所有不同的工件，这样我可以非常轻松地查看，比如说，每个电话中的产品信号。每个信号都可以链接到创建的另一个工件。这也极大地改善了人在循环中的体验。我可以轻松跟踪哪些事情实际上需要我的关注。但核心在于，你可以定义那些在循环之间共享的不同工件类型和文件夹。

然后，对于每个循环本身，我通常会定义一个契约，包括循环的目标、它应该遵循的工作流程以及积压任务列表。这样，下一个循环可以挑选最重要的任务，或者更新和重新优先排序任务，以及一个时间线列表，让你记住之前做了什么。在我的案例中，由于我只有几个不同的循环，我有多个不同的循环文件夹。在每个循环中，我只有一个简单的自述文件，服务于这个契约的目的。它会谈论目标和流程。

然后它列出时间线，记录特定领域发生的情况。因此，每次循环触发时，它都会读取这个契约，理解目标、流程以及之前发生的事情。基于这些信息，采取大规模的反向行动。这个契约非常有用。第三点是日志。你可能会困惑，既然已经有循环契约的时间线和工件，为什么我们还需要日志？

我们需要日志的原因是，我发现我每天总是混合这些类型的任务，既审查循环的输出，又与智能体执行一些真正困难或创造性的工作，处于那种副驾驶状态。我希望有一种简单的方法，让智能体首先理解跨不同领域正在发生的事情，并捕获那些临时信息。这就是我们拥有这种全局工作日志 MD 文件的地方。每个智能体在完成大量工作后，都会写入此文件。

此外，在开始工作之前，它们也会读取最后五或十条条目。这些基本上就是核心成分。让我们一起设置一个。假设这是容易开始的，支持循环。我们希望智能体每 30 分钟拉取我们所有的最近支持票证，起草回复或直接回复给客户，其中包含相关信息。同时记录它们识别的所有摩擦点和想法。首先，我们需要创建一些技能。这里我已经预先创建了一些我知道支持人员需要访问的技能。一个是 Intercom 技能，用于获取所有票证，另一个是 Stripe，你可以检查支付订阅数据。

有了 Supabase 的访问权限，你就可以调试支付信息，并使用技能来实际获取后端日志。他们还编写了一些脚本，以便让代理更容易地提取信息。此外还有用于分类支持工单的技能。这部分内容你需要根据自己的业务情况进行定制。在我的具体案例中，我想练习处理所有问题。我定义了一个工作流，它会获取过去 X 小时内有更新的所有工单，然后调查用户提到的问题。

我还希望创建一个工单工件，以记录我处理过的所有工单，甚至创建工程师工单，记录反馈和想法。最终，它应该记录它所做的操作。这些就是技能。同时，你通常还需要创建一个云端日志 MD 文件，以便代理对我们的业务有充分的理解。你可以直接提示 Cloud Code 或 Code X 来研究你的业务，并将信息保存到云端日志 MD 文件中。

然后它可能会创建像这样的云端日志 MD 文件，其中包含所有的业务上下文。通常我还会包含一些针对工程师工作的代理响应规则。在这里，我会解释我们拥有的仓库，并要求它每次都直接开展工作。它还包含了一些关于它应该如何管理直接开展工作的合同条款。

这些是实际上适用于任何类型循环的内容，所以我将其包含在云端 MD 文件中。同时，我还有这个 architecture.md 文件，它将在云端 MD 文件中被引用。这就像是我定义的结构基础上的通用指令。包括代理应该定义的不同工件类型结构，以及定义循环领域和日志约定。

现在我只需指向这个文件说：“帮我设置相关的工件。”在我的情况下，这将是信号任务、工单、文档加一个领域。代理应该能够像读取这个架构文件一样，搭建好这些东西。然后它将设置不同的工件类型，比如一个用于文档，一个用于信号，涵盖反馈、想法、观察以及工单等内容。

这也记录到 MD 文件中，起初是空的。然后我创建了这种 domain/support 文件夹。如前所述，对于每个循环，我发现如果我定义一个合同，捕捉循环的目标、整体工作流、边界、未完成任务列表和时间表，真的很有用。

通常的工作流我会手动运行一次作为测试运行。一旦测试运行大致完成，我会要求它创建一个合同，然后设置循环。例如，我想让你处理我的支持，这意味着从过去一小时获取支持工单，进行分析、审查，并起草回复保存工单。还要保存关于产品想法、用户摩擦的信号，对于明确的错误，你可以直接生成代理进行修复，并创建工程师工单任务。

我们每小时运行一次，但让我们先进行一次测试运行。然后代理将开始工作。我可以看到它已经处理了一些工单，并且为每个工单创建了关于结果的工件，还识别出一些可能对产品优先级排序有用的潜在客户反馈或摩擦，并记录了一些已解决的工程师错误。

这是一种你可以与代理进行校准的过程，以了解工作流是否符合你的期望。一旦看起来正确，这就是我设置循环的地方。说：“现在帮我设置一个循环，但首先创建一个 readme 作为合同，包括此文件夹中的目标、工作流和时间表，然后将循环设置到会话中。”

这应该会创建像这样的适当 readme 文件。它还设置了将每小时触发此会话的循环。所以我实际上创建了一个名为 loop engineer setup 的仓库模板，其中捕捉了我团队设置的所有循环的最佳实践学习成果。希望你可以直接复制此文件夹和结构来设置工件并启动新循环。

我在下面的描述中放了链接，你也可以免费使用。但如果你感兴趣，我们有数小时的逐步演示，展示我如何从零开始在实际中设置这些循环。另外还有 10 多个小时深入探讨在生产环境中构建代理和 AI 编码。所以如果你想为你的业务设置第一个循环，一定要加入。

我希望你喜欢这个视频。谢谢，我们下次见。