@KaiWuBOSS #6 不比 10 年前的开源了。如果只是单体 application ，熟悉个把高级语言，也能参与。但是你这个是一个解决方案，里面涉及到的技能和知识点，不是 web 体系，有门槛的。你指望这些普通前后端围墙里的人，主动免费突破自己的知识壁垒，这是妄想。

而且你要做的这个事情，本身 top 厂商 也没有完全解决。还在演化迭代中，随着模型本身能力的进化，harness 都快要成过去时了。虽然，我不看好 LLM 这波，但是我自己也有使用的需求，我也持续关注。但是，变化太快了，你可以这么理解，agentic 本身的鲁棒性 一般，方法论迭代，时好时坏，benchmark 甚至都不能作为完整的验证依据。

这也是为什么市面上，迟迟没有人做。我 2024 年夏天的时候，langchain 就摸了一遍，去年开春的时候，llama.cpp 也摸了一遍，我这个摸，都是直接看源码的，当然，这是个人习惯，我看源码和看小说没什么区别。我为什么没做，因为，我看的太多了。我试图给 llama.cpp 找 异构多机多卡的分布式并行推理 的解决方案，想了几个月，并且还花点钱组了一个 10G 网络，但是最终，我发现是徒劳的。

比如，联网的问题，searxng ，如果你深度使用过就知道，就是个玩具（一则是它整合结果的算法，二则是 search 能识别有时候返回不相干结果）。不用钱买 search api ，都是玩具。
记忆这块，本身学界也没有什么好方案，论文出了一大堆，吹的比实际都好。至于 a ，o ，厂的技术，基本上都是人力财力堆出来的。开源完全无法媲美。

kvcache 的问题，在 gram 有限的开源环境中不可能解决，这是 0 day 原始问题，不是工程技术的问题，是原始架构的问题。唯一的方法，就是堆 gram 。

context 问题，和 kvcache 如出一辙。

有限 gram 的开源异构环境，没有通用解。

为了避免我在骗代码，我让 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

@KaiWuBOSS #20 我的经验就是，不要一早就立一个宏大到一眼看不到头的 flag 。 目标放的低一点，日拱一卒的去做，反而比一开始就冲锋，可能效果会更好。你一早就对标 cc ，那么期望值必然太高，各种达不到的预期会冲抵这份积极性。

cc 是大资本裹挟了一个超人才 team 逼出来的。它被动开源的部分，早就是它们内部的过去时了，你只看到了一个被动开源的中间态罢了，未必是最终形态，也未必是真正能持续有用的。search 的这部分，包括整个 harness ，从根源上是 反着 the bitter lesson 来的，过往之谏 让我对这些本身就很抵触，本质上和过去符号主义没什么区别。

你这份态度，我欣赏，我也不打消你的态度积极性，闯一闯，失败了，也未必是坏事。

search 只有花钱买 api ，这是市场选择。

你要做的这个事情，缝缝补补，总是差强人意的能用一下，但是对标 cc 这种云 api 的想法，可以先停一停。不如它，很正常。比它差一点，但是能用，也不是不可以。对标它，那是要融资了凑人才 team 做的事情，开源注定是做不成的一地鸡毛。