https://yennj12.js.org/yennj12_blog_V4/tags/llm-gateway/Recent content in LLM Gateway on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 27 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part10-enterprise-ai-platform-engineering-zh/Mon, 27 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part10-enterprise-ai-platform-engineering-zh/一個團隊接 Bedrock,叫專案。五十個團隊各自接 Bedrock,叫混亂:每個團隊重新踩一次合規的坑、各自把 API key 寫死在 Lambda、成本一整包分不清誰花的、某個團隊的失控迴圈把整個帳號的 Bedrock 配額吃光、資安團隊要追五十套不同的架構。 企業 AI 的最終形態,不是「更強的模型」,而是「平台」:把前九篇的能力——多租戶、模型治理、合規、可觀測——打包成內部團隊可以「自助點用」的產品。讓應用團隊專注寫業務邏輯,把落地區、閘道、護欄、分帳這些重複的重活,一次做對、所有人共享。 這是平台工程(Platform Engineering)套在 AI 上:黃金路徑(golden path)讓做對的事變得最容易,集中閘道讓治理有單一施力點,自助讓平台團隊不變成瓶頸。 這是 Part 10,整個系列的終章:把十篇累積的一切,收束成一個企業能長期運營的 AI 平台。 一、情境與痛點:從「幾個專案」到「幾十個團隊」 前九篇每一篇都在教「怎麼蓋一個好的 AI 系統」。但當你的公司從「一個 AI 專案」長成「五十個團隊都想用 AI」時,一個新的、組織層級的問題浮現: 沒有平台時,每個團隊各自為政的後果 ────────────────────────────────────────────────────────────── 合規 每個團隊重踩 Part 9 的坑,資安追五十套架構追到死 成本 Bedrock 帳單一整包,不知道哪個團隊、哪個專案花的 配額 一個團隊的失控 agent 迴圈吃光全帳號 Bedrock TPM,全公司癱瘓 一致性 A 團隊用 Claude、B 團隊 hardcode 舊模型、C 團隊沒接 Guardrails 重複造輪 每個團隊重寫一次向量庫、重寫一次授權、重寫一次可觀測性 安全 API key 散落各處,某個 repo 一外洩全公司曝險 平台工程的答案:把重複的、需要做對的重活,抽成一個中央平台;讓應用團隊透過「自助」與「黃金路徑」消費它。平台團隊的產品不是某個 AI 應用,而是「讓別人安全、快速、可控地蓋 AI 應用的能力」。 核心心法三條: 黃金路徑(Golden Path):讓「做對的事」成為阻力最小的路。團隊照著鋪好的路走,合規、可觀測、成本標籤自動就位。 集中施力點(Single Point of Control):所有 LLM 呼叫走同一個閘道,治理(限流、日誌、快取、分帳)只需在一處施行。 自助不設限(Self-service):平台團隊提供能力,不當審批瓶頸——否則平台自己變成塞車點。 二、系統目的:平台的產品需求 平台的「使用者」是內部的應用團隊。它的需求以「開發者體驗 + 治理」雙軸衡量: