量化策略：闭环在 C 端是体验，在 B 端是准入

本篇是 EasyQuant 量化策略交付平台技术博客的观点篇，承接「平台底座线」（00–23）、「机构能力线」（24–33）与「真实策略治理案例复盘」（34–38）。前几辑回答的是「EasyQuant 有什么、怎么用、跑出来怎么样」；本篇换一个更靠前的问题：同样是五个环节，为什么 C 端可以只做信号层，而 B 端必须做成闭环——以及一个真正的 B 端闭环，技术上到底难在哪里。

结论先行：市面上大量「四个环节空着」的系统，并不是没做好，而是 C 端那门生意本来就可以让用户兜底；B 端的形态是多策略 × 多账户 × 无人逐单确认，没有人可兜底，所以闭环是准入条件而非加分项。而 B 端闭环的真正门槛，不在「把五个模块做出来」，在于让五段共享同一套口径，并且口径一旦不一致就会响。

一、三个很好的问题，但答案取决于你在哪个市场

最近读到一篇关于 AI 交易 Agent 的综述解读，里面有一句话很扎心：

信号是入口，不是出口。

它把量化流水线拆成五段——因子挖掘、信号发现、组合构建、订单执行、风险管理——然后指出：这一波系统几乎全都挤在「信号发现」这一段，另外四段基本空着。

量化流水线：五个阶段

图 1：量化流水线五个阶段——行业注意力高度集中在第二阶段；真正的闭环要求五段全部打通，且口径一致。

作者给了一个很实用的判别法，三个问题：

信号出来之后，谁决定买多少？
下单走的是真实撮合，还是理想成交？
最大回撤到某个阈值时，谁在执行平仓？

三个问题只要有一个答不上来，它就不是交易系统，而是个信号生成器。

这三个问题问得很好。但我想补一句：它们在不同市场里的正确答案本来就不一样，而「不一样」不是水平差异，是生意差异。

把这件事想清楚，能解释很多看起来矛盾的现象。

二、C 端可以只有信号层，因为用户就是那四段

先说一句公道话：市面上大量「四个环节空着」的系统，并不是没做好，而是它们那门生意本来就不需要。

C 端消费级产品是这样运转的。用户说「我想买 100 块的某只股票」，或者说「帮我配一个绿色能源主题的组合」。产品把这句话变成一张配置单、一次下单。剩下的：

这 100 块怎么分配？用户自己说了算。
亏了怎么办？用户自己承担。
要不要止损、仓位多重？用户自认的风险偏好就是风控。

在这个结构里，用户本人就是「组合构建」和「风险管理」这两个环节。产品只需要把「想」和「做」之间的距离压缩到一句话，就已经完成使命。所以「AI 给建议、人来点确认」不是偷懒，而是一种正确且高效的分工——用户要的恰恰就是这个：把复杂的操作变简单，同时把决定权留在自己手里。

这也解释了为什么在 C 端，「四个环节空着」从来不是问题：它们在那个商业模式里本来就应该由用户承担。 你不需要一套账户级风控引擎，因为没有一个账户背后站着几百条策略；你需要的是一句听得懂人话的交互。

三、B 端不行，因为没有人可兜底

换到 B 端，同一个结构会立刻塌掉。

B 端的形态是多策略 × 多账户 × 多产品。一个交易日里，可能是几十条策略、上百个标的、几千笔委托在同时跑。没有任何人能坐在那里逐单确认。 你不可能把「这 100 块怎么分」这个问题交给每一位用户——因为服务这些策略的不是一个人，而是一整套系统。

于是前面那三个问题，在 B 端全部变成硬约束：

第一，组合构建不能靠偏好，必须可复现。 同一批信号、同一份行情，今天算出来的权重和明天算出来的必须一致。否则你无法回答一个最基本的问题：这个月赚的钱，是策略赚的，还是参数漂移带来的？B 端要给客户交代，就得让每一次权重计算都是可复算的。

