骑士资本4.4亿美元崩盘始末：遗留代码激活引发的量化灾难

2012年8月1日，美国做市商骑士资本的交易系统在开盘后的45分钟内，于154只股票上错误执行了超过400万笔交易，涉及近4亿股，最终造成4.4亿美元税前亏损。这个数字甚至超过了公司前一日约3.65亿美元的现金及等价物储备。一次看似普通的代码部署，最终把一家拥有成熟自动交易基础设施的公司推到了破产边缘。

这不是外部黑客攻击，也不是某个交易员在键盘前做出了错误判断。事故起因藏在更安静、也更容易被忽略的地方：8台服务器中，有1台没有成功更新；一个早已退出实际使用的遗留测试算法，仍然留在系统里；一个曾经用于测试的标志位，被新代码重新使用；而多年以前一次系统重构，又让这段遗留算法失去了原本的安全限制器和订单反馈机制。

我们常说，量化交易的核心是策略、数据和执行。但骑士资本的经历提醒我们，真正托住这三者的，是那些不容易被写进策略回测报告里的工程边界：版本是否一致，旧代码是否真正删除，异常行为能否被及时截断，系统是否知道自己已经偏离了预期。

一次手动部署，为什么会变成系统性事故

2012年7月27日至31日，骑士资本的IT人员为其自动路由系统SMARS部署一套用于对接纽约证券交易所零售流动性计划的新代码。部署目标是8台服务器，操作方式却是手动完成。

手动部署本身并不必然意味着危险。许多交易系统在特定时期仍然需要人工参与，尤其是在遗留架构、权限隔离和业务环境复杂的机构中，自动化部署也未必能覆盖所有场景。真正的问题在于，手动操作之后是否存在足够独立、足够严格的复查机制。

骑士资本的8台服务器中，第8台没有成功更新，继续运行着旧版本代码。表面看，这似乎只是一个版本不一致的问题；但在自动交易系统里，版本不一致从来不是单纯的运维瑕疵。只要请求可能被路由到不同服务器，交易指令在不同节点上获得不同解释，系统就不再是一个统一的系统，而变成了几个拥有不同记忆的系统共同接收市场指令。

新代码复用了此前用于激活遗留测试算法“Power Peg”的标志位。这个标志位原本属于旧的测试逻辑，在新代码中被重新赋予了用途。问题是，第8台服务器仍然保留着旧版本，于是当带有该标志的交易指令被发送到这台服务器时，旧系统并没有把它理解为新功能的一部分，而是唤醒了处于休眠状态的Power Peg。

这正是事故中最令人不安的一层：触发灾难的，并不是一条完全陌生的恶意指令，而是一个在不同版本系统里含义发生变化的普通标志。

在软件工程里，我们习惯把标志位看成轻量、灵活、便于兼容的工具。它可以打开某个功能，也可以临时切换一段逻辑。但在交易系统中，一个标志位实际连接着多层行为：订单生成、路由、反馈、风险限制和状态管理。只要其中一台机器对它的解释不同，整个交易链条就可能出现无法预期的分叉。

从这个角度看，骑士资本事故并不是“一个服务器漏更新”这么简单。它更像是一条由多个小缺口拼成的链条：

1. 部署没有覆盖全部目标服务器。

8台服务器中有1台仍运行旧代码，说明部署完成与部署成功之间缺少可靠的确认。

2. 缺少足够有效的复查机制。

如果存在独立的版本核验，理论上应当能够在新代码进入生产环境前发现节点差异。

3. 新旧代码复用了同一个标志位。

标志位在不同版本中的语义没有被彻底隔离，旧逻辑因此获得了被重新触发的机会。

4. 遗留代码仍然存在于生产系统中。

Power Peg虽然已经不再承担正常业务功能，但并没有被删除或从可执行路径上彻底隔离。

5. 旧算法的安全约束早已失效。

一次发生在2005年的系统重构，让Power Peg与原有的安全限制器断开，订单完成反馈机制也被破坏。

