使用 Bedrock AgentCore、Strands Agents 與 Backtrader 建立受治理的 Amazon 交易歷史工廠（Trade-History Factory）

免責聲明

教育目的： 此處內容僅聚焦於合法的財務規劃教育，目的在於提升對概念、方法論與分析方式的理解，並不推廣任何特定證券、策略或市場參與決策。

非個人化建議： 本教育材料在任何情況下均不提供個人化推薦、招攬或保證，也不明示、暗示或以其他方式表示對未來績效、結果或報酬有任何保證。

資料限制： 由於沙盒（sandbox）環境中無法取得即時資料（live data），上傳結果依賴確定性（deterministic）、離線資料（offline data），因此輸出應解讀為示範性範例，而非即時分析。

純做多（Long-Only）範圍： 所有研究語言皆為純做多（long only），避免選擇權（options）、賣權（puts）、放空（short selling）或看空策略（bearish strategies），確保討論整體聚焦於傳統資產持有與正向方向性風險敞口（exposure）概念。

開場：將回測（Backtests）轉成交易歷史工廠（Trade-History Factory）

單一 AMZN 回測（backtest）可以回答一個研究問題，但機構需要可重複的工廠（factory）。本文聚焦於每個核准的執行（approved run）應如何產生相同的證據模式（evidence pattern）：政策驗證（policy validation）、資料集參考（dataset reference）、策略版本（strategy version）、參數記錄（parameter record）、交易帳本（trade ledger）、風險摘要（risk summary）、異常日誌（exception log）與審閱備忘錄（review memo）。

定位

本文的語氣是一位營運模型擁有者（operating-model owner），面向量化分析師（quants）、風險經理（risk managers）、平台工程師（platform engineers）與治理審閱人員（governance reviewers）。訊息是：可重複性（repeatability）與策略創意（strategy creativity）同樣重要；如果兩次執行（runs）無法透過相同的產出物結構（artifact structure）進行比較，研究流程就尚未達到委員會評審標準（committee-ready）。

值得解決的客戶問題

金融服務團隊常常在研究請求（research request）與支撐它的交易記錄（trade records）之間失去脈絡。受治理的工廠透過標準化 AMZN 策略執行（strategy runs）的請求、核准、執行、儲存與質疑（challenge）方式來解決此問題。業務問題不只是分析速度，而是幾個月後是否還能找回證據。

此工作流（Workflow）支援的業務成果

工廠設計（Factory design）支援可重複的研究取入（research intake）、標準化交易帳本（trade ledgers）、更乾淨的異常處理（exception handling）、一致的產出物儲存（artifact storage），以及更容易的獨立質疑（independent challenge）。投資組合團隊（Portfolio teams）可以比較不同的策略（strategies），風險團隊（risk teams）每次都能檢查相同的欄位，技術團隊（technology teams）也能在不拖慢每個研究週期（research cycle）的情況下強制執行權限（permissions）。

目錄

• 第 1 部分：開場與市場脈絡 — 建立 AMZN 時機選擇（timing）問題、機構審閱（institutional review）目的、基準指數認知（benchmark awareness）、揭露紀律（disclosure discipline），以及在配置（allocation）前先建立證據的框架。
• 第 2 部分：智能體研究架構（Agentic Research Architecture） — 說明 Bedrock AgentCore 與 Strands 工作流（workflow）、職責分離（separation of duties）、工具權限（tool permissions）、審計產出物（audit artifacts），以及人工核准邊界（human approval boundary）。
• 第 3 部分：真實市場資料與基準指數（Benchmarks） — 定義 AMZN 與基準指數背景（benchmark context）、調整後 OHLCV 處理（adjusted OHLCV handling）、日曆對齊（calendar alignment）、資料血統（lineage）、公司行動（corporate actions）與資料品質控制（data-quality controls）。
• 第 4 部分：受治理的交易歷史工廠實作與程式碼邏輯（Governed Trade-History Factory Implementation 與 Code Logic） — 將策略邏輯（strategy logic）翻譯為進場（entry）、出場（exit）、部位規模調整（sizing）、風險控制（risk-control）與可審閱的程式碼路徑語言（code-path language），供機構利害關係人（institutional stakeholders）使用。
• 第 5 部分：交易帳本製造與部位管理（Trade-Ledger Manufacturing 與 Position Management） — 展示帳本欄位（ledger fields）、最大回撤審閱（drawdown review）、週轉率（turnover）與已實現交易記錄（realized trade records）如何支援有紀律的部位管理決策（position-management decisions）。
• 第 6 部分：高階主管總結與治理審閱（Executive Close 與 Governance Review） — 將技術工作流（technical workflow）轉換為委員會語言（committee language），同時把合適性（suitability）、實作就緒性（implementation readiness）與最終決策（final decisions）留給人類。
• 第 7 部分：工廠治理、資料設定與架構細節（Factory Governance、Data Setup 與 Architecture Detail） — 將系列焦點（series focus）、智能體架構（agentic architecture）、真實資料設定（real data setup）與治理設計筆記（governance design notes）集中為一個具可讀性的營運模型章節（operating-model section）。
• 第 8 部分：Backtrader 測試底座、智能體執行期與交易歷史綱要（Backtrader Harness、Agent Runtime 與 Trade-History Schema） — 將可執行底座（executable harness）、執行期草圖（runtime sketch）、時機選擇治理問題（timing-governance problem）與帳本綱要（ledger schema）分離，讓技術閱讀更清楚。
• 第 9 部分：策略型錄與 Backtrader 策略類別（Strategy Catalog 與 Backtrader Strategy Classes） — 將策略審閱方法（strategy review method）與策略 16 到策略 20 的程式碼範例（code examples）組織為一個策略型錄章節（strategy-catalog section）。
• 第 10 部分：高階主管摘要與最終治理資料註記（Executive Summary 與 最終治理資料註記） — 以委員會就緒的摘要語言（committee-ready summary language）、正式環境注意事項、最終資料註記與僅限教育用途邊界收尾。

