平静的十五分钟，与突然放量的十五分钟，在普通图表上都只是一根十五分钟 K 线。但这两段时间里，市场发生的交易活动可能差得很远。

如果让成交量决定什么时候结束一根 K 线，再用它判断价格突破，结果会怎样？

这次就用“成交量时钟突破策略”做一个完整实践：把想法交给自己的 AI 助手，让它编写程序、读取回测结果、检查运行日志，再根据证据修改。过程中需要回答一个具体问题：换一种观察市场的节奏，是否真的改善了交易？

上期我们使用扩展 API 和策略同步码连接这条开发链路。这期沿用相同框架，改用 FMZ 的 MCP 接口。下面按接入、开发测试、运行巡检的顺序，把任务一步步交给 Agent。

一、先分清谁写代码，谁执行交易

Agent 是能够读写文件、调用工具、连续处理任务的 AI 助手。MCP 提供平台工具及参数说明，让它知道怎样读取策略、保存版本、提交回测和查询结果。

            text
            
            
提出交易想法
    ↓
Agent 编写策略与测试
    ↓ 通过 MCP
平台执行回测，返回结果和日志
    ↓
Agent 分析证据，修改后重新验证

部署以后，策略程序计算行情和信号，托管者运行程序并连接交易所。每次交易按照预先写好的规则执行。Agent 负责研究、开发和检查，也可以在明确的操作范围内完成更新。

定期巡检还需要客户端或外部调度器唤起 Agent。MCP 提供工具，调度器负责按时发起检查；本地项目保存源码、实验配置和记录。

这样，一条异常日志才能追溯到正在运行的版本，一次回测才能对应到当时使用的规则和参数。

大白话:
简单说就是，FMZ平台上的策略实盘作为程序化交易的主体。
让 AI Agent 负责策略开发、测试、迭代、评估、审核、监督实盘运行。

二、接入自己的 AI，先完成一次读取

打开 FMZ 首页，找到“把 FMZ 交给你自己的 AI agent”，点击“复制接入指令”。

把指令交给自己的助手，同时说明本轮范围：

            text
            
            
读 https://www.fmz.com/agent/setup.zh-CN.md 然后接入发明者量化

本轮申请全部权限。
接通后列出可用工具，核对权限，并完成一次只读查询。
暂不创建或启动运行实例。

• 让 Agent了解如何接入，如图：

  

• 点击 Agent 给出的授权链接：

  

按官方接入指南，Agent 申请授权后会给出确认链接。你在浏览器登录、核对权限并授权，它再完成连接配置。已有连接可以先检查是否可用。

截图中的工具数量是页面示意，实际以连接后的工具列表为准。接入是否完成，看工具能否成功返回数据；不能只看助手说了一句“配置好了”。

read、backtest、write 分别覆盖读取、回测和保存修改。后续创建、启停实例需要 trade，并明确实例、托管者和交易所对象。交易所 API Key 在平台网页中配置，Agent 使用已配置对象的 ID。授权可在 API Key 管理页面 调整。

本轮新建独立策略。接入阶段保存一次成功查询和工具范围的记录，后面的开发都围绕同一个策略 ID 展开。

三、把成交量时钟做成一项可复现的实验

先说清这个想法为什么值得测

普通十五分钟 K 线，到时间就结束。成交量 K 线则累计成交量，达到目标后结束。

假设某根柱的目标是 1,000 个成交量单位：每分钟成交 50 个单位，需要二十分钟；每分钟成交 250 个单位，四分钟就完成。这只是机制示意，实际目标由历史数据计算。

我们的假设是，成交集中出现时，更快更新观察区间，可能更及时地识别突破。相反的可能也要考虑：放量时价格已经走远，更快成柱带来更多假突破，新增收益不足以覆盖费用。

为了判断这件事，第一版采用简单、固定的突破规则，与普通十五分钟 K 线版本做对照。

明确第一版规则

策略名称为“成交量时钟突破”，英文 Volume Clock Breakout，简称 VCB。首轮研究 ETH_USDT.swap，使用已收盘的一分钟行情。

每根新成交量柱开始前，取此前完整二十四小时的成交量除以 96，作为这一根的目标量。96 对应一天包含的十五分钟区间数，用于初始尺度校准，不代表每天一定形成 96 根。

