使用 Bedrock AgentCore 和 Strands Agents 构建机构级 Amazon 只做多回测代理

描述： 机构级 AMZN 研究需要因子验证、基准风险、回撤治理、执行台账和云端控制。使用 Amazon Bedrock AgentCore、Strands Agents、AWS 数据服务、Nasdaq 100、S&P 500、Dow Jones 基准、Sharpe 分析以及可审计的 FSI 头寸管理证据，构建只做多 Backtrader 工作流，用于有纪律的择时决策和治理审查。

免责声明

教育目的：
本文内容仅聚焦于合法的金融规划教育，旨在增进对概念、方法论和分析方法的理解，不推广任何特定证券、策略或市场参与决策。

非个性化建议：
本文不提供个性化推荐、招揽或保证；在任何情况下，本教育材料均不暗示、明示或以其他方式表示对未来表现、结果或收益的任何保证。

数据限制：
由于沙盒环境无法获取实时数据，上传结果依赖确定性的离线数据，因此输出应被理解为示例说明，而非实时分析。

只做多范围：
所有研究表述均限定为只做多，避免期权、看跌期权、卖空或看跌策略，确保讨论总体聚焦于传统资产持有和正向方向性敞口概念。

目录

• 第 1 部分：开篇背景与文章重点
  介绍 AMZN 只做多择时问题、文章重点，以及在讨论任何配置决策之前先生成证据的业务原因。本部分帮助读者理解交易表达、市场背景，以及为什么该工作流属于教育内容而非投资建议。
• 第 2 部分：代理式架构与治理控制
  解释 AgentCore 和 Strands 的运行模型，包括编排器、数据代理、策略代理、风险复核代理、治理检查器、工具权限、审计工件和人工审批边界。本部分让架构在代码和策略记录出现之前更易阅读。
• 第 3 部分：数据、基准与回测框架
  涵盖真实或经批准的数据输入、基准背景、OHLCV 对齐、数据血缘以及可复用回测框架。本部分展示 AMZN、Nasdaq 100、S&P 500 和 Dow Jones 背景如何转化为可复核的研究证据。
• 第 4 部分：策略框架与只做多代码逻辑
  解释本文策略族背后的实现框架，包括入场逻辑、出场逻辑、头寸规模、执行隔离、风险控制和通俗代码审阅。本部分帮助读者在不丢失治理背景的情况下检查策略示例。
• 第 5 部分：交易台账与头寸管理证据
  聚焦交易台账、头寸管理证据、换手率、回撤审查，以及为什么每次模拟入场和出场都必须可追溯。本部分将回测从一张图表转化为一串可复核的决策序列。
• 第 6 部分：治理、风险复核与机构质询
  汇集机构审查指引、模型风险问题、质询工作流、审计追踪预期、生产就绪、参数敏感性、失效模式和委员会证据标准。本部分通过在策略记录之前集中呈现治理内容来提升可读性。
• 第 7 部分：策略目录与阅读方法
  展示策略目录和阅读策略记录的方法。本部分为读者在治理概念与单个策略示例之间提供一段简短导航。
• 第 8 部分：策略记录 1-5：EMA、Breakout、Donchian、RSI 与 Bollinger
  将策略 1-5 归入一个可读部分，便于读者审阅本文的五条策略记录，而不把每个策略都变成独立的一级目录项。重点是研究目的、代码逻辑、风险控制和交易台账解读。
• 第 9 部分：执行委员会摘要与收束陈述
  将技术研究转化为高管和委员会语言。本部分总结测试了什么、仍有哪些不确定性、为什么工作流不能取代人的问责，以及如何负责任地讨论结果。
• 第 10 部分：来源、数据说明与最终披露
  将来源、数据说明、限制和最终披露语言集中在一起。本部分澄清数据假设、时间窗口、AWS 设计参考以及文章的教育边界。

第 1 部分：开篇背景与文章重点

相关摘要： 介绍 AMZN 只做多择时问题、文章重点，以及在讨论任何配置决策之前先生成证据的业务原因。本部分帮助读者理解交易表达、市场背景，以及为什么该工作流属于教育内容而非投资建议。

开篇与市场背景

相关摘要： 确立 Amazon 只做多择时问题，解释为什么回测属于机构审查的一部分，并将本文定位为证据生成而非预测。本节把一笔盈利的 AMZN 头寸与风险纪律、基准意识、披露语言和委员会可用沟通连接起来。

一笔较大的 Amazon 未实现收益可能带来信心，但信心不是控制框架。机构层面的问题不只是该多头头寸在历史上是否奏效。更好的问题是，交易台能否解释为什么增加敞口、为什么持有、为什么降低敞口，以及该决策相对于广义股票和科技板块环境表现如何。

