利用人工智能工具进行软件开发，已经不再局限于写下一条提示词并等待答案。开发者越来越多地讨论重复运行循环、多代理，以及围绕模型并对其进行引导的系统。GitHub Blog 试图在一篇指南中对这些概念进行梳理。该指南由 Cassidy Williams 于 2026 年 9 月 2 日发布，依据的是 GitHub Podcast 中的一次讨论，参与者包括 Marlene Mhangami 和 GPS。
其中一些术语描述了新的实践模式，另一些则为原本已经存在的思想赋予了新的名称，而还有一些术语的含义仍在形成之中。因此，指南并未将这些词语视为最终标准，而是把它们作为理解软件开发团队之间当前讨论的一种方式。
从单次提示到循环工程
循环工程指的是围绕代理设计可重复的系统，而不是每次都手动要求代理执行一项孤立任务。文中给出的例子是创建一个定时流程：获取项目中的新问题，将其交给代理进行总结并提出修复方案，然后验证输出，并将停滞的情况升级到另一条流程中。
从这个意义上说，这种循环类似于为人工智能配置的 cron 进程，但它所需的要素不止调度。指南指出，还需要明确的技能、行为监控、输出验证、任务引导，以及可以进行人工介入或审查的暂停点。
Ralph loops 是循环理念的一种更简单、更直接的应用：向代理提供一项任务的详细描述，通常以需求或规格说明为起点，并持续运行，直到代理认为任务已经完成。这种方式有助于将工作拆分为规划、执行和检查的重复周期，但如果每一轮都消耗更多令牌、上下文和计算能力，也可能成本高昂且效率低下。
团队、舰队与运行框架的区别
squads 和 fleets 描述的是如何在多个代理之间分配工作。团队是由承担不同角色的代理组成的群体：一个负责规划，另一个审查计划，第三个执行，第四个测试，第五个审查结果。舰队则指同时并行处理任务的代理。可以在并行舰队中运行完整团队，也可以按顺序组织其中的角色。
这里的实际理念是通过专业化和并行处理工作，而不是让一个代理包办一切。但多个代理的存在并不会自动保证更高质量；文章本身也将其价值与团队分配和控制角色、验证输出的能力联系起来。
运行框架或 harness 指的是围绕模型、使其能够在工作流中使用的一切：工具、权限、记忆、上下文以及任务之间的协调。指南以 GitHub Copilot 为例，说明这类系统如何将模型与代码库、编辑器、拉取请求和终端连接起来。而运行框架工程则是对围绕模型的这一系统进行设计和优化。
通过反馈进行改进
hill climbing 用来描述依靠反馈逐步改进代理和运行框架的过程。团队可以先通过评估测试衡量代理的表现，然后在结果不够准确时，调整工具、上下文或引导机制。
例如，在审查拉取请求时，衡量标准不只是代理能否生成评论，还包括它是否能发现有意义的错误并提出有用的建议。这里的实际启示是，将代理引入工作流并不是终点；之后还会开始一个持续的衡量与调整周期。
角色与模型术语
驻场工程师这一角色早在人工智能浪潮之前就已存在，例如直接与客户合作的软件工程师、销售工程师或解决方案工程师。在人工智能语境下，这一角色帮助团队调整工具、工作流和代理，并将其整合到现有系统中。
闭源模型通过应用程序编程接口或托管产品提供给用户，而不会向用户提供模型权重、训练数据或训练方法。开放权重模型允许下载权重，并在本地或用户自己的基础设施上运行，但这并不一定意味着数据和训练方法也可用。在开源模型中，可用程度更进一步，涵盖模型、代码、数据和训练过程，以便进行检查、重复使用和修改。
为什么这份指南很重要？
真正的变化不仅在于出现了一套新的词汇，更在于讨论已经从“模型能够生成什么”转向“我们如何围绕模型构建可重复、可衡量的系统”。对于考虑在自身流程中运行代理的软件开发团队而言，这一点很重要，因为选择术语并不能替代对权限、验证机制、人工介入点以及重复运行成本的明确界定。
不过，来源也承认这些术语尚未稳定；其中一些可能会固定下来，另一些则可能消失，或被更准确的表达取代。因此，最重要的问题仍然是实践性的：工作流能否可靠地重复？如何审查结果？人在什么时候介入？以及对模型的依赖程度达到什么水平才是可接受的？文章认为，这些问题比跟上每一个流行词更重要。