能一起给本地部署的开源模型做个适配的 coding agent 吗？我憋了口气

[KaiWuBOSS]

我做了一个专门为本地开源模型优化的 Coding Agent ，希望更多华人开发者一起来搞

本贴发布的目的不是推产品，不是炫技，而是想扬眉吐气——和华人开发者一起，和开源模型本地部署开发者一起，做一件我们自己的事。

---

一、我遇到了什么问题

去年开始用本地模型做编程辅助。原因很简单：公司代码不能传到海外服务器，Claude Code 和 Cursor 走不通。

但更大的问题是：中国开发者根本没有一个好用的本地 coding agent 平台。

CC 需要翻墙，还要订阅。Cursor 同样。Codex 刚出来也是海外服务。Hermes 这类开源工具不支持 Windows 原生运行，要装 WSL2 ，劝退了大多数国内开发者。最后大家的选择是：要么翻墙凑合用，要么忍着不用。

这是一个真实存在的空缺，没有人填。

本地跑 qwen3:8b ，然后发现问题一个接一个：

🔴 无限循环，像卡带一样

这是本地小模型最让人抓狂的问题。遇到它不会处理的场景，它不会说"我不知道"，而是开始重复——同一句话说三遍，同一个错误的修改建议循环出现，同一段代码反复生成。整个任务卡死，只能手动强制退出。这不是偶发现象，是小模型在推理能力不足时的典型崩溃模式。

🔴 修 bug 反复踩同一个坑

让它修一个函数，第一次失败，第二次用完全一样的方式再试，第三次依然。三次机会全浪费在同一个错误上，什么都没推进。

🔴 模型能力本身就弱于 API 模型

这是无法回避的现实。8B 、14B 的参数量，推理能力和 Claude Opus 、GPT-4 差距明显。让一个 8B 模型扛下一个复杂任务的全部推理，成功率很低，这不是哪个工具的问题，是模型本身的边界。

🔴 找不到要改的文件

项目大了之后，模型根本不知道要改哪个文件。让它找 bug ，它要么猜错，要么说"我需要看更多代码"，然后把整个项目塞进 context ，然后 context 又爆了。

🔴 对话几轮就开始遗忘

8B 模型 context 窗口只有 8K ，对话多了就满了，模型开始给出驴唇不对马嘴的回答。

---

这些问题叠在一起，用本地模型做开发辅助的体验极差。

所以我想自己做一个产品来跑。有人就会说：为什么不直接用 ollama + cc ？还友情指导我命令。

哎。

大厂的产品只会为它的商业模式服务。ollama 放弃了参数微调来换取稳定，lm 让开发者纠结什么是最优，CC/Codex/Cursor 都是卖 token ，没有人会真的认真想本地部署缺什么，需要优化什么，记忆怎么优化，上下文怎么压缩，小参数怎么辅助。

但我人微言轻，所以我做了个 MVP 想抛砖引玉。我们可以一起把要优化的都优化了，打造我们自己的产品。

有人也说，我能力不够。

那我的思路是：不够就做整合，够了就做突破。

所以我做了 KWCode ，不是为了商业化，MIT 任何人都能拿走，只希望哪个感兴趣的大神，愿意和我或者和所有开发者一起把它实现并开源，给所有被本地部署膈应的宝子们。

---

二、我用了哪些思路

思路一：MoE 架构——让 LLM 只做它擅长的那一步

这是 KWCode 最核心的设计决策，也是解决上面所有问题的根本思路。

传统 coding agent 的架构是：一个 LLM 扛全部——理解需求、定位代码、生成修改、验证结果，全让同一个模型做。强模型能扛，小模型扛不住，然后就开始循环、幻觉、乱说。

KWCode 用的是 MoE （ Mixture of Experts ）架构：把任务切碎，每个专家只做一件事，LLM 只负责 Gate 分类和内容生成，其他步骤能不调 LLM 就不调。

用户输入
  └─► Gate （ LLM 做一次分类，判断任务类型）
        └─► Locator （ BM25 + 调用图，不调 LLM ，毫秒级定位文件和函数）
              └─► Generator （ LLM 只写需要修改的那几行代码）
                    └─► Verifier （自动跑语法检查 + pytest ，不调 LLM ）
                          └─► SearchAugmentor （两次失败后自动搜索）

LLM 在这条流水线里的任务被压到了最小：Gate 做一次分类，Generator 生成几行代码。定位文件、验证结果这两件最耗推理能力的事，完全不让 LLM 做。

参考：Agentless 论文（ ICSE 2025 ）——确定性流水线在 SWE-bench 上同时达到最高通过率和最低成本，优于让 LLM 自主决策的复杂 agent 。原因很简单：每一步 scope 极小，小模型在小 scope 里表现稳定。

---

