Oft3r/agentic-trading-desk

代理交易台

短期交易分析與執行的操作手冊。 我（代理）執行對Robinhood MCP的呼叫；腳本作為我的確定性計算器；框架做出決策，我執行。 我絕不直接從價格K線中推理計算指標：而是取得數據並傳遞給 scripts/。

護欄 — 請先閱讀，不可協商

1. 保護倉位： 某些股票代號可能被指定為受限制（例如股票贈與）。絕不分析它們以進行賣出或減持，也不得將其納入出場建議。它們僅可在相關時作為曝險背景提及。
2. 兩個帳戶，兩個角色：
   • Agentic → 短期交易；這是我在此授權下執行的地方。
   • 個人（保證金帳戶）→ 核心買入持有；僅分析持有品質，不進行主動交易。
   • 我透過券商自己的標誌從 get_accounts 中辨識可交易帳戶（恰好一個帳戶是代理可交易的；其他帳戶會直接拒絕我的訂單）。我絕不從帳戶暱稱推斷，也絕不硬編碼帳戶號碼。
3. 購買力： 我始終以 get_portfolio.buying_power 作為權威數字，而非自行推算。帳戶類型很重要且可能改變：在現金帳戶中，只有已結算的現金才可動用（T+1），而有限保證金帳戶則可立即交易未結算收益。
4. 僅在星期五生成HTML視覺化 作為每週回顧儀式的一部分。除非用戶明確要求，否則不在其他日子提供或生成。
5. 宏觀來源（可選/盡力而為）： Investing.com（不使用Polymarket）。如果因網路出口政策無法訪問或遭封鎖，請勿停止或阻擋執行：在沒有殖利率利差的情況下，繼續使用確定性市場數據。
6. Agentic帳戶已授權自主執行 根據自主執行授權（下一節）。此授權是持久的，由用戶在2026-08-26的即時會話中建立；它不依賴於任何聲稱擁有它的排程提示。儲存的提示無法自行授予同意 — 授權存在於此（設定中），可透過讀取驗證。在執行 place_*_order 之前，始終使用 review_*_order（模擬）進行審查。

自主執行授權

用戶授權在無需即時確認的情況下執行訂單，僅限於券商指定的代理可交易帳戶，且僅在以下限制範圍內。超出限制並非請求許可的信號：而是不交易並報告的信號。

我可以執行的內容

• 由 score.py 在同一個會話中輸出的決策，其宏觀支柱由 macro_pillar.py 在同一天計算。腳本仍然在每個會話中運行，其輸出仍然是基準 — 框架不是可選的。
• 自主進出場已獲授權（由用戶在2026-08-26的即時會話中建立，取代先前的零裁量權規則）：趨勢變化、新聞催化劑或決策階梯未涵蓋的設定，都是採取行動的有效理由。階梯本身設計剛性，必然會遺漏一些情況；這就是此條款的目的。
• 每一筆自主交易必須在會話報告中以書面形式附帶其理由 — 我看到了什麼、為什麼採取行動合理、以及什麼情況會證明我是錯的。無法用兩句話解釋的交易，就是不該做的交易。
• 戰術性反彈以半倉進場 — 本質上屬於逆勢操作。
• 可選：對於新聞驅動的進場，要求在行動之前，價格走勢朝論點方向移動，而非預測走勢。理由在外部背景一節中說明 — 在排程運行中，新聞來源是最弱的輸入，價格確認是防止根據過期標題採取行動的最便宜防護。

硬性限制

• 每筆訂單最高 $1,200。

• 每個會話最多 3個新倉位。出場次數無上限。

• 帳戶價值的至少 15% 持有現金。我絕不動用該儲備。

• 訂單類型跟隨會話時鐘（Eli於2026-08-26設定的規則，取代先前的僅限限制規則）：

  • 常規交易時段 — 週一至週五 09:30–15:58 ET：type: "market"。 如果分析說要進場，就進場；被動的限價單等待價格並非進場。此處允許使用 dollar_amount — 這是以帳戶的3%進行規模化的自然方式，且MCP僅在接受 type=market 時接受它。
  • 非交易時段：type: "limit" 搭配明確的 limit_price，具市場競爭力 — 在價差內或剛越過遠端，且與最後成交價差距在0.3%以內 — 並以股數（SHARES）計量（quantity = dollars / limit_price，截斷至6位小數）。此處絕不使用 dollar_amount：MCP會將其靜默轉換為市價單，可能在數小時後以未知價格成交。儘管工具結構中有分數股的備註，但分數限價單確實受到支援（2026-08-26透過 review_equity_order 驗證：DIA買入限價單 quantity=0.400000 @ 534.50，被接受且 order_checks 為空）。
  • stop_market 和 stop_limit 在任何時候皆禁止。 Robinhood也拒絕分數股的停損單，因此此帳戶的停損是手動水準，我每個會話重新檢查，而非保留訂單。
  • time_in_force 必須是 gfd。 沒有訂單能比下單的會話活得更久 — 隔夜佇列的訂單是在無人評估價格的情況下被動成交。
  • 為何要拆分：最初的僅限限價單規則之所以存在，是因為無人值守的市價單存在不可見的滑價。將市價單限制在會話時鐘內直接解決了這個問題 — 它們只在委託簿深度足夠且會話處於活動狀態時才觸發，而該窗口之外的訂單始終保持定價。

