AWS Emulator 解讀：AI 代理寫出本機雲端，測試通過能相信多少？（2026）

2026 年 11 月 11 日，Swami Sivasubramanian 在 Werner Vogels 的 All Things Distributed 發布客座文章〈AWS Emulator and the engineer’s job when agents write the code〉，介紹 AWS Emulator 與代理寫程式後的工程分工。Werner 撰寫的是開頭引言。這次最值得追問的，是代理有了 AWS 推出的本機測試選項之後，我們該相信哪一種「測試通過」？

先讀作者如何把測試環境放進代理的工作迴圈，再核對公開文件的能力邊界，最後決定它適合接走哪一段工作。本機跑通可以縮短回饋路徑，正式環境的權限與完整行為仍要另行驗收。

一、AWS Emulator 的故事，從「怎麼知道寫對了」開始

原文回到 AWS 早年的分散式鎖服務 Alf：團隊把網路與伺服器環境放進可控制的模擬中，重排事件、注入故障，再搭配形式推理找錯。Swami 的重點是，程式需要一個能暴露錯誤的世界；模擬之外，真實環境也會揭露另一批問題。

今天同一個問題進入代理開發。代理可以寫一段程式、執行、讀回結果，再決定怎麼改；若每次碰到雲端依賴都要等待部署，回饋就拉長。作者把 AWS Emulator 放在這個位置：讓代理在本機取得服務行為的回應。

他把工程師的工作重心放在規格、測試與合併關卡；文中重寫舊複寫引擎的短時間案例，則是個人經驗，不能直接換算成一般開發的效率倍數。這條分工也可對照 Agent Harness 的基本觀念：能動手只是起點，還要有工具、狀態與完成條件。

二、AWS Emulator 提供的是本機 API 環境，服務數不等於保真度

It runs free and offline on your own machine.

中文：它可在你自己的電腦上免費、離線執行。

Swami Sivasubramanian，All Things Distributed，2026 年 11 月 11 日

這是原文最直接的產品承諾。同文說它建立在超過 400 個 API 模型上，涵蓋超過 200 項 AWS 服務；這些是作者對發布範圍的描述，不能讀成每項服務的所有行為都已完整重現。

官方使用指南把它定義為本機 AWS API 模擬器。應用透過 AWS CLI 或 SDK，把請求送往本機端點；使用模擬器不需要 AWS 帳戶。它沒有額外服務費，實際部署到 AWS 所使用的資源則另計費。本機 CPU、記憶體與建置工作也仍有自己的成本。

Linux 可用 RPM 或 Debian 套件；macOS 與 Windows 走 Docker 路徑。Rust 測試另有嵌入同一程序的模式。這些是不同的整合入口，本文沒有在本次環境執行模擬器，因此不提供 AlphaLab 的相容性或速度成績。

用一個簡化情境理解：你的程式建立物件儲存空間、寫進測試檔，再讀回。若對應行為在這一版模擬器成立，代理就能先檢查資料流；這一步的價值是提早發現應用錯誤，而不是證明雲端的每個運作條件都相同。

三、保真度怎麼量？看同一個工作流程，而非只看成功回應

這套建置方法有兩個參照：公開的 Smithy API 模型描述操作、輸入、輸出與錯誤；真 AWS 提供實際行為。代理先產生情境測試並確認它在真 AWS 成立，再讓模擬器通過同一份測試。原文用 SQS 的訊息可見性逾時作例子：重點是訊息被接收後，其他讀取者在等待期間看見什麼，而非僅確認收到一個成功代碼。

在 AWS 的 fidelity 定義裡，一項測試會走完 SDK 工作流程，比對回應、資源狀態與副作用；遇到錯誤呼叫，也要對上 AWS 的錯誤。尚未實作的操作會回傳 HTTP 501／NotImplemented。官方目前說，控制平面 API 的吻合程度較高；資料平面與基礎設施即程式碼工具的支援則依服務而異。

白話說，「建立一個資料庫資源成功」和「資料庫對所有查詢都正確」是兩道題。測試有沒有真的跑到你的讀寫、順序與錯誤分支，比服務名稱出現在清單更接近採用決策。

官方 公開測試庫提供測試程式、manifest 與 runner。README 說這些題目先在真 AWS 沙盒帳戶驗證，再用來檢查模擬器；這仍是 AWS 維護的測試證據，並非外部單位替所有行為背書。

每次發布的分數，要連同模擬器 commit 與考卷版本一起保存。假設你的版本通過更多題，新增考題卻揭露更多缺口，百分比仍可能下降。因此，先確認考的是同一份題目，再比較分數；再好的整體分數，也不能替未被覆蓋的工作流程作答。想練習把「看起來能用」寫成明確測項，可接著讀 AI Evals 的驗收方法。

四、上線前的界線：權限、帳戶、區域與執行環境

這裡有一條不能省略的官方限制：安全文件明確要求，別用模擬器判斷應用是否安全。部分服務會評估模擬環境裡建立的 IAM 使用者或角色政策，但方式不等同 AWS；AWS KMS 金鑰政策、S3 bucket policy 等也有明列缺口。真 AWS 會拒絕的請求，可能在模擬器成功。

「這段程式能完成工作」與「這個身分應該被允許完成工作」必須分開驗。程式庫內多一位安全審查代理，也不會自動補齊模擬器的授權語意。這與 AlphaProof Code 的證明範圍有相通的閱讀原則：先看它保證的是哪個命題，再談「安全」兩個字。

