We 成为 AI 产业观察信号

2026年6月将被记为人们意识到闭源模型也会被拿走的那个时刻。随着 Anthropic 最新旗舰模型 Claude Fable 5 被移除的消息仍历历在目，人们不难理解，为什么拥有自己的 AI 技术栈、并且能够在本地运行模型，比以往任何时候都更重要，尤其当你是把业务建立在 AI 之上的时候。

在这样的背景下，我们想分享一下，自己是如何在 agent harness 中使用 Gemma 和 Qwen 这类本地模型来执行分类任务 [1] 的。这种做法不同于把 BERT 这类模型直接用于分类。本地模型在像 Pi 这样的 agent harness 中，可以与结构化输出结合使用，用来分配标签。我们选择这种方式，是因为手头已经有本地模型和 harness，而且我们也坚信，随着本地模型能力不断提升，类似的方案会越来越受欢迎。[2]

我们的起点是 OpenClaw 仓库中的开源贡献。OpenClaw 每天都会收到数百个 issue 和 PR，需要进行分流、优先级排序，并路由给维护者。Onur 正在努力让本地模型在 OpenClaw 上表现良好。作为这个特定垂直领域的维护者，我需要对任何 P0 问题迅速作出响应。

如果使用 GPT-5、Opus 或 Sonnet 这类 SOTA 闭源模型，这其实是个相当直接的任务。但我手头恰好有 128 GB 统一内存，也就是一台 NVIDIA GB10。所以我接下了这个任务：

我能不能用本地开源权重模型，搭建一个实时通知系统，只筛选并通知我负责的那些问题……？

如果我让 OpenClaw 的主智能体跑在每月 200 美元的 ChatGPT Pro 方案上，并在每个新 issue 或 PR 出现时触发一次任务，那很快就会把额度用光。于是我也许会改成每 2 小时，或者每 6 小时运行一次。这样就会把 issue 按更长时间窗口批量处理，相当于用实时通知换取延迟处理。

如果我把它部署在一台已经在运行的本地模型上，利用我现成的硬件来跑，我不仅能获得近乎即时的通知，还能免费完成这件事（更准确地说，只需支付电费）。

我们先确定了一组有限的标签，用来表示需要分流处理的问题类别，然后用本地模型把每个 issue 归类到这些类别中的某一个，例如 local_models、self_hosted_inference、acp、agent_runtime、codex、ui_tui 等等。[3]

但我们该怎么给 pull request 分类？是不是只要对 Chat Completions 端点发一个简单的单次请求，带上一个工具的 JSON schema，再把主题做成一个枚举就行？

某种程度上是。但现在是 2026 年，不是 2023 年，而且我们有 AGENTS。我们可以做得更好！

对于本地模型的选择，我们测试了 `gemma-4-26b-a4b` 和 `qwen3.6-35b-a3b`。经过性能优化后，这两者都能在本地每秒生成数百个 token。

我们使用一个 agent harness 来驱动分类运行。为此，我们把 `pi` 打包成一个 harness，它可以调用本地模型端点。

默认情况下，agent 在第一轮提示中会收到 PR 的标题、正文以及一段截断后的 PR diff 摘录。随后，它可以选择使用 bash 工具，对 OpenClaw 仓库执行只读操作（如果它需要查看代码库），或者使用 final_json 工具提交最终的分类结果。

在这种高吞吐场景下，你不会希望把完整的 bash 访问权限交给本地模型，因为一旦出现 prompt injection 的 issue 或 PR，就可能把模型引导到与分类无关的操作上。

因此，我们使用 reposhell 而不是 bash：这是一个受限的、类似 bash 的 shell，只允许对 OpenClaw 仓库执行只读操作（如 ls、find、cat、grep 等）。模型以为自己在使用 bash，但任何不被允许的操作都会被拒绝：

这里有一个具体例子可以说明这一点。在某个已保存的 session 示例中，qwen3.6-35b-a3b 正在为 openclaw/openclaw#84621 做分类，标题是 Fix Kimi tool-call rewriting stop reason handling。思考块显示，模型最初考虑的是 coding_agent_integrations，因为变更路径 extensions/kimi-coding 看起来很像。模型随后使用 reposhell，通过一些简单的只读命令检查本地仓库，例如 ls extensions、ls extensions/kimi-coding 和 cat extensions/kimi-coding/package.json。package 元数据表明，这个扩展实际上是 @openclaw/kimi-provider，一个 OpenClaw 的 Kimi provider 插件。于是模型把最终标签修正为 inference_api 和 tool_calling，并明确排除了 coding_agent_integrations。

我们前面提到过，我们打包了一个特定的 pi 配置，它只能执行只读操作并返回分类结果。我们把它称为 `localpager-agent`，名字来自这里的主项目 `localpager`。每个 PR 和 issue 都会生成一段 prompt，然后像下面这样连同其他参数一起传给 CLI：

