作者：Cassidy Williams
排版：Alan Wang
从 Loop Engineering 到 Harness、Squad，再到 Open Weights，GitHub Podcast 带你拆解开发者社区里频繁出现的 AI 热词，帮助你快速理解 AI 时代的新概念与新实践。
如今，随着 AI 工具不断引入新的概念，软件开发领域涌现出越来越多的新词汇，看到这些术语铺天盖地出现，可能确实让人有些应接不暇。
其中一些新词汇描述的是人们最近开始探索的实用模式；另一些只是给已经存在的事物换了一个更时髦的名字；还有一些概念，甚至直到现在都还在不断被定义和完善。
在最新一期的 GitHub Podcast 中，我和 Marlene Mhangami、GPS 一起聊了聊当下开发者正在学习的一些 AI 术语：Loop Engineering、Ralph Loops、Squads、Harness Engineering、Hill Climbing、Forward Deployed Engineers、Closed Models、Open Weights 以及 Open Source Models。
下面这份指南将帮助你了解这些术语分别是什么意思、为什么重要，以及应该如何理解它们。
Loop Engineering：超越一次性 Prompt
Loop Engineering 指的是围绕 Agent 设计可重复运行的系统，而不是每次只针对一个任务手动向 Agent 发出 Prompt。
举一个简单的例子：与其每天早上手动让 Agent 检查新 Issue、总结问题并提出修复方案，不如创建一个按计划自动运行的循环。这个循环可以获取 Issue，将它们交给 Agent，验证输出，并将任何卡住的问题升级处理。说白了，它就是一个 AI 原生的定时任务。
Ralph Loops：Loop Engineering 的"暴力版"亲戚
Ralph Loop 是"循环"这一概念的一种实现方式：你给 Agent 一个详细的任务，通常来自产品需求文档或技术规格，然后让它持续工作，直到任务完成。
这种方式确实很有用，尤其适合将大型任务拆分成不断重复的"规划---执行---检查"循环。但另一方面，它也可能成本高昂且效率低下，因为每次迭代都会消耗更多 Token、上下文和计算资源。
Loop Engineering 的目标，就是让这种模式更加结构化，这样你就不必一直让 Agent "再试一次"。一个设计良好的 Loop 会加入 Skills、可观测性、验证、路由以及检查点等基础能力。
Squads、Fleets 与多 Agent 工作流
如果说 Loop 定义了工作流，那么 "Squads" 和 "Fleets" 描述的就是多个 Agent 如何参与到这个工作流中。
Squad 是一组承担不同角色的 Agent。它们通常对应现实世界中的一个团队。其中一个 Agent 负责规划，另一个负责审核方案，还有一个负责实现，另一个负责测试，还有一个负责代码审查。
Fleet 则指的是多个 Agent 同时并行处理任务。你可以让一个 Squad 中的 Agent 以 Fleet 的形式并行工作，也可以让它们按照顺序执行。
这种方式可以让不同的 Agent 负责流程中的不同部分，同时还可以通过特定的 Skills 对每个 Agent 进行微调和专业化，从而提升效率。
其核心理念就是并行化与专业化。与其让一个 Agent 试图完成所有事情，不如让不同的 Agent 分别负责开发流程中的不同环节。
Harnesses：围绕模型构建的系统
除了模型本身生成的内容之外，Harness 指的是模型周围所有让它能够真正融入工作流并发挥作用的东西。
这可能包括工具、权限、记忆、上下文、编排等等，它们共同决定并引导模型如何行动。如果想更容易理解这个概念，可以想想马匹使用的马具。模型就像可能肆意奔跑的马，而 Harness 则帮助我们控制和引导马匹，让它能够安全地完成任务。明白了吗？
无论如何，GitHub Copilot 就是一个很好的软件 Harness 示例。它将模型与代码库、编辑器、Pull Request、终端等连接起来。
当你听到有人谈论 "Harness Engineering" 时，指的就是设计和改进模型周围这一整套系统的工作。
Hill Climbing：通过反馈持续改进 Agent
Hill Climbing 这个术语，用来描述随着时间推移，通过不断反馈来改进 Agent 和 Harness 的过程。
例如，可以使用 Evals 来衡量 Agent 是否能够生成符合要求的输出，然后不断调整 Harness，直到结果得到改善。
再比如，如果你的 Agent 负责审查 Pull Request，那么 Hill Climbing 就可以是检查它是否真的能够发现有意义的 Bug、给出有价值的建议，然后通过调整工具来进一步改进效果。
Forward Deployed Engineer：一个聚焦 AI 的熟悉角色
Forward-Deployed Engineer 其实早就已经存在，只是 AI 领域的包装让这个职位听起来又酷又新。如今，它通常指的是面向客户的软件工程师、销售工程师或解决方案工程师，只不过往往更加聚焦 AI。
如果你以前没有见过这些职位名称，那么简单来说，这类人员通常会与客户密切合作，将技术解决方案部署到客户环境中，或者根据实际需求进行调整。在 AI 场景下，这意味着帮助团队将 AI 工具、工作流、Agent 等集成到现有系统中。
Closed Models、Open Weights 与 Open Source Models
并非所有模型都是以相同的方式开放的。
Closed Models 通常通过 API 或托管产品提供访问。开发者可以使用模型，但无法获得底层权重、训练数据或训练过程。我们经常听到的那些大型、知名的前沿模型，通常都属于闭源模型。
Open Weight Models 会公开模型权重------可以把它们理解为决定不同输入重要程度的一组"旋钮"。开发者可以下载并运行这些模型，通常可以在本地或自己的基础设施上运行。但需要明确的是，数据集和训练方法不一定会完全公开。
Open Source Models 则更进一步，模型、代码、数据以及训练过程都可以被查看、复用和修改。
模型开放程度越高，你就越能够运行、定制、审计和信任它。
这些术语仍在不断演变
以上只是我们如今经常听到的一部分术语。有些会长期存在，有些最终会被我们遗忘，还有一些会随着行业不断成熟，被更好的表达方式所取代。
不用担心自己跟不上这些 AI 热词。它们终究只是一些词，更重要的是这些词背后的实践！不妨问问自己：工作流能否可靠地重复运行？如何验证任务是否完成？人类应该（或者不应该）在什么时候介入？你对一个模型有多大的依赖程度？又该如何持续改进整个系统？
这是一个全新的工程时代，而工程实践依然重要！