Bedrock Chat：把 Amazon Bedrock 包成一套可部署的內部 AI 平台

它解決的不是「接上模型」，而是「誰能用哪個 bot」

多數人第一次看到這個專案會以為它是 Bedrock 的聊天前端。README 的定位更接近平台：支援 chat、帶知識的 custom bot、透過 bot store 分享 bot，以及用 agent 做任務自動化。真正花心思的地方在治理。README 寫明，基於治理理由，只有被允許的使用者能建立自訂 bot，條件是該使用者必須是名為 CreatingBotAllowed 這個 group 的成員，而這個 group 要透過管理主控台的 Amazon Cognito user pools 或 aws cli 設定。

這代表預設狀態下，一般使用者只能聊天與取用別人分享的 bot，不能自己造一個。對企業內部部署來說這是合理預設，因為自訂 bot 會消耗 Bedrock 呼叫、可能掛上知識庫、甚至被發佈成獨立 API。反過來說，如果你的情境是讓每位同仁自由實驗 prompt，這道權限閘門會是第一個要拆的東西。

目標讀者因此相當明確：已經在用 AWS、想把 Bedrock 包成一層內部服務、而且需要區分「bot 建立者」與「bot 使用者」兩種角色的團隊。

Multi-tenant 知識庫：繞過 100 個 Knowledge Base 的配額

這是整份材料裡最具體的設計取捨。README 指出，Amazon Bedrock Knowledge Bases 在單一 AWS 帳號內預設最多只能建立 100 個。當每個 bot 都要有自己的知識庫時，這個上限很快就會被撞到。

專案的做法是 multi-tenant 模式：多個 bot 共用一個設定相同的 Knowledge Base，各 bot 上傳的檔案則以 Bot ID 作為 metadata 附加，查詢時再用這個 metadata 過濾。新建立的 bot 預設就啟用 multi-tenant 模式。

把隔離層從「一個 bot 一個知識庫」下移到「同一知識庫內的 metadata 過濾」，代價是隔離強度取決於過濾邏輯是否正確，而不是取決於資源邊界。README 沒有說明過濾在檢索管線的哪一層執行，也沒有說明失敗時的行為，這是要自己進程式碼確認的部分。

既有 bot 的遷移路徑有兩條。單一 bot 是在 bot 的知識設定裡改成 Create a tenant in a shared Knowledge Base。批次處理則給了實際指令：先用 aws dynamodb execute-statement 把 BedrockKnowledgeBase.type 設為 shared、SyncStatus 設為 QUEUED，再用 aws stepfunctions start-execution 觸發 embedding 的 state machine。指令裡的 $BotTableNameV3、$UserID、$BotID、$EmbeddingStateMachineArn 都要自行代入。批次改完資料列並不會自動重新同步，必須另外觸發 state machine，這一步漏掉的話 bot 的知識會停在舊狀態。

部署：bin.sh 一條路，但區域先決

README 的部署流程刻意做得很短。在目標區域開 CloudShell，然後：

git clone https://github.com/aws-samples/bedrock-chat.git cd bedrock-chat chmod +x bin.sh ./bin.sh

執行過程會詢問是新使用者還是既有 v3 使用者。文件另外提到 Bedrock Model access 必須先在主控台開通想用的模型，這步在 us-east-1 的 Bedrock 主控台完成。

真正會卡住人的是區域。若要用 bot 與建立知識庫，部署區域必須同時提供 OpenSearch Serverless 與 Ingestion API，因為 OpenSearch Serverless 是預設選項。README 列出截至 2025 年 8 月支援的區域：us-east-1、us-east-2、us-west-1、us-west-2、ap-south-1、ap-northeast-1、ap-northeast-2、ap-southeast-1、ap-southeast-2、ca-central-1、eu-central-1、eu-west-1、eu-west-2、eu-south-2、eu-north-1、sa-east-1。另外 bedrock-region 參數要選 Bedrock 本身可用的區域，這兩個清單不必然重疊。

對資料落地有要求的人要注意：這份清單裡沒有 af-south-1、ap-southeast-3、me-south-1 之類的區域。若合規要求資料必須留在某些地區，這個專案可能一開始就不成立。

v2 到 v3：README 用全大寫警告的那件事

README 的警告寫得很直白：V3 released，升級前請仔細閱讀 migration guide，否則 BOTS FROM V2 WILL BECOME UNUSABLE。文件路徑是 docs/migration/V2_TO_V3.md。

這種措辭在範例專案裡不常見，通常意味著資料模型有結構性變動。材料裡看得到的線索是資料表名稱帶了 V3 後綴，例如批次指令中的 $BotTableNameV3，而 v3 的預設分支也是 v3。這與 bot 資料從舊結構搬到新結構的推論一致，但 README 沒有說明具體欄位差異，所以實際影響範圍必須看 migration guide。

