# Shopify CEO Tobi Lütke考虑封杀Claude Code 因AGENTS.md问题 —— 为何这“小”文件可能重塑AI编程

Shopify CEO Tobi Lütke因AGENTS.md支持对Claude Code提出挑战。了解为何智能体配置可移植性正成为关键AI编程标准。

Canonical URL: https://aiidelist.com/zh/blog/shopify-ceo-claude-code-agents-md-zh

Language: zh

Published: 2026-08-26

Updated: 2026-08-26

## 关键要点

- Shopify首席执行官Tobi Lütke在2026年8月25日表示，他正考虑在Shopify禁用Claude Code，直至该工具能够直接读取AGENTS.md、.agents/skills/以及类似的供应商无关的智能体配置文件。
- 争议的焦点并非一个Markdown文件名，而是仓库级别的AI指令应归属于特定编码智能体供应商，还是应保持跨工具的可移植性。
- Claude Code仍将CLAUDE.md视作其原生项目记忆文件。团队可以导入AGENTS.md、在CLAUDE.md中引用它或使用符号链接，但这些方法在大型仓库中会增加协调开销。
- Shopify对此问题异常敏感，因其World单体仓库包含代码、技能、规范、操作手册、AGENTS.md文件，以及公司范围内AI智能体使用的其他机器可读工程知识。
- 可能的长期架构是：一个供应商无关的指令层，加上可选的工具特定覆盖项，而非为每个AI编码产品维护相同规则的分立副本。
- 截至2026年8月26日，Claude Code已改进迁移和互操作性功能，但其官方项目记忆行为仍区分CLAUDE.md与原生AGENTS.md的识别机制。