思路二：用调用图定位代码，不靠 LLM 猜

代码定位是小模型最容易失败的步骤，把它从 LLM 手里拿走，换成确定性算法。

CodeCompass （ arXiv:2602.20048 ，2026 年）做了 258 次实验，发现了一个关键结论：

真实项目里，很多 bug 的根因文件名和错误描述毫无关联，只能通过调用链追踪才能找到。对这类"隐藏依赖"任务，BM25 关键词搜索准确率只有 **76.2%**，而图遍历达到 **99.4%**，差了 23 个百分点。

KWCode 的两阶段检索：

1. BM25 关键词召回（毫秒级，不调 LLM ）：从代码库所有函数/类中，快速召回 top-20 候选
2. AST 调用图展开（毫秒级，不调 LLM ）：对每个候选函数，沿调用图向上向下各展开 2 跳，发现隐藏依赖

整个过程不调 LLM ，SQLite 持久化调用图，重启不重建。

技术栈：tree-sitter + rank-bm25 + SQLite。不需要 Neo4j ，不需要 embedding 模型，不需要额外 Docker 。

---

思路三：打破循环——失败时强制换策略

针对"反复踩同一个坑"和"无限循环"这两个问题：

反无限循环：MAX_RETRIES 硬编码为 3 ，没有任何路径能绕过。同时检测连续两次生成完全相同的 patch ，直接跳过不重试，告诉用户"模型卡住了，建议缩小任务范围"。

反重复失败：三次重试强制用三种不同的问题表述：

第几次	策略
第一次	正常描述需求
第二次	从错误信息出发："直接修复这个报错，不要解释"
第三次	最小化修改："只改这一个函数，其他代码一行不动"

第一次失败后先做 Reflection：让 LLM 一句话分析上次失败的原因，然后把这个分析注入下次的 prompt 。不是让模型自由发挥，是强制它先诊断再修。

---

思路四：专家飞轮，越用越懂你的项目

参考：EE-MCP （ NeurIPS 2025 ）——从任务执行轨迹自动提取经验，验证可显著提升后续同类任务成功率。

KWCode 预置了 15 个专家（ BugFix 、TestGen 、SpringBoot 、FastAPI 等），每个专家有独立的 system prompt 。

同类任务成功 5 次之后，飞轮自动分析轨迹，生成新专家，经过三道验证门后投产：

• 回测门：新专家成功率必须 ≥ 原流水线
• AB 测试门：10 次真实对比，提升超过 10% 才投产
• 生命周期：new → mature → declining → archived ，自动淘汰变差的专家

专家可以导出成 .kwx 文件，kwcode expert install URL 一行安装别人分享的专家。

---

思路五：模型能力自适应

CC 不需要考虑这个，因为它只用一个模型。KWCode 需要。

自动检测当前模型的参数量，然后应用不同策略：

模型规模	自动策略
< 10B （ qwen3:8b ）	强制计划确认 · 任务范围限 2 个文件 · 第 1 次失败触发搜索
10-30B （ qwen3:14b ）	可选计划 · 4 个文件范围 · 第 2 次失败触发搜索
> 30B （ qwen3:72b ）	宽松策略 · 8 个文件 · 自动处理复杂任务

切换模型，策略自动切换。

---

三、现在做了什么

核心功能跑通了。282/282 单元测试通过，E2E 验收通过率 87%（ 26/30 ，4 个失败是模型能力边界，不是框架问题）。

代码能力

• BM25 + AST 调用图两阶段定位，G3 隐藏依赖准确率 99.4%（论文验证）
• 三阶段重试 + Reflection ，不重复同样的错
• 专家飞轮三道门（轨迹 → 模式 → AB 测试 → 投产）
• 15 个预置专家（通用 + SpringBoot / MyBatis / FastAPI / UniApp 等）
• Office 文档生成（ Excel / PPT / Word ，有样式不是白底）

工程能力

• KWCODE.md 项目规则文件，按任务类型分段注入，永远不忘
• /plan 计划模式 + 风险评估（ High/Medium/Low ，基于历史失败记录）
• Checkpoint 文件快照，失败一键还原
• 非代码文件读取（ PDF / Word / Markdown ，BM25 段落匹配注入）
• 搜索增强（ SearXNG 自部署 + DDG fallback ，四级内容提取）

体验

• Windows cmd/PowerShell 原生支持，不需要 WSL2
• 首次引导（ API 配置 + 连通性验证）
• 执行过程只显示 spinner ，完成后输出用户可读的结果摘要
• 支持任何 OpenAI 兼容 API （本地 Ollama / DeepSeek / 硅基流动等）

---

四、还差什么

说实话，有些地方还挺粗糙的：