原先的表达指引现在直接融入开篇：使用证据语言、展示假设，并避免确定性表述。优秀的讲述者不会以承诺开场，而是以研究问题开场，说明约束条件，并明确告诉听众回测能证明什么、不能证明什么。

Amazon 是单一股票头寸，但会受到成长偏好、流动性、利率、消费者预期、云计算情绪和广义股票风险的影响。因此，本文使用 Nasdaq 100、S&P 500 和 Dow Jones Industrial Average 作为背景，而不是把 AMZN 当作图表上一条孤立曲线。

该工作流的目的在于有纪律地创建证据。Bedrock AgentCore 和 Strands Agents 的价值在于它们可以协调工具、保存工件并组织审查。Backtrader 的价值在于它把策略规则转化为可回放的订单、头寸、指标和交易记录序列。

系列重点

本文聚焦研究运行模型、数据来源和前五个择时策略。它面向金融服务读者而设计，因为他们需要的不只是一张图表，还需要可辩护的工作流、清晰的台账，以及能够区分教育内容和投资建议的表述。

业务问题：择时是治理问题

一笔 Amazon 头寸可以在长期维度上盈利，同时仍然管理不善。因此，机构需要的是流程语言，而不仅是业绩语言。研究团队应展示买入了什么、何时买入、为什么买入、何时卖出、为什么卖出，以及该决策相对于主要股票基准表现如何。代理式工作流让这些证据更容易生成，也更容易被质询。

实务沟通规则在这里直接嵌入，而不是事后附加：在委员会能够检查假设、数据源、策略逻辑、风险控制和交易台账之前，不要要求委员会相信一张图表。这就是作为营销幻灯片的回测与作为机构证据的回测之间的差异。

第 2 部分：代理式架构与治理控制

相关摘要： 解释 AgentCore 和 Strands 的运行模型，包括编排器、数据代理、策略代理、风险复核代理、治理检查器、工具权限、审计工件和人工审批边界。本部分让架构在代码和策略记录出现之前更易阅读。

代理式研究架构

相关摘要： 解释 Bedrock AgentCore、Strands Agents、数据工具、策略生成、Backtrader 执行和结果汇总如何形成受控工作流。本节强调工具权限、职责分离、审计工件，以及在任何真实投资组合决策之前所需的人工审批。

该架构是一个受控运行模型，而不是单个自主交易大脑。Quant Orchestrator 接收研究请求。Market Data Agent 验证数据。Strategy Agent 准备经批准的规则逻辑。Backtest Tool 执行模拟。Risk Review Agent 汇总回撤、敞口和交易。Governance Agent 检查政策边界。

原先关于用证据说话的说明没有被放在附录中，而是作为架构纪律嵌入在这里：每个代理动作都应产生可追溯工件，包括数据快照、代码版本、参数集、运行时间、结果文件、图表和异常记录。这就是技术自动化转化为机构证据的方式。

代理治理意味着权限有边界。代理可以调用经批准的工具、运行经批准的研究并汇总输出。它不应决定客户适当性、批准资本配置，或把历史回测呈现为未来收益声明。人工审批仍然是最终控制点。

在生产环境中，AgentCore 可以托管代理运行时，Strands Agents 可以协调工具行为。投资团队仍然需要 IAM 边界、日志记录、数据权限、代码审查和复核闸口。目标是在控制下提升速度，而不是以牺牲问责为代价追求速度。

下面的代理草图将政策验证与回测执行分离。代理可以提交研究任务，但不会批准交易，也不会提出个性化推荐。

from bedrock_agentcore import BedrockAgentCoreApp
from strands import Agent, tool

app = BedrockAgentCoreApp()

ALLOWED = {
    "ema_cross": "EMACrossStrategy",
    "breakout_55": "Breakout55Strategy",
    "donchian_trend": "DonchianTrendStrategy",
}

@tool
def validate_policy(strategy_key: str, side: str, derivatives: bool) -> dict:
    if side.lower() != "long_only":
        return {"ok": False, "reason": "Only long-only equity research is allowed."}
    if derivatives:
        return {"ok": False, "reason": "Derivative instruments are outside this workflow."}
    if strategy_key not in ALLOWED:
        return {"ok": False, "reason": "Strategy is not approved in the registry."}
    return {"ok": True, "reason": "Policy accepted."}

@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):
    request = payload.get("request", "Run approved AMZN long-only backtest.")
    return agent(request)

使用 Bedrock AgentCore 和 Strands Agents 的代理式架构

