夜雨聆风
Claude Code 源码泄漏对三省六部multi-agent的改进
2026年3月底，Claude Code 51万行源码意外泄漏。我们正好在做一个多Agent系统——状态不统一、事件丢失、并发互踩。逐模块读完泄漏源码后，我们提炼了五个关键设计模式，逐一应用到自己的系统里。改造前 55% 的任务以取消告终，改造后 5 个真实开发任务全部完成。
0️⃣、传统技能
我发现,微信的礼物就零食看起来有点用(贵的买不起…)
一、事件始末
2026 年 3 月 31 日下午，Solayer Labs 实习生 Chaofan Shou 在 X 上发了一条帖子，引爆了整个 AI 开发者圈：
Anthropic 旗下明星产品 Claude Code 的 npm 包里，附带了一个 59.8 MB 的 source map 文件。通过这个文件，可以完整还原出 1,884 个 TypeScript 源文件、超过 51 万行代码。
几小时内，源码被镜像到多个 GitHub 仓库。Anthropic 反应过来后紧急移除了 source map，发布了 v2.1.89 修复版。
但代码一旦泄漏，就收不回来了。
关键数据：
|
指标 |
数值 |
|
泄漏文件数 |
1,884 个 TypeScript 文件 |
|
代码行数 |
~512,000 行 |
|
Source map 大小 |
59.8 MB |
|
内建工具 |
36 个 |
|
内建 Agent |
6 个 |
|
Bash 安全验证器 |
23 个 |
|
编译时 Feature Flag |
82+ 个 |
|
运行时 Feature Flag |
~52 个 |
|
已发现 CVE |
5 个 |
这不是一段被反编译出来的混淆代码。这是完整的、带注释的、有测试的生产级源码。
这对我们来说是一个难得的学习机会。因为我们正好在做一个多 Agent 系统，遇到的问题——状态不统一、事件丢失、并发互踩——和 Claude Code 要解决的是同一类。于是我们根据资料,提炼出了五个可以直接应用到自己系统的关键设计模式。
二、从泄漏源码中提炼的五个关键模式
我们提炼出五个对自己系统最有价值的设计模式。以下是每个模式在 Claude Code 中的实现，以及我们参考后做的改进。
① 状态机必须是唯一法源
Claude Code 里所有状态转换都有一个 canonical source。任何组件要读状态定义都从那一个地方读。DeepImmutable
我们的改进：参考这个思路，将散落在三个文件中的状态定义统一到 task.py 单一法源，CI 自动校验引用一致性。编译时强制不可变和引用相等优化暂未实现，但统一法源已经消除了最常见的状态不一致问题。
② 事件和数据必须在同一个事务里
Claude Code 在每次 API 调用和工具执行循环里，用了典型的 Outbox Pattern——事件不直接发，先写进同一个数据库事务，再由独立 worker 投递。上下文管理是五层压缩管道，每一层独立判断是否需要介入，轻量操作优先，昂贵的全量压缩兆底。
我们的改进：实现了 Outbox Pattern——事件写 outbox 表、同事务提交、Relay worker 投递、失败进 DLQ。五层压缩管道暂未实现，但数据和事件的一致性问题已经彻底解决。
③ 并发不能一把锁通吃
源码里 partitionToolCalls() 函数做了精细的并发控制：连续的并发安全工具合并为一个批次并行执行，非安全工具各自一个批次串行执行。关键是——并发安全性是 per-invocation 的，不是 per-tool-type 的。同一个 BashTool，ls 是并发安全的，rm -rf 不是。
我们的改进：参考这个思路实现了分桶调度——快桶（太子等 5 个 Agent，4 并发）和慢桶（六部，3 并发）互不阻塞。per-invocation 级别的安全判定暂未实现，但分桶已经解决了慢任务阻塞快任务的核心痛点。
④ Agent 需要分层记忆
不是将全部上下文塞进 prompt 的暴力方案。Claude Code 的 Memory 系统是文件级持久化：MEMORY.md 始终加载（限 200 行 25KB），独立话题文件按需召回，四种记忆类型各司其职。还有 DreamTask——一个仿人类“睡眠记忆整理”的子 Agent。
⑤ 上游输出不可信
源码里有 7 层纵深防御、23 个 Bash 验证器、DANGEROUS_ 前缀强制 code review 关注安全关键路径。isConcurrencySafe(input) 的输入相依设计不是“这工具安全吗？”而是“这个输入 + 这个工具安全吗？”
我们的改进：实现了 6 正则模式过滤 + 审计事件 + GLOBAL.md 安全条款。跟 Claude Code 的 7 层纵深防御相比粒度还差得远，但至少建立了基本的防御层。
五个模式中，我们完整实现了前三个（状态机统一、Outbox、分桶调度），部分实现了后两个（三级记忆、基础注入防御）。离 Claude Code 的精细度还差很远——51 万行生产级代码和社区项目的差距是客观的——但已经解决了系统最致命的工程问题。
下面是具体的改造过程和实际效果。
三、改造过程
以下是参考泄漏源码后，我们对系统做的改造。所有改动跑在 41 个单元测试 + 57 个端到端检查点的守护下。每个阶段全绿才进下一阶段。
Phase 0：统一状态机
|
改了什么 |
具体内容 |
|
统一状态机 |
12 个状态 + PendingConfirm，唯一法源 task.py，CI 自动校验一致性 |
|
事件总线升级 |
consume_multi / publish_batch / get_delivery_count |
|
Agent 上下文 |
灵魂上下文（GLOBAL → 组 → SOUL.md）+ 任务上下文双层注入 |
|
僵尸检测 |
超时 30 分钟的 Executing 任务自动发 task.stalled 事件 |
改造前每个模块各自维护状态列表，新增状态需要同步修改三个文件。现在统一到单一文件定义，CI 自动校验引用一致性。
Phase 1：审计 + 分权 + 配置
|
改了什么 |
具体内容 |
|
审计日志 |
只追加不删除的 AuditLog 表，谁在什么时候改了什么 |
|
三级配置 |
GLOBAL.md → 组级 → SOUL.md 三层叠加，优先级递增 |
|
权限矩阵 |
11 个 Agent 各有命令白名单，越权直接 PERMISSION_DENIED |
|
刷新防抖 |
信号文件 + watcher，5 秒内多次触发合并为一次 |
改造前任何 Agent 均可执行任意命令。现在每个 Agent 仅能使用白名单内的操作，越权行为立即拦截并记录审计日志。
Phase 2：Outbox + 行级锁（核心）
这是整次改造中最关键的一步。
|
改了什么 |
具体内容 |
|
Transactional Outbox |
事件写 outbox 表 → 同事务 COMMIT → Relay worker 投递 → 失败进 DLQ |
|
SELECT FOR UPDATE |
行级排他锁，两个 Agent 同时改一条任务不再 Lost Update |
|
失败分类 |
超时/返回码可重试，命令找不到直接 DLQ，重试次数从 Redis 读 |
改造前“先写 DB 再发事件”，中间崩溃就会数据不一致。现在事件和数据在同一个事务里提交，Relay worker 负责投递，失败自动重试，五次仍失败则归入 DLQ。
Phase 3：并行 + 记忆 + 注入防御
|
改了什么 |
具体内容 |
|
并行编排 |
按 task_id 分组，不同任务 asyncio.gather，同任务保持串行 |
|
分桶调度 |
快桶（太子等 5 个 Agent，4 并发）+ 慢桶（六部，3 并发），互不阻塞 |
|
三级记忆 |
个人记忆 / 任务记忆 / 全局记忆，Agent 调用时自动注入 |
|
注入防御 |
6 正则模式 + 审计事件 + GLOBAL.md 安全条款 |
工部写文档 5 分钟不再卡住太子分拣消息。户部算完的数据写入任务记忆，兵部接手时自动读到。
Phase 4：确认机制 + 技能 + 委派
|
改了什么 |
具体内容 |
|
高危确认 |
Executing → Done 等 4 类高危操作先进 PendingConfirm，需审批方确认 |
|
任务分解 |
同时只允许一个 in-progress 子任务，全完成自动标 ready_to_close |
|
技能系统 |
manifest.json 动态加载 SKILL.md，按标签匹配注入 |
|
任务委派 |
委派链路记录 + 最大深度 3 层 + 循环检测 + 结果回传 |
改造前任何 Agent 均可直接将任务标记为完成。现在高危操作必须经过审批方确认才能生效。
四、真实运行案例——改造前后对比
测试全部通过只能说明代码正确。更有说服力的是系统实际处理过的真实任务。以下案例全部来自 tasks_source.json 中的生产记录。
案例一：早期调试地狱——55% 的任务以 Cancelled 告终
以 3 月 20 日为例，当天连续创建了 11 个任务测试系统流转，结果：
JJC-20260320-008CancelledE2E验证：编写一段Python hello world代码
JJC-20260320-009Cancelled编写一段Python hello world代码并保存到文件
JJC-20260320-010Cancelled编写Python hello world并保存
JJC-20260320-011Cancelled写一个Python脚本计算斐波那契数列前10项
JJC-20260320-012Cancelled写一个Python脚本计算1到10的和
…
连 hello world 都无法完成，反复取消重试。11 个任务中仅 2 个到达 Done 状态。
▲ 奏折阁 · 已取消——早期大量任务以失败告终
统计整个早期阶段：33 个任务，18 个取消，取消率 55%。
原因包括：状态不一致导致流转卡死、Agent 间传递数据出错、缺少审计日志无法定位故障环节、并发时数据互踩。
案例二：改造后—5 个复杂任务全部完成，0 取消
改造全部上线后，连续提交了 5 个真实的开发任务：
|
任务 |
内容 |
耗时 |
门下省封驳 |
结果 |
|
JJC-001 |
代码安全审计（Flask，OWASP Top 10） |
19分 |
1次封驳 |
✅ Done |
|
JJC-002 |
营销活动 H5 落地页前端 |
11分 |
0次 |
✅ Done |
|
JJC-003 |
支付模块单元测试（覆盖率≥90%） |
17分 |
1次封驳 |
✅ Done |
|
JJC-004 |
月度销售数据报表生成 |
8分 |
0次 |
✅ Done |
|
JJC-005 |
用户管理 CRUD API 开发 |
13分 |
1次封驳 |
✅ Done |
5 个任务全部完成，0 个取消。
▲ 奏折阁 · 已完成——改造后的任务全部成功
案例三：门下省封驳——在上线前挡住了安全漏洞
JJC-20260329-001 是一个 Flask 应用的安全审计任务。门下省的封驳记录：
🔴 封驳：中书省的方案只让刑部检查 OWASP Top 10 通用项，但该代码使用了 render_template_string，需额外检查 SSTI 漏洞类型。补充后方可准奏。
门下省不是橡皮图章——它真的读了任务内容，发现方案漏了 SSTI（Server-Side Template Injection）这个 Flask 特有的攻击面。
另一个例子是 JJC-20260329-003（支付模块测试）：
🔴 封驳：缺少幂等性测试用例，Mock 粒度过粗导致无法检测真实支付网关异常。要求补充幂等性场景和细化 Mock。
如果没有门下省这一层，这两个任务的执行质量会直接降一档。
案例四：完整流转链路
点开 JJC-20260329-005（用户管理 CRUD API）的详情页，可以看到完整的流转时间线：
▲ 任务详情——完整的流转时间线，包括门下省封驳记录
10:15:32皇上→ 太子下旨：开发用户管理CRUD接口
10:15:45太子→ 中书省⬇️ 太子分拣完毕，转中书省起草
10:22:18中书省→ 门下省提交审议
10:23:47门下省→ 中书省🔴 封驳：密码字段未过滤+分页无上限
10:23:47中书省→ 门下省修改后重新提交审议
10:23:47门下省→ 尚书省✅ 准奏
10:23:56尚书省🧭 派发执行
10:28:51尚书省→ 归档执行完毕，御批通过
13 分钟，经过太子分拣 → 中书省起草 → 门下省审议（封驳一次）→ 重拟 → 准奏 → 尚书省派发 → 执行 → 完成。每一步都有时间戳、有操作人、有原因说明。
改造之前？流转记录不完整，出问题只能猜。
改造前后对比
|
改造前 |
改造后 |
|
|
任务总数 |
33 |
5 |
|
完成率 |
45%（15/33） |
100%（5/5） |
|
取消率 |
55%（18/33） |
0% |
|
任务复杂度 |
hello world / 斐波那契 |
安全审计/支付测试/API开发 |
|
封驳质量 |
无 |
发现 SSTI 漏洞、幂等性缺失等 |
|
可追溯性 |
查 JSON 猜 |
完整时间线 + 审计日志 |
▲ 官员总览——每个 Agent 的功绩、任务参与和成本统计
五、社区反应：分析多、应用少
改造完成后，我们调研了社区中是否有人做了类似的实践。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
分析派：拆得非常细，但止步于“看”
泄漏三天内，GitHub 上至少冒出了 8 个分析仓库。掘金三天内涌现了 20+ 篇拆解文章。
重写派：从零复刻，但不是改进自己的系统
韩国团队 instructkr/claw-code 用 Rust 做了 clean-room 重写。但它的目标是复刻 Claude Code，不是用 Claude Code 的模式改进其他系统。
我们检索了 GitHub、掘金、知乎，未找到任何人提到“读了 Claude Code 源码后，对照自己的 Agent 系统做了改进”。
所有人都在分析。所有人都在重写。但没有人在对比和改进。这其实是我们写这篇文章的原因。
不是因为做得多好——恰恰相反，改造前的系统问题很多，改完之后对照 Claude Code 才发现还有很大差距。
六、升级后的三省六部功能全景
改造完成后，三省六部系统已经从“能跑”进化到“可用”。以下是当前系统的完整能力全景。
🏢 11 个 Agent 协作体系
|
Agent |
职能 |
擅长领域 |
|
👑 太子 |
消息分拣、需求整理 |
闲聊识别、旨意提炼 |
|
📜 中书省 |
接旨、规划、拆解 |
需求理解、方案设计 |
|
🔍 门下省 |
审议、把关、封驳 |
质量评审、风险识别 |
|
📮 尚书省 |
派发、协调、汇总 |
任务调度、结果整合 |
|
⚔️ 兵部 |
代码、算法、巡检 |
功能开发、Bug 修复 |
|
💰 户部 |
数据、资源、核算 |
报表生成、成本分析 |
|
📝 礼部 |
文档、规范、报告 |
技术文档、API 文档 |
|
⚖️ 刑部 |
安全、合规、审计 |
安全扫描、红线管控 |
|
🔧 工部 |
CI/CD、部署、工具 |
Docker、流水线、自动化 |
|
📋 吏部 |
人事、Agent 管理 |
权限维护、培训 |
|
🌅 早朝官 |
每日早朝、新闻聚合 |
定时播报、数据汇总 |
核心流转路径：
皇上下旨 → 太子分拣 → 中书规划 → 门下审议(可封驳) → 尚书派发 → 六部并行执行 → 回奏
🔧 工程升级了什么
|
改造项 |
改造前 |
改造后 |
|
状态管理 |
散落在 3 个文件 |
单一法源 task.py + CI 校验 |
|
事件可靠性 |
先写 DB 再发事件 |
Outbox Pattern + Relay + DLQ |
|
并发控制 |
共享槽位，慢任务阻塞快任务 |
快桶/慢桶分离，互不影响 |
|
Agent 记忆 |
每次从零开始 |
三级记忆自动注入 |
|
安全防御 |
无 |
6 正则 + 审计 + 权限矩阵 |
|
审计追溯 |
查 JSON 文件猜 |
完整时间线 + 只追加审计日志 |
|
测试守护 |
无 |
41 单元测试 + 57 端到端检查点 |
🚀 部署方式
•一键启动：bash start.sh
•Docker：docker-compose up
•systemd：edict.service 开机自启 + 崩溃自救
•多渠道派发：飞书 / Telegram / 企微 / Signal / Discord / Slack
▲ 省部调度总览——11 个 Agent 的在线状态和任务分配
▲ 模型配置——每个 Agent 可以独立选择不同的 LLM
七、总结与反思
泄漏源码给了我们一次难得的学习机会。以下是最核心的收获：
•状态管理：我们统一了状态定义，Claude Code 做到了编译时强制不可变 + 引用相等优化
•数据一致性：我们实现了 Outbox Pattern，Claude Code 在此基础上还有五层上下文压缩管道
•并发控制：我们做了分桶调度，Claude Code 的并发安全性是 per-invocation 级别的
•安全防御：我们加了正则过滤，Claude Code 是 7 层纵深防御 + 23 个 Bash 验证器
51 万行代码中最值得学习的，不是某个具体的算法，而是工程纪律的彻底程度——每一个状态转换都有记录、每一个事件发布都有事务保障、每一个 Agent 的权限都有边界、每一个上游输出都不被盲信。
现在有了 51 万行的真实实现作参考,极大的优化了三省六部的项目。
项目已开源：
https://github.com/cft0808/edict
致谢
请在微信客户端打开