第 1 部分：開場與市場脈絡

相關摘要： 建立 AMZN 時機選擇（timing）問題，說明為何回測（backtesting）屬於機構審閱（institutional review），並將文章定位為證據生成（evidence generation）而非預測（prediction）。本節把一個獲利的純做多（long-only）部位連結到風險紀律（risk discipline）、基準指數認知（benchmark awareness）、揭露語言（disclosure language）與委員會就緒的溝通（committee-ready communication）。

一篇強而有力的文章應從交易問題開始，而不是從軟體開始。一個純做多（long-only）的 Amazon 部位可能獲利，卻仍受困於時機選擇（timing）薄弱、出場紀律（exit discipline）不清楚，以及風險敞口（exposure）過大。因此，本節將回測定位為一種治理工具，協助交易台在討論配置（allocation）前先說明決策。

先前交付註記（delivery note）的實用內容在此被消化為：用證據說話、明確說出假設、避免確定語氣。受眾應聽到工作流測試了什麼、哪些資料支撐它、可能失敗之處，以及哪些仍是人的決策。這比在結尾附上重複的實踐段落（practice paragraph）更有力。

市場脈絡很重要，因為 AMZN 受到成長胃納（growth appetite）、廣泛股票體系（broad equity regime）、消費者預期（consumer expectations）、雲端投資情緒（cloud sentiment）、流動性（liquidity）與估值壓力（valuation pressure）影響。基準指數認知（Benchmark awareness）幫助交易員避免宣稱每一分收益都來自個股特有技能（stock-specific skill）。

第 2 部分：智能體研究架構（Agentic Research Architecture）

相關摘要： 說明 Bedrock AgentCore、Strands Agents、資料工具、策略生成、Backtrader 執行與結果摘要如何形成受控工作流。本節強調工具權限（tool permissions）、職責分離（separation of duties）、審計產出物（audit artifacts），以及在任何真實世界投資組合決策（real-world portfolio decision）前的人為核准。

智能體架構會分離職責。協調器（Orchestrator）接收請求（request），資料工具（data tool）驗證 OHLCV 輸入（inputs），策略生成器（strategy generator）準備規則邏輯（rule logic），Backtrader 工具執行模擬（simulation），風險審閱員（risk reviewer）彙總回撤（drawdown）與交易行為（trade behavior），治理檢查員（governance checker）則驗證政策邊界（policy boundaries）。

被消化後的交付規則以架構紀律（architecture discipline）形式呈現：每個智能體動作（agent action）都應產生證據。一個有用的執行會留下資料參考（data reference）、程式碼版本（code version）、參數（parameters）、時間戳記（timestamps）、交易帳本（trade ledger）、指標（metrics）、圖表路徑（chart path）與異常記錄（exception record）。這些產出物（artifacts）讓投資（investment）、技術（technology）與風險團隊（risk teams）能夠審閱輸出。

AgentCore 與 Strands Agents 可以加速研究迴圈（research loop），但有限授權至關重要。系統可以執行核准的工具（approved tools）並準備備忘錄（memo）；它不應決定合適性（suitability）、核准資金配置（capital allocation），或把歷史回測轉換為績效承諾（performance promise）。

第 3 部分：真實市場資料與基準指數（Benchmarks）

相關摘要： 定義 AMZN 作為研究資產（research asset），並定義那斯達克 100 指數（Nasdaq 100）、標普 500 指數（S&P 500）與道瓊工業平均指數（Dow Jones Industrial Average）作為基準指數背景（benchmark context）。本節說明調整後 OHLCV 資料（adjusted OHLCV data）、日曆對齊（calendar alignment）、資料血統（data lineage）、公司行動處理（corporate-action handling），以及為何不應使用虛構市場價格。

資料血統（Data lineage）是一項交易控制（trading control）。調整後價格（adjusted prices）、公司行動（corporate actions）、缺失值（missing values）、節假日曆（holiday calendars）、供應商變更（vendor changes）與基準指數對齊（benchmark alignment）都可能改變時機選擇規則（timing rule）的表面行為。本節將資料工程（data engineering）視為投資治理（investment governance）的一部分，而不是背景任務。

AMZN 是可交易資產。那斯達克 100（Nasdaq 100）、標普 500（S&P 500）與道瓊工業平均指數（Dow Jones Industrial Average）分別提供成長體系（growth regime）、廣泛股市風險（broad equity risk）與藍籌股風險情緒（blue-chip sentiment）的不同視角。工作流應記錄為何使用每個基準指數，以及每個基準指數可能在哪裡誤導分析。

本文避免虛構價格與缺乏支撐的績效主張（performance claims）。若無法擷取資料，應說明限制。若使用正式生產資料（production data），資料集快照（dataset snapshot）與調整政策（adjustment policy）應與回測產出物（backtest artifacts）一併保存。

第 4 部分：受治理的交易歷史工廠實作與程式碼邏輯（Governed Trade-History Factory Implementation 與 Code Logic）

相關摘要： 介紹本文使用的策略範例（strategy examples），並說明每個規則如何建立進場與出場條件（entry 與 exit conditions）。本節將訊號邏輯（signal logic）與執行邏輯（execution logic）分離，並把程式碼翻譯成白話的部位管理控制（position-management controls）。