这些问题单独看，或许都像是可以在日常维护中被容忍的小风险。它们叠加在一起，却形成了一个没有人完整看见的触发器。

量化系统最危险的缺陷，往往不是某一处特别复杂，而是许多“暂时没关系”的小问题，恰好在同一个时刻彼此接通。

Power Peg：一段没有真正离场的旧逻辑

Power Peg最初设计于2003年，是一套用于测试的遗留算法。它并不是为当日真实交易准备的核心策略，而是属于系统生命周期中很容易被遗忘的那类代码：曾经有用，后来退出舞台，却没有被彻底清除。

对普通软件来说，遗留代码可能只是增加维护成本；对自动交易系统而言，遗留代码还可能保留着真实的市场权限、订单接口和执行路径。一段代码即使不再被业务人员主动调用，也不代表它不存在风险。只要某个条件、某个参数或某个标志位仍然可以到达它，它就依然拥有改变现实的能力。

这和人的心理状态有一点相似。我们以为一件旧事已经过去，是因为日常生活里不再谈论它；但只要相似的情境重新出现，沉没成本、锚定效应和未完成的情绪仍可能回来，要求我们用过去的方式做出反应。遗留代码也是如此，它不会因为被搁置就自动失去行为能力。

2005年，骑士资本进行系统重构，Power Peg与原有的安全限制器Throttle断开，同时，确认订单完成的反馈机制也遭到破坏。这里有两个关键变化。

第一，安全限制器不再有效。

一个交易算法并不是只由“产生订单”的部分组成。真正可靠的执行系统还必须知道：一次下单可以多快、多少、在什么条件下继续；当市场反馈异常时，是否应该停下来；当订单没有完成时，系统能否区分“尚未成交”“反馈丢失”和“请求根本没有被正确处理”。

Throttle的作用，正是为行为设置速度和数量上的边界。它不一定理解策略意图，却能够限制系统在单位时间内产生订单的规模。对于高频或自动化交易而言，这种限制不是附加功能，而是系统能够保持可控性的基础。

第二，订单完成反馈机制失效。

Power Peg激活后无法收到“订单已完成”的确认，于是系统不断认为自己还没有完成上一项任务，并以极高频率持续发送重复交易指令。它并不是因为突然形成了一个新的交易观点而不停下单，也不是因为策略判断出了某种极强的市场趋势，而是因为内部状态与外部现实之间失去了同步。

这类问题在自动交易系统中尤其危险。策略通常按照一个循环运行：

• 读取市场或订单状态；
• 生成交易动作；
• 接收执行反馈；
• 更新内部状态；
• 决定下一步动作。

如果最后两个环节断裂，系统就会陷入一种封闭的自我重复。它不再根据市场事实更新自己，而是根据错误的内部假设继续行动。此时，交易频率越高，错误扩散越快；系统越自动化，人的介入窗口越短。

我们有时会把算法失控想象成一种复杂的机器智能，好像它做出了超出人类理解范围的决定。但骑士资本的案例反而朴素得令人难受：系统没有“想错”，它只是失去了确认自己是否完成任务的能力，却仍然保留着继续执行的权限。

安全限制器为什么不能被当作附属组件

在策略研究阶段，研究员通常更关心收益曲线、胜率、最大回撤、换手率和容量；在生产环境中，真正需要被反复确认的，则是策略能否在异常状态下保持沉默。

一个完整的风险边界至少应当能够回答以下问题：

• 单个策略在单位时间内最多可以发出多少笔订单？
• 单个账户、单只股票和整个系统的订单数量上限分别是多少？
• 同一方向、同一价格、同一标的的重复订单是否会被识别？
• 当订单回报长时间缺失时，系统是等待、撤单，还是停止相关策略？
• 当成交数量、撤单数量或拒单数量偏离历史范围时，谁有权切断交易？
• 交易节点之间版本不一致时，系统是否允许继续接收生产指令？

