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

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

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

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

https://github.com/val1813/kwcode 仓库已上传

@kevan 现有版本支持 50 了 你能不能试试 我努力好久了

@coefu 嗯 目标定高点是想拉着大伙一起干的。我一个人能力确实有限。希望老师您等我仓库出来，帮我多指导，我们一个板块一个功能去优化。反正 ai 也才起步 我们方向没错就可以了。

为了避免我在骗代码，我让 ai 给我排的计划以及已实现功能
KWCode 产品项目计划
> 天工开物 · 中国开发者的本地 Coding Agent
> 最后更新：2026-04-28
> 当前版本：v0.4.3
---
产品定位
一句话：中国开发者的本地 Coding Agent——Windows 打开就能用，数据不出网，越用越懂你的项目。
核心差异化：
CC/Cursor：云端强模型，数据出境，国内访问不稳定
Hermes：不支持 Windows 原生，7B 以下不可用，无中国本地化
OpenClaw：通用 agent ，无 coding 专项流水线，安全问题频发
KWCode：Windows 原生 + Coding 专项 MoE 流水线 + 小模型适配 + 中国市场
---
已完成功能（ v0.4.3 现状）
核心架构
[x] Gate 路由（ JSON 输出，专家注册表关键词匹配 + 通用分类兜底）
[x] MoE 确定性专家流水线（ Locator→Generator→Verifier ，每步独立 context ）
[x] AST 调用图 Locator （ BM25 召回 + tree-sitter 调用图两阶段，函数级 100%）
[x] Generator （从文件读 original ，LLM 只生成 modified ，3 个候选 patch ）
[x] Verifier （语法检查 + pytest 双验证，按扩展名跳过非代码文件）
[x] SearchAugmentor （ SearXNG→DDG→Bing fallback ，失败 2 次触发）
[x] OfficeExpert （ docx/xlsx/pptx Python 脚本生成执行）
[x] ChatExpert （非编码输入友好回复）
[x] MAX_RETRIES=3 硬编码，重试策略三阶段（正常/从错误出发/最小化）
[x] Reflection 机制（第二次失败前分析错误原因）
专家系统
[x] 12 个预置专家（通用 7 个 + 中国场景 5 个）
[x] 专家 system_prompt 管道打通（ YAML→Gate→Orchestrator→LLM ）
[x] cl-v2 规范注入（ quality_rules + china_env + model_behavior + testgen ）
[x] 专家飞轮（轨迹收集→模式检测→三道投产门→生命周期管理）
[x] 专家导出/安装 CLI （.kwx 格式，支持 URL 安装）
[x] Gate _postprocess （ office 误分类兜底，few-shot 示例补充）
记忆系统
[x] 三层记忆分离（ PROJECT.md / EXPERT.md / PATTERN.md ）
[x] Context Pruner （纯算法，头尾保留+中间关键词提取，<5ms ）
[x] 失败模式写入 PATTERN.md
中国本地化
[x] Windows cmd/PowerShell 原生支持
[x] ModelScope 自动切换（ HuggingFace 不通时）
[x] pip 清华/阿里镜像自动配置
[x] SearXNG 自部署（ install 脚本自动 docker pull ）
[x] Bing 中文版 fallback （ DDG 被墙时自动切换）
[x] 国产模型适配（ DeepSeek/Qwen3 reasoning token 处理，temperature≥0.01 ）
CLI 体验
[x] KWQode header （产品名/版本/模型/项目/专家）
[x] 状态栏（ prompt_toolkit bottom_toolbar ，ctx/压缩/tok/s/VRAM/RAM ）
[x] VRAMWatcher 后台线程（每 10 秒刷新，daemon=True ）
[x] /model 切换（更新 reasoning 检测，重建流水线）
[x] /api temp|default|show （切换 endpoint ，验证连通性）
[x] 首次启动引导（ API 配置，连通性验证选 B 方案）
[x] 模型兼容性检测（视觉模型如 qwen3-vl 提示警告）
工程质量
[x] 174 单元测试全绿
[x] 30 题 E2E 基准测试（ 25/30=83%，5 个失败均为模型能力限制）
[x] 10/10 CORE 红线全部通过
[x] V5 AST +50pp 函数级提升
[x] V6 专家生成 3/3 PASS
[x] MCP Router （ KaiwuMCP ，唯一对外入口）
---
待实现功能（按优先级排序）
---
P0 — 正在进行中
[P0-1] 反复循环修复（进行中）
目标：小模型反复输出同样错误 patch 的问题
已完成：
[x] retry_strategy 三阶段（正常/从错误出发/最小化）
[x] previous_failure 传给 Generator
[x] Reflection 机制（第二次失败分析错误原因）
待完成：
[ ] 强制换路径验证（确认三次 prompt 表述完全不同）
[ ] 失败模式写入 PATTERN.md 的格式规范化
---
P1 — 必须做，主流 agent 都有，KWCode 必须补
[P1-1] KWCODE.md 用户规则文件
对标：CC(CLAUDE.md)、Hermes(MEMORY.md)、OpenClaw(AGENT.md)
价值：用户写"永远用 pytest"、"认证逻辑在 src/auth/"，每次启动自动注入
小模型增强：读取后做任务前预处理——把复杂任务拆成原子操作序列
实现规格：
```
触发：启动时自动检测项目根目录的 KWCODE.md
格式：标准 Markdown ，用户自由编写
注入：Gate 调用前注入 system （ token 上限：模型窗口的 15%）
优先级：KWCODE.md > PROJECT.md （用户规则覆盖自动积累的记忆）
命令：kwcode init 时自动创建模板 KWCODE.md
```
验收：
[ ] 项目根目录有 KWCODE.md 时自动加载
[ ] 内容注入到 Gate 的 system prompt
[ ] kwcode init 生成标准模板
[ ] token 超出上限时截断不报错
---
[P1-2] /plan 计划模式
对标：CC(--plan flag)、Codex CLI(plan mode)
价值：先看计划再执行，解决用户"不敢用 agent 做复杂任务"的心理门槛
小模型增强：计划阶段分析每步可能失败的原因，提前注入防御策略
实现规格：
```bash
# 使用方式
kwcode --plan "重构数据库连接层"
# 或 REPL 内
/plan 重构数据库连接层
```
输出格式：
```
计划：重构数据库连接层

步骤 1：定位相关文件
目标文件：src/db/connection.py, src/db/pool.py
相关函数：init_pool(), get_connection(), close_connection()
风险：如果 connection.py 被多处 import ，需同步更新调用方

步骤 2：生成重构方案
修改范围：以上 3 个函数
不涉及：业务逻辑层（ src/services/）

步骤 3：验证
运行：pytest tests/test_db.py

确认执行？[y/N]
```
验收：
[ ] --plan 参数和 /plan 命令都生效
[ ] 计划输出包含文件列表和风险提示
[ ] 用户确认 y 后才执行
[ ] 用户按 N 或 Ctrl+C 退出不修改任何文件
---
[P1-3] Checkpoint 文件快照
对标：CC(enable_file_checkpointing)
价值：任务开始前自动快照，失败一键还原，用户敢放手用 agent
小模型增强：失败回滚后自动降级任务复杂度（整体→单函数）
实现规格：
```python
# 实现方式：git stash （项目是 git 仓库时）或文件复制快照
# 任务开始前：
# 1. 检测项目是否 git 仓库
# 2. 是：git stash save "kwcode-checkpoint-{timestamp}"
# 3. 否：复制被修改文件到 ~/.kwcode/checkpoints/{timestamp}/

# 命令
kwcode checkpoint list # 查看所有快照
kwcode checkpoint restore # 还原到最近快照
kwcode checkpoint restore <id> # 还原到指定快照
```
自动降级（小模型增强）：
```
失败→回滚后：
原任务："重构整个认证模块"（涉及 5 个文件）
降级为："只修复 validate_token 函数"（ 1 个函数）
提示用户："任务较复杂，已降级为更小范围，继续？[y/N]"
```
验收：
[ ] 任务开始前自动创建快照（ git stash 优先）
[ ] 任务成功后快照自动清理
[ ] kwcode checkpoint restore 还原正确
[ ] 失败回滚后提示降级选项
---
[P1-4] 非代码文件读取（项目知识库）
对标：CC （读取项目所有文件类型）
价值：PDF 需求文档、Word 规范、Excel 数据表纳入知识库，辅助 coding 任务
边界：只读取用于辅助 coding 任务的文件，不做通用文档管理
小模型增强：不全文注入，提取结构化摘要（接口名/字段/业务规则）按相关性注入
支持格式：
```
简单（直接实现）：
PDF 文本型 → pdfplumber （已在 office 模块）
Word(.docx) → python-docx （已在 office 模块）
Markdown → 直接读文本
JSON/YAML → 直接解析

中等（需额外处理）：
PDF 扫描件 → paddleocr （可选，本地 OCR ）
Excel → openpyxl 读数据（已在 office 模块）

暂不支持：
图片原型图 → 需视觉模型，暂不做
```
集成到 Locator：
```python
# Locator 的 retrieve() 扩展：
# 除了代码文件，同时搜索项目里的 PDF/Word/MD 文件
# BM25 关键词匹配 → 提取相关段落 → 结构化摘要 → 注入 context
# token 上限：非代码文件内容占 context 的 20%
```
验收：
[ ] 项目目录有 PDF 时，Locator 能读取并提取文本
[ ] "按需求文档实现登录接口" → 自动读取 requirements.pdf
[ ] 摘要注入不超过 context 的 20%
[ ] 不支持格式优雅降级（不报错，跳过）
---
[P1-5] 任务难度自动评估（小模型新功能）
价值：小模型特有需求，大模型不需要。主动管理用户预期，避免超出能力的任务白跑三次
对标：无竞品做过，KWCode 独有
实现规格：
```python
# Gate 分类后，Orchestrator 执行前，评估任务难度：
评估维度：
- 涉及文件数（ Locator 预估）
- 涉及函数数
- 是否跨模块
- 是否有外部依赖（网络/数据库）
- 任务描述是否模糊

超出阈值（任意一条）：
- 涉及文件 > 3
- 涉及函数 > 8
- 描述模糊（ Gate 置信度 < 0.6 ）

触发提示：
"这个任务比较复杂（涉及 4 个文件，8 个函数）。
建议拆分为以下子任务：
1. 先修复 validate_token 的边界检查
2. 再更新 login_handler 的错误处理
直接执行完整任务？[y] 还是拆分执行？[n]"
```
验收：
[ ] 复杂任务（>3 文件）触发提示
[ ] 用户选 y 继续原任务
[ ] 用户选 n 输出拆分建议（不自动执行）
[ ] 简单任务不触发提示（无干扰）
---
P2 — 重要，有用户后优先做
[P2-1] Git 完整工作流
对标：CC 、OpenClaw
价值：branch 创建、PR 草稿、cherry-pick ，团队用户刚需
实现规格：
```bash
kwcode "帮我把登录功能提一个 PR"
# → 自动：git checkout -b feat/login
# → 执行任务
# → git push origin feat/login
# → gh pr create --draft --title "feat: 登录功能"
```
依赖：gitpython （已有）+ gh CLI （用户自行安装）
验收：
[ ] 自动 branch 创建和切换
[ ] 任务完成后自动 commit
[ ] PR 草稿创建（依赖 gh CLI ）
---
[P2-2] 多文件原子修改
对标：CC （改接口同步更新所有调用方）
价值：复杂任务成功率低的主因
小模型增强：先用 AST 调用图找出所有需要改的地方，再批量生成 patch
实现规格：
```
现在：Generator 每次只改一个文件
目标：
1. Locator 找出所有相关文件和函数（利用调用图）
2. Generator 按依赖顺序生成所有文件的 patch
3. Verifier 一次性验证所有 patch
4. 全部通过才 apply ，任意失败全部回滚（原子性）
```
验收：
[ ] 修改接口时自动更新调用方
[ ] 所有 patch 原子性 apply （全成功或全回滚）
---
[P2-3] 权限管控（ allowlist/denylist ）
对标：CC(settings.json)、OpenClaw(exec-policy)
价值：哪些命令自动执行，哪些需要确认，企业用户安全需求
实现规格：
```yaml
# ~/.kwcode/permissions.yaml
auto_approve:
- read_file
- write_file
- run_bash: ["pytest", "python", "git status", "git diff"]
require_confirm:
- run_bash: ["rm", "docker", "curl"]
- git_commit
always_deny:
- run_bash: ["rm -rf /", "sudo"]
```
验收：
[ ] auto_approve 列表中的命令直接执行
[ ] require_confirm 命令执行前提示确认
[ ] always_deny 命令拒绝执行并说明原因
---
[P2-4] 微信/钉钉/飞书接入
对标：Hermes （ 6 个平台）、OpenClaw （ 16 个平台）
价值：中国用户不用 Discord/Slack ，手机发消息让 agent 改代码
优先做：微信（个人用户）、钉钉/飞书（企业用户）
实现规格：
```
架构：KWCode Gateway （本地服务，8090 端口）
← 微信/钉钉/飞书 webhook
→ 转发给 Orchestrator
→ 结果推回消息平台

依赖：
微信：wxpy 或企业微信 webhook
钉钉：钉钉机器人 webhook （最简单，直接 HTTP ）
飞书：飞书机器人 webhook
```
验收：
[ ] 钉钉机器人能触发 kwcode 任务
[ ] 任务结果推回钉钉
[ ] 支持 @机器人 触发
---
[P2-5] CI/CD 监听
对标：CC （监听 GitHub/GitLab CI 自动修复）
价值：团队用户刚需，测试失败自动拉日志修复
实现规格：
```bash
# 启动监听模式
kwcode watch --ci github --repo user/repo --branch main

# 当 CI 失败时：
# 1. 拉取失败日志
# 2. 分析失败原因
# 3. 自动修复
# 4. 推送修复 commit
```
验收：
[ ] 监听 GitHub Actions 失败事件
[ ] 自动拉取 CI 日志
[ ] 触发修复流程
---
P3 — 后期，等有用户再做
[P3-1] IDE 插件（ VS Code ）
对标：CC （原生 VS Code 扩展）
方案：VS Code 扩展 → 调用本地 kwcode CLI → 结果显示在侧边栏
[P3-2] 远程执行/VPS 部署
对标：Hermes （$5 VPS 跑 agent ）
方案：KWCode Server 模式 → HTTP API → 消息平台控制
前置：需要消息平台接入（ P2-4 ）先完成
[P3-3] 沙盒执行
对标：CC 、OpenClaw
方案：Docker 容器隔离执行环境
前置：企业用户需求，个人用户优先级低
[P3-4] KaiwuHub 专家社区平台
对标：npm/pip 的专家包注册中心
现状：FLEX-6 降级方案（ GitHub URL 安装）已实现
升级：专家搜索、评分、一键安装的 Web 平台
[P3-5] prompt_optimizer 自动进化
对标：cl-v2 的 auto_evolve.py
方案：用 Opus API 分析失败任务，自动优化专家 system_prompt
前置：bench_tasks 测试集需要先扩充到 50+ 题
---
技术债务
TD-1：Gate 专家路由叠加模式（已设计，待实现）
问题：专家 trigger_keywords 和通用分类存在大量重叠，Gate 分类不稳定
方案：Gate 先做通用分类，再叠加专家知识（不是替代）
影响：T22/T26 等 Gate 分类不稳定问题
TD-2：飞轮 Gate2 回测未真实执行
问题：ABTester 的 Gate2 直接 passed=True ，没有真正回测原始轨迹
方案：用 source_trajectories 真实跑一遍新专家，对比成功率
TD-3：SQLite 跨 session 历史查询
现状：三层记忆是文件，没有跨 session 的结构化查询
方案：记忆条目写入 SQLite ，支持 BM25 检索相关历史
TD-4：conversation_history 使用真实 LLM 输出
问题：conversation_history 存的是假数据，Pruner 估算不准
方案：每轮任务后 append 真实 LLM 输出
---
验证基准
单元测试
目标：174 测试全绿（当前：174/174 ✅）
E2E 基准（ 30 题）
当前：25/30 = 83%
5 个失败：T3/T21/T28 （ Generator 能力）、T22/T26 （ Gate 不稳定，模型限制）
目标：P1 功能实现后重测，目标 27/30
红线约束
CORE-1 到 CORE-10：全部通过 ✅
LOC-RED-5 （ Locator <3s ）：通过 ✅
UI-RED-2 （ Pruner <5ms ）：通过 ✅
---
竞品对照总结
功能 CC Hermes OpenClaw KWCode 当前 KWCode 目标
小模型 MoE 流水线 ✗ ✗ ✗ ✅ ✅
AST 调用图定位 ✗ ✗ ✗ ✅ ✅
中国本地化 ✗ ✗ ✗ ✅ ✅
专家飞轮三道门 ✗ ✗ ✗ ✅ ✅
项目规则文件 ✅ ✅ ✅ ✗ P1-1

