Home

把券商 API 包成只讀工具給 agent — Kuan-Yu Hsieh 的 OpenClaw 投資流程，補兩條他沒看到的資訊差

2026-06-07 · 8,277 字 · 19 分鐘

原文出處：OpenClaw 龍蝦接上股票券商 API — Kuan-Yu Hsieh

本文為 Claude 對外部文章的解說整理，非原文作者觀點。

若您是原作者並希望下架，請來信 [email protected]。

原文（Kuan-Yu Hsieh 撰；點開看全文）

OpenClaw 龍蝦接上股票券商 API

自從架好 OpenClaw 龍蝦之後，我就一直想讓 Agent 幫我處理跟投資紀錄有關的事，最近終於有空把自己的 AI-native 投資流程搞起來

因為真的太多人問我怎麼串的，為了大家的生計跟我的生計，乾脆整理一下我怎麼串的。

我不是要讓它自動下單，只讓它能讀資料、整理資訊、輔助分析，我希望它能做到幾件事：

1. 查看個人持股
2. 查詢即時盤況
3. 進行庫存分析
4. 把選股策略記在電腦上

這樣以後我跟 AI 討論策略，它就不是憑空亂聊，而是看著我實際的持股跟市場資料在分析。

投資記憶先給他建起來

————

下面把流程拆開講，順便把踩過的雷一起寫進來，大概照著做應該就會動了

1. 先架好 OpenClaw 龍蝦

第一步先把龍蝦架起來（有點廢話）後面才有一個能掛工具、讓不同 LLM 調用的 agent 系統。龍蝦就是模型跟外部世界中間那層 — LLM 負責想，真正伸手去碰券商 API 的是掛在它身上的工具

2. 跟永豐金申請 API Key（超雷…）

到永豐金後台的 API 金鑰管理申請，四個權限 — 行情/資料、帳務、正式環境、交易 — 我全部勾，環境選正式

雷在這：我做的明明是「只查不下單」，照理「交易」權限不勾不是更安全？結果不行。永豐的帳務查詢被後台一個 signed=True 開關鎖著，沒開的話查庫存、查餘額一律回 406；要打開它得先用模擬模式對帳戶下一筆不會成交的假單，後台才會把帳戶標記成可查 — 而下單（就算假單）就需要交易權限。

所以結論有點好笑：一個只想查資料的工具，權限反而要全開。你跟我開玩笑？還是我哪裡做錯了？永豐的工程師歡迎跟我聊聊

（這個啟用是一次性的，屬帳戶屬性，開過就永久有效）

那權限全開，AI 不就能亂下單？不會，擋它的根本不是權限。永豐要送一筆真單，程式得先用 CA 憑證（activate_ca）把 .pfx 啟用過才送得出去；而我從頭到尾不想下載憑證、不呼叫 activate_ca、不寫任何下單函式 — 所以模型就算想下單，架構上也送不出去

3. 自己寫一支查詢腳本

key 到手後，我針對券商 API 包了一支查詢腳本：查庫存跟未實現損益、查區間已實現損益、查即時報價、抓歷史 K 棒

真正花時間的不是查詢，是把資料整理成 agent 能直接吃的格式 — 每個函式都回乾淨的 dict / list，別回券商原本那包物件，才能直接 json 化丟給模型、也能 pipe 給別的工具（我自己還有寫一個 Human Readable 的輸出）

還有個很煩的雷：查股票庫存一定要指定單位是股（Unit.Share），不然純零股部位會直接回 0，混合部位的零股成本也會被漏算。我就是不知道為什麼買零股的 AI 都說我沒有庫存才發現的

多帳戶我用 profile 設計 — 新增帳戶只要加兩個環境變數，不用改 code。我自己是本人加家人兩個 profile 共用一套

4. 把腳本整合進 OpenClaw 龍蝦的 Tools

工具寫好接進龍蝦。我沒寫原生 plugin/skill，這個架構太簡單了，改 TOOLS.md 就可以 — 把怎麼啟動、哪支腳本做什麼、profile 怎麼切、死規則是什麼寫清楚，龍蝦讀了就會自己在 bash 照規則跑這些腳本

接進去後，不同 LLM 都能透過龍蝦調用這支工具 — 模型完全不用知道券商 API 怎麼串，只看得到我開放的那幾支查詢

這裡藏了我覺得最重要的設計：agent 的能力面就只有這幾支查詢腳本，沒有下單那條路。所以不下單不是我在 prompt 裡拜託它乖一點，而是它結構上根本做不到。我還把死規則（不准出現 place_order、activate_ca 這些字）寫成 CI 跟 pre-commit 的 git grep，code 裡冒出這些字就直接 fail — 這條規則是機器在擋，不靠我自律

弄到這邊，基礎設施就差不多了。我現在每天大概這樣用：

・早上讓它自動讀庫存，做盤前、盤後分析，盤中也會監測，有狀況就通知我

・盤中掛了 cron，每 30 分鐘自動抓 watchlist 即時報價，整理成精簡的表推到聊天群組（現價、漲跌、距買賣點、有沒有觸發）— 整條 pipeline 一樣只讀不寫

・個人資訊雷達掃到新的選股理論、或新聞冒出熱門題材時，讓它去找相關標的、推薦給我

・每天丟幾個還不錯的候選給我

・也可以叫它分析某檔成分股出現在哪些 ETF、最近那些 ETF 的狀況

這次比較像先把地基打好，再往下我覺得會卡在投資記憶。現在的投資記憶很零散，每一筆大概就是某個時間點的選股策略，至今還沒整理過。之後應該得引入帶 consolidation 的記憶管理，把這些散落的策略整合成比較穩定的長期觀點。還沒做，以後再說，現在 Context Window 這麼大，不怕

把券商 API 包成一支只查不下單的工具，接進 OpenClaw 龍蝦，讓 AI 在有真實資料的情況下幫我分析，而它動不了我的錢

以後有錢一點，有乾爹，再讓它自動下單

————

（作者留言補充：完整可跑的版本 — 腳本核心片段、API 申請細節、對照官方文件的部分 — 整理成一份 gist。不是什麼很屌的或很新的東西，希望幫得上有緣人的忙。）

說明：本文只解說 Kuan-Yu Hsieh 的原文（含他自己的留言補充）。這是技術實作分享文，論點分層改成「設計判斷 / 技術主張 / 經驗觀察」三層，個人感想不評估。第 3 節走硬文 mode，並針對「為什麼只查也要全開權限」這段對廠商的抱怨做事實核查 — 比對永豐官網的 AI Coding Assistant 與金管會 API 法規，看根因到底落在哪裡。

1. 核心論證骨幹

Kuan-Yu Hsieh 想用 agent 幫他做投資分析，但不想讓 agent 動到他的錢 — 於是他把永豐金 Shioaji 券商 API 包成「只查不寫」的查詢工具，接進自架的 OpenClaw 龍蝦 agent 框架。

他的核心安全主張只有一句：不下單這件事不能靠在 prompt 裡拜託模型乖一點，要靠結構性的不可能 — 程式碼裡乾脆不寫下單函式、不下載 CA 憑證、不呼叫 activate_ca；再用 CI 與 pre-commit 的 git grep 擋住敏感字（place_order、activate_ca）出現在 code 裡，機器在擋、不靠自律。

實作流程是四步：架龍蝦 → 申請永豐 API key（踩雷，「只查也要全開權限」）→ 寫查詢腳本（資料整理成乾淨的 dict / list，零股要指定 Unit.Share）→ 整合進龍蝦的 Tools（用 TOOLS.md 文字檔讓 LLM 自己讀 bash 跑腳本，沒寫原生 plugin）。

他的判斷是：基礎設施差不多了，下一步會卡在「投資記憶」 — 散落的選股策略需要 consolidation 整合成長期觀點。並且自承：「以後有錢一點，有乾爹，再讓它自動下單。」

2. 論點分層萃取

這篇是技術實作文，有很多技術細節（profile 多帳戶設計、dict / list 輸出、零股 Unit.Share 雷），但能支撐整篇的核心命題只有 4 條。其他細節都是支持這 4 條的論據或踩雷，併進對應骨幹討論，不獨立列。

「不下單」不靠 prompt 拜託，靠 agent 的能力面結構性沒有這條路（設計判斷，核心）

不下單不是我在 prompt 裡拜託它乖一點，而是它結構上根本做不到

