当一个每周下载上亿次的包可以被投毒，当最强大的 AI Agent 的源码一夜之间暴露在公网上——我们该重新审视的，不只是某个产品的安全问题，而是整个 AI Agent 生态的信任基石。
一、事件全景
2026 年 4 月，AI Agent 生态接连爆发两起安全事件，指向同一个核心问题：我们正在构建一个高度依赖第三方组件的智能系统，但信任机制远未跟上技术演进的速度。
| 事件 | 性质 | 影响面 |
|---|---|---|
| Claude Code 源码泄露 | 架构暴露 | Agent 开发者生态 |
| axios 供应链投毒 | 供应链攻击 | 每周 1 亿次下载 |
| MCP 协议开始失宠 | 架构争议 | Agent 互操作性 |
这三起事件看似独立，实则指向同一趋势：AI Agent 生态从"跑通功能"进入"信任重建"阶段。
二、Claude Code 源码泄露：不只是泄露，是架构暴露
有人花了一天读完泄露的全部 Claude Code 源码，得出了一个比"泄露"本身更重要的发现：Agent 的架构秘密被彻底暴露了。
2.1 泄露了什么？
不是用户数据，不是隐私信息，而是架构代码本身——一个顶级 AI Agent 的完整工程实现：
- 分层架构如何设计
- 上下文（Context）如何管理
- 安全边界在哪里
- Subagent 如何调度
- Skill 如何被注册和执行
这些信息此前是各家 AI 公司的核心机密。如今，Claude Code 的源码让所有 Agent 开发者看清了一个顶级产品的内部构造。
2.2 比泄露更深远的影响
泄露本身是安全事件，但它的"副产品"更有价值：它为整个行业提供了一份免费的 Agent 架构参考实现。
这意味着：
- 后来者可以直接参考顶级 Agent 的架构设计
- 安全研究者可以系统性审计 Agent 的漏洞模式
- 开发者可以更准确地评估自己使用的 Agent 的安全边界
2.3 开发者的四条启示
从泄露的源码中，可以提炼出四条 Agent 安全实践：
① 分层信任：Agent 不是单层应用，是多层信任链。每层都应有独立的安全边界，不能假设"内层安全，外层就安全"。
② 最小权限原则：Agent 的每个子模块（Subagent、Skill、MCP 服务器）都应该只拥有完成任务所需的最小权限。
③ 输入不可信：Agent 接收的所有外部输入（用户 prompt、工具返回、网络请求）都必须经过验证和清洗。
④ 审计优先：Agent 的决策链路必须可追溯，每个关键操作都应有日志记录。
三、axios 供应链投毒：没有一行恶意代码的攻击
每周 1 亿次下载的 axios 被投毒了，但源码里没有一行恶意代码。这是一种更高级的供应链攻击。
3.1 攻击手法
攻击者没有直接在代码中写入恶意逻辑，而是通过更隐蔽的方式：
- 依赖包版本替换
- 构建过程注入
- 间接依赖链污染
这种攻击的特点是：你在代码审查中看不到任何问题，因为恶意行为不在代码里，而在依赖链的某个环节中。
3.2 为什么 axios 特别危险
axios 作为 HTTP 请求的事实标准，被无数前端项目和 Node.js 服务依赖。它的供应链被攻破意味着：
- 影响面极广：任何使用 axios 的项目都可能受影响
- 难以检测：没有显式恶意代码，常规 SAST/DAST 工具无法发现
- 自动传播：npm install 会自动拉取被污染的依赖
3.3 防御策略
- 锁定依赖版本：使用 lockfile（package-lock.json / pnpm-lock.yaml），不自动更新依赖
- 定期审计：运行
npm audit/pnpm audit，关注依赖链安全 - 使用可信源：配置企业级私有 npm registry，不直接从公共仓库拉包
- 代码签名：关注 npm 的 Provenance 功能，验证包的构建来源
四、MCP 失宠：协议之争背后的信任危机
MCP（Model Context Protocol）从爆红到被嫌弃，反映的不是技术失败，而是架构方向的重新思考。
4.1 MCP 的承诺
MCP 的初衷是好的：做一个统一的连接协议，让不同的 AI 模型可以访问相同的数据源。它的定位是**"能访问什么"**。
4.2 为什么开始失宠
实际落地中暴露了三个问题：
- 过于通用：试图用一个协议覆盖所有数据源，结果每个场景都不够深入
- 安全边界模糊：当所有工具都通过 MCP 暴露给 Agent 时，权限控制变得极其复杂
- 与 Skill 的定位重叠：Skill 作为"能力封装"，部分覆盖了 MCP 的功能空间
4.3 MCP vs Skill 的分野
| 维度 | MCP | Skill |
|---|---|---|
| 定位 | 连接协议（能访问什么） | 能力封装（会做什么） |
| 粒度 | 粗粒度（整个数据源） | 细粒度（具体行为） |
| 安全 | 依赖外部权限控制 | 内嵌权限模型 |
| 复用 | 一次接入，多模型使用 | 跨 Agent 复用行为 |
两者不是替代关系，而是互补关系。但现实中，团队往往只选其一，导致架构不完整。
五、Linux 社区的答案：责任必须钉在人身上
在 AI Agent 生态的安全讨论中，Linux 社区的态度提供了一个清醒的参照系：代码可以开源，但责任必须钉在人身上。
Linus Torvalds 对 Linux 内核的治理模式是：
- 代码开放审查
- 维护者对每个子模块负全责
- 安全问题直接追溯到具体维护者
这种模式移植到 AI Agent 生态就是：
- 每个 Subagent 有明确的所有者
- 每个 Skill 有安全责任人
- 供应链漏洞有明确的响应路径
AI Agent 生态缺的不是技术方案，是治理方案。
六、重建信任的五条原则
综合三起事件，AI Agent 生态需要重建信任机制：
- 架构透明：开源 Agent 的架构文档应公开，让社区可以系统性审计
- 供应链安全：从依赖管理到构建过程，每个环节都要有可验证的信任链
- 分层防御：不依赖单一安全措施，每一层都有独立的安全边界
- 责任明确：每个模块、每个依赖、每个 Skill 都有明确的安全责任人
- 持续审计：安全不是一次性工作，是持续的监控和响应
七、延伸观察：开源生态的信任正在重构
从 axios 投毒到 Claude Code 泄露，再到各种 npm 包的供应链事件，一个趋势已经清晰：开源生态的信任模式正在从"默认信任"转向"持续验证"。
这意味着：
- 不再假设知名项目是安全的
- 不再假设代码审查能发现所有问题
- 不再假设依赖链上的任何一个环节是可信的
对于使用 AI Agent 的开发者来说，这不是恐慌的理由，而是行动的指南：从今天开始，把你的 Agent 当成一个需要持续审计的安全系统，而不是一个开箱即用的工具。
本文基于今日热点池中 7 篇知识沉淀文章交叉分析创作，素材来源：掘金技术社区。 关联热点：ClaudeCode 源码泄露 | axios 供应链投毒 | MCP 协议争议
