AWS 把 Prompt 優化做成 A/B 測試：AI 代理人上線後怎麼改才不翻車？

代理人上線後，一段看起來更好的 prompt，有時比換模型更容易把風險帶進 production。

一個團隊準備更新客服代理人的 system prompt。新版本在幾個失敗案例上表現比較好：它更會拒答高風險要求，也比較少漏掉退款政策。

但發布會議裡的討論不會停在「這段 prompt 寫得漂不漂亮」。團隊要判斷的是：它有沒有讓其他任務變差？它是不是只迎合了一個 evaluator？如果把 20% 真實流量切給新版本，指標會不會倒退？

AWS 5 月 4 日推出 Amazon Bedrock AgentCore 的 quality optimization preview，重要的地方在這裡。它把代理人品質改善做成一條發布流程：從 production traces 找失敗模式，產生 recommendation，用 batch evaluation 或 simulated dataset 測試，再透過 AgentCore Gateway 做 live A/B test，最後由團隊決定 promote 或 rollback。

這比較像代理人時代的 release management：prompt 和 tool description 也要像程式碼一樣，有 evidence、test、traffic split 和回復路徑。對已經把 agent 放進 production 的團隊來說，這比多一個漂亮 demo 更接近真實痛點。

Prompt 不能只靠手感進 production

很多 agent 失誤不會一上線就爆炸，而是慢慢漂移。模型版本變了、使用者問法變了、工具描述過時了、原本只在 demo 裡成立的 system prompt 被搬到 production。

AWS 的說法是，quality optimization 會讀 AgentCore Observability 裡的 production traces，也會看 AgentCore Evaluations 的結果，替指定 evaluator 產生 recommendations。現在 preview 的主要修改面是 system prompt 和 tool descriptions。

這個範圍很重要。它不會任意改 code，也不會接管整個 agent runtime。AWS 文件裡還特別把 configuration bundle 和 runtime endpoint 分開：如果改的是 prompt、model ID、tool description，會進入 immutable configuration bundle；如果是 code changes，應該走另一個 runtime endpoint。

對導入團隊來說，這代表兩件事：

第一，prompt 變更不應該只靠資深工程師讀 trace 後手修。第二，就算系統幫你提出 recommendation，也還只是候選版本，還沒有資格直接進 production。

AWS 把改善流程拆成五站

這次最值得拆的不是單一功能，而是整條 loop。它把「我看 trace 後覺得應該這樣改」變成一條可被追問的發布流程。

站點	AgentCore 做什麼	團隊要檢查什麼
Production traces	從實際執行紀錄裡找失敗模式	trace 是否代表真實風險，還是只是一群特殊案例
Evaluator	用指定 evaluator 當 reward signal	evaluator 量到的是安全、正確、成本，還是表面格式
Recommendation	產生 system prompt 或 tool description 修改建議	recommendation 是否把行為寫得更窄、更可測
Batch / simulation	用資料集或模擬使用者測候選版本	測試集是否涵蓋已知回歸場景
A/B test	透過 Gateway 將部分 live traffic 切到新版本	traffic split、confidence、rollback 是否可執行

這張表也是讀這則新聞的實用方法：不要只問「AWS 新增了什麼按鈕」，要看它是不是把 agent quality 從一次次手動調 prompt，推向一條可審查的發布管線。

AWS 在文章中也提到 confidence intervals 和 statistical significance。這些字眼不能被理解成「品質保證」。它們只能說明，在你定義的 evaluator 和流量條件下，新版本是否比舊版本更可能表現好。

如果 evaluator 很弱，A/B test 只會幫你更有把握地優化錯東西。

Preview 能改什麼，不能改什麼

現在可以合理說的是：AgentCore quality optimization 把 traces、recommendations、evaluations、simulations 和 A/B tests 放到同一條產品路徑裡。

現在不該說的是：代理人可以自己修好自己。

AWS 的來源把開發者放在流程裡。團隊要指定 evaluator，選擇是否生成 recommendation，決定要不要跑 batch evaluation，安排 A/B test，也要決定最後是否 promote。這些步驟不是裝飾，它們正是風險控制點。

還有一個邊界：recommendations 目前集中在 system prompt 和 tool descriptions。這很合理，因為它們是 agent 行為最常被調整、也最容易漂移的部分。但這也表示它不能解掉所有 production 失誤。錯的工具權限、缺的資料連線、錯誤的業務流程、低品質 evaluator，仍然要由團隊自己處理。

Evaluator 才是新的控制點

這則新聞的後果，會落在 evaluator。

以前團隊常把 prompt 當控制點：誰能改 system prompt，誰就能改 agent 行為。AgentCore 這條路徑出現後，控制點往前移了一格：誰定義 evaluator，誰就在決定 recommendation 被獎勵什麼。

一個客服 agent 可以被要求更快結案，也可以被要求更少犯規；一個研究 agent 可以被要求引用更多來源，也可以被要求少浪費 token。不同 evaluator 會把同一批 traces 推向不同 recommendation。

所以導入前要看的，不只是「能不能自動優化 prompt」：

1. evaluator 代表哪個業務目標；
2. 測試集有沒有負例與回歸案例；
3. A/B test 的成功指標有沒有副作用；
4. promote 之後誰負責監控 rollback。

這四項檢查，比任何一段新 prompt 都更接近 production quality。

上線後的 Prompt 需要 Release Owner

AgentCore quality optimization 的價值，在於它把一個原本很散的工作變成可操作流程。這對有 production agents 的團隊有吸引力，尤其是已經在用 traces 和 evaluations，卻還靠人力把失敗案例翻成 prompt 修正的團隊。

但它也讓一件事變得更明顯：agent 的品質管理不會停在觀測。你看見一個錯誤之後，要能證明修正沒有引入另一個錯誤；你把新版本切到真實流量之前，要能說清楚用什麼 evaluator、什麼資料集、什麼信心水準，以及失敗時怎麼回復。

這次 preview 留給企業和開發者的實際判斷很清楚：代理人不只需要 prompt owner，也需要 release owner。當 prompt 變成 production artifact，它就不該再以「我覺得這樣比較好」進版控，而要以「這樣測過、這樣切流量、這樣退回」進 production。

林子睿（編輯：廖玄同），《AWS 把 Prompt 優化做成 A/B 測試：AI 代理人上線後怎麼改才不翻車？》，矽基前沿 [Si]gnals，2026-05-10。https://signals.tw/articles/aws-agentcore-quality-optimization/