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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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