解码新AI黑话：Loops、Harnesses、Squads、Hill Climbing……等等！
最近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 构建可重复系统的实践，而不是每次手动输入 prompt 来完成单个任务。
一个简单的例子：与其每天早上让 agent 审核新 issue、总结并提议修复方案，不如创建一个按时间表运行的循环。这个循环可以自动拉取 issue，传递给 agent 处理，验证输出结果，并将卡住的问题升级上报。本质上，这是个高级版的 AI 原生 cron 任务。
Ralph loops：loop engineering 的暴力版
Ralph loop 是"循环"概念的一种具体实现方式：给 agent 一个详细的任务（通常来自产品需求文档或规格说明），让它持续工作直到完成任务。
这种方式或许很有用，尤其适合把大任务拆解为反复的"规划-执行-检查"循环。但另一方面，它也可能既昂贵又低效，因为每一次迭代都会消耗更多的 token、更长的上下文以及更多的计算资源。
Loop engineering 的目标是让这种模式更加结构化，避免你不得不反复要求 agent "重试"。一个设计良好的循环会加入 skills、可观测性、验证、路由和检查点等基础组件。
Squads、fleets 与多 agent 工作流
如果说 loop 定义了工作流，那么"squads"和"fleets"描述的就是多个 agent 如何参与该工作流的组织方式。
**Squad：专业化分工的 Agent 团队** 一个 Squad 是由不同角色组成的 Agent 群体，通常映射现实世界中的团队分工。一个 Agent 负责规划，另一个审查方案，再一个实现功能，还有负责测试和最终审核的 Agent。 **Fleet：并行 Agent 集群** Fleet 指的是同时并行处理任务的 Agent 集合。一个 Squad 可以在 Fleet 中以并行或串行方式运作。 这种模式让不同 Agent 各司其职，并通过精细调优和专业化技能提升整体效率。核心理念就是并行与专业化——与其让单个 Agent 包办一切，不如让不同 Agent 分别承担开发流程的不同环节。 --- ## Harnesses：围绕模型的支撑体系 Harness 指的是模型输出之外、围绕它构建的一切，让模型在工作流中真正发挥作用。 这包括引导模型行为的各种要素：工具、权限、记忆、上下文、编排机制等。如果觉得拗口，可以联想马具——Harness 的命名正源于此。马就像可能脱缰的模型，而 harness 帮助安全地引导它的力量完成任务。懂了吧？ 软件 harness 的一个典型例子是 GitHub Copilot，它将模型接入代码库、编辑器、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工具、工作流程、agents等接入现有系统。
闭源模型、开源权重与开源模型
并非所有模型的开放方式都一样。
闭源模型只能通过API或托管产品来访问。开发者可以使用这些模型，但无法接触到底层权重、训练数据或训练流程。那些耳熟能详的前沿大模型，大多都属于闭源。
开源权重模型会公开模型权重（可以理解为决定各个输入重要性的"旋钮"）。开发者能够下载并在本地或自有基础设施中运行这些模型。但需要说明的是，数据集和训练方法未必完全开放。
开源模型则更进一步——模型、代码、数据和训练流程全部公开，可供审查、复用和修改。
模型越开放，你能运行的范围、定制空间、审计能力和信任度就越大。
这些术语在不断演变
这只是当下高频热词的一个缩影。有些会留下来，有些会淡出记忆，还有些会随着行业成熟被更好的表述所取代。
不必担心落后于潮流用语。它们只是标签，重要的是标签背后的实践！不妨问自己几个问题：工作流程能否稳定复现？如何验证任务结果？人类应该如何（或不应该）介入？对模型的依赖程度是否合理？系统还能怎么优化？这是工程实践的新纪元，最佳实践依然至关重要！