AWS AgentCore Web Search API 上線：不用 Gateway，AI 代理如何取得搜尋來源？
AgentCore Web Search API 可透過 SDK 直接取得搜尋結果。解析與 Gateway、Web Answer 的差別，包含 IAM、UTC 日期、區域與每千次7美元。
AgentCore Web Search API 面向需要近期網路資料的程式，想查今天的公告時，應用需要的可能是搜尋結果與原文連結，額外建立工具閘道，反而增加了整合步驟。
AWS 在 2026 年 11 月 10 日宣布，Amazon Bedrock AgentCore 新增 Web Search API，可透過 SDK 或 CLI 直接呼叫 InvokeWebSearch。
這是新的整合入口：既有程式自己接結果，不必先建立 AgentCore Gateway，也不必把整個應用改成 MCP 用戶端。
API 回傳排序後的文字節錄，標題、網址與發布時間則在資料可取得時提供。它不是保證正確的完整答案，引用與查核仍由應用負責。
直接呼叫與 Gateway 工具在授權和時間參數上有差異，尤其只給日期的截止時間，可能讓同一天後續發布的內容不在結果裡。
對已有程式工作流的團隊，我會先比較自己的授權與查核方式，再決定直接 API 是否比工具閘道更合適。
AgentCore Web Search API 這次新增了什麼？
11 月 10 日新增的是直接呼叫 InvokeWebSearch 的入口，既有 MCP 工具和 Web Answer 各有不同用途，因此先分清整合方式，才不會把舊功能當成新發布。
AgentCore 是 AWS 提供的代理執行與工具服務，先前 Web Search 以 Gateway 裡的工具形式提供，代理可透過 MCP 這種工具溝通方式發現並呼叫它。
對已經有自己的程式迴圈或資料管線的人，這條路徑未必必要，因為他們只是想在程式中送出查詢、取得結果，再依原本規則處理。
新的直接 API 就回應這個需求，使用 AWS SDK 或命令列工具呼叫資料介面，不需要先建立與維護 Gateway 資源。
這裡減少的是整合步驟，搜尋本身仍是外部資料來源，不會因為程式碼比較短，就自動替應用判斷一篇公告是否可信或仍然適用。
如果現有代理本來就透過 MCP 管理工具，Gateway 仍有自己的用途，因此這次更新不是宣布所有人都應該移除原本的閘道。
先前 Web Answer 著重整理帶來源的答案，新 API 則把搜尋結果交回應用，兩者應按需要的輸出比較，而不是只看名稱都有 Web。
延伸閱讀：AWS Web Answer 正式開放，AgentCore 如何一次回傳有來源的網路答案？
直接 API 會回傳答案，還是搜尋資料？
API 回傳排序後的文字節錄，並在可取得時附上標題、網址與發布時間，因此接收結果的程式仍要決定如何閱讀、引用與產生回答。
AWS 說搜尋依據來自其運作的索引，應用可以用它查新公告、收集研究來源，或從信任的網域找資料，但索引結果並不等於內容已逐條驗證。
例如新聞研究可能需要確認原始公告日期、功能適用地區與方案，節錄剛好只包含新功能時，就仍應打開原文找限制，而不是直接產生確定結論。
回傳發布時間也有條件，某些網頁沒有可辨識的日期，不能把欄位缺少理解成今天發表，更不能由查詢當天自行補上日期。
標題與網址同樣依可取得資料提供，應用需要處理缺少欄位或資訊不足的情況，避免空白來源被後續模型補成看似完整的引用。
因此，一個較穩定的流程會保存原始查詢、回傳結果與後續採用的頁面，再把摘要中的主張連回實際來源，讓錯誤可以被追查。
如果工作最後交給人員審稿，最好連同未能確認的地方一起回報，而不是因為搜尋已有結果，就把研究狀態自動標成完成。
直接 API 與 Gateway 工具，授權有什麼差別？
直接 API 只使用 IAM 授權，每次請求帶入網域條件，Gateway 則另外支援 JWT 與目標層級規則，因此選擇入口也會改變規則放置的位置。
IAM 是 AWS 用來管理誰能執行哪些服務操作的權限機制，適合既有 AWS 程式以自己的角色呼叫，JWT 則常用來攜帶應用端身分資訊。
若既有工具架構已經依使用者身分經過 Gateway，改用直接 API 前就需要重新確認角色與限制，不能只刪掉中間一層，卻遺漏原本在那裡執行的規則。
網域過濾也有差別，API 每次查詢帶自己的條件，Gateway 工具還能在目標層設定每次都適用的網域清單，代理本身不必看到這些設定。
這會影響企業希望把政策放在哪裡，例如固定只能查核准來源的研究工作，應用需要確保每次請求都有遵守，而不是依賴模型記得補上篩選。
預設結果數也不同，直接 API 若不設定上限，最多回傳 25 筆，MCP 工具則最多 10 筆，因此搬移時應重新檢查後續閱讀與成本預期。
AWS 同時提供透過 PrivateLink 呼叫與 CloudTrail 紀錄操作的方式，團隊可接進既有網路與稽核安排，但這些機制記錄的是操作，不能替內容真偽背書。
日期篩選為何可能漏掉同一天的新聞？
API 的發布時間上下界都包含邊界，但 SDK 與 CLI 只給結束日期時，會送出該日 UTC 零時，因此日期看似正確，仍可能排除當天稍後的內容。
這和 Gateway 工具把結束日期視為包含整天不同，所以將舊查詢參數直接搬過去，可能讓結果範圍變小，卻沒有明顯錯誤訊息。
例如想查到某天結束的所有公告，若結束值實際是那天剛開始的時間，當天上午或晚上發布的頁面就不在條件裡，這是時間界線的問題。
台灣工作流還要把本地日期和 UTC 區分，早上整理最近一天消息時，應先定義實際起訖時間，再轉成 API 所需要的值。
採用完整時間與時區，並保存轉換後參數，會比只在紀錄裡寫昨天更容易回查，也比較能處理跨日或重新執行的情況。
不過，時間過濾仍依賴來源可用的發布資訊，不能只因設定了最近一天，就認定所有結果一定都是新消息，仍需逐篇看公告日期與事件內容。
每千次 7 美元，還有哪些區域與用量限制？
直接 API 每千次搜尋 7 美元，不收 Gateway 費，開放六個商業區域且預設每區每帳號每秒十次，因此上線前需要把費用與請求安排一起估算。
這裡的搜尋費和模型推論是不同項目，若後續用模型閱讀結果、產生摘要或反覆改查詢，仍會有各自的使用量與費率。
不用 Gateway 的優勢，是省下沒有使用的那一層費用，而不是整個代理研究工作都只剩搜尋費，預算仍要看從查詢到答案的完整流程。
目前六個區域包括美國維吉尼亞、俄亥俄、奧勒岡，以及雪梨、東京與愛爾蘭，沒有台灣區域，部署時需依既有系統與資料要求選擇。
直接 API 不支援美國西部 GovCloud，而原本 Web Search 工具可在該處使用，因此不能把舊工具的區域清單直接套到新入口。
預設請求配額可向 AWS 申請提高，但在確認前，程式就需要安排佇列與重試，避免多個代理同時查詢時，反覆碰到限制又立刻重送。
同一項研究也可能產生多次查詢，成本應按實際請求計算，不能把一次使用者提問當成必定只收一次搜尋費。
搜尋結果接回代理，怎麼驗收比較有意義？
搜尋結果需要保留來源引用與連結，應用也要處理沒有日期、資料過期及相互矛盾的頁面，因此驗收應看後續判讀，而不只看 API 回應成功。
第一輪可準備已知公告與固定來源網域，確認查詢能找到正確頁面，並把節錄、原文與發布日期對照，避免模型引用同公司的另一篇舊公告。
第二輪加入邊界情況，例如沒有結果、網頁缺日期與結束時間跨日，觀察程式是否回報不足，而不是為了給出完整答案自行補資訊。
第三輪再檢查來源保留，確保原始網址能從最後輸出回查，並依服務使用條件顯示引用與連結，不能在彙整後把來源全部丟掉。
網域白名單有助控制範圍，卻不能直接等同正確，因為官方網站也可能有舊文件、預覽公告或尚未普遍開放的功能，需要把版本與適用條件讀進去。
對多代理工作，還要避免每名工作者重複查同一條問題，可以保存已取得的來源與查詢時間，再由負責查核的人判斷何時需要重查。
如果研究結果會送到正式文件或公開內容，應保留人員採用與修訂的紀錄，讓搜尋工具、模型分析與最後決策各自有清楚責任。
延伸閱讀：Cloudflare Web Search API 開放測試：讓 AI 代理用即時網路資料回答
什麼工作值得改用直接搜尋 API？
如果團隊已經有排程程式、研究管線或自己的代理迴圈，直接 API 比較容易接進現有步驟，因為結果可以由程式按既有規則整理。
例如每天查產品公告，程式可以先限定來源網域與時間，再把結果交給負責讀原文的步驟，最後由人員採用，而不是讓搜尋服務一次承擔全部判斷。
如果來源規則原本集中在 Gateway，則要先找出這些設定放在哪裡，遷移時安排同等檢查，不能只比較少建立幾個資源的方便。
需要讓多種代理自行發現工具的環境，也可能繼續適合 MCP 入口，因為工具清單、身分與政策都已經沿同一路徑管理。
因此比較的單位應是完整工作，而不只是一次 API 呼叫，少一層整合若增加了各應用重複管理規則的負擔，未必真正節省維護。
搜尋沒有結果，應該讓代理一直重試嗎？
沒有結果可能是網域或日期太窄，也可能是頁面尚未進入索引，程式應先保留條件與回應，再決定是否調整查詢，而不是沒有上限地重試。
若第一次搜尋已碰到請求配額，立刻以相同速度重送只會延長問題，應把等待與有限次重試放進程式，並讓最後失敗能被看見。
多名工作者可以共用已取得的來源紀錄，但需要帶上查詢時間，避免舊結果被當成剛剛取得的資料，尤其是價格、資格或功能開放狀態。
如果新聞題材不足，搜尋介面不會改變事實數量，研究流程應如實回報缺額，不能為了產出固定篇數把同一公告換標題重寫。
把這些規則接在搜尋之後，能讓直接 API 成為有界線的資料入口，而不是一個只要回應成功，就自動把內容判定完成的按鈕。
AgentCore Web Search API 常見問題
已有自己的代理迴圈，一定要建立 Gateway 嗎？
不需要，新入口就是讓程式直接以 SDK 或 CLI 取得搜尋結果，但若既有架構依賴 MCP、JWT 或目標層規則，仍應比較 Gateway 的作用。
API 回傳的來源能直接當成已確認事實嗎？
不能，結果是搜尋資料與節錄，應用仍要閱讀原文、確認日期與限制，再決定哪些主張可以採用。
只設定查最近一天，就能保證全部是新消息嗎？
不能，除了正確設定 UTC 起訖時間，也需要檢查頁面日期與事件是否真的更新，搜尋條件本身不會替研究完成去重與時效查核。
結語：少一層整合，保留完整來源責任
這次更新讓已有程式工作流的人更容易取得網路搜尋資料，適合不需要 MCP 工具發現的應用，但是否更好仍取決於原本授權與政策放在哪裡。
我會先用同一組可核對的公告比較查詢、日期與引用結果，再決定改接直接 API，讓整合變簡單的同時，仍能知道每一項答案從哪裡來。
原始資料來源
資料核對於 2026 年 11 月 11 日，依官方公告與文件整理，未自行部署或獨立驗證產品效能。