策略實作（Strategy implementation）應讀起來像一張控制地圖（control map）。進場邏輯（Entry logic）說明為何開立做多部位（long position）。出場邏輯（Exit logic）說明為何平倉。規模調整邏輯（Sizing logic）說明承擔多少風險敞口（exposure）。風險邏輯（Risk logic）說明流程何時覆寫訊號（signal）。這讓非開發者也能理解程式碼審閱（code review）。

訊號邏輯（Signal logic）與執行邏輯（execution logic）應保持分離。訊號可以辨識有利條件，但執行引擎（execution engine）必須檢查既有部位狀態（position state）、可用現金（available cash）、手續費（commission）、風險停損（risk stops）與目標出場（target exits）。分離可改善可審計性（auditability），並降低隱藏行為。

本文把程式碼討論（code talk）放在主要策略討論（strategy discussion）內，而不是作為分離的筆記。每個策略應依其帳本（ledger）、回撤（drawdown）、週轉率（turnover）、基準指數行為（benchmark behavior）與營運可行性（operational feasibility）評估，而不是只看標題報酬率（headline return）。

本文特別聚焦於治理（governance）、政策驗證（policy validation）、交易歷史製造（trade-history manufacturing）、異常處理（exception handling）、產出物儲存（artifact storage）與高階主管溝通（executive communication）。因此程式碼審閱應評估策略家族（strategy family）是否支援該業務目標，以及其交易記錄是否足以向機構審閱委員會解釋。

第 5 部分：交易帳本製造與部位管理（Trade-Ledger Manufacturing 與 Position Management）

相關摘要： 說明交易帳本（trade ledger）如何透過記錄進場（entries）、出場（exits）、價格（prices）、規模（sizes）、已實現損益（realized profit and loss）、訊號原因（signal reasons）、回撤行為（drawdown behavior）、週轉率（turnover）與風險調整後審閱（risk-adjusted review），支援部位管理決策（position-management decisions）。

交易帳本是交易台的記憶系統。它記錄進場日期（entry date）、出場日期（exit date）、價格（price）、規模（size）、毛損益（gross profit and loss）、進場原因（entry reason）與出場原因（exit reason）。沒有帳本，策略（strategy）只是一個故事。有了帳本，委員會可以檢查模擬決策（simulated decisions）的實際序列。

最大回撤審閱（Drawdown review）必須先於報酬率慶祝（return celebration）。策略可能在總報酬率（total return）上看起來具吸引力，卻難以在真實壓力中持有。帳本與回撤路徑協助審閱人員（reviewers）判斷該規則是否符合投資授權（mandate）與風險承受度（risk tolerance）。

先前實作筆記（practice-note）訊息被消化進審閱流程（review process）：在任何結論之前，說明資料來源（data source）、日期範圍（date range）、策略規則（strategy rule）、基準指數背景（benchmark context）、風險指標（risk metric）與帳本（ledger）。本文將其保留在部位管理章節（position-management section）內，因為它改變了證據的閱讀方式。

第 6 部分：高階主管總結與治理審閱（Executive Close 與 Governance Review）

相關摘要： 將技術工作流（technical workflow）轉換為委員會語言（committee language）。本節說明智能體如何加速研究而不取代問責、證據應如何被挑戰，以及專業人士如何持續負責合適性（suitability）、風險承受度（risk tolerance）、資料品質（data quality）、實作就緒性（implementation readiness）與最終資金決策（final capital decisions）。

結尾把工廠設計（factory design）轉換為委員會語言。委員會需要知道每個 AMZN 研究執行（research run）是否都產生請求記錄（request record）、政策結果（policy result）、資料集參考（dataset reference）、策略版本（strategy version）、交易帳本（trade ledger）、風險摘要（risk summary）、異常日誌（exception log）與保留的產出物路徑（retained artifact path）。

智能體（Agent）不會取代專業人士。智能體工具（Agentic tools）可以標準化執行與儲存，但審閱人員仍負責核准、質疑（challenge）、合適性語言（suitability language）與最終資金決策。

有紀律的結尾會避免宣傳性語言（promotional language）。訊息是：只有當產出物（artifacts）能被找到、重新執行、比較與挑戰時，才信任這個工廠。

第 7 部分：工廠治理、資料設定與架構細節（Factory Governance、Data Setup 與 Architecture Detail）

系列焦點（Series Focus）

本文聚焦於治理（governance）、政策驗證（policy validation）、交易歷史製造（trade-history manufacturing）與高階主管溝通（executive communication）。它是四篇技術系列文章的一部分。結構已達可發布狀態，且避免暴露草稿指令。它保留演講教練（speaking-coach）的意圖，同時把訊息轉化為面向金融服務受眾的精煉章節。

結合 Bedrock AgentCore 與 Strands Agents 的智能體架構（Agentic Architecture With Bedrock AgentCore And Strands Agents）

此架構將判斷與自動化分離。量化協調器（Quant Orchestrator）接收研究請求並協調專業工具（specialist tools）。策略生成器（Strategy Generator）撰寫或擷取 Backtrader 策略類別（strategy classes）。市場資料工具（Market Data Tool）擷取 AMZN、^NDX、^GSPC 與 ^DJI 的每日（daily）OHLCV 資料。風險摘要智能體（Risk Summary Agent）計算報酬率（return）、最大回撤（drawdown）、風險敞口（exposure）、交易次數（trade count）、勝率（win rate）、獲利因子（profit factor）與基準指數相對行為（benchmark-relative behavior）。治理智能體（Governance Agent）檢查政策邊界（policy boundary）：純做多普通股（long-only common equity）、無衍生性商品（no derivatives）、無毫無根據的績效承諾（no unsupported performance promise）。

