YayJun
LOADING
YayJun
LOADING
各部門自行開發AI應用、本地LLM無有效利用 → 統一應用入口，AI工具重複利用。
我的角色｜協作開發：多租戶權限模型、per-service JWT 金鑰對簽發與輪替、自架本地 LLM 與雲端 API 的統一代理、金鑰與流量管控後台。
THE PROBLEM ／ 問題與情境
各自接
同一個文件檢索、同一個摘要功能，在不同部門的專案裡各被寫過一次。
無人管
金鑰直接寫在各專案設定檔：誰在用、用了多少、何時該換，都查不出來。
閒置
公司自購高階機器自架本地 LLM，各單位卻仍付費打雲端 API，費用散在各專案。
進不去
非技術同事想用 AI 工具，只能請工程師開發，需求全部排進開發佇列。
THE SOLUTION ／ 解決方案
01 上架
上架部門自助註冊
填模型與提示詞、從共用工具庫勾選，不必排進工程佇列。
02 授權
上架設定三層權限並送審
租戶 → Agent → 角色逐層收斂，通過後簽發 per-service 金鑰對。
03 關鍵
呼叫每次呼叫逐層驗證
任一層不通就擋下，三層皆通過才解密取金鑰並預扣配額。
04 執行
呼叫統一模型入口
本地與雲端收成同一組介面，預設走自架 GPU 機，用量回沖稽核。
ARCHITECTURE ／ 系統架構
管理端
註冊與送審
呼叫端
閘道層
平台共用資產
權限與配額
逐層收斂後放行
Redis原子預扣
三層皆通過才取金鑰
執行與外部服務
INTERACTIVE DEMO ／ 互動演示
可互動填寫 Agent 設定
名稱、用途、模型與提示詞範本
綁定共用工具
從工具庫勾選，不必重寫實作
設定三層權限
租戶 → Agent → 使用者角色
送審並發布
簽發 per-service 金鑰對與配額
待上架申請 ／ 合成資料
上架結果
待機中從左邊選一筆申請，四個步驟會依序點亮，最後產出可呼叫的 Agent 端點。
綁定共用工具
三層權限
POST /agents/legal-contract-qa/invoke
簽發金鑰 kid：svc_legal_2f9c ・ 有效期 15 分鐘
申請由部門管理者自行送出，平台只驗證權限與配額設定是否合規。
綁定共用工具
三層權限
POST /agents/mkt-copywriter/invoke
簽發金鑰 kid：svc_mkt_7b41 ・ 有效期 15 分鐘
申請由部門管理者自行送出，平台只驗證權限與配額設定是否合規。
綁定共用工具
三層權限
POST /agents/cs-ticket-classifier/invoke
簽發金鑰 kid：svc_cs_9d20 ・ 有效期 15 分鐘
申請由部門管理者自行送出，平台只驗證權限與配額設定是否合規。
本頁為去識別化整理，不含前雇主原始碼或資料；互動演示皆為前端合成資料。
TECHNOLOGY & DESIGN DECISIONS ／ 技術選型與設計決策
ALTERNATIVE CONSIDERED
為何不直接用 Dify／LangChain 等現成平台，而自建 Agent 註冊？
現成平台讓「做出一個 Agent」很快，但我們要解的是治理：三層權限得對齊公司實際的部門與角色、流量要預設導到公司自架的本地 LLM、供應商金鑰必須留在自家資料庫、用量要能按單位檢核。自建註冊中心把工具與模型呼叫抽成可重用元件，各部門新增 Agent 能有效互相利用工具。
CHALLENGES & RESULTS ／ 挑戰與成果
挑戰 01 ・ 專案方向轉向
平台不該是 AI 工具的主開發者
最初把開發與上架權限收在技術部門，需求還是全部排隊。後來把定位改成「提供安全的上架環境」：權限與治理由平台負責，Agent 由懂業務的部門自己做。
挑戰 02 ・ 開放之後的邊界
開放上架，但不能開放越權
改成各部門自助後，租戶隔離與金鑰邊界成為前提：JWT 只帶單一服務，資料存取層統一注入租戶條件，避免查到別部門的資料。
模型
各自付雲端 API
→ 預設走自架本地 LLM
金鑰
散在各專案設定檔
→ 保管庫加密可輪替
上架
請工程師代跑
→ 各部門自助送審
工具
每部門各寫一份
→ 寫一次全公司重用