→ 整篇文章最核心的安全設計原則。能力面 = 開放的工具集 ∪ 工具能呼叫的函式集；下單函式不在裡面，就不存在「能不能下單」這個問題。對應到 capability-based security 與 principle of least privilege。

死規則用 git grep 寫成 CI + pre-commit，機器擋字面字串（設計判斷，第二道防線）

我還把死規則（不准出現 place_order、activate_ca 這些字）寫成 CI 跟 pre-commit 的 git grep

→ 把規則從「人自律」推到「機器強制」。在 commit / merge 階段就 fail，是教科書級的左移檢查（shift-left）做法。

沒寫原生 plugin / skill，改用 TOOLS.md 讓 LLM 自己讀 bash 跑腳本（設計判斷）

我沒寫原生 plugin/skill，這個架構太簡單了，改 TOOLS.md 就可以

→ 在「結構化 tool schema」與「靠 markdown 文字檔協作」之間選了後者。這個選擇對個人 / 單機 / 單目的場景非常划算。

「只查資料的工具，權限反而要全開」 — 暗示永豐 API 設計失誤（經驗觀察 + 隱含抱怨）

結論有點好笑：一個只想查資料的工具，權限反而要全開。你跟我開玩笑？還是我哪裡做錯了？永豐的工程師歡迎跟我聊聊

→ 對永豐 API 設計的不滿。措辭保留了「還是我哪裡做錯了」這個開放餘地。這條是這篇文章最需要做事實核查的論點 — 第 3 節會直接拉永豐官網與金管會法規來對照。

其他次要技術細節 — 永豐送真單需要 CA 憑證、零股要指定 Unit.Share、查詢函式回乾淨 dict / list、多帳戶 profile 設計、日常 use case、投資記憶下階段卡點 — 都併進對應骨幹當論據或案例。個人感想層級（「以後有錢一點」、「不是什麼很屌的或很新的東西」）不評估。

3. 論述評估（硬文 mode：論證強度評估 + 資訊差核查）

這是技術實作文，有可查證的技術事實主張、引用了外部產品（Shioaji）並對它有意見，走硬文三段式評估。對 4 條骨幹逐項看。對第 4 條抱怨，會直接拉永豐官網與金管會法規當輔助資料做事實核查。

「不下單」不靠 prompt 拜託，靠 agent 的能力面結構性沒有這條路

論據能支撐到哪裡？

這個論點對應到資安領域很硬的兩條原則。一條是 capability-based security — 程式的能力面只能由它持有的 capability 決定，沒持有就做不到。另一條是 principle of least privilege — Saltzer & Schroeder 1975 年那篇 The Protection of Information in Computer Systems 把這條寫成顯學，五十年來沒有過時。

更貼近現在的脈絡：Anthropic、OpenAI、Google DeepMind 近兩年都反覆強調，agent 安全的「最便宜也最可靠」做法不是訓練模型更乖，而是用工具的最小曝光面與沙箱把不該做的事「結構性地」拿掉。所以作者的這條主張不是個人偏好，是當前 LLM 安全社群的共識。

論證紮實。

結論是否跳太快？

要小心的只有一點：「結構上根本做不到」這句話在 Python 動態語言環境下不是絕對的 — 如果模型有 shell 執行權，它仍可能用 pip install shioaji 在執行時動態載入並 activate_ca。所以「結構上做不到」的真正前提是：agent 不能任意執行 shell、不能 pip install 工具集以外的套件、不能寫檔到能被執行的位置。

更精準的說法應該是：

agent 的能力面要靠工具集邊界與執行環境共同收緊；下單函式不在工具集裡是必要條件，但若 agent 同時可以執行任意 shell / 安裝任意套件，那「結構上做不到」就會退化成「設計上有意不暴露」 — 仍然有意義，但保證強度不同。

要讓論點完整，需要補什麼？

可以加一段執行環境邊界的描述：agent 的 shell 是不是 sandboxed？能裝套件嗎？能寫到什麼路徑？這些決定了「結構上做不到」的真正強度。

死規則用 git grep 寫成 CI + pre-commit，機器擋字面字串

論據能支撐到哪裡？