/plan 计划模式 ✅ ✗ ✗ ✗ P1-2
Checkpoint 回滚 ✅ ✗ 部分 ✗ P1-3
非代码文件读取 部分 ✗ ✗ ✗ P1-4
任务难度评估 ✗ ✗ ✗ ✗ P1-5 （独有）
Git 完整工作流 ✅ 部分 ✅ 部分 P2-1
多文件原子修改 ✅ ✗ ✗ ✗ P2-2
消息平台接入 ✗ ✅ ✅ ✗ P2-4 （中文）
IDE 插件 ✅ ✗ 部分 ✗ P3-1
远程执行 ✅ ✅ ✅ ✗ P3-2
---
参考文献
Agentless：Xia et al. ICSE 2025 — 确定性流水线优于复杂 agent
CodeCompass：arXiv:2602.20048, 2026 — 调用图遍历 G3 任务 99.4% vs BM25 76.2%
KGCompass：arXiv:2503.21710, 2025 — SWE-bench Lite 58.3%，$0.2/次
AgentCoder：EMNLP 2023 — 多专家分工验证（ GPT-4 达 96.3%）
EE-MCP：NeurIPS 2025 — 从任务轨迹提取经验的机制设计
---
KWCode Product Plan | 2026-04-28

@coefu 尤其我对你刚说 search 的问题我也遇到，我的技术方案是：
Query 生成：一次 LLM 调用，把中文任务描述转成英文搜索 query 。这是中文 query 在技术搜索上效果明显差于英文。
SearXNG：主搜索引擎，本地 Docker 部署，JSON API 调用。SearXNG 内部聚合了几十个搜索源，它做路由。自动启动容器、自动配置 JSON 格式。DDG 库（ duckduckgo-search ）作为 fallback ，SearXNG 不可用时接管。
质量过滤：域名白名单（ github/stackoverflow/docs.python.org 等）优先排序，黑名单（ csdn/baidu/zhihu 等）直接过滤。最多取 3 条 URL 进入下一步。
页面抓取：trafilatura 提取正文，失败时降级到 httpx+简单 HTML 去标签。天气类网站有反爬限制，SearXNG 返回的 snippet 对这类查询已经够用，不必强求全文。
压缩注入：提取的正文截断到 800 字，注入 Generator 的 prompt 。
但实际使用的时候，体验没有 cc 好，老师能给个更好思路么？

