Freqtrade Is the Execution Layer, Not the Brain
在 ProBitForge，我们把 Freqtrade 当成“执行层”（execution layer），而不是“脑子”（brain）。
这句话听起来像是架构洁癖，但它其实是为了一个非常朴素的目标：把系统失控的概率压到足够低，而且让每一次交易都能被解释、被复盘、被追责。
这篇文章是 research only，not financial advice。并且，backtests are not live performance，not an instruction to trade。
如果你刚来，建议先看站点的定位说明：<https://www.probitforge.com/what-probitforge-is-building/>
1) 为什么“不要让执行层思考”
把执行层做成“又能下单、又能自己决定下不下单”的一体化系统，会带来三个典型问题：
1. 不可审计的复杂性堆叠 - 当策略逻辑、数据处理、风控、状态机、交易执行混在一起时，你很难回答：这笔交易为什么发生？下一笔会不会重复同样的问题？
2. 风险边界不清晰 - 研究代码里经常有“临时修一下”“先跑起来”的东西。一旦这些临时代码能直接触发交易，就相当于把风险边界打穿了。
3. 迭代速度反而变慢 - 你以为一体化能更快，但每次修改都需要担心影响执行的稳定性。最终你会被“回归恐惧”拖慢。
我们更偏向把系统拆成两层：
- 执行层（Freqtrade）：稳定、可审计、可回放；负责接收“明确的交易意图”，并在严格约束下执行。
- 决策层（Research / Risk / Orchestration）：负责产出“交易意图”，并提供证据、限制条件与可解释记录。
2) 执行层应该提供什么能力
把 Freqtrade 定位为执行层，并不意味着它很“傻”。相反，我们希望它具备工程上最值钱的能力：
1. 标准化执行接口 - 输入清晰：标的、方向、仓位规则、止损/止盈/保护规则、执行窗口等。 - 输出可记录：订单、成交、滑点、费用、延迟、失败原因。
2. 可观测性与回放 - 执行层要能把“发生了什么”完整记录下来，方便后续把决策事实与交易事实对齐。
3. 最小权限原则 - 执行层只对“能否执行”负责，不对“是否值得执行”负责。 - 例如：风控命令明确要求暂停时，执行层应该无条件拒绝下单。
4. 失败要可解释 - 断线、余额不足、交易所拒单、价格偏离、杠杆限制，这些都必须变成结构化原因，而不是“没下单”三个字。
3) 决策层应该承担什么责任
如果执行层不“思考”，决策层就必须承担更明确的责任：
1. 研究与证据 - 明确使用了哪些数据、哪些特征、哪些假设。 - 明确哪些条件会让结论失效（regime shift、流动性枯竭、手续费变化等）。
2. 风控与门禁（gates） - 在任何“允许执行”的决策被下发之前，先过门禁：反过拟合检查、样本外检查、交易次数阈值、回测一致性检查等。 - 这也是为什么我们反复强调：backtests are not live performance。
3. 编排与节奏 - 决策层负责“什么时候允许系统更激进，什么时候必须保守”，而不是把所有风险都交给执行层的一个参数。
4. 事实账本 - 你要能回答：这个策略候选在什么时候通过了哪些门禁？当时的证据是什么？上线后是否违背了预设假设？
4) 一个更清晰的接口：从“信号”到“意图”
很多系统把“信号（signal）”直接塞给执行层。但信号通常太轻了，它只告诉你“可能要买/卖”，却没告诉你：
- 这是研究信号还是上线信号？
- 允许的执行窗口多长？
- 允许的最大风险暴露是多少？
- 是否允许加仓？是否允许反手？
- 如果环境不满足假设，是否必须拒绝执行？
所以我们更倾向于用“意图（intent）”来描述发给执行层的输入。意图应该是结构化的，至少包含：
- 行为：long / short / exit / reduce / pause
- 约束：最大仓位、最大杠杆、最小流动性、最大滑点容忍
- 风控：允许/禁止的失败模式（例如连续亏损后强制降级）
- 证据引用：该意图来自哪个研究结论、哪个回测/样本外报告
执行层拿到意图后做两件事：
1. 检查约束是否满足（不满足就拒绝执行并记录原因） 2. 在满足约束的前提下稳定执行（并记录执行事实）
5) 这套拆分对运营有什么好处
如果你把 ProBitForge 当成一个长期的工程项目，而不是一阵子能跑就行的脚本，这种拆分会带来非常直接的收益：
- 更容易持续发文：每篇文章可以围绕一个边界（执行/决策/风控/数据）展开，而不是堆一坨不可复用的细节。
- 更容易积累可信度：读者能看到我们如何验证假设、如何记录失败、如何做门禁，而不是“回测很好看”。
- 更容易做自动化：当流程清晰，发布脚本可以自动生成 draft、做脱敏扫描、做验证、输出回执。
6) 最重要的一条红线
AI、研究脚本、临时分析，不应该直接触达买卖按钮。
这不是“反 AI”，而是工程上对风险的尊重：你越是依赖复杂系统，就越需要把执行层做得单纯、可控、可审计。
这篇文章依然是 research only，not financial advice；backtests are not live performance；not an instruction to trade。
下一篇我们会继续写：如何把“意图”落到可审计的事实表里，让每一次决策都能回放。