LangAlpha：把「vibe investing」做成持久化工作區的代理框架
Claude Code for Financial Market
秒懂
- 它是什麼？
- LangAlpha 以 Python 3.13 撰寫，Apache-2.0 授權，把程式碼代理的持久工作區模式搬到投資研究上。它的核心主張是研究應該像程式碼庫一樣累積，但這個主張能否成立，取決於你願不願意被綁進它那套相當完整的服務端基礎設施。
- 適合誰用？
- 適合已經有明確研究流程、願意自架 FastAPI、PostgreSQL 與 Redis 的團隊或個人，尤其是需要把多年財報、圖表與多輪假設更新累積在同一份工作區的人。不適合只想問一句話拿一個答案的輕度使用者，也不適合無法接受把 BYOK 金鑰與憑證交給自架服務管理的人。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
LangAlpha 想修的是「一次性問答」這個壞習慣
README 開頭把問題講得很直白：現有的 AI 金融工具都把投資當成單次問答，問完就結束。但真實的投資流程是貝氏式的，你先有一個論點，每天有新資料進來，再據此調整信心程度，這個過程會延續數週甚至數月。單一提示詞裝不下這種節奏。
它借用的解法來自軟體工程。程式碼庫會一直存在，每個 commit 都建立在先前的基礎上。Claude Code、OpenCode 這類程式碼代理之所以可行，是因為代理會探索既有脈絡再往上疊。LangAlpha 把同一套想法搬到研究場景：給代理一個持久工作區，研究就會自然複利。
實際用法是每個研究目標開一個工作區，README 舉的例子包括「Q2 rebalance」、「data center demand deep dive」、「energy sector rotation」。代理會先訪談你的目標與風格，產出第一份交付物，把所有東西寫進工作區檔案系統。明天再回來，檔案、thread 與累積的研究成果都還在。
目標讀者輪廓不難推斷：做賣方或買方基本面研究、需要反覆更新模型與論點的人；以及已經在用 LLM 但受不了每次都要重新貼脈絡的人。如果你只是想知道某檔股票今天為什麼漲，這個專案對你來說太重。
架構：FastAPI 加雙連線池，狀態全部落在 PostgreSQL
README 的架構圖把元件切得很清楚。前端是 React 19、Vite、Tailwind 組成的 Web UI，透過 REST 與 SSE 連到 API，另有一條 WebSocket 走 WebSocket Proxy。CLI 與 TUI 也走同一組 REST 與 SSE 介面。
後端是 FastAPI，API Routers 涵蓋 Threads、Workspaces、Market Data、OAuth、Automations、Skills。Chat Handler 負責 LLM 解析與 workflow 分派，再交給 Background Task Manager 執行，讓背景任務與 HTTP 連線解耦。這代表代理跑很久也不會因為瀏覽器關掉就中斷。
PostgreSQL 用了雙連線池：App Data 池放使用者、工作區、thread、turn、BYOK 金鑰與 automations；另一個獨立池給 LangGraph Checkpointer，存代理狀態與 checkpoint。這個切分有實際意義，checkpoint 的寫入頻率與交易資料的讀取模式差很多，混在同一個池裡容易互相排擠。
Redis 負責三件事：SSE 事件緩衝（README 標示 150K events，支援重連回放）、市場資料的 API 快取（SWR），以及 steering 相關狀態。SSE 事件緩衝這個設計值得注意，它讓使用者重新連線時不必從頭重跑代理，直接回放緩衝區裡的事件即可。對動輒跑數十分鐘的深度分析來說，這是能不能用的差別。
PTC 與漸進式工具發現：真正省下的是 context window
這個專案最值得看的兩個機制是 Programmatic Tool Calling 與 Progressive Tool Discovery。
PTC 的做法是讓代理自己寫 Python 去處理來自 MCP server 的金融資料，而不是把原始資料整批倒進 LLM 的 context window。README 的說法是這樣能支援複雜的多步分析，同時大幅減少 token 浪費。這個方向合理：財報時間序列、逐日價量這種資料，塞進 context 既不經濟也不精確，交給程式碼算完再回傳摘要，誤差與成本都低得多。代價是代理必須寫出正確的 Python，而它寫的程式碼會在 sandbox 裡執行。
Progressive Tool Discovery 處理的是另一個方向的問題。任何 MCP 工具在 context 裡只以摘要形式存在，完整文件被丟進工作區，代理需要時再去讀。它也支援把 JSON 工具綁在 skill 上，只有 skill 被啟用時才暴露給代理。當你接上十幾個 MCP server，工具定義本身就會吃掉大量 context，這個設計是必要的。反過來說，代理得先知道某個工具存在才會去查文件，工具摘要的品質就直接決定了它會不會漏用某個能力。
多層供應商階層則區分用途：原生工具有快速查詢，MCP server 負責大量資料處理、繪圖與跨年度分析，後者跑在 sandbox 裡。這個分層是效能考量，不是功能考量。
工作區、記憶與 memo 是三種不同生命週期的儲存
LangAlpha 的持久化不是單一機制，而是三層，混用會出問題。
第一層是工作區本身，對應一個專屬 sandbox，內有結構化目錄與一份 agent.md 筆記檔。這份筆記是研究複利的載體，跨 session、跨 thread 累積。第二層是長期記憶，路徑為 .agents/user/memory/ 與 .agents/workspace/memory/，前者存跨 sandbox 的使用者偏好，後者存工作區層級的知识。第三層是使用者自己管理的 memo，路徑 .agents/user/memo/，讓你上傳 PDF 與 markdown 研究筆記，代理按需讀取。
這三層的差別在於誰決定寫入。agent.md 由代理維護，memory 由系統判斷什麼值得長期保留，memo 完全由你控制。實務上最容易被忽略的是第二層：跨 sandbox 的使用者偏好一旦寫進去，之後每個新工作區都會繼承，如果偏好被記錯，錯誤會擴散到你所有的研究。
Skills 則是一組預建工作流程，涵蓋 DCF 模型、initiating coverage 報告、財報分析、morning notes、文件生成等，可以斜線指令啟動，也可以自動偵測觸發。自動偵測聽起來方便，但也意味著你得先弄清楚它什麼時候會自己跳出來。
啟動路徑與你必須先準備的東西
專案要求 Python 3.13 以上。倉庫結構把元件分得很開：代理核心在 src/ptc_agent/，後端在 src/server/，Web 前端在 web/，TUI 在 libs/ptc-cli/，外掛在 plugins/，API 文件在 docs/api/README.md。
README 把 Getting Started 連到倉庫的 anchor，但提供的內容裡沒有逐條列出安裝指令。這是這篇評測必須說清楚的邊界：我沒有實際安裝或執行過這個專案，下列項目是從架構與說明推導出的前置條件，不是實測步驟。
你至少需要 PostgreSQL，而且因為 README 提到以 pgcrypto 做靜態加密，資料庫必須支援這個擴充。你需要 Redis，用於 SSE 事件緩衝與市場資料快取。你需要一組 LLM 供應商憑證，多供應商模型層支援自動 failover。若要用 MCP 工具與金融資料供應商，還得另外準備對應的 API key。
設定面的關鍵名稱可以直接從 README 取得：工作區層級的密鑰存在 per-workspace secret storage，長期記憶在 .agents/user/memory/ 與 .agents/workspace/memory/，使用者上傳的研究筆記放 .agents/user/memo/。Automations 支援排程與價格觸發，後者在股票或指數達到即時價格條件時觸發。Channel integrations 涵蓋 Slack、Discord、Feishu、Telegram，排程結果也能用 email 寄送。
值得注意的是桌面版有兩個發行線：desktop-v0.2.3 與 desktop-oss-v0.2.3（標示 self-hosted）。如果你打算自架，要認明的是後者。
限制：這是一套服務，不是一個套件
最明顯的門檻是部署形態。LangAlpha 不是 pip install 之後就能跑的東西，它需要 PostgreSQL 雙連線池、Redis、FastAPI 後端，還要處理 OAuth 與各通訊頻道的整合。對一個只想在筆電上做幾次分析的個人使用者，這個重量不成比例。
第二個限制是資料相依。專案本身不生產金融資料，它靠多層供應商階層與 MCP server 取得。你的資料品質、延遲與授權範圍決定了整個系統能回答什麼問題。README 提到即時 WebSocket 市場資料與價格觸發的 automations，但這些能力的前提是你接上了對應的資料源。
第三個是安全模型的張力。專案提供 pgcrypto 靜態加密、憑證洩漏偵測與遮蔽、sandbox 執行、per-workspace 密鑰儲存，這些都是為了讓代理能安全地碰觸敏感憑證。但 PTC 的本質就是讓 LLM 生成並執行 Python。遮蔽機制能不能跟上模型生成的程式碼，是採用前最該自己驗證的事，而不是看功能列表就放心。
第四，代理 swarm 具備平行非同步子代理、隔離 context window、預載工具集與 skill、執行中轉向、checkpoint 續跑。這些機制讓長任務可行，也讓失敗模式變得難懂。當五個子代理各自跑在不同 context 裡，出錯時你要追的是哪一層，README 沒有交代。
最後是維護成本。發行節奏相當密集，v2026.09.07 與兩個 desktop 版本都在 2026 年 9 月 7 日發布，主線最後推送時間是 2026 年 9 月 8 日。這種節奏對早期採用者是好事，對已經把工作區養了幾個月的人則是升級風險：LangGraph checkpointer 的狀態格式、工作區目錄結構、記憶檔案的佈局，任何一項變動都可能讓既有研究工作區需要遷移。
替代方案：OpenCode 與 Claude Code 的差別在哪
LangAlpha 自己承認靈感來自 Claude Code 與 OpenCode。拿它們對比最能看出差異。
Claude Code 與 OpenCode 的持久物件是程式碼庫，代理的動作有編譯器與測試可以驗證，錯了他會知道。LangAlpha 的持久物件是研究工作區，代理的產出是 DCF 模型、覆蓋報告、交易配對想法，這些沒有編譯器。對錯要靠人判斷，或靠後續市場走勢驗證。這是根本差異，也解釋了為什麼 LangAlpha 要花力氣做 per-turn source-provenance panel 與來源標註，它必須用可追溯性替代可驗證性。
另一類替代是直接用 LangChain 或 LangGraph 自己組。LangAlpha 的價值在於它已經把難做的部分做完了：SSE 事件緩衝與重連回放、背景任務與 HTTP 解耦、雙連線池的 checkpoint 隔離、MCP 工具的漸進式發現、skill 綁定 JSON 工具。自己組這些要花掉數週，而且很容易在 context 管理上踩坑。代價是你得接受它的目錄慣例、它的記憶分層、它的升級節奏。
如果你只需要財務數據查詢與圖表，不需要代理反覆更新論點，那用一個 MCP server 加現成聊天介面就夠了，LangAlpha 的持久工作區對你是多餘的。
授權與採用判斷
Apache-2.0 是寬鬆授權，允許商業使用、修改與再散布，並附帶專利授權條款。需要留意的是它要求保留版權與授權聲明，修改過的檔案要標示變更。這不是法律建議，實際條文請自行閱讀 LICENSE 全文。
對企業採用者還有一層：LangAlpha 會把使用者的密鑰存在 per-workspace secret storage，並以 pgcrypto 加密。這代表你的 BYOK 金鑰與資料供應商憑證會進入你自架的 PostgreSQL。合規上這通常比送到第三方 SaaS 好處理，但前提是資料庫本身的存取控制與備份策略要到位。
升級成本要提前想。工作區目錄（.agents/user/memory/、.agents/workspace/memory/、.agents/user/memo/）與 LangGraph checkpoint 都是狀態，跨版本升級時這些狀態的相容性沒有在提供的資料裡說明。在把重要研究放進去之前，先確認遷移路徑是否存在。
編輯結論
適合已經有明確研究流程、願意自架 FastAPI、PostgreSQL 與 Redis 的團隊或個人，尤其是需要把多年財報、圖表與多輪假設更新累積在同一份工作區的人。不適合只想問一句話拿一個答案的輕度使用者，也不適合無法接受把 BYOK 金鑰與憑證交給自架服務管理的人。動手前先確認三件事：PostgreSQL 的 pgcrypto 擴充是否可用、你的資料供應商憑證要放在哪一層、以及 .agents/workspace/memory/ 的寫入策略是否符合你的合規要求。
社群筆記