學者的計量程式能不能直接變成 API？博山科技用 AI Agent 上線 OptiVaR 的案例

一支計量程式在研究員的電腦上跑得很順：打開統計軟體、載入三年多的每日價格、按下執行，一分鐘左右吐出一份結果。麻煩在下一步。業務端希望串接方的系統每天自己來拿結果，而這支程式只認得研究員的桌面，電腦前面沒人，它就不會動。

博山科技找上我們時，卡的就是這一段。我們讓 AI Agent 負責「把研究程式變成系統」的整段工程：把統計引擎搬上伺服器、把研究程式改寫成固定樣板的分析模組、包成 API 交給串接方呼叫。至於每一次實際運算，交給固定的程式執行，不讓 AI 臨場發揮。這篇把過程、踩到的坑，以及這個取捨背後的理由攤開來講。

專案背景：一家靠計量模型吃飯的金融科技公司

博山科技做金融與不動產的量化分析服務，客戶涵蓋金融機構、企業與政府單位。公司的核心資產是研究團隊累積的計量模型；對外，則需要一個能讓其他系統直接呼叫的統計運算平台，也就是官網上的「博山分析模組」。

這次上線的主角是 OptiVaR。給它台股、那斯達克與原油三種資產的價格序列，它會算出波動最小的配置權重，並估計未來三個交易日報酬可能落在的風險值區間。模型是合作學者團隊的研究成果，我們的工作是讓它能被系統穩定、重複地呼叫。

研究程式為什麼不能直接丟上伺服器

把一支能跑的程式放上伺服器，聽起來只是複製檔案。真的動手才發現，研究環境和系統環境的假設差很多，這個案子至少撞到四面牆：

• 統計軟體是為桌面設計的。搬到沒有螢幕的 Linux 主機上，第一次執行就直接當掉。
• 授權只允許單一使用者。同一時間只能有一個運算在跑，兩個請求同時進來就會互相踩到。
• 一次運算要將近一分鐘。OptiVaR 每跑一次，要做 99 次滾動的多變量 GARCH 估計，再做一萬次拔靴模擬，網頁請求等不了這麼久。
• 研究程式預設輸入的人知道自己在做什麼。放上網路之後，進來的可能是空值、負數、非數字，甚至是想夾帶指令的字串。

這四件事，每一件都得在上線前解決。

AI Agent 在這個案子裡做了什麼

這個案子的 AI Agent 是我們平常開發就在用的 Claude Code。它住的位置很明確：系統的建造與擴充流程。我們在企業 AI Agent 導入指南裡談過，Agent 要先找到一個責任邊界清楚的位置，這個案子就是一個例子。

把統計引擎搬上伺服器

引擎在無畫面環境當掉的問題，是 AI Agent 一路追出來的。它讀錯誤紀錄、比對執行條件，找到兩個只有在沒有視窗時才會觸發的程式錯誤，補好之後，引擎終於能在背景穩定執行。我們另外讓引擎跑在一個常駐的虛擬螢幕裡，對它來說，就像一直有人開著電腦。這一步沒過，後面全部免談。

把研究程式改寫成固定樣板

OptiVaR 是從學者團隊的原始程式移植過來的。AI Agent 把整段運算整理成三個階段：先把價格轉成日報酬，接著用滾動的多變量 GARCH 加二次規劃，求出最小變異的配置權重，最後對整個組合做 GARCH 估計與拔靴模擬，取出風險值區間。整段程式變成一份樣板，每次執行只替換「數字」這個部分。

有一件事我們刻意不做：API 不開放估計視窗這類會改變模型本身的參數。串接方能給的只有價格資料，要動模型設定，得回到研究團隊那一關。輸入的每個數字都會先過檢查，非數字、無限大一律擋掉，估計區間內的價格也必須是正數；程式執行時不經過系統命令列，每次運算都在一個用完即刪的獨立資料夾裡進行。

用佇列同時解決慢和一次一個

單一授權和將近一分鐘的運算時間，用同一個方法處理。請求進來時，系統先建立一筆運算紀錄、丟進專屬佇列，立刻回傳一個編號；背景只有一個工作者在跑，再加一把全域鎖，保證同一時間只有一個運算佔用引擎。串接方拿著編號回來查，算完就拿到結果。這套非同步設計的細節，在 Laravel 非同步實戰和 Queue 容錯設計手冊裡都有拆解。