此設計適合機構研究（institutional research），因為它建立可追溯性（traceability）。模型不會暗中決定投資組合。相反地，智能體呼叫核准的工具（approved tools）、記錄輸入與輸出，並回傳可由人類委員會（human committee）質疑的備忘錄（memo）。程式碼範例使用 Backtrader，因為它提供事件驅動研究引擎（event-driven research engine）、技術指標（technical indicators）、分析器（analyzers）、訂單處理（order handling）與交易統計數據（trade statistics）。

真實資料設定（Real Data Setup）

範例使用 Amazon 普通股作為可交易資產，並使用三個基準指數作為背景：那斯達克 100 代表成長與科技體系（growth 與 technology regime），標普 500 代表廣泛美國股票體系（broad U.S. equity regime），道瓊工業平均指數代表藍籌股風險情緒（blue-chip risk sentiment）。可執行底座（executable harness）在您的環境中執行時，會透過 yfinance 下載真實每日資料。本文不虛構市場價格或捏造績效數字（fabricated performance numbers）。

第 8 部分：Backtrader 測試底座、智能體執行期與交易歷史綱要（Backtrader Harness、Agent Runtime 與 Trade-History Schema）

適用於二十年交易歷史的可重複使用 Backtrader 測試底座（Reusable Backtrader Harness For Twenty-Year Trade History）

## 檔案: run_amzn_long_only_backtest.py
## 僅限教育研究用途。非投資建議。

import json
from pathlib import Path
from typing import Dict, Type

import backtrader as bt
import pandas as pd
import yfinance as yf

START_DATE = "2006-06-19"
END_DATE = "2026-06-19"
TICKERS = ["AMZN", "^NDX", "^GSPC", "^DJI"]

class TradeLoggerMixin:
    params = dict(risk_per_trade=0.10, stop_loss_pct=0.12, take_profit_pct=0.35)

    def __init__(self):
        self.order = None
        self.entry_price = None
        self.trade_rows = []

    def long_size(self):
        price = self.data0.close[0]
        if price <= 0:
            return 0
        return int((self.broker.getcash() * self.p.risk_per_trade) / price)

    def buy_long(self, reason):
        if self.position or self.order:
            return
        size = self.long_size()
        if size > 0:
            self.entry_reason = reason
            self.order = self.buy(size=size)

    def close_long(self, reason):
        if self.position and not self.order:
            self.exit_reason = reason
            self.order = self.close()

    def risk_exit_check(self):
        if not self.position or self.entry_price is None:
            return
        close = self.data0.close[0]
        if close <= self.entry_price * (1 - self.p.stop_loss_pct):
            self.close_long("risk_stop")
        elif close >= self.entry_price * (1 + self.p.take_profit_pct):
            self.close_long("profit_target")

    def notify_order(self, order):
        if order.status == order.Completed:
            dt = self.data0.datetime.date(0).isoformat()
            if order.isbuy():
                self.entry_date = dt
                self.entry_price = order.executed.price
                self.entry_size = order.executed.size
            else:
                exit_price = order.executed.price
                pnl = (exit_price - self.entry_price) * self.entry_size
                self.trade_rows.append({
                    "entry_date": self.entry_date,
                    "exit_date": dt,
                    "entry_price": round(self.entry_price, 4),
                    "exit_price": round(exit_price, 4),
                    "size": int(self.entry_size),
                    "gross_pnl": round(pnl, 2),
                    "entry_reason": getattr(self, "entry_reason", "signal"),
                    "exit_reason": getattr(self, "exit_reason", "signal"),
                })
                self.entry_price = None
            self.order = None
        elif order.status in [order.Canceled, order.Margin, order.Rejected]:
            self.order = None

    def stop(self):
        self.rets = list(self.trade_rows)

def download_data() -> Dict[str, pd.DataFrame]:
    raw = yf.download(TICKERS, start=START_DATE, end=END_DATE, auto_adjust=True, group_by="ticker", progress=False)
    out = {}
    for ticker in TICKERS:
        frame = raw[ticker].dropna().copy()
        frame.columns = [c.lower() for c in frame.columns]
        frame.index = pd.to_datetime(frame.index)
        out[ticker] = frame
    return out

def run_backtest(strategy_cls: Type[bt.Strategy], strategy_name: str, cash: float = 100000.0):
    data = download_data()
    cerebro = bt.Cerebro(stdstats=False)
    cerebro.broker.setcash(cash)
    cerebro.broker.setcommission(commission=0.0005)
    cerebro.adddata(bt.feeds.PandasData(dataname=data["AMZN"]), name="AMZN")
    cerebro.adddata(bt.feeds.PandasData(dataname=data["^NDX"]), name="NDX")
    cerebro.adddata(bt.feeds.PandasData(dataname=data["^GSPC"]), name="SPX")
    cerebro.adddata(bt.feeds.PandasData(dataname=data["^DJI"]), name="DJI")
    cerebro.addstrategy(strategy_cls)
    cerebro.addanalyzer(bt.analyzers.SharpeRatio, _name="sharpe", timeframe=bt.TimeFrame.Days)
    cerebro.addanalyzer(bt.analyzers.DrawDown, _name="drawdown")
    cerebro.addanalyzer(bt.analyzers.TradeAnalyzer, _name="trades")
    result = cerebro.run()[0]
    final_value = cerebro.broker.getvalue()
    out_dir = Path("backtest_outputs")
    out_dir.mkdir(exist_ok=True)
    trade_file = out_dir / f"{strategy_name}_trade_history_2006_2026.csv"
    pd.DataFrame(getattr(result, "rets", [])).to_csv(trade_file, index=False)
    report = {
        "strategy": strategy_name,
        "start": START_DATE,
        "end": END_DATE,
        "initial_cash": cash,
        "final_value": final_value,
        "total_return_pct": round((final_value / cash - 1) * 100, 2),
        "sharpe": result.analyzers.sharpe.get_analysis(),
        "drawdown": result.analyzers.drawdown.get_analysis(),
        "trade_analyzer": result.analyzers.trades.get_analysis(),
        "trade_history_file": str(trade_file),
    }
    with open(out_dir / f"{strategy_name}_summary.json", "w") as f:
        json.dump(report, f, indent=2, default=str)
    return report