该架构将判断与自动化分离。Quant Orchestrator 接收研究请求并协调专门工具。Strategy Generator 编写或检索 Backtrader 策略类。Market Data Tool 获取 AMZN、Nasdaq 100、S&P 500 和 Dow Jones Industrial Average 的日度 OHLCV 数据。Risk Summary Agent 计算收益、回撤、敞口、交易次数、胜率、利润因子以及相对基准行为。Governance Agent 检查政策边界：只做多普通股、不使用衍生工具、不作无依据的业绩承诺、不提供个性化推荐。

这种设计适合机构研究，因为它创造了可追溯性。模型不会暗中决定投资组合。相反，代理调用经批准的工具，记录输入和输出，并返回一份可由人工委员会质询的备忘录。该工作流将原先的演示指引吸收到架构本身：在讨论任何结论之前，先解释数据、解释规则、解释风险，并列明假设。

AgentCore 与 Strands 运行控制

代理式工作流应围绕权限进行设计。代理应知道自己可以调用哪些工具、可以研究哪些标的、哪一数据源已获批准，以及哪些输出需要人工复核。这可以避免把研究助手变成不受控制的决策者。

Strands Agents 可以协调推理和工具调用模式，而 Bedrock AgentCore 可以为代理部署提供运行环境。本文将二者定位为工作流基础设施，而不是任何策略未来有效的保证。

第 3 部分：数据、基准与回测框架

相关摘要： 涵盖真实或经批准的数据输入、基准背景、OHLCV 对齐、数据血缘以及可复用回测框架。本部分展示 AMZN、Nasdaq 100、S&P 500 和 Dow Jones 背景如何转化为可复核的研究证据。

真实市场数据与基准

相关摘要： 将 AMZN 定义为研究资产，并将 Nasdaq 100、S&P 500 和 Dow Jones Industrial Average 定义为基准背景。本节解释经调整 OHLCV 数据、日历对齐、数据血缘、公司行为处理，以及为什么不应使用虚构市场价格。

数据血缘是一项交易控制。如果经调整价格、公司行为、时区、缺失值或基准日历处理不当，表面上的策略结果可能发生变化。因此，本文在正文中讨论数据来源，而不是把它当作后台细节。

AMZN 是可交易资产。Nasdaq 100 提供成长和科技背景。S&P 500 提供广义美国股票环境背景。Dow Jones Industrial Average 提供蓝筹风险情绪背景。这些基准帮助交易员判断 Amazon 的强势是个股特有、受市场支持，还是容易受到广泛去风险的影响。

工作流应记录开始日期、结束日期、供应商、调整设置、标的代码、缺失值处理方式和对齐规则。这些记录使重新运行成为可能，并帮助委员会理解为什么数据来源变化时两次回测会出现差异。

本文不依赖虚构市场价格。如果沙盒中无法获得真实数据，必须披露这一限制。如果生产环境中可以获得真实数据，研究流程应保存每次运行所使用的精确数据集引用。

真实数据设置

示例使用 Amazon 普通股作为可交易资产，并使用三个基准指数作为背景：Nasdaq 100 用于成长和科技环境，S&P 500 用于广义美国股票环境，Dow Jones Industrial Average 用于蓝筹风险情绪。在生产环境中，可执行框架应从经批准的来源下载或加载真实日度数据，保存数据快照，并记录调整方法。本文不需要虚构价格或编造业绩数字。

AMZN 研究的数据质量控制

数据质量控制不仅是技术检查。它是一项交易风险控制，因为每个信号都依赖价格、成交量、日期和标的映射。研究团队应记录价格是否已调整、拆股和股息是否已处理，以及缺失交易日是被剔除还是填补。

对于 AMZN，公司行为和长期时间跨度可能显著影响表面趋势路径。因此，二十年回测应在每次运行时保存数据源细节。如果日后重新运行同一规则，团队应能够识别结果变化来自代码、参数还是数据修订。

相对基准解读

只做多 Amazon 策略应与相关基准比较，因为单看绝对收益可能产生误导。如果 AMZN 随整个成长市场一起上涨，信号可能并未增加太多价值。如果策略在市场普遍疲弱时避免回撤，即使总收益较低，也可能具有价值。

相对基准解读也有助于讲述者避免过度声称。交易员可以说某条规则在特定历史背景下改善了参与质量，同时承认未来市场环境可能不同。这比宣称某个策略更优更具专业语气。

第 4 部分：策略框架与只做多代码逻辑

相关摘要： 解释本文策略族背后的实现框架，包括入场逻辑、出场逻辑、头寸规模、执行隔离、风险控制和通俗代码审阅。本部分帮助读者在不丢失治理背景的情况下检查策略示例。

策略实现与代码逻辑

相关摘要： 介绍五个只做多择时策略，并解释每条规则如何生成入场和出场条件。本节将信号逻辑与执行逻辑分离，展示 Backtrader 框架如何记录交易，并把代码转译为通俗的头寸管理控制。

