即时响应机制与循环处理机制：开发者指南

对许多开发者来说，人工智能的工作流程大致是这样的：编写一个提示语，获取模型给出的回复，提取其中有用的信息，然后继续下一步工作。这种工作流程涵盖了范围相当广泛的任务，从总结文档内容到起草电子邮件，再到解释代码逻辑。然而，当某项任务需要多个步骤、外部数据的支持，或者决策结果取决于模型刚刚返回的信息时，这种工作流程就会遇到问题。这时，开发者不得不手动重新编写提示语，手工调整输出结果，去做那些本应由系统来完成的工作。在这种情况下，单一的提示语就不再是一种有效的工具了，而设计一个能够多次向模型发送请求的系统，才成为了真正需要完成的任务。有两种术语可以用来描述这两种不同的工作模式： **

“提示语工程”是指你与模型进行一次性交流的过程——包括所使用的措辞、结构以及提供的示例，这些因素都会影响模型给出的回复质量。

** **

“循环工程”则是指设计一个能够与模型反复交互的系统，该系统会自动评估每次交互的结果，并决定下一步该采取什么行动，而无需等待人类的干预。

** 本指南会同时介绍这两种工作模式。你会了解到：在哪些情况下，精心设计的提示语确实就是你所需要的全部工具；在哪些情况下，使用循环工程才是更合适的选择；以及如何开始构建这样的系统，同时又避免使其变得过于复杂。事实上，“提示语工程”并不会在“循环工程”的框架中被完全取代，它反而会成为整个系统运作的基础。 **

目录

**

• 提示语工程与循环工程详解

• 人工智能工作流程的变化

• 选择合适的方法

• 循环工程的真实成本与风险

• 提示语工程与循环工程：三个现实案例

• 如何开始构建你的第一个循环系统

• 结语

**

提示语工程与循环工程详解

** **

“提示语工程”是指你与模型进行一次性交流的过程。所使用的措辞、结构以及提供的示例，都会直接影响模型给出的回复质量。

** **

一个设计精良的提示语，确实能够显著改变模型产生的结果。因此，掌握这种技能仍然非常有用。大多数人所说的“开放循环”，其实就是指这种一次性的交互过程——在每次模型给出回复后，都由人类来决定下一步该做什么。

** **

而“循环工程”则将这种交互关系进一步延伸。你不需要进行一次性交流，而是设计一个能够多次与模型互动的系统，该系统会自动检查每次交互的结果，并据此决定后续的操作步骤。

**

在这个循环中的每一步，都可能涉及不同的提示语、工具调用、API请求，或者这三者的组合。系统会自行决定下一步该做什么，而无需等待用户的干预。这就是闭环在实践中的运作方式。

不过需要再次强调的是，即使构建了循环结构，提示语的设计工作也并不会因此消失。循环内的每一次模型调用仍然依赖于精心设计的提示语。循环本身代表着系统的架构，而提示语则决定了循环中每一步能否顺利执行。大多数团队直到他们的单提示语工作流程不再能够满足实际需求时，才会意识到这一点。

AI工作流程的变化

早期的人工智能应用大多属于事务性操作。开发人员会构建内部提示语库，对各种表达方式进行实验测试，并将经过优化的提示语视为独立的成果。这些工作的价值在于确保表述准确、上下文清晰以及提问方式得当。

诸如持续集成故障分析、问题优先级排序以及文档更新这类任务，都需要模型来阅读相关内容、做出决策、执行相应操作，并检查这些操作是否有效。如果使用单提示语机制，那么在每一个步骤中，这个决策都会重新交由人类来完成，这样一来，在任何包含多个环节的工作流程中，人类就会成为瓶颈。

这就是开放循环与闭环之间的区别：在开放循环中，每一步该做什么都由人类来决定；而在闭环中，这些决策则由系统自动完成。

GitHub于2026年6月11日推出了“Agentic Workflows”，这一功能清楚地展示了当闭环被真正实现时，工作流程会发生怎样的变化。

在“Agentic Workflows”出现之前，开发人员需要先使用人工智能助手来检测持续集成故障，然后手动分析日志、确定问题的优先级，并推送修复代码。而通过GitHub Agentic Workflows，团队只需在普通的Markdown文件中定义自动化任务，编码代理就会在GitHub Actions中自动完成整个流程。

