YayJun
LOADING
YayJun
LOADING
各部門自行開發AI應用、本地LLM無有效利用 → 統一應用入口，AI工具重複利用。
我的角色｜協作開發：多租戶權限模型、per-service JWT 金鑰對簽發、本地 LLM 與雲端 API 的統一代理、金鑰與流量管控後台。
01 ／ 問題與情境
THE PROBLEM ／ 問題與情境
各自接
同一個文件檢索、同一個摘要功能，在不同部門的專案裡各被寫過一次。
無人管
金鑰直接寫在各專案設定檔：誰在用、用了多少、何時該換，都查不出來。
閒置
公司自購高階機器自架本地 LLM，各單位卻仍付費打雲端 API，費用散在各專案。
進不去
非技術同事想用 AI 工具，只能請工程師開發，需求全部進開發排程。
02 ／ 解決方案
THE SOLUTION ／ 解決方案
01 上架
上架單位自助上架
填模型與提示詞、從共用工具庫勾選，不必排進工程佇列。
02 授權
上架設定三層權限並送審
租戶 → Agent → 角色逐層收斂，通過後簽發 per-service 金鑰對。
03 關鍵
呼叫每次呼叫逐層驗證
任一層不通就擋下，三層皆通過才解密取金鑰。
04 執行
呼叫統一模型入口
本地與雲端收成同一組介面，不用煩惱LLM API怎麼接。
03 ／ 系統架構
ARCHITECTURE ／ 系統架構
1／7 上架・管理端
2／7 上架・註冊與送審
3／7 呼叫・呼叫端
4／7 呼叫・閘道層
5／7 平台共用資產
6／7 權限與配額
逐層收斂後放行
Redis原子預扣
三層皆通過才取金鑰
7／7 執行與外部服務
※Desktop 版可展示 Data Flow 🖥️
管理端
註冊與送審
呼叫端
閘道層
平台共用資產
權限與配額
逐層收斂後放行
Redis原子預扣
三層皆通過才取金鑰
執行與外部服務
04 ／ 互動演示
INTERACTIVE DEMO ／ 互動演示
動手桌機可操作可互動填寫 Agent 設定
名稱、用途、模型與提示詞範本
綁定共用工具
從工具庫勾選，不必重寫實作
設定三層權限
租戶 → Agent → 使用者角色
送審並發布
平台逐項驗證，通過才簽發金鑰對
欄位已預先帶好一份範例，改幾個字、換幾個選項就能送審，跑完就長出一個可呼叫的 Agent。整段流程沒有工程師參與，正是這個平台要證明的事。
※Desktop 版可操作這段演示 🖥️
本頁為去識別化模擬，不含專案原始碼或資料；上架與審核皆在瀏覽器端模擬，資料為合成，發布的 Agent 不可實際呼叫。
填寫 Agent 設定
名稱、用途、模型與提示詞範本
綁定共用工具
從工具庫勾選，不必重寫實作
設定三層權限
租戶 → Agent → 使用者角色
送審並發布
平台逐項驗證，通過才簽發金鑰對
上架申請表／合成資料
Agent預覽
草稿 ・ 未送審合約條款問答
讓同事直接問內部合約範本與條款差異，不必再找法務逐條確認。
綁定工具
欄位已預先帶好一份範例，改幾個字、換幾個選項就能送審，跑完就長出一個可呼叫的 Agent。整段流程沒有工程師參與，正是這個平台要證明的事。
本頁為去識別化模擬，不含專案原始碼或資料；上架與審核皆在瀏覽器端模擬，資料為合成，發布的 Agent 不可實際呼叫。
05 ／ 技術選型與設計決策
TECHNOLOGY & DESIGN DECISIONS ／ 技術選型與設計決策
ALTERNATIVE CONSIDERED
為何不直接用外部現成平台，而自建內部 Agent 平台？
現成平台讓「做出一個 Agent」很快，但我們要解的是治理：權限得對齊公司實際的部門與角色、流量要預設導到公司自架的本地 LLM、金鑰必須留在自家資料庫、用量要能按單位檢核。自建平台把工具與模型呼叫抽成可重用元件，各部門新增 Agent 能有效互相利用工具。
06 ／ 挑戰與成果
CHALLENGES & RESULTS ／ 挑戰與成果
挑戰 01 ・ 專案方向轉向
平台不該是 AI 工具的主開發者
最初我們把開發與上架權限收在技術部門，需求還是全部排隊。後來把定位改成「提供安全的上架環境」：權限與治理由平台負責，Agent 由懂業務的部門自己做。
挑戰 02 ・ 開放之後的邊界
開放上架，但不能開放越權
改成各部門自助後，租戶隔離與金鑰邊界成為前提：JWT 只帶單一服務，資料存取層統一注入租戶條件，避免查到別部門的資料。
模型
各自付雲端 API
→ 預設走自架本地 LLM
金鑰
散在各專案設定檔
→ 保管庫加密可輪替
上架
請工程師代跑
→ 各部門自助送審
工具
每部門各寫一份
→ 寫一次同仁即可重複使用