这些问题看起来不如因子模型和预测算法有吸引力，却决定了系统是否拥有“边界”。边界并不是对策略能力的否定，而是给策略保留一个可以回头的空间。

45分钟里发生了什么：从异常订单到无法承受的损失

2012年8月1日开盘后，Power Peg被错误激活。由于安全限制器失效，订单完成确认机制损坏，系统开始以极高频率发送重复交易指令。

在短短45分钟内，错误交易扩展到154只股票，成交笔数超过400万笔，涉及近4亿股。这个规模已经不是某个单一订单、某个单一标的或某个交易员权限范围内的异常，而是整个执行系统被带入了持续扩散的状态。

这里最值得我们停下来思考的，不是“为什么没有人马上发现”，而是人在如此高速的环境里究竟还能发现什么。

当自动化系统每秒产生大量订单时，人类观察者面对的不是一条清晰的错误提示，而是一片由成交回报、拒单、撤单、持仓变化和市场价格组成的噪声。异常可能一开始只表现为某个统计指标轻微偏离：订单频率增加，某些股票上的成交数量不寻常，策略的预期库存逐渐失真。等到这些信号汇总成明显的资金损失，系统已经完成了大量不可逆操作。

这也是“人始终在环路中”并不等于“人可以及时控制系统”的原因。人可以拥有最终权限，却不一定拥有足够的时间、信息和认知带宽。

从行为经济学的角度看，交易团队在突发事故中还会面临另一种压力：锚定效应会让人倾向于相信最初的解释。比如，系统刚刚完成新功能部署，团队可能自然地把异常归因于新功能本身；如果监控界面没有直接显示某台服务器仍在运行旧代码，排查过程就可能沿着错误方向推进。

而沉没成本则会在另一个层面出现。团队已经投入了大量时间完成部署、测试和上线，面对异常时，人的本能并不总是立即停止系统，有时会先尝试局部修正、重启某个组件或等待状态恢复。对于普通应用，这种谨慎可能减少误操作；对于高速交易系统，继续运行本身就可能扩大损失。

当然，这并不意味着应该把责任归于某个具体的人。恰恰相反，事故暴露的是系统如何把人的有限注意力、组织流程中的默认假设和软件历史遗留问题放在了一条高速轨道上。

关键指标与事故链条

表格里的数字并不只是事故报告中的统计项。它们共同描绘出一个系统从“局部异常”走向“组织无法承受”的过程：一台服务器的差异，连接到一个旧标志；旧标志连接到遗留算法；遗留算法又因为限制器和反馈机制失效而不断重复；重复订单最终转化为巨额财务损失。

真正需要被修复的，从来不只是某一处代码。

量化系统为什么容易被遗留问题反噬

量化交易系统与一般软件产品有一个明显区别：它不仅处理信息，还会把信息转换成真实的市场行为。一个普通应用出现错误，可能是页面显示不正常、服务中断或数据错位；自动交易系统出现错误，则可能在错误被理解之前已经完成了大量委托和成交。

这种差异，让系统的“历史”变得格外重要。

一个交易平台往往经历过多次策略迁移、接口改造、服务器扩容、功能下线和权限调整。每一次重构都会留下某种兼容性安排，每一次临时测试都可能增加一个标志位，每一次功能下线都可能只是从业务界面消失，而不是从代码和生产权限中彻底移除。

随着时间推移，系统会形成一种类似地层的结构。表层是当前团队熟悉的新模块，中间层是仍在运行的旧服务，最底层则是一些几乎没有人愿意触碰、但仍然拥有执行能力的遗留逻辑。真正危险的，不是某一层本身，而是新旧层之间那些已经无人能够完整解释的连接。

骑士资本事故至少说明了四个常见的结构性风险。

1. 代码下线不等于功能消失

很多团队会把“当前业务不再使用”当作“可以暂时保留”。但对于交易系统，保留意味着继续承担被调用的可能性。

如果一段遗留代码仍然可以访问订单接口，仍然能够接收生产参数，仍然可能被某个标志位触发，它就不应被视为普通历史文件，而应被当作生产风险资产管理。

