GitHub 把九个新词写成了一份词典，其中只有三个在讲模型
2026 年 9 月 2 日，GitHub 开发者推广高级总监 Cassidy Williams 在 GitHub Blog 发布了一份 AI 术语解读，把最近冒出来的一批新词逐个讲了一遍：loop engineering、Ralph loop、squad、fleet、harness、harness engineering、hill climbing、forward deployed engineer，以及 closed models、open weights、open source models。配套的是同名的 GitHub Podcast 一集，讨论者为 Marlene Mhangami、GPS 和 Cassidy Williams。
九个词排在一起，很像一份要背的单词表。换一个角度，按“它在描述谁”重新分一次，会看到一件更简单的事：只有最后三个词在讲模型本身，另外五个描述的是模型外面那一层——流程怎么排、多个 agent怎么分工、工具和权限怎么配、输出怎么验证、系统怎么一轮轮改；剩下一个 forward deployed engineer 是个岗位名。那一层在这批词里有一个名字，就是 harness。它是最关键、也最容易被当成又一个新词划过去的那个。
Cassidy Williams 给出的收尾建议指向同一处：别追新词，去问自己的流程能不能稳定重复、任务怎么验证、人该在什么时候插手、模型能信到什么程度。
九个新词分别管哪一层
| 术语 | 管的是哪一层 | 它回答的问题 |
|---|---|---|
| loop engineering | 流程 | 怎么把一次性提示变成可重复运行的系统 |
| Ralph loop | 流程 | 给它一份规格让它一直做到完成，代价是每轮更贵 |
| squad 与 fleet | 协作 | 多个 agent 怎么分工、怎么并行 |
| harness 与 harness engineering | 系统 | 模型之外的工具、权限、上下文、编排怎么设计 |
| hill climbing | 改进 | 怎么用评测和反馈一轮轮把系统调好 |
| forward deployed engineer | 角色 | 谁把工具和 agent 接进客户的既有系统 |
| closed／open weights／open source | 共享方式 | 你能拿到多少、改到什么程度 |
先从最小的一件事看起：把每天早上的手动提示，换成一条会自己跑的流程。
把每天早上的手动提示，换成一条会自己跑的流程
loop engineering 指的是围绕 agent 设计可重复的系统，而不是一次一个任务地手动提示它。GitHub 给的例子很日常：不要每天早上去跟 agent 说一遍“看看新 issue、总结一下、提个修改建议”，而是建一条按计划运行的循环——自己去取新的 issue，交给 agent 处理，验证它的输出，把卡住的任务升级处理。对这个循环，文章用了一个自嘲的说法：一条被美化的 AI 原生 cron job，也就是按时间表自动执行的定时任务。
同样是循环，做法可以差很远。Ralph loop 是其中一种实现：给 agent 一个详细任务，常常直接来自产品需求文档或规格说明，然后让它一直做到任务结束。好处是大任务能被拆成一轮轮“计划—执行—检查”；代价写在明处——每多迭代一轮，就多消耗 token、多占用上下文、多花算力。这是一个定性判断，文中没有给出任何量化对比。
所以“把提示写进循环”和 loop engineering 不是一回事。一份设计良好的循环会加上 skills、observability、validation、routing、checkpoints 这些原语，拆开看就是：让循环知道自己有哪些能力可用、跑到哪一步了、输出算不算合格、出错时交给谁、在哪个位置可以停下来等人工确认。这些东西不产生模型能力，它们决定模型的能力在什么时候被信任。
一条会自己跑起来的循环长什么样
定时启动
不是等人来问，而是按计划自己开始。
抓取新 issue
循环自己去取要处理的对象。
交给 agent 处理
把任务传给 agent，由它产出总结或修改建议。
验证输出
这一步决定循环能不能被信任，也是它与无限重试的分界线。
卡住的升级给人
验证不过或卡住的任务交回人工，而不是继续空转。
步骤来自 GitHub 博文给出的 issue 处理示例，是说明用的流程，不是某套产品的实际实现。
多个 agent 不是把同一个 agent 复制几份
squad 和 fleet 描述的不是流程，而是“有几个 agent、各自负责什么”。squad 是一组角色不同的 agent，常常照着真实团队的分工搭：一个负责规划，一个负责审查这份规划，一个负责实现，一个负责测试，一个负责代码审查。fleet 说的是并行——同一时间有一批 agent 在干活。
这两个词可以叠在一起用：一个 squad 可以放进 fleet 里并行跑，也可以按顺序走。核心思路是并行化加专业化，不让一个 agent 从头包到尾，而是让不同 agent 接手流程的不同部分，各自用特定的 skills 去调优。
需要提醒的是，这一层的描述全部停留在设计意图上。GitHub 没有给出并行度、成本或效率的任何数据，也没有真实团队的使用记录，“多个 agent 分工更快”目前没有被证明。还有一个没展开的问题是：agent 并行之后，冲突、合并和责任归属要由谁处理。
squad 和 fleet 不是同一种东西
| 对比维度 | squad | fleet |
|---|---|---|
| 组成 | 一组角色不同的 agent，常对应真实团队分工 | 同时处理任务的并行 agent 集合 |
| 解决的问题 | 专业化：不同环节交给不同 agent | 并行化：同一时间处理更多任务 |
| 两者关系 | 可以在 fleet 中并行，也可以顺序工作 | 是并行尺度，本身不规定角色 |
流程排好了、分工也有了，还缺一件东西：模型本身被摆在什么位置。这正是这批新词里最关键的一个。
harness：模型之外的一切，才决定模型的能力往哪使
GitHub 对 harness 的定义是：模型之外、让模型在你的工作流里真正有用的一切，包括工具、权限、记忆、上下文和编排。这个词本义是马具；马会跑，但方向、力道和安全性由马具决定。模型会生成内容，但它什么时候被允许做什么、看得到哪些信息、输出交给谁，由 harness 决定。围绕这套东西做设计和改进，就是 harness engineering。
GitHub 举的软件 harness 例子是自己的 GitHub Copilot：它把模型接到代码库、编辑器、pull request、终端这些地方，让模型能在真实工作流里干活。这个例子要打个折扣看——发布方就是 GitHub，Copilot 也是 GitHub 的产品，自己举例说明自己的定义，属于发布方自证。同一发布方的工程文章把 Copilot agentic harness 描述为 Copilot SDK（软件开发工具包）的单一共享组件，驱动 Copilot CLI（命令行工具）、Copilot app 和代码审查；这同样只是自证，不能算独立核验。
但即便只是自证，里面有一个值得记住的结构事实：同一套 harness 支持 20 多个前沿模型，横跨 GPT、Claude、Gemini 和 MAI 家族，还可以用自带 key 接入开源与本地模型。模型是可替换的，外壳是留下来的那一套。这种“模型与外壳分开设计”的做法，正是外围系统这个说法在工程上站得住脚的原因。
边界也要说清楚：“20+ 前沿模型”是发布方自报的数字，具体清单和统计时间都没有给出；能被一套外壳支持，不等于在每个模型上都表现一样。
类比harness 与模型的关系马具与马
模型可以换、外壳留下来，那就冒出一个具体问题：同一个模型换一套外壳，成绩会差多少？
同一模型换一套外壳，GitHub 自评的答案是“持平”，但有一项差了 7%
GitHub 自己的评测给了一个分裂的答案：大部分指标看不出差距，个别地方差得出来。报告称，在固定同一模型和同一批任务的前提下，GitHub Copilot harness 的任务完成率与其他模型厂商自带 harness 相当，差异落在模型随机性造成的运行间波动范围内；并且在多数配置下，它的 token 消耗更低。但在 SWE-bench Verified这一项上，Copilot CLI 对 GPT 5.4 和 GPT 5.5 分别低了 7% 和 4%。两个方向相反的结论同时成立。
先看条件。被测的是四个模型：Claude Sonnet 4.6、Claude Opus 4.7、GPT-5.4、GPT-5.5。对照的是这些模型厂商自带的外壳——Sonnet 4.6 和 Opus 4.7 对 Claude Code，GPT-5.4 和 GPT-5.5 对 Codex CLI。
运行条件被尽量拉平：context window（上下文窗口）大小、prompt token 上限、reasoning effort（推理投入，取中等档 medium）都做了归一化，并关掉 tool search 和 MCP servers 这类额外接入，只保留各 harness 自带的内置工具。所有运行都是两小时超时、非交互式、单轮完成、禁用 web 工具，其余工具全部允许。判定指标是 pass@1，也就是一次通过率。样本是 TerminalBench 2.0 的 89 个任务，每个模型–配置至少跑五次独立运行；基础设施相关的失败会重跑，模型自己犯的错误保留在结果里。
再看不该跨过的那条线。这是 GitHub 自己设计、自己运行、自己报告的测试，没有第三方复核。归一化设置低于公开榜单提交常用的配置，这些数字不能和公开排行榜直接比。对实例少于 100 个的 benchmark，它报告的是五次运行里最好的一次，这个口径本身就偏乐观。可读正文只给了“持平”和“多数配置更低”这类定性说法，具体的完成率、token 数和美元成本没有出现；7% 和 4% 来自官方图表的说明文字，分母和置信区间未知。
即使把折扣打满，这份评测还是说明了一件有用的事：harness 的差别真实存在，而且方向不固定——它可以省下 token，也可以在某一类任务上落后。所以“哪个模型最强”这个问法至少缺两个限定：配的是哪套系统，跑的是哪类任务。
同一模型、同一批任务，换一套 harness 会差多少
GitHub Copilot 的 agentic harness 与模型厂商自带 harness 相比，在任务完成率与 token 效率上表现如何？
- 实验设置
- 固定同一模型与同一批 benchmark 任务，把 context window 大小、prompt token 上限、reasoning effort（中等）与设置归一化（无 tool search、无 MCP servers），保留各 harness 的默认内置工具；所有运行两小时超时、非交互式单轮、禁用 web 工具、允许全部工具。Claude Code 与 Codex 使用直连的 Anthropic／OpenAI 端点；TerminalBench 2.0 分析中 Claude Code 与 Copilot CLI 启用 tool search，Copilot CLI 使用 github-mcp-server。
- 样本与轮次
- TerminalBench 2.0 共 89 个任务，每个模型–配置至少 5 次独立运行，Copilot 分两批评测；实例少于 100 的 benchmark 做 5 次独立运行并报告最好一次；基础设施相关失败重跑，模型自身错误保留在结果中。
- 模型
- Claude Sonnet 4.6、Claude Opus 4.7、GPT-5.4、GPT-5.5
- 判定指标
- pass@1 的任务完成率、每任务 token 消耗与每任务美元成本；1σ 椭圆表示运行间波动
- 对照或基线
- 同模型的模型厂商自带 harness：Claude Code（Sonnet 4.6、Opus 4.7）与 Codex CLI（GPT-5.4、GPT-5.5）
结果：发布方称 Copilot harness 的任务完成率与模型厂商 harness 持平（差异落在运行间方差内），并在多数配置下 token 消耗更低；图表说明文字显示 SWE-bench Verified 上 Copilot CLI 对 GPT 5.4、GPT 5.5 分别差 7% 与 4%。
边界：由 GitHub 自行运行并报告，无第三方复核；归一化设置低于公开 benchmark 提交常用配置，不可与公开榜单直接比较；小 benchmark 报告最好一次运行而非平均；两小时超时限制；具体完成率、token 与成本数值未在可读正文给出，7% 与 4% 来自图表说明文字，分母未知。
如果外壳的影响真有这么大，改进它就不该是小修小补。GitHub 记录了一次极端的手术。
把 Copilot runtime 重写成 80 万行以上 Rust，一个人几个月
这次手术的对象是 Copilot 的 agent runtime，也就是支撑 Copilot CLI、Copilot app 和 SDK 的那套运行时。它原本是 TypeScript 跑在 Node.js/V8 上，重写之后变成超过 80 万行生产 Rust。整个移植横跨 128 个 pull request，增量合入主干、分批发布，而不是攒到最后一次性切换。策略上选的是“就地”原子替换：逐个组件从 TypeScript 换成 Rust，主分支始终保持可发布。
数字要连口径一起记。2026 年 5 月初的初始移植计划估算 runtime 约 13 万行 TypeScript；作者后来估计，实际有约 43 万行生产 TypeScript 经过移植。移植期间 runtime 收进约 30 万行生产 TypeScript、移除约 43 万行，同期约 120 万行生产 Rust 进入、约 36.5 万行离开。后面这两个数字包含移植之外的常规新增代码，不能直接算作移植产出，也不该和 80 万行这个存量口径相减。
最常被引用的一句是：这个项目在 agent 出现之前需要一整支开发团队花一到两年。如今它主要由单个开发者在几个月内完成，团队其余成员同期继续扩展 runtime 功能。这句话是作者的估计，没有基线项目，也没有受控对照；“一到两年”和“几个月”都是区间，不能当成通用的效率倍数。作者本人也明确否认这个案例能推广成“其他大型 TypeScript 项目都该改写为 Rust”。移植也还没彻底结束，CLI 尚未完全迁移到 SDK 的公开接口上。
这段经历的价值不在 Rust 本身，而在于它给出了 harness engineering 的实际量级：不是拧几个参数，而是可以重新安排一整套运行时、交付节奏和验证方式。它同时也暴露了这类工程的典型风险——代码在移植途中继续增长，原计划估算的 13 万行，最后变成 43 万行经过移植。范围膨胀是常态，不是意外。
这次重写的三个数字
- 800,000+
重写后的生产 Rust 代码
- 128
增量合入主干的 pull request
- 约 100
旧架构下每个 SDK 消费者、每种语言的最小工作集开销量级
Copilot runtime 从 TypeScript 重写成 80 万行以上生产 Rust
Copilot agent runtime（支撑 Copilot CLI、Copilot app、SDK 等产品）原为 TypeScript on Node.js/V8 实现，TUI 与 runtime 交织，SDK 通过 JSON-RPC 调用 headless CLI 子进程，每个 SDK 消费者、每种语言至少要额外承载约 100 MB 量级的语言运行时工作集。
- 规划
2026 年 5 月初的初始移植计划估算 runtime 约 13 万行 TypeScript。
- 策略选择
放弃一次性重写，选择就地、逐组件原子替换，主分支始终可发布。
- 执行
大部分代码由 AI agent 编写，共 128 个 pull request 增量合入主干并分批发布。
- 范围膨胀
移植期间仍有新 TypeScript 代码持续进入，作者最终估计约 43 万行生产 TypeScript 经过移植。
- 完成重写
runtime 被重写为超过 80 万行生产 Rust，并以纯原生二进制暴露 C ABI。
结果：作者称 runtime 性能提升数个数量级；该项目此前需要整支团队一到两年，现主要由单个开发者在几个月内完成，团队其余成员同期继续扩展 runtime 能力。
不能据此证明：不能证明其他大型 TypeScript 项目都应改写为 Rust（作者本人明确否认这一点），也不能证明其他团队能复现同等速度；移植工作仍在进行，CLI 尚未完全迁移到 SDK 公开表面；“一到两年”与“几个月”均为估计区间，无基线项目对照。
基于证据重建事件顺序，非逐字对话
靠反馈一轮轮往上调，可能只走到邻近的小山头
hill climbing（爬山法）在这批词里指的是用反馈持续改进 agent 和 harness：用 evals（评测集）衡量 agent 的输出对不对，再回头调整 harness，看结果有没有变好；如果这个 agent 负责审查 pull request，那就去看它找到了几个真 bug、建议有没有用，再据此调整它手里的工具。
这个词有两层边界。第一层是信息量：GitHub 只说了“用反馈接着调”，没有给出任何评测指标、提升幅度或实验设置，所以“这样调能调多好”在这里没有答案。第二层是词义：hill climbing 在优化理论里是一个有严格定义、也容易卡在局部最优的算法名称，这里是工程口语，两者不能直接画等号。混在一起看，容易把“持续调优”想得比实际更可靠——靠反馈往上走，也可能只是走到邻近的小山头。
类比hill climbing 的改进方式在浓雾里爬山，只能看见脚下一小段路，靠每一步的反馈决定往哪挪
系统之外，这份清单里还混进了唯一一个讲人的词。
forward deployed engineer 不是新岗位，是新招牌
forward deployed engineer 这个职位在 AI 之前就存在，只是 AI 的包装让它听起来像新词。它指的是面向客户的软件工程师、销售工程师或解决方案工程师，通常带 AI 焦点。
这类人的工作不是训练模型，而是把技术方案搬进客户自己的环境：先弄清客户现有的系统，再把工具、工作流和 agent 接进去，让它真的跑起来。带 AI 焦点之后，接进去的对象换成了 AI 工具和 agent，工作方式没有变。
把它放回这份清单，九个词的构成就清楚了：三个讲模型，五个讲模型之外那套系统，剩下一个讲的是人。GitHub 没有给出这个岗位的任何量化信息，也没有说这类岗位眼下有多少需求。
人和系统说完了，最后一道边界在模型本身：交到你手里时，你能拿到哪一层。
同样叫开放，能拿到的东西差三层
最后一道边界是模型本身的共享方式，它决定你能改到多深。closed models 通过 API 或托管产品访问，开发者能调用，但拿不到权重、训练数据和训练过程；open weight models 把模型权重公开，可以下载，常在本地或自有基础设施上运行，但数据集和训练方法可能并不完全可得；open source models 更进一步，模型、代码、数据和训练过程都可用于检查、复用和修改。GitHub 的结论是：越开放，越能运行、定制、审计和信任它。
这套三档划分有一处没交代：它和 OSI 等组织的开源定义是否一致，GitHub 没有对照，也没有列出任何具体模型或许可证。所以它更适合当成一个“我能拿到哪一层”的提问框架，而不是一份合规判据。
三种模型共享方式，你分别能拿到什么
| 共享方式 | closed models | open weight models | open source models |
|---|---|---|---|
| 模型权重 | 不可得 | 可得（可下载） | 可得 |
| 训练数据 | 不可得 | 可能不完全可得 | 可得 |
| 训练过程 | 不可得 | 可能不完全可得 | 可得 |
| 本地或自有基础设施运行 | 只能通过 API 或托管产品访问 | 可得 | 可得 |
| 检查、复用与修改 | 不可得 | 可下载运行，能否修改未说明 | 可得 |
回到最开始：这些词到底该不该背。
该背的不是词，是判断它落在哪一层
这些词会留下多少，没人知道。GitHub 自己也承认，有些会留下来，有些会被更好的说法替换，还有些仍在被定义的过程中。所以真正可复用的不是定义，而是三件事：流程能不能稳定重复——这正是 loop engineering 要解决的问题；输出由谁验证——validation 和 evals；模型能信到什么程度、系统能改到多深——取决于你给它配了哪套外壳，以及模型以哪种方式共享。定义会换，这三件事不会。
其中“外壳值不值得设计”这一条，恰好有可查的硬数据可以回答，而答案有点别扭：同一个模型换一套 harness，任务完成率大体持平、token 消耗可能更低，也可能在 SWE-bench Verified 上落后 7%。也就是说，外壳值得认真设计，但不存在一套默认最优的外壳——包括 GitHub 自己那一套。
这个判断会改变的条件很具体：如果出现第三方用同样口径复现的评测，或者公开数据补上被略去的绝对值，“哪套外壳更好”才谈得上结论。
在那之前，遇到一个新词，可以先问它落在哪一层：流程、分工、人，还是模型外面那套系统。这个方法比记住九个定义更耐用——定义会换，层不会。