策略实现应被解释为一张控制映射。入场逻辑回答为什么打开多头头寸。出场逻辑回答为什么关闭头寸。头寸规模逻辑回答有多少资本暴露在风险中。风险逻辑回答流程在何时覆盖信号。这种语言让投资、技术和风险团队能够共同质询设计。

信号逻辑和执行逻辑被刻意分离。信号可以说明条件有利，但引擎仍必须检查投资组合是否已经持有股票、现金是否可用、佣金如何适用，以及止损或目标规则是否被触发。这种分离让代码更易审查。

该策略集合覆盖趋势跟随、突破确认、基准感知参与、超卖修复和受控均值回归。目标不是推广某个通用指标，而是在共同框架下比较规则族，使交易台能够学习择时行为如何变化。

原先的实践指引在这里被吸收为代码审阅纪律：解释规则、展示假设、列明失效模式，并要求委员会在任何真实世界实施之前，同时质询信号和执行路径。

下面的可复用框架展示了数据、经纪商状态、头寸规模和风险退出之间的分离。本文将这段代码保留在实现部分，使读者看到治理如何直接体现在引擎设计中。

第 5 部分：交易台账与头寸管理证据

相关摘要： 聚焦交易台账、头寸管理证据、换手率、回撤审查，以及为什么每次模拟入场和出场都必须可追溯。本部分将回测从一张图表转化为一串可复核的决策序列。

交易历史与头寸管理

相关摘要： 解释二十年交易台账如何通过入场日期、出场日期、价格、规模、总损益、信号原因、回撤、胜率、换手率和风险调整审查来支持决策质量。台账成为策略的机构记忆。

交易台账是交易台的记忆系统。它记录入场日期、出场日期、入场价格、出场价格、头寸规模、总损益、入场原因和出场原因。没有这份台账，策略只是一个故事。有了它，委员会就可以检查决策序列。

回撤审查必须先于收益庆祝。即使一个策略总收益具有吸引力，如果路径难以承受，仍可能不适合。回撤显示从峰值到谷值损失了多少价值，并帮助交易台理解该规则是否能够在实时环境中被坚持执行。

换手率很重要，因为每增加一笔交易都可能引入滑点、佣金拖累、税务复杂性、运营负担和审查成本。高换手率规则必须说明为什么这些活动改善了风险调整后的参与质量，而不只是制造噪音。

经验教训应当明确。基准过滤器是否减少了不良入场？出场是否来得太晚？策略是否因为限制性过滤器而错过了大幅上涨？是否某个异常市场阶段解释了大部分利润？这些问题将回测转化为机构学习。

二十年交易历史 Schema

交易历史之所以重要，是因为它防止含糊叙事。委员会可以检查利润是来自许多可重复交易还是某个异常时期，出场是否在熊市环境中减少损害，基准过滤器是否有帮助，以及换手率能否承受现实实施成本。

头寸规模与资本纪律

头寸规模是研究转化为风险的地方。如果敞口相对于波动率、流动性或授权约束过大，即使入场信号良好，也可能产生糟糕结果。示例框架使用受控的头寸规模方法，使讨论保持聚焦于流程而非冲动。

头寸规模应与回撤、换手率和基准环境一起审查。如果某个策略只有在激进敞口下才表现良好，风险委员会应当知道这一点。如果某个策略在适度敞口和受控回撤下也能运行，则在保守的机构环境中可能更容易讨论。

将交易台账审查作为经验教训

交易台账帮助交易员识别利润是广泛分布还是高度集中。它可以揭示是否由某个异常趋势支撑了结果，是否累积了许多小额亏损，或出场是否持续保护了资本。这比单一标题收益更有用。

经验教训审查应将交易员假设与实际交易行为进行比较。策略是否按预期运行？它是否在强基准环境中入场？是否在重大回撤前退出？交易是否过于频繁？这些问题会让下一轮研究周期更好。

第 6 部分：治理、风险复核与机构质询

相关摘要： 汇集机构审查指引、模型风险问题、质询工作流、审计追踪预期、生产就绪、参数敏感性、失效模式和委员会证据标准。本部分通过在策略记录之前集中呈现治理内容来提升可读性。

规则型策略的模型风险问题

规则型策略看起来可能很透明，但仍然带有模型风险。参数选择、指标滞后、回看窗口、基准过滤器和出场规则都可能对历史条件过拟合。委员会应询问某个策略是否对合理的参数变化具备稳健性，以及是否具有合理的市场逻辑。

透明规则比含糊的主观判断更容易被质询，但这并不使它自动可靠。交易员应解释规则为什么可能失效、哪些环境不利，以及工作流如何在头寸管理流程变得情绪化之前发现恶化。