@scyuns 嗯 可以这么说 本土化 且对开源模型专项优化的 codex 或者 cc 或者 hermess

@GeruzoniAnsasu 不好意思 我才搞 vibe 不太明白这里面的忌讳，这样做不合适么？我怕我现在仓库发早了，用户一看功能残缺没兴趣继续了。

@coefu 非常感谢让我认识到了不足，我现在的做法是 1 、追平 CC ，cursor 和 hermes ，他们的基础功能都实现，我觉得这个不难，毕竟大部分都开源。实现也没有技术难度。2 、在他们基础上，对小 B 模型进行辅助，比如上下文插入记忆实现无限压缩、比如限制他重复废话，比如尝试通过让他搜索互联网拿到现成答案去解决他无法解决的问题等。3 、增加一些优化本地模型或者本土化的功能，比如网络被墙、工具调用问题。4 、最后蒸馏一些好的代码规范。确实如您所说，我没办法突破，但我做的本身只是一个整合，把市面上能对本地部署有优化的内容和功能整合到这个项目中。

@listenerri 不好做是么？还是实用性不强？

@WispZhan A 卡老师很牛的，我之前只弄过 N 卡，请问现在模型有适配 A 卡好的么？

回过头来看 这个帖子怎么写得这么煽动。。。
其实我就是一个人能力不够想找专家帮忙一起写这个项目，我已经有个 MVP
这两天把稳定性跑跑就能发仓库了。

