Copilot 新增 Raptor mini 模型,提供更快的代码补全速度,改善开发者的编码体验和工作流效率。
GitHub 悄悄在 Copilot 中加入了一个名为 “Raptor mini (Preview)” 的新模型。
更新日志基本上只说了:
“Raptor mini 是一个新的实验性模型,目前正逐步向 Visual Studio Code 中使用 GitHub Copilot Pro、Pro+ 和 Free 方案的用户开放……我们将分阶段逐步推送。”
……但这完全没有告诉我们它是什么、为什么会存在,也没有说明什么时候应该选它,而不是其他模型。
于是,我们做了开发者都会做的事:在 UI 里四处探索,查看支持模型的表格,并深入研究 VS Code 的调试日志。结果发现,其中的信息已经足够让我们勾勒出 Raptor mini 的大致全貌。
这篇文章讲的就是我们还原出的这幅图景。
Raptor mini = 一个由 Microsoft/GitHub 针对 Copilot 微调的 OpenAI GPT-5-mini 系列模型。
它通过 GitHub 的 Azure OpenAI 租户提供服务,并不是由你直接调用 OpenAI。
对于一个名字里带有 “mini” 的模型来说,它的 context window 大得出奇,约为 264k,最大输出也很大,约为 64k。
它已经知道如何处理 Copilot 中的各种任务,包括 chat、ask、edit 和 agent;在测试中,它处理工具和 MCP 工作流的表现也很好。
如果你要在 VS Code 中完成工作区级别、重复性的“把这个改动应用到所有地方”任务,值得试试它。
它看起来像一个低调的试验场:GitHub/Microsoft 似乎希望通过真实使用数据,测试一个以代码为核心的 GPT-5-codex-mini。
如果这些信息对你来说已经足够——那就到 GitHub Copilot Models 中启用它,然后在 VS Code 里打开 Copilot Chat,选择 “Raptor mini (Preview)”,拿一个真实任务试试看。
如果你想看证据,请继续往下读。
根据 Copilot 的 UI 和文档:
它叫作 Raptor mini (Preview)。
它会出现在 VS Code Copilot Chat 的模型选择器中。
它被标记为 “fine-tuned GPT-5 mini”。
文档称,它部署在由 GitHub 管理的 Azure OpenAI 上。
仅凭这些信息,我们就可以判断:GitHub 使用了一个 OpenAI GPT-5-mini,进行了自己的微调和配置,然后只通过 Copilot 向用户提供,而不是将它作为通用公共 API 开放。
到目前为止:✅ 确实是一个真实模型,✅ 确实处于预览阶段,❌ 具体细节为零。
通过 VS Code 的调试日志,我们实际上可以看到模型对象。它看起来是这样的:
{
"billing": {
"is_premium": true,
"multiplier": 1
},
"capabilities": {
"family": "gpt-5-mini",
"limits": {
"max_context_window_tokens": 264000,
"max_output_tokens": 64000,
"max_prompt_tokens": 200000,
"vision": {
"max_prompt_image_size": 3145728,
"max_prompt_images": 1,
"supported_media_types": [
"image/jpeg",
"image/png",
"image/webp",
"image/gif"
]
}
},
"object": "model_capabilities",
"supports": {
"parallel_tool_calls": true,
"streaming": true,
"structured_outputs": true,
"tool_calls": true,
"vision": true
},
"tokenizer": "o200k_base",
"type": "chat"
},
"id": "oswe-vscode-prime",
"is_chat_default": false,
"is_chat_fallback": false,
"model_picker_category": "versatile",
"model_picker_enabled": true,
"name": "Raptor mini (Preview)",
"object": "model",
"policy": {
"state": "unconfigured",
"terms": "Enable access to the latest Raptor mini model from Microsoft. [Learn more about how GitHub Copilot serves Raptor mini](https://gh.io/copilot-openai-fine-tuned-by-microsoft)."
},
"preview": true,
"supported_endpoints": [
"/chat/completions",
"/responses"
],
"vendor": "Azure OpenAI",
"version": "raptor-mini"
}
]
这里有几个重要结论:
模型家族是 gpt-5-mini。因此,我们面对的并不是某个老旧的 GPT-4 衍生模型。它可能是 gpt-5-codex-mini。
对于一个被 GitHub 称为 “mini” 的模型来说,264k 的 context window 相当大。
64k 的输出上限意味着,它可以处理长篇编辑、长篇总结,以及涉及多个文件的长指令。
支持 tool calls 和 parallel tool calls,说明它就是为了与 Copilot 这种“实际做事,而不只是聊天”的使用界面良好协作而构建的。
Vision: true——你可以给它一张图片,而它不会因此不知所措。
这些信息已经比公开公告具体多了。
可以给你的团队这样定义它:
Raptor mini 是一个针对 Copilot 微调的 GPT-5-mini,可能是 codex mini,由 GitHub/Microsoft 托管在 Azure 上。它的规模和连接方式都针对快速完成大型、编辑器式、多文件任务进行了设计,同时能够与 Copilot 的工具和 Agent 协同工作。
就是这样。它并不是什么魔法,但确实非常实用。
因为这是 GitHub 第一次让我们接触到具备以下特征的 GPT-5 系列模型之一:
以编辑器为中心。它确实能够在 Copilot 的 chat、ask、edit 和 agent 上下文中正常工作。
拥有大 context。超过 200k 个 prompt token,意味着“我希望你查看这个工作区里的大量内容”开始变得切实可行。
适合执行操作。在测试中,它“使用工具、skills 和 MCP 的表现非常出色,而且能够正确进行编辑”——这正是你对 Copilot 模型的期待,而不只是一个话很多的助手。
速度足够快。即使设置为 “reasoning: high”,也能达到约 122 tokens/sec,对于 IDE 中的交互循环来说已经足够。
它很可能代表了未来 Copilot 模型的形态。这感觉像是 GitHub/Microsoft 正在收集真实世界的数据,然后才会用一个更友好的名字,推出更加“稳定”的版本。
换句话说,这个模型瞄准的是真实、无聊但价值很高的开发任务——“把这个模式重命名并应用到所有地方”“更新多个文件中的文档”“修复这个类并重新生成测试”,而不只是“解释一下这道 LeetCode 题”。
下面是一种实用的判断方式,可以直接告诉读者:“现在就该用这个模型”:
你正在使用 VS Code,并且已经在使用 Copilot Chat、Ask、Edit 或 Agent。
你希望跨多个文件应用或解释改动。
你希望它能够可靠地调用 MCP 或工具。
你粘贴了一段很长的错误信息、diff 或文件内容,不想看到“内容太长”之类的拒绝。
相比一篇 1,000 字的长文,你更在意它能否正确完成编辑。
你需要极具创意的、长篇的、与编程无关的输出。
你需要一份有正式文档和明确版本记录的 model card,因为它目前仍处于预览阶段。
你的模型选择器里还没有它,因为 GitHub 表示该模型会逐步推送。
在 GitHub Copilot 设置中启用 Raptor Mini Model(需要 Copilot Pro+ 方案)。
在 GitHub Copilot 设置中启用 Raptor Mini Model(需要 Copilot Pro+ 方案)。
打开 GitHub Copilot Chat。
打开 GitHub Copilot Chat。
点击顶部的模型选择器。
点击顶部的模型选择器。
选择 “Raptor mini (Preview)”。
选择 “Raptor mini (Preview)”。
运行一个真实任务,例如:
运行一个真实任务,例如:
I have the file that's open in the editor. Explain why this custom hook is rerendering so often, then propose the smallest fix, then apply the edit.
Scan the components in src/components and update every usage of <OldButton> to <NewButton variant="primary" />. Show me the diff per file.
如果你想深入研究,可以在 VS Code 中打开 Developer Tools,观察网络请求和模型信息——我们就是在那里看到了 oswe-vscode-prime 和 raptor-mini 等信息。
这是一个预览版本。这意味着:
GitHub 可能会在不通知我们的情况下更换底层模型。
我们不知道完整的微调细节,例如使用了哪些任务和哪些数据。
我们没有一份稳定的延迟或性能说明表。
它的命名可能会改变——GitHub 最近经常调整 Copilot 的模型阵容。
因此,如果你要为团队编写内部使用指南,可以这样表述:
“当 VS Code Copilot 中提供 Raptor mini 时,可以使用它,尤其适合长上下文或大量使用工具的编辑任务。它仍处于实验阶段,因此实际效果可能会发生变化。”
这看起来像是 GitHub/Microsoft 正在最安全的场景中内部试用一个以代码为核心的 GPT-5-mini——也就是 VS Code 中的 Copilot。在这里,他们可以控制上下文、工具和遥测数据。
这样才能获得真正的使用数据:“它能处理包含 200k token 的工作区 prompt 吗?”“它能正确调用工具吗?”“开发者会接受它的编辑结果吗?”——这些都是无法从一个通用聊天 playground 中了解到的事情。
所以,是的,适当炒作一下也算合理——不是因为这个名字听起来很酷,而是因为下一代 Copilot 模型实际上就是通过这种方式训练和调优出来的。
GitHub 没有向我们讲清楚整个故事,所以我们只能自己把它还原出来:
它是什么:运行在 Azure 上、针对 Copilot 微调的 GPT-5-mini,可能是 codex mini。
它为什么重要:大 context 加上出色的工具调用能力,意味着它能更好地处理真实的 VS Code 任务。
谁应该尝试:任何已经重度使用 Copilot,并且经常撞上“内容太长”或“别再忽略我的工作区”这类问题的人。
应该期待什么:它会发生变化——毕竟还是预览版本——但现在试用它,既能让你今天获得更好的编辑结果,也能帮助模型在未来变得更好。
如果你的模型选择器里已经有它,就交给它一项真正的工作。不要让它“写一首诗”,而是让它“安全地修改 12 个文件”。
如果你现在还没有看到它……GitHub 已经表示会逐步推送,所以过段时间再回来看看。😉
我很想听听其他开发者对此有何看法,也希望看到社区能够进一步验证这个模型的能力,以及大家是如何使用 Mini-Raptor 的。
如需采取进一步措施,你可以考虑屏蔽此人和/或举报滥用行为。