回撤期间的交易员沟通

最重要的陈述往往发生在回撤期间，而不是净值高点。能够解释规则、预期承压阈值、历史压力路径和当前偏离的交易员，比只展示收益图的交易员更能赢得信任。

因此，本文将回撤视为一次沟通事件。如果策略下跌，团队应知道亏损是在预期行为范围内、超出预期行为范围，还是由数据或执行问题导致。台账、图表和指标支持这场对话。

委员会可用证据包

完整的证据包应包括研究问题、数据集引用、代码版本、参数、交易台账、权益曲线、回撤图、汇总指标、异常日志和披露语言。该证据包让审查者能够同时评估策略和流程。

本文将代理定位为证据构建者。它们帮助收集、运行、汇总和组织。它们不会把教育性回测转化为建议。对于合法的金融规划讨论和内部金融服务治理而言，这一区分非常重要。

综合审查主题 1：参数敏感性审查

参数敏感性显示策略是否依赖某个脆弱设置。委员会应询问，如果 EMA 窗口、突破周期、RSI 阈值或 Bollinger 设置略有变化，会发生什么。稳健的研究流程不需要依赖单一完美参数来保持可信。

该审查主题属于正文的一部分，因为它会改变读者解读策略结果的方式。它不是独立说明，也不是作为填充内容附加。它将技术工作流与治理、公开沟通和机构决策质量连接起来。

综合审查主题 2：代理式研究中的异常处理

异常处理是治理的一部分。如果数据下载失败、基准缺失、策略没有产生交易，或分析器返回意外值，代理应标记异常，而不是悄悄生成误导性摘要。

综合审查主题 3：图表解读纪律

图表应支持台账，而不是取代台账。权益曲线可能看起来平滑，却隐藏集中风险；回撤图可以揭示标题收益忽略的压力。因此，本文将图表视为审查工件，而非未来机会的证明。

综合审查主题 4：人工质询工作流

强有力的投资委员会应从多个角度质询策略：数据质量、经济逻辑、参数稳定性、基准相关性、交易成本、运营可行性和披露语言。当工作流让这些质询更容易进行时，它才是成功的，而不是回避质询。

综合审查主题 5：FSI 审计追踪设计

FSI 审计追踪应保留是谁请求了运行、哪个代理处理了请求、调用了哪些工具、使用了哪个数据集、运行了哪个代码版本，以及工件存储在何处。这将研究流程从非正式实验转化为受控审查记录。

综合审查主题 6：只做多政策边界

本文保持只做多政策边界，因为教育目标是头寸择时和敞口管理，而不是复杂工具构建。清晰边界帮助审查者验证系统没有引入隐藏空头敞口或不受支持的衍生品逻辑。

综合审查主题 7：基准失效模式

基准可以提供帮助，但也可能误导。Nasdaq 确认可能来得较晚，S&P 环境过滤器可能排除快速修复，而 Dow 确认对高成长股票的相关性可能较低。交易员应在依赖基准过滤器之前解释这些失效模式。

综合审查主题 8：研究备忘录结构

研究备忘录应汇总问题、数据、策略规则、假设、业绩指标、回撤行为、交易台账发现、限制和下一步。即使实现代码是为量化开发人员编写的，备忘录也应让风险经理能够理解。

治理整合细节 1：从文章到工作流的控制映射

控制映射将文章中的每一项声明连接到一个运营检查点。如果文章说工作流可审计，就应有运行标识符。如果说策略行为可解释，就应有信号标签。如果说流程只做多，订单路径就应使空头敞口不可能出现。这将语言转化为证据。

该细节被整合进正文，因为它会改变专业读者解读回测的方式。它不是单独的说明块，也不是放在末尾的填充内容。它通过把主题连接到证据、控制和委员会审查，来支持重写后的目录。

治理整合细节 2：盈利头寸中的回测谦逊

一笔盈利的 Amazon 头寸可能让每张历史图表都显得有说服力。回测谦逊意味着记住下一个市场环境可能并不像上一个。因而本文避免暗示确定性的语言。它把回测视为能够改进问题的结构化历史回放，而不是产生答案的机器。

治理整合细节 3：风险委员会审查包

风险委员会需要一份简明材料包：目标、范围、数据源、基准集合、策略描述、头寸规模规则、风险控制、交易摘要、回撤画像、已知限制和拟议下一步。本文将这份材料包融入正文，使读者理解技术研究如何转化为审批讨论。

治理整合细节 4：为什么台账必须先于叙事

看到结果之后，叙事很容易被美化。台账更难被操纵，因为它展示事件顺序。因此，本文把交易台账置于讲故事之前。如果台账与叙事相矛盾，应改变叙事，而不是反过来。

治理整合细节 5：研究工件的云端治理