把規則從「人寫文件提醒」推到「機器在 commit / merge 時 fail」，這是教科書級的左移檢查做法。git grep 簡單、快、不需要新工具鏈，當作第二道防線非常划算。

論證紮實。

結論是否跳太快？

要小心的是 git grep 只擋字面字串。理論上模型可以用字串拼接（getattr(api, "place" + "_order")）、eval、反射 (importlib) 或 base64 編碼繞過。要 grep 全部擋住要寫一堆 regex。

所以這層的真正定位是「擋掉模型不小心生成的直接呼叫」，不是「擋掉對抗式的繞過」。

更精準的說法應該是：

git grep 擋禁字是一道便宜有效的左移防線，能擋住模型誠實寫出 place_order(...) 的情況；但要擋對抗式繞過，仍要靠執行環境沙箱（沒有 eval、沒有任意 import、沒有 shell escape）。兩道防線分工，不能互相取代。

要讓論點完整，需要補什麼？

可以加一段「左移擋誠實使用、執行環境擋對抗繞過」的分工描述。或乾脆改用 AST-level lint（例如自訂 ruff 規則），就能擋到更多字串拼接型態。

沒寫原生 plugin / skill，改用 TOOLS.md 讓 LLM 自己讀 bash 跑腳本

論據能支撐到哪裡？

對於「單一使用者、單一目的、固定環境」的場景，這套設計極輕量 — 不需要學 MCP / plugin SDK、不需要維護 schema、不需要重新部署，改 TOOLS.md 就生效。

論證紮實（在這個 scope 內）。

結論是否跳太快？

要小心的是這個架構的取捨：拿不到的好處包括結構化 schema 驗證（MCP / function calling）、強型別回傳、跨機器跨團隊的 reproducibility。對個人 use case 來說划算；要 share 給別人用就會開始痛。

順帶一提，永豐官方那個 Claude Code plugin 其實已經實作了一個結構化版本可以參考 — 這條訊息會在下一條論點裡展開。

要讓論點完整，需要補什麼？

可以加一段「什麼時候從 TOOLS.md 切到 MCP / 原生 plugin」的判斷標準 — 多人共用、多機器同步、需要型別保證的場景就該切。

「只查資料的工具，權限反而要全開」 — 暗示永豐 API 設計失誤

這段是這篇文章裡論證最弱的部分。把官網與法規一起拉出來對照，會看到兩層資訊差。

論據能支撐到哪裡？

作者實際遇到的現象是真的 — 「沒勾交易權限就無法跑通啟用流程」「signed=True 沒開、查帳務回 406」「啟用 signed=True 需要先在模擬模式下假單」「下假單需要交易權限」。這些不是作者誤解，是 Shioaji 開通流程的客觀事實。

所以「只查資料的工具，權限反而要全開」這個現象描述成立。

結論是否跳太快？

跳太快的不是現象描述，是把現象的根因歸給「永豐工程師設計失誤」。

第一層資訊差：永豐官網其實有專門的 AI Coding Assistant

永豐有專門的 AI agent 整合入口（sinotrade.github.io/ai_assistant），自稱「first financial API in Taiwan to support LLM.txt and AI Coding Agent Skills」。它提供：

也就是說，signed=True 與「先做模擬下單」在官方文件裡是公開的 milestone，不是隱藏雷區。作者文章從頭到尾沒提到這個入口的存在，看起來是直接從 API 後台與一般 tutor 文件摸索 — 路徑上少看了那一頁。

第二層資訊差：先模擬下單測試是金管會法規要求

「先模擬下單測試才能啟用正式環境」這個流程不是永豐自找麻煩，是金管會證期局「證券商受理投資人使用應用程式介面（API）服務作業規範」的明文要求：「投資人首次使用 API 委託下單前，應就相關傳輸設定進行連線測試，並留存相關測試紀錄。」

永豐自己的 tutor 中文版（條款簽署與測試頁）也直接寫了：「Due to Taiwan financial regulations, new users must sign relevant documents and complete a test report in simulation mode before using the formal environment.」

所以 signed=True 的設計邏輯是：法規預設「API 用戶 = 會下單」 → 模擬下單測試是強制前置條件 → signed=True 是「你已完成法規測試報告」的 flag → 完整啟用 API（包含帳務查詢）的前提是完成這條合規流程。

收斂