更稳妥的做法不是只在文档里写一句“已废弃”，而是让它在权限、编译、部署和运行层面都无法重新进入生产路径。否则，所谓废弃只是人的主观判断，不是系统状态。

2. 复用标志位会制造语义错觉

为了减少改动，工程团队有时会复用旧参数、旧接口或旧标志位。这样做在短期内看似高效，但它会让不同版本、不同模块对同一个信号产生不同理解。

新代码认为某个标志表示“启用零售流动性计划相关功能”，旧代码却把它解释为“启动Power Peg”。当这两种含义在同一生产环境相遇时，系统不会主动提醒自己：这可能是语义冲突。它只会按照各自的逻辑执行。

在交易系统中，标志位最好具备清晰的生命周期和唯一的语义归属。功能更换时，旧标志不应被默认视为可回收资源。它可能还承载着历史行为，而这些行为并没有随着文档更新自动消失。

3. 重构可能改变安全边界，而不是只改变代码结构

2005年的系统重构使Power Peg与Throttle断开，也破坏了订单完成反馈机制。这个细节特别值得重视，因为它说明重构的风险不只在于“新功能有没有跑通”，还在于原来隐含的保护关系是否仍然存在。

一个模块可能在旧系统里默认依赖另一个模块的限流、确认或状态校验，而这种依赖没有写在接口名称里，也没有被单独测试。当系统被拆分、迁移或重写之后，业务功能看起来仍然可以启动，原本的安全边界却已经悄悄消失。

这就像我们在交易中常常只关注策略能否产生信号，却忽略信号进入执行层之后还需要经过多少道确认。策略的逻辑是显性的，安全约束往往是隐性的；而事故通常从隐性部分开始。

4. 回测通过不代表生产可控

Power Peg本身属于测试算法。测试阶段没有暴露出生产事故，并不意味着它具备面向真实市场的安全性；更准确地说，测试算法被错误地放进了真实执行环境。

回测验证的是一组历史条件下，策略逻辑和数据处理是否符合预期。生产风控需要验证的，却是系统在异常条件下是否能够拒绝执行，包括：

• 数据反馈缺失时是否停止；
• 订单状态未知时是否暂停；
• 节点版本不一致时是否拒绝上线；
• 订单数量突然放大时是否自动熔断；
• 交易范围超出配置时是否拦截；
• 某个旧功能被意外触发时是否能被识别。

这两类测试不能互相替代。一个策略可以在历史数据上表现得很稳定，但它的执行容错仍然可能非常脆弱。

回测证明的是“策略在给定条件下如何行动”，风控要证明的则是“系统在条件失真时能否停下来”。

从4.4亿美元亏损到被收购：事故的财务与监管代价

骑士资本在事故发生前一日拥有约3.65亿美元现金及等价物，而事故造成的税前亏损达到4.4亿美元。这个对比非常直观：一次系统故障的损失超过了公司当时能够即时调动的现金基础。

这也是量化机构常常不愿意面对、却必须面对的现实——系统风险并不按照策略的历史波动率来发生。

一套策略可能长期表现稳定，单日风险指标也处于预设范围内，但如果执行层突然以错误频率下单，风险就不再是策略收益曲线上的波动，而是基础设施本身对市场发出了大量未经授权的行为。此时，最大回撤、夏普比率和胜率都失去了原本的解释力，因为系统已经离开了策略假设所在的世界。

事故发生后，骑士资本陷入资金危机，并在2013年被电子交易公司Getco LLC收购。美国证券交易委员会同年因其未能建立足够的风险控制措施，对骑士资本处以1200万美元罚款。

这1200万美元与4.4亿美元亏损相比，当然不是同一个量级。但监管罚款的意义并不只在金额，它明确指出：交易系统的风险控制不是企业内部可以随意取舍的工程习惯，而是市场基础设施的一部分。

