做量化交易的人通常都有這種體會模擬盤跑得再順心里也始終懸著一塊石頭畢竟模擬和實盤永遠隔著一堵看不見的墻。我這個項目最開始就是想讓一個 AI Agent 自己去看行情、自己決策、自己在模擬盤里下單同時把每一次買賣和理由同步到飛書像帶了一個能實時匯報的交易助理。整套系統基于 OpenClaw 這個開源 Agent 執(zhí)行框架加上飛書開放平臺的自定義機器人應用我把從零到模擬盤跑通、再到為實盤做準備的全過程完整走了一遍踩了不少坑也總結了一套可以復用的搭建方法。這篇文章就是把這段經歷原原本本記錄下來適合對自動化交易系統、Agent 工具調用、飛書機器人開發(fā)感興趣的開發(fā)者參考。先說明白這套系統本身不構成任何投資建議代碼和參數完全用于技術驗證。尤其是“實盤”部分我只講對接思路和風控準備不會勸任何人把真錢交給 AI 去管。1. 項目設計思路這套架構到底在解決什么問題我先把你可能最關心的問題放最前面為什么偏偏用 OpenClaw 加飛書 Agent 這個組合而不是直接寫一個 Python 定時腳本原因在于傳統定時腳本解決的是“到點執(zhí)行”而 AI 自主系統要解決的是“根據當前狀態(tài)自主判斷下一步做什么”。OpenClaw 的核心價值是把大語言模型變成一個可以調用外部工具的執(zhí)行體你要做的不是把每一步都寫死而是給它注冊好工具、設定好目標讓它自己決定在什么條件下調用買入、賣出、查詢、通知這些動作。飛書 Agent 則解決人機協作的問題——Agent 在后臺再怎么自主運行你也不可能一直盯著終端看把它接進飛書之后每個決策、每筆模擬成交、每日持倉匯總都會以消息形式推送到你的手機你只需要在群里做最終確認和干預。這套系統的整體架構可以拆成四層每一層都有明確邊界交互層飛書機器人應用負責接收用戶指令、推送交易報告和預警消息。決策層OpenClaw 運行時中的 Agent 核心負責調用策略模塊、讀取行情、判斷買賣信號。撮合層自建的模擬交易引擎用虛擬資金模擬真實交易中的手續(xù)費、印花稅、持倉成本和成交邏輯。數據層免費或低成本的行情數據接口提供 K 線、實時報價和賬戶快照。1.1 OpenClaw 在系統里扮演的角色OpenClaw 在這套系統里相當于“管事的那個大腦”但它本身不內置炒股知識它更像一個調度中樞。你要做的事情是把數據源、策略判斷、模擬下單、消息推送這些能力做成一個個具名的工具函數注冊進 OpenClaw 的工具列表里然后給 Agent 一段總目標 Prompt告訴它“你是一個模擬交易助手負責監(jiān)控這幾只標的遵循策略模塊給出的信號執(zhí)行操作并把關鍵動作匯報到飛書”。這種設計最直接的好處是邏輯邊界非常清楚。行情獲取、策略計算、下單撮合這些偏重邏輯的事情用傳統代碼實現而什么時候該看盤、遇到異常怎么處理、如何組織匯報語言這些偏重判斷的事情交給大模型去完成。OpenClaw 跑起來之后每一次周期循環(huán)就是一輪標準的 Agent 工作流讀取工具狀態(tài) → 調用工具獲取數據 → 根據模型輸出決定動作 → 執(zhí)行動作 → 寫日志 → 進入下一輪。我自己沒有把 OpenClaw 魔改成什么很復雜的東西因為它的收益恰恰來自克制。工具只注冊了四個核心函數查詢行情、執(zhí)行模擬買入、執(zhí)行模擬賣出、推送飛書消息。Agent 能做的事再大最終也要落到這四個函數上。1.2 飛書 Agent 解決的人機協作問題把系統接入飛書是我覺得整個項目里影響體驗最關鍵的一步。早期我用最簡單的方式調試也就是把日志寫到文件里等想起來再去看一眼。后來發(fā)現系統自主運行的時候決策理由、執(zhí)行結果、賬戶權益這些信息如果不在第一時間推送到手邊你根本沒法判斷它是不是在正常工作。飛書這邊我有兩種接入方式可以用兩者的定位差別很明顯自定義機器人應用走飛書開放平臺注冊一個企業(yè)自建應用拿到 App ID 和 App Secret通過接口主動發(fā)消息給群聊。能力更完整可以接收消息回調、支持復雜交互適合做正式的 Agent 交互窗口。群自定義機器人 Webhook在飛書群里添加一個自定義機器人提供一個 Webhook 地址用 HTTP POST 就能把消息推到群里。實現成本最低適合快速驗證消息鏈路。第二個方案雖然簡單但它只能發(fā)消息不能收消息對于“人工干預指令”這種需求支持有限。我在項目正式跑起來之后換成了第一種方案因為我還需要能在飛書群里直接發(fā)一句“暫停交易”或“清倉”讓 Agent 響應這些指令。1.3 模擬盤與實盤的邊界標題里寫了“從零到實盤”但我必須把模擬和實盤這兩個階段說清楚因為它們對應的系統要求完全不同。模擬盤階段你的賬戶資金是假的行情是真實的目標是驗證策略邏輯、Agent 決策質量、消息鏈路穩(wěn)定性和故障恢復能力。這個階段可以放開手腳讓 Agent 每天自動跑跑得越久暴露的問題越充分。實盤階段資金變成真的這時候系統要求會發(fā)生質變接口穩(wěn)定性、鑒權安全、交易額度限制、異常中斷恢復、人工熔斷機制每一個都是硬指標。當時我把這套系統連接到真實券商賬戶之前實際上在模擬盤上連續(xù)跑了幾周確認了兩件事一是 Agent 的每次操作都有完整可追溯的日志二是所有操作在極端行情下也不會出現明顯超出風控參數的交易。即便這樣實盤真正上線時我也只放了極小的一筆資金而且保留了隨時人工接管的權利。把這套系統完整做完之后我最大的感受是架構本身不難難的是把每一個細節(jié)都擺到它該在的位置上。下面我先講環(huán)境搭建和基礎接入過程。2. 前期準備飛書機器人、OpenClaw 運行環(huán)境和行情源第一步不是寫核心代碼而是把地基打好。這一階段我花了大約兩天時間主要精力在飛書應用配置和行情接口的穩(wěn)定性測試上。2.1 OpenClaw 運行環(huán)境搭建OpenClaw 是一個以 Python 為主的 Agent 執(zhí)行框架。我是在一臺云服務器上部署的配置不需要太高2 核 4G 內存足夠跑起來因為真正消耗資源的大模型推理走的是 API 調用本地只負責邏輯編排和工具執(zhí)行。環(huán)境準備工作包括安裝 Python 3.10建議用虛擬環(huán)境隔離依賴。通過 Git Clone 拉取項目之后把環(huán)境變量文件拷貝一份在里面配置大模型 API 地址和模型參數。確認網絡能正常訪問行情接口和飛書開放平臺接口這兩者都是標準 HTTPS 請求沒有特殊要求。用官方自帶的 demo 跑一遍工具調用流程確認 Agent 能成功執(zhí)行一次簡單的函數調用。這一步其實不用搞得很復雜。OpenClaw 本身提供了工具注冊的接口你只需要把自定義函數通過裝飾器或者配置表掛上去就能被 Agent 看到。初次跑 demo 時我犯過一個低級錯誤把模型 API 的地址填成了局域網地址導致 Agent 一直處于等待響應的狀態(tài)日志看起來像卡死實際是網絡不通。2.2 創(chuàng)建飛書自定義機器人應用飛書這邊的完整步驟我一步步記錄一下因為配置過程中容易漏掉回調地址的校驗。登錄飛書開放平臺進入開發(fā)者后臺創(chuàng)建一個“企業(yè)自建應用”。在應用能力里開啟“機器人”能力這樣應用在群里表現得像一個普通機器人。在“憑證與基礎信息”頁面拿到 App ID 和 App Secret這兩個值后面代碼里要用。在“事件訂閱”里配置請求地址選擇監(jiān)聽消息事件。注意飛書會先發(fā)送一個 URL 驗證請求你需要讓服務端正確響應 challenge 字段否則配置保存不了。發(fā)布應用版本等待管理員審核通過。對于僅推送消息的場景其實拿到 App ID 和 App Secret 之后就能調接口了。核心邏輯是先用憑證換取一個tenant_access_token再用這個 token 調消息發(fā)送接口把消息以機器人身份發(fā)送到指定群聊。這里有個細節(jié)飛書的 token 有有效期一般是兩小時所以代碼里最好做一層緩存不要每次發(fā)消息都重新請求。我自己的實現里寫了一個簡單的飛書客戶端把獲取 token 和發(fā)送消息封裝成兩個函數token 快過期時才自動刷新。這樣 Agent 在調用推送工具時不需要關心底層憑證的邏輯。2.3 行情數據接入免費源就能跑起來行情數據是整個系統決策的依據這一步我建議優(yōu)先考慮免費開源數據源因為模擬盤階段對行情實時性的要求并沒有想象中那么高。我用的方案是 Python 的開源數據接口庫通過它把 A 股的歷史日線數據和實時行情都拿到本地。它支持滬深京三地股票也支持指數和基金基本覆蓋了我們常見的需求。對于更專業(yè)的分鐘級數據也可以申請一些數據平臺的測試 token但免費額度通常有限做模擬盤夠用了。行情模塊只需要封裝三個底層能力獲取單只標的的最新價格獲取單只標的最近一段時間的日 K 數據獲取整個監(jiān)控列表的行情快照。為了讓 Agent 調用更順手我把這三個能力封裝成一個統一函數入參是股票代碼返回一個包含最新價、漲跌幅、近五日收盤價的字典。Agent 只關心“這個標的價格是多少、趨勢怎么樣”這類語義化的問題數據獲取的技術細節(jié)被完全屏蔽在函數內部。這里要注意免費數據接口在盤中請求頻率過高容易被臨時限制訪問。我自己踩過這個坑Agent 循環(huán)間隔設得太短每分鐘去拉一次全列表行情結果跑了一個多小時數據源就返回空數據了。后面把輪詢間隔拉長到五分鐘并為接口加了一組備用源切換邏輯是主源返回空數據或者連續(xù)超時的時候自動切換。3. 核心模塊一個一個寫模擬撮合、決策循環(huán)和消息推送地基搭好之后就可以開始把系統的五臟六腑填充起來了。這一部分是整個項目工作量最大的地方也是讓我覺得最有收獲的地方。3.1 模擬撮合引擎虛擬資金先跑起來模擬撮合引擎的核心職責就是讓買賣操作在虛擬資金池里產生真實的成本和盈虧。它不需要跟真實券商系統對接但一定要盡量貼近實際交易的費用規(guī)則。我用一個 Python 類實現了最簡版本的模擬券商from dataclasses import dataclass, field from typing import Dict dataclass class Position: symbol: str shares: int avg_cost: float dataclass class MockAccount: cash: float positions: Dict[str, Position] field(default_factorydict) trade_log: list field(default_factorylist) class MockBroker: def __init__(self, initial_cash: float 100000.0): # 初始資金默認10萬元純虛擬 self.account MockAccount(cashinitial_cash) def market_buy(self, symbol: str, shares: int, price: float): cost price * shares # 傭金按萬2.5計算不足5元按5元收取 commission max(cost * 0.00025, 5) total_cost cost commission if self.account.cash total_cost: raise RuntimeError(f現金不足無法買入 {symbol}) self.account.cash - total_cost if symbol in self.account.positions: pos self.account.positions[symbol] new_total_shares pos.shares shares # 移動加權平均成本 pos.avg_cost (pos.avg_cost * pos.shares cost) / new_total_shares pos.shares new_total_shares else: self.account.positions[symbol] Position(symbol, shares, price) self.account.trade_log.append( (買入, symbol, shares, price, commission, 0) ) def market_sell(self, symbol: str, shares: int, price: float): pos self.account.positions.get(symbol) if not pos or pos.shares shares: raise RuntimeError(f持倉不足無法賣出 {symbol}) proceeds price * shares commission max(proceeds * 0.00025, 5) # 印花稅按賣出金額的千分之0.5計算 stamp_tax proceeds * 0.0005 net_proceeds proceeds - commission - stamp_tax self.account.cash net_proceeds pos.shares - shares if pos.shares 0: del self.account.positions[symbol] self.account.trade_log.append( (賣出, symbol, shares, price, commission, stamp_tax) ) def total_assets(self, price_map: Dict[str, float]) - float: stock_value sum( pos.shares * price_map.get(symbol, pos.avg_cost) for symbol, pos in self.account.positions.items() ) return self.account.cash stock_value這個引擎把幾個關鍵規(guī)則都覆蓋了買入時計算傭金賣出時額外計算印花稅持倉成本用移動加權平均法計算賬戶權益等于現金加持倉市值。模擬盤的成本結構和真實交易已經非常接近得出的收益曲線也更有參考價值。在真實代碼里我會把交易日志同時寫入一個 CSV 文件保證 Agent 崩潰重啟后還能通過日志恢復賬戶狀態(tài)。這是模擬盤階段容易被忽略、實盤階段卻非常致命的問題。3.2 決策模塊規(guī)則策略怎么接入 Agent決策模塊是整個系統里最符合“策略”二字的部分。我沒有在一開始就設計很復雜的模型而是先用一個基于均線關系的規(guī)則策略跑通全鏈路。原因很簡單復雜模型出錯了你很難判斷是策略問題還是系統問題簡單策略則可以讓所有異常都暴露在可解釋的邏輯里。這個策略的邏輯非常樸素對每個監(jiān)控標的計算近 5 日均線和近 20 日均線當 5 日均線上穿 20 日均線時產生買入信號當 5 日均線下穿 20 日均線時產生賣出信號其他情況保持當前狀態(tài)不變。def make_decision(kline_list, position_shares): kline_list: 按時間升序排列的收盤價列表 position_shares: 當前持倉股數 if len(kline_list) 20: return hold, 數據不足 closes [k[close] for k in kline_list] short_ma sum(closes[-5:]) / 5 long_ma sum(closes[-20:]) / 20 if short_ma long_ma and position_shares 0: return buy, f5日均線{short_ma:.2f}上穿20日均線{long_ma:.2f} if short_ma long_ma and position_shares 0: return sell, f5日均線{short_ma:.2f}下穿20日均線{long_ma:.2f} return hold, f均線狀態(tài)無變化short{short_ma:.2f}, long{long_ma:.2f}為什么要把決策邏輯放到一個普通函數里而不是直接讓大模型自己算均線因為大模型不擅長精確數值計算讓它算均線既慢又容易出錯。正確的分工是數值計算交給代碼判斷和調度交給模型。Agent 的職責是調用 make_decision 獲取信號然后把買入或賣出信號翻譯成一次 mock_buy 或 mock_sell 調用。這個經驗是項目中的一個重要轉折點。最初我試著讓 Agent 自己做技術指標計算和信號判斷結果十次里有三次方向是反的而且給出錯誤信號后它還會一本正經地生成一段解釋顯得自己特別有道理。后來我把所有需要精確計算的部分全部下沉為工具函數Agent 只做動作選擇整個系統的可靠性一下子提升了一個臺階。3.3 OpenClaw 任務循環(huán)讓它自己跑起來OpenClaw 的任務循環(huán)是這套系統的發(fā)動機。為了讓 Agent 真正“自主”我們得給它注冊好工具再設定一個大目標讓它在這個目標框架內循環(huán)決策。工具注冊的關鍵代碼大致長這樣# 在 OpenClaw 中注冊自定義工具 def register_stock_tools(claw): claw.register_tool( nameget_quote, description獲取指定股票的實時價格和近期K線數據, parameters{ symbol: {type: string, description: 股票代碼例如 600000} }, funcget_quote, ) claw.register_tool( namemock_buy, description在模擬賬戶中買入指定股票傳入股票代碼和股數, parameters{ symbol: {type: string}, shares: {type: integer, description: 買入股數必須是100的整數倍}, }, funcmock_buy, ) claw.register_tool( namemock_sell, description在模擬賬戶中賣出指定股票傳入股票代碼和股數, parameters{ symbol: {type: string}, shares: {type: integer, description: 賣出股數不能超過當前持倉}, }, funcmock_sell, ) claw.register_tool( namepush_feishu, description推送文本消息到飛書群聊, parameters{ text: {type: string, description: 要推送的文本內容}, }, funcpush_feishu, )注冊好之后給 Agent 設置一個總目標 Prompt。我用的是這個方向的描述“你是一個自主模擬炒股助手。你擁有查詢行情、模擬買入、模擬賣出、推送飛書消息四個工具。你的任務是每隔一段時間檢查監(jiān)控列表中的標的根據工具返回的數據調用決策函數判斷買賣信號。每次執(zhí)行買賣后必須調用推送飛書消息工具把操作內容和原因發(fā)送到群里。如果賬戶現金不足或者持倉不足不要重試超過兩次直接把異常信息推送至飛書?！边@個 Prompt 有三個關鍵設計明確告訴 Agent 有哪些工具可用避免它自己臆造不存在的函數。明確要求它“每次執(zhí)行買賣后必須推送消息”用機制保證可觀測性。明確異常處理方式避免 Agent 陷入無意義的死循環(huán)。OpenClaw 的調度頻率我是通過外部定時任務控制的比如每隔 10 分鐘觸發(fā)一次 Agent 運行。這是因為大模型 API 調用本身有延遲和費用你不可能讓 Agent 像高頻交易系統一樣每秒跑一次也沒有必要。3.4 飛書消息推送的實現飛書消息推送這塊我前面提到有兩個方案正式版我采用了自定義機器人應用。核心代碼其實就是兩步換 token 和發(fā)消息import requests import time class FeishuClient: def __init__(self, app_id: str, app_secret: str): self.app_id app_id self.app_secret app_secret self.token None self.token_expire_at 0 def _get_token(self) - str: # token 兩小時有效在有效期內直接復用 if self.token and time.time() self.token_expire_at: return self.token resp requests.post( https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal, json{app_id: self.app_id, app_secret: self.app_secret}, timeout10, ) data resp.json() self.token data[tenant_access_token] self.token_expire_at time.time() data.get(expire, 7200) - 60 return self.token def send_text(self, chat_id: str, text: str): token self._get_token() resp requests.post( fhttps://open.feishu.cn/open-apis/im/v1/messages?receive_id_typechat_id, headers{Authorization: fBearer {token}}, json{ receive_id: chat_id, msg_type: text, content: json.dumps({text: text}), }, timeout10, ) return resp.json()這里有一個飛書 API 的細節(jié)content 字段必須是一個字符串化的 JSON直接傳字典會被接口拒絕。我第一次接入時在這里卡了快二十分鐘一直報參數錯誤后來仔細查文檔才發(fā)現這個坑。把推送功能接好后我讓 Agent 在消息里用固定格式輸出比如【模擬交易】買入 600000 浦發(fā)銀行 200股 成交價格10.25 觸發(fā)原因5日均線上穿20日均線 賬戶剩余現金98620.50固定格式好處非常多它讓歷史記錄更容易追溯而且你掃一眼飛書消息就能判斷 Agent 行為是否正常不需要逐行翻日志。4. 從模擬盤到實盤我踩過的坑和過渡清單模擬盤和實盤之間的距離比大多數人想象中要遠得多。模擬盤里跑出的漂亮收益曲線換成實盤后可能會因為各種微小差異而面目全非。我把自己一路從模擬切到實盤的過程整理成下面幾個要點。4.1 模擬盤驗證的重點指標模擬盤階段最重要的事情不是看收益有多高而是驗證系統在長時間運行下能不能保持穩(wěn)定。我給自己定了四個核心驗證指標連續(xù)運行時長系統是否能連續(xù)運行一兩周不崩潰、不卡死。Agent 框架、數據源接口、消息推送任何一個環(huán)節(jié)掉鏈子都會中斷自主交易。操作可追溯性每一筆模擬交易的觸發(fā)原因、成交價格、費用明細是否完整記錄。不可追溯的操作等于沒有發(fā)生。信號執(zhí)行一致性Agent 是否嚴格按決策模塊的信號執(zhí)行有沒有出現信號是買入、結果卻變成賣出的情況。異常自恢復能力數據源超時、接口限流、飛書 token 過期這類常見故障發(fā)生后系統能否自動恢復并在下個周期繼續(xù)正常工作。模擬盤階段如果把這四個指標練扎實了切換實盤時心里會稍微有底一些。4.2 實盤接入的注意事項實盤接入并不是簡單地換一個真實賬戶接口就完事了。它涉及券商選擇、接口權限申請、資金劃轉、風控參數配置等一系列環(huán)節(jié)。首先任何實盤操作都必須通過券商官方提供的量化交易接口或者合法合規(guī)的交易軟件進行。個人開發(fā)者對接實盤時優(yōu)先找支持這種接入方式的券商開戶的時候直接咨詢量化接口的開通條件。我這邊最終用的是一個支持 Python 接口的量化柜臺申請通過后券商提供一個獨立的資金賬號這個賬號和你平時用的交易賬號隔離可以單獨設置交易權限和資金上限。其次安全方面有一個容易忽視的細節(jié)API 密鑰和賬號信息絕對不能寫在代碼里或者提交到代碼倉庫。我自己專門在服務器上配置了一個環(huán)境變量文件權限設置為只有運行用戶可讀程序啟動時從環(huán)境變量加載賬號信息。實盤下單前還有一個必須做的動作在券商的客戶端里手動設置風控參數包括單筆最大委托金額、單日最大委托次數、最大持倉數量等。這些限制是資金安全的最后一道防線萬一 Agent 或代碼出現邏輯失控券商的系統會自動攔截異常委托。4.3 風控清單我把實盤階段必須做到的風控項做成了一份清單每次調整系統后我都會對著清單過一遍資金額度實盤賬戶只放總資金的一小部分比例設定到即使全部虧完也不會影響生活的水平。人工熔斷開關在飛書群里預留一個指令比如“緊急暫?！盇gent 收到后立即停止所有后續(xù)操作。這個功能對 Agent 來說是一種安全繩。操作限額在模擬撮合引擎之外再加一層實盤專用的參數校驗任何單筆金額超過設定上限的委托都會直接拒絕。盯盤閾值設置一個最大單日虧損百分比觸發(fā)后自動停止當日后續(xù)交易。賬號隔離實盤賬戶和測試賬戶的憑據嚴格分開避免誤操作把測試代碼發(fā)到實盤。日志備份每一筆實盤委托和回報都同步寫入數據庫且每 5 分鐘做一次增量備份。這個清單不是萬能的但它能把最壞情況造成的損失控制在可接受范圍內。5. 常見問題與排查思路實錄整個項目開發(fā)和運行期間我記錄了一批典型問題。我把它們整理成一份問題速查表形式方便你直接對照排查?，F象可能原因排查步驟與解決方案Agent 長時間無響應大模型 API 網絡不通或配置錯誤先手動調用一次模型接口確認連通性再查看 Agent 日志中最后一次請求的狀態(tài)碼飛書機器人發(fā)不出消息token 過期或 chat_id 錯誤檢查 token 刷新邏輯用飛書 Open API 調試工具手工發(fā)一條消息定位問題行情數據突然為空免費數據源被限流或網絡異常檢查接口返回的字段切換備用數據源并適當降低請求頻率Agent 重復執(zhí)行同一買入操作狀態(tài)記錄缺失導致重復決策檢查賬戶狀態(tài)是否持久化確保 Agent 每次讀到的都是最新持倉模擬賬戶現金變成負數買入前未檢查可用資金在 mock_buy 里增加資金校驗并在異常時通過推送通知人工處理實盤委托被券商拒絕超出券商設置的風控閾值查看券商客戶端內的委托拒單原因調整 Agent 參數或券商風控配置還有幾個排查經驗比較瑣碎但對效率影響很大。第一日志必須帶時間戳和工具名。Agent 執(zhí)行鏈路長沒有時間戳的日志在排障時幾乎是廢的。我自己后來在 OpenClaw 里給每個工具調用都包了一層裝飾器自動記錄調用時間、入參、出參和耗時。第二異常不要靜默吞掉。最初我在一些接口調用上用了 try except 加 pass結果系統看起來一切正常實際上已經好幾天沒有執(zhí)行任何交易了。正確的做法是任何異常都要推送飛書即使不影響主流程也要讓你知道系統發(fā)生了異常。第三模擬盤數據輸出格式要穩(wěn)定。行情接口偶爾會返回缺失字段如果程序直接拋異?；蜉敵龈袷絹y七八糟Agent 的決策質量會急劇劣化。解決方案是寫一個統一的數據清洗函數所有數據源返回后先過清洗邏輯再交給 Agent。第四升級代碼前一定要備份當前狀態(tài)。模擬盤階段還好實盤階段任何一個代碼變更都要先在測試環(huán)境完整跑一遍確認沒有副作用后再部署到實盤。我在實盤系統上線前的最后一次演練是把所有異常情況都主動觸發(fā)了一遍斷掉行情接口、偽造飛書 token 過期、給模擬引擎造資金不足的假數據然后記錄了系統每個環(huán)節(jié)的反應。這套故障演練方法比修好任何一個具體 bug 都更有價值因為它能驗證整個系統的韌性。最后再分享一點個人體會。做 AI 自主交易系統最容易踩的坑是過分崇拜 Agent 的能力。大模型確實擅長理解和生成但它完全不擅長精確計算和紀律執(zhí)行而交易系統偏偏對精確和紀律要求極高。把這兩者的優(yōu)勢結合起來讓模型負責判斷和交互讓代碼負責計算和執(zhí)行這套系統才能走得遠。我現在每天還是會翻一遍飛書群里的交易記錄看看 Agent 的行為是否合乎預期。這不是不信任它而是作為系統的負責人你永遠需要保留對系統行為的最終解釋權和掌控權。