llama.vscode：把 FIM 补全和 Llama Agent 放进 VS Code 的本地方案
VS Code extension for LLM-assisted code/text completion
秒懂
- 它是什么？
- 这个 MIT 许可的 TypeScript 扩展把 llama.cpp 的 FIM 补全、聊天和 agent 接进 VS Code，模型跑在本机。它适合愿意自己装 llama.cpp、自己管模型的人，不适合想要开箱即用云端补全的人。
- 适合谁用？
- 如果你的机器有独立显存、你接受自己维护 llama.cpp 和 GGUF 模型，并且需要补全数据不出本机，llama.vscode 值得装；如果你只想在 VS Code 里得到一个不用配置的补全服务，或者团队里没人愿意处理模型下载和端口配置，它不是合适的工具。上手前先确认三件事：llama.cpp 是否已经装好并能被扩展自动安装流程识别（macOS 需要 Homebrew，Windows 需要 winget，Linux 要自己把 bin 目录加进 PATH）；你的显存落在哪一档，README 给出的分档是 64GB 以上、16GB 以上、16GB 以下、8GB 以下；以及你要用的模型是不是 FIM 兼容，仓库明确要求这一点。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 10 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决的是补全延迟和代码外流这两件事
云端补全的常见问题是每次按键都要一次网络往返，以及对私有代码库的合规顾虑。llama.vscode 的做法是把模型放在本机，通过 llama.cpp 提供服务，扩展只负责收集上下文、发起请求、把结果渲染成内联建议。README 把它定位为「Local LLM-assisted text completion, chat with AI and agentic coding extension for VS Code」，三个功能共用一套模型配置。目标用户是已经在用 llama.cpp 或愿意折腾本地推理的开发者，而不是想装完就用的人。
补全的触发方式和接受粒度
扩展默认在输入时自动给出建议。接受整段建议按 Tab，只接受第一行按 Shift + Tab，逐词接受按 Ctrl/Cmd + Right Arrow，手动触发或关闭建议按 Ctrl + L。这种分层接受的设计在写代码时比较实用：整段建议往往包含不止一处的改动，逐行或逐词接受能让开发者保留控制权。README 还提到可以控制最大文本生成时间和配置光标周围的上下文范围，这两项直接决定补全的响应速度和相关性。
ring context 与上下文复用
上下文来源不只是当前文件。README 描述的 ring context 会从打开的文件、编辑过的文件以及被 yank 的文本中取块，拼成一个围绕光标上下文的环形缓存。更关键的一点是它引用了 llama.cpp 的一个 PR（#9787）来说明「Supports very large contexts even on low-end hardware via smart context reuse」。这意味着扩展不会每次都把完整上下文重新喂给模型，而是尽量复用服务端已有的 KV 缓存。这是它在低端硬件上还能跑大上下文的原因，也是它强依赖 llama.cpp 服务端行为的地方：换一个不支持 cache reuse 的后端，这个优势就不存在了。
安装：扩展和 llama.cpp 是两件事
扩展本身从 VS Code Marketplace 安装，Open VSX 上也有同名包。llama.cpp 的安装按 README 已经自动化：点击状态栏的 llama-vscode 或按 Ctrl+Shift+M 打开菜单，选「Install/Upgrade llama.cpp」，macOS 走 Homebrew，Windows 走 winget，Linux 需要自己下载最新二进制并把 bin 目录加入 PATH。手动安装的命令是 brew install llama.cpp 或 winget install llama.cpp。装好后从菜单的「Select/start env...」选择环境。模型下载默认落盘位置：macOS 是 ~/Library/Caches/llama.cpp/，Linux 是 ~/.cache/llama.cpp，Windows 是 LOCALAPPDATA。
服务端参数按显存分档，CPU 档要接受质量下降
README 给出的推荐配置直接按显存分档：超过 64GB 用 llama serve --fim-qwen-30b-default，超过 16GB 用 --fim-qwen-7b-default，不足 16GB 用 --fim-qwen-3b-default，不足 8GB 用 --fim-qwen-1.5b-default。纯 CPU 的两条配置示例显式带了 -ub 512 -b 512 --ctx-size 0 --cache-reuse 256 这类参数，并注明「the quality will be significantly lower」。这一点值得直说：如果你没有独立显卡，这套方案能跑，但补全质量会明显低于同价位的云端服务，把它当成离线兜底比当成日常主力更合理。
Llama Agent 和它依赖的外部条件
除了补全，扩展内置了 Llama Agent，入口是 Ctrl+Shift+A 或菜单里的「Show Llama Agent」。README 说它可以用本地模型（当前推荐 gpt-oss 20B），也可以接 OpenRouter 这类外部模型，支持从 VS Code 里已安装并启动的 MCP Server 取工具，自带 9 个内部工具，其中 custom_tool 用于返回文件或网页内容，custom_eval_tool 允许用 JavaScript 写自定义工具。最大循环次数可配置。这里有一个容易被忽略的耦合：MCP 工具来自 VS Code 中已安装且已启动的 MCP Server，也就是说 agent 的能力上限取决于你在编辑器里另外配了什么，扩展本身不提供这些服务。
模型管理和 env 这层抽象
扩展支持对补全、聊天、嵌入和工具四类用途分别添加、删除、导出、导入模型，并引入了 env（一组模型的集合）的概念，选中或取消 env 会连带选中或取消其中所有模型。仓库提供预定义模型和预定义 env，覆盖「只补全」「聊天加补全」「聊天加 agent」等场景，也可以在扩展内直接搜索并下载 Hugging Face 上的模型。这层抽象解决的是多用途模型切换的问题，代价是配置项变多：模型、env、用途三者的对应关系需要自己理清，配错一处会出现补全能用但 agent 不出结果这类现象。
和 llama.vim 的关系，以及不适合它的场景
同一组织下还有 llama.vim，README 在「Other IDEs」里把它列为 Vim/Neovim 的对应实现，并说明本扩展的初版是参考 llama.vim 写的。两者共享 llama.cpp 后端和 FIM 的思路，差别在于宿主编辑器和交互方式，所以选哪个取决于你主要在哪写代码，而不是功能强弱。反过来说，如果你的团队需要统一的补全体验、跨编辑器一致的行为、或者不想在每台机器上分别处理 Homebrew、winget、PATH 和模型缓存，这套方案的成本会迅速上升。它也不适合需要极低延迟且没有本地 GPU 的场景。
维护成本和许可
扩展以 MIT 许可发布，代码是 TypeScript，默认分支为 master。从发布节奏看，v0.0.63 到 v0.0.65 集中在 2026 年 8 月中旬到 9 月初，版本号仍在 0.0.x，说明接口和配置项还可能变动，升级前值得看一眼 release notes。真正的维护负担不在扩展本身，而在 llama.cpp：它由扩展自动安装或由你手动安装，模型文件需要自己占磁盘和管理，服务端参数需要按硬件调。MIT 许可只覆盖这个扩展仓库，llama.cpp 和各个 GGUF 模型有各自的许可条款，商用前需要分别确认，这里不构成法律意见。
编辑结论
如果你的机器有独立显存、你接受自己维护 llama.cpp 和 GGUF 模型，并且需要补全数据不出本机，llama.vscode 值得装；如果你只想在 VS Code 里得到一个不用配置的补全服务，或者团队里没人愿意处理模型下载和端口配置，它不是合适的工具。上手前先确认三件事：llama.cpp 是否已经装好并能被扩展自动安装流程识别（macOS 需要 Homebrew，Windows 需要 winget，Linux 要自己把 bin 目录加进 PATH）；你的显存落在哪一档，README 给出的分档是 64GB 以上、16GB 以上、16GB 以下、8GB 以下；以及你要用的模型是不是 FIM 兼容，仓库明确要求这一点。补全质量最终取决于你选的模型和上下文配置，而不是扩展本身。
社区笔记