OctoBot 项目研究站 · 交易模式
OctoBot 交易模式:六类自动化各自靠什么驱动
OctoBot 的官方 README 把可自动化的策略分成六类:网格靠固定间隔挂单吃波动,DCA 靠周期买入摊成本,加密篮子像买一篮子币的指数,TradingView 模式把指标或 Pine Script 的 alert 变成下单指令,AI 模式把行情上下文交给大模型征求观点,做市则单独放在另一个仓库。它们驱动器不同、外部依赖不同,下面把差异摊开。
- 一句话结论
- 六类交易模式的驱动方式不同:纯规则、外部信号与模型判断,对应的风险与排查方式也不同。
- 适合谁
- 已有明确行情假设、想找匹配模式并知道参数边界的人
- 不适合谁
- 指望模式名称本身带来收益的人
- 最后核验
- 2026-10-12(官方仓库与文档口径)
- 对应版本
- 3.0.0-beta3(2026-10-08)/稳定线 2.1.1
- 实测状态
- 未在本机运行 OctoBot:本站没有运行环境与交易所凭据,内容为官方仓库与文档核对 + 作者分析,不含本站实测数据
OctoBot 的六类交易模式怎么选:横向对照
先看驱动方式与外部依赖,再决定读哪一节。
| 模式 | 靠什么驱动 | 外部依赖 | 相对适合 | 注意点 |
|---|---|---|---|---|
| 网格 Grid | 价格在区间内来回波动 | 交易所与交易对 | 震荡行情中的机械化做区间 | 单边趋势里网格会持续反向成交,参数必须配合标的特性 |
| DCA | 按周期买入 | 交易所与交易对 | 长期分批建仓、摊薄成本 | README 同时提到可做短期或长期,参数差异很大 |
| 加密篮子 Basket | 一组币的加权涨跌 | 交易所;官方云另有现成篮子 | 想一次暴露多条赛道(如 AI、RWA 币) | 成分与再平衡规则决定实际表现,需自行确认 |
| TradingView | TradingView 指标或 Pine Script 策略的 alert | TradingView 账号与 alert 通道 + 交易所 | 已有成熟 TradingView 策略的人 | 链路变长(外部平台 → 机器人 → 交易所),排查点更多 |
| AI(ChatGPT 模式) | 大模型对行情上下文的判断 | OpenAI 账号,或本地 Ollama 服务器 | 想把主观判断交给模型、且能接受不确定性 | 模型输出不保证正确;本地模型省成本但需自备算力 |
| 做市 Market Making | 双边挂单提供流动性 | 独立仓库 OctoBot-Market-Making;官方另有自助平台 | 代币方/做市场景 | 不在主仓库内,部署与支持渠道都不同 |
| 信号输入(通用) | 技术指标(RSI / 均线 / MACD)与社交数据(Google Trends、Reddit) | 随数据源而定 | 给上述模式提供判断依据 | 社交数据噪声大,README 未给出有效性证明 |
OctoBot 的网格与 DCA 是怎么工作的
它们的共同点是驱动来源完全来自价格与时间,不需要外部信号。
| 维度 | 网格 | DCA | 注意点 |
|---|---|---|---|
| README 原文定位 | 从波动中提取价值,靠纯数学而非统计 | 定期买入以利用局部下跌、摊薄整体买入成本 | 两者都不是收益承诺,逻辑不同 |
| 核心动作 | 按固定间隔持续挂买卖单,两边成交即完成一轮 | 到点买入,不预测方向 | 网格依赖区间,DCA 依赖纪律 |
| 可配置程度 | README 称「可深度定制与优化,以适配市场与交易所」 | README 称「可高度定制,并支持短期或长期」 | 具体参数项以界面版本为准 |
| 典型失效场景 | 单边行情把仓位套在逆向一侧 | 长期下行中持续买入 | 都与标的选择强相关,需自行评估 |
| 能否先验证 | 可:内置回测 + 模拟盘 | 可:同上 | 回测仅手动实例可用(见回测页) |
| 本站立场 | 只解释机制,不给参数建议 | 同上 | 不提供任何收益或胜率数字 |
OctoBot 的加密篮子模式:像买指数一样买一组币吗
README 把篮子类比为股票指数或 ETF。
| 问题 | README 的说法 | 适用场景 | 注意点 |
|---|---|---|---|
| 篮子是什么 | 把多个加密货币一次买入的组合,类似指数或 ETF | 想一次暴露整个市场或某个方向 | 组合不降低系统性风险,只改变暴露结构 |
| 可以跟什么 | 整个市场,或分类方向(如 AI、RWA 币) | 按赛道做主题配置 | 分类口径由数据源决定,需自行确认成分 |
| 自定义篮子 | 支持自定义加密指数 | 已有自己的成分与权重想法 | 权重与调仓规则要自己定义清楚 |
| 现成篮子 | 官方云 octobot.cloud 提供一批加密篮子 | 想省去自己搭组合 | 云服务与开源版本是两种形态,条款不同 |
| 篮子模式的驱动 | 成分涨跌的加权结果 | 中低频持有 | 不预测方向,也不保证分散效果 |
| 与网格/DCA 的关系 | 三种模式可组合使用(node 模式支持多自动化) | 多策略并行 | 组合后的风险敞口需自己核算 |
OctoBot 怎么把 TradingView 与 AI 的外部判断接进来
这两类模式的共同点是交易决策来自 OctoBot 之外。
| 对比项 | TradingView 模式 | AI 模式(ChatGPT 交易模式) | 注意点 |
|---|---|---|---|
| 决策来源 | TradingView 指标或 Pine Script 策略产生的 alert | 大模型对行情上下文的观点 | 都不是 OctoBot 自己算出来的信号 |
| 外部账号 | TradingView 账号(README 链接带 aff_id 推广参数,本站不复制) | OpenAI 账号,或本地 Ollama 服务器 | 凭据都由你自己保管 |
| 成本结构 | 取决于 TradingView 订阅与 alert 额度 | 云端模型按调用计费;本地模型一次性投入算力 | README 提到本地模型的一个动机就是成本管理 |
| 可自动化范围 | 任意加密市场与交易所(README 表述) | 由该模式配置决定 | 取决于交易所支持范围(见交易所页) |
| 失败面 | 外部平台或 webhook 中断会导致信号断流 | 模型不可用、输出异常或幻觉 | 建议在模拟盘验证整条链路后再考虑实盘 |
| 本站立场 | 只说明机制,不评价信号质量 | 不评价模型判断能力,不提供任何趋势预测 | 所有内容仅供研究 |
怎么在 OctoBot 里配置一个交易模式:四步
具体字段随版本变化,这里给的是通用顺序。
选定模式
在 OctoBot 的配置流程里选择网格、DCA、篮子、TradingView 或 AI 模式。若列表里没有你想要的模式,多半是 tentacles 没有装全(见 Tentacles 页)。
选交易对与交易所
设定要交易的币对与目标交易所。能选到哪个所,取决于当前安装的交易所 tentacle(见交易所页)。
填参数与风险限制
网格填区间与间隔、DCA 填周期与金额、篮子填成分、TradingView 填信号来源、AI 填模型与提示上下文。README 强调这些模式都可深度定制——可配项越多,越需要先想清楚失效场景。
先回测,再模拟盘
用内置回测验证参数,再用模拟盘跑一段真实行情;确认行为符合预期后,才考虑让 OctoBot 用真实资金下单。
OctoBot 交易模式怎么选:不同行情下适合哪些模式、有哪些限制?
这是阅读项目机制后的选型框架,不是收益推荐;回测能力只在 manual 实例可用。
| 场景 | 可先研究的模式 | 选择理由 | 需要先验证 | 限制与注意点 |
|---|---|---|---|---|
| 价格在自设区间反复波动 | Grid 网格 | 固定区间与间距可将规则化买卖交给程序执行 | 边界、间距、手续费、极端突破后的剩余仓位 | 单边趋势可能使仓位累积在不利方向;不能把震荡假设当市场保证 |
| 按固定日程分批建仓 | DCA | 周期与金额规则明确,适合检查纪律化执行流程 | 周期、单次金额、总资金上限与长时间下跌情况 | 摊薄买入成本不等于避免亏损;资金需求可能随周期持续增加 |
| 需要按多个币种构成组合 | Crypto Basket | 将成分组合与权重作为一套自动化配置 | 成分来源、权重、再平衡规则及交易对可用性 | README 提及 Cloud 现成篮子;Cloud 价格与具体权限未核验 |
| 已有 TradingView 指标或 Pine Script 触发信号 | TradingView 自动化 | 可把既有 alert 流程接到执行侧 | Webhook 可达性、重复/延迟信号、触发后订单状态 | 链路依赖外部平台与网络;某环节中断可能漏掉信号 |
| 希望把行情上下文交给模型判断 | AI / ChatGPT 模式 | README 提及 OpenAI 与本地 Ollama 等接入方向 | 模型不可用、结构化输出异常、调用成本与拒答时行为 | 模型观点不是可靠性证明;需模拟验证,不能让未知输出直接越权执行 |
| 为代币提供双边流动性 | OctoBot-Market-Making 独立项目 | 做市不属于主仓库普通交易模式 | 单独核对项目部署、交易场所与做市风险 | 不要把主仓库支持列表或安装教程套用到独立做市项目 |
| 参数检查项 | 要确认什么 | 何时检查 | 注意点 |
|---|---|---|---|
| 区间与间距 | 网格下边界、上边界与每格间距是否与标的近期波动匹配 | 开启网格前 | 区间外单边行情会持续消耗一侧资金,需预设失效处理 |
| 单次金额与总上限 | 单次下单量、累计资金占用与最坏情况的余额需求 | 所有模式上线前 | DCA 的资金需求会随周期累加,不能只看单期金额 |
| 手续费与最小下单量 | 该交易所费率档位、交易对精度与最小下单量是否满足策略动作频率 | 网格与 DCA 类高频动作前 | 间距过小可能被手续费吃掉,且订单会因精度被拒 |
| 失效条件 | 突破区间、长期单边、模型连续异常时如何处理(减仓、停机或人工介入) | 模拟盘之前 | 没有失效条件等于没有退出机制 |
| 外部依赖可用性 | TradingView 信号或大模型不可用、延迟或重复触发时的行为 | 外部信号类模式上线前 | 链路中断会造成漏信号或重复执行,需在模拟盘验证 |
| 实例与权限 | 回测用 manual 实例、模拟与实盘用哪套 API Key、权限是否最小化 | 从模拟切到实盘前 | 提现权限始终不开启;密钥不进仓库与截图 |
OctoBot 网格与 DCA 的参数边界:调大调小分别会发生什么
两种模式的差别不在名字,而在参数怎么决定下单行为。下表按参数逐项列出影响与失效场景。
| 参数或机制 | 调大或调小会发生什么 | 失效场景 | 适用场景 | 注意点 |
|---|---|---|---|---|
| 网格上下边界 | 区间越窄,价格一离开就停止工作;越宽则单格间距越大、成交越稀疏 | 价格快速离开设定区间 | 区间震荡行情 | 边界按历史高低点设定,等于把未来信息带进参数 |
| 网格数量(单格间距) | 数量越多间距越小,成交更频繁但单格利润更薄 | 手续费高于单格利润时,成交越多亏得越多 | 低波动震荡行情 | 间距必须与费率一起算,不能只看成交次数 |
| 单格挂单量 | 决定每格买卖的规模 | 资金不足时触发下单失败 | 震荡行情 | 与总资金占用、交易所最小下单额冲突会被直接拒单 |
| 初始仓位 | 决定开盘即持有的比例 | 满仓开局在下跌行情里没有加仓空间 | 需要底仓的策略 | 底仓比例是资金管理决定,不是收益决定 |
| DCA 加仓触发条件 | 触发越松,加仓越频繁、资金消耗越快 | 单边下跌中资金很快用尽 | 分批建仓 | 触发条件与总资金上限必须同时设定 |
| DCA 止盈设置 | 止盈过近会被手续费吃掉,过远会回吐大部分浮盈 | 区间来回震荡时反复止盈又追高 | 波动较大的标的 | 止盈与加仓是同一套资金曲线,要一起调 |
| DCA 加仓次数上限 | 限制极端行情下的资金投入 | 次数过多会在长熊中让敞口失控 | 有明确资金上限的账户 | 次数上限要和可承受亏损一起算 |
| 与交易所内置网格的差别 | 内置网格由交易所托管执行;OctoBot 的网格跑在你自己的环境里 | 交易所侧规则或可用性变化会直接影响内置方案 | 想统一管理多策略的人 | 跨交易所与可回测是它的能力,代价是环境要自己维护 |
TradingView webhook 与 AI 模式的复现难点有哪些
这两类模式的共同点是判断来自外部:一个是 Pine 脚本的 alert,一个是语言模型。外部输入越不可控,回测越难覆盖。
| 环节 | 机制(依据官方说明) | 常见故障 | 排查与注意点 | 适用场景 |
|---|---|---|---|---|
| 信号生成 | TradingView 上的 alert 由脚本条件触发 | 条件写错、alert 未启用或未通知到外部 | 先用 TradingView 自身的通知验证 alert 会触发 | 已有可用 Pine 脚本的用户 |
| webhook 投递 | 由平台向你填写的地址发送 POST 请求 | 地址填错、被网络策略拦截、证书不被信任 | 先在本机用最小请求试投一次 | 需要接收端对外可达 |
| 接收与校验 | OctoBot 侧接收并按配置处理信号 | 路径或字段与预期格式不一致 | 对照官方文档的信号格式逐字段核对 | 所有 webhook 接入 |
| 下单执行 | 通过校验后由 OctoBot 发送订单 | 权限不足、低于最小下单额、余额不足 | 看订单请求与交易所错误码 | 实盘接入 |
| 重复触发 | 同一条件反复触发会重复下单 | 条件未做去重或状态判断 | 在脚本侧加状态与冷却时间 | 高频触发的条件 |
| 延迟与乱序 | 网络与交易所响应造成时间差 | 同一根 K 线内买卖信号互相打架 | 记录信号时间与成交时间对比 | 短周期策略 |
| AI 决策过程 | 由模型基于行情数据给出判断 | 相似行情可能给出不同结论,过程不可完全复现 | 把模型输出与人工判断分开记录 | 研究与探索 |
| AI 成本与频率 | 每次决策都可能产生调用费用与延迟 | 高频调用导致成本失控或超时 | 限制调用频率与标的范围 | 有明确预算上限的用户 |
| 本地模型与云端模型 | 本地运行模型与走云端接口是两条路 | 本地需要算力,云端需要 Key 与网络 | 按数据敏感度与预算选择 | 不希望数据外发到第三方的场景 |
OctoBot 交易模式常见问题:怎么选、能不能同时开
这些模式里有哪个更容易赚钱?
本站不做这种判断,官方也没有任何模式收益对比。README 只描述各模式的机制与可配置性,且免责声明明确要求自负盈亏。任何「某模式更稳」的说法都缺乏官方证据支撑。
网格和 DCA 能同时开吗?
node 模式支持从同一个 node 运行多个自动化(README 表述),因此并行使用在形态上是支持的。但并行意味着风险敞口叠加,需要自己核算总仓位与保证金占用。
AI 模式一定要用 ChatGPT 吗?
不一定。README 说明可以使用 OpenAI 的模型(例如 ChatGPT),也可以使用 Ollama 上的本地模型(llama 等)或自建模型,官方提到本地模型的一个动机是深度定制与成本管理。
TradingView 模式的 alert 怎么接?
思路是把 TradingView 指标或 Pine Script 策略产生的 alert 作为触发源,让 OctoBot 在指定交易所执行。具体配置字段与网络要求以官方指南为准;本站未做链路实测。
做市也能用这个仓库吗?
做市逻辑在独立仓库 Drakkar-Software/OctoBot-Market-Making,官方另有自助平台 market-making.octobot.cloud。主仓库 README 只给出入口与说明,本站未核验其代码细节。
社交数据(Google Trends、Reddit)算交易模式吗?
更准确地说它是信号来源,可以被策略模式使用。README 把社交指标与技术指标并列列为可用的分析输入,但未给出有效性证明;把它当作判断依据时需要自担风险。