本文最初发表于 deepu.tech。
我最近写了一篇文章，标题是《笔记本上跑的 Qwen 3.8 真能在 Agent 编程中替代 Claude Opus 吗？》。而这篇文章可以说是这个问题的一个明确答案——至少对我个人如此，或许也适用于那些正在探索本地 AI 方案做 Agent 编程的朋友。
让我直接进入细节，不堆砌大段文字。自从上面的帖子以来，很多事情已经改变，出现了多种针对特定硬件的微调引擎。由于我使用的是 AMD Strix Halo，我对诸如 Halogen 和 Gufo 这样的引擎产生了兴趣，于是决定对不同引擎进行基准测试。请参阅我的 Reddit 帖子（链接）获取完整的基准数字。Halogen 和 Gufo 表现尤为突出。
Halogen 性能最佳，但为闭源，我非常希望开发者以后能够开源。Gufo 是开源的，排名第二。以下是它们在 2026 年 10 月 5 日的速度数字。
| 引擎 | 冷预填充 (t/s) | 解码 (t/s) | 草稿接受率 | 检索 |
|---|---|---|---|---|
| Halogen 0.16.2 | 1,342 / 1,440 / 1,437 | 45.6 / 46.8 / 45.6 | 83 to 90% | 7/7 each |
| Gufo v0.7.1 | 1,090 / 1,059 / 1,060 | 38.9 / 39.9 / 40.7 | 67 to 71% | 7/7 each |
每种引擎各跑了 3 次。功率限制为 70 W。每个数值对应一次冷启动的 32k-token 提示词（一个 Pi 编码任务），在 temperature 1.0 / top_p 0.95 / top_k 20 且 MTP 开启的情况下采样。Halogen 使用其 v2 检查点，Gufo 使用 Unsloth UD-Q4_K_XL 并共享 Q8_0 MTP 头。Halogen 的全部三次运行均为完全冷启动。Gufo 在第二次和第三次运行中重复使用了 6k 和 12.6k 缓存的提示词 token，因此只有其第一次运行是完全冷启动。
解码速度已经足够。预填充才是实际产生最大差异的因素，也是决定模型感觉是否响应的关键。上面的预填充数值是可以接受的，不会让你觉得模型有滞后感。
我的设置
在这些速度下，它们表现相当出色，非常适合作为日常驱动使用。虽然它们还不及前沿模型那么快，但也不算慢，特别是当你一次只运行一个会话时。以下是
我已经让 Pi 和 Claude Code 共享记忆和规则（CLAUDE.md/AGENTS.md），除了模型和 harness 的系统提示词外，两种设置拥有相同的知识和上下文，这样就能根据需要轻松切换并进行比较。
这是一个提示词如果你拥有 Strix Halo 并想尝试我的设置。
我主要以高强度推理运行单个 256k 上下文会话，以免占用其他应用的内存。虽然我可以轻松在降低上下文大小的情况下同时运行两到三个会话。有时我甚至只启动一个 TTY 会话，而不是完整的桌面，让 Pi 和 LlamaStash 在那里并行运行两个完整上下文会话。
过去几周，我使用 Qwen3.8-Flash-Next 运行的 Pi 会话比使用 Claude Code 的更多。我的大部分编码工作面向开源项目，最近主要用于 LlamaStash 和 KDash。两者都是复杂的 Rust 项目。而 LlamaStash 尤其复杂，它支持多种推理引擎，拥有终端 UI，以及大量的 GPU/CPU 硬件交互和复杂的状态管理。这些决非简单项目。以下是我目前在 LlamaStash 上使用 Flash-Next 提交的所有 PR。
| PR | 作用 | 规模 | 复杂度 |
|---|---|---|---|
| #75 |
run 是 start 的别名，以及携带模型预设的 YAML 启动文件
|
12 files, +1,846/-132 | Medium |
| #76 |
命名启动：model@name 在代理、 CLI 和 TUI 中寻址（始于 Qwen3.8-27B， Flash-Next 继承）
|
47 files, +4,038/-345 | High |
| #89 |
daemon restart 命令， CLI、 TUI 和 --llama-server 重启共享同一停止路径
|
12 files, +852/-415 | High |
| #91 | 修复了在 macOS 和 Windows 上失败的文件监视器测试 | 1 file, +30/-3 | Low |
| #92 | 为 #91 修复在 CI 上计时文件监视器事件的临时探针（已关闭， 原本不打算合并） | 1 file, +100/-0 | Low |
| #94 | 模型驻留：每个预设的空闲 TTL，守护进程启动时预加载，以及卸载空闲模型以腾出空间 | 42 files, +3,128/-216 | High |
| #95 |
将 Claude Code 中的 /effort 设置映射到 llama.cpp 模型在 /v1/messages 上的推理强度
|
20 files, +979/-100 | Medium |
| #99 | 为客户端硬编码的模型名称提供代理别名， 共享目录读取以及另外两个代理修复 （尚未合并） | 22 files, +1,553/-100 | High |
Flash-Next 也参与了我最近几次 LlamaStash 的发布。
到目前为止，我的体验真的非常好。使用 Flash-Next 和 Halogen，我尚未遇到思考循环或频繁崩溃之类的问题。公平地说，旧版 Halogen 曾出现过一些连接掉线和少数模型启动失败的情况，但此后我再也没有看到这些问题。而且，在编码质量方面，它绝对不输于甚至优于 Claude Opus 4.8，速度也不相上下。我甚至还有有趣的体验：Flash-Next 在某些情况下竟然比 Opus 5.5 更好 😂
Flash-Next 对比 Claude Opus 5.5
最近我的常规工作流程是先用 Opus 5.5 制定计划，然后用 Flash-Next 执行。接着用 Opus 和 Flash-Next 两者一起审查。随后用 Flash-Next 修复，并不断迭代直到满意。有时我也会调换角色，让 Flash-Next 审查 Opus 的输出。以下是我目前的真实体验。
Flash-Next 实现与 Opus 5.5 审查：
- 在类似规模的任务中，所需轮数与 Opus 大致相同（即我需要的交互量相同）
- 完成一个任务的总时间有时是 Opus 的两倍，有时则根据上下文和思考力度会多出 5 到 10 倍
- 代码质量非常好，Opus 的审查通常只会发现一些小问题和次要问题。阻塞性问题很少。到目前为止，尚未遇到存在严重缺陷或需要大量返工的任务。
- 只要给出清晰的指令或计划，它就能一次性高准确率完成
- 有了清晰的计划，它执行得非常出色，感觉也更快（可能是思考开销更低）
Opus 5.5 实现与 Flash-Next 审查：
- 所需时间是 Flash-Next 的 2 到 5 倍
- 它确实能发现问题并提供改进建议（查看此例）。到目前为止 Opus 只拒绝了极少数发现，主要是出于设计决策。我认为它的审查水平甚至可以匹配 Opus 5。令我惊讶的是，当我让两者审查同一些 PR 时，它竟然发现了比 Opus 多得多的问题。
以下是我迄今为止的两个有趣实验示例：
高复杂度特性：Opus 5.5（中等力度） vs Flash-Next（极高力度）
我把下面的提示词同时给了 Flash-Next 和 Opus 5.5 进行比较。我本来也想在 xhigh 设置下比较 Opus，但 Claude 出于某种原因在选择最新模型时把思考级别调到了 medium，直到任务完成我才发现。我不重新用 xhigh 进行测试，因为我认为 Opus 在 medium 下已经是一个较为公平的比较。我故意保持提示词模糊，并省略了一些细节，以观察模型是否能自行弄清楚。需要注意的是，这里的 Flash-Next 使用的是较旧的 Halogen 版本（0.14.0），比我现在运行的要慢。Halogen 在第三个提示词期间掉线了，因此该提示词的剩余部分以及 PR 步骤是在 Gufo 上运行的。
First prompt: "为 daemon 命令添加一个 restart 子命令 llamastash daemon restart，它应尽量复用 start 和 stop 命令的代码，最大程度复用现有代码，必要时进行抽象。在新的 worktree 和分支上工作。"
Opus 5.5 完成第一次迭代大约用了 9 分钟。Flash-Next 完成第一次迭代大约用了 38 分钟。两者都成功完成了任务，但都未能复用现有路径的代码，于是我给了两者同样的提示。
Second prompt: "顺便说一下，TUI 中的 daemon restart 快捷键和 CLI 的 restart 命令应该复用代码，而不是在两处重复实现。请也检查这一点。"
Opus 5.5 找到了第二条路径并复用了代码，耗时大约 6 分钟。Flash-Next 也找到了第二条路径并复用了代码，耗时大约 34 分钟。此时 Opus 发现了一条流程相同的第三条路径，并同样复用了代码。因此第三个提示词只是让 Flash-Next 赶上进度。
Third prompt (Flash-Next only): "还有其他路径在执行重启吗？保持 DRY。"
Flash-Next 找到了该路径并复用了代码，耗时大约 30 分钟（如果连接没有掉线，速度会更快，因为需要重新预填充整个上下文，这会增加几分钟的时间）。
Final prompt: "创建 PR"
Opus 用了 3 分钟创建了 PR，但尽管我的 main 分支有更新且 PR 出现冲突，它并未执行 rebase。Flash-Next 创建 PR 用了大约 30 分钟。Flash-Next 首先执行了 rebase，并在 3 个文件中解决了冲突。随后它重新运行了测试和 E2E 检查，大约在 18 分钟时打开了 PR，然后一直等待 CI 完成剩余的检查。
总体来看，Opus 完成任务并创建 PR 总共用了大约 18 分钟（输入 token 7.83M，输出 token 41.5K），而 Flash-Next 用了大约 130 分钟（输入 token 20.61M，输出 token 101K）。因此 Flash-Next 的耗时是 Opus 的 超过 7 倍，且消耗的 token 超过了 Opus 的两倍。如果我用最新的引擎重新进行测试，我认为耗时会大幅下降。
成本方面，Claude Code 整个 Opus session 报告了 7.53 美元（这包括后来对 PR 的修复）。Flash-Next 除了大约 0.15 kWh 的电力之外基本没有花费，假设整个 130 分钟都受到 70 W 的功率上限。
结果很有趣。两个模型都很全面，按照 AGENTS.md 中的项目说明进行了自审查、端到端测试等每一步工作。有趣的是，我发现 Flash-Next 相比 Opus 进行了更彻底的端到端测试。以下是两个模型创建的 PR，供参考。
| Opus 5.5 (medium) | Flash-Next (xhigh) | |
|---|---|---|
| 拉取请求 | #88 | #89 |
| 更改的文件 | 10 | 11 |
| 更改的行数 | +334 / -272 | +586 / -404 |
| 新增测试 | 1 | 4 (其中 2 个是端到端) |
| 新增测试代码 | 29 行 | 146 行 |
| 新增文档 | 3 行 | 30 行 |
| 创建 PR 所需时间 | ~18 分钟 | ~130 分钟 |
| Tokens（输入 / 输出） | 7.83M / 41.5K | 20.61M / 101K |
#89 的数字来自模型审查的版本。现在它多了 6 次提交，因此拉取请求页面显示 +852/-415。
我让 GPT 5.6、Opus 5.5 和 Flash-Next 在一个新会话中审查并比较这些拉取请求。以下是他们的摘要。
GPT 5.6:
我选择 89。它在停止运行的守护进程之前检查替换配置，它会停止已解析的 --state-dir，并且它具备冷启动和热启动的端到端测试。88 在默认状态目录下调用 stop_daemon(false)，因此使用 restart --state-dir X 可能会停止错误的守护进程。89 在合并前需要一个修复：在 shutdown 调用之后删除(client)，就像 88 所做的那样。
Flash-Next:
我选择 89。它具备冷启动和热启动的真实二进制测试，一个在启动和重启时都运行每个标志的解析测试，一个处理陈旧状态的 NoChannel 结果（集中在一个地方），以及一个架构文档章节。88 具有一个单元测试和 usage.md 中的一段文字。89 应该从 88 中采纳三点：在停止前检查新配置，在等待之前删除 IPC 客户端（每次停止可节省 2 秒），并在停止阶段尊重 --state-dir。
Opus 5.5:
我选 88。它在停机之前先构建新配置，所以即使标志或配置有误，正在运行的守护进程也不会受影响。它还绕过了 IPC 客户端，让停止操作不必等待 2 秒的连接排空，并且会在指定的 --state-dir 中停止守护进程。89 这几点都做不到，但测试更好，还有 NoChannel 的过期状态处理和架构文档。我会合并 88，再把这三点从 89 移植过来。
GPT 和 Flash-Next 都选了 89，而 Opus 选了 88。我自己也做了审查，发现 Flash-Next 的实现更好：测试更完善，覆盖率更高，还有回归测试。它的处理也更细致，边缘情况覆盖得更周全。最终我把评论中提到的 #88 的修复移植过来之后，合并了 #89。
要知道，Opus 这里用的是 medium 推理力度，如果用 xhigh，token 消耗会大得多，耗时也更长，实现质量可能也会更好。但对我来说，能在本地跑一个模型，还能和前沿模型掰手腕，这件事本身就很不可思议。
中等复杂度任务：Opus 5.5（xhigh 推理力度）vs Flash-Next（xhigh 推理力度）
我让 Opus 5.5（xhigh）和 Flash-Next（xhigh）分别为 LlamaStash 提议一些新功能。下面是它们的回答。两者都提出了不少有意思的想法，有些不谋而合，也各有独到的建议。我个人更喜欢 Qwen 给出结果的格式，更清晰，不需要追问任何澄清。而 Opus 这边，我得反复追问才能拿到同样详尽的内容。你更喜欢哪一个？
提示词：“为项目建议一些值得添加的功能，要求对最终用户有用，或者能提升性能、安全性或用户体验。”
我先检查了当前的代码面（v0.6.1： 首选方案 1. 页缓存预热 — 2. 按模型的请求指标—— 3. 从Shell直接单次提问—— 4. 密钥移出 5. 6. 磁盘管理—— 7. 8. 低成本润色 已在 TODO.md 中跟踪 — 不再重复建议 LAN TLS，MCP 表面，代理并发上限，SSE 日志尾随，Flash-Next 的回答（耗时约 4 分 57 秒，输入 574K token，输出 9.2K token）
src/cli/cli_args.rs 中的 CLI 子命令、src/proxy/*、TODO.md 中的待办项），确保以下建议都是尚未实现的，而不是和 TODO 重复。llamastash warm <model>（性能，性价比最高）
docs/usage.md:855）；TODO 中提到冷加载 104 GB 的 GGUF 约需 130 秒。posix_fadvise(WILLNEED)（或用受限的读取线程），在空闲内存装不下或已有启动任务正在加载时跳过。Windows 上对应 PrefetchVirtualMemory。daemon.preload_warm:（0.6.0daemon.preload的低成本姊妹功能——只预热内存，不分配服务器），外加llamastash warm --json。目前src里完全没有用到fadvise/readahead。llamastash stats [model]（新的用户可见数据）
src/proxy/*.rs里没有解析usage，没有/metrics路由，TUI里也只有实时仪表盘。state.json里持久化一个小的环形缓冲。--prometheus。llamastash ask <model> -p "..."（面向Agent和脚本的体验）
src/tui/tabs、oai_client.rs）；start没有提示词参数，所以写脚本的人现在只能自己拼curl加bearer token。--json、stdin管道、--system、--file。这就是大家用ollama run <m> "prompt"时已经养成的肌肉记忆。config.yaml + 密钥卫生（安全）
env:值只支持字面占位符（src/backend/generic/config.rs:11），引擎的API密钥只能明文写入——而在你的机器上，config.yaml是指向~/dotfiles的符号链接，也就是一个git仓库。{env:VAR} / {file:path}解析、用doctor检测疑似密钥的字面量（sk-…、hf_…）和非0600权限的配置、api-key rotate，以及LAN模式密钥的认证失败退避（目前可以无限次尝试）。start --dry-run（可调试性，约一天工作量）
show会打印将用于启动的架构默认值，但不显示最终的argv和环境变量，也无法传入参数覆盖。目前没有任何命令能在不加载模型的情况下输出解析后的命令。llama-fit-params预览功能的自然归宿。llamastash storage + CLI delete（终端用户在大模型库下的痛点）show 只能看到单个模型的大小，没有整体视图，也没有孤儿清理。HF 的 blob 在快照之间是硬链接，所以 naive 的逐文件删除无法释放用户期望的空间——真正起作用的是引用计数的会计。
daemon install-service (运维)
clap_complete 依赖，因此没有 llamastash completions bash|zsh|fish。约 30 行，立刻可见。doctor --fix: 今日文档为只读（cli_args.rs:233）；修复权限，过期的 runtime.json/daemon.pid，失效的集成端口，缺失的 llama.cpp 安装。
llamastash update 加上在 status/TUI 页脚中的 'vX.Y.Z 可用' 行。不存在自更新路径或版本检查；发布渠道（brew/scoop/gh）已经在 init 中已知。
llama-fit-params 预览，混合架构 KV 估计（高估 Qwen3.8-Flash-Next 24 GiB，实际约 6 GiB），vLLM cors: true 默认值，TUI 常驻编辑器。
已检查 最终用户 性能 安全 用户体验 已跟踪且值得提升优先级：CLI 来自 Opus 5.5 的回答（耗时约 2 分钟，输入 690K tokens，输出 9.3K tokens）
TODO.md 和 src/ 中的想法，确保它们尚未被实现或跟踪。我的首选是 1、6 和 8。
status --json 中。src/ 中除了 init 的估计外，没有吞吐量代码。
llamastash bench <model> [--preset a,b]: 每个预设快速给出 tok/s 和首 token 数，以便用户比较参数变化。目前这仅存在于 scripts/bench/ 中的维护脚本。
proxy.aliases: {gpt-4o-mini: <model>} 映射，用于硬编码模型名称的工具。解析器接受真实 ID 的多种拼写，但不接受任意名称。
list 标记了一个缓存的 HF 仓库，其上游修订版本较新，而 pull --update 会获取它。在 src/ 中不存在更新检查。
daemon install: 编写一个 systemd 用户单元或 launchd 代理，使守护进程和预加载模型在登录时启动。docs/usage.md 仅记录 daemon start。
--slot-save-path）；我凭记忆这么说，这不是针对当前构建的检查。src/ 中没有使用它。
route::decide 中的按请求目录克隆（TODO.md:565）以及异步路径上的阻塞 GGUF 头部读取（TODO.md:566）。
no_new_privs）：模型目录为只读，写入仅限于 state/log 目录。主管目前仅执行 setsid 和环境变量剥离。这对通用后端最有帮助，因为它会运行用户声明的任何服务器，也适用于不受信任的 GGUF 下载。
lfs.sha256: src/init/download.rs 缺少哈希检查，尽管 HF 树 API 会返回哈希。为现有文件添加 doctor --verify-models。我未检查 hf-hub crate 是否自行验证。
proxy.api_key。命名密钥可以逐个撤销，并能提供每客户端的使用次数。这与 TLS 配对（TODO.md:493）。
src/tui/tabs/chat.rs:7 表示它是单次发射。
delete（TODO.md:430）、代理并发上限（TODO.md:502）以及更丰富的 /v1/models 行（TODO.md:503）。
最后的想法
标题说忘掉 Claude Code，但这取决于使用场景和对时间的敏感度。Opus 仍然比它快 2 到 10 倍。我仍然使用 Opus（$20 方案）进行规划和评审，但使用量在下降，我甚至没有达到它的使用上限。现在实际编码在我的笔记本上通过 Flash-Next 完成，除非我想快速完成某件事，我对结果相当满意。
如果你使用的是类似 Strix Halo、DGX Spark 或 Mac 的统一内存机器，可以试试 Flash-Next。寻找适合你 GPU 的最快引擎。在我看来，将云端前沿模型作为编排/规划器，并在本地使用 Flash-Next 进行执行，能够在性能和效率之间取得最佳平衡。如果你用它来处理对时间不太敏感的事情，比如开源软件、测试、基准测试、研究或实验，本地配置可能就足够了。期待 Qwen 4。
如果你喜欢这篇文章，请留下点赞或评论。
你可以在以下平台关注我：Bluesky、 Mastodon 和 LinkedIn。