那么，在传入的 PR/issue 和最终在 Discord 上发出的通知之间，究竟是谁在协调这一切？

这一部分的编排非常简单；只有分类步骤会用到 LLM：

我们使用 `openclaw/gitcrawl` 作为仓库的本地镜像。每当有新的 PR 或 issue 时，每个条目都会被归一化为相同的结构，并写入 `localpager` 自己的 SQLite 数据库。如果该条目是新的，`localpager` 就会为它创建一个分类任务。

随后，一个 worker 会从该队列中认领任务。它会构建一个 GitHub 上下文对象，其中包含 issue 或 PR 的标题、正文、标签、作者、状态，并可选地包含评论、变更文件以及选取的 diff 片段。这意味着，本地模型在大多数时候不需要自己浏览 GitHub 或打开对应 URL；系统会把所有相关上下文直接交给它。

该上下文对象会被渲染成 prompt，并按照上一节所述传递给 localpager-agent。这个 agent 可以思考并使用 reposhell，但最终必须以定义好的 schema 输出分类结果。

输出结果会重新写回 localpager SQLite database，并根据用户配置的通知策略转发到 Discord（也就是：这些主题提醒我，但那些主题不要提醒我）。

下图展示了 localpager 的整体架构：

这个架构是半代理式的。标签由 agent 方式完成，而发送通知则由确定性规则处理。这样做是为了去掉最直接任务部分的推理需求，从而让通知流水线更快。本地推理是免费的，但每个任务都会带来资源争用成本：GPU 带宽应该留给那些确实需要推理的任务。这也降低了通知出错的可能性。

坦白说：这个系统最初的本地版本噪音很大。我们测试的第一个模型——gemma-4-e4b-it——对打通端到端本地流水线很有帮助，但它也倾向于给一个 PR 或 issue 打上太多不相关的标签。误报标签会让 Discord 信息流变得嘈杂，也无法把我的注意力聚焦到真正重要的问题上。这促使我们转而测试更大的本地模型，包括 gemma-4-26b-a4b 和 qwen3.6-35b-a3b，并在下面这个 330 行的评测集上进行验证。

在早期的提示词工作中，我们还通过 antirez 的 DS4 实现 [4] 使用 DeepSeek-V4-Flash 来生成更早期的数据集标签。那套方案通过 CUDA 使用 DS4 服务器。我们最终放弃让 DS4 作为标注器，因为它在不同运行之间的标注不一致。我们也没有把它视为 localpager-agent 的主力本地模型，因为它体积太大，无法在我们的硬件上获得足够的吞吐量：DS4 服务器的速度大约只有每秒 14 个 token，最大并发为 1。

为了测试模型性能，我们选取了 330 个 GitHub issue 和 PR，并为它们生成标签。每一项都标注了五次（3 次 GPT-5.5 和 2 次 Opus 4.8），只有模型之间达成一致时才接受结果。这个过程包括人工裁决、完善标签定义，以及向模型说明内部产品设计选择。这让我们得到了一套稳定、可复现的标签，用来和更小的模型进行比较。

我们在得到这组评测的有效结果之前，并不需要对 gemma-4-26b-a4b 或 qwen3.6-35b-a3b 做提示词优化。沿用同一套路由提示词时，Gemma 的召回率更高、每行耗时更低；而 Qwen 的精确率、更高的 exact match 以及更少的 false positives 表现更好。我们还把 DeepSeek-V4-Flash 作为参考跑了同一组数据。它的 false positives 最少，但模型规模和吞吐量使其不适合在 NVIDIA GB10 上实时执行这些任务。由于每一行可能包含多个标签，false positives 和 false negatives 统计的是所有行上的标签总数。下面的 Qwen 结果，是在重试结构化输出失败之后得到的；当模型在调用 `final_json` 之前就耗尽输出 token 时，我们会进行重试。对于 Gemma 和 Qwen，重复运行的指标报告的是三次运行的均值 ± 样本标准差。DeepSeek-V4-Flash 只运行了一次，作为参考。

这里的吞吐量和 wall-clock 数字，并不是这些模型在这套硬件上的绝对最高性能。它们只是我们在当时使用可用优化后得到的配置。例如，在另一个探测中，gemma-4-26b-a4b 还支持 concurrency 32，并且达到超过 700 的 aggregate output tokens per second。

在 Gemma 基准测试中，我们使用 vLLM 提供 gemma-4-26b-a4b，并采用了这套环境下我们能找到的优化。其中很大一部分来自 NVFP4 量化：在 GB10 级别的 Blackwell 硬件上，它不仅仅是更小的模型文件格式，而且是一种更适合硬件的格式，相比 Q4_K_M 这类可移植的 GGUF 量化，能更直接地使用 NVIDIA/vLLM 执行路径。实际效果就是更少的内存流量，以及更多用于 batching 的空间。我们还启用了 prefix caching、FP8 KV cache、CUTLASS MoE backend 和 language-model-only mode。完整的 330 行运行在 concurrency 16 下大约用了 7.5 分钟完成。