作为早期采用这一技术的公司之一，Carvana直接表示：那些过去需要耗费数小时人工才能完成的任务，现在几分钟内就能解决。Carvana的工程与分析高级副总裁Alex Devkar将这一变化描述为“让智能代理在大规模的实际工程工作中发挥更重要的作用”，包括那些涉及多个代码库的修改任务。

然而，并非所有任务都需要如此复杂的自动化机制。因此，在选择合适的解决方案时，其重要性丝毫不亚于掌握具体的实现方法。

选择正确的方案

只有当任务的输入明确、输出结果对人类来说具有直接的实际意义时，提示语才是一种合适的工具。例如，起草支持请求的回复内容、总结拉取请求的描述信息，或者解释程序堆栈跟踪信息，这些任务的价值都体现在一次性的交互中。如果为这些任务添加循环结构，虽然会增加复杂性，但并不会对最终结果产生任何实质性的影响。

当一项任务包含多个步骤，且每个步骤都依赖于前一步的结果时，或者每次手动执行这项任务所花费的成本高于一次性构建自动化系统所需的成本时，循环结构会发挥出显著的作用。在代码库中对问题进行分类处理、监控开发流程并应对出现的故障，或是按照预定时间表根据实时数据生成报告，这些场景都是循环结构能够迅速带来实际收益的例子。

一个有用的判断标准：如果你发现自己经常需要将某个命令的输出结果复制到另一个命令的输入框中，那么这种操作模式其实就是一个亟需被转化为循环结构的流程。

在以下情况下使用命令行提示：	在以下情况下使用循环结构：
该任务是一次性的或风险较低的	该任务需要定期重复执行，或者需要在较大规模上运行
你只需要快速得到结果或初步草案即可	多个步骤之间存在相互依赖的关系
下一步该做什么由人工来决定	系统应该能够自动判断下一步该执行什么操作
你目前处于探索阶段或正在进行原型设计	你需要确保输出结果的可信赖性及可审核性

大多数团队最初都会使用命令行提示来完成任务，而当同样的任务需要反复执行时，才会逐渐转向使用循环结构。这种发展过程是正常的，没有必要在早期就过度设计复杂的系统。只有当手动执行这些任务所花费的成本高于自动化处理所需的成本时，才应该开始构建循环结构。

循环结构的真实成本与风险

设计得当的循环结构能够自动完成那些需要人类花费数小时才能完成的任务，还能按照预定时间表持续运行，并及时指出那些需要关注的问题。这些功能确实非常实用，但循环结构毕竟也是软件系统，因此如果测试不足，它们也会像其他任何软件系统一样带来风险。

以下是循环结构能够真正发挥价值的地方：

• 它们可以自主完成多步骤的任务，无需人类在每个决策点进行干预。

• 它们能按照预定时间表可靠地运行，从而使重复性工作流程保持一致性且可重复执行。

• 它们能够处理那些原本需要更多人力才能完成的任务。

然而，循环结构也会带来一些风险：

• 调试难度会增加：单个命令行提示只会显示输入和输出结果，而涉及多个步骤和工具调用的循环结构则需要通过详细的日志记录和故障排查才能了解问题所在。

• 错误可能会被累积：如果在第二步中产生了错误的输出结果，这个错误结果就会作为第三步的输入数据，等到循环结构完成执行时，最终得到的结果可能看似合理，但实际上却存在诸多问题。

• 循环结构可能会出现死循环：如果停止条件定义不明确、成功判断标准模糊不清，或者某个API调用出现了故障，都可能导致循环结构无限期地运行下去，从而浪费资源而无法产生任何有用的结果。

从一开始就应建立的防护机制：

• 记录每一步的执行过程，而不仅仅是最终的结果。

• 在编写循环代码之前，就明确界定成功与失败的标准，而不是在之后才去确定这些标准。

• 为每一次外部调用设置速率限制和最大重试次数。

• 对于任何可能影响生产环境或真实用户的使用功能，都必须添加人工审核环节。

应将循环视为能够自主做出决策的定时任务，而不是会自动运行的简单程序。以下是通过三个实际工作流程来说明这一点的。

提示机制与循环机制：三个现实世界中的例子

为了使这些概念更加具体，下面有三个例子，展示了仅使用提示机制和基于循环机制的方法在处理相同任务时会有哪些不同。

例子1：电子邮件摘要生成