智能體執行期草圖（Agent Runtime Sketch）

## 檔案: quant_agent_runtime.py
## 範例模式；請根據正式生產環境調整 IAM、網路、核准與日誌。

from bedrock_agentcore import BedrockAgentCoreApp
from strands import Agent, tool

app = BedrockAgentCoreApp()

ALLOWED = {
    "breakout_55": "Breakout55Strategy",
    "ema_cross": "EMACrossStrategy",
    "multi_factor": "MultiFactorEnsembleStrategy",
}

@tool
def validate_policy(strategy_key: str, side: str, derivatives: bool) -> dict:
    if side.lower() != "long_only":
        return {"ok": False, "reason": "僅允許純做多股票研究。"}
    if derivatives:
        return {"ok": False, "reason": "衍生性商品工具超出此工作流範圍。"}
    if strategy_key not in ALLOWED:
        return {"ok": False, "reason": "策略未在註冊表中獲得核准。"}
    return {"ok": True, "reason": "政策已接受。"}

@tool
def run_registered_backtest(strategy_key: str) -> dict:
    return {"status": "submitted", "strategy": ALLOWED[strategy_key], "artifact_prefix": f"s3://research/amzn/{strategy_key}/"}

agent = Agent(tools=[validate_policy, run_registered_backtest])

@app.entrypoint
def invoke(payload):
    return agent(payload.get("request", "執行核准的 AMZN 純做多回測。"))

if __name__ == "__main__":
    app.run()

業務問題：時機選擇（Timing）是治理問題

Amazon 部位可能在長期區間獲利，卻仍管理不佳。因此，機構需要流程語言（process language），而不只是績效語言（performance language）。研究團隊應展示買了什麼、何時買、為何買、何時賣、為何賣，以及該決策相對於主要股票基準指數（equity benchmarks）的行為。智能體工作流（Agentic workflow）讓這些證據更容易產生，也更容易被挑戰。

二十年交易歷史綱要（Twenty-Year Trade History Schema）

交易歷史（Trade history）很重要，因為它防止模糊敘事。委員會可以檢查獲利是來自多次可重複的交易（trades）還是某個異常期間、出場（exits）是否在熊市體系（bear regimes）中降低傷害、基準指數過濾（benchmark filters）是否有幫助，以及週轉率（turnover）是否能承受現實的執行成本（realistic implementation costs）。

高階主管演講結語（Executive Speaking Close）

最後訊息是針對特定工廠（factory-specific）：一個有用的回測若流程無法重複，就還不夠。AgentCore 與 Strands Agents 可以協助製造一致的審閱記錄（review records），而 Backtrader 可以產生交易帳本（trade ledger）。人類審閱人員（Human reviewers）仍決定證據是否完整。

來源與資料註記（Sources And Data Notes）

• 真實資料工作流： 可執行範例使用 yfinance 下載 AMZN、^NDX、^GSPC 與 ^DJI 的每日（daily）OHLCV 資料。
• 時間範圍： 2006-06-19 至 2026-06-19，受市場休市日（market holidays）與資料提供商可用性（data-provider availability）影響。
• AWS 設計模式： Bedrock AgentCore 執行期（runtime）用於智能體協調編排（agent orchestration），Strands Agents 用於工具協調（tool coordination），而 AWS 受治理的資料模式（AWS governed data patterns）用於資料血統（lineage）、存取（access）與產出物儲存（artifact storage）。
• 僅限教育用途： 非個人化建議、非招攬，也非績效保證。

應用主文細節 1：交易歷史工廠設計（Applied Main-Article Detail 1: Trade-History Factory Design）

受治理的工廠每次都建立相同產出物模式（破坏型模式）：輸入記錄（input record）、策略版本（strategy version）、參數（parameters）、資料快照（data snapshot）、交易帳本（trade ledger）、風險指標（risk metrics）、圖表包（chart package）、異常日誌（exception log）與審閱備忘錄（review memo）。可重複性（Repeatability）是重點。

應用主文細節 2：執行前政策驗證（Applied Main-Article Detail 2: Policy Validation Before Execution）

政策驗證（Policy validation）應在回測執行前發生。工作流應確認標的範圍（symbol scope）、純做多行為（long-only behavior）、許可的策略鍵（permitted strategy key），以及沒有不受支援的工具邏輯（unsupported instrument logic）。這能防止研究輸出（research output）違反營運邊界（operating boundary）。

應用主文細節 3：異常處理即治理（Applied Main-Article Detail 3: Exception Handling As Governance）

失敗的資料下載（failed data download）、缺失的基準指數（missing benchmark）、零交易策略（zero-trade strategy）、拒絕的訂單（rejected order）或分析器錯誤（analyzer error）都應成為可見的異常（exception）。工廠不應把營運問題（operational problems）隱藏在精美摘要（summary）後面。

應用主文細節 4：產出物儲存與檢索（Applied Main-Article Detail 4: Artifact Storage And Retrieval）

工廠的價值在於檢索（retrieval）。委員會應能找到產生某項聲明的精確帳本（ledger）、圖表（chart）、程式碼（code）與參數集（parameter set）。這正是 AWS 資料控制（data controls）與智能體日誌（agent logs）轉化為業務證據（business evidence）的地方。

