ReelOS.AI 禅定｜一句话看懂本文
量化交易天然是一个循环，但循环跑得更快，不代表策略变得更真。
- Agent 可以自动提出假设、编写策略、运行回测、解释失败。
- 统计结果必须由程序计算。
- 生产策略必须经过版本晋级。
- 真实订单必须穿过独立风险闸门。
- 自进化量化不是让 Agent 在实盘中边亏边改。
- 而是让 Agent 在研究环境中快速进化，让资金在生产环境中严格受控。
一、一人量化的真正机会，不是“无人交易”
2026 年 6 月，Addy Osmani 将一种新的 Agent 工程范式总结为 Loop Engineering：
过去，人不断向 Agent 输入下一条提示词；现在，人开始设计一个能够自动发现任务、调用工具、验证结果、记录状态并决定下一步的循环系统。
这套方法通常包含：
- 自动触发任务的 Automation；
- 隔离并行工作的 Worktree；
- 沉淀专业规则的 Skill；
- 连接外部系统的 MCP Connector；
- 分离生成者与检查者的 Sub-agent；
- 跨会话保存进度的持久化 State。
Addy 特别强调，长期运行的 Agent 不能只依赖对话上下文。模型会结束会话，但存放在代码仓库、任务系统和状态文件中的外部记忆可以继续存在。
这套方法与量化研究天然契合。
因为量化研究本身就是一个循环：
观察市场
→ 提出假设
→ 准备数据
→ 构建策略
→ 回测验证
→ 识别失败
→ 修改假设
→ 重新实验过去，研究员坐在循环内部，手动推动每一步。
未来，交易员可以站到循环外部，设计：
- 什么问题值得研究；
- Agent 可以调用哪些工具；
- 什么结果算有效；
- 什么条件必须停止；
- 什么经验可以进入下一轮；
- 什么策略有资格接触真实资金。
这才是“一人量化”真正的杠杆。
不是减少一个下单员，而是建立一个能够持续运行的研究组织。
二、Loop 提高的是实验吞吐量，不是统计真实性
Agent 可以一天生成几十个因子、几百组参数和大量回测。
这看起来像生产力提升。
但在量化领域，实验越多，假阳性往往越多。
假设一个系统连续测试了：
- 100 个因子；
- 20 个持有周期；
- 10 种过滤规则；
- 5 种仓位模型。
它实际上已经搜索了大量策略组合。
即使市场完全不可预测，也可能碰巧找到一条历史 Sharpe 很高的曲线。
这就是 Backtest Overfitting。
Bailey、López de Prado 等人的研究指出，传统留出法在投资回测中可能并不可靠，并提出了 Probability of Backtest Overfitting，用于估计所选策略是回测过拟合结果的概率。
Deflated Sharpe Ratio 则尝试修正两类常见的绩效膨胀：
- 大量策略搜索形成的选择偏差；
- 收益分布的非正态性。
因此：
Agent 越擅长生成策略，系统越需要记录它一共尝试过多少次。
只保存最好的一次回测，会让 Agent 变成一台高效率的“假 Alpha 制造机”。
Loop 的目标不应是：
不断寻找更高的历史 Sharpe而应该是：
不断提出可证伪假设
→ 用统一协议验证
→ 记录全部失败
→ 淘汰不能泛化的策略真正有价值的循环，不是不断生产策略，而是不断压缩错误策略的生存空间。
三、Q-Loop 3×8×5：自进化量化的系统框架
为了把 Loop Engineering 转化为可执行的量化系统，可以使用一套 Q-Loop 3×8×5 框架：
- 3 个系统平面
- 8 个自进化子循环
- 5 个策略晋级等级
它解决三个核心问题：
- Agent 在哪里可以自主？
- 哪些判断必须由确定性程序完成？
- 一个策略如何从想法逐步获得资金权限？
四、三个系统平面：研究、执行、治理必须分离
1. Research Plane｜研究平面
研究平面负责发现机会。
Agent 可以深度参与：
- 阅读市场与另类数据；
- 搜索论文；
- 提出市场假设；
- 生成特征；
- 编写策略代码；
- 运行回测；
- 分析失败原因；
- 创建下一轮实验；
- 生成研究报告。
研究平面允许探索，也允许失败。
因为研究错误不应直接触达真实资金。
2. Execution Plane｜执行平面
执行平面负责将已批准策略转化为订单。
它应该尽可能确定性：
已批准策略版本
→ 确定性信号引擎
→ 结构化订单意图
→ Pre-trade Risk Gateway
→ OMS
→ Broker
→ 成交对账
→ 持仓账本实时执行阶段，不应由 LLM 临场决定：
- 突然扩大仓位；
- 临时更改止损；
- 修改最大滑点；
- 跳过风险检查；
- 因一条新闻更改生产策略；
- 在异常状态下继续下单。
研究可以使用自然语言，订单必须使用结构化协议。
3. Governance & Risk Plane｜治理与风险平面
治理层独立于研究 Agent 和执行程序。
它至少负责：
- 策略版本注册；
- 数据版本管理；
- 权限控制；
- 策略晋级；
- 最大资金规模；
- 单标的仓位限制；
- 行业与因子暴露；
- 订单价格和数量校验；
- 日内亏损限制；
- 最大回撤限制；
- 重复订单防护；
- 异常停机；
- Kill switch；
- 审计与回滚。
核心关系是：
Agent 提出
程序验证
治理授权
风险否决风险层必须拥有最后否决权。
三平面架构
| 系统平面 | 核心职责 | 是否允许概率性判断 | 是否可接触真实资金 |
|---|---|---|---|
| Research Plane | 提出假设、生成代码、运行实验 | 是 | 否 |
| Execution Plane | 生成信号、管理订单、成交对账 | 尽量否 | 是 |
| Governance & Risk Plane | 权限、限额、审批、阻断、审计 | 规则必须确定 | 拥有最终控制权 |
一句话概括：
研究可以自主，执行必须确定，风险必须独立。
五、八个子循环：不要设计一个“大而全”的 Agent
一个能够长期运行的量化系统，不应该只有一个万能 Agent。
它应该由多个职责清晰、权限隔离的子循环组成。
Loop 1｜数据治理循环
目标不是“拿到数据”，而是确保数据能够被安全用于研究。
流程：
数据拉取
→ 数据版本化
→ 多源校验
→ 缺失值检测
→ 时间戳检测
→ 复权处理
→ Point-in-time 检查
→ 数据快照发布必须重点识别：
- Look-ahead bias；
- Survivorship bias；
- 财务数据发布日期泄漏；
- 拆股和分红处理错误；
- 退市样本缺失；
- 时区错位；
- 数据源中断；
- 价格异常；
- 历史数据被供应商修订。
输出不能只是一个 DataFrame。
应生成：
dataset_id
dataset_version
source_manifest
quality_report
data_hash
known_issues没有通过数据验证的数据，不得进入研究循环。
Loop 2｜假设生成循环
好的量化研究不是从指标开始，而是从可证伪的市场假设开始。
每个假设至少回答：
- 为什么可能存在这项收益？
- 谁在为这项收益付费？
- 这种行为为什么不会立即消失？
- 它在什么市场状态下会失败？
- 什么证据可以证明这个假设错误？
标准 Hypothesis Card：
hypothesis_id: momentum-liquidity-001
economic_rationale: 投资者反应不足造成中期价格延续
expected_edge: 高流动性资产中的中期动量溢价
holding_period: 20-60 trading days
expected_failure_regime:
- sharp market reversal
- liquidity crisis
required_features:
- point-in-time price
- volume
- corporate actions
falsification_condition:
- cost-adjusted out-of-sample return <= benchmark
- performance concentrated in one historical regime先写假设，再看结果。
而不是先找到一条好曲线，再让 Agent 编一个故事。
Loop 3｜实验构建循环
实验循环负责把假设转化为可复现的研究对象。
每次实验必须绑定：
Hypothesis ID
Dataset Version
Code Commit
Parameter Set
Random Seed
Cost Model
Evaluation Protocol
Environment Version建议每次实验自动产生：
experiment.json
metrics.json
trades.parquet
equity_curve.parquet
validation_report.json
runtime.log失败实验不能删除。
测试集不能在看完结果后重新定义。
验证门槛不能因为结果不好而临时修改。
实验记录不是副产品，而是自进化系统的训练数据。
Loop 4｜确定性验证循环
验证器不应该让 LLM“感觉这个策略不错”。
所有可计算指标必须由确定性程序完成。
数据验证
- 是否使用未来数据；
- 是否存在训练测试泄漏；
- 是否使用 point-in-time 成分股；
- 是否正确处理退市、停牌和复权；
- 特征生成时间是否早于交易决策时间。
统计验证
- Out-of-sample；
- Walk-forward；
- Purged 或组合交叉验证；
- Deflated Sharpe Ratio；
- Probability of Backtest Overfitting；
- 多重假设校正；
- 参数敏感性；
- 收益集中度；
- Regime 稳定性；
- 最小有效样本量。
交易验证
- 手续费；
- 买卖价差；
- 滑点；
- 市场冲击；
- 借券成本；
- 换手率；
- 部分成交；
- 流动性约束；
- 策略容量；
- 执行延迟。
风险验证
- 最大回撤；
- Gross / Net Exposure；
- 单标的集中度；
- 行业集中度；
- Beta；
- 因子暴露；
- 尾部风险；
- 压力测试。
验证器只输出：
PASS
FAIL
NEEDS_REVIEW同时附带机器可读证据。
LLM 可以解释验证报告，但不能代替统计程序生成验证结论。
Loop 5｜独立审查循环
独立审查不是再算一次 Sharpe，而是审查研究过程。
Reviewer Agent 负责检查：
- 经济逻辑是否成立；
- 是否存在事后归因；
- 参数是否过度复杂；
- 是否隐藏失败实验；
- 是否反复查看测试集；
- 策略收益是否由少数交易贡献；
- 是否对某一市场阶段过度依赖；
- 是否存在更简单的基线模型。
生成者和审查者需要隔离。
但“隔离”不只是换一个模型。
真正的独立性包括：
- 审查者不能修改验证阈值；
- 审查者不能覆盖失败结果；
- 审查者读取的是结构化实验产物；
- 审查者不能获得券商写权限；
- 审查结果必须保留审计记录。
Addy 在 Loop Engineering 中也把 Maker 与 Checker 分离视为核心结构：一个 Agent 负责产生方案，另一个独立角色负责检查；但即使如此，“完成”仍然只是一个声明，不自动等于证明。
Loop 6｜策略晋级循环
通过回测，不等于获得实盘资格。
策略应该逐级晋升，而不是一步接入券商。
Research
→ Paper Trading
→ Shadow Mode
→ Limited Live
→ Governed Automation每一级都应有独立准入条件。
Loop 7｜实时风险循环
风险循环不应依赖研究 Agent。
它应该运行在独立服务中，持续检查：
- 策略版本是否已批准；
- 信号是否过期；
- 订单是否重复；
- 数量和价格是否异常；
- 市场数据是否过期；
- 仓位是否超限；
- 日内亏损是否超限；
- 风险暴露是否异常；
- 券商持仓与内部账本是否一致；
- 订单是否长时间未确认；
- 数据源或 Broker API 是否失联。
美国 SEC 的市场接入规则提供了一个重要的系统设计参照：风险控制应在订单进入市场前阻止超过预设信用、资金、价格或数量阈值的订单，也应识别错误和重复订单，并向监督人员提供及时的成交报告。
这不是说所有个人交易系统都直接适用相同法规。
但它说明了一条重要工程原则：
风险控制应在订单进入市场前生效，而不是出事后再让 Agent 解释原因。
Loop 8｜经验沉淀循环
交易结果可以触发学习，但不能直接修改生产策略。
错误机制：
发生亏损
→ Agent 自动增加一条规则
→ 立即修改生产策略这会导致：
- 追逐近期市场；
- 规则不断堆积；
- 策略复杂度失控；
- 对随机亏损过度反应；
- 历史拟合越来越严重；
- 生产系统无法复现。
正确机制：
异常事件
→ Lesson Proposal
→ 收集证据
→ 创建新假设
→ 运行新实验
→ 独立验证
→ 创建候选版本
→ Shadow
→ 晋级标准 Lesson Proposal：
lesson_id: lesson-20260710-001
event_type: execution_slippage
observed_behavior: 实际滑点高于模型预期
expected_behavior: slippage <= 8 bps
performance_gap: 17 bps
possible_causes:
- insufficient liquidity filter
- order participation too high
- stale quote
evidence:
- fill_report_id
- market_snapshot_id
confidence: medium
proposed_experiment:
- test lower participation rate
production_change_requested: false经验可以自动提出，但不能自动成为生产规则。
六、自进化的本质：版本晋级，而不是在线变异
很多人把自进化理解为：
Agent 观察市场，然后实时修改自己的交易逻辑。
这更接近不可控的在线变异。
真正可管理的自进化，应当建立在版本体系上：
Production Strategy V1
│
├── 继续稳定运行
│
└── 产生异常与经验
↓
Candidate Strategy V2
↓
独立回测与验证
↓
Shadow V2
↓
Limited Live V2
↓
晋级为 Production生产版本在运行期间保持冻结。
新经验只能进入候选版本。
任何变化都必须回答：
- 改了什么？
- 为什么改？
- 使用了什么数据？
- 通过了哪些验证？
- 谁批准了晋级？
- 出现问题如何回滚？
因此：
自进化不是一个策略持续改变，而是一个策略种群持续竞争。
七、先写 Goal Contract，再启动 Agent
Agent Loop 最常见的失败，不是不会执行，而是不知道什么叫完成。
模糊目标：
帮我找到一个高收益策略Agent 会不断搜索，直到找到一条历史曲线足够漂亮。
可执行目标必须写成 Goal Contract。
goal_id: us-equity-medium-momentum-v1
objective: >
在美国大盘股中研究经过成本调整后仍具有稳定性的中期动量策略
scope:
market: US Equities
universe: point-in-time large-cap universe
rebalance: weekly
holding_period: 20-60 trading days
required_data:
- point-in-time prices
- delisted securities
- corporate actions
- volume and liquidity
success_metrics:
deflated_sharpe_ratio: "> 0"
max_drawdown: "< 15%"
positive_oos_period_ratio: "> 60%"
annual_turnover: "< 800%"
risk_constraints:
max_single_position: "2% NAV"
max_sector_exposure: "25% NAV"
max_gross_exposure: "100% NAV"
statistical_requirements:
transaction_costs_included: true
survivorship_bias_controlled: true
multiple_testing_recorded: true
parameter_stability_required: true
resource_limits:
max_experiments: 100
max_runtime: 24h
max_agent_cost: 50 USD
stop_conditions:
- valid_candidate_found
- experiment_budget_exhausted
- no_improvement_after_20_valid_experiments
- data_quality_failure
approval_level: research_onlyGoal Contract 解决的是意图边界。
它不是告诉 Agent“怎么做”。
它告诉 Agent：
- 什么可以做；
- 什么不能做；
- 什么叫成功；
- 什么叫失败；
- 什么时候必须停。
八、每个循环都需要 Loop Contract
Goal Contract 管目标。
Loop Contract 管运行。
统一结构：
loop_id:
objective:
trigger:
inputs:
state_read:
tools_allowed:
tools_forbidden:
steps:
verifier:
success_condition:
failure_condition:
stop_condition:
max_turns:
max_runtime:
max_cost:
retry_policy:
rollback_policy:
outputs:
state_write:
escalation_policy:示例：
loop_id: hypothesis-experiment-loop
objective: >
在既定数据、成本和统计协议下验证候选市场假设
trigger:
type: queue
source: approved_hypothesis_queue
inputs:
- hypothesis_card
- approved_dataset_version
- evaluation_protocol
tools_allowed:
- read_approved_dataset
- create_worktree
- write_strategy_code
- run_backtest
- submit_experiment
- read_validation_report
tools_forbidden:
- place_live_order
- modify_risk_limits
- change_test_period
- delete_experiment
- overwrite_production_strategy
verifier:
type: deterministic
command: validate_experiment
success_condition:
- validation_status == PASS
failure_condition:
- data_quality_status == FAIL
- reproducibility_status == FAIL
stop_condition:
- valid_candidate_found
- max_experiments_reached
- cost_budget_exhausted
max_turns: 30
max_runtime: 4h
max_cost: 20 USD
outputs:
- candidate_strategy
- experiment_artifacts
- validation_evidence没有工具权限、失败条件和停止条件的 Prompt，不是 Loop，只是一条长期运行的愿望。
九、State 是循环的脊柱，但不能成为资金账本
长期 Agent 需要外部状态。
但不能把所有状态都塞进 STATE.md。
正确做法是按状态性质分层：
| 状态类型 | 推荐存储 |
|---|---|
| 研究目标 | Markdown / Git |
| Hypothesis Card | Research DB |
| 策略代码 | Git |
| 数据快照 | Object Storage |
| 实验参数 | Experiment DB |
| 回测指标 | Analytics DB |
| 策略版本 | Strategy Registry |
| 订单 | Transactional DB |
| 成交记录 | Immutable Event Log |
| 持仓 | Position Ledger |
| 风险阈值 | Independent Risk Store |
| Agent 当前摘要 | STATE.md |
| 经验提案 | Lessons DB |
STATE.md 可以记录：
# Current Goal
# Active Hypotheses
# Recent Valid Experiments
# Failed Experiments Summary
# Open Risks
# Pending Reviews
# Recommended Next Actions但真实仓位、资金、成交和订单状态必须存放在具有事务、并发和审计能力的系统中。
Markdown 可以保存认知状态，不能保存资金真相。
十、Agent 团队：按责任分工，而不是按模型品牌分工
建议至少设置以下角色：
| Agent / Service | 主要职责 | 允许工具 | 禁止工具 |
|---|---|---|---|
| Orchestrator | 拆解目标、分配任务、管理状态 | 任务队列、状态库 | Broker 写操作 |
| Data Agent | 数据获取与质量检查 | 数据源、数据仓库 | 修改策略 |
| Hypothesis Agent | 生成可证伪假设 | 论文、研究库 | 查看隐藏测试结果 |
| Experiment Agent | 编写策略、运行实验 | Git、计算环境 | 删除失败实验 |
| Deterministic Verifier | 计算统计与风险指标 | 固定验证代码 | 自主修改阈值 |
| Reviewer Agent | 审查逻辑与实验设计 | 只读实验产物 | 修改回测结果 |
| Promotion Governor | 判断策略是否晋级 | 策略注册表 | 直接下单 |
| Risk Sentinel | 阻断违规订单、触发停机 | OMS、持仓、风险状态 | 修改研究代码 |
| Execution Service | 提交并管理订单 | Broker API | 修改风险限制 |
| Archivist Agent | 汇总经验、维护研究记忆 | 实验库、Lessons DB | 修改生产策略 |
不要简单地认为：
强模型 = 审查者
弱模型 = 执行者真正重要的是：
- 上下文是否隔离；
- 工具权限是否隔离；
- 数据权限是否隔离；
- 验证规则能否被修改；
- 结果能否被覆盖；
- 操作是否可审计。
十一、MCP 解决连接，不解决治理
MCP 为 Agent 提供了标准化工具接口。
例如，Alpaca 官方 MCP Server 已经可以向 Claude Code、Cursor 等 MCP Client 暴露账户、行情、订单和持仓工具。其官方文档显示，服务包含多个交易和市场数据工具，并默认支持从 Paper Trading 环境开始。
这意味着 Agent 的确可以从：
分析市场继续走到：
调用订单接口但 MCP 只解决：
Agent 如何调用外部能力。
它没有自动解决：
- Agent 是否有资格调用；
- 订单是否符合策略版本；
- 是否为重复订单；
- 信号是否过期；
- 数量单位是否正确；
- 部分成交如何处理；
- 超时后订单是否已进入市场；
- 账户与内部账本是否一致；
- 异常时如何强制停止。
MCP 官方安全文档也将授权流程、攻击面和服务端安全控制列为核心问题。
因此：
MCP 是执行接口，不是风险闸门。
正确结构应是：
Agent
→ Order Intent
→ Policy Engine
→ Risk Gateway
→ OMS
→ MCP / Broker Adapter
→ Broker而不是：
Agent
→ MCP
→ Broker十二、订单必须是结构化意图，而不是自然语言
Agent 不应该直接发送：
“苹果动量不错，买入一些。”
标准订单意图应包含完整上下文：
{
"signal_id": "sig-20260710-001",
"strategy_id": "momentum-v17",
"strategy_version": "17.2.1",
"symbol": "AAPL",
"side": "BUY",
"target_notional": 10000,
"max_position_pct": 0.02,
"order_policy": "TWAP",
"valid_from": "2026-07-10T14:30:00Z",
"valid_until": "2026-07-10T15:00:00Z",
"reason_code": "MOMENTUM_ENTRY",
"idempotency_key": "mom-v17-AAPL-20260710"
}订单提交前，Risk Gateway 至少执行：
Schema Validation
→ Strategy Version Check
→ Signal Expiry Check
→ Idempotency Check
→ Asset Whitelist
→ Position Limit
→ Gross Exposure Limit
→ Sector Exposure Limit
→ Price Deviation Check
→ Liquidity Check
→ Daily Loss Check
→ Broker Submission任何一步失败，都不能进入 Broker。
十三、五级晋级：让策略逐步获得资金权限
Level 0｜Research Only
Agent 只能：
- 读取历史数据；
- 创建假设；
- 编写策略；
- 运行回测；
- 生成研究报告。
没有交易账户写权限。
Level 1｜Paper Trading
接入模拟账户。
验证重点：
- 信号是否按时产生；
- 订单状态机是否正确；
- 是否出现重复订单；
- 持仓计算是否正确；
- 服务异常后能否恢复；
- 数据、订单和成交能否完整审计。
Paper Trading 不是验证 Alpha。
它主要验证系统能不能正常工作。
Level 2｜Shadow Mode
系统使用真实行情产生真实订单意图，但不实际提交。
重点比较：
- 理论价格与可成交价格；
- 回测滑点与真实滑点；
- 订单产生时延；
- 流动性；
- 市场冲击；
- 真实交易时段限制；
- Corporate Action 和停牌事件。
Shadow Mode 是连接回测世界与真实市场的关键阶段。
Level 3｜Limited Live
使用小规模真实资金。
必须限制：
- 品种；
- 单笔金额；
- 总仓位；
- 交易频率；
- 日内损失；
- 最大回撤；
- 订单类型；
- 运行时间段。
此阶段的目标不是证明高收益。
而是证明：
系统在面对真实延迟、真实滑点、真实错误和真实资金压力时仍然可控。
Level 4｜Governed Automation
只有已批准、固定版本的策略可以自动运行。
Agent 可以：
- 监控异常；
- 生成报告；
- 提出新假设；
- 创建候选版本；
- 建议暂停策略。
Agent 不可以：
- 在线修改生产策略；
- 提高自身资金权限；
- 修改风险阈值；
- 关闭审计；
- 绕过 Risk Gateway；
- 自动将候选版本升级到生产。
十四、最小可行系统：先构建研究闭环，不要先接券商
对于交易员或一人量化团队，第一版不需要同时完成所有模块。
第一阶段：可复现研究闭环
先完成：
Goal Contract
→ Hypothesis Card
→ Data Version
→ Experiment Runner
→ Deterministic Verifier
→ Experiment Registry验收标准：
- 同一实验可以重复得到相同结果；
- 失败实验不会丢失；
- 每个指标都能追溯到代码和数据；
- Agent 无法修改验证门槛；
- Agent 无法删除不利结果。
第二阶段：自进化研究闭环
增加：
Failure Analysis
→ Lesson Proposal
→ Next Experiment
→ Candidate Version验收标准：
- Agent 能根据失败证据生成下一轮假设；
- 不会直接修改生产版本；
- 每项经验都有证据与置信度；
- 搜索次数被完整记录；
- 达到预算后能够自动停止。
第三阶段：Paper 与 Shadow
增加：
Real-time Data
→ Signal Engine
→ Order Intent
→ Risk Gateway
→ Paper / Shadow Execution
→ Reconciliation验收标准：
- 重复运行不会重复下单；
- Broker 超时后能够确认订单真实状态；
- 内部持仓和 Broker 持仓可以自动对账；
- 过期信号不会执行；
- 数据过期会触发 Risk-off。
第四阶段：Limited Live
只有当前三个阶段稳定后，才进入小资金实盘。
在此之前：
不要把“能连接券商”误认为“已经具备实盘能力”。
十五、一个 Agent 可以直接读取的项目目录
quant-loop/
├── goals/
│ └── goal-contract.yaml
├── hypotheses/
│ ├── active/
│ ├── rejected/
│ └── validated/
├── skills/
│ ├── data-governance/
│ │ └── SKILL.md
│ ├── hypothesis-research/
│ │ └── SKILL.md
│ ├── experiment-builder/
│ │ └── SKILL.md
│ └── failure-analysis/
│ └── SKILL.md
├── datasets/
│ ├── manifests/
│ └── quality-reports/
├── strategies/
│ ├── candidate/
│ ├── shadow/
│ └── production/
├── experiments/
│ ├── registry/
│ ├── results/
│ └── failed/
├── validators/
│ ├── data/
│ ├── statistics/
│ ├── costs/
│ └── risk/
├── execution/
│ ├── signal-engine/
│ ├── order-intent/
│ ├── oms/
│ └── broker-adapters/
├── risk/
│ ├── policies/
│ ├── gateway/
│ └── kill-switch/
├── lessons/
│ ├── proposals/
│ └── approved/
├── state/
│ ├── STATE.md
│ └── PROGRESS.md
├── reports/
└── audit/并行实验可以使用独立 Worktree，避免 Agent 同时修改同一策略文件；Claude Agent SDK 也提供了可编程的 Agent Loop、文件操作、命令执行与上下文管理能力。
但要注意：
Worktree 解决的是代码文件冲突，不是交易状态并发、数据库事务和订单幂等问题。
十六、上线前的强制验收清单
研究层
- 所有实验拥有唯一 Experiment ID
- 数据、代码、参数和环境均可追溯
- 失败实验不可删除
- 测试集不能被研究 Agent 修改
- 实验搜索次数被记录
- 交易成本已经纳入验证
- 过拟合风险已经评估
- 策略具有经济解释和失效条件
Agent 层
- 每个 Agent 拥有最小工具权限
- Maker 与 Checker 已隔离
- Agent 不能修改验证阈值
- Agent 不能覆盖审计日志
- Loop 设置最大轮数、时间和成本
- 异常任务进入人工队列
- 所有外部写操作支持幂等
执行层
- 所有订单来自已批准策略版本
- 信号包含过期时间
- 订单拥有幂等键
- 重复订单能够被阻断
- 订单状态机处理部分成交
- Broker 超时后进行状态确认
- 内部账本与 Broker 定期对账
风险层
- Risk Gateway 独立于 Agent
- 风险规则由确定性程序执行
- 数据过期时自动停止新订单
- 日损失和最大回撤能够阻断交易
- Kill switch 可人工触发
- Kill switch 不依赖 LLM
- 系统可以撤销未成交订单
- 系统可以快速进入 Risk-off
只要其中任何关键项未通过，系统就不应进入自动实盘。
十七、对交易员与 Agent Builder 的真正启发
对交易员
未来的竞争不只是：
谁能想到一个更好的因子。
而是：
谁能建立一套更高质量的假设生成、实验验证和失败沉淀系统。
交易员的工作会逐渐从：
亲自完成每一次研究转向：
定义研究方向
设计验证标准
管理风险边界
审查策略晋级你的核心资产不再只是一段策略代码。
而是一套：
- 数据治理标准；
- 实验协议；
- 验证器；
- 经验库；
- 策略注册表；
- 风险系统；
- 晋级制度。
对 Agent Builder
一个真正的量化 Agent，不是一个“会分析股票”的聊天机器人。
它必须具备：
Goal
+ State
+ Tool
+ Verifier
+ Stop Condition
+ Permission Boundary
+ Audit
+ RecoveryClaude Code 的 Hooks 提供了一种重要工程思路：对必须稳定执行的行为，使用确定性 Hook，而不是期待模型每次都主动记得执行。
映射到量化系统中：
- 数据质量检查应该是 Hook；
- 验证器应该是 Hook；
- 风险检查应该是 Gateway；
- 订单审计应该是强制事件；
- Kill switch 应该是独立服务。
不要用更多提示词代替系统约束。
结语：你不是在写一个策略，而是在设计一个会做研究的组织
Loop Engineering 对量化领域最大的价值，不是自动下单。
而是让一个交易员能够设计出一个持续工作的研究组织：
Data Agent 维护数据
Hypothesis Agent 提出想法
Experiment Agent 运行研究
Verifier 淘汰假结果
Reviewer 检查逻辑
Governor 管理晋级
Risk Sentinel 保护资金
Archivist 沉淀经验这套组织可以持续工作。
但它不应该拥有无限自由。
真正成熟的自进化量化系统，必须同时具备两种相反的能力：
在研究环境里，它应当尽可能开放，快速试错。
在生产环境里，它应当尽可能克制，严格执行。
所以，最终的系统原则不是：
让 Agent 替你交易。
而是：
让 Agent 持续提出和淘汰策略，让确定性系统管理订单，让独立风险层守住资金。
交易可以自动化。
研究可以自进化。
但资金权限，永远不应该由一个正在生成下一句话的模型自行决定。
参考资料
- Addy Osmani：《Loop Engineering》，提出 Automation、Worktree、Skill、Connector、Sub-agent 与外部 State 组成的循环工程结构。
- Anthropic：Claude Agent SDK 与 Hooks 官方文档。
- Model Context Protocol：官方安全最佳实践。
- Alpaca：官方 Trading MCP Server 文档。
- Bailey、Borwein、López de Prado、Zhu：《The Probability of Backtest Overfitting》。
- Bailey、López de Prado：《The Deflated Sharpe Ratio》。
- SEC：Rule 15c3-5 市场接入风险控制说明。