一笔明显大于簿口一档深度的订单，直接丢进市场会自己抬自己的价：吃穿几档之后成交均价比决策时的价格难看一截，这就是冲击成本。平台的算法委托是为这个问题设计的：TWAP 把总量按时间切成一串子单，在设定时间窗里分批执行；冰山单把大单藏起来，簿口永远只露出一个小额数量，成交掉多少就自动补多少。两类算法的目标一致——缩小成交价与你做决策那一刻价格之间的差距，但没有任何一种算法以更低价格为承诺。参数层面真正管用的是三件事。第一是时间窗或总时长：TWAP 把一小时执行完和把十分钟执行完，是两种完全不同的风险偏好——时间窗越长，子单越小越隐蔽，但你暴露在价格漂移里的时间也越长，行情一路单边时这种暴露会变成实打实的均价恶化。第二是参与率上限：算法每笔子单最多吃掉当前市场成交量的多大比例，防止你的执行节奏本身成为行情。参与率压得过低时，时间窗到了单子还剩一大截，算法只能以未完成收场，这是单边行情里最常见的失败模式，不是 bug。第三是价格限制：给算法画一条红线，越过就不再执行，它保护你不在失控行情里追价，代价同样是未完成风险。冰山单的隐蔽性也有限度。簿口永远只有一小笔，但连续不断补单的行为模式对老练的对手方是有信号的——补单间隔、每轮露出的数量、成交后的再挂速度，都在泄露总量信息。它降低的是你主动吃单时的冲击，不能阻止别人顺着你留在簿上的影子做判断。另一个常被忽略的差别是算法在哪里跑：交易所内置算法直接在你所在的那个簿上排队，享受本地队列位置，逻辑简单透明，代价是策略种类少；外部自建机器人可以跑更复杂的逻辑，但要多付一次往返延迟，还会触发 API 限速问题，小资金通常不值得。怎么用才合理：先量量订单相对市场的规模，用近期平均分钟成交量粗略换算，你的单子需要几分钟才能消化完，决定该不该动用算法委托；几千元规模的小单用市价限价就够了，硬上 TWAP 只是给自己加参数要调。用了算法，执行结束后一定要去回报里核对子单明细：每一笔子单的时间、价格、剩余量，确认实际完成率和均价，别被总进度条糊弄。算法参数是默认值最危险的地方，默认时间窗、默认参与率都是为平均水平设计的，跟你的单子未必匹配。相关参数与可用算法列表以各平台交易规则页为准。执行完之后还有一层成本核算值得做，它决定你下次用不用、怎么用。算法委托的真实成本要这样拆：决策时刻的参考价、执行结束后的成交均价、同期市场均价，三个数两两对比。成交均价对决策价的差是你的冲击成本加漂移成本，同期均价对决策价的差是纯市场漂移，两者相减才是算法替你省下的部分——多数小资金用户的真实结论是算法没省什么钱，只是把误差摊平了，这不是失败，是把决策成本变成了执行确定性，值不值取决于你的策略对哪个更敏感。回报核对时特别注意子单的时间戳分布：时间窗参数生效正常时，子单应大致均匀铺开，如果你的单子集中在前几分钟成交完，可能是簿的深度让每个子单都吃了太多、参与率没有起到约束作用，下次收窄子单上限。冰山单在单边行情里有额外代价：补单机制让它在同一个价位反复挂出，被探测方吃掉后你再补，等于在持续不利的价位持续挂卖，它保护不了你不在下跌途中接刀，需要配合价格限制一起用。最后是关于依赖度的提醒：算法委托是工具不是代理人，参数背后的逻辑要装在你自己脑子里。一个粗规则可以随身带：订单量占分钟成交量的比例在低个位数以内，手动限价分批就够；到这个比例的数倍，内置算法开始有意义；更大规模或跨交易对对冲，属于机构执行范畴，不该在零售界面上解决。本文仅解释交易所产品与机制结构，不构成投资建议、收益承诺或买卖建议；数字资产价格波动剧烈，相关交易可能造成本金损失，请自行评估风险承受能力。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。