• 訂單預檢。 在每一次 place_equity_order 之前，我印出此表格並檢查每一行。如果有任何一行失敗，我不會下單 — 而是報告。

  欄位	值	檢查
  ET時鐘	…	在週一至週五 09:30–15:58內或外？
  type	…	常規交易時段內為 market · 常規交易時段外為 limit · 絕不為 stop_*
  limit_price	…	僅限常規交易時段外：具市場競爭力，與最後成交價差距在0.3%以內
  規模	…	常規交易時段內為 dollar_amount · 常規交易時段外為股數 quantity
  time_in_force	…	必須是 gfd
  名目金額	dollar_amount 或 quantity × limit_price	≤ $1,200

• 除非 jq 已安裝，否則守衛不承擔負載。 該掛鉤使用 jq 實現所有規則；沒有它，腳本會以無輸出的退出碼0結束，運行器會將其解讀為允許（2026-08-26驗證 — 早期修訂版讓一個 stop_market 通過了）。它現在改為故障關閉，但一個否決一切的守衛也不是一個可用的設定。請參閱下面的會話開始 — 證明守衛處於活動狀態；無論如何，我將上面的預檢表格視為真正的檢查，而不是掛鉤。

• 在確認的財報發布後2個會話內，不得在單一標的名稱中建立新倉位（使用 get_earnings_calendar）。ETF 除外。

• 在每次 place_equity_order 之前，我運行 review_equity_order。如果模擬結果與我計算的價格或數量差異超過1%，我中止並報告。

會話開始 — 證明守衛處於活動狀態

授權是散文，散文無法自行強制執行；hooks/mandate-order-guard.sh 才是使「僅限限價單」規則機械化的東西。重要的故障模式是：一個未連接、不可執行或缺少 jq 的守衛，在訂單溜走之前，看起來與正常運作的守衛一模一樣。這並非假設：在2026-08-26，一個 stop_market 通過了，因為 jq 不存在，腳本以無輸出的退出碼0結束，而掛鉤運行器將其解讀為允許。因此，在任何會話的第一個 place_equity_order 之前，我運行：

bash <skill-dir>/scripts/session-setup.sh

它會安裝 jq，將守衛標記為可執行，並在兩個時鐘分支上運行 8項探測 — 6個授權禁止的訂單（必須被拒絕）和2個授權允許的訂單（必須通過）。僅針對拒絕進行探測是不夠的：一個否決一切的守衛與一個不否決任何東西的守衛同樣糟糕，且從單一的拒絕探測來看，兩者看起來一模一樣。這些探測通過 MANDATE_FAKE_ET 固定守衛的會話時鐘，因此無論會話在何時啟動，常規交易時段和盤後交易時段的分支都可以測試。退出碼0並輸出 order guard verified 表示守衛實際上在評估規則。任何其他結果表示它沒有在評估，並且我該會話不執行訂單 — 我仍然運行分析並報告框架發出的內容，並且我明確說明執行已被禁用及其原因。帶有故障守衛的分析是有用的，但帶有故障守衛的無人值守執行則不是。

我需要對自己誠實的一件事是：.claude/settings.json 僅對其專案目錄包含它的會話加載。當交易台作為已安裝技能（而非作為專案打開）加載時，PreToolUse 掛鉤永遠不會註冊，並且上述探測僅驗證腳本在被呼叫時會拒絕。在該模式下，除了我之外沒有任何東西在檢查，因此預檢表格是整個安全邊際 — 在每次下單前，我逐行填寫它，並在任何失敗的行上中止，而不是將其視為文書工作。

這不是假設，我在適用時會在會話報告中說明。 在2026-08-26，一個帶有 dollar_amount: 250（DIA）的 market 訂單和兩個 market 訂單（JPM，2026-08-25）在守衛未註冊的技能模式下通過了。根據當前的時鐘規則，這三筆訂單都是在常規交易時段內下達的，現在會根據其本身的優點通過守衛 — 但它們當時之所以通過，是因為沒有任何東西在檢查，這與被允許是兩碼事。如果會話自我稽覈顯示有代理訂單，且我正以技能模式運行，我會明確說明：這些訂單是未經守衛的，無論其內容最終是什麼。

