8.0
热点
AI SCORE
编程提效2026-08-07 11:14
用4位本地模型远程编排开发任务
dev.to · AI#本地模型#Agent编排#远程开发
Editor brief · 编辑速览
作者让小型4位量化本地模型只负责理解手机端指令、委派给更强的编程Agent并汇报结果，而不承担代码实现。该分层方案让开发任务可在离开电脑时继续推进，并完成多文件修改和测试。
昨晚，我没碰笔记本电脑就提交了一个 PR。6 个 commit、修改了 8 个文件、417 项测试全部通过。整个过程，我一直躺在床上用手机操作。
这并不是一个“本地模型包办所有代码”的故事。这个本地模型很小，经过量化，而且我刻意不让它负责具体实现。它的工作是理解我的需求，把任务交给能力更强的 coding agent，再向我汇报结果。
我想解释这是如何实现的，但在此之前，我想先讲讲为什么要折腾这套系统，因为这个“为什么”决定了整个方案中的每一项选择。
我是一名国际学生，靠兼职工作负担自己的开销。
关于兼职，有件事没人会告诉你：它占用的不只是你上班的那几个小时，还会吃掉上班前和下班后的时间。这些时间被切得太碎，根本不足以开始做一件真正的事。出门前只剩 40 分钟时，你不可能打开项目，把整个项目重新装回脑子里，再做出什么有用的进展。于是，这些时间就这样白白流失了。我的作业和个人项目输给的不是能力问题，而是时间安排问题。
这才是我想解决的问题，不是提高编码速度。我希望自己不在电脑前时，工作依然能够向前推进。
我之前一直被一个假设困住：我以为必须在本地运行一个优秀的 coding model。但学生用的笔记本电脑根本装不下优秀的 coding model。
后来我突然意识到，是我把需求搞错了。本地模型不需要写代码。它只需要理解我在 Discord 消息里提出的要求，选择正确的命令，把任务交给真正能写代码的工具，然后告诉我发生了什么。
理解意图并分发任务，远比亲自实现简单。
一旦把编排和实现拆开，硬件问题基本就消失了。
编排器使用的是 Nous Research 的 Hermes Agent。它采用 MIT License，提供支持 Discord、Telegram、Slack 等平台的消息网关，而且开箱即用地安装了用于把任务委派给 Claude Code 和 OpenCode 的 skills。最后这一点，正是这套方案实际搭建起来远没有听上去那么麻烦的原因。我没有编写任何 glue code。
在一台学生用笔记本电脑上的运行配置如下：
编排模型：Qwen3.6-35B-A3B。这是一个 Mixture-of-Experts 模型，总参数量为 35B，但每个 token 只激活约 3B 参数，这也就是名称中“A3B”的含义。使用 Unsloth GGUF 的 UD-Q4_K_XL 量化版本，通过 LM Studio 提供服务。
机器：RTX 5070 Ti mobile、12GB VRAM、32GB RAM、Core Ultra 9 275HX、Windows
LM Studio：context 设置为模型原生支持的 262,144，使用 FP8 KV cache quantisation，GPU offload 设置为所有层，同时强制将 32 个 expert layer 放在 CPU 上
Hermes 和所有 coding tools：运行在 WSL 中
具体实现：使用配备 Opus 的 Claude Code，或者搭配 DeepSeek V4 Flash NEW 的 OpenCode；后者目前可在 OpenCode Zen 上免费使用
LM Studio 的那项配置看起来自相矛盾，但其实并不冲突。offload 滑块被设置为所有层；与此同时，LM Studio 还可以把指定数量层中的 MoE expert weights 重新放回系统 RAM。需要高带宽的 attention path 仍然留在 GPU 上，而体积庞大的 expert weights 则存放在 32GB 系统内存中。正是这种拆分方式，让一个 35B 模型能够在只有 12GB VRAM 的机器上运行。它确实不快，但分发一条命令本来也不需要多快。
出于同样的架构原因，完整的 262k context 并没有听上去那么吓人。Qwen3.6 是一种混合架构：大多数层使用 Gated DeltaNet linear attention，它维护的是固定大小的状态，而不是一个随着序列长度增长的 KV cache。只有标准 attention layer 才需要按 token 付出缓存成本，因此在长 context 下，它的缓存开销只相当于完全 dense model 所需开销的一小部分。实际使用中，我的编排对话无论如何都远远达不到这个上限。
关于成本，我想说得准确一些，因为那些宣称“完全免费的本地 AI”的文章，通常都通过省略关键信息来误导读者。编排层确实完全免费，运行在我已经拥有的硬件上。真正写代码的那一层才是本该付费的部分，而目前我也没有为它付费：DeepSeek V4 Flash NEW 当前属于 OpenCode Zen 的免费套餐，因此本文中的这个 PR，API 花费是 $0.00。从规划、实现到 6 个 commit，全部包含在内。
这是一个真实数字，不是四舍五入后的结果。但它也是一个推广套餐，不会永远持续下去。更诚实的说法是：其中一部分免费是结构性的，另一部分免费则是暂时的。编排会一直免费，因为它运行在我的硬件上；而具体实现能免费多久，则取决于 Zen 什么时候改变政策。如果你是在几个月后读到这篇文章，请先查看定价，不要想当然地认为这里的成本结构仍然成立。
加载模型，然后进入 developer 选项卡并打开：
Serve on local network (on)
记下它提供的 base URL。大概会是 http://192.168.x.x:1234/v1 这样的形式。
如果你不知道这一点，这一步足以吃掉你整个下午。
LM Studio 运行在 Windows 上，Hermes 则运行在 WSL 中。WSL 使用独立的 network namespace，因此从 WSL 内部访问 localhost:1234，并不能连接到 Windows 主机上的 LM Studio。这就是为什么必须开启“serve on local network”，也解释了为什么 Hermes 应该连接这台机器的 LAN IP，而不是 localhost。
在继续下一步之前，先从 WSL 中检查连接：
curl http://192.168.x.x:1234/v1/models
你应该会收到 JSON 响应，其中包含你的 model ID。如果请求一直挂起，几乎总是因为 Windows Defender Firewall 阻止了这个端口上的入站连接；为 LM Studio 开放 private networks 权限即可。如果连接被直接拒绝，则说明服务器没有运行，或者 IP 地址不正确。
在这一步成功之前，不要继续配置 Discord。还要注意，LAN IP 可能会在 DHCP 续租后发生变化。因此，如果一周后整套系统莫名其妙地失效了，首先检查这里。
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc
hermes setup
hermes model
选择 custom endpoint 或 OpenAI-compatible endpoint，然后填入第 1 步得到的 base URL。运行 hermes 启动 TUI，并发送一条消息，以确认连接是否正常。如果收到了回复，就说明本地模型已经接通，后续所有环节都有了一个能够正常工作的上游基础。
不要跳过这项验证。当你还不确定模型本身能否访问时，调试一个坏掉的 Discord gateway 会困难得多。
npm install -g @anthropic-ai/claude-code
npm i -g opencode-ai@latest
分别完成身份验证。运行一次 claude 进行登录，并针对你要使用的 provider 执行 opencode auth login。然后验证：
claude --version
opencode auth list
还要确保 gh 已经安装并完成登录，因为真正负责创建 PR 的就是它：
gh auth status
这两个 agent 对应的 Hermes skills 都已经打包并默认安装，因此只要这些 CLI 能够正常工作，就没有其他需要配置的地方。
前往 Discord Developer Portal，创建一个 application，然后在其中创建 bot。
在 Privileged Gateway Intents 下启用：
Message Content Intent（必需，否则 bot 收到的消息文本会是空的）
Server Members Intent（必需，用于识别是谁发送了消息）
复制 bot token。它只会显示一次。
使用下面的 URL 邀请 bot，并把其中的 application ID 替换成你自己的：
https://discord.com/oauth2/authorize?client_id=YOUR_APP_ID&scope=bot+applications.commands&permissions=274878286912
然后在 Discord 中开启 Developer Mode（Settings、Advanced），右键单击你自己的用户名，复制 user ID。
hermes gateway setup
选择 Discord，粘贴 token 和你的 user ID。你也可以直接编辑 ~/.hermes/.env：
DISCORD_BOT_TOKEN=your-bot-token
DISCORD_ALLOWED_USERS=your-discord-user-id
hermes gateway
DISCORD_ALLOWED_USERS 不是可选项。较新版本的 Hermes 采用 fail closed 策略，因此没有 allowlist 的 gateway 虽然能够建立连接，却会拒绝所有传入消息。更重要的是，任何能向这个 bot 发送消息的人，都可以针对你的代码仓库执行命令。请把它设置为你自己的 ID，不要添加其他人。
既然已经配置到这里，也值得花两分钟想清楚其余的影响范围。这套系统会把一条聊天消息变成在你机器上执行的 shell commands——这既是它的全部意义，也是它的全部风险：
把 bot token 当作密码对待。如果发生泄露，请在 Developer Portal 中重置它。
chmod 600 ~/.hermes/.env, and never commit it.
让 LM Studio 仅停留在 LAN 内。它没有身份验证机制；不要对它进行 port-forward。
启用 branch protection 并要求通过 CI，这样有问题的 PR 就无法自行合并。
不要把它指向这样的代码仓库：你无法接受 agent 意外接触到其中的凭据。
如果 bot 显示在线，却默默忽略你的消息，十有八九是 Message Content Intent 的问题。回到第 6 步检查。
DISCORD_HOME_CHANNEL=your-channel-id
主动发送的消息会落到这里。一旦你开始使用 cron jobs，或者希望完成通知总能发送到一个固定位置，这项配置就会很重要。
整个循环分为三个节拍：选择一个 issue、拿到计划、交付成果。
开头几秒钟值得留意。Hermes 猜错了 owner，尝试访问 Aegis-MD/Aegis-MD，结果什么也没找到；随后它推断出 repo 实际位于我自己的用户名 PyaesoneP 下，即 PyaesoneP/Aegis-MD，于是继续执行。这就是小模型在猜测我的意图，而这一次它成功纠正了自己。但它并非每次都能做到，这也是下一节大部分内容所讨论的问题。
接着，我让它使用 OpenCode 的 plan mode 处理 issue #44。它把 repo clone 到临时目录中，然后将任务继续向下传递。
返回的计划比我预期得更好。在编写任何代码之前，它就指出了三个会阻塞实现的设计决策，其中包括 year_published 与现有 publication_year 之间的命名冲突，以及 Chroma 是否能够直接存储 list fields 的问题。这些决定需要由我亲自做出。它把这些问题明确提出来，而不是悄悄自行决定，正是让我能够在公交车上审查这个 PR 的关键；否则，我根本无法在那里完成审查。
回答完这些问题后，我让它继续执行。
CI 随后开始运行，我会收到 PR 链接以及已提交内容的摘要。如果想再检查一遍，我会先让它调用 Claude Code，以 print mode 阅读整个 diff，然后我再亲自查看。
从开始规划到创建 PR，这次运行端到端花了大约 40 分钟。我没有一直盯着它。这才是最重要的部分：如果我正在上班，这 40 分钟的实际时间对我而言没有任何成本；如果我坐在电脑前陪它跑，这件事就会占掉我整个晚上的一块完整时间。
这就是完整的工作循环。它可以在公交车上、火车上，以及我的工作休息时间里运行。
有一点需要注意：要完成这些操作，我的笔记本电脑必须保持唤醒。这里没有什么魔法。如果我知道自己出门后还想继续处理工作，就会在离家前让电脑保持运行。否则，Windows 的睡眠设置绝对会毁掉你的整个下午。
4-bit 量化的 Qwen 负责判断我指的是哪个 issue，以及应该向下游传递什么指令。如果它误解了我的意思，系统不会抛出错误。它会自信地分发错误任务，而我直到一个自己从未要求过的 PR 出现时，才会发现问题。一个成本很低的修复办法是：在分发前，让它先复述自己的理解。例如：“准备处理 #44，扩展 chunk metadata，可以开始吗？”多发这一条消息，就能拦住大多数此类错误。使用固定的命令词汇，而不是自由形式的透传，同样会有所帮助。这样一来，解析错误会明确失败，而不是悄无声息地在错误任务上执行成功。
我确实没有在笔记本电脑前坐上几个小时。很好。但依然需要有人阅读一份 +630 / -37 的 diff。而在手机上、公交车上，你做的只是快速浏览，不是真正的代码审查。你必须诚实面对自己现在做的究竟是哪一种。
Claude Code 很擅长发现 diff 内部的不一致之处。但它不太擅长意识到整个实现思路可能从一开始就是错的，因为它读到的也是生成这份代码时所依据的同一套问题框架。应该把 CI 当作真正的门禁。417 项测试全部通过，是比任何模型声称“看起来没问题”都更可靠的信号。开启 branch protection，没有我的参与，任何内容都不能合并。我不会在公交车上合并代码，而是把审查任务留到回到桌前时再处理。
当实现成本趋近于零时，你的上限就取决于 ticket 写得有多好。一个模糊的 issue，现在可以生成一份自信、测试完善、但完全错误的 PR，最后你只能在审查过程中才发现问题。现在，我写 issue 时比以前谨慎得多，这是搭建这套系统之前完全没有预料到的变化。
我的清单包括 migrations、auth、dependency bumps 和 CI config。无论我在公交车上看到的 PR 多么干净，这些任务都会被标记出来，留到我坐在桌前时再处理。这些领域的失败代价太高，无法只靠手机屏幕发现问题。
是否值得搭建这套系统，取决于你的限制条件。与其一味鼓励，我更愿意把适用范围说清楚。
如果你经常离开电脑，却拥有一些零碎时间；有一台内存足以容纳小模型的笔记本电脑；项目中有描述清晰的 issue；并且拥有自己真正信任的测试，那么这套系统值得搭建。这里的每一个条件都很重要。一旦去掉测试，你搭建出来的就只是一台批量生成“看起来很合理的错误”的机器。
如果你本来就整天坐在桌前，它的价值就不大。你只是在自己与原本可以直接使用的工具之间，额外增加一个会丢失信息的翻译层。它也不能让你彻底停止代码审查，更无法拯救一个 issue 模糊、没有 CI 的项目。它只会让这些问题更快地来到你面前。
它实际能做的事情非常具体：把过去那些无处可用的时间——轮班间隙、公交车上的路程、上课前的 20 分钟——变成能够推动某些事情向前进展的时间。对我来说，这就是全部意义所在。我仍在探索还能把它用于哪些任务，而 triage 看起来显然是下一步。如果你也搭建过类似形态的系统，我很想知道它曾经在哪里出过问题。
若要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。