LLM寫市場評論有個老毛病——沒看數(shù)據(jù)也能說得頭頭是道。閑聊無所謂，但做產(chǎn)品功能、內(nèi)部工具，用戶真信了就是事故。

這篇指南教你搭一個金融助手：用MCP協(xié)議（模型上下文協(xié)議）拉取真實數(shù)據(jù)，Python算指標，LLM只負責把算好的事實講清楚。不發(fā)明數(shù)字，不做數(shù)學題，只當"播音員"。

最終產(chǎn)出兩個能直接塞進產(chǎn)品流程的模塊：單只股票市場簡報，以及對比多只股票波動率和回撤的觀察清單。所有工具調(diào)用都有跡可循，用了什么數(shù)據(jù)一目了然。

MCP到底是什么，為什么能省掉一堆膠水代碼

MCP解決的是工具集成的標準化問題。以前每換個數(shù)據(jù)源就要重寫一遍封裝層，現(xiàn)在MCP服務器把工具暴露成統(tǒng)一格式，應用端自動發(fā)現(xiàn)、直接調(diào)用。

對產(chǎn)品經(jīng)理來說，這意味著集成成本可控。工具發(fā)現(xiàn)可預測，技術棧換了不用重寫wrapper，模型層和數(shù)據(jù)層徹底解耦。

本教程的數(shù)據(jù)層用的是EOD Historical Data（EODHD），一家市場數(shù)據(jù)供應商。他們的MCP服務器暴露了價格和基本面工具，助手需要時直接調(diào)用。

關鍵前提：這里的MCP服務器純粹當數(shù)據(jù)入口用。模型不決定調(diào)哪個工具、傳什么參數(shù)——這些由代碼硬編碼，確保結果可復現(xiàn)。

"播音員"架構：讓LLM只動嘴，不動手

整個系統(tǒng)分三層：MCP客戶端封裝、助手核心邏輯、 narration輸出。數(shù)據(jù)流是單向的：工具調(diào)用→確定性計算→LLM潤色。

客戶端層（client.py）處理MCP服務器連接、工具發(fā)現(xiàn)、異步調(diào)用。核心層（core.py）包含7個模塊：預算與追蹤日志、請求解析、價格和基本面工具封裝、確定性指標計算、觀察清單工具、事實對象與narration、以及編排函數(shù)run_assistant()。

預算機制是個實用設計。每次調(diào)用前檢查token消耗和API調(diào)用次數(shù)，防止跑飛。追蹤日志則記錄完整的工具調(diào)用鏈，方便審計。

指標計算全部用pandas和numpy完成。年化波動率、最大回撤、夏普比率——這些數(shù)字是算出來的，不是問出來的。LLM拿到的只是格式化后的事實對象。

兩個Demo：從單股簡報到多股對比

Demo 1輸入一個股票代碼，輸出市場簡報。流程：調(diào)用價格工具→計算20日波動率和52周回撤→查基本面→LLM用固定模板生成三段式評論。全程約4次API調(diào)用，耗時3秒內(nèi)。

Demo 2處理觀察清單。輸入多個代碼，并行拉取數(shù)據(jù)，計算橫向對比指標。輸出表格+文字解讀，突出波動率分位和回撤排名。適合盤前快速掃一眼持倉風險。

兩個Demo都保留了原始工具調(diào)用記錄。用戶點一下就能看到"這個數(shù)字來自哪次API返回"， debug和產(chǎn)品演示都很方便。

能直接上線嗎？還差點什么

當前版本是MVP級別。已具備：確定性的指標計算、可追溯的數(shù)據(jù)血緣、清晰的LLM職責邊界。欠缺：實時數(shù)據(jù)流（目前是日終批量）、錯誤重試機制、以及多用戶并發(fā)隔離。

如果要產(chǎn)品化，建議優(yōu)先加緩存層。EODHD的日終數(shù)據(jù)不變，重復查詢直接命中Redis，成本能降一個數(shù)量級。

另一個隱藏收益：這套架構換數(shù)據(jù)源極快。把EODHD的MCP服務器換成Bloomberg或Wind，核心代碼幾乎不用動——只要新服務器的工具名和參數(shù)格式一致。

代碼已開源。需要準備：EODHD API key、OpenAI API key、支持async的Python環(huán)境。沒寫過異步代碼也能跟，把async函數(shù)當成"網(wǎng)絡請求黑箱"就行，重點看數(shù)據(jù)怎么從工具流到最終輸出。

最后留個實際問題：如果你的金融助手某天算出的夏普比率跟用戶自己的Excel對不上，你會優(yōu)先懷疑數(shù)據(jù)源頭、計算邏輯、還是LLM的narration把數(shù)字寫錯了？