![图片](https://cdn.aiidelist.com/api/image/Ah_NhXxg6elf8zpV6GhWl.webp)

## Shopify与Claude Code之间发生了什么？

2026年8月25日，Shopify首席执行官Tobi Lütke就Claude Code处理仓库指令的方式公开质疑Anthropic。

Lütke表示，他正考虑在Shopify禁用Claude Code，直至该工具能够直接读取AGENTS.md、.agents/skills/及相关共享智能体配置。他的担忧在于：当同一仓库内的工程师使用不同的AI编码智能体时，强制使用CLAUDE.md可能导致"脑裂"问题。

措辞很重要。Shopify并未宣布已实施全公司范围的禁令。该声明是对工具设计决策的公开警告，这种决策在组织规模下会变得代价高昂。

Claude Code团队成员Thariq Shihipar回应称，Anthropic正在努力使Claude Code更具可定制性，包括更便捷地使用Agents.MD以及更广泛的系统提示定制。

这一回应使该事件超越了社交媒体争论的层面。它揭示了一个快速增长的基础设施问题：AI编码智能体所依赖的项目上下文归谁所有？

## AGENTS.md为何重要

AGENTS.md是一个仓库级别的指令文件，旨在为编码智能体提供持久的项目上下文。

一个有效的AGENTS.md可以告知智能体：

- 仓库的结构组织方式；
- 应使用的包管理器及命令；
- 测试的运行方式；
- 不可跨越的架构边界；
- 哪些生成文件永远不应手动编辑；
- 数据库迁移的处理方式；
- 适用的安全或兼容性约束；
- 哪些目录特定规则会覆盖更广泛的默认设置。

简化示例如下：

```text

# 仓库使用说明

包管理器：pnpm

在提交拉取请求前：
- 运行 pnpm lint
- 运行 pnpm test
- 运行 pnpm typecheck

请勿手动编辑生成的 GraphQL 文件。

packages/payments 目录下的变更必须保持向后兼容性。
```

重要的特性并非 Markdown 本身，而是可移植性。

如果同一个仓库与 Codex、Gemini CLI、Cursor、GitHub Copilot、Claude Code 以及未来的智能体共同使用，维护一套权威的项目规则集比维护六份语义相同的副本更安全。

## CLAUDE.md 与 AGENTS.md：真正的区别

Claude Code 将 CLAUDE.md 作为其原生仓库记忆机制。

这让 Anthropic 能够专门针对 Claude 模型和 Claude Code 工作流程优化指令。特定于工具的配置本身并非坏事。事实上，某些指令可能仅对 Claude Code 有用。

问题始于当特定于工具的配置成为共享仓库策略的唯一可靠路径时。

一个健康的区分是：

| 文件 | 最佳角色 |
| --- | --- |
| AGENTS.md | 供应商中立型仓库策略和项目知识 |
| CLAUDE.md | Claude 特定行为、工作流程偏好和优化配置 |
| .agents/skills/ | 可移植、可复用的智能体能力 |
| .claude/skills/ | Claude Code 特定或为 Claude 优化的技能 |

这种分层模型允许团队保持项目真实性的独立，不受当前季度流行的智能体影响。

## 在代码仓库中，“分裂脑”意味着什么？

考虑一个带有嵌套指令的大型单体仓库：

```text
world/
├── AGENTS.md
├── CLAUDE.md
├── checkout/
│   ├── AGENTS.md
│   └── CLAUDE.md
├── payments/
│   ├── AGENTS.md
│   └── payments-api/
│       └── AGENTS.md
└── storefront/
    ├── AGENTS.md
    └── CLAUDE.md
```

假设 payments-api/AGENTS.md 包含一条关键规则：

```text
所有结算 API 变更必须保持向后兼容性。

修改结算状态转换前，请运行集成测试套件。
```

能够自动发现嵌套 AGENTS.md 文件的智能体可能会接收到这条规则。

而一个仅依赖不同 CLAUDE.md 文件层次结构的 Claude Code 会话，除非仓库刻意镜像或导入该规则，否则可能无法获得相同信息。

因此，两位工程师可以要求不同的智能体修改同一个包，却在无意中赋予这些智能体不同的策略集。

这就是分裂脑现象：

```text
仓库真实性
 |
 +--> 智能体 A 看到根目录 + payments + payments-api 规则
 |
 +--> 智能体 B 仅看到根目录 + payments 规则
```

代码是共享的。AI 上下文却不是。

对于小项目来说，这可能只是一个不便之处。对于大公司而言，这就变成了一个工程治理问题。

## 为什么符号链接不是完整的企业解决方案

显而易见的变通方法很简单：

```bash
ln -s AGENTS.md CLAUDE.md
```

另一个选项是创建一个导入共享指令的 CLAUDE.md 文件：

```text
@AGENTS.md

## Claude 代码

对 src/billing/ 下的更改使用计划模式。
```

这两种方法都很有用，对于中小型仓库来说可能完全合理。

难点不在于变通方法是否有效，而在于如何确保在庞大的目录树中任何地方它都不会失效。

在大规模场景下，团队必须回答以下问题：

- 每个嵌套的 AGENTS.md 是否都有对应的 Claude 可见路径？
- 当团队创建新包但忘记适配器时会发生什么？
- 符号链接在 Windows 和每个开发环境中是否都能一致处理？
- 生成的 CLAUDE.md 是否会与规范的 AGENTS.md 文件产生偏差？
- CI 是否会验证这种关系？
- 本地覆盖是否能被一致地解释？
- 迁移工具是只复制配置一次，还是能随时间保持同步？

因此，这种变通方法可能会创建一个额外系统，而这个系统本身需要测试、代码检查、自动化和所有权归属。

这就是为什么分歧最好理解为复杂性成本问题，而非 Markdown 技术问题。

## 为什么 Shopify 是一个重要的测试案例

Shopify 已经围绕 AI 代理重组了其工程环境的重要部分。

其名为 World 的大型单体仓库不仅仅是一个代码容器。Shopify 将其描述为同时承载代码、技能、规范、意图文档、运维手册、AGENTS.md 文件以及书面领域知识的平台。

这很重要，因为仓库指令不再只是装饰性文档。它们正逐渐成为机器可读的组织记忆。

Shopify 的内部代理 River 体现了所涉及的规模。据报道，在 30 天的时间里，River 处理了数万个会话，涉及数千个 Slack 频道，并共同编写了数千个已合并的拉取请求。

River 构建于 Shopify 的代理平台 Aquifer 之上，该平台分离了持久会话、代理框架、沙箱环境、凭据管理、网关和可观测性。

该平台的重要架构目标之一是可替换性：模型、运行时和框架实现应该能够更换，而无需强制整个系统随之改变。

将仓库知识层紧密绑定到单一供应商的作法，违背了这一哲学理念。

## 深层架构：仓库知识应比智能体更持久

从Shopify争议中最重要的启示是，代码仓库正演变为AI运行时环境。

历史上，一个仓库包含：

```text
README.md
package.json
.gitignore
CI配置文件
源代码
测试文件
```

而面向智能体就绪的仓库正逐渐包含：

```text
README.md
AGENTS.md
技能目录/
执行手册/
架构决策记录
工具策略
评估规则
自动化钩子
仓库专属记忆
```

这些文件的价值可能持续数年。

团队使用的AI编程工具可能每几个月就会更换。

由此导出一个核心设计原则：

> 持久的项目知识应比任何单一智能体供应商的生命周期更长。

这也是为什么团队更倾向于采用可移植标准来管理环境变量、包元数据、版本控制和协议接口。

## Claude Code当前支持的功能

截至2026年8月26日，Claude Code已具备有意义的互操作性特性，但其原生项目记忆模型仍以CLAUDE.md为核心。

| 功能 | Claude Code状态 |
| --- | --- |
| 原生CLAUDE.md项目记忆 | 支持 |
| 嵌套CLAUDE.md加载 | 支持 |
| CLAUDE.local.md | 支持 |
| 在CLAUDE.md中导入AGENTS.md | 支持 |
| 将CLAUDE.md符号链接至AGENTS.md | 支持 |
| 原生自动发现AGENTS.md | 尚未作为默认文档化行为 |
| /init可通过新版初始化流程检查AGENTS.md | 支持 |
| /import可迁移支持的智能体配置 | 支持 |
| .claude/skills/ | 原生支持 |
| .agents/skills/作为文档化原生搜索路径 | 尚未与.claude/skills/同等支持 |

这个差异很容易被忽视。

迁移支持不同于持续的原生发现能力。

如果/import将指令复制到Claude配置中，除非生成的配置引用了规范文件，否则对原始AGENTS.md的后续修改仍需同步策略来维护一致性。

## 为何 .agents/skills/ 属于同一议题范畴

仓库指令（repository instructions）回答的是类似以下的问题：

> 在这个项目中，智能体应该如何运作？

而技能（skills）则回应另一类问题：

> 当智能体需要执行特定任务时，它可以加载哪些可复用的能力？

一项技能可能包含以下结构：

```text
发布检查/
├── SKILL.md
├── 脚本/
├── 参考/
└── 资源/
```

例如，一项发布技能可以教导智能体如何：

- 验证变更日志；
- 检查版本规则；
- 运行发布测试；
- 验证软件包来源；
- 生成发布检查清单。

智能体技能格式（Agent Skills format）关注的是技能的结构和渐进式加载行为。`.agents/skills/` 这个位置已经逐渐成为跨客户端互操作性的一种约定，而非核心格式定义的唯一可能安装位置。

这个细微差别很重要。

生态系统正在同时标准化两个不同的层面：

1.  智能体技能的格式；
2.  多个客户端应该发现技能的位置。

Shopify的请求连接了这两个层面，因为如果每个编码智能体都需要不同的目录布局，那么一个便携的技能就没那么有用了。

## 为何 Anthropic 可能仍需要 CLAUDE.md

从 Anthropic 的角度来看，也存在一个合理的、技术性的论点。

不同的模型家族不一定对完全相同的系统指令做出最优反应。

一个 Claude 专属的文件可以表达如下偏好：

```text
@AGENTS.md

## Claude 特定指导

对于复杂的重构：
- 在编辑前检查相邻的抽象层；
- 在处理超过三个包之前使用规划模式；
- 保持实现笔记简洁；
- 在结束前验证生成的工件。
```

这种配置可以与一个便携的基础配置共存。

错误在于将可移植性和模型特定的优化视为互斥的。

更强大的架构是：

```text
          仓库
            |
         AGENTS.md
      共享项目策略
            |
      +-----+-----+
      |     |     |
   Claude   Codex  Gemini CLI
      |     |     |
 CLAUDE.md 覆盖  覆盖
  可选调优
```

在这个模型中，厂商配置成为一个覆盖层，而非重复的信息来源。

## AGENTS.md 正成为生态系统标准

这一论点之所以重要，还因为 AGENTS.md 已不再是一种小众规范。

自 2025 年 8 月发布以来，该格式已被超过 60,000 个开源项目和智能体框架采纳。这一生态系统涵盖了主流的代码智能体产品和开发环境。

2025 年 12 月，AGENTS.md 被贡献给 Linux 基金会旗下的 Agentic AI 基金会，为该规范创建了一条中立治理路径。

Anthropic 本身是更广泛基金会工作的一部分，而它的 Model Context Protocol（MCP）代表了开放式智能体基础设施的另一重要组成部分。

这形成了一个重要的战略模式：

- MCP 标准化智能体如何连接到工具和数据。
- AGENTS.md 标准化代码仓库如何传达项目指令。
- Agent Skills（智能体技能）标准化可复用的程序知识包。
- 供应商特定文件针对特定智能体的行为进行优化。

这些层级解决了不同问题，并且可以协同工作。

## 正在形成的开放式智能体栈

一个成熟的、已准备好接入智能体的项目最终可能呈现如下结构：

```text
项目目录/
├── AGENTS.md
├── .agents/
│   └── skills/
│       ├── deploy/
│       │   └── SKILL.md
│       ├── database-migration/
│       │   └── SKILL.md
│       └── security-review/
│           └── SKILL.md
├── CLAUDE.md
├── .claude/
│   └── skills/
├── .cursor/
├── package.json
└── src/
```

长期目标不应是消除每一个供应商目录。

目标应该是让供应商目录成为可选的专项化层级。

一个团队应该能够在更换代码智能体时，不丢失项目的架构记忆。

## 当前多智能体团队的实用设置

在原生行为统一之前，团队可以采用规范源策略来降低风险。

### 1. 将共享策略置于 AGENTS.md 中

将架构、命令、测试、安全规则和目录特定的约束保留在这个可移植的文件中。

避免将核心的仓库“真相”仅存放在 CLAUDE.md 中。

### 2. 让 CLAUDE.md 导入规范文件

```text
@AGENTS.md

## Claude Code 特定指令

对于跨包重构，优先使用计划模式。
```

这样可以保持低重复率，同时保留 Claude 特定的调优。

### 3. 为嵌套文件添加 CI 检查

大型单体仓库应该能够检测到何时创建了新的嵌套 AGENTS.md 文件，却没有兼容的 Claude Code 路径。

一个概念性的检查可能强制执行：

```text
对于每一个嵌套的 AGENTS.md：
  验证 Claude Code 能够访问到相同的规范指令
```

具体实现取决于仓库层级结构和所选择的导入策略。

### 4. 测试代理上下文，而不仅是文件

仓库可能包含正确的 Markdown 文件，却仍加载了错误的上下文。

团队应定期验证：

- 代理实际加载了哪些记忆文件；
- 当前工作目录下哪些嵌套指令生效；
- 导入的内容是否为最新状态；
- 是否存在冲突规则；
- 本地配置是否无意中覆盖了共享策略。

### 5. 保持供应商特定指令的精简

若 CLAUDE.md 演变成第二份完整的项目手册，配置漂移几乎不可避免。

理想目标应为：

```text
AGENTS.md = 项目核心准则
CLAUDE.md = Claude 专属增量配置
```

## 常见陷阱

### 复制完整指令集

将相同的 500 行策略复制到多个供应商文件中，初期看似稳妥。

这通常是最高风险的做法——因为副本会在无声中逐渐偏离。

### 将一次性导入视为同步机制

迁移工具有助于初期适配，但不能自动保证未来的变更保持同步。

团队应明确区分：

- 复制配置
- 引用配置
- 本地发现配置

### 忽视嵌套目录语义

最严重的故障常发生在仓库根目录之下。

根目录适配器可能看似正确，但包级指令对某个代理却完全不可见。

### 混淆通用策略与模型提示调优

数据库兼容性要求等规则应属于共享项目策略。

特定模型如何规划大型重构等指令应属于供应商特定配置。

保持这两者分离能使迁移过程顺畅得多。

### 假设所有技能目录等同

即使不同客户端发现路径存在差异，技能格式本身仍可保持通用性。

团队应测试每个客户端如何发现项目级与用户级技能。

## 后续发展预测

最可能出现的结果并非 CLAUDE.md 的消失，而是更强的互操作性。

Claude Code 已为其他编程工具创建的配置强化了初始化与导入路径。Anthropic 也公开表示，优化 AGENTS.md 的使用体验是让 Claude Code 更可定制化的工作组成部分。

值得关注的重要里程碑包括：

- 无需适配器即可原生发现 AGENTS.md
- AGENTS.md 与 CLAUDE.md 优先级规则的文档化
- 原生或官方标准化的 .agents/skills/ 发现机制
- 嵌套指令文件的更明确行为规范
- 保留模型特定优化的兼容层
- 允许企业验证各工具实际加载指令的跨代理测试

这些细节将决定互操作性仅便利于个人开发者，还是足以支撑大型组织的可靠需求。

## 为何这场争论比Claude Code更重要

编码助手竞争正超越原始模型质量。

企业日益需要回答基础设施问题：

- 能否在更换编码助手时不必重写知识层？
- 技能能否在不同客户端间迁移？
- 助手能否共享相同的架构约束？
- 组织能否追溯哪些指令影响了自动化代码变更？
- 底层模型变更时助手配置能否保持有效？
- 单体仓库能否维护一套权威的AI可读策略？

这些问题的答案将决定AI编码究竟是个人生产力工具的集合，还是能成为持久的工程基础设施。

Shopify事件之所以重要，正是因为Shopify已处在这场转型的另一侧。

## 结论

只有当AGENTS.md被视为普通文本文件时，Tobi Lütke对Claude Code的批评才显得微不足道。

在企业级场景中，它代表着更重要的内核：机器可读工程知识的归属权与可移植性。

Claude Code的CLAUDE.md仍适用于Claude专属优化。AGENTS.md则适用于厂商中立的知识库事实。最稳健的未来方案很可能同时支持两者——建立明确的优先级和原生互操作性，而非强迫团队重复配置。

对于当前使用多种AI编码助手的工程团队，实用原则很简单：保持共享项目知识规范化，保持厂商专属层级精简化，并验证助手实际加载的上下文。

下一阶段AI编码的赢家，或许不是那些拥有最多专有配置的工具，而是那些能最简洁融入开放、可移植助手生态的工具。