我用 Kimi3 完整复刻了 grok-build：Spring Boot 3 + Java 21 重写马斯克开源的 AI 编码代理

📝

作者拿 Kimi3 完整复刻了马斯克开源的 grok-build（Rust 生产级 AI 编码代理）：前端 Electron+React+Vite+TS，后端 Spring Boot 3 + Java 21，WebSocket 协议（端口 19528）。本文拆解五大核心部件——Agent 循环（含 TodoGate 待办门禁防偷懒）、20 个内建工具两阶段调度（安检串行、干活并行、按文件加锁）、五层权限决策链默认从严、上下文压缩 80% 阈值自动触发、SSE 流式采样+指数退避重试——以及最惊艳的 Goal 模式 skeptic 陪审团（AI 监督 AI）。7 天 Kimi3 coding-plan 用量 2 天烧完。结论：开源参照物 + 开源大模型 = 人人都能造自己的 AI 编码代理。

我用 Kimi3 完整复刻了 grok-build 的功能

原文：微信公众号《我用Kimi3完整复刻了grok-build的功能》· 作者：月夜烛峰

马斯克开源的 grok-build 是一个生产级 AI 编码代理。当 Kimi3 发布后，作者决定拿它当「考题」：用 Kimi3 把 grok-build 完整复刻一遍，既验证 Kimi3 的工程化综合能力，也顺便给自己造一个趁手的 Agent——能帮自己解决日常问题、分析 ELK 日志、排查内存溢出。

结果不仅是「套了个壳」：技术栈从 Rust 换成 Spring Boot 3 + Java 21，前端用 Electron，后端从零重写，且刻意做了清醒的取舍。本文按架构 → 五大核心部件 → Goal 模式 → 运行方式的顺序，把这次复刻讲透。

一、复刻效果：授权审批、ELK 查询、内存分析

先用一个最小场景看整体效果：在聊天窗口输入「九九乘法表」，Agent 生成代码前会弹出授权提示，点击「允许一次」后继续运行。这个窗口就是 Kimi3 自由设计的界面，体验相当不错。

复刻不是只做个前端界面，每一个功能在后端都有对应实现：

• ELK 日志查询工具：作者自研添加，会话中可直接调用配置好的 ELK 平台查询日志，并由 Agent 自行分析日志信息；
• 内存溢出分析：接入后可在对话中直接排查 OOM 问题；
• 外加原版 grok-build 的通用能力：文件读写、终端命令、网页抓取、搜索、子代理派发等。

Token 消耗：作者用的是 Kimi3 的 coding-plan，7 天用量基本 2 天用完——足见这次是动真格的：不只是一层 UI，而是一整套「前端界面 + 后端服务」的完整工程。

二、整体架构：同一个大脑，换个壳

复刻前，作者让 Kimi3 先分析了 grok-build 的代码结构，得到的回答非常抽象但也非常准确：

grok-build 像一家餐厅。后厨（运行时大脑）负责真正做菜；前台（TUI 界面）只负责点单和端菜。前台可以随便换——堂食窗口、外卖 App、电话点单——都不影响后厨。

层级	原版 grok-build（Rust）	我们的复刻（Java）
前台界面	终端 TUI / IDE 插件 / 无头 CI	Electron 桌面界面
前后台协议	ACP 协议（前后台通用语言）	自定义 WebSocket 协议
大脑	Rust Agent 运行时	Spring Boot 运行时

💡 核心架构洞察：运行时与界面解耦，界面可以随便换，大脑不变。

为了让 Kimi3 在重构时理解原版每个部件「为什么存在」，作者先让它整理了一份学习教程：充分分析理解 grok-build 每个功能点的设计、工作流的底层编排原理，再用 Java 的方式重新表达它，而不是逐行翻译。

取舍表：有些东西刻意不抄

原版有的	我们的处理	为什么
核心运行时（循环/工具/权限/压缩/持久化）	✅ 重写	这是灵魂，必须自己长出来
全屏 TUI 终端界面	❌ 换掉	用 Electron 桌面界面替代
ACP 协议兼容	❌ 简化	自定义 WebSocket 协议，更简单
OAuth 全家桶登录	❌ 砍掉	先用 API Key，够用
操作系统内核级沙箱	❌ 降级	Java 无等价物，后续用容器兜
长任务自主编排（Goal 模式）	✅ 精髓复刻	这是最惊艳的部分，必留

前端目录结构（Electron + React + Vite + TypeScript）

