update · TowCue 編輯團隊
Claude Code 新增 AGENTS.md 支援：為什麼可攜式專案指令很重要
Claude Code 2.1.277 新增 AGENTS.md 支援，在專案沒有 CLAUDE.md 時可讀取共用指令。TowCue 分析這對多 Coding Agent 團隊的意義，以及部署前必須確認的限制。
快速解答
Claude Code 2.1.277 新增 AGENTS.md 支援：當專案裡沒有 CLAUDE.md 時，Claude Code 可以讀取 AGENTS.md 作為專案指令。Anthropic 的 changelog 也說明，可在 /config 的 Project instructions 調整這項行為，而且目前 Bedrock、Vertex 與 Foundry 尚未支援。
這看似只是檔名相容性更新，實際上對多 Agent 工作流很重要。使用多個 Coding Agent 的團隊，可以更接近把共用的 repository 規範放在一份可攜式指令檔，而不是為每個 Agent 重複維護同一套規則。
延伸閱讀可查看 Claude 工具頁、Codex 工具頁與 AI Agent 最佳實務。
Claude Code 2.1.277 到底改了什麼？
Anthropic 官方 Claude Code changelog 說明，2.1.277 會在專案沒有 CLAUDE.md 時讀取 AGENTS.md。這個條件很重要：目前描述的是 fallback 支援，不代表 AGENTS.md 已取代 CLAUDE.md，也不代表兩個檔案會自動合併。
Anthropic 的專案設定文件仍把 CLAUDE.md 描述為一般的專案指令檔，會在 session 開始時載入。官方建議把 repository 慣例、常用指令與架構背景放在其中，而只與特定任務有關的知識則可放進 skills 或 scoped rules。
因此，團隊應把這次更新理解成相容性提升，而不是強制遷移訊號。
為什麼 AGENTS.md 相容性值得關注？
Repository instructions 正逐漸成為程式碼庫與 AI Agent 之間的介面。
它可以告訴 Agent 應執行哪些 build、lint 與 test 指令、哪些目錄可以修改、架構如何劃分、命名規則是什麼，以及哪些操作需要人工批准。
如果每個 Coding Agent 都需要一份不同版本的規則，團隊就會產生設定漂移：某項規範可能只在一個 Agent 更新，另一個仍使用舊版本。
可攜式指令檔可以降低這種維護成本。較合理的流程是：
repository policy → Agent 可讀指令 → 有邊界的任務 → 驗證 → 人工審查
它的價值不是「一個 Markdown 檔就讓 Agent 值得信任」，而是讓重要 context 更容易重用與稽核。
Claude Code 現在會像 CLAUDE.md 一樣使用 AGENTS.md 嗎？
不能這樣假設。官方 changelog 描述的是明確 fallback：只有在沒有 CLAUDE.md 時才讀取 AGENTS.md。在 Anthropic 沒有正式文件支持前，不應自行推論 recursive precedence、自動合併或完全相同的載入行為。
另外還有部署限制。Anthropic 明確說目前 Amazon Bedrock、Google Vertex AI 與 Microsoft Foundry 尚未支援。如果組織透過這些 provider 使用 Claude Code，不應在尚未驗證前刪除或整併原本的指令檔。
低風險做法是先在團隊真正使用的執行環境測試，而不是假設本機 Claude Code 的行為在所有部署方式都一致。
TowCue 判斷：Agent instructions 正成為可攜層
真正重要的趨勢不是檔名本身。
開發團隊愈來愈可能同時使用多個 Agent：一個適合長時間自主實作，一個適合 review，另一個適合快速 terminal 任務。Repository 規則最好能在切換 Agent 時繼續存在。
因此可以把責任拆開：
- 穩定的團隊規範放在 repository-owned instructions；
- 只有真正需要時才保留 Agent-specific tuning；
- 權限與破壞性操作限制應放在可強制執行的設定，而不只寫成文字；
- tests 與 CI 繼續作為 evidence layer。
共用指令檔能提升可攜性，但不應被當成安全邊界。
Repository instructions 應該放什麼？
優先放穩定、可執行，而且一旦猜錯代價很高的資訊。
例如 build、lint、test 指令；架構邊界；不可手動修改的 generated files；命名與格式規則；必要驗證步驟；以及明確的 Git 限制。
不要把它變成超長手冊。Anthropic 文件提醒，長篇且每次都載入的 context 可能降低遵循度；只與特定任務相關的流程，更適合放進需要時才載入的 skills 或 scoped rules。
多 Agent 團隊應該如何測試？
先用一個小型 repository，設定一條容易觀察的規則，例如必須執行某個 test command，或禁止修改特定目錄。
確認安裝的 Claude Code 版本後，在沒有 CLAUDE.md 的情況下只保留 AGENTS.md，並到 /config 的 Project instructions 檢查，再觀察 Claude 是否遵循規則。接著在團隊真正使用的部署方式重複測試。
如果同時使用 Codex 或其他 Coding Agent，可用同一個有邊界的任務比較 instruction adherence、人工修正次數與驗證失敗率。
在自己的環境完成驗證前，不建議一次刪除所有 production repository 現有的 CLAUDE.md。
哪些團隊最值得關注？
已同時使用多個 Coding Agent 的團隊最直接受益，因為重複維護 instruction files 本身就有成本。Open-source 專案也可能受益：貢獻者使用不同 Agent，但都需要遵循相同 repository conventions。
如果團隊只使用 Claude Code，而且現有 CLAUDE.md 已經成熟穩定，則沒有必要只因為新功能存在就遷移。除非可攜性真的解決一個具體問題，保留現況反而是風險更低的選擇。
TowCue 判斷：標準化 context，不等於標準化信任
AGENTS.md 支援讓 repository context 更容易攜帶，但不能證明 Agent 一定會完美遵守每一條指令。
更合理的分工是：instruction files 提供 context，permissions 負責 enforcement，tests 提供 evidence，而高後果變更仍由人工 review 做最後關卡。
Coding Agent 的執行時間愈長、工具權限愈廣，這個差異就愈重要。共用 instruction format 只有在周邊工作流仍能偵測錯誤時，才真正有價值。