作者 |Tofu
来源 | 至顶AI实验室
本地 AI，开始接手开发者最容易拖延的那些活。
这一次，它不只是坐在聊天框里回答“这段代码怎么写”，而是打开一个项目，读需求、建文件、跑命令、修报错，把一个应用从空目录一步步推到能用。
YouTube 上的 Techno Tim 把两台华硕 Ascent GX10 接进 coding agent 工作流，给它安排了一个任务：做一个 HomeLab 服务追踪器，用来管理 Proxmox、TrueNAS、Grafana、Plex、Pi-hole 这些家庭实验室服务。
它要处理项目初始化、依赖配置、页面交互、数据保存、功能修复和后续 UI 改造。也就是说，它要面对的，正是那些高频出现、技术含金量不一定有多高，但极度消耗精力和耐心的“工程脏活”。
那么问题来了：本地 AI 能搞定这种任务吗？
本地模型要有用，先得能碰到项目
把模型跑起来，只能证明机器的算力。要让本地 AI 真的参与工作，它还要进入开发环境、拿到项目文件、调用终端命令、看到运行结果，再根据错误继续修改。
Tim 搭了一套接近实际开发的链路：模型文件放在 NAS 上，本地 AI 机器通过网络加载模型；vLLM 把模型变成一个本地服务端点；OpenCode 作为 coding agent，拿到项目文件和终端执行能力；开发者继续在自己的 VS Code 里工作，但真正跑模型、执行命令、修改项目的是本地机器。
这套流程看起来有点折腾，却刚好对应 coding agent 的核心能力。模型不能只给建议，它要能看到项目结构，改动文件，运行命令，观察报错，再继续修。
他给 agent 安排的任务也挺复杂：做一个 HomeLab 服务追踪器，用来管理 Proxmox、TrueNAS、Grafana、Plex、Pi-hole 这类家庭实验室服务。需求里包含技术栈、数据模型、测试要求和完成标准，还要求模型先创建 spec、task、agents、progress 文件，再按步骤推进。
一个项目从零开始，往往不只需要写代码，还要处理依赖、配置、接口、测试、状态保存、页面交互和后续修改。coding agent 如果只能生成代码片段，价值很有限；只有能在这些环节之间来回跑，才算真正接近开发工作流。
一台机器能接活，但还需要人带着
第一轮测试只用一台 GX10，模型是 Qwen 3.6 35B A3B FP8。
它确实把应用做出来了。模型会创建待办列表，会生成规划文件，也能开始写代码、跑项目。最后，一个 HomeLab 服务追踪器真的能打开，页面里有服务分类，也有基础管理功能。
就是过程并不丝滑。
模型中途会卡在工具调用里，需要他反复输入 continue 才能继续。初版应用跑起来后，过滤、编辑、保存都有问题。Tim 让它修复这些功能，并要求写回归测试，模型又陷入循环。后来，他明确要求模型先聚焦过滤功能，并让它查看相关文档，模型才找到 search params 的正确用法，把过滤问题修好。
这个结果很接近今天本地 coding agent 的状态。
它能帮你干活，但你没法完全撒手不管。它能理解任务、创建项目、改代码、跑命令，也能在人的提示下修 Bug。只是它还需要人盯着，需要人打断、纠偏、补上下文、做验收……
更准确地说，它像一个执行力不错、经验还不够的初级助理。你给它目标和边界，它可以替你处理一部分重复、琐碎、耗时间的工程活；你把任务丢给它就离开，它大概率会搞砸。
模型变大后，做事方式明显变了
小规模的模型不太行，那么更大的模型呢？在第二轮测试里，Tim 把两台 GX10 连在一起，运行更大的 MiniMax M2.7 AWQ 4-bit 模型。
不过光是搭建的过程就不那么容易。两台机器要通过高速线缆连接，先验证 NCCL 通信，再配置 vLLM 多节点运行。模型文件大小也不是全部压力，真正运行时还要给 KV Cache 留空间。中间经历了版本调整、库编译、容器权限排查等问题，最后通过 privileged 模式，才把速度从 26 到 28 tokens/s 提升到接近 41 tokens/s。
这说明，本地 AI 的门槛已经不只是“装个模型”。模型、服务层、容器、网络、存储、监控、agent 工具，任何一层出问题，都会影响最终体验。
但大模型跑起来后，agent 的表现确实变了。
同样是做 HomeLab 服务追踪器，这次模型没有手写一堆配置文件，而是主动调用 create-next-app，先生成 Next.js 项目脚手架。真实开发者通常也会先用成熟工具搭好项目结构，再进入功能实现。
应用跑起来后，过滤、编辑、删除、新增服务这些核心操作基本可用。刷新页面后，数据也能保持。随后 Tim 继续让它优化 UI，模型引入 DaisyUI，改善按钮、表单、字体、徽章、对话框和空状态，让应用从“能用”变得更像一个可以演示的产品原型。
他还给了一个特别任务：把整个应用改成 Windows XP 桌面风格。模型也真的做出了开始菜单、窗口、状态栏、服务图标和可移动窗口。
这个看起来有点“闹着玩”的任务其实也是一次很好的压力测试。模型需要理解现有项目结构，做大范围视觉改造，还要尽量保持功能可用。它考验的其实就是 agent 能不能围绕一个已有项目持续迭代。
这一轮，agent 少走了很多弯路。它会选工具，会搭框架，会保持功能完整，也能接着做后续改造。硬件让模型跑起来，模型规模影响 agent 的做事质量，工具链决定它能不能真正碰到项目。
至顶AI实验室洞见
本地方案当然不是免费午餐。单台设备价格不低，国内电商平台的售价大约在3万多起售，两台成本直接翻倍，还要额外购买 QSFP 连接线。功耗也要算进去，单机模型驻留时会持续耗电，双机高负载时功耗能到 300W 左右。再加上调环境、看日志、换版本、改容器权限、处理模型加载和网络通信，普通用户很难开箱就用。
至顶 AI 实验室之前也对这款华硕 Ascent GX10 进行过评测，这台机器本身确实很强。单机 128GB 统一内存，已经能支撑不少本地大模型任务；双机、三机互联之后，能力会继续往上走。我们当时做过三机互联测试，通过 ConnectX-7、Ray 集群和 vLLM，把它们串起来运行 2000 亿参数级模型，过程虽然折腾，但最终确实跑通了。这说明 GX10 这类桌面 AI 设备的硬件上限并不低，尤其在多机互联状态下，它已经能摸到过去只有小型 GPU 集群才会讨论的问题。
但强大，不代表它适合每个人。
到了 coding agent 场景里，问题不只是“模型能不能跑起来”，还要看它能不能稳定地跑进你的日常工作流。你要准备模型文件、NAS 存储、vLLM 服务、Docker 环境、远程开发链路、agent 工具，还要处理网络、权限、版本和各种奇怪报错。只要其中一层出问题，AI 就可能卡住，项目也会停在半路。
所以本地 AI 更适合一类明确的人：长期使用 AI 写代码，愿意把模型部署、项目环境和执行链路放在自己手里的人。
这类人面对的任务，往往不够性感，却很耗时间。比如老项目依赖升级、移动应用适配新系统、测试补齐、UI 细节修复、脚本整理、内部工具重构。人当然能做，但很容易拖。coding agent 的价值，恰好在这些地方显现。
你给它一个清晰的目标，它在后台不断尝试、修改、运行、修复；你保留最终判断，负责 review 和验收。云端 agent 已经证明这种工作方式有价值，本地 AI 现在要回答的问题，是这种工作方式能不能长期跑在桌面环境里。
我想，通过 Tim 的测试，我们已经知道答案：可以，但还需要人坐在驾驶位上。
本地 AI 还会卡住，还会犯错，还会误判，也会把环境搞乱。可它已经能打开一个项目，理解需求，修改代码，运行检查，把一个小应用一步步推到可用状态。
它离“放手让 AI 写完项目”还有距离，但离“把一部分工程脏活交给本地机器”已经很近了。
常见问题
Q1：两台华硕 GX10 跑 Coding Agent，最大的变化是什么？
最大的变化不在于模型能不能跑起来，而在于本地 AI 开始进入真实开发流程。它可以通过 vLLM 提供本地模型服务，再由 OpenCode 接入项目和终端，完成读需求、建项目、改代码、跑命令、修 Bug、改 UI 这些动作。也就是说，本地 AI 不再只是回答代码问题，而是开始参与项目推进。
Q2：一台 GX10 和两台 GX10 的体验差别明显吗？
明显。一台 GX10 跑 Qwen 35B 时，已经能把应用做出来，但过程里需要人频繁介入，比如继续执行、补充提示、修正方向。两台 GX10 跑更大的 MiniMax M2.7 后，Agent 的选择更接近真实开发流程，比如会主动用 create-next-app 搭脚手架，功能完成度和后续 UI 迭代也更好。模型变大之后，少走弯路这件事会变得很直观。
Q3：本地 Coding Agent 适合普通开发者买吗？
要看使用频率和“折腾”的意愿。它适合长期使用 AI 写代码、愿意部署本地模型、能处理 Docker、vLLM、网络、权限和日志问题的人。它可以承担老项目升级、测试补齐、UI 修复、内部工具开发这类长期被拖延的工程活。但如果只是偶尔让 AI 写几段代码，云端 Agent 依然更省心。
