我用9个AI Agent，从0到1复刻了一个完整的Claude Code

tunsuy

发布于 2026-04-16 15:46:58

510

起因

4月初，Claude Code的源码泄露了。

拿到源码之后通读了一遍，大概1,900个文件、512K+行TypeScript代码。看完之后就有了一个想法：能不能用Go把它重写一遍？不是写个Demo玩玩，而是把所有功能都搬过来——CLI入口、LLM查询引擎、40多个内置工具、TUI终端界面、MCP协议客户端、权限系统、配置系统、多Agent协调、会话管理，全都要。

更进一步，我决定自己不写任何生产代码。设计、编码、评审、测试、Bug修复，全交给AI Agent来做。

我只管提需求、定流程、验收结果。

为什么用Go？

Claude Code原版是TypeScript + Bun运行时，换成Go有几个实际的好处：

「Go编译成单一二进制」，分发部署简单，不需要Node.js运行时
「goroutine + channel」天然适合并发场景——流式响应、工具并发执行、多Agent协调
「Go的类型系统和接口机制」做大型项目的模块解耦比较舒服
另外我也想试试，AI Agent处理Go语言的复杂工程项目能做到什么程度

组建AI团队

这个项目的规模不小，一个Agent搞不定。我参照真实软件团队的组织结构，设计了一套多Agent协作方案：

项目治理层

「PM Agent（项目经理）」 —— 项目的"中枢神经"。不写代码，但对整个项目的交付结果负全责。负责任务拆解、进度跟踪、依赖管理、风险控制、流程执法。PM是唯一有权宣布"项目完成"的角色。
「Tech Lead Agent（技术负责人）」 —— 项目的"技术大脑"。输出架构设计、定义接口契约、做代码评审、解决技术阻塞。所有技术决策的最终拍板人。

开发执行层

六个专职开发Agent，每人负责一个架构层次：

Agent	负责层次	核心模块
Agent-Infra	基础设施层	公共类型、配置系统、应用状态、会话存储
Agent-Services	服务层	API客户端、MCP客户端、OAuth认证
Agent-Core	核心层	查询引擎、权限系统、上下文压缩、Hooks
Agent-Tools	工具层	40+内置工具的完整实现
Agent-TUI	TUI层	BubbleTea终端界面、Slash命令
Agent-CLI	入口层	Cobra命令解析、程序启动

质量保障层

「QA Agent」 —— 项目的"质量门卫"。制定测试策略，对每个模块独立验收，出具验收报告。

「总共9个Agent」，分工明确。

具体怎么做的

这不是简单地告诉AI"帮我写个CLI工具"，整个过程走了一套完整的软件工程流程。

第一步：架构先行

Tech Lead Agent先上。基于泄露的TypeScript源码，它输出了一份完整的Go版架构设计文档。

这份文档定义了：

「六层分层架构」——入口层、TUI层、核心层、工具层、服务层、基础设施层
「严格的单向依赖」——下层禁止依赖上层，同层禁止互相依赖
「核心技术决策」——BubbleTea做TUI、goroutine+channel做并发、三级配置优先级、权限决策流程
「完整的数据流定义」——LLM查询主循环、工具权限检查流程、子Agent调度流程

┌─────────────────────────────────────────┐
│              入口层 (Entry)              │
│          CLI 命令解析与程序启动            │
└──────────────────┬──────────────────────┘
                   │
┌──────────────────▼──────────────────────┐
│              TUI 层 (UI)                │
│     终端用户界面，渲染与用户交互           │
└──────────────────┬──────────────────────┘
                   │
┌──────────────────▼──────────────────────┐
│             核心层 (Core)               │
│  LLM 查询引擎 | 工具编排 | 权限检查        │
└────┬──────────┬──────────┬──────────────┘
     │          │          │
┌────▼──┐  ┌───▼───┐  ┌───▼────────────┐
│工具层  │  │服务层  │  │  基础设施层     │
└───────┘  └───────┘  └────────────────┘

六层架构示意图

第二步：全员并行开发

这是整个项目比较关键的一个决定。

传统做法是按依赖顺序串行——先搭基础设施，再写核心逻辑，最后做UI。但我让所有Agent同时开工。

PM Agent定了一条规矩：

❝「所有Agent同时启动，不串行等待。依赖没就绪的地方用 // TODO(dep): 等待 <模块> 就绪后补全 标记，先跳过继续推进。」 ❞

实际效果是：

Agent-Infra在写配置系统的同时，Agent-Core已经在设计查询引擎了
Agent-Tools不用等Agent-Core完成，先按接口契约写工具实现
PM Agent持续跟踪依赖状态，某个模块就绪了就通知对应Agent回填TODO

六个开发Agent同时推进，项目整体耗时缩短了不少。

多Agent并行开发

第三步：三层质量门控

代码写完不算完，每个模块要过三关：

「第一层：Tech Lead代码评审」

Tech Lead Agent先读设计文档，再对比实现代码，逐行审查。每份评审报告都包含"设计 vs 实现差异分析"，标注P0（阻塞性问题）、P1（重要问题）、P2（建议改进）。