第二，风控不能靠自我声明，必须是引擎。 C 端可以问用户「你的风险承受度是多少」，B 端不能问——因为承担风险的是一整个账户、一个产品，不是某个人当下的心情。B 端必须在每一笔委托发出之前，系统自己就知道：这笔单会不会撞穿单标的集中度上限、会不会超过账户当日额度、预算还够不够。

第三，执行不能「差不多」，必须可审计。 出了问题要能定位到是哪一段、哪一帧、哪个口径。这不是为了好看，是因为 B 端每一次偏差都要向客户解释。

把这三条合起来，就是一句话：

C 端可以让人兜底，B 端没有人可兜底。

所以，闭环在 C 端是加分项，在 B 端是准入条件。 这不是谁比谁强，是两门生意的门槛本来就不一样。

顺带也就回答了一个常见疑问：为什么真正把五段打通、并且口径前后一致的闭环比比皆是——因为它在 C 端不必要，而在 B 端极难。 稀缺来自难度，而不是来自没人想到。

四、同样是五个环节，两种做法

把上面两节落到每个环节上，差异一目了然：

环节	C 端（体验闭环）	B 端（决策闭环）
人在哪	用户逐次确认，随时可接管	没有人逐单确认，只有需人工解锁的熔断
组合构建	说出主题，生成一个组合	因子打分 → 排序 → 目标权重
风险管理	按用户自认的风险偏好自动调整仓位	下单前预检 + 预算预占 + 账户/产品级熔断
订单执行	转化为下单动作，「一句话成交」	单一收口 + 纸面/实盘分流 + 柜台能力校验
正确性由什么保证	产品体验与用户自行判断	由产品自己兜底（如「相同输入必然产生相同输出」）
前后口径	无需一致（每笔单都是一次独立意图）	必须一致（回测与实盘共用同一份内核）
一句话概括	让用户兜底	没有人可兜底

最后三行是关键。C 端的正确性，由用户体验和用户自己的判断来兜底；B 端的正确性，由产品自己来兜底。

五、B 端闭环的技术定义：口径一致

把五个模块都做出来、用流程串起来，那只是「接通」。真正的闭环还有第二个条件：同一件事，在五段里必须是同一个口径。

这句话听起来像常识，实践中却是最容易塌的地方。原因很简单——口径不一致几乎从不会报错。

举一个具体的例子。风控规则要算「这笔单占用了多少风险预算」，可以按名义金额算，可以按保证金算，也可以按数量算。三个口径都对，用哪个取决于规则本身的设计。问题出在别处：如果上下文里已经给了一个「算好的占用资本」，规则再乘一次保证金率，名义金额就被打了两遍折扣——

在期货上，这个错误会把敞口放大几十倍；而在股票上，乘数和占用率都等于 1，两种写法完全同值。

于是结果是：这个缺陷在股票市场没有任何痕迹，所有测试都是绿的。 只有当它跑到期货上，一笔小单突然撞穿了单标的上限，你才会第一次看见它。

这就是闭环里最贵的那一类问题：功能完全正确、任何测试都不会红，只有生产环境的审计才看得见。

同类的问题还有一串，它们长得都不一样，但性质完全相同：

取价有多个口径，选错不报错。 事件驱动的那一刻，驱动决策的行情快照本来就带在手上，不该重新取价；但要新价格的单子，必须按运行态能力分级取；批量估值要能批量、并且容忍缺失；历史回填必须显式指定时点。选错不会报错，只会静默地拿到另一个口径的价——然后拿这个价去比阈值、判成交。
失败会静默降级。 「取不到实时价」如果被写成「回落到昨天的收盘价」，对代码只是一行兜底，对业务却是把「没有价」悄悄变成了「用了一个错的价」。这类降级比直接报错危险得多。
口径漂移会往松的方向错。 风控限额从策略档迁到账户档，如果限额搬了、计数没搬，就会变成「用账户级的上限，配单策略的计数」——同一个账户下十几条策略，每条都能各自跑满账户额度。没有任何测试会红，只会在某一天集中爆发。