云存储可以用一致结构保存策略工件：原始数据、整理后数据、代码、参数文件、交易台账、图表、摘要和审批。其价值不只是便利，更在于每个工件都可以在多个研究周期之间被定位、审查、留存和比较。

治理整合细节 6：人工交易员在代理式研究中的角色

人工交易员仍然负责市场解读、授权匹配、沟通和升级。代理可以减少手工工作，但无法自行理解客户约束或机构问责。本文在主要章节中始终保持这一区分清晰可见。

治理整合细节 7：值得先行呈现的失效模式

当作者及早列明失效模式时，专业读者会更信任策略。趋势策略可能遭遇来回止损。回归策略可能在持续走弱中不断加仓摊低。基准过滤器可能滞后。成交量确认可能来得较晚。本文在策略示例之前解释这些风险，使读者准备好批判性评估代码。

治理整合细节 8：从研究运行到决策会议

研究运行只有在被汇总、质询并记录之后，才会成为决策材料。会议不应只问图表看起来是否漂亮，而应询问假设是否可接受、数据是否获批、回撤是否符合授权，以及策略是否带来任何可执行的洞察。

治理整合细节 9：只做多敞口作为设计约束

只做多敞口是一项简化治理的设计约束。它让本文聚焦于择时、头寸规模、入场、出场和审查，而不是工具工程。该约束也使政策验证更容易，因为代理可以拒绝任何试图引入不受支持敞口类型的请求。

治理整合细节 10：基于证据的陈述顺序

有力的陈述顺序是问题、流程、证据、限制和下一步。本文在主要内容中采用这一顺序。它从择时问题开始，解释代理式流程，提供代码和台账结构，说明限制，并以治理行动收束。

治理整合细节 11：独立质询与红队审查

机构工作流应主动引入独立质询。第二位审查者可以检查数据窗口、代码路径、指标和交易台账。红队审查可以询问策略在跳空风险、缺失数据、波动率上升或环境变化下可能如何失效。这会在生产决策之前提升信任。

治理整合细节 12：策略简洁性如何帮助治理

简单规则并不自动更好，但更容易解释和监控。简单的交叉、通道突破或修复规则让委员会理解交易为什么发生。如果简单规则失效，失效原因也更容易诊断。这对机构学习很有用。

第 7 部分：策略目录与阅读方法

相关摘要： 展示策略目录和阅读策略记录的方法。本部分为读者在治理概念与单个策略示例之间提供一段简短导航。

本文策略目录

• 策略 1：EMACrossStrategy — 10/30 EMA 交叉，并使用 S&P 环境确认。
• 策略 2：Breakout55Strategy — 55 日突破，并使用 20 日通道出场。
• 策略 3：DonchianTrendStrategy — Donchian 趋势延续，并使用 Nasdaq 确认。
• 策略 4：RSIRecoveryStrategy — 在长期上升趋势内从超卖状态进行 RSI 修复。
• 策略 5：BollingerReversionStrategy — 在趋势仍具建设性时进行 Bollinger 下轨回归。

第 8 部分：策略记录 1-5：EMA、Breakout、Donchian、RSI 与 Bollinger

相关摘要： 将策略 1-5 归入一个可读部分，便于读者审阅本文的五条策略记录，而不把每个策略都变成独立的一级目录项。重点是研究目的、代码逻辑、风险控制和交易台账解读。

策略 1：EMACrossStrategy

研究目的。 10/30 EMA 交叉，并使用 S&P 环境确认。该策略被写作只做多 AMZN 择时示例。它可以建立多头头寸、关闭多头头寸，或保持现金状态。它不会创建空头敞口，也不使用衍生工具。

代码逻辑摘要。 快速 EMA 上穿慢速 EMA 会生成入场候选，但 S&P 500 过滤器也必须提供支持。出场条件是快速 EMA 下穿慢速 EMA。该规则有助于解释如何将单一股票 Amazon 信号与广义市场环境检查结合起来。关键审查点是，在考虑回撤、换手率、基准背景和运营可行性之后，该规则是否改善了参与质量。

Backtrader 代码。

class EMACrossStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(fast=10, slow=30, benchmark_sma=100, risk_per_trade=0.10)

    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.fast = bt.ind.EMA(self.data0.close, period=self.p.fast)
        self.slow = bt.ind.EMA(self.data0.close, period=self.p.slow)
        self.cross = bt.ind.CrossOver(self.fast, self.slow)
        self.spx_sma = bt.ind.SMA(self.data2.close, period=self.p.benchmark_sma)

    def next(self):
        self.risk_exit_check()
        if not self.position and self.cross[0] > 0 and self.data2.close[0] > self.spx_sma[0]:
            self.buy_long("ema_cross_up_with_spx_filter")
        elif self.position and self.cross[0] < 0:
            self.close_long("ema_cross_down")

