謝謝AI,真的很謝謝他才能讓我在短時間內學到很多預料之外的內容。
這是一個「完全」由ai開發的portal,甚至連接下來30天的內容也是ai產的。
主要業務是一個ai客服平台。從前端經由portal(大平台)再到後方的engine檢索km,來得到最精確回答的一系列過程。
雖然我覺得RAG檢索KM,很有趣,但portal更有趣!!
接下來的30天就讓我們從頭開始認識這個portal(我真的很想把頭貼換成王大陸)需要知道哪些技術細節吧。
Day 1|系列總導覽 接下來 30 天,我想帶你把一個東西從頭拆到尾:Agent Portal,一套銀行的企業 AI 助理平台的對外入口。不是貼程式碼那種拆法...
昨天 Day 1 給了地圖,也給了一個定位:Portal 是對外入口,自己不產生答案,只做身分、安全、路由、整合這四件橫切的事。今天把鏡頭拉遠一格,看它站在整個...
昨天 Day 2 我們把 Portal、Engine、KM 三者的分工攤開來看,結論是 Portal 在最外層當了一層 BFF/Gateway——身分、安全、路...
昨天我們把 Portal 跟 LiteLLM 那類純 AI Gateway 擺在一起比,結論是:Portal 不只是轉發流量的閘道,它是一個內建身分、守門、路由...
昨天把三大技術選型攤在桌上時,我留了一個沒拆開的選擇:Portal 的 web 層走的是 reactive,不是大家最熟悉的那套「一個請求配一條執行緒」。當時只...
昨天結尾我說了這麼一段話:reactive 用少數幾條執行緒撐起高並行,本錢是「事件迴圈絕不空等」這個能力,但同一個本錢也是弱點——只要有一段程式在事件迴圈上一...
昨天 Day 6 結尾埋了一個問題:既然 reactive 下一個請求會在不同執行緒間流轉,那「這位使用者是誰」「這次請求的追蹤碼是什麼」這些隨身資訊,要怎麼跟...
Day 7 我們把身分和追蹤碼這兩件「隨身行李」從執行緒身上挪下來,改掛在請求本身(request context)上,讓它們跟著資料流走、跨幾條執行緒都不掉。...
昨天 Day 8 把身分的源頭講清楚了:使用者是誰,在他登入 SSO(單一登入)那一刻就由帶 HMAC 簽章的 cookie 確立,往後每個請求靠驗章重新確認,...
昨天我們看著一個請求進門:先貼上 correlation id a1b2c3d4,再驗 cookie、還原出「他是誰」,把身分放進請求上下文一路帶下去。今天要追...