@kubecoder 我印象更新到 0.1.5 之后版本就不用手动安装了。现在版本应该直接可用我把 dll 打包进去了 谢谢试用 有什么优化建议麻烦随时提

@rechardwong0522 问题是 iso3 不支持（ SM61 ），llama.cpp 的 q4_0 KV cache 在这个量化精度下反而会占更多，加上 SM61 driver overhead ，实测就是过不了。如果实在要跑，试试这个：
kaiwu run Qwen3-30B-A3B-UD-Q3_K_M --ctx-size 4096
回复下为什么标题那个 8G 能跑 30B ，因为 50 显卡支持 iso3 的 turbo 。

@CFM880 这是开源模型通病，调用工具就是差。我正在开发另外一套适配的 coding agent 考虑一起优化这些问题。但是价值可能不太大，这个赛道 hermas 、cc 、codex 已经很成熟了，只是没有专门为开源本地部署做优化。

@hanli 是的 ，我测试时候遇到的，就是 think 模式很讨厌，但我觉得这个不应该我这个模型部署器应有的功能，应该是 hermas 或者 cc 、cursor 做，我感觉这个功能加进去有点越界了，我现在也深深感觉我这个工具里面那个上下文压缩，我也觉得有点越界，比如 hermas 她本身也有此类功能。