交易员审查与经验教训。 该策略应通过交易台账审查，而不只是通过最终收益审查。有用的审查会询问入场是否可解释、出场是否及时、风险退出是否主导信号退出、基准过滤器是否有帮助，以及该规则是否足够简单，能够在委员会质询下被辩护。

策略 2：Breakout55Strategy

研究目的。 55 日突破，并使用 20 日通道出场。该策略被写作只做多 AMZN 择时示例。它可以建立多头头寸、关闭多头头寸，或保持现金状态。它不会创建空头敞口，也不使用衍生工具。

代码逻辑摘要。 当 AMZN 收盘价高于此前 55 日高点时，策略入场；当价格跌破此前 20 日低点时，策略出场。这是一条清晰的趋势跟随规则，委员会容易对其提出质询，因为入场和出场阈值都可见。关键审查点是，在考虑回撤、换手率、基准背景和运营可行性之后，该规则是否改善了参与质量。

Backtrader 代码。

class Breakout55Strategy(TradeLoggerMixin, bt.Strategy):
    params = dict(entry_period=55, exit_period=20, risk_per_trade=0.10)

    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.entry_high = bt.ind.Highest(self.data0.high(-1), period=self.p.entry_period)
        self.exit_low = bt.ind.Lowest(self.data0.low(-1), period=self.p.exit_period)

    def next(self):
        self.risk_exit_check()
        if not self.position and self.data0.close[0] > self.entry_high[0]:
            self.buy_long("fifty_five_day_breakout")
        elif self.position and self.data0.close[0] < self.exit_low[0]:
            self.close_long("twenty_day_channel_exit")

交易员审查与经验教训。 该策略应通过交易台账审查，而不只是通过最终收益审查。有用的审查会询问入场是否可解释、出场是否及时、风险退出是否主导信号退出、基准过滤器是否有帮助，以及该规则是否足够简单，能够在委员会质询下被辩护。

策略 3：DonchianTrendStrategy

研究目的。 Donchian 趋势延续，并使用 Nasdaq 确认。该策略被写作只做多 AMZN 择时示例。它可以建立多头头寸、关闭多头头寸，或保持现金状态。它不会创建空头敞口，也不使用衍生工具。

代码逻辑摘要。 该规则要求 Amazon 向上突破 80 日通道，同时 Nasdaq 100 交易于 120 日均线之上。出场使用 35 日通道低点。它明确纳入基准确认，这对成长属性较强的单一股票头寸很有用。关键审查点是，在考虑回撤、换手率、基准背景和运营可行性之后，该规则是否改善了参与质量。

Backtrader 代码。

class DonchianTrendStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(channel=80, exit_channel=35, ndx_ma=120, risk_per_trade=0.08)

    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.highest = bt.ind.Highest(self.data0.high(-1), period=self.p.channel)
        self.lowest_exit = bt.ind.Lowest(self.data0.low(-1), period=self.p.exit_channel)
        self.ndx_ma = bt.ind.SMA(self.data1.close, period=self.p.ndx_ma)

    def next(self):
        self.risk_exit_check()
        if not self.position and self.data1.close[0] > self.ndx_ma[0] and self.data0.close[0] > self.highest[0]:
            self.buy_long("donchian_breakout_ndx_confirmed")
        elif self.position and self.data0.close[0] < self.lowest_exit[0]:
            self.close_long("donchian_exit")

交易员审查与经验教训。 该策略应通过交易台账审查，而不只是通过最终收益审查。有用的审查会询问入场是否可解释、出场是否及时、风险退出是否主导信号退出、基准过滤器是否有帮助，以及该规则是否足够简单，能够在委员会质询下被辩护。

策略 4：RSIRecoveryStrategy

研究目的。 在长期上升趋势内从超卖状态进行 RSI 修复。该策略被写作只做多 AMZN 择时示例。它可以建立多头头寸、关闭多头头寸，或保持现金状态。它不会创建空头敞口，也不使用衍生工具。

代码逻辑摘要。 当股票仍高于长期趋势过滤器时，该策略等待 RSI 修复并上穿低阈值。它不是接飞刀策略；它只在更大趋势仍具建设性时尝试参与修复。关键审查点是，在考虑回撤、换手率、基准背景和运营可行性之后，该规则是否改善了参与质量。

Backtrader 代码。

class RSIRecoveryStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(rsi_period=14, buy_level=35, sell_level=68, trend_period=200, risk_per_trade=0.07)

    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.rsi = bt.ind.RSI(self.data0.close, period=self.p.rsi_period)
        self.trend = bt.ind.SMA(self.data0.close, period=self.p.trend_period)

    def next(self):
        self.risk_exit_check()
        recovery = self.rsi[-1] < self.p.buy_level and self.rsi[0] > self.p.buy_level
        if not self.position and self.data0.close[0] > self.trend[0] and recovery:
            self.buy_long("rsi_recovery_in_uptrend")
        elif self.position and self.rsi[0] > self.p.sell_level:
            self.close_long("rsi_strength_exit")

策略 5：BollingerReversionStrategy

研究目的。 在趋势仍具建设性时进行 Bollinger 下轨回归。该策略被写作只做多 AMZN 择时示例。它可以建立多头头寸、关闭多头头寸，或保持现金状态。它不会创建空头敞口，也不使用衍生工具。

代码逻辑摘要。 只有当价格仍高于更长期趋势过滤器时，该策略才买入跌破 Bollinger 下轨的弱势。它在中轨附近出场。这将受控回归与无纪律摊低成本区分开来。关键审查点是，在考虑回撤、换手率、基准背景和运营可行性之后，该规则是否改善了参与质量。

Backtrader 代码。

class BollingerReversionStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(period=20, devfactor=2.0, trend_period=150, risk_per_trade=0.06)

    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.bbands = bt.ind.BollingerBands(self.data0.close, period=self.p.period, devfactor=self.p.devfactor)
        self.trend = bt.ind.EMA(self.data0.close, period=self.p.trend_period)

    def next(self):
        self.risk_exit_check()
        constructive = self.data0.close[0] > self.trend[0]
        if not self.position and self.data0.close[0] < self.bbands.bot[0] and constructive:
            self.buy_long("bollinger_lower_band_reversion")
        elif self.position and self.data0.close[0] >= self.bbands.mid[0]:
            self.close_long("bollinger_midline_exit")

交易员审查与经验教训。 该策略应通过交易台账审查，而不只是通过最终收益审查。有用的审查会询问入场是否可解释、出场是否及时、风险退出是否主导信号退出、基准过滤器是否有帮助，以及该规则是否足够简单，能够在委员会质询下被辩护。

第 9 部分：执行委员会摘要与收束陈述

相关摘要： 将技术研究转化为高管和委员会语言。本部分总结测试了什么、仍有哪些不确定性、为什么工作流不能取代人的问责，以及如何负责任地讨论结果。

高管收束与治理审查

相关摘要： 将技术工作流转化为委员会语言。本节解释代理如何在不取代问责的前提下加速研究、证据应如何被质询，以及专业人员如何继续对适当性、风险承受能力、数据质量、实施就绪和最终资本决策负责。

高管收束应把代码转化为决策语言。委员会需要听到测试了什么、产生了什么证据、哪些失败了、哪些改善了、仍有哪些不确定性，以及实施前需要哪些治理步骤。

代理不会取代投资组合经理。AgentCore 和 Strands Agents 可以加速数据收集、代码生成、执行和审查，但问责仍由理解适当性、授权约束、风险承受能力、运营就绪和客户沟通的专业人员承担。

运营就绪需要版本化代码、受控数据访问、参数记录、可复现工件、图表存储、异常处理、审批工作流和监控。对于生产级金融服务环境，仅有 notebook 结果是不够的。

最终信息刻意保持保守：在讨论配置之前先构建证据，在信任图表之前先检查台账，在庆祝收益之前先审查回撤，并在部署自动化之前保留人的问责。

高管陈述收束

第一篇文章的收束信息刻意保持基础性：确立研究问题，证明数据血缘，展示前五条策略规则，并在讨论配置之前检查台账。AgentCore 和 Strands Agents 让证据更容易组装，而 Backtrader 让规则路径可回放。二者都不能消除人的问责需求。

收束部分有意保持保守。它避免胜利式语言，聚焦工作流能够证明的内容：使用的数据、测试的规则、生成的交易、观察到的风险，以及仍待解决的治理问题。这就是技术回测如何成为业务对话，而不构成投资建议。

第 10 部分：来源、数据说明与最终披露

相关摘要： 将来源、数据说明、限制和最终披露语言集中在一起。本部分澄清数据假设、时间窗口、AWS 设计参考以及文章的教育边界。

来源与数据说明

• 真实数据工作流：可执行示例应使用经批准的 AMZN、Nasdaq 100、S&P 500 和 Dow Jones Industrial Average 日度 OHLCV 数据。
• 时间范围：示例设计使用二十年研究窗口，并应在每次运行中记录精确的开始和结束日期。
• AWS 设计模式：Bedrock AgentCore runtime 可以托管代理编排，而 Strands Agents 可以协调工具使用和结果审查。
• 仅用于教育：不属于个性化建议，不属于招揽，也不保证业绩。