更精準的說法應該是：

「只查不下單」這個 use case 在台灣證券業 API 的合規制度上不是頭等公民。法規預設 API 用戶會交易，所以模擬下單測試是強制前置條件，signed=True 是這條合規流程的副產品。永豐的設計是合規架構帶來的 friction，不是工程師個別失誤；要改善這個 use case 的反饋對象應該是金管會證期局或永豐合規團隊，不是 Shioaji 工程師。

要讓論點完整，需要補什麼？

可以加兩段補充：

加上這兩段，作者的核心技術設計（只讀架構、git grep 擋禁字）的價值會被凸顯得更清楚 — 它是在一個對「只讀」use case 不友善的合規環境下做出來的漂亮應對，而不只是在罵永豐。

4. 案例與論點一致性

挑文章裡三個最具體的技術案例看 — 它們是支撐第 2 節骨幹的關鍵實作細節。

零股庫存 Unit.Share 漏算

支撐「查詢函式設計要回乾淨可用的資料」這條設計判斷。預設 unit 不對純零股部位回 0、混合部位漏算零股成本，是 Shioaji API 的真實行為。論證紮實。

作為「文件曝光不足造成的踩雷」案例，這個例子非常典型 — 行為是合理的（不同 unit 走不同資料路徑），但預設值與文件曝光對新手不友善。如果作者願意把這個雷回報給永豐 DX 團隊或寫成 issue，可能比抱怨更有用。

git grep 擋 place_order / activate_ca

支撐「機器擋字面字串」這條設計判斷。展示了 shift-left 防線的最廉價版本 — pre-commit + CI 就能擋住模型誠實寫出敏感字的情況。

要小心對抗式繞過（字串拼接、eval、反射）擋不到。可以對照 Python 生態的成熟做法 — 自訂 ruff lint rule、bandit security linter、AST visitor 都能擋到更多字串拼接型態。但對個人自架場景，git grep 已經夠用。

TOOLS.md + bash 取代 plugin

支撐「輕量 agent tool 設計」這條設計判斷。展示了一個「不需要 MCP 也能用」的路徑。

限制是只在「個人、單機、單目的」場景成立。多人共用 / 跨機器 / 需要結構化 schema 時會撞牆。可以對比作者也許沒走的另一條路 — 永豐官方 Claude Code plugin — 把兩條路的成本、彈性、可維護性做一次對比，讀者就能判斷自己該選哪邊。

5. 關鍵概念解讀

OpenClaw 龍蝦

作者自架的 agent 框架。它在這套設計裡扮演的角色：模型（LLM）與外部世界中間的 thin layer，負責「掛工具、解析 LLM 的請求、執行對應的 bash 工具、把結果丟回給模型」。

要注意：龍蝦本身不是市面上的標準框架（不是 LangChain、不是 OpenAI Agents SDK、不是 MCP），是作者自己設計、用 TOOLS.md 當設定檔的客製品。

Agent 的能力面（capability surface）

一個 agent 能做的事的集合。它由兩塊組成：(1) 開放給它的工具集 (2) 工具能呼叫的函式集。

capability-based security 的核心觀念是：agent 的安全邊界不是「我有沒有告訴它不要做 X」，是「X 是不是在它的能力面裡」。作者把這個觀念直接搬進來：能力面裡只有查詢函式 → 「下單」這個動作根本不在地圖上 → 不需要擔心模型會去做。

signed=True

Shioaji API 的一個 flag，登入後可以從帳戶資訊看到。它的意思：這個 API 帳戶已經完成永豐的「條款簽署 + 模擬模式測試報告」流程，可以使用正式環境的完整功能（包含帳務查詢）。

啟用方式：在模擬模式下成功完成一次登入測試 + 一次下單測試（不會真的成交），永豐後台會把帳戶標記成 signed=True，這個 flag 一旦設成 True 就永久有效。

它存在的原因：金管會「證券商受理投資人使用應用程式介面（API）服務作業規範」要求「投資人首次使用 API 委託下單前，應就相關傳輸設定進行連線測試，並留存相關測試紀錄」。signed=True 是這條合規要求的具體實作。

CA 憑證 / activate_ca

