我做了一个专门为本地开源模型优化的 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 需要。

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

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

三、现在做了什么

核心功能跑通了。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