目标量在柱内保持固定。逐分钟聚合开、高、低、收和成交量，首次达到目标后完成一根。巨量分钟也只生成一根，不虚构分钟内的价格先后顺序，也不重复使用超额成交量。

这种方法称为“一分钟近似成交量 K 线”。成交量单位必须统一，不能混用币数量、合约张数和成交金额。

交易规则固定为：

下单数量按“账户权益 × 风险比例 ÷（止损价差＋每单位预计交易成本）”估算，再受最大名义金额限制，按数量步长向下取整。数量或保证金不足就显示原因，不自行放大预算。

信号确认时固定 ATR，按实际成交均价设置止损和目标，最长持仓从首次成交计时。开始交易前，要备齐二十四小时成交量基线、二十根历史柱及 ATR 所需数据；预热不足就等待。

通道不能包含当前柱。核心顺序如下，完整程序还需要数据、订单和风险处理：

            javascript
            
            
let signal = 0;
const prior = completedBars.slice(-20);

if (prior.length === 20) {
    const upper = Math.max(...prior.map(b => b.High));
    const lower = Math.min(...prior.map(b => b.Low));
    signal = closedBar.Close > upper ? 1
           : closedBar.Close < lower ? -1 : 0;
}

completedBars.push(closedBar);

先读取历史通道，再加入当前柱。如果当前柱也参与最高价计算，严格向上突破就无法成立。

信号确认后，使用下一次可获得的行情执行，不能假定成交在已经过去的收盘价。持仓的止损、止盈与超时检查独立运行，不等下一根成交量柱完成。

第一步：把需求交给 Agent

把本文作为需求说明发给 Agent，再附上下面的开发指令：

            text
            
            
请用 FMZ JavaScript 新建 VCB 策略，支持 ETH_USDT.swap。
按本文规则实现成交量柱版本，并提供十五分钟时间柱对照。
两版共用信号、仓位和退出代码，初始参数采用下文的回测配置。

检查行情周期、成交量单位、预热长度和交易数量规则。
重复分钟只处理一次；数据缺口未恢复时不新增仓位。
重启后恢复数据、订单和持仓状态，不补下过去的信号单。
下单结果不确定时先查订单，不直接重复下单。

图表显示突破通道；状态栏显示成柱进度、不交易原因、
订单持仓、账户权益和策略净收益。

先完成本地测试，交付源码、参数说明、测试结果和使用方法。
保存到平台后读回核对，记录策略 ID 与代码版本。
先不启动运行实例。

具体接口可查 GetRecords 文档。策略规则和测试条件都在本文中，接口文档用于查调用方式。

本地测试重点看三件事：同一份行情能否得到相同柱子；中途重启能否接着原状态运行；后续数据会不会改写之前的信号。检查新增仓位的条件时，已有持仓的退出处理仍要继续。

部分成交、重复回报和下单超时，要用本地测试单独检查。FMZ 回测采用吃单、全额成交撮合，无法覆盖部分成交；模拟的分钟内路径也不代表真实先后顺序。回测模式说明

• Agent 自己根据需求把策略设计好了：

  

第二步：先检查程序，再比较策略

先选开发区间内的一周做短回测，核对预热、成柱、信号、订单与收益账本。没有交易时查看逐级计数，并用确定性样本验证信号能否触发；不要为了制造成交而放宽真实交易规则。

程序流程正常以后，再执行正式对照。首轮建议使用以下固定配置，均为研究条件：

• 历史区间：2025-10-01 至 2026-10-01，按 UTC 的左闭右开区间处理。
• 前九个月用于开发；2026-07-01 起的三个月留作最后检查。
• 两版初始模拟资金均为 10,000 USDT，单笔计划风险比例 0.25%，最大名义金额 1,000 USDT。
• 初始费用假设为每边吃单 5 bp、滑点 2 bp，并追加两项均加倍的压力测试。它们是研究假设，实际费率另行核对。
• 开始日期之前另备预热数据。若取不到完整历史，先报告覆盖范围，重新固定实验区间。

1 bp 为万分之一。资金费用按历史持仓核算；数据缺失时，报告“未含资金费用”的结果，不把缺失成本写成零。

两个版本从同一份一分钟数据出发，时间柱按 UTC 十五分钟边界聚合。唯一主动改变的实验条件是成柱方式，仓位和退出共用实现。实际 ATR、仓位、持仓时长与交易频率可能随之变化，报告要一并列出。

            text
            
            
