用 EMOS 管理操作系统，拆解 Anthropic “Claude Code 开源事故”

事情是这样发生的

2026年3月31日，一件有点讽刺的事发生了。

全球最顶尖的 AI 安全公司之一 Anthropic，在给自家 AI 编程工具 Claude Code 发布更新包时，意外把完整的源码一起推到了公开的 npm 仓库里。

一个本该在打包时被排除的文件——cli.js.map——溜进了发布产物。这个文件里，藏着 1,906 个 TypeScript 源文件，共约 51.2 万行代码。

Claude Code 的核心实现：内部 API 设计、遥测系统、加密工具、进程间通信协议……全出去了。

更戏剧的是里面藏着的几个功能：

• • 电子宠物系统 Buddy：18 种物种、稀有度分级、属性系统。网友说，”终端里的塔麻可吉”。
• • 常驻助手 Kairos：后台会话、自动任务触发、记忆整理。
• • 多智能体协调 Coordinator Mode：并行管理多个工作代理。
• • 卧底模式 Undercover Mode：隐藏 Anthropic 内部信息，防止员工在开源社区操作时泄露敏感内容。

最后这个”卧底模式”，舆论炸了。工具居然会隐藏自己是谁？听起来像骗人。

Anthropic 紧急推送更新，删除了问题文件。但源码已经在 GitHub 上广泛备份，收不回来了。

这不是黑客干的

在继续分析之前，有一点要说清楚：

这不是 Anthropic 被黑了。

没有人入侵他们的服务器，没有人窃取了什么。是他们自己，在一次普通的版本发布中，把本不该公开的东西，亲手推了出去。

这个细节，反而是整件事最值得深思的地方。

EMOS 是什么？先用一分钟了解它

为了更清晰地拆解这件事，我想借用一套经营分析框架——EMOS（Enterprise Management OS，企业经营管理操作系统）。

EMOS 的核心思想是：把公司当软件系统来设计。

传统管理依赖人——老板盯着人干活，规则写在文件里，人一走规则就废了，越扩张越失控。

EMOS 的解法是：把规则硬化进系统，让系统自动运行，人做架构师而不是监工。

它把企业经营分成三层：

O 层（Output）：输出与反馈系统  ←  仪表盘    ↕ 监测结果，感知异常P 层（Process）：组织与流程系统  ←  算法引擎    ↕ 自动化执行，协议驱动协议I 层（Input）：战略与目标系统  ←  防火墙    ↕ 接收信号，决定做什么、不做什么

每一层的核心任务：

• • I 层：拒绝 —— 决定哪些信号和行为可以进入系统
• • P 层：运行 —— 将人工干预替换为系统自动执行
• • O 层：监测 —— 确保输出始终在健康区间内

用这三层，来看看 Anthropic 这次到底哪里出了问题。

用 EMOS 拆解这次事故

I 层没有失守

先说结论：这次事故，I 层是无辜的。

Anthropic 的战略方向没问题——专注 AI 安全研究，做负责任的 AI 公司，目标是明确的。他们在安全红线上投入了大量资源：模型对齐、用户数据保护、网络安全……

I 层设置了很多防火墙，只是漏了一个口：没有在战略层面写下”发布流程本身就是安全红线”这条规则。

这条规则没有被认定为”战略级约束”，所以它没有被认真对待。

P 层是真正的失控现场

这次事故是 P 层问题。

P 层的核心任务是：将原本依赖人去执行的规则，硬化成系统自动执行的协议。

EMOS 有一个核心判断：能硬化进系统的规则，绝不靠人记。

人会犯错，人会遗忘，人会在高压的迭代节奏中漏掉”显而易见”的步骤。

来看 Anthropic 的发布流程，在这次事故里暴露的 P 层状态：

每一个环节，都有一条规则应该被写进系统——但没有。

这些规则飘在空中，可能存在于某个 Wiki 文档里，可能在某个工程师的记忆里，但没有住进系统的配置里。

EMOS 把规则落地叫做”找到它的家”——规则硬化有四个家：产品和工具、增长模型、组织结构、运营系统。

“不发布 source map 文件”这条规则，应该住在产品和工具这个家里（也就是 CI/CD 构建脚本中）。它没有住进去，所以一次版本迭代，就把它冲走了。

O 层是盲的

事故曝光后，Anthropic 的响应速度还算快，这说明他们有危机响应机制。

但问题在于——他们是被外部告知之后才知道的，不是自己发现的。

一个健康的 O 层，应该有这样的监测指标：

• • 发布包体积监测：本次包比上次突然增大 → 自动告警
• • 发布内容 diff：新版本比上版本多了哪些文件 → 自动列出审核
• • 下载量异常：短时间内被大量下载 → 可能出了什么事

如果 O 层是完整的，这件事会被内部先发现，甚至在发布之前就被拦截。

现在的结果是：外部先发现，内部后补救。O 层在这个维度是盲的。

被忽视的”稳定性原则”

EMOS 有五条经营原则，其中一条叫稳定性原则：

稳定比速度更重要。 系统的可靠性是经营的底座，速度建立在稳定之上，而不是相反。

Claude Code 的版本号是 v2.1.88——这说明他们迭代极其频繁。快速迭代本身没有问题，但发布流程的稳定性没有跟上迭代的速度。

速度超过了规则，事故就是代价。

这是很多快速成长的公司共同面临的陷阱：产品快、技术快、迭代快，但内部系统的成熟度跟不上。于是某一天，在一个最不起眼的地方，出现了一个没人注意的漏洞。

修复方案：EMOS 会怎么做？

如果用 EMOS 来重新设计 Anthropic 的发布系统，核心动作只有三步：

第一步：I 层补漏

在发布策略的顶层文档中，明确写入：

“发布流程安全”是战略级约束，与模型安全、用户数据安全同等级别。任何发布流程变更，必须经过安全审查。

这条规则一旦进入 I 层，后续所有流程设计都以它为约束条件。

第二步：P 层硬化（最关键）

把”不发布 source map”这条规则写进 CI/CD 构建脚本：在 npm publish 之前，自动扫描 artifact，发现 .map 文件直接中断发布，报错，不过。

规则住进”产品和工具”这个家，从此不靠任何人记，也不会因为人员变动或迭代压力而丢失。

第三步：O 层补盲

建立发布监控看板。每次发布自动记录：包体积变化、文件列表 diff、对比上一版本的差异。超出阈值，自动告警，人来决策，不是人来发现问题。

这件事真正重要的启示

这次事故最深的教训，不是”要小心 .map 文件”，而是：

技术能力的强大，不等于系统能力的成熟。

Anthropic 拥有世界顶级的 AI 研究团队，在模型安全上投入了极大资源。但这一切，都没能阻止一个构建配置的疏漏把核心代码推出去。

因为模型安全和发布流程安全，是系统的两个完全不同的维度。顶级的研究能力，无法自动转化为顶级的工程流程管理能力。

这个道理对所有公司都成立：

• • 你的销售很强，不代表你的客户成功体系成熟
• • 你的产品做得好，不代表你的交付流程可靠
• • 你的技术水平高，不代表你的发布流程安全

公司能跑多稳，不取决于最强的那个模块，而取决于最弱的那个流程节点。

EMOS 想解决的，正是这个问题：把公司的运营能力，从依赖个人经验和人工记忆，升级到依赖系统规则和自动化协议。

一家真正成熟的公司，应该让规则住进系统，而不是住在人的脑子里。

本文基于公开信息写成。EMOS（企业经营管理操作系统）是一套将系统思维应用于企业经营的方法论，详见《管理架构师：像设计产品一样设计公司》。