web-ui · Electron + React + Vite + TypeScript 桌面前端
│
├─ 🪟 electron/ (2) ── 主进程 main.cjs + preload 桥
├─ 📄 index.html ── Vite 入口
└─ 📁 src/
   ├─ 🚀 main.tsx · App.tsx ── 应用入口 + 根组件
   ├─ 📡 api/ (3) ── ws · rest · actions（连后端 19528）
   ├─ 🪝 hooks/ (1) ── useWebsocket
   ├─ 🗃️ store/ (3) ── chatStore · appStore · uiStore（Zustand）
   ├─ 📐 types/ (3) ── protocol · config · desktop.d（镜像后端协议）
   ├─ 🧩 components/
   │  ├─ 💬 chat/ (7) ── 对话主区（消息流/工具卡/审批）
   │  │  └─ 🔧 tools/ (5) ── Terminal/File/Diff/ELK/Generic 卡片
   │  ├─ 🧱 common/ (7) ── CodeBlock/Markdown/Modal/icons…
   │  ├─ ⌨️ input/ (5) ── PromptInput/Mode/Model/Slash/Goal
   │  ├─ 🖼️ layout/ (5) ── TitleBar/Sidebar/ContextPanel/Goal…
   │  ├─ ⚙️ settings/ (1) ── SettingsModal
   │  └─ 📑 tabs/ (9) ── Providers/Models/Tools/Skills/MCP…
   ├─ 🎨 styles/ (2) ── index.css · hljs.css
   └─ 🛠️ utils/ (1) ── index.ts

后端目录结构（Spring Boot 3 + Java 21）

com.grokbuild · GrokBuildApplication（Spring Boot 入口）
│
├─ 🌐 server       (9)  ── 入口与协议：WebSocket /ws/agent + REST /api
├─ 🧠 runtime      (22) ── 运行时核心：AgentLoop / SessionActor / 压缩 / 子代理
│   └─ 🎯 goal     (7)  ── 长时自主任务 + skeptic 陪审团验证
├─ 📡 provider     (8)  ── 模型接入：OpenAI / Anthropic / 重试 / 注册表
├─ 🛠️ tools        (31) ── 工具骨架：契约 / 注册表 / 两阶段调度
│   └─ ⚡ builtin  (20) ── 20 个内建工具实现
├─ 🛡️ permission   (5)  ── 五层权限决策链
├─ 🔌 mcp          (4)  ── MCP 工具发现
├─ 📚 skills       (4)  ── SKILL.md 扫描与注入
├─ ⚙️ config       (4)  ── 分层合并 + 热重载
├─ 💬 conversation (6)  ── 消息模型 + token 估算
├─ 💾 persistence  (2)  ── JSONL 双文件持久化
└─ 🧰 common       (3)  ── JSON / 路径 / 取消信号

五层架构总览

🖥️ Electron 桌面界面（聊天 · 审批弹窗 · 设置 · 会话管理）
   前端只负责「说」和「画」，什么都不懂
        │
        ▼  WebSocket / REST