按已经固定的配置运行两种版本，记录每次回测 ID。
先完成开发区间及费用压力测试；代码与参数冻结后，再检查留出区间。

比较信号数、实际交易数、持仓时间、换手、毛收益、
手续费、资金费用、净收益和最大回撤。
分别列出数据缺失与撮合假设，不重复扣除引擎已计入的费用。

代码报错就读日志修复，最多三轮；每轮保存版本并用原条件重测。
不要根据留出结果继续调参，不自动挑选最好看的区间。

毛收益提高而净收益下降，需要检查新增交易的成本；开发区间改善、留出区间失效，需要检查结果对行情的依赖。若两版成柱结果异常一致，或者同一信号反复发单，先回到实现排查。

测试成功的标准包括程序正确、记录完整；策略有没有交易优势，则由扣除成本后的表现另行判断。

四、运行巡检：让异常有证据，让更新能核对

先观察，再验证订单与收益

历史测试之后，先运行只观察模式，确认实时数据、成柱和信号正常。随后使用明确指定的模拟交易对象验证发单与对账。

平台界面中的“实盘实例”是运行容器的名称，资金环境取决于连接的交易所对象。创建实例可能产生平台费用。策略里的“允许发单”开关，也不会把真实交易所变成模拟交易所。

启动前，将下面任务中的对象和预算补齐：

            text
            
            
使用我指定的托管者与模拟交易对象，启动已经核对的 VCB 版本。
先报告对象 ID、交易环境、参数、资金与订单数量检查结果。
按本轮明确的范围执行，不修改其他实例。

启动后读回版本、数据状态、订单、持仓和净收益。
记录发单、交易所确认、实际成交和撤单确认，不能把请求当成交。

状态栏保留五类信息：数据预热、成交量进度、信号与阻止原因、订单持仓、权益与策略收益。详细数据留在日志里。

如果没有交易，沿着这条路径定位：

            text
            
            
一分钟数据 → 完成柱 → 突破信号 → 执行检查 → 发单 → 成交

还没形成新柱，可能是在等成交量；形成了柱但没有突破，是信号未出现；有信号但未发单，再查数量、保证金、报价和待确认订单。不同原因分别统计，不合并成一句“条件不满足”。

收益分开核算已实现、未实现、手续费与资金费用，充值提现和其他策略损益不计入本策略。状态栏可刷新浮盈浮亏；收益日志在成交、持仓变化或资金费用入账等事件发生时记录。

模拟运行先验证系统行为。一天没有成交，不能据此判定策略有效或无效；少数成交也不足以证明长期收益。

把巡检变成实际执行的任务

先手动执行一次只读巡检，确认能够拿到状态和新增日志，再设置调度：

            text
            
            
每天 Asia/Singapore 时间上午九点检查指定实例。
核对运行版本、参数、托管者、交易所对象和数据状态。
从上次日志游标读取新增记录，报告各阶段计数、
未交易原因、订单持仓、费用与净收益。

将时间、证据和结论保存到本地项目。
这项巡检只读，不自动改参数、修改代码或重启实例。
创建后返回调度记录；执行后保留一次实际运行记录。

如果当前助手不支持调度，就用外部定时任务唤起。MCP 已接通与定时巡检已运行，是两项需要分别验证的事情。

用一次可复现的问题走完更新流程

实测中出现异常时，把原始数据和日志一起交给 Agent：

            text
            
            
根据这次巡检记录复现问题，说明证据对应的代码版本。
只修复已定位的问题，加入回归测试，用原配置重新测试。
报告修改内容、测试结果及仍未确认的事项。

需要更新运行实例时，先核对未完成订单和仓位处理方案，
再按本轮明确的范围保存版本、更新并重启。
重启后读回启动日志、实际版本、订单持仓和收益账本。

如果暂时没有发现故障，可以在本地回放中主动测试重复分钟、缺失分钟或中途重启，检查程序是否按设计处理。

新源码保存成功以后，还要确认运行实例确实使用了新版本。保留代码摘要、回测 ID、运行参数、日志和一条可复核的研究结论，下一轮才能沿着已有结果继续。

• Agent 启动并监督的实盘运行，无人工干预，如图：

  

此次研究的策略

此次AI进行闭环自行研究的策略源码公开：https://www.fmz.com/strategy/551039