AWS 推出 Agent Toolkit 給寫程式代理

AWS 推出 Agent Toolkit for AWS，讓 coding agents 透過受控方式操作 AWS API。

AWS 這次不是在講 AI 概念。它直接把工具做出來了。重點是，這套東西要給 Claude Code、Cursor，還有其他支援 MCP 的 agent 用。

說白了，就是讓 agent 不要再亂猜 AWS 文件。AWS 這次主打的是 Agent Toolkit for AWS、MCP、技能包，還有稽核控管。這組合很實際，也很 AWS。

AWS 這次到底送了什麼

這套 Agent Toolkit for AWS 主要有三塊。第一塊是 managed MCP server。第二塊是 Agent Skills。第三塊是各種 agent 外掛。

這三塊合起來，就是讓 AI agent 可以查 AWS 文件、跑核准過的指令，還能照著 AWS 的流程走。這比叫模型自己瞎掰，可靠多了。

最核心的東西是 MCP server。AWS 把它做成遠端、受管理的服務。agent 透過 MCP 連進去，不用每個工具都客製整合一次。

這件事的價值很直白。模型訓練資料會過期。AWS 產品更新很快。你今天問對了，明天可能就不對了。

• agent 不必在本機安裝 AWS CLI。
• 沙箱 Python 腳本會隔離執行。
• 文件查詢是即時的。
• CloudWatch 與 IAM 可追蹤 agent 行為。

為什麼 AWS 要加技能包

很多 coding agents 其實很會寫看起來合理的 code。問題是，一碰到 AWS，就容易選錯服務。再來就是權限、部署、網路設定，全部都會卡住。

AWS 的解法不是叫模型變更大。它是把 context 做得更準，把執行規則做得更緊。這個方向我覺得很務實。

Agent Skills 就是這個思路的核心。它把 instructions、scripts、reference material 包成一組。agent 只載入當下需要的那包，不是把整座 AWS 文件山塞進 context window。

“MCP is an open standard for connecting AI agents to external tools and data sources.” — Model Context Protocol

這句話很重要。因為它解釋了 AWS 為什麼選 MCP。只要 agent 會講 MCP，就能找工具、送結構化輸入、拿結構化輸出。

AWS 也說，這些 skills 有經過測試與評估。它們包含 service decision guides、逐步流程、故障排除指南。像是建立 S3 Tables、設定 Glue ETL、調 IAM policy，或部署 serverless app。

• 服務選擇指南，幫 agent 避免選錯產品。
• 步驟流程，適合重複性高的工作。
• 故障排除指南，處理常見錯誤。
• 技能可預載，也可在執行時動態抓取。

安全性才是這次的重點

展示 demo 很簡單。讓 agent 真的去動 AWS 資源，才是麻煩開始的地方。你會想知道它改了什麼、什麼時候改的、是不是符合公司政策。

AWS 這次把 CloudWatch metrics、CloudTrail audit logging、IAM access controls 一起放進來。它還加了 aws:CalledViaAWSMCP condition key。這個設計很像是在說：人和 agent，要分開看。

這種分法對企業很重要。人類可能有一組寬鬆權限。agent 走 MCP 時，卻可以套另一組更嚴的規則。這樣比較像能上 production 的東西，不像玩具。

另外，AWS 說這套工具本身不用額外付費。聽起來很佛。可是別忘了，agent 打到的 AWS 資源還是照算。工具免費，不代表 prompt 不會燒錢。

跟 AWS Labs 舊工具比，有差嗎

AWS 這次其實是把舊的 AWS Labs MCP server、skills、plugins 整理成正式版本。差別不只是包裝變漂亮。

新的 toolkit 多了 agent-specific IAM condition key，也多了更清楚的 audit controls。AWS 還說，這些 skills 是經過評估的，不是隨便丟一包腳本就上線。

如果你是平台團隊，這種差別很有感。因為你不想每次都靠人盯著 agent 跑。你要的是可控、可查、可回溯。

• 舊版 AWS Labs 工具：開源、可用、但比較分散。
• 新版 Agent Toolkit：集中管理，更新也比較一致。
• 安全模型：能分人類操作與 agent 操作。
• 可觀測性：CloudWatch 與 CloudTrail 都接上了。

還有一個很實際的點。Claude Code、Cursor、Codex 這些工具，安裝都很快。對已經在玩 coding agents 的團隊來說，這降低了試用成本。

我覺得 AWS 的策略很清楚。它不是要 agent 取代工程師。它是要 agent 先做低風險、重複性高的 AWS 工作。像是建 VPC、接 Lambda、查部署失敗原因，這些都很適合先丟給它。

真正的問題只有一個。你願不願意讓 agent 碰你的 AWS 帳號。這題沒有漂亮答案。只有風險控管。

數字上看起來，AWS 這次很有料

如果只看數字，這次 release 不小。300+ AWS services、15,000+ API actions，這代表它不是只包幾個玩具功能。

而且它還把支援面拉到 Claude Code、Cursor、Codex。這表示 AWS 不打算綁死單一 agent。它想吃整個 coding agent 生態。

另一個重點是 $0 的額外費用。這個很會打。因為很多團隊根本不是卡在授權費，而是卡在導入摩擦。AWS 這次把門檻壓低了。

• 300+ 服務覆蓋，適合跨團隊共用。
• 15,000+ actions，表示可做的事很多。
• $0 額外費用，適合先做內部試點。
• 多 agent 支援，降低被單一工具綁住的風險。

但別太快高潮。工具免費，不代表使用成本低。agent 如果一直重試、一直查文件、一直打錯服務，Token 和雲端費用還是會上去。

所以我會把這套東西看成一個測試平台。先拿它做低風險任務。看 agent 是真的省時間，還是只是更會花錢。

這波對台灣團隊有什麼意思

如果你在台灣做 SaaS、內部工具、或雲端維運，這東西其實很有感。很多團隊早就開始用 AI 寫 code。只是碰到 AWS 時，大家還是得回頭翻文件。

現在 AWS 直接把 context、流程、稽核都塞好。這對平台工程師、DevOps、甚至小型新創，都很實用。尤其是人少、事情多的團隊。

但導入時還是要保守一點。先從只讀查詢開始。再來是低風險部署。最後才是會改 production 的操作。

我會建議先看三件事。第一，agent 會不會選錯服務。第二，它會不會亂打權限。第三，CloudTrail 能不能清楚看出它做了什麼。

接下來該怎麼看

AWS 這次的方向很明確。它想把 coding agents 拉進 AWS 的日常工作流。不是做 demo 而已，是要真的進到部署、排錯、設定權限這些流程。

接下來最值得觀察的，不是功能還會不會增加，而是企業會不會真的放手。只要團隊開始把 IAM、VPC、Lambda 這些任務交給 agent，這套工具就不只是新玩具。

我的建議很簡單。先挑一個低風險 AWS 任務試跑。看 agent 會不會亂猜、亂改、亂花錢。這比看發表頁面準多了。