官方也要求，一個模擬器的請求使用同一個帳戶與區域，因為它不會像真 AWS 那樣完整隔離不同帳戶或區域的資源。分別啟動程序，可提供各自的測試環境；跨帳戶授權、跨區域互動仍需要對應的真 AWS 驗收。資料保留在記憶體，停止時會清除，也應納入測試設計。

還有一個容易被「本機」掩蓋的細節：官方指出，模擬器替你執行函數等程式時，並不把該程式與主機隔離；它可用執行者的權限存取檔案。保持端口私有、只用測試資料、移除真 AWS 憑證，以及只執行可信程式，是這個產品具體要求的使用邊界。把身分留在本機，也不代表別的程序無法借用能力，SSH agent 轉送的案例可幫你理解這個差別。

五、全由代理寫程式，真正公開的是哪一層證據？

Matthew Goldberg 在 Amazon 的建置說明表示，團隊未撰寫或人工審閱模擬器程式碼。他描述三種代理工作：出題並對照真 AWS、找行為差異、修正問題；變更還要經過建置、審查、安全與保真度關卡，之後才進入發布流程。

這是專案負責方的自述。公開程式與測試讓外界能檢查部分成果，但不能僅靠作者欄位，獨立證明整個開發過程完全沒有人工介入。另一方面，「由代理寫」也不足以推出成品必然差；應把判斷落在可檢查的行為、缺口與回歸。

授權也要讀到例外。2026 年 11 月 12 日查閱的 官方 repository README將主要軟體列為 CC0 1.0，而 vendor 目錄程式碼採 Apache 2.0。公開可讀、授權條件與保真度是不同維度；CC0 本身不提供應用正確性的測試結果。

同一份 README 也說，完整原始碼建置需要預留至少 100 GB 給 target 目錄；嵌入模式首次建置也會編譯服務 crates。對只想評估一條流程的團隊，先用官方套件或文件的容器路徑，比為了讀一篇發布消息就重建整套環境更合適。

六、離線可跑，還要另外決定遙測設定

「請求留在本機」和「程式預設不對外傳送任何資料」是兩件事。官方遙測文件說，匿名使用與錯誤資料預設開啟，可關閉；列出的內容包含環境、版本、操作次數與結果類別。文件也明確排除請求／回應內容、程式碼與憑證等資料。

若你的測試要求不送出遙測，可在啟動程序時使用官方列出的 aws-emulator --telemetry off。Docker 內要把參數或環境變數交給容器中的程序，不能只在外面的 shell 設定就當成完成。這是資料流設定，應和 SDK 的本機端點一起核對。

七、AlphaLab 的判讀：代理可以擴大實作，驗收責任需要更清楚

我同意：把可查驗的世界放進工作迴圈

對代理開發而言，便宜、可重開的測試環境有合理價值。每次改動後都能觀察結果，才有機會在提交之前抓到錯誤。值得借用的，是「明確介面＋真實參照＋可重跑考卷＋合併門檻」這個組合；把一次提示寫得更長，並不會自然得到同樣的回饋。

我存疑：同一套代理同時擴充實作與考卷，能抓到多少共同盲點

代理可以把測試寫得與自己的實作一致，兩者卻一起漏掉使用者真正需要的條件。先對真 AWS 驗題能降低這個風險，但公開的已知題目仍有範圍。我的採用標準會再加一組由應用團隊預先保留、貼近實際失敗方式的工作流程，避免把通過率當成完整性。這是評估設計上的要求，不是指控本次專案曾修改考題掩蓋失敗。

服務覆蓋越廣，越要把缺口放回你的依賴圖

如果你的應用只依賴少數操作，全站服務數的意義有限。反過來，一個跨服務流程只要有關鍵一環行為不同，就可能在本機成功、部署後失敗。比起追求一個總分，先把建立、讀寫、重試、刪除與拒絕條件列出來，才能看出哪些測試適合留在本機。

安全代理審查程式，和應用授權驗收要各自有關卡

前者問的是變更是否引入可利用的問題，後者問的是指定身分與資源政策，在真實環境中是否允許或拒絕指定操作。兩個問題都重要，也需要各自的證據。工程師工作重心若真的往驗收移動，這種問題拆分會比合併了多少行程式更值得衡量。

八、現在怎麼用這個消息？先挑一條流程，留下兩份結果

不用先遷移全部 CI。依 官方專案相容性檢查方法，先列出一條既有測試呼叫的 AWS 操作，在公開 manifest 裡找對應題目，再核對所用 release 的服務分數與未通過項目。

先留下什麼	用來回答哪個問題
模擬器版本、commit、SDK 與考卷版本	下次比較時，是否仍在看同一組條件？
操作清單、測試資料、預期狀態與錯誤	這條流程需要哪些可觀察行為？
本機結果與真 AWS 對照結果	哪一項差異會阻止採用？
真 AWS 權限與跨帳戶／區域測試	本機之外的部署條件有沒有另外驗收？

真 AWS 對照使用你已授權的測試環境與預算，並保存清理紀錄；本機端則把真憑證移開、確認端點與遙測設定。對照通過的部分，再逐步放進快速回歸流程；關鍵權限與部署前整體測試保留在真 AWS。若想從另一個 Amazon 案例學習「成本下降與品質驗收分開看」，可讀 Strands Decider 的工單成本分析。

AWS Emulator 最有價值的承諾，是把更多回饋搬到開發者身邊。下一份值得追的證據，是你的應用能否在固定版本、明確失敗條件與真實對照下，持續得到相符結果。先讓代理在本機發現錯誤，再讓真實環境決定能否交付。