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

支持大佬

链接呢？ 如果是 Rust + TS/Bun.sh 愿意贡献一份力。 我也只有一个小破电脑，AMD 5700X + AMD 6900XT

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

点赞但不看好

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

@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 的开源异构环境，没有通用解。

不是咋贡献呀 我们整一个本土化 codex 吗

吓我一跳，我以后后面要一转中转站广告了。。

没有用啊，没有模型，没法用。皮之不存，毛将焉附？

你手里没有真东西，最后就变成其他人薅你的中转额度

寇可往，我亦可往

硬盘坏了怎么办

支持

开源方案不少了吧，可以 fork 一个 vibe 魔改，也可以自己 vibe 一个

/go/aislop


> 后续在本链接发布


你自己看了不会觉得不妥么？
给你看我收藏的第一个这种帖子： https://www.v2ex.com/t/561958

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

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

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

@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 好，老师能给个更好思路么？

为了避免我在骗代码，我让 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 做的事情，开源注定是做不成的一地鸡毛。