• AST 调用图目前只完整支持 Python ，其他语言调用图准确率还没有充分验证
• 专家飞轮的 Gate 2 回测逻辑偏简单，还不够严格
• Windows 上的各种边界情况（ AMD 显卡、部分 Ollama 版本兼容性、中文路径）没有充分测试
• 钉钉/飞书 webhook 没做，手机发消息触发 agent 这个场景设计了但没实现
• 没有 IDE 插件，目前只有 CLI
• Prompt Optimizer （用 Opus API 自动迭代优化专家 prompt ）只做了框架，没有跑起来

---

五、为什么想让更多人一起做

我一个人做这个工具有明显的上限，不是技术上的上限，是视野上的上限。

我自己主要用 Python 和 FastAPI ，所以这方面想得细。但我不知道每天写 Spring Boot 的人最痛的点在哪，不知道搞 Rust 的人在本地模型上遇到什么问题，不知道做小程序的人需要什么。

更重要的是，这件事不应该只是一个人的工具，应该是中国开发者社区的工具。

CC 是 Anthropic 的，Cursor 是美国公司的，Hermes 是外国社区做的。我们用的工具，我们的使用习惯、技术栈偏好、本地化需求，从来都是别人顺手加进去的功能，不是第一优先级。

我想做的是反过来——把中国开发者的需求放在第一位，把本地开源模型的适配放在第一位，然后把这个工具做到能和大厂产品掰手腕。

这件事一个人做不到，但开源社区可以。

Linux 打败了 Unix ，不是因为某一个天才，而是全球开发者共同维护了几十年。VSCode 能超过那么多商业 IDE ，也是因为背后有庞大的插件和贡献生态。

KWCode 不需要你有多高的水平，只需要你在用本地模型做开发，然后把你遇到的问题、你的解法、你的改进贡献进来。多一个人，就多一个使用场景被照顾到，多一个坑被填掉。

Fork 这个项目，改进你最痛的那个点，提 PR ，我们互相借力，一起把它做好。

闭源大厂有钱有人有算力，我们有什么？我们有真实的使用场景，有对本地部署的真实需求，有不依赖海外服务的动力。这已经足够了。

---

六、怎么参与

项目地址：github.com/val1813/kwcode

# Fork 项目，克隆到本地
git clone https://github.com/your-fork/kwcode.git
cd kwcode

# 安装开发版
pip install -e ".[dev]"

# 运行测试确认环境正常
python -m pytest kaiwu/tests/ -v

# 找一个你最想改的地方，开始动手
git checkout -b fix/your-improvement

改什么都可以：

• 你每天用 Go 写代码，觉得 Go 的 AST 调用图支持不够好，就去改它
• 你在用 Qwen3 发现某个场景总是触发无限循环，就去修它
• 你有更好的 context 压缩算法，就替换掉现有的
• 你发现 README 写错了，改一个字也算

Issues 里列了已知问题和规划中的功能，可以从那里找方向。Discussions 里可以聊技术思路，聊某个方向值不值得做。

没有什么贡献太小。

---

七、最后说一句

我不知道 KWCode 能不能真的超越 CC 或者 Hermes 。

但我知道，如果中国开发者一直用别人做的工具，一直把自己的需求当作"次要功能"等别人来实现，这件事永远不会有答案。

有些东西，只有自己做才知道能不能做到。

项目是 MIT 开源的，你贡献的代码永远是你的。如果 KWCode 最后做成了，这件事是所有参与的人一起做成的。

---

项目地址：github.com/val1813/kwcode

天工开物 · KWCode · 中国开发者自己的本地 Coding Agent

[KaiWuBOSS]

抖音被群嘲了 不知道真懂假懂 问我为啥不用 ollama+cc 问我电费不要钱 告诉我最差的闭源都比 30b 最好开源好

[aceboy]

目前主要问题是本地开源部署的模型太弱，但是，未来身份验证一定越来越严格，无论中外。因为 ai 智能后面是算力是能源支撑的巨量消耗，不是边际成本为零的传统软件。势必分层，出现阶级属性，成为一部分人压迫另一部分人的工具之一。那么本地开源模型及智能体可能是唯一选择，使用者越多就越有发展潜力。

[Tink]

这真的是个大工程啊佬

我能力不够，但是我 respect🫡，期待能用上本地模型来 coding

[zhanying]

@KaiWuBOSS 30b 做做 rag 算了，做 Agent 还是想到了

[KaiWuBOSS]

@aceboy 所以国际共产主义要求我们 必须一起去突破

[zhanying]

@zhanying 想到了 -> 想多了

[wxyoux2]

大佬牛逼，我也一样，公司不让用外部大模型，但是内部的模型又不行，刚部署上一个本地小模型

[purerain]

放弃本地吧，agent 要模型能力支持的，本地只能玩玩 4bit chat ，真干活至少 FP8 版本起步，能玩得起的没几个。

