AWS Web Answer 正式開放，AgentCore 如何一次回傳有來源的網路答案？

代理要回答最新資料時，通常得先搜尋網頁，再逐頁閱讀、整理答案與來源。這些步驟都要接成程式，搜尋結果一變，團隊還要處理失敗與重試。

AWS Web Answer 在二○二六年十一月五日正式開放，讓代理以一次工具呼叫，取得整理過的答案和引用。它放在 Amazon Bedrock AgentCore Gateway 裡，由 AWS 代管搜尋與綜合流程。

這次功能改變的是應用與搜尋工具的分工。開發者提出問題後，工具會安排查詢、讀取頁面，再把結果交回主要代理，因此不用自行維護每一步搜尋邏輯。

工具接手的工作越多，團隊越需要事先決定資料範圍。來源是否合用、引用能否支持答案，以及整項任務花了多少錢，都會影響導入成果。

對已在 AWS 建置代理的團隊，我會先挑來源明確、答案可核對的即時問題試用。把錯誤與費用一起記錄，才有根據決定要不要擴大。

先從一次問題經過哪些環節看起，就能分清 AWS 接走的工作，以及應用仍須保留的判斷。

Web Answer 如何完成一次有來源的回答？

代理把自然語言問題交給 Gateway，Web Answer 才開始安排搜尋與閱讀。Gateway 是代理呼叫工具的統一入口，負責辨識誰在發出請求，以及可以使用哪些工具。

AWS 公告的流程會先驗證請求，再由設定好的服務角色呼叫 Web Answer。使用者對 Gateway 的存取權，與 Gateway 代表應用使用服務的權限，分別處理不同一段授權。

工具收到問題後會規劃查詢，平行搜尋相關網頁，並擷取內容。如果第一輪資料不足以回答，它可以繼續查找，再由模型綜合出最終回覆。

因此，一次外部工具呼叫可能包含多個內部研究步驟。主要代理看到的是整理後的結果，應用團隊省下的是搜尋、閱讀與彙整的串接工作。

回傳結果同時包含可讀文字與結構化欄位。content 裡是帶有引用標記的 Markdown，structuredContent 則將答案文字與引用清單放在可供程式處理的結構裡。

官方回傳範例也保留 isError 狀態與 latencyMs 延遲欄位。程式可以先判斷工具結果是否為錯誤，再決定怎麼呈現答案，而不是只要收到文字就視為完成。

structuredContent.answer 通常包含一個答案區塊，每筆引用保存網址，並在有資料時附上網域。應用可利用欄位建立來源介面，減少自行從一大段文字猜測連結用途。

整合時仍應確認畫面顯示的答案與結構化答案一致。如果介面只保留文字、丟掉引用，使用者就失去回看證據的入口，代管工具提供的結構也沒有真正用上。

AWS 使用自有搜尋索引與知識圖譜支援這套流程，並宣稱搜尋會針對當次問題取得新資料。索引更新速度仍會影響能找到哪些內容，答案附來源也需要檢查。

AWS 完整流程說明的範例出現約五點二秒的執行時間，這只反映該次示範。問題複雜度、需要讀取的頁面與再次搜尋的次數，都可能改變等待時間。

當搜尋與綜合都交給工具，開發者接著要決定自己還需要保留多少控制。

Web Answer 與 Web Search 差在誰負責綜合？

Web Search 把搜尋結果交回應用，Web Answer 直接交付整理後的答案。兩者面對相近的網路資料，卻在不同位置結束工作。

若使用 Web Search，代理會取得排序後的網址、標題與摘要，再自行決定要讀哪一頁。採用的模型、比較來源的方法，以及最後如何下結論，都留在應用端。

這適合已經有研究流程的團隊。例如既有代理需要分別保存公告、文件與舊版本，再逐項比較差異，直接拿到搜尋結果比較方便安排後續工作。

若使用 Web Answer，工具會連閱讀與綜合一起處理。應用可以用較少的串接步驟取得回答，但也把更多研究決策交由代管服務執行。

以查詢雲端產品的支援地區為例，Web Answer 能交回整理與引用。若任務還要求逐一保存不同語言文件、核對版本差異，應用仍可能需要自行擴充查核流程。

這裡的取捨會反映在產品設計。只想快速提供附來源答案的入口，可以先測代管綜合。需要自訂研究順序的工具，則應比較原始搜尋介面是否更符合流程。

兩種路線也能分工使用。主要代理可以根據任務類型選擇工具，但團隊仍要定義何時接受代管答案、何時需要回到原始頁面。

選定入口以後，工具能查哪些資料就成了下一個設定條件。

管理員與代理如何共同限制搜尋範圍？

管理員先設定來源邊界，代理在每次查詢時只能把範圍收得更小。這讓應用有機會先固定可接受的資料來源，再讓代理處理問題。

官方提供包含與排除網域的設定。團隊若只想引用特定官方網站，可以先把允許範圍寫進工具目標，減少搜尋到不適用資料的機會。

每次呼叫仍能加上較窄的篩選，但無法藉此擴大管理員允許的網域。這個層次讓管理政策與單次查詢需求可以同時存在。

例如管理員允許幾家產品官網，代理可以在特定問題中只查其中一家。它不能因為搜尋結果不足，就自行把範圍改成整個網路。

日期與國家條件則協助縮小查詢背景。產品價格、服務資格或政策經常隨地區改變，提出問題時交代時間和地區，能減少把不同版本混在一起的情況。

篩選條件仍只是搜尋邊界。官方網站可能同時保留舊公告與新文件，因此應用還要檢查頁面日期、方案名稱，以及來源是否明確適用於提問情境。

