本地 Coding Agent 的关键，不是模型多快，而是整条 Stack 是否可控

本地 coding agent 真正进入可用区间后，讨论重点已经从“能不能跑”变成“该怎么跑”。Sebastian Raschka 的本地编码代理教程之所以值得看，不是因为它宣布可以抛弃云端工具，而是因为它把模型、推理运行时、agent harness 三层拆开评估。

这三层经常被混在一起。模型负责推理，运行时负责把模型高效跑在硬件上，harness 负责读文件、改文件、调用 shell、维护上下文和审批。实际体验差异，往往出在 harness，而不只出在模型。

同一个模型，放进不同 harness，成本会变

Raschka 的测试里，同一个本地模型在 Codex CLI、Qwen-Code、Claude Code 等 harness 下表现不同。更关键的是 token 消耗不同。某些 harness 为了稳妥，会反复塞入历史对话、工具输出和文件内容；这在云端 API 里表现为账单，在本地推理里表现为时间。

本地模型不是免费无限快。上下文越长，KV cache 越大，prefill 越慢。一个 harness 如果用两倍 token，同样会让本地工作流慢下来。

30B MoE 是当前甜蜜点之一

30B 级 MoE 编码模型的意义在于：总参数提供知识容量，活跃参数控制推理成本。像 Qwen 35B-A3B、North Mini Code、Nemotron Nano 这类模型，已经让本地编码从玩具演示进入日常辅助区间。

但“小模型快”并不等于适合 agent。不会稳定调用工具、无法保持上下文、容易陷入循环的模型，再快也只能做补全，不能可靠接管任务。

隐私不是自动成立的

本地运行模型，只说明权重推理在本地。harness 是否上传遥测、是否自动更新、是否继承 shell 环境里的 secret、是否能访问整个文件系统，都需要单独审计。否则所谓本地，只是把模型换到了本地，控制权并没有真正回来。

实用部署建议

把模型、运行时、harness 分开测试，不要一次性评价“本地 AI 好不好”。
用长上下文 benchmark，不要只测 4k prompt。
记录 token 消耗、任务通过率、工具调用失败率和总耗时。
在隔离用户、容器或 VM 里运行新的 agent。
关闭不需要的遥测、自动更新和外部 trace。
敏感项目先从只读审查任务开始，再放开写权限。

结论

本地 coding agent 不会立刻替代顶级云端模型，但它已经成为一个现实选项：适合敏感代码、固定预算、高频迭代、离线环境和希望掌握工具链的人。真正的判断标准，不是某个模型跑出多少 tok/s，而是整条 stack 在你的项目里能否稳定、可控、可审计。