應用主文細節 5：高階主管溝通層（Applied Main-Article Detail 5: Executive Communication Layer）

主管層（Executive layer）應在不過度誇大（overclaim）的情況下總結發生了什麼。它應展示測試了什麼、套用了哪些控制（controls）、產生了哪些記錄（records）、哪些失敗，以及哪個決策（decision）仍由人類負責。

應用主文細節 6：就緒可審計生命週期（Applied Main-Article Detail 6: Audit-Ready Lifecycle）

就緒可審計生命週期（Audit-ready lifecycle）涵蓋請求、驗證、執行、審閱、核准、保留（retention）與重新執行（rerun）。本文將工廠定位為生命週期，而不僅僅是程式碼筆記本（code notebook）。

機構審閱視角 1：證據包設計（Institutional Review Lens 1: Evidence Package Design）

完整的證據包（evidence package）應包含研究問題（research question）、資料來源（data source）、調整政策（adjustment policy）、股票清單（symbol list）、程式碼版本（code version）、參數集（parameter set）、交易帳本（trade ledger）、回撤概況（drawdown profile）、指標摘要（metrics summary）、異常日誌（exception log）與揭露語言（disclosure language）。這讓回測可在投資、風險、技術與合規團隊（compliance teams）之間被審閱。

機構審閱視角 2：人工質疑工作流（Institutional Review Lens 2: Human Challenge Workflow）

當工作流能邀請質疑（challenge）時，它才算成功。審閱人員應詢問資料是否乾淨、規則是否具備經濟合理解釋（economic rationale）、基準指數（benchmark）是否適當、參數（parameters）是否穩定、成本（costs）是否符合現實，以及結論是否限於證據所支持的範圍。

機構審閱視角 3：純做多政策邊界（Institutional Review Lens 3: Long-Only Policy Boundary）

本文將政策邊界（policy boundary）保持為純做多（long-only）。該邊界讓工作流聚焦於時機選擇（timing）、部位規模調整（sizing）、出場（exits）與證據品質（evidence quality），而不是複雜的金融工具建構（instrument construction）。它也給治理智能體（governance agent）一條明確規則，用於拒絕缺乏支撐的請求（requests）。

機構審閱視角 4：圖表與帳本解讀（Institutional Review Lens 4: Chart And Ledger Interpretation）

圖表（Charts）很有用，但帳本（ledger）才是審計追蹤（audit trail）。權益曲線（Equity curve）可能隱藏集中度（concentration），單一報酬數字也可能隱藏週轉率（turnover）。因此，本文將圖表、帳本與指標視為互補證據，而非可互換的證明（proof）。

機構審閱視角 5：正式環境就緒檢查清單（Institutional Review Lens 5: Production Readiness Checklist）

筆記本（Notebook）不是正式生產環境（production）。正式環境就緒需要受控的資料存取（data access）、具備版本控制的程式碼（versioned code）、參數記錄（parameter records）、可重複的執行（repeatable runs）、異常處理（exception handling）、產出物儲存（artifact storage）、核准工作流（approval workflow）與監控（monitoring）。智能體工具（Agentic tooling）應支援這些控制，而不是繞過它們。

機構審閱視角 6：失效模式揭露（Institutional Review Lens 6: Failure Mode Disclosure）

專業文章應及早指出失效模式（failure modes）。趨勢規則可能遭受雙邊洗盤（whipsaw），動能（momentum）可能消耗殆盡（exhaust），波動率過濾器（volatility filters）可能落後（lag），基準指數過濾器（benchmark filters）也可能排除快速復甦的機會。點名這些風險能提高可信度，並協助委員會準備有用的問題。

第 9 部分：策略型錄與 Backtrader 策略類別（Strategy Catalog 與 Backtrader Strategy Classes）

相關摘要： 將策略審閱方法（strategy review method）與策略 16 到策略 20 的程式碼範例（code examples）組織為一個策略型錄章節（strategy-catalog section）。

閱讀記錄前的策略審閱方法（Strategy Review Method Before Reading The Records）

閱讀策略記錄（strategy records）前，對每個規則使用相同的證據序列（evidence sequence）：確認資料、辨識進場條件（entry condition）、辨識出場條件（exit condition）、檢查規模調整假設（sizing assumption）、審閱回撤（drawdown）、比較基準指數行為（benchmark behavior），並記錄經驗教訓（lesson learned）。這句話把重複的交付註記轉成文章內使用的方法。

本文中的策略型錄（Strategy Catalog In This Article）

• 策略 16: StochasticStrengthStrategy — 隨機指標強度延續（Stochastic strength continuation）。
• 策略 17: CCIMomentumStrategy — 順勢指標動能進場（Commodity Channel Index momentum entry）。
• 策略 18: IchimokuLongStrategy — 一目均衡表雲帶趨勢過濾（Ichimoku cloud trend filter）。
• 策略 19: ParabolicSARStrategy — 拋物線轉向指標趨勢追隨進場（Parabolic SAR trend-following entry）。
• 策略 20: MultiFactorEnsembleStrategy — 趨勢、動能與市場體系整合（Trend, momentum, and market-regime ensemble）。

策略 16: StochasticStrengthStrategy

研究目的。 隨機指標強度延續（Stochastic strength continuation）。此策略（strategy）被寫作純做多（long-only）AMZN 時機選擇範例（timing example）。它可以進入做多部位（long position）、平掉做多部位，或維持現金（cash）。它不建立放空風險敞口（short exposure），也不使用選擇權（options）、賣權（puts）、掉期/互換（swaps）、期貨（futures）、保證金（margin）或其他衍生性商品（derivative instruments）。