AWS 宣稱查詢與結果會留在 AWS 環境內，不把使用者問題送到第三方搜尋服務。這是供應商對服務資料流程的說明，團隊仍應依實際資料要求核對適用條款。

若使用 PrivateLink 連接代理與 Gateway，保護的是這段服務連線。工具本身仍會研究公開網頁，不能因此把整個流程視為離線資料查詢。

來源範圍確定後，執行地區與用量條件會決定第一次測試能怎麼安排。

地區、速率與費用如何影響導入？

上線初期的區域與速率限制，會直接影響測試規模。截至十一月六日台灣時間查閱公告，Web Answer 在美國東部維吉尼亞北部區域提供服務，區域代碼是 us-east-1。

公告列出的每帳戶請求上限為每秒十次。若多個代理共用帳戶，應用需要把尖峰流量一起估算，避免只按單一使用者的操作頻率安排容量。

工具定價為每一千次呼叫十美元。換算後每次呼叫一美分，但這個數字只涵蓋 Web Answer 這項工具的計價單位。

主要代理使用的模型、Gateway 與其他服務仍可能有額外費用。使用者問一次問題，代理也可能在過程中再次呼叫工具，因此總成本要依實際執行紀錄計算。

第一次測試可以固定一組問題，同時記錄工具呼叫次數、主要模型用量與完成時間。如此比較自建搜尋流程時，才會包含真正省下的開發與維護工作。

官方示範以 Python 三點十以上環境設定 Gateway，並使用服務角色授權。Gateway 的角色需要 InvokeWebAnswer 權限，呼叫者則需要 InvokeGateway，兩者對應不同一段服務連線。

服務角色的信任政策允許 AgentCore 代表指定帳戶執行工作。這個角色控制向外呼叫 Web Answer，不會同時替主要代理取得模型使用權，模型仍依代理自己的身分執行。

管理員加入 Web Answer 連接器目標後，應等狀態回報 READY 才開始呼叫。建立目標請求成功，和目標已經可供代理使用，是兩個不同階段。

連接器使用 Gateway 角色驗證，因此不用再為 Web Answer 建立與保存另一把工具金鑰。這減少一項機密維護工作，但入口的 IAM 或 JWT 驗證仍要先設定。

代理先透過 tools/list 取得工具清單，再以 tools/call 呼叫。這把工具探索與實際執行分開，測試時可先確認名稱和參數，較容易知道應用是否已連上正確目標。

MCP 是讓代理以共同格式連接工具的通訊方式。已經使用這種介面的 Strands、LangChain、LangGraph 或 CrewAI 應用，可以沿用熟悉的工具連接方式。

正式接上既有代理之前，開發者應先確認該代理能呼叫 Gateway，以及服務角色有權使用 Web Answer。分開檢查兩段權限，較容易定位請求在哪一層失敗。

測試完成後，官方也提供清除資源順序。若 Gateway 只為這次試用建立，先刪除工具目標，再處理 Gateway、服務角色與政策，避免留下不再使用的測試設定。

若使用原有 Gateway，則應只移除這次測試的目標，先確認其他代理是否仍依賴它。這讓試用有完整收尾，也保留既有應用的服務連線。

把區域、權限與資源生命週期列清楚後，團隊才能對照原本自行維護搜尋流程的成本。

答案附引用，團隊還要驗收什麼？

有來源的答案讓查核有了起點，團隊可以先檢查一組容易混淆的產品問題。保留地區、日期與方案作為標準答案，就能辨識工具是否把預覽功能擴大成全面開放。

每項結論應對上實際引用，再打開頁面確認適用條件。若來源沒有支持回答，後續修正方向就是資料選擇與綜合方式，不能只增加連結數量。

測試也應包含允許網域沒有答案的情況。這能觀察應用是否保留資料不足，或為完成問題而超出證據，並確認管理員的來源邊界有沒有保持。

正式流量則要核對同帳戶的合計用量。若多個代理同時接近每秒十次限制，應用端可以安排排隊與失敗呈現，避免使用者反覆送出造成更多呼叫。這是依容量限制提出的導入做法，並非公告提供的自動排隊保證。

第一次試用可固定同一組問題，保存答案、引用、完成時間與總費用。比較時同時看有效答案與失敗情況，才知道代管流程是否減少了原本的開發和人工工作。

常見問題

AWS Web Answer 可以接在既有代理上嗎？

可以透過 AgentCore Gateway 與 MCP 連接。應用仍須具備呼叫 Gateway 的授權，並讓 Gateway 使用適當的服務角色。完成連接後，再確認列出的工具與呼叫結果符合預期。

每次呼叫都會回傳同一組來源嗎？

服務會依問題安排搜尋，網頁與索引也可能更新。若任務需要重現結果，應保存當次答案與引用，並記下查詢時間，方便後續對照資料變動。

可以把所有搜尋工作都交給它嗎？

是否合適取決於控制需求。需要快速得到附來源答案的任務，可以測試 Web Answer。需要指定逐頁閱讀順序、保留完整研究證據的流程，仍要設計相應步驟。

從可核對的小問題開始導入

AWS Web Answer 把搜尋與綜合包進一次工具呼叫，對已採用 AWS 代理基礎設施的團隊有直接的整合價值。它能節省多少工作，要看原本維護的是哪一段流程。

先選一組有官方標準答案的問題，固定地區和日期，保存答案、引用、延遲與總費用。當資料不足時也能保留合理限制，再考慮擴大到更多使用者。

若要繼續規劃工具與驗收流程，可閱讀AWS Step Functions 接上 AI 代理：工作流程能照規則跑，為何固定工具還不等於完整授權？與AI 說完成之後，怎麼驗收？文件、網站與資料任務的檢查方法。

原始資料來源

• AWS Web Answer 正式開放與操作說明
• AWS 官方 X 公告