此文章現在已發布於 AWS 官方 Builder Center。你可以前往官方文章，或關閉此視窗並留在此頁繼續閱讀。
機構級 AMZN 投資組合研究需要進出場時機治理、最大回撤 (Drawdown) 歸因、基準指數 (Benchmark) 脈絡、因子 (Factor) 紀律、執行分類帳 (Ledger) 以及雲端可審計性。使用 Amazon Bedrock AgentCore、Strands Agents、AWS 資料控管、自訂 Cerebro 風格模擬、夏普 (Sharpe) 分析、交易歷史與金融服務業 (FSI) 風險語言，建立純做多 (Long-only) 回測工廠，用於負責任的部位管理審閱與監督。
教育用途： 本文內容僅聚焦於合法的財務規劃教育，旨在提升對概念、方法論與分析方法的理解，不推廣任何特定證券、策略或市場參與決策。
非個人化建議： 本文不提供個人化推薦、招攬或保證，也不在任何情況下，於本教育材料中明示、暗示或以其他方式表示任何未來績效、結果或報酬保證。
資料限制： 由於沙盒 (Sandbox) 環境中無法使用即時資料，上傳的結果仰賴確定性離線資料 (Deterministic Offline Data)，因此輸出應解讀為示範範例，而非即時分析。
純做多 (Long-Only) 範圍： 所有研究語言皆僅限純做多，不包含選擇權 (Options)、賣權 (Puts)、放空 (Short Selling) 或看空策略 (Bearish Strategies)，以確保討論整體聚焦於傳統資產持有與正向方向性曝險概念。
500% 的未實現獲利可能讓研究簡報顯得很有說服力，但機構首先需要知道是誰提出這次執行、使用哪個工具執行、資料從何而來、哪些規則已被核准，以及保存了哪些證據。作為自訂引擎系列的第一篇文章，本文會先建立該營運模型，再討論策略排名。
本系列文章並不建議買進、賣出或持有 Amazon。文章旨在展示受治理的研究工作流程 (Workflow) 如何將部位管理問題轉化為受控的證據。
此部分的交易員語氣代表著一位營運模型的發起人 (Sponsor)：擁有足夠經驗且尊重市場，但主要聚焦於流程設計。本文探討 AgentCore、Strands Agents、自訂 Cerebro 風格引擎 (Engine) 以及 AWS 產出物控制 (Artifact Controls) 如何協助團隊審閱 AMZN 的進出場時機 (Timing)，而非將判斷權完全交給自動化程式。
Part 1 的客戶問題在於營運所有權 (Ownership) 分散。投資組合經理 (Portfolio Managers)、風險審查員 (Risk Reviewers)、工程師與合規利害關係人 (Compliance Stakeholders) 經常檢視同一個研究故事的不同版本。此營運模型為他們提供了一條從請求 (Request) 到政策檢查 (Policy Check)、模擬 (Simulation)、分類帳 (Ledger)、圖表 (Chart)、摘要 (Summary) 與委員會審查 (Committee Review) 的單一路徑。
此工作流程支援更清晰的所有權邊界、可重複使用的代理角色 (Agent Roles)、一致的產出物生成，以及從技術結果走向治理討論的更強路徑。其價值並不在於排名第一的策略成為最終答案，而是在於每個被排名的策略都能透過同一份證據包裹 (Evidence Package) 進行檢視。
相關摘要： 建立機構交易語氣、AMZN 部位脈絡與溝通紀律。本文定位為教育與規劃支援，而非投資建議、推薦、招攬或對未來報酬的承諾。
開場不應在說明控制問題之前就盲目慶祝部位。強勁的 AMZN 獲利可能帶來信心，但信心不能取代進場紀律、出場紀律、部位規模化邏輯 (Sizing Logic)、最大回撤容忍度 (Drawdown Tolerance) 以及相對於基準指數的審閱。
有用的實務筆記 (Practice-Note) 訊息在此被融入到表達紀律中：使用證據語言、說明資料模式、指出假設，並避免承諾確定性。文章讀起來應像機構研究，而不是促銷文宣 (Pitch)。
相關摘要： 定義為何即使是有獲利的做多部位 (Long Positions)，仍需要以證據為基礎的進場、出場、部位規模、最大回撤與基準指數控制。它將投資組合管理、風險監督、技術治理與審計需求 (Audit Requirements) 連接成一個可審閱的工作流程。
業務問題在於證據的分散。投資組合團隊需要速度，風險團隊需要可追溯性 (Traceability)，技術團隊需要安全的編排，合規團隊則需要適當的語言。此工作流程透過建立可重複的研究路徑來對齊 these 需求。
部位紀律代表每個策略都應回答相同的問題：為何進場、為何出場、曝險多少、成本假設是什麼、最大回撤路徑 (Drawdown Path) 為何，以及基準指數背景是什麼。這些問題現在是主文內容的一部分，而不是結尾的附註。
相關摘要： 透過分離編排器 (Orchestrator)、資料代理 (Data Agent)、策略代理 (Strategy Agent)、回測工具 (Backtest Tool)、風險審查員 (Risk Reviewer) 與治理檢查員 (Governance Checker) 來說明代理型架構 (Agentic Architecture)。每個組件 (Component) 都具備受限權限、受控工具與日誌輸出，以便進行金融服務審閱。
架構從清晰的角色分工開始。量化編排器負責請求拆解，市場資料代理負責資料狀態，策略代理負責信號定義，回測引擎工具負責模擬機制，風險審查代理負責指標解讀，治理代理則負責政策與資訊揭露檢查。
代理治理 (Agent Governance) 代表受限權限。代理可以準備證據，但不能決定適合度 (Suitability)、保證報酬率 (Returns)，或取代投資委員會 (Investment Committee)。日誌與產出物讓工作流程具有可被挑戰性。
相關摘要： 說明本文專屬的引擎路徑、程式碼解析、策略邏輯與審查控制。此章節將實作細節 (Implementation Details) 轉化為可被風險、技術與治理利害關係人挑戰的交易員語言。
程式碼路徑應被解釋為控制地圖。輸入產生指標，指標產生進場與出場信號，引擎模擬訂單、套用成本、寫入分類帳，並由度量指標 (Metrics) 摘要該路徑。這個順序用業務可讀的邏輯取代了逐行唸誦程式碼。
信號邏輯與執行邏輯應保持分離。信號可能表示條件有利，但引擎仍必須檢查現金、部位狀態、手續費、風險出場與分類帳更新。這種分離能大幅提升審閱品質。
本文聚焦於營運模型、代理角色、資料控管與排名最高的趨勢策略 (Trend Strategies)。讀者應評估程式碼路徑是否讓這些控制足夠可見，使委員會、風險審查員或技術負責人 (Technology Owner) 能夠提出挑戰。
相關摘要： 透過報酬率、波動度、夏普值、最大回撤、交易次數、勝率、分類帳品質與營運可行性，審閱策略紀錄與所學到的教訓。此章節將示範結果視為工作流程證據，而非真實的市場建議。
策略紀錄不應被解讀為投資推薦。它們是用於比較規則行為、交易頻率、回撤輪廓與可解釋性的證據。當資料模式是確定性離線示範資料時，這些數字尤其受到限制。
學到的教訓應該具體。高報酬策略可能有令人難以接受的最大回撤。低周轉率策略可能更容易治理。高交易次數策略則可能造成決策疲勞、滑點曝險與營運負擔。
相關摘要： 將程式碼、圖表與分類帳轉化為委員會語言：測試了什麼、改善了什麼、失敗了什麼、仍有哪些不確定性，以及為何在任何正式上線 (Production) 或資金配置決策之前，人類判斷仍是最終控制。
結語應將研究轉化為治理語言。委員會需要知道測試了什麼、產生了哪些證據、哪些假設至關重要、什麼地方失敗了，以及哪些部分仍屬於人類決策。
負責任的結語會避免歌功頌德式的語言。它會指出代理可以協助記錄假設、執行可重複的測試、比較行為並準備更好的審閱，同時人類判斷仍是最終控制。
相關摘要： 將整合後的主文細節與治理視角分組，讓讀者可一併審閱政策、產出物、示範資料限制與問責制。
營運模型從分離研究支援與投資組合權限開始。代理可以驗證範圍、呼叫回測工具並準備證據，但不應決定 AMZN 是否屬於讀者的投資組合。
每次執行 (Run) 都應留下可被挑戰的產出物：請求載荷、政策結果、參數紀錄、資料模式、交易分類帳、圖表輸出、指標摘要與異常筆記。
只有在人類審閱保持可見時，此工作流程才有用。委員會應收到證據包裹，並決定該研究是否足以進行進一步分析、修訂或拒絕。
AWS 控制層應分離原始資料、精選資料表、執行輸出、圖表產出物與審批紀錄，讓技術團隊可以支援資料保留、權限與重新執行。
研究敘事應先識別資料模式、規則邏輯、假設、成本、最大回撤與分類帳可用性。意見應該出現在證據之後，而非之前。
當結果來自離線確定性示範資料時，文章應在主體中明確說明。示範紀錄對工作流程教育與審查設計很有用，但不適合用來做真實的資金配置決策。
交易分類帳是交易桌的記憶系統。它顯示部位何時開啟、何時關閉、使用多大的部位規模、哪個信號被觸發，以及流程是否遵守風險規則。
專業讀者應在結論之前看到失敗模式。趨勢規則可能會被雙巴（反覆洗盤，Whipsaw），恢復規則可能會錯過持續的弱勢，而活躍信號產生的周轉率在 Notebook 中看起來可能比在實際交易桌上更乾淨。
代理工具可以收集、執行、摘要與組織，但投資組合所有者 (Portfolio Owner) 仍應對授權符合度、適合度、風險承受度與最終判斷負責。
相關摘要： 將營運模型、Strands 入口點與自訂引擎程式碼拆分到一個聚焦的實作章節。
本文是四篇系列文章的第 1 篇，聚焦於營運模型、代理角色、資料控管，以及排名最高的趨勢策略。它使用 Bedrock AgentCore 與 Strands Agents 作為代理型營運模型，使用上傳的自訂 Cerebro 風格引擎作為程式碼基礎，並以策略摘要紀錄作為績效審閱證據。討論內容屬於教育用途，而非投資推薦。
正式上線設計 (Production Design) 分離了五項責任。量化編排器接收研究請求，並將其拆解為資料、策略、執行、風險與治理任務。市場資料代理擷取或驗證 AMZN 與基準指數資料。策略代理產生進場與出場信號。回測引擎工具執行自訂的 Cerebro 風格模擬。風險審查代理讀取交易分類帳、績效指標與圖表。治理代理則檢查資訊揭露、純做多政策、資料來源 (Data Provenance) 與適合度語言。
AgentCore Runtime 是代理與工具的安全託管層，而 Strands Agents 提供工具呼叫、編排與代理行為的程式設計模型。在受監管的金融服務業環境中，代理不應直接核准交易。它應該建立證據、凸顯不確定性，並將輸出引導至人工審查。
這篇基礎文章的實務 AWS 資料層會分離原始輸入、精選的 OHLCV (開高低收量) 資料表、策略程式碼、結果摘要、圖表資料夾與審批紀錄。重點在於生命週期控制 (Lifecycle Control)：後續的每篇文章都能重用相同的儲存模式，同時聚焦於不同的策略審查問題。
Strands 層不應該是黑盒子。代理接收研究請求、驗證政策、呼叫回測工具並回傳結構化結果。工具應寫入不可變的產出物：參數檔案、資料快照識別碼、交易分類帳、圖表路徑與摘要指標。治理檢查會在執行前後發生。
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from strands import Agent, tool
app = BedrockAgentCoreApp()
@tool
def validate_research_policy(symbol: str, side: str, derivatives: bool) -> dict:
if symbol != "AMZN":
return {"ok": False, "reason": "此工作流程範圍僅限於 AMZN 研究。"}
if side != "long_only":
return {"ok": False, "reason": "僅核准純做多研究。"}
if derivatives:
return {"ok": False, "reason": "衍生性商品超出政策範圍。"}
return {"ok": True, "reason": "政策已接受。"}
@tool
def run_custom_cerebro_strategy(strategy_name: str) -> dict:
return {
"strategy": strategy_name,
"status": "已提交",
"artifact_prefix": f"s3://amzn-research/backtests/{strategy_name}/"
}
quant_agent = Agent(tools=[validate_research_policy, run_custom_cerebro_strategy])
@app.entrypoint
def invoke(payload):
request = payload.get("request", "執行 AMZN 純做多時機研究")
return quant_agent(request)
這段程式碼刻意保持保守。驗證工具會在回測工具執行前阻擋不支援的範圍 (Scope)。回測工具回傳產出物位置，而不是情緒化語言。代理可以進行摘要，但人類委員會仍對決策負責。
自訂引擎刻意保持小巧且清晰。建構子 (Constructor) 儲存價格序列、初始資金、配置百分比、手續費、停損百分比與停利百分比。這些參數形成了風險代理與治理代理可在策略執行前檢視的控制介面。
run 方法接收兩個布林值時間序列：entry 與 exit。策略代理會從指標建立這些序列。引擎負責執行紀律。它將信號對齊價格索引，把缺漏的信號值填為 False，然後在不窺探未來的情況下沿著時間軸向前推進。
class CustomCerebroEngine:
def __init__(self, price, initial_cash=100000, allocation=0.95,
commission=0.0005, stop_loss=0.12, take_profit=0.35):
self.price = price.astype(float)
self.initial_cash = initial_cash
self.allocation = allocation
self.commission = commission
self.stop_loss = stop_loss
self.take_profit = take_profit
def run(self, entry, exit):
entry = entry.reindex(self.price.index).fillna(False)
exit = exit.reindex(self.price.index).fillna(False)
cash, shares, entry_price = self.initial_cash, 0, None
trades, equity, position = [], [], []
for dt, px in self.price.items():
if shares > 0:
stop_hit = px <= entry_price * (1 - self.stop_loss)
target_hit = px >= entry_price * (1 + self.take_profit)
if bool(exit.loc[dt]) or stop_hit or target_hit:
gross = shares * px
cash += gross - gross * self.commission
trades[-1].update({"exit_date": dt, "exit_price": px,
"gross_pnl": (px - entry_price) * shares})
shares, entry_price = 0, None
if shares == 0 and bool(entry.loc[dt]):
invest = cash * self.allocation
shares = int(invest / px)
if shares > 0:
cash -= shares * px + shares * px * self.commission
entry_price = px
trades.append({"entry_date": dt, "entry_price": px,
"shares": shares, "entry_reason": "信號"})
equity.append(cash + shares * px)
position.append(shares)
return pd.Series(equity, index=self.price.index), pd.DataFrame(trades), pd.Series(position, index=self.price.index)
當引擎已持有部位時，它會檢查三個出場條件：策略出場信號、跌破停損點或觸及停利點。若其中一個條件為真，引擎會賣出做多部位、扣除手續費、更新現金，並在交易分類帳中記錄已實現毛損益。
相關摘要： 將頂尖策略紀錄收斂到單一績效審閱章節，並提供每個規則的程式碼解析與教訓。
相關摘要： 以交易教訓、來源註記、委員會敘事與最終治理檢核表收尾。
交易紀錄不單單只是收據。它是交易桌的記憶系統。每個進場日期都在質問交易員究竟是擁有可重複驗證的信號，還是只是流於說故事。每個出場日期都在檢視流程是否尊重風險，亦或是在等待情緒化的妥協。每一次的回撤都在考驗部位規模化規則是否誠實面對了波動度。
營運模型文章的第一個教訓是，流程證據必須先於績效解讀。只有當審查員清楚知道資料模式、規則邏輯、執行假設、成本處理方式以及產出物儲存位置時，一張排名表才具有實際價值。
第二個教訓是，代理角色應該劃分得足夠狹窄，以便被挑戰。編排器可以負責協調，引擎可以負責模擬，審查員可以負責摘要，但這些組件都不應該悄悄變成了投資組合的最終決策者。
第三個教訓是，營運模型應該在任何人爭論個人偏好之前，先揭露策略的個性 (Strategy Personality)。低周轉率規則、高夏普值規則與高交易頻率規則會產生不同的審閱義務，因此產出物包裹應讓 these 差異一目了然。
本文使用上傳的自訂引擎產出物作為績效討論的來源。資訊清單 (Manifest) 說明該引擎為 CustomCerebroEngine，資料模式為確定性離線示範資料，策略數量為 20 個，圖片數量為 22 張，且規則皆為純做多、無選擇權、無賣權、無放空。策略摘要檔案依據總報酬率、年化報酬率、波動度、夏普值、最大回撤、交易次數與勝率排列全部 20 個策略。上傳的程式碼檔案提供了引擎結構、指標定義、信號映射 (Signal Map)、計量函數 (Metrics Function) 以及彭博 (Bloomberg) 深色模式圖表生成方法。
外部架構參考：Amazon Bedrock AgentCore 文件將 AgentCore 描述為用於安全且大規模部署與營運代理的託管服務 (Managed Service)，並將 AgentCore Runtime 描述為支援 Strands、LangGraph 與 CrewAI 等框架的安全無伺服器環境 (Secure Serverless Environment)。Strands 文件說明如何將 Strands Agents 部署到 AgentCore Runtime，以及使用 Python 整合模式建立代理入口點。Backtrader 文件則作為 Cerebro 模式的概念參考，用於收集資料摘要 (Data Feeds)、策略、分析器、觀察器與繪圖功能。
以下是向委員會簡報研究前可以演練的結語訊息：
我們今天不是來慶祝獲利的。我們是來檢視獲利背後的流程。Amazon 的部位表現確實強勁，但強勁的表現並不能消除風險紀律的必要性。我們建立了自訂引擎、整理了 20 種時機策略、審閱了紀錄，並將研究證據與推薦語言完全分離。
正確的結論並不是我們應該讓代理來替我們進行交易。正確的結論是，代理可以協助我們記錄假設、執行可重複的測試、比較策略行為、暴露邏輯盲點，並與風險、技術和治理團隊展開更具建設性的對話。人類的判斷仍然是最終的控制關卡。