部位管理審閱。 對於 StochasticStrengthStrategy，交易台應評估隨機指標強度延續是否在考慮成本（costs）、回撤（drawdown）與基準指數背景（benchmark context）後，仍能增加有用的時機選擇證據。審閱應檢查規則交易頻率、出場（exits）是否可理解、持有期間（holding period）是否符合授權（mandate），以及訊號是否提供超越在每個體系（regime）中單純持有 AMZN 的洞察。

Backtrader 程式碼。 將此類別（class）加在可重複使用底座（reusable harness）下方，然後在受控研究環境中執行 run_backtest(StochasticStrengthStrategy, "StochasticStrengthStrategy")。

class StochasticStrengthStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(period=14, period_dfast=3, risk_per_trade=0.07)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.stoch = bt.ind.StochasticFast(self.data0, period=self.p.period, period_dfast=self.p.period_dfast)
        self.trend = bt.ind.SMA(self.data0.close, period=100)
    def next(self):
        self.risk_exit_check()
        if not self.position and self.data0.close[0] > self.trend[0] and self.stoch.percK[0] > self.stoch.percD[0] and self.stoch.percK[-1] <= self.stoch.percD[-1]:
            self.buy_long("stochastic_strength_cross")
        elif self.position and self.stoch.percK[0] < self.stoch.percD[0]:
            self.close_long("stochastic_cross_exit")

智能體對 StochasticStrengthStrategy 的審閱應總結此特定策略執行的訊號路徑（signal path）、帳本完整性（ledger completeness）、風險控制活動（risk-control activity）與純做多政策狀態（long-only policy status）。

策略 17: CCIMomentumStrategy

研究目的。 順勢指標動能進場（Commodity Channel Index momentum entry）。此策略（strategy）被寫作純做多（long-only）AMZN 時機選擇範例（timing example）。它可以進入做多部位（long position）、平掉做多部位，或維持現金（cash）。它不建立放空風險敞口（short exposure），也不使用選擇權（options）、賣權（puts）、掉期/互換（swaps）、期貨（futures）、保證金（margin）或其他衍生性商品（derivative instruments）。

部位管理審閱。 對於 CCIMomentumStrategy，交易台應評估順勢指標動能進場是否在考慮成本（costs）、回撤（drawdown）與基準指數背景（benchmark context）後，仍能增加有用的時機選擇證據。審閱應檢查規則交易頻率、出場（exits）是否可理解、持有期間（holding period）是否符合授權（mandate），以及訊號是否提供超越在每個體系（regime）中單純持有 AMZN 的洞察。

Backtrader 程式碼。 將此類別（class）加在可重複使用底座（reusable harness）下方，然後在受控研究環境中執行 run_backtest(CCIMomentumStrategy, "CCIMomentumStrategy")。

class CCIMomentumStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(period=20, entry=100, exit=0, risk_per_trade=0.07)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.cci = bt.ind.CCI(self.data0, period=self.p.period)
    def next(self):
        self.risk_exit_check()
        if not self.position and self.cci[0] > self.p.entry and self.cci[-1] <= self.p.entry:
            self.buy_long("cci_momentum_break")
        elif self.position and self.cci[0] < self.p.exit:
            self.close_long("cci_zero_exit")

智能體對 CCIMomentumStrategy 的審閱應總結此特定策略執行的訊號路徑（signal path）、帳本完整性（ledger completeness）、風險控制活動（risk-control activity）與純做多政策狀態（long-only policy status）。

策略 18: IchimokuLongStrategy

研究目的。 一目均衡表雲帶趨勢過濾（Ichimoku cloud trend filter）。此策略（strategy）被寫作純做多（long-only）AMZN 時機選擇範例（timing example）。它可以進入做多部位（long position）、平掉做多部位，或維持現金（cash）。它不建立放空風險敞口（short exposure），也不使用選擇權（options）、賣權（puts）、掉期/互換（swaps）、期貨（futures）、保證金（margin）或其他衍生性商品（derivative instruments）。

部位管理審閱。 對於 IchimokuLongStrategy，交易台應評估一目均衡表雲帶趨勢過濾是否在考慮成本（costs）、回撤（drawdown）與基準指數背景（benchmark context）後，仍能增加有用的時機選擇證據。審閱應檢查規則交易頻率、出場（exits）是否可理解、持有期間（holding period）是否符合授權（mandate），以及訊號是否提供超越在每個體系（regime）中單純持有 AMZN 的洞察。

Backtrader 程式碼。 將此類別（class）加在可重複使用底座（reusable harness）下方，然後在受控研究環境中執行 run_backtest(IchimokuLongStrategy, "IchimokuLongStrategy")。

class IchimokuLongStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(risk_per_trade=0.08)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.ichi = bt.ind.Ichimoku(self.data0)
    def next(self):
        self.risk_exit_check()
        cloud_top = max(self.ichi.senkou_span_a[0], self.ichi.senkou_span_b[0])
        cloud_bottom = min(self.ichi.senkou_span_a[0], self.ichi.senkou_span_b[0])
        if not self.position and self.data0.close[0] > cloud_top and self.ichi.tenkan_sen[0] > self.ichi.kijun_sen[0]:
            self.buy_long("ichimoku_cloud_break")
        elif self.position and self.data0.close[0] < cloud_bottom:
            self.close_long("ichimoku_cloud_exit")

智能體對 IchimokuLongStrategy 的審閱應總結此特定策略執行的訊號路徑（signal path）、帳本完整性（ledger completeness）、風險控制活動（risk-control activity）與純做多政策狀態（long-only policy status）。

策略 19: ParabolicSARStrategy