我们前面已经提到，与其针对每个新的 issue 或 PR 都运行一次本地模型作业，不如每隔 n 小时（例如每 2 小时）用一个 SOTA 云端模型跑一批作业，比如在 OpenClaw 中运行的 GPT-5.5，来达到同样的效果。[5]

在这种情况下，我们就需要一个 ChatGPT Pro 方案。由于模型本身是 SOTA，即使把 2 小时内的 issues/PRs 打包在一起，我们仍然可以预期它表现得相当不错。

因为我们想看看本地分类器相对于 GPT-5.5 的表现如何，所以我们让两者同时运行，并让 GPT-5.5 每 2 小时判断一次 false positives 和 negatives。

为安全起见，我们把 OpenClaw 作业运行在一个沙箱中，并且只允许它访问我们要向其汇报结果的公开仓库。在我们的场景里，我们让 OpenClaw 作业更新一个机器可读文件，然后由一个简单脚本读取 Codex 分配的标签，并计算 false positive/negative 状态。示例输出：

问题 #88499 openai-responses 提供方：在 store=false（默认）时，previous_response_id 返回 404

库存区域：OpenAI 兼容/代理；通知主题：agent_runtime、api_surface、sessions；通知：无

PR #88275 修复(models-config)：允许 self-hosted 提供方在 models.json 中不提供 apiKey（#88267）

通知关注：i0；主题：self_hosted_inference、local_model_providers、config；通知：已发送

PR #88266 重构：抽取模型目录核心包

通知器关注度：i1；主题：config、API surface、本地模型提供方；已发送通知

PR #88247 新功能：新增托管模型提供方

通知器关注度：i0；主题：本地模型提供方、模型服务、文档、API surface；已发送通知

关于如何分类、如何编辑这个机器可读文件、以及如何借助脚本统计误报和漏报的说明，都写在一个 agent skill 里；该 skill 又被一个每 2 小时运行一次的 OpenClaw cron job 引用。随后，OpenClaw agent 会摄取新增的 issue 或 PR，将它们连同相应标签一起写入 JSON 文件，运行这些脚本，并在同一个 Discord 频道里回报结果。这样一来，我们就能每隔几小时观察本地模型的表现，并收到遗漏项的通知。

我们认为，issue/PR 分流任务是一个更广泛任务集合中的特例，我们把这类任务称为“高吞吐量分流”。这篇文章探讨了只在一个领域中使用本地模型进行实时信息过滤的想法，也就是开源贡献。像 gemma-4-26b-a4b 和 qwen3.6-35b-a3b 这样的中等规模本地模型，能够在无需微调的情况下，以较高准确率完成零样本分类，这使它们在进一步转向更具成本效率的传统分类器模型之前，成为快速原型验证的不错首选。

不过，同样的方法也可以应用到其他领域：

新闻分类（新闻业）

在 X 或 Reddit 等社交媒体和论坛中筛选感兴趣的帖子

对客户支持工单进行分流

对内容审核申诉进行分流

在做销售时筛选潜在外联对象

在做研究时，对 arXiv 上特定主题进行筛选

这个列表还可以继续扩展，不过我们认为这个思路已经足够清楚了。

除了分流处理之外，我们还探索了如何借助 agent harness，在安全的前提下运行快速的本地模型来完成分类。更合适的命名可能是 agentic classification：模型不会一开始就接收全部信息，而是可以在返回结构化数据之前先搜索更多上下文。虽然我们不能把这准确地称为一种新方法，但我们希望这篇博客能成为 Pi +受限 shell+ final_json 这一特定配方的一个有用参考。

在本文的用例中，我们发现，要把一个 PR/Issue 拆解到足以让产品表面被正确理解和标注，这其实是一个很难的问题。back

尽管在我们的测试中并没有这样做——模型完全合理地可以得出下一步应先收集信息、再使用外部分类器这一结论。agentic 方法和传统方法并不互斥。

完整的主题列表和其他配置见此处。

我们使用的是 antirez/deepseek-v4-gguf 中的 DeepSeek-V4-Flash-IQ2XXS-w2Q2K-AProjQ8-SExpQ8-OutQ8-chat-v2.gguf。

我们知道，把 LLM 用作裁判会抵消“免费”这一点，不过我们这里的具体实现是出于研究目的。实际应用中，可以在试用期内让更大、更昂贵的模型与之配合使用，作为校准手段，之后系统就会完全切换到更小的模型。最近几次运行中，这个审计循环每次 2 小时检查大约总共使用 4 万个 GPT-5.5 token，其中大部分是缓存上下文，按 API 定价每次成本约 2 到 3 美分，或者按每天 12 次运行计算，每月大约 9 美元。这是针对所有新条目的一次性批量审计，不是对每个条目分别调用一次裁判；如果按条目逐个执行，成本很可能会高出数倍。

· 注册或登录后发表评论