六个模块总共产出了12份评审报告——6份设计评审 + 6份代码评审，累计超过100个审查意见。

「第二层：QA验收测试」

QA Agent从测试角度独立验收：单元测试质量、可测试性、功能完整性。不评审代码架构（那是Tech Lead的活儿），专注于"这个模块能不能正确工作"。

「第三层：Bug退回与修复闭环」

评审发现的问题不代为修改，退回给对应的开发Agent修复，修复完Tech Lead复核。直到所有P0问题关闭。

跟真实团队的流程差不多。

代码评审报告

数字说话

列几个关键数据：

指标	数值
Go源文件数	170+
Go代码总行数	50,000+
测试文件数	80+
文档数	80+
Agent角色数	9个
任务总数	50+
评审报告数	12份
架构层次	6层
内置工具数	40+

从架构设计到代码评审完成，总共花了大约「一周」。9个Agent并行推进，产出了一个可编译的、带80多份文档的Go语言项目。

技术细节

1. 功能覆盖

不是阉割版，主要功能都做了：

「交互式TUI界面」：基于BubbleTea的Elm架构（Model-Update-View），支持暗色/亮色主题、Vim键绑定、流式输出渲染
「LLM查询引擎」：完整的请求-响应主循环，支持工具调用编排（只读工具并发、写工具串行）、token预算管理、上下文自动压缩
「40+内置工具」：文件读写编辑、Shell执行、Glob/Grep搜索、子Agent调度、MCP工具适配、Web搜索抓取、任务管理等
「权限系统」：多级规则匹配（全局/项目/本地配置叠加）、文件路径校验、Shell命令匹配、用户确认对话框
「MCP客户端」：完整的Model Context Protocol实现，支持stdio/SSE/HTTP三种传输方式
「OAuth认证」：完整的OAuth2授权码流程、Token安全存储与刷新
「会话管理」：对话持久化、--resume断点恢复
「18个Slash命令」：/help、/clear、/compact、/commit、/review、/diff、/mcp等

2. 用Go的方式重写

没有照搬TypeScript的写法，而是按Go的惯例重新做：

TypeScript特性	Go实现方案
React + Ink	BubbleTea + Lip Gloss
async/await + Promise	goroutine + channel
useState/setState	Model struct + Update()
EventEmitter	channel广播
Zod schema验证	go-playground/validator
Commander.js	Cobra

3. 工程层面

「接口驱动开发」：所有模块通过interface解耦，支持依赖注入和Mock测试
「并发安全」：全局状态使用sync.RWMutex保护，上下文取消统一走context.Context
「分层架构」：严格的单向依赖，pkg/types作为零依赖公共基础
「错误处理」：自定义错误类型、AbortError优雅退出、API可重试/不可重试错误区分

做完之后的一些想法

AI能干的活比想象中多

9个Agent不光写了代码，还：

输出了完整的架构设计文档
做了12轮代码评审
发现并修复了9个P0级Bug
产出了80多份技术文档
建了完整的测试策略和验收流程

流程比技术更重要

前几轮迭代踩了不少坑——QA跑去评审代码架构、PM直接改代码、Agent改了别的Agent负责的模块。后来加了严格的角色边界：

PM不碰代码
QA只管测试，代码质量的事交给Tech Lead
发现问题退回原Agent修，不允许"顺手帮忙"
所有变更走正式流程

管AI团队和管人，套路差不多——「流程和规范才是规模化的关键」。

并行开发的依赖管理

传统思路是"等依赖好了再动手"。但用TODO占位的方式，可以做到全员同时开工，PM跟踪依赖链，就绪了就通知回填。项目总耗时缩短很多。

这个思路对真实团队也有参考价值。很多时候，"等"只是惯性思维。

开源地址

项目已开源，欢迎Star、Fork、提Issue：

🔗 「GitHub」: https://github.com/tunsuy/claude-code-go

你可以在docs/project/目录下找到：

完整的架构设计文档
9个Agent的角色定义
项目开发计划表和依赖关系图
12份代码评审报告
QA验收报告
PM巡检日志

这些文档本身就是一份完整的多Agent协作记录，有兴趣可以翻翻。

写在最后

这个项目目前还在评审修复阶段，有些P0问题正在处理。但核心代码已经就绪，go build可以通过编译。

这个项目的意义不在于"又多了一个Claude Code替代品"，而是验证了一件事：

「一个50,000+行、六层架构、有完整工程流程的Go项目，可以由AI Agent团队从0到1交付。」

不是Demo，是实际的软件工程。

AI写代码这事已经不新鲜了，但让一群AI Agent像真实团队一样分工协作、互相评审、迭代修复——这件事还有很多可以探索的空间。

感兴趣的可以来GitHub上看看，欢迎交流。

❝项目地址：https://github.com/tunsuy/claude-code-go ❞

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2026-04-10，如有侵权请联系 cloudcommunity@tencent.com 删除

工具

本文分享自有文化的技术人微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度