当一个系统能够在45分钟内影响154只股票、执行超过400万笔错误交易时，事故就已经超越了单家公司内部的运维问题。它会影响交易对手、市场流动性、价格形成和其他参与者的风险判断。自动交易系统的边界，因而也成为市场秩序的一部分。

从组织治理角度看，骑士资本的结局还让我们看到一个容易被忽略的心理事实：技术事故的后果通常不是在代码提交的那一刻显现，而是在资金、信誉和组织选择不断收缩之后才完整呈现。

最初可能只是一次部署失败，随后变成紧急排查；排查没有及时阻止损失，就转化为流动性压力；流动性压力进一步影响公司能否继续承担交易和清算责任；最后，企业失去独立生存的空间。

我们会本能地把这种结果归因于某个“关键错误”，因为这样比较容易理解，也比较容易获得一种已经找到答案的安全感。但真正的系统事故很少只有一个原因。它更像一张由旧代码、流程缺口、监控盲区、权限配置和组织惯性共同织成的网。事故只是让这张网突然收紧。

今天设计自动交易系统，应该怎样重新理解“安全”

复盘骑士资本，并不是为了寻找一个可以简单复制的结论，也不是为了制造对自动交易的恐惧。我们真正需要做的，是把一些经常被推迟的问题重新放回设计中心。

部署必须能够证明“全部完成”

部署流程不能只记录“脚本执行成功”，而应当验证每一个目标节点是否运行了预期版本，包括：

• 代码版本和构建摘要是否一致；
• 配置文件是否一致；
• 关键依赖是否一致；
• 权限和环境变量是否一致；
• 节点是否真的加载了新逻辑；
• 新版本是否能够被回滚；
• 未完成更新的节点是否会自动退出生产流量。

尤其是人工参与的部署，最需要的不是更多口头确认，而是可追踪、可重复和独立的核验。部署者不能同时成为唯一的验收者。因为人在熟悉的流程里很容易受到确认偏误影响：当我们已经相信“更新应该完成了”，就更容易把没有明显报错理解成“系统已经正确”。

旧代码要有真正的退场机制

遗留算法管理不应停留在代码仓库的注释里。对于曾经能够生成真实订单的模块，系统至少需要清楚记录：

• 它由谁负责；
• 当前是否仍可执行；
• 可以接收哪些输入；
• 是否拥有生产权限；
• 触发条件是什么；
• 最后一次测试和审计是什么时候；
• 如果不再使用，何时、以什么方式删除或隔离。

一个算法如果已经退出业务，却仍然保留完整的生产执行能力，那么它并没有真正退出，只是暂时没有被看见。

在这个意义上，删除旧代码不是一种洁癖，而是一种风险治理。我们每个人都知道整理抽屉并不能解决所有问题，但当抽屉里放着仍然接通电源的设备时，整理就不再只是审美选择。

限流器和熔断器要独立于策略

策略自己说“我会控制订单数量”，并不能构成可靠的系统边界。限流和熔断应当尽可能位于策略之外，由独立模块执行，避免策略失控时连同风险控制一起失效。

可分层设置的边界包括：

1. 单次请求限制：

防止一条异常指令携带超出预期的数量、价格或标的范围。

2. 单策略频率限制：

控制某个策略在单位时间内能够发出的订单数量。

3. 单节点限制：

防止某台服务器因状态异常持续发送请求。

4. 账户与组合限制：

约束净持仓、名义金额、成交量和资金占用。

5. 全局系统限制：

当整体订单频率、撤单比例或成交分布异常时，能够暂停全部或部分交易。

6. 人工紧急停止：

保留清晰、快速、权限明确的人工停机路径，并定期演练，而不是等到事故发生时才寻找按钮。

这些限制不需要理解每一个策略的预测逻辑，却必须能够判断系统行为是否已经超出允许范围。它们的价值恰恰在于，即使上层算法没有意识到自己出了问题，底层边界仍然可以替人做出停止动作。

反馈缺失本身就是异常状态

Power Peg的问题并不只是“没有收到成交确认”，更严重的是系统没有把“没有收到确认”视为需要停止的异常。