所以 B 端闭环真正的工作量，不在「把五个模块做出来」，而在于把这些口径差异一条条找出来、钉死，并且让它们一旦不一致就会响。

这部分不产生任何可见的功能。它是纯投入，也是门槛。

六、闭环为什么贵：可观测、单一收口、确定性

既然口径一致是纯投入，那它到底投入在哪？在 EasyQuant 量化策略交付平台里，主要落在三件事上。

第一，整条链路必须可观测。 一笔委托从信号产生到送去柜台，被拆成若干段独立计时。分段耗时相加约等于端到端耗时，残量不到 1 毫秒——这意味着链路上没有「黑盒段」。任何一笔单慢在哪、卡在哪，是能读出来的。做不到这一点，「闭环」就只是流程图上的闭环，不是可运维的闭环。

第二，下单必须只有一个收口点。 不管信号来自策略 DSL、事件驱动、手工操作还是组合调仓，最终都必须经过同一个下单入口。纸面/实盘的分流、柜台能力校验、风控预算的预占，全部发生在那一处。这样做只有一个目的：让「口径」只有一个定义点，而不是在每一条链路里各写一份。新增任何一道下单守卫，也只改那一处。收口越少，口径漂移的空间越小。

第三，策略求值必须是确定性函数。 「相同输入必然产生相同输出」不是一句愿望，而是一条写进测试的前提。因为如果引擎本身不是纯函数，那么用同样的 K 线数据跑两次都可能得到不同的信号——回测与实盘就永远对不上，闭环也就无从谈起。

在这三条之上，还有两条我认为最重要的设计约束：

回测和实盘必须共用同一份计算内核。 组合权重的计算，回测与实盘是同一个实现，而且有一条守卫专门盯着「回测侧不得出现第二份权重计算」。因为一旦有人另写一份，两条路径就会静默分叉——净值曲线照样好看，只是它和实盘已经不是一回事了。

刹车不能是自动的。 当账户或产品的阈值被触发时，系统的动作是固化成一个需要人工解锁的安全闸，而且它只阻断开仓、不影响平仓。这个设计是有意的：在极端行情里自动平仓，很容易把一次回撤变成一次踩踏。真正成熟的做法是「冻结加仓 + 交给人决定」，而不是「机器替所有人做最激进的减仓」。

这些事情没有一件是聪明的。它们只是必须有人愿意去做。

七、把三个拷问升级成五个

回到开头那三个问题。它们依然有效，但如果你面对的是 B 端系统，我建议再加两个：

第四个：同一个策略，回测和实盘用的是同一份代码吗？ 如果回测是一套实现、实盘是另一套「等价」实现，那么这两套实现迟早会分叉，而且分叉是静默的。判断标准很简单：改动其中一份的时候，另一份会不会跟着变？如果不会，它们就已经不是同一个策略了。

第五个：这条链路上，哪一步失败了会静默发生、不报错？ 这个问题最难回答，也最有价值。大多数系统能答「哪一步会报错」，但答不上「哪一步错了却不报错」。而后者才是真正会吃掉收益的部分——因为报错会被发现、被修复，不报错的错误会一直在那里，直到某一天以「策略突然失效」的形式出现。

这五个问题，建议放在同一张清单上问。前三个问「有没有」，后两个问「对不对得上」。

前者决定你是不是一个交易系统；后者决定这个系统能不能被托付。

结语

「可信投研一体化平台」这个词，很多时候被当成一句宣传语。但在 B 端的语境里，它其实有一个很硬的技术定义：从研究到执行，五段共享同一套口径；口径不一致时，系统会响，而不是静默。 这不是一个可以靠聪明解决的问题，只能由产品自己来兜底。

也正因为如此，闭环在 C 端是体验，在 B 端是准入——当你服务的系统里没有人可兜底时，闭环就不是一个卖点，而是一张入场券。