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

关键要点

• 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的识别机制。

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可以告知智能体：

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

简化示例如下：

# 仓库使用说明

包管理器：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 有用。

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

一个健康的区分是：

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

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

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

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 包含一条关键规则：

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

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

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

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

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

这就是分裂脑现象：

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

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

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

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

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

ln -s AGENTS.md CLAUDE.md

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

@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运行时环境。

历史上，一个仓库包含：

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

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

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

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

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

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

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

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

Claude Code当前支持的功能

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

这个差异很容易被忽视。

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

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

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

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

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

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

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

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

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

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

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

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

这个细微差别很重要。

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

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

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

为何 Anthropic 可能仍需要 CLAUDE.md

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

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

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

@AGENTS.md

## Claude 特定指导

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

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

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

更强大的架构是：

          仓库
            |
         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（智能体技能）标准化可复用的程序知识包。
• 供应商特定文件针对特定智能体的行为进行优化。

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

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

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

项目目录/
├── 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 导入规范文件

@AGENTS.md

## Claude Code 特定指令

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

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

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

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

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

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

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

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

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

团队应定期验证：

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

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

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

理想目标应为：

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编码的赢家，或许不是那些拥有最多专有配置的工具，而是那些能最简洁融入开放、可移植助手生态的工具。