實測下來，OptiVaR 平均一次約 48 秒，最久一次 73 秒左右；敘述統計、相關係數和迴歸這些簡單模組，則在零點幾秒內就回來。

之後的新模型，照同一條路交件

後台有一個「模組需求」收件匣。研究團隊有新模型時，工程師把統計程式上傳到這裡，AI Agent 再一支一支把它做成模組：移植、寫樣板、補輸入檢查、接上 API 與說明文件。OptiVaR 是這條路上的第一支正式模組，它的移植、API 金鑰機制和給串接方的 API 文件，都在同一天完成。

為什麼不讓 AI 在每一次運算裡即時操作

一開始討論時，最直覺的想像是讓 AI 直接操作統計軟體：使用者丟資料進來，AI 自己寫程式、自己跑。技術上做得到，但我們最後沒有這樣做。

金融試算最重要的兩件事，是同樣的輸入永遠得到同樣的輸出，以及事後查得到是怎麼算的。讓語言模型在每一次請求裡臨場寫程式，等於把一個會變動的環節放進最需要穩定的地方，出錯時也很難追。我們在代理人護欄設計那篇講過同樣的原則：能用程式擋的，就不要只靠模型自律。

所以 AI 的工作停在建造這一側。它把研究程式變成可以重複執行的模組；模組上線之後，每次運算都是同一份樣板、同一套檢查，每一筆都留下紀錄。需要改模型時，再由 AI Agent 和研究團隊一起改樣板。我們說「讓 AI 住進系統」，指的是這個位置：它住在系統持續長大的地方，負責讓新模型一支一支接上來。

OptiVaR 算什麼，不算什麼

這個模組很容易被誤解成預測市場漲跌。它回答的其實是另一個問題：如果資金放在這三種資產上，怎麼配置波動最小，以及接下來三個交易日的報酬，可能落在什麼區間。

如果你想知道預測類模型怎麼跟業務資料接起來，AI 銷售預測模型實戰是另一個方向的例子。

上線之後

對外，博山官網有一個線上試算頁，訪客可以直接試基本運算、敘述統計、相關係數和線性迴歸，每一次運算都留下可追溯的紀錄。OptiVaR 則透過 API 金鑰提供給串接方，對方系統每天傍晚固定時間來呼叫一次，取回最新的配置與風險區間。截至 2026 年 9 月 25 日，OptiVaR 累計執行一百六十多次（含開發測試），其中透過 API 金鑰的呼叫約一百五十次。API 金鑰在資料庫裡只存雜湊值，金鑰本身不落地，驗證方式的考量可以參考 Laravel API 認證實戰。

這種做法適合誰

手上有模型、卻只能靠研究員手動執行的團隊，最適合這條路：金融、保險、不動產估價，或任何「分析做得很好、系統卻叫不動」的單位。模型越穩定、需要被越多系統重複呼叫，越值得包成模組。

反過來，如果模型還在頻繁改動、一個月只跑一兩次，先別急著系統化，讓研究員手動跑反而省事。等模型穩定、呼叫的需求出現，再做也不遲。要自己養工程師接手，還是交給外部團隊，可以先看外包還是自己養工程師的比較。

這類專案的費用取決於模型複雜度、要串接的系統和軟體授權條件，我們在免費診斷看過程式與使用情境之後才報價。想先了解預算由哪些項目組成，可以看客製化系統開發費用怎麼算。我們的AI Agent 開發與客製化系統開發服務頁，也有整理這類專案的做法。

資料來源與查證日期

本文依專案實際交付內容與系統紀錄撰寫，數字查證於 2026 年 9 月 25 日：

• 博山科技官網
• 博山統計運算平台（分析模組與 API 端點列表）
• 博山分析模組線上試算

延伸閱讀

• 排課條件交給 AI 行得通嗎？元智大學終身教育部排課系統案例，另一種 AI 住進系統的方式：直接住在後台，陪承辦人工作。
• MCP、API、CLI 差在哪，看懂系統對外開放的三種介面。
• 用漏斗緩衝與佇列架構防禦流量爆衝，排隊設計的另一個應用場景。
• AI 代理護欄設計的三道防線，把權限交給 AI 之前必讀。

如果你們也有一支只能在研究員電腦上跑的模型，把程式的狀況和想串接的系統寄到 [email protected]，或直接預約免費診斷，我們先幫你判斷它能不能、值不值得包成 API。更多交付案例在作品案例。