每天早上，你都需要打开三位客户的邮箱，手动筛选出看似重要的邮件，将其粘贴到模型中，然后等待摘要结果。虽然摘要生成的速度还算快，但整个过程仍然需要20分钟的时间，而且无论提示机制的设计多么完善，这个时间占比都不会有太大改善。

而如果使用基于循环的机制，系统会按照预设的时间表自动获取新邮件，根据发件人、主题和关键词进行筛选，对每一批邮件应用摘要生成功能，标记出紧急邮件，并在你打开笔记本电脑之前直接将摘要结果发送到Slack中。

模型本身仍然在完成它一直以来都在做的那项工作，但现在所有这些步骤都由循环机制来代替人类完成了。

例子2：代码审查流程

你们团队的一名开发人员在某个下午需要处理三份拉取请求。他首先将第一份变更内容粘贴到Claude系统中，得到反馈意见后，再手动将这些评论复制到GitHub上，然后继续处理下一份请求。 到了第三份请求时，他依然在重复着之前已经做过十几次的操作：复制相同的评论、标记相同类型的问题……这些步骤其实都遵循着固定的模式，因此本不应该每次都需要人工参与。 如果构建一个基于这种模式的循环机制，那么代码审查流程就会在拉取请求被提交的那一刻就开始运行。该机制会自动获取变更内容，从代码库中检索相关信息，执行审查流程，并直接将评论结果添加到拉取请求中，而无需等待人类手动操作。任何涉及认证、支付或系统敏感部分的操作，在循环机制继续执行之前，都会被标记为需要人工审核。 作为最早采用GitHub Agentic Workflows的企业之一，Mark & Spencer在其整个代码库中都建立了这种可复用的工作流程。这些流程涵盖了漏洞修复、依赖关系管理以及安全、质量和交付环节中的常规变更审查等工作。

例子3：内容运营工作

一个内容团队每周需要发布三篇技术文章。作者会先使用模型生成初稿，然后手动进行编辑，再利用另一个模型获取SEO优化建议，并根据这些建议对文章进行修改，最后将其提交给编辑审核。每篇文章的编写过程通常需要一整天的时间，而其中有一半的时间都是用于那些每次都会重复出现的步骤。 如果使用基于循环的机制来处理这个流程，系统会首先从实时数据源中搜集相关资料，生成初稿，然后将其提交给另一个模型进行风格审核。根据反馈结果，模型会对初稿进行修改，接着会检查文章在目标关键词方面的优化效果，最后将最终版本提交给人工审核后再发布。作者仍然需要参与一些关键决策的环节，而其余所有工作都由循环机制来完成。

如果这三个例子中的任何一个与你目前手动执行的工作相似，那么构建你的第一个循环就是下一个合理的步骤。

如何开始构建你的第一个循环

大多数团队会犯的错误是试图一次性自动化太多流程。一个更好的起点是：为每一项任务创建一个循环，并在编写任何代码之前，明确界定完成这项任务所需要的具体条件。

• 找出那些需要重复执行、且包含多个步骤的任务：寻找你或你的团队定期需要手动完成的工作。如果这些任务的执行步骤具有规律性，且输出结果也遵循一定的模式，那么这类任务就很适合使用循环来自动化处理。

• 事先明确成功的标准与失败的条件：什么样的输出才算合格的结果？什么情况会导致循环停止、重新尝试，或者需要由人工介入处理？在开始编写代码之前回答这些问题，可以大大节省后续的调试时间。

• 设计具体的执行流程：详细规划每一个步骤：循环需要获取哪些数据，在每个步骤中应该执行什么操作，进行哪些检查，以及什么条件会触发下一个动作。

• 逐步添加相关工具：先从仅使用模型开始，然后再依次加入API调用、数据库查询或代码执行等功能。每次添加新的功能都会增加出现故障的风险，因此逐步引入这些功能有助于更好地控制调试难度。

• 从一开始就注重安全性：记录循环执行的每一个步骤，为所有外部接口设置速率限制和最大重试次数。对于任何会写入生产环境或影响真实用户的数据处理操作，都必须添加人工审核环节。

• 不断迭代并监控运行结果：先在小型数据集上测试循环的执行效果，在确保其运行正常后再让其在没有人工监督的情况下持续运行。将第一个版本的循环视为草稿，而不是一个成熟的系统。