在交易系统中，未知状态比明确失败更危险。明确拒单意味着系统知道动作没有完成；未知状态则可能让系统重复发送请求，以为上一笔动作只是延迟。

因此，订单状态管理不能只有成功和失败两个结果，还要处理：

• 回报延迟；
• 回报丢失；
• 部分成交；
• 重复回报；
• 撤单状态不确定；
• 交易所与本地状态不一致；
• 网络恢复后的状态重建。

当状态不确定时，系统应当进入一种保守模式，而不是继续用正常速度行动。所谓保守，并不是要求系统永远不交易，而是在事实未被确认之前，暂时收紧权限，让新的动作不能无限累积。

生产前测试要模拟“系统不相信自己”

许多测试围绕正常流程展开：数据输入正确，服务运行正常，订单回报及时，节点版本一致。可是事故通常发生在这些条件不再成立的时候。

更有价值的测试，应当主动破坏系统对环境的信任，例如：

• 让一台服务器保留旧版本；
• 让订单回报延迟或中断；
• 让同一请求被重复发送；
• 让某个废弃标志位重新出现；
• 让配置文件与代码版本不匹配；
• 让订单数量在极短时间内异常增加；
• 让监控系统收到不完整或互相矛盾的数据；
• 让负责交易的节点与风控节点短暂失联。

测试的目的不是证明系统在理想环境下能够工作，而是确认它在不确定环境下是否还能保持边界。

这也是我们在设计回测系统时常常忽略的部分。回测可以告诉我们某个因子、趋势跟踪策略或统计套利模型在历史条件下的表现，却不能告诉我们部署过程是否会遗漏服务器，旧标志位是否可能触发遗留代码，订单回报丢失后执行引擎会如何变化。

量化研究和交易工程需要相互尊重，却不能互相代替。研究员关心信号是否有效，工程师关心状态是否一致，风控人员关心损失是否可控。一个成熟的系统，需要把这三种视角放在同一张桌子上，而不是让其中一种视角代表全部现实。

事故之后，我们如何与自动化相处

骑士资本事故发生在2012年，但它提出的问题并没有随着技术升级自动消失。服务器更多了，部署工具更成熟了，监控系统也更复杂了，可系统复杂度往往会同时增加。新的服务、新的接口、新的策略和新的数据源，会继续把历史逻辑包裹在更大的结构里。

技术进步可以减少某些错误，却不会自动消除人的心理盲区。

我们仍然会受到锚定效应影响，相信上一次成功的部署方法仍然适用；仍然会因为沉没成本而不愿意关闭正在运行的策略；仍然会在面对复杂告警时选择最容易解释的原因；仍然会把“没有报错”误认为“没有问题”。

所以，风险控制不只是系统功能，也是一种组织中的自我和解：承认我们无法预见所有异常，承认代码会被遗忘，承认人在压力下会迟疑，承认一套看似稳定的系统也需要经常重新回答“它现在到底拥有什么权限”。

这种承认并不意味着悲观。恰恰相反，只有承认边界存在，我们才有可能真正建立边界。

对自动交易系统而言，最重要的能力未必是永远快速、永远在线、永远不漏掉机会，而是在无法确认自身状态时，能够停下来；在某个节点与其他节点不一致时，能够拒绝继续行动；在旧逻辑被意外唤醒时，能够把它隔离在真实市场之外。

这也是骑士资本4.4亿美元崩盘始末留给量化行业最深的一层提醒：灾难未必来自一个天才般复杂的算法，更多时候，它来自系统忘记了自己曾经经历过什么。

代码会留下历史，部署会留下假设，重构会留下没有写进文档的依赖，而市场不会因为我们暂时没有看见这些东西，就替我们保管风险。夜盘结束之后，我们或许可以重新检查那些看起来已经不再使用的模块，也重新问一问自己：当系统失去确定性时，它是否还知道自己的边界在哪里。

有些答案，只有在真正愿意停下来之后，才会慢慢显现。