🔌 协议层：/ws/agent（WebSocket） + /api/*（REST）
   前后台的通用语言，相当于原版的 ACP
        │
        ▼
🧠 运行时层（runtime）—— 真正的大脑
   SessionManager · SessionActor · AgentLoop · CompactionService
   每个会话独占一个线程，命令排队串行执行（无锁并发）
   ├─ 📡 Provider   连模型（Grok/OpenAI/Kimi3…）
   ├─ 🛠️ Tools      20 个内建工具：读写/执行/搜索
   └─ 🛡️ Permission 权限引擎：危险操作先问人
        │
        ▼
📦 底座：Conversation（消息） · Config（配置） · Persistence（持久化）
   配置可热重载 · 会话落盘可恢复

依赖方向：从上往下，不互相绕行

三、五大核心部件：大脑是怎么转的

1. Agent 循环：思考 → 动手 → 再思考，直到干完

它回答了一个根本问题：「用户说一句话」之后，代理怎么自主地一直干到任务完成？

① 用户提问 / 注入任务
② 体检：上下文太长？→ 自动压缩
③ 调用模型，流式生成回答（一边想一边把字吐出来）
④ 模型想用工具吗？──否──→ ⑤ 回答完成
    │是
⑤ 权限审批 → 执行工具 → 结果回填
    │
    └── 带着工具结果回到第③步

真正的代码就是一个循环，每转一圈叫「一轮（turn）」。这是 Java 实现里精简后的真实骨架：

// AgentLoop.java —— 每个会话在一个虚拟线程上跑这个循环
for (int turn = 0; turn < maxTurns; turn++) {
    throwIfCancelled(cancel);                    // ① 用户按了取消？立刻停
    compaction.maybeCompact(ctx, threshold);     // ② 上下文太长就压缩
    ConversationRequest req = chat.buildRequest(
        SystemPrompts.build(ctx, tools, skillsSection), ...);
    // ③ 流式调用模型，边生成边把字推给前端
    List<ToolCall> toolCalls = provider.streamChat(req, model, ...);
    if (toolCalls.isEmpty()) break;              // ④⑤ 没工具要用了 → 回答完成
    dispatcher.executeAll(ctx, toolCalls);       // ⑤ 执行工具，结果回填历史
    // 然后自然回到循环顶，带着工具结果再问模型……
}

两个值得注意的设计：

• Java 21 虚拟线程（newVirtualThreadPerTaskExecutor）：对应原版 Rust 的「单线程 actor」模型，用很低的代价做到「每个会话、每个工具互不干扰」；
• TodoGate（待办门禁）：如果模型嘴上说做完了、但 todo 清单里还有没打勾的任务，系统会「戳它一下」让它继续干，最多戳 2 次——专门防止代理偷懒。

2. 工具系统：20 个内建工具，安检串行、干活并行

光有循环不够，模型得有「手」才能真正干活。这套代理内置 20 个工具，分几类：

类别	工具
📂 文件类	read_file · write_file · search_replace · list_dir · grep · glob
⚡ 执行类	run_terminal_cmd（跑命令）· ELK 查日志
🌐 联网类	web_fetch（抓网页）· web_search（搜索）
📋 管理类	todo_write（待办）· 后台任务 · 定时任务 · 监控
🤖 协作类	task（派子代理）· skill（技能）· update_goal（汇报目标进度）

工具执行有个精妙的两阶段设计：

阶段一：逐个过安检 🔒          阶段二：一起开干 ⚡
工具A → 权限审批               工具A ▶
工具B → 权限审批      ═══▶    工具B ▶  （并行）
工具C → 权限审批               工具C ▶

为什么串行？审批是和人打交道，  为什么并行？执行是机器活，
一个个问，别轰炸用户            能同时跑就同时跑

另外有个聪明的小机制：按文件加锁。如果两个工具都要改同一个文件，它们会自动排队（避免互相覆盖）；改不同文件的，则真正同时跑。

3. 权限引擎：五层决策链，默认从严

给 AI 权力让它能改文件、跑命令，万一它 rm -rf 了怎么办？权限系统是命门。每一次工具调用，都要过一条五层决策链：

第1层：配置规则（你写的 allow / deny / ask）
第2层：plan 计划模式（写操作一律拦）
第3层：yolo 模式（「我全都要」全放行）
第4层：你之前「总是允许」过的记忆
第5层：内建白名单（ls / cat / git 等安全命令）
        │
        ├─ ✓ 命中 allow → 放行
        ├─ ✗ 命中 deny → 拒绝
        ├─ ? 命中 ask → 弹窗
        └─ 都没命中？→ 弹窗问你（120秒不回=拒绝）

这套设计的精髓是默认从严：不确定的操作，宁可停下来问你，也不会擅自执行——这是让 AI 编码代理「敢用」的关键。

4. 上下文压缩：80% 阈值自动触发，配对工具调用整体保留

模型能「看」的字数是有限的。会话聊久了、读了一堆代码，上下文就会爆掉。做法和人一样：把前面的对话记成摘要，丢掉原文，只保留要点。当上下文用到一定比例（默认 80%）时自动触发压缩，把历史浓缩成一段摘要，然后接着聊。

难点在于压缩时不能把正在进行的工具调用拦腰切断——系统会智能地把「一对配对好的工具调用」整体保留，避免上下文错乱。

5. 流式采样：SSE + 指数退避重试

和模型对话不是「问一句、等半天、吐一大段」，而是流式的：模型一边想，一边把字一个个吐出来，前端实时显示，就像微信对话框里对方正在打字。这背后是 SSE（Server-Sent Events）流式协议。

还有一层自动重试：网络抖了、服务限流了（429 错误），系统会自动按指数退避重试（等 2 秒、4 秒、8 秒……），还带随机抖动避免雪崩。这一切对用户透明。

四、Goal 模式的设计精髓：skeptic 陪审团

如果说前面五个部件是「常规操作」，那 Goal 模式就是整个 grok-build 最有想法、最惊艳的设计，复刻时特别用心保留了精髓。

普通模式下代理是「你说一句，它做一句」。Goal 模式则完全不同：你给它一个目标（比如「把这个项目从 Vue 迁移到 React，并保证测试通过」），再给一个预算（比如 50 万 token），然后它就自己干去了——自己规划、自己执行、自己喊「我做完了」，直到目标真正达成、预算花光、或者它卡住向你求助。

把「agent 循环」升级成了「agent 编排」。但这里有个致命问题：

⚠️ 模型自己说「我做完了」，能信吗？
AI 有幻觉，它可能自信满满地宣布完成，其实根本没做完、甚至做错了。

grok-build 的答案是教科书级别的：不信。用一组「对抗性验证者」去反驳它。这套机制叫 skeptic 陪审团（skeptic = 怀疑论者）：

模型：「我做完了！」（update_goal: completed = true）
        │
        ▼
⚖️ 先收集「呈堂证供」
   git diff（到底改了啥） + plan.md（验收标准变没变）
        │
        ▼
🏛️ skeptic 陪审团开庭
   skeptic 0：守门员 🧐 「连任」——记得你上次在哪里造假
   skeptic 1..N：评审团 👥 每次「冷启动」新法官，防止老法官变偏袒
   各自独立审查，写出 JSON 判词：驳回？还是放行？
        │
        ▼ 冷面板「严格多数决」
   ✓ 多数不驳回 → 通过，目标达成，收工总结
   ✗ 驳回（附上缺口）→ 打回去继续干，别想蒙混

🎯 AI 监督 AI：自己说「完成」不算数

这套设计的精妙之处：

1. 连任守门员：有一个 skeptic（编号 0）是「连任」的——它记得上次模型在哪里造假、被驳回了什么缺口，这次重点复查。专治「屡教不改」。
2. 冷面板多数决：其他评委每次都是「新面孔」冷启动——防止同一个评委和模型混熟了，变成「盖章机器」。要多数同意才算通过。
3. 带证据反驳：驳回时不是一句「不行」，而是附上具体的缺口清单（哪里没做、哪里做错了），模型下轮拿到后能对症补齐。
4. 三条安全绳：① 重启后绝不自动复活一个自主代理（必须人按「继续」）；② 卡住 3 次会暂停求助；③ 预算花光自动停。

这是「AI 监督 AI」这一范式最扎实的落地之一：不靠人盯，而是用一套对抗机制让模型自证其罪。这套机制在 Java 代码里整整占了一个子包、7 个类：GoalOrchestrator（编排）、GoalTracker（状态机）、GoalVerification（陪审团验证）……是整个项目工程密度最高的地方。

五、如何运行

后端就是一个 Spring Boot 应用：

# 编译打包
mvn -DskipTests package
# 启动后端（监听 19528 端口）
java -jar target/grokbuild-agent.jar
# 验一下活的
curl localhost:19528/api/health
# {"status":"ok","version":"0.1.0"}

前端是 Electron 应用，npm run dev 起来就连上后端。配好模型的 API Key，新建一个会话，就能开始流式对话、触发工具、走审批了。

前后端通过一个简单的 WebSocket 协议通信（端口 19528）：

// 前端 → 后端
{"id": 6, "method": "session/prompt",
 "params": {"sessionId": "...", "text": "帮我把登录改成 JWT"}}

// 后端 → 前端（流式吐字）
{"method": "session/update", "params": {"update":
 {"kind": "agent_message_chunk", "text": "好的，我来看看..."}}}

就这几种消息，撑起了整个交互。简单、清晰、够用。

六、写在最后：开源的意义

这次复刻能成，靠的是两点：

一是 grok-build 本身开源——它把一个生产级 AI 编码代理的设计毫无保留地摊开，等于免费送了一份「大师级蓝图」。没有它，连「该有哪些部件」都摸不清。

二是 Kimi3 开源——一个万亿级参数、能自由使用的强力模型，成了手里最得力的「搭档工程师」。没有它，一个人根本啃不动上万行的重构。

开源参照物 + 开源大模型 = 人人都能造自己的 AI 编码代理。

这或许就是 2026 年最让人兴奋的事：曾经只有顶级 AI 公司能做的东西，现在一个开发者加一个开源模型，就能在自家电脑上复刻出来。