[KaiWuBOSS]

@zhanying 确实现在 30b 还不行 如果未来 100b 模型可能在 5060 部署了呢 如果不久我们发现 30b 模型够了能各方面超越 opus 呢？我们依然被他们牵着。大厂在争抢更好的模型，开发者继续被折腾。我不喜欢这样，但我又无能为力，这是我为什么要发起这件事的原因。

[KaiWuBOSS]

@purerain 可是差距越来越小了不是吗？现在也许不行，但很快了，你难道不感觉吗？昨天有个抖音吹牛逼说 8g 显存部署了 100b 模型。

[ChicVoice]

搞个 trae 不香吗

[KaiWuBOSS]

如果没人一起搞我就自己干了 反正 tok 开发那些无聊的 skill 也是浪费 认真深耕这套产品

[KaiWuBOSS]

@ChicVoice 你应该问 ollama+cc 不香吗？

[kennylam777]

Roo code 也不做了, 你現在才開始?
同類型的還有 OpenCode 在做, 中國模型也有首輪適配的, 這輪子不要自己造吧。

不過我建議你用 claude code 配 local model 試試看, llama.cpp 支援 Anthropic API
https://huggingface.co/blog/ggml-org/anthropic-messages-api-in-llamacpp

只要設定好兩個環境變數就能用 claude code, 不用 login 也不怕被 ban
ANTHROPIC_BASE_URL=http://127.0.0.1:8080 claude
ANTHROPIC_AUTH_TOKEN=local

[zhanying]

@KaiWuBOSS 5060 肯定部署不了 100b ，你不如期待下国产版 mac studio ，来个 512G 的统一内存

[suiterchik]

已 fork ，后面看看有没有能帮上忙的 🫡

[KaiWuBOSS]

@kennylam777 1 、这几个我都看了 但他是标准的通用型 coding agent 不是专门为本地部署优化的 采用都是串行的 llm 解决思路 意思就是靠主模型强大能力去做任务 框架只做约束和规范。 但本地模型参数小干不了 2 你这句话很像我刚说的 ollama+cc 都不用你这么麻烦 你装了 ollama 再装 claude code 然后 ollama 有命令直接接入 claude 。

[KaiWuBOSS]

@suiterchik 谢谢哥

[xzcv]

opencode 不是可以吗？

[KaiWuBOSS]

@zhanying 以前有个人跟我说过一个笑话 说手机怎么可能拍照 手机要是能拍照 那得设计得很厚 装得下镜头和底片

[KaiWuBOSS]

@xzcv 我说下技术不同，opencode 和 cc 一样的思路，是 llm 做功的串行框架，就是自然语言给 llm llm 去调用各种工具去实现。这个技术对本地低参数模型并不友好。因为他没那么大能力去实现多参数多文件的处理。所以我用了 moe 框架，llm 只需要控制 gate 然后分配专家去干活 ，不需要他亲自去解题，我不知道这么说能不能听懂。

[kennylam777]

喔我看懂了, 思路是把問題切小, 讓小模型能處理, 一步一步來能讓自我修復

的確, 即使是 Cluade Code 的 context management 比 OpenCode 還是強太多, 以前用 Roo Code 在 4090 上跑 local LLM 基本上 tool calling fail 是基本, 現在用 Qwen3.6 + 5090 會好一點但還是有差

我也來試試用看

[CuteGirl]

点了个 star 加油

[sampeng]

当我看到 5060 部署 100b 我就乐了。。so 。。你认识后面那个 b 代表什么意思么？

[int0x03]

公司能用 Claude code + sonnet 4.6, 4.5. 还有公司本地部署的 GLM 4.7, Minmax 2.*. 如果能用 sonnet 没人用 GLM 和 Minmax, 没有对比就没有伤害.

我今天在一个项目上尝试使用 Claude code + 本地 Qwen3.5 30B 模型(M4 64G MAC pro 上), 能干活, 但是干的不好, 理解能力和整个过程都欠缺. 相同的问题, 扔给 Sonnet 4.6 又快又好.

模型真的很重要, 当然配合它自己的 本地 Agent 也很重要.

------------------
我想说的是: 我们还是需要最好的模型, 比如 Deepseek v4, 虽然我还没用上. 模型带来的能力让很多我们期望的 agent 框架的工作很苍白.

如果愿景变成超越 opencode, 简介可靠,自主可控, 是不是更好呢? 不知道.

-----------------
加油 ⛽️

[KaiWuBOSS]

@kennylam777 我本来想了个天才点子 能彻底解决小模型能力不足问题 就是搞不定的问题上网搜答案 我现在 opus 修不了的我就让他上网搜 一搜就有方案了 但我搭建的搜索引擎太拉胯了 优化不够