在每一个步骤中设计的提示语仍然非常重要。如果提示语设计得不好，那么当循环在大规模环境中运行时，就会产生不可靠的结果，而这种问题的调试难度远高于处理单个错误响应。优秀的提示语设计与良好的循环设计其实是相辅相成的。

为了将这些步骤付诸实践，这里有一个使用Python和Mistral API构建的简单示例——这个示例完全遵循上述流程进行开发。完整代码可以在GitHub上找到。

审核提示语的设计

一切都要从设计良好的系统提示语开始。在循环系统中，提示语的设计依然起着至关重要的作用。如果提示语不够完善，那么在大规模应用时，审核结果也会相应地不准确。

SYSTEM_PROMPT = """你是一名经验丰富的代码审核员。你会收到一份git差异对比文件，请仔细检查其中是否存在错误、安全问题、代码表述不清的地方，以及可能被忽略的边界情况。请只对真正重要的问题进行评论，不要纠结于格式细节或无意义的表扬。如果差异文件没有问题，就返回一个空列表作为审核结果。"""

循环结构

这个循环包含四个步骤：加载差异文件，检查是否存在敏感区域，调用模型进行处理，然后发布评论。

def review(diff_text: str) -> None:
    if not diff_text.strip():
        print("差异文件为空，无需审核。")
        return

    sensitive_reasons = find_sensitive_matches(diff_text)
    if sensitive_reasons:
        flag_for_human_review(sensitive_reasons)
        return

    client = Mistral(api_key=os.environ.get("MISTRAL_API_KEY"))
    comments = get_ai_review(client, diff_text)
    post_comments(comments)

如果差异文件涉及到敏感区域，这个循环会立即停止执行，标记该部分需要人工审核，然后结束整个流程。这一检查会在任何API调用之前进行。

实际应用中的防护机制

敏感区域检测功能会扫描文件路径及修改后的代码行，寻找诸如“auth”、“login”、“password”、“token”、“payment”以及“api_key”之类的关键词。一旦发现这些关键词，循环就会立即终止：

SENSITIVE_PATH_KEYWORDS = [
    "auth", "login", "logout", "session", "password", "credential",
    "token", "jwt", "oauth", "payment", "billing", "stripe",
]

SENSITIVE_CONTENT_keywordS = [
    "password", "secret", "api_key", "private_key",
    "authenticate", "authorize", "permission",
]

这意味着，如果差异文件涉及到“auth/login.py”这样的文件，循环会在进行任何API调用之前就终止执行。系统会在控制台显示相应的提示信息，然后由团队成员手动进行审核。

运行循环流程

我们可以用一个包含故意设置的SQL注入漏洞的差异文件来测试这个循环流程：

+def get_user_by_name(name):
+    query = "SELECT * FROM users WHERE name = '" + name + "'"
+    return db.execute(query)

使用这个差异文件运行循环后，会得到如下输出结果：

[CRITICAL] app.py:13 - SQL注入漏洞：查询语句是通过将用户提供的输入值(`name`)与字符串连接起来生成的。这种做法会导致攻击者能够插入恶意SQL代码。建议改用参数化查询方式，具体参考链接：https://cdn.hashnode.com/uploads/covers/629e46c5a6bfa05457952a41/26da1a9c-4180-4ae4-89d3-6574e119a0d9.png

[WARNING] app.py:14 - 函数`get_user_by_name`没有处理用户未找到的情况。它应该返回`None`或抛出特定的异常，以便与`get_user`函数保持一致。

该系统确实检测出了两个实际存在的问题，这些问题都涉及具体的文件路径、行号，并且系统还给出了相应的严重性等级及处理建议。这个循环流程能够自动发现那些需要人工审核的问题，而无需任何人手动复制或粘贴代码来进行检查。

最后的思考

提示设计与循环机制的开发并非相互竞争的两种方法。每一个循环环节都离不开恰当的提示，而一个有效的提示会使另一个机制的价值得到进一步提升。

如果你的任务是一次性的，或者仍在探索中，那么一个设计精良的提示就足以满足需求；但如果同样的任务会反复出现、涉及多个步骤，或者需要系统根据自身的输出来采取行动，那么建立相应的循环机制就显得十分有必要了。

首先从一项具体的任务开始，明确成功的标准，然后再逐步展开后续的工作。