update · TowCue 編輯團隊
Anthropic ant apply 把 Claude Agent 變成「資源即程式碼」:團隊工作流會怎麼改變?
Anthropic 在 ant CLI 1.30.0 新增 ant apply,讓團隊把 Claude agents、環境、Skills、memory stores 與 deployments 以版本控制檔案管理。本文整理 CI/CD 工作流、lockfile、限制與適合的導入方式。
快速解答
Anthropic 在 2026 年 9 月 3 日發布的 ant CLI 1.30.0 中加入 ant apply。它讓團隊可以把 Claude Platform 上的 Agent 資源寫成 repository 內的檔案,再透過 CLI 建立或更新遠端資源。
目前可管理的類型包含 agents、environments、skills、memory stores 與 deployments。執行後,CLI 會產生 claude-lock.json,讓之後無論在開發者電腦或 CI 執行,都能更新同一批遠端資源,而不是不斷建立新的副本。
真正重要的不是多了一個 CLI 指令,而是 Claude Agent 的維運開始接近軟體團隊熟悉的流程:
定義 → review → 預覽 plan → apply → 記錄狀態 → 重複執行。
如果團隊已經把 prompts、Skills、權限、執行環境與 deployment schedule 當成生產基礎設施,這是一個很實際的進步。不過它也有需要先理解的邊界:多數既有 Console 資源不能直接被自動接管、--prune 可能移除資源、CI 必須使用非互動參數,而且 Anthropic 明確要求一次只執行一個 apply,因為 lockfile 本身沒有鎖定機制。
若要先補產品背景,可以閱讀 TowCue 的 Claude 完整評測、AI Agent 最佳實務指南,以及 Anthropic Computer Use / Browser Use / Skills / Files API GA 更新。
ant apply 到底改變了什麼?
在這項更新之前,一個團隊可能同時用 Claude Console、API、內部 script 與文件來維護 Agent。原型階段這樣做很快,但進入多人與多環境後,很容易回答不了幾個基本問題:
- 現在線上究竟是哪一版 Agent?
- 它引用哪一版 Skill?
- 綁定的是哪個 environment?
- 誰改過這項設定?
- 變更能不能先經過 pull request review?
- 能不能只靠 repository 重建相同配置?
ant apply 的價值,是讓 repository 裡的檔案成為這些資源的「期望狀態」。
Anthropic 的文件示範了以帶 YAML frontmatter 的 Markdown 定義 Agent、以設定檔描述 environment 與 memory store,並讓 deployment 透過相對路徑引用這些檔案。Apply 時,路徑會被解析到該次建立或更新的實際資源版本。
因此它更接近 resources as code,而不是一個單純方便建立 Agent 的 CLI shortcut。
真正關鍵的是 claude-lock.json
這套流程的核心其實是 claude-lock.json。
Anthropic 說明,lockfile 會記錄 repository 檔案目前對應的遠端資源。把它一起 commit 進 Git,之後的執行才知道要更新哪些既有資源,而不是重新建立副本。
可以把整個模型理解成四層:
| 層級 | 作用 |
|---|---|
| Repository 檔案 | 描述你希望 Agent 系統長什麼樣 |
ant apply plan | 顯示即將對遠端做什麼變更 |
claude-lock.json | 記錄這些檔案目前管理哪些遠端資源 |
| Claude Platform | 真正執行中的 agents、skills、environments、memory stores、deployments |
這與有狀態的 infrastructure tooling 有相似概念,但不能直接假設它與 Terraform 或 Kubernetes 的語義完全一樣。Anthropic 對 reconciliation 有自己的規則,而這些規則正是生產導入時最需要閱讀的部分。
為什麼這對 AI Agent 團隊有價值?
生產環境中的 AI Agent 已經不只是「一段 prompt + 一個 model」。
它可能同時依賴:
- Agent instructions;
- 多個 Skills;
- memory store;
- execution environment;
- tool permissions;
- 其他 sub-agents;
- deployment schedule;
- networking configuration。
如果這些設定只存在 dashboard 中,一次完整變更很難被放在同一個 review context 裡。
改成 repository 檔案之後,一個 PR 可以同時顯示「Agent instruction 修改」與「引用 Skill 變更」。Reviewer 能先看 diff,再決定是否讓遠端資源更新。
對原本就把 code review 當作 approval boundary 的團隊而言,這會比事後追記 Console 操作更容易治理。
一個實用的 CI/CD 模式
Anthropic 文件很清楚地把 PR 與 default branch 分開。
在 Pull Request 可以執行:
ant apply --dry-run .
這會顯示 plan,但不套用變更,也不寫 lockfile。Reviewer 因此可以先看到配置將對遠端造成什麼影響。
Merge 後,在 CI 執行:
ant apply --yes .
這裡的 . 很重要。Anthropic 特別提醒,若只執行裸的 ant apply --yes,它只會 reconcile lockfile 已經追蹤的檔案,新加入的 resource file 可能被跳過。
文件也要求 CI 在工作結束時 commit 更新後的 claude-lock.json,即使 apply 中途失敗也一樣,因為部分失敗仍可能已經建立資源並寫入狀態。
這代表 lockfile 不是可以隨時丟掉的 build artifact,而是部署狀態的一部分。
CI 身份驗證比長期 API Key 更合理
Anthropic 建議 CI 使用 Workload Identity Federation,而不是存放長期 API key。
CI identity 必須能存取 claude-lock.json 記錄的同一個 organization 與 workspace;如果 credential 對應到其他 organization / workspace,ant apply 會拒絕執行。
這個方向很合理,因為 deployment job 應該使用短期、可控範圍的身份,而不是把一把永久 Claude API key 放進 repository secret 後長期不動。
但團隊仍然要審核 CI identity 的實際權限。更好的 authentication mechanism 不代表可以無限制賦予 Agent deployment 權限。
生產導入前一定要理解的四個限制
1. 既有 Console 資源不會自動被接管
Anthropic 明確表示,ant apply 不能直接 adopt 透過 Console 或 ant beta:agents create 建立的資源。如果 lockfile 不知道那個遠端資源,直接套用一份看起來相同的設定,可能會再建立一份新的資源。
官方文件提供的遷移方式,是使用 Console 的 Export as code。匯出的內容會包含對應 lockfile,之後才能由 repository 繼續管理原本資源。
所以有既有 Agent fleet 的團隊應該把遷移當作一次 inventory 與 ownership 轉換,而不是直接跑 apply 期待工具自動發現所有東西。
2. Out-of-band drift 可能讓 apply 停止
如果一個已受管理的資源在 Console 被手動修改、archive 或刪除,Anthropic 說 plan 可能會直接拒絕套用。
雖然有 --force,但如果日常都靠 force 解決,resources-as-code 的治理價值就會大幅下降。
更合理的規則是:一旦資源交給 Git 管理,Console 應該盡量變成 read-mostly,只有明確的 emergency procedure 才允許人工改動。
3. --prune 具有破壞性
刪除 repository 中的設定檔,不會立刻刪除遠端資源;--prune 才會移除 lockfile 中仍記錄、但已不再宣告的資源。
Anthropic 特別指出,Skill 的移除屬於 deletion,不只是 archive。
因此 --prune 應該有比一般更新更高的 review 門檻。Protected branch 上的自動化在執行前,團隊最好能明確看到會被刪除的是哪些資源。
4. 不要並行執行 apply
Anthropic 要求一次只跑一個 apply,因為 沒有任何機制會鎖住 lockfile。
因此 CI workflow 應該加 concurrency control。即使兩個 PR 的變更各自看起來都合理,同一時間對同一套 Agent project 套用,也可能造成 state management 問題。
這是文件裡很短的一句話,但對生產環境影響很大。
GitHub-hosted Skills 可以 pin 到 commit
ant apply 可以讓 Skill 直接引用 GitHub repository URL。Anthropic 說 CLI 會下載該目錄,並把它 pin 到 lockfile 所記錄的 resolved commit。
只有在執行 --upgrade 時,才會重新解析較新的 commit。
這對可重現性很重要。Agent 不應該每次部署都默默抓到不同版本的 Skill;pinning 讓 dependency 固定,而 upgrade 則變成一個可以被 review 的動作。
如果是 private repository,官方文件說可以使用 GITHUB_TOKEN 取得內容。
真正的價值不是能貼 GitHub URL,而是 Skill 開始更像可追蹤版本的 dependency,而不是一個永遠指向「最新」的可變外部引用。
哪些團隊現在最值得測試?
已有多個 Claude Agents 的團隊
如果你已經有多個 agents、skills、environments 與 deployments,降低配置漂移與重建成本會很有價值。
最好的第一個目標不是關鍵生產 Agent,而是一個配置已經充分理解、錯誤影響有限的內部 Agent。
Platform / DevOps 團隊
如果組織希望 Agent 變更走完整的 branch → PR → automated checks → approval → merge → deployment 流程,這項更新非常值得關注。
它比圍繞 API 自行堆很多 ad hoc scripts 更容易形成一致治理。
只有一個原型 Agent 的小團隊
如果目前只有一個 prototype,沒有 CI/CD,也沒有多環境需求,那 ant apply 可能暫時比實際需求更重。
探索階段 Console 仍可能更快。當「可重現、多人協作、變更可追蹤」開始比「設定速度」重要時,再切換會更划算。
一個低風險導入方式
TowCue 不建議一次遷移所有 Claude 資源。
可以先選一個邊界清楚的 Agent project:
- 用 Export as code 或手動定義方式把 Agent 與 dependencies 變成 repository files。
- 將設定與 lockfile 一起 commit。
- 在 Pull Request 加入
ant apply --dry-run .。 - Merge 前要求人工檢查 plan。
- 只允許 protected default branch 執行
ant apply --yes .。 - 用 CI concurrency control 確保 apply 序列化。
- 使用 Workload Identity Federation,而不是長期 API key。
--prune與--force不放進一般流程,只有明確 review 後才使用。- 已由 Git 管理的資源,把 Console 視為 read-mostly。
- 正式上線前,先演練 rollback 與 partial failure。
這樣做,ant apply 才會從「新指令」變成真正的 operating discipline。
TowCue 觀點
ant apply 值得關注,是因為它改善的是 operability,而不是模型 IQ。
Agent 系統已經複雜到 prompts、Skills、environments、memory、permissions 與 deployment schedules 都需要軟體基礎設施早已具備的特性:
版本歷史、code review、可重現性、明確 state、CI authentication,以及受控 rollout。
它並沒有讓 Agent deployment 自動變安全。Anthropic 自己的文件也清楚列出 adoption、drift、prune、partial failure 與 concurrent apply 等邊界。
但這些細節反而說明 Agent 平台正在成熟。問題已經慢慢從「我要怎麼建立一個 Agent?」變成:
「當我有一整批 Agent 之後,要怎麼確保團隊始終知道線上到底部署了什麼?」
對已經超過 prototype 階段的團隊來說,這比另一個 benchmark 提升更值得關注。
研究來源
- Claude Platform release notes — 2026 年 9 月 3 日
- Claude Platform Docs — Manage resources as code with ant apply
- Anthropic ant CLI repository