對評估者來說，這是一項維護成本，不是一次性事件。專案從 v3.15.6 到 v3.16.0 再到 v3.17.0，發佈節奏大約每兩個月一個 minor，2026 年 4 月甚至出現 v3.15.6 與 v3.16.0 相隔一天的情況。這種節奏下，把 bot 設定當成不可隨意重建的資產來管理是合理的。

授權是 MIT-0。它比 MIT 更寬鬆，主要差別在不需要保留姓名標示。這對內部部署幾乎沒有實務影響，但若你要把改過的版本對外散布，條款細節仍應由法務確認，本文不提供法律意見。

Agent 與 Bot Store：能力邊界與它的代價

Agent 功能讓 chatbot 處理更複雜的任務。README 的描述是：為了回答使用者問題，Agent 可以從外部工具取回必要資訊，或把任務拆成多個步驟處理。文件在 docs/AGENT.md。

拆解步驟與呼叫外部工具會讓延遲與失敗模式變複雜。單輪對話失敗就是失敗，多步 agent 失敗可能是中間某一步的結果不如預期，而使用者看到的只是一個不完整的答案。README 沒有交代步驟上限、逾時設定或中途失敗的回退行為，這些在導入前應該從程式碼與 CDK 參數確認。

Bot store 解決的是另一個問題：讓已建好的 bot 在應用使用者之間流通，避免每個人各自重建一份。搭配管理功能（API Management、把 bot 標記為 essential、bot 使用分析，見 docs/ADMINISTRATOR.md），這套組合的定位是內部市集，而不是給外部客戶的產品。

自訂 bot 還能發佈成獨立 API，文件在 docs/PUBLISH_API.md。這條路徑值得注意，因為它把 bot 從「介面裡的功能」變成「可被其他系統呼叫的端點」，隨之而來的認證與配額問題就不在聊天介面的範圍內了。

什麼時候該選別的方案

如果你的需求只是把單一模型接進既有應用，直接呼叫 Bedrock API 會比部署這整套簡單得多。Bedrock Chat 的價值來自它附帶的 Cognito 使用者池、DynamoDB 資料表、Step Functions 同步流程與 OpenSearch Serverless 知識庫，而這些只有在你要服務多個使用者、多個 bot 時才划算。

另一個對照是 Amazon Bedrock 自家的 Knowledge Bases 與 Agents 主控台。兩者的差別在控制權：用主控台設定，你拿到的是託管功能；用 Bedrock Chat，你拿到的是部署在自己帳號裡的 CDK 堆疊，可以改 React 前端、改 FastAPI 後端、改 bot 的權限邏輯。代價是這些元件從此由你維運，包括 OpenSearch Serverless 這類按容量計價的資源。

還有一種情況應該直接排除這個專案：部署區域不在前述清單內。README 把區域限制放在部署章節，而不是藏在附錄，這通常表示它不是可以繞過的設定問題。若你的資料必須留在未列出的區域，這個專案在架構層面就不適用。

導入前該確認的四個具體項目

第一，確認部署區域同時出現在 OpenSearch Serverless 與 Ingestion API 的支援清單，以及 Bedrock 可用區域清單。這兩份清單在 README 裡是分開講的。

第二，確認帳號內既有 Bedrock Knowledge Base 的數量。若接近 100 的上限，新 bot 應該走 multi-tenant 模式，而這也是新 bot 的預設值。

第三，若你是 v2 使用者，先讀 docs/migration/V2_TO_V3.md 再執行任何升級動作。README 的警告語氣意味著跳過這步會導致 bot 不可用。

第四，確認 CreatingBotAllowed 這個 Cognito group 的成員名單。README 說明可透過管理主控台的 Cognito user pools 或 aws cli 設定，而 user pool id 可以從 CloudFormation 的 BedrockChatStack 輸出中找到，鍵名格式為 AuthUserPoolIdxxxx。這個名單決定了誰能建立自訂 bot，也就是誰能消耗 Bedrock 額度並掛上知識庫。

把這四項當成部署前的檢查清單，其餘的設定可以在 bin.sh 的互動流程與 Optional Parameters 裡逐步補齊。

編輯結論

如果你需要一個部署在自己 AWS 帳號內、能讓非工程師透過 bot store 取用既有知識庫的對話入口，而且部署區域落在 OpenSearch Serverless 與 Ingestion API 支援的清單內，Bedrock Chat 值得進到試用階段。若你只想接一顆模型做單一問答服務，這套 Cognito、DynamoDB、Step Functions 加 OpenSearch Serverless 的組合會遠超需求。動手前先確認三件事：部署區域是否同時支援 Bedrock 與 OpenSearch Serverless、你的帳號內既有 Knowledge Base 數量是否逼近 100 的上限、以及你是否已經有 v2 的 bot 資料需要走 migration guide。最後一項不是提醒而是硬條件，README 明講未依文件處理的話 v2 的 bot 會變成不可用。

官方來源

1. aws-samples/bedrock-chat on GitHub
2. Issues
3. License: MIT-0
4. README
5. Releases