研究目的。 拋物線轉向指標趨勢追隨進場（Parabolic SAR trend-following entry）。此策略（strategy）被寫作純做多（long-only）AMZN 時機選擇範例（timing example）。它可以進入做多部位（long position）、平掉做多部位，或維持現金（cash）。它不建立放空風險敞口（short exposure），也不使用選擇權（options）、賣權（puts）、掉期/互換（swaps）、期貨（futures）、保證金（margin）或其他衍生性商品（derivative instruments）。

部位管理審閱。 對於 ParabolicSARStrategy，交易台應評估拋物線轉向指標趨勢追隨進場是否在考慮成本（costs）、回撤（drawdown）與基準指數背景（benchmark context）後，仍能增加有用的時機選擇證據。審閱應檢查規則交易頻率、出場（exits）是否可理解、持有期間（holding period）是否符合授權（mandate），以及訊號是否提供超越在每個體系（regime）中單純持有 AMZN 的洞察。

Backtrader 程式碼。 將此類別（class）加在可重複使用底座（reusable harness）下方，然後在受控研究環境中執行 run_backtest(ParabolicSARStrategy, "ParabolicSARStrategy")。

class ParabolicSARStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(af=0.02, afmax=0.20, risk_per_trade=0.07)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.psar = bt.ind.ParabolicSAR(self.data0, af=self.p.af, afmax=self.p.afmax)
    def next(self):
        self.risk_exit_check()
        if not self.position and self.data0.close[0] > self.psar[0] and self.data0.close[-1] <= self.psar[-1]:
            self.buy_long("psar_flip_positive")
        elif self.position and self.data0.close[0] < self.psar[0]:
            self.close_long("psar_flip_exit")

智能體對 ParabolicSARStrategy 的審閱應總結此特定策略執行的訊號路徑（signal path）、帳本完整性（ledger completeness）、風險控制活動（risk-control activity）與純做多政策狀態（long-only policy status）。

策略 20: MultiFactorEnsembleStrategy

研究目的。 趨勢、動能與市場體系整合（Trend, momentum, and market-regime ensemble）。此策略（strategy）被寫作純做多（long-only）AMZN 時機選擇範例（timing example）。它可以進入做多部位（long position）、平掉做多部位，或維持現金（cash）。它不建立放空風險敞口（short exposure），也不使用選擇權（options）、賣權（puts）、掉期/互換（swaps）、期貨（futures）、保證金（margin）或其他衍生性商品（derivative instruments）。

部位管理審閱。 對於 MultiFactorEnsembleStrategy，交易台應評估趨勢、動能與市場體系整合是否在考慮成本（costs）、回撤（drawdown）與基準指數背景（benchmark context）後，仍能增加有用的時機選擇證據。審閱應檢查規則交易頻率、出場（exits）是否可理解、持有期間（holding period）是否符合授權（mandate），以及訊號是否提供超越在每個體系（regime）中單純持有 AMZN 的洞察。

Backtrader 程式碼。 將此類別（class）加在可重複使用底座（reusable harness）下方，然後在受控研究環境中執行 run_backtest(MultiFactorEnsembleStrategy, "MultiFactorEnsembleStrategy")。

class MultiFactorEnsembleStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(risk_per_trade=0.09)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.ma50 = bt.ind.SMA(self.data0.close, period=50)
        self.ma200 = bt.ind.SMA(self.data0.close, period=200)
        self.rsi = bt.ind.RSI(self.data0.close, period=14)
        self.macd = bt.ind.MACD(self.data0.close)
        self.spx200 = bt.ind.SMA(self.data2.close, period=200)
    def next(self):
        self.risk_exit_check()
        score = int(self.data0.close[0] > self.ma50[0]) + int(self.ma50[0] > self.ma200[0]) + int(self.rsi[0] > 50) + int(self.macd.macd[0] > self.macd.signal[0]) + int(self.data2.close[0] > self.spx200[0])
        if not self.position and score >= 4:
            self.buy_long("ensemble_score_entry")
        elif self.position and score <= 2:
            self.close_long("ensemble_score_exit")

智能體對 MultiFactorEnsembleStrategy 的審閱應總結此特定策略執行的訊號路徑（signal path）、帳本完整性（ledger completeness）、風險控制活動（risk-control activity）與純做多政策狀態（long-only policy status）。

第 10 部分：高階主管摘要與最終治理資料註記（Executive Summary 與 最終治理資料註記）

供委員會使用的高階主管摘要（Executive Summary For Committee Use）

這篇工廠（factory）文章應被閱讀為營運模型設計（operating-model design），而不是尋找某個偏好的 AMZN 訊號（signal）。它的核心問題是每次策略執行（strategy run）是否都留下足夠證據，以供重新執行（rerun）、質疑（challenge）、保留（retention）與比較（comparison）。

最終決策仍由人类負責。智能體工具（Agentic tooling）可以標準化請求處理（request handling）、政策檢查（policy checks）、帳本生成（ledger generation）與產出物儲存（artifact storage），但它不能決定產生的證據是否足以支援投資組合行動（portfolio action）。

最終治理資料註記

• 真實資料工作流： 可執行範例應使用經核准的每日 OHLCV 資料，涵蓋 AMZN、那斯達克 100（Nasdaq 100）、標普 500（S&P 500）與道瓊工業平均指數（Dow Jones Industrial Average）。
• 時間範圍： 範例設計使用二十年研究窗口，並應在每次執行（run）中記錄精確的開始與結束日期（start 與 end dates）。
• AWS 設計模式： Bedrock AgentCore 執行期（runtime）可託管智能體協調編排（agent orchestration），而 Strands Agents 可協調工具使用（tool use）與結果審閱（result review）。
• 僅限教育用途： 非個人化建議、非招攬，也非績效保證。