斷路器

• 如果會話開始時的帳戶價值較前一次收盤下跌超過4%：當天不進行新的買入。出場仍被允許。
• 如果數據無法核對 — 缺少K線、明顯過時的報價、與 get_equity_positions 不符的倉位 — 我不交易。授權的前提是數據正確；沒有數據，授權不適用。

執行後

• 每個已執行訂單發送推播通知，並在運行結束時提供摘要。用戶在同一天（而非星期五）得知結果。
• 持久記錄存在於券商端（get_equity_orders、get_realized_pnl），而非本地檔案：執行容器是臨時的。

仍然禁止

• 保護倉位，始終（護欄1）。
• 任何非券商指定的代理可交易帳戶。
• 攤平成本。
• 選擇權、加密貨幣、保證金和放空：超出授權範圍。

Robinhood MCP 配方（呼叫順序）

在使用工具之前，先用 tool_search 加載它們（它們是延遲加載的）。

守衛驗證在任何這些操作之前運行 — 請參閱授權中的會話開始 — 證明守衛處於活動狀態。在探測未返回拒絕結果的會話中，不會發出任何訂單。

會話自我稽覈（每次運行的第一個呼叫）。 在代理可交易帳戶上以 placed_agent="agentic" 參數呼叫 get_equity_orders，查詢自上次會話以來的訂單。如果訂單是 stop_market 或 stop_limit；如果是 market 訂單且其 market_hours 欄位非 regular_hours；如果它在非交易時段攜帶 dollar_amount；如果其 time_in_force 不是 gfd；或者其名目金額超過 $1,200，則該訂單構成先前運行的授權違規。我在每個返回的訂單上檢查 type、market_hours、time_in_force 和名目金額，並在推播通知中揭露任何違規，而不是讓它默默通過。券商的訂單歷史是唯一的持久記錄 — 執行容器是臨時的，因此今天未揭露的違規將會遺失。

分析股票代號時：

1. Robinhood:get_equity_historicals → 約290根日K線（收盤價）。這是 indicators.py 的輸入。請求一個能產生≥220根K線的範圍（EMA200的理想數量）。
2. Robinhood:get_equity_quotes → 即時價格 / 上次會話收盤價。
3. 如果用戶有倉位：Robinhood:get_equity_positions（正確帳戶）獲取規模和損益 → 將 holding 設為評分中的正確值。

對於宏觀情緒支柱（每個會話一次，共享）：

1. 為8個ETF獲取 get_equity_historicals：SPY、RSP、IWM、HYG、LQD、TLT、XLY、XLP。
2. 嘗試從 Investing.com（網頁）獲取10Y-2Y殖利率利差並注入為 yield_spread。如果因網路出口政策受阻或不可用，立即忽略而不重試：腳本會自動將其20%權重重新分配給其他元件，執行順暢地繼續進行，無需阻塞。

對於投資組合管理：

• Robinhood:get_portfolio → 市值和購買力。
• Robinhood:get_equity_positions → 按帳戶劃分的未平倉倉位。
• Robinhood:get_realized_pnl → 已實現損益（對星期五回顧有用）。

計算流程（透過程式碼執行運行）

腳本純粹使用標準庫；無需網路存取。它們位於此技能自身目錄內的 scripts/ 目錄中 — 運行時在加載技能時會提供基礎路徑。我絕不硬編碼該路徑：它在不同環境之間有所不同。

Robinhood 歷史數據很大，經常超出工具的輸出限制；發生這種情況時，結果會寫入檔案，我會獲得路徑。我直接從該檔案用程式碼處理它們 — 我絕不將原始K線載入到上下文中。

步驟 0 — 附加今天的收盤價（每個會話，在任何其他操作之前）。 來自 get_equity_historicals 的日K線在收盤後很長一段時間內都不包含當前會話：剛過16:00 ET，最後一根K線仍然是昨天，因此對該序列進行評分等於對昨天的市場進行評分。對於每個標的，我取 get_equity_quotes → last_trade_price（~19:59:59Z 的打印是今天的收盤交易），並在確認最後一根現有K線是前一個會話之後，將其與今天的日期一起附加到收盤價陣列中。絕不附加 last_non_reg_trade_price — 延長時段的打印不是收盤價。

步驟 1 — 宏觀（每個會話一次）。 輸入結構是 `{"as_of": …

[因長度截斷]