activate_ca 是 Shioaji 用來啟用 CA 憑證的函式。CA 憑證是一個 .pfx 檔（你的數位簽章），永豐要送一筆真實的下單請求必須先呼叫 activate_ca(path_to_pfx, ca_passwd, person_id) 載入這個憑證，才能執行 place_order。

它存在的原因：金管會規定 API 下單必須通過「網路下單帳號、網路登錄密碼及數位憑證（電子簽章）」這三層驗證，CA 憑證是其中的電子簽章層。

作者用「不下載 CA 憑證 + 不呼叫 activate_ca」當第二道防線，就是用「下單路徑根本接不通」當保險。

Capability-based security vs Prompt-based safety

兩種讓 agent 不做壞事的路線。

Capability-based：靠工具集邊界、執行環境沙箱、結構性的「沒這條路」。 Prompt-based：靠在 prompt 裡告訴模型「不要做 X」、訓練模型更乖。

兩者的差異：第一條的失敗模式是「我忘了把某條路擋住」（可被 audit 的設計缺陷）；第二條的失敗模式是「模型在某個輸入下決定無視規則」（無法窮舉的隨機事件）。作者的核心主張是前者更可靠 — 這跟當前 LLM 安全社群的共識一致。

Shift-left（左移檢查）

把規則檢查從「執行期 / 人工 review」推到「commit / merge 時自動 fail」的做法。作者用 git grep + pre-commit + CI 就是這條路。

越早擋住代價越低：執行期擋 > 部署期擋 > merge 擋 > pre-commit 擋。作者用了最早期的兩道（pre-commit + CI），是教科書做法。

6. 技術性主張 vs 價值判斷分列

技術性主張（可查證）

價值判斷（看立場）

為什麼這個區分對讀者重要

技術實作分享文最容易混的，是把「我觀察到的現象」、「我做的設計選擇」、「我對廠商的不滿」全部攪在一起。讀者讀完很容易把這三層的可信度當成同一級。

技術性主張可以查證（API 行為、金管會法規條文、官網文件存在性），這些不靠立場。價值判斷則是設計哲學與情緒結論 — 你可以同意「不下單要靠架構」但不必同意「永豐工程師設計失誤」。

特別是「永豐 API 設計很雷」這個情緒結論，在分清楚之後會看到 — 雷的不一定是永豐工程師，可能是金管會合規制度，也可能是 onboarding 文件的曝光不足；對應的修法路徑也完全不一樣。

7. Takeaway

8. 總結評語

這篇最站得住腳的部分，是核心的安全設計哲學 — 「agent 不做某件事」要靠能力面沒有這條路，而不是靠 prompt 裡叮嚀；再加上 git grep + CI 把機器擋作為第二道防線。這套設計不是個人偏好，是當前 LLM 安全社群（Anthropic、OpenAI、Google DeepMind）反覆強調的共識做法，作者把它落地成一個非常具體、可重現的小架構，這是最有教學價值的部分。

另外把資料層整理成「乾淨 dict / list、可直接 json 化」這個堅持也很對。它呼應了 agent tool design 的一條基本原則 — 工具的回傳應該是「下一個工具能直接吃」的格式，而不是「人類要再解析一次」的物件。

至於最需要修正的部分，集中在「永豐工程師歡迎跟我聊聊」這段對廠商的批評上。

把作者觀察到的現象（「只查也要全開權限」）與兩條補充資料對照之後，會看到事情比作者想的要結構一點 — 永豐其實有專門的 AI Coding Assistant 入口（含官方 Claude Code plugin、llms.txt、Getting Started Prompt），作者文章看起來是繞過這個入口、從 API 後台與一般 tutor 自己摸索；signed=True 與「先做模擬下單」是金管會 API 法規的合規副產品，不是永豐工程師個別設計失誤。

如果想更嚴謹，缺的是兩塊 — 一是承認「永豐其實已經為 AI agent 整合做了相當完整的官方支援」（即使你選擇自己包，也值得在文章裡點到），二是把「為什麼要全開權限」的根因收斂到「合規架構副作用」而不是「工程師設計失誤」。補上這兩塊，整篇文章從「自己包了一個還不錯的東西順便吐槽券商」升級為「在不友善的合規環境下做出漂亮應對」 — 後者的故事其實更精彩。

附註：與核心論證無直接關係的補述