简介TradeLink是国外基于C#开发的量化交易平台面向程序化交易与量化策略研究可用于行情数据处理、策略编写、订单管理和自动交易执行。平台适合量化方向学生、个人交易团队及有C#基础的开发者学习也可作为国外开源交易系统调研的参考。压缩包为zip格式大小约32.44MB资源页未给出文件总数和类型明细解压后可先查看目录结构具体构成以实际内容为准。已有461人学习说明该资源有一定关注度适合国内开发者作为了解TradeLink的入门素材。通过研读源码和相关材料可观察平台如何拆分数据分析、策略回测、交易执行等模块理解模块间接口与调用关系也能参考工程组织和异常处理思路为自研轻量级系统提供架构借鉴是一份适合量化爱好者和C#程序员收藏的资源。1. 国外基于C#的TradeLink量化交易平台先搞懂它在解决什么问题做量化的人翻开源社区十有八九会有个困惑Python 的框架一抓一大把可 C# 生态里能直接商用的交易框架却屈指可数。TradeLink常被简称为 TL算是其中一个绕不开的存在——它最早来自国外个人量化开发者社区目标是解决一个非常具体的痛点让 C# 交易策略和五花八门的券商接口彻底解耦你写策略的人不用天天问“到底连的是哪个柜台”只管把自己的信号逻辑放进独立的程序集其余下单、回报、持仓同步都交给框架去路由。我第一次接触 TL 时正赶上要给某跨平台系统接一个内部模拟柜台从编译到跑通只用了一个晚上但随之而来的配置细节、事件时序、订单状态机理解却是实打实啃了一个星期。这篇文章不从“什么是量化”讲起直接把你按在 TradeLink 前面告诉你这条路到底通不通、要过哪些坎、值不值得投入。适合两类人一是已经在用 C# 写信号但被接口绑定折磨的开发者二是想找一个不依赖 Python 的轻量级本地回测与实盘框架、愿意折腾源码的初学者。2. TradeLink 是个什么样的平台解耦、C# 原生、事件驱动2.1 核心设计思想策略与券商接口之间的“通用翻译层”很多人第一次看 TradeLink 的源码会懵因为它不像国内常见的商业量化平台那样给你一个“策略编辑器 行情面板 下单按钮”的成品界面它更像一个骨架——核心是一个叫做消息/事件总线的东西所有数据成交回报、行情 tick、委托状态都以标准消息格式在总线上流转策略只要实现对应的消息处理接口就能被框架认知并驱动。这个设计借鉴了事件驱动的消息模式也让它能和任意券商柜台对接前提是有人为那个柜台写一个“翻译适配器”。它的核心模块拆开来看大致是这样几条线TradeLink.Common包含基础类型比如证券代码、委托单、持仓结构、佣金模型TradeLink.API接口定义层规定了策略TradeLink与券商Broker之间通信的边界TradeLink.Research数据与回测工具你可以拿历史数据驱动同一个策略接口跑一遍验证信号有效性TradeLink Server / 通道组件负责具体的券商链路连接把柜台协议转成 API 层消息。我一般会建议新接触的人把你的策略看成一台“只会响应事件的机器”——它不主动问行情“现在多少钱”而是等待 tick 被推送过来。这个模型刚上手时很不适应因为大多数人写策略的直觉是“循环取数、算信号、下单”但事件驱动的好处是行情到达的瞬间触发计算和下单延迟低、代码结构也干净。需要特别说明的是TradeLink 并没有内置什么“必杀技”的策略库它给的是底层机制策略算法完全是你自己来实现。这也意味着如果一个平台宣传自己“基于 TradeLink 内置了上百种策略”那大概率就是挂个名字而已。2.2 为什么选 C#性能、类型安全与生态平衡点用 C# 写量化一直是个争议话题TradeLink 敢于站队 C#本身说明了几件事。其一C# 在 Windows/.NET 生态里属于“全能手”既能写高频风格的循环计算也能写复杂的业务逻辑不至于为了性能去碰 C 那套可怕的开发效率其二托管内存模型有 JIT 的加持在数据吞吐量不那么极端的场景下性能完全够用——处理几千只股票的分钟级信号计算、管理几百个并发挂单C# 没有压力。我做过一个粗略对比同样的均线策略实现C# 和优化过的 PythonNumPy 向量化在回测速度上差距并不大但如果涉及逐 tick 循环、订单状态机切换C# 甩开 Python 的可不止一个身位。另一个选它而不选 Java/Go 的现实理由是 Windows 桌面客户端和本地 Broker 接入的便利性。TradeLink 的原生形态长在 .NET Framework 与 Windows 环境里对 win-tap 类、COM 组件、以及很多柜台给的 Windows 动态库兼容性极好。哪怕在今天 .NET Core / .NET 6 跨平台已成趋势TL 的老版本依然保留了浓重的 .NET Framework 血缘你把它迁移到新版运行时就需要处理一些边界问题这部分后面会展开。如果你团队里已经有 C# 技术积累那么 TL 的学习成本主要在“理解它的消息约定”而不是重新学一门语言。这是它相对其它跨语言框架最大的吸引力。2.3 编译与最小启动30 分钟跑通一个本地模拟行情在动手写策略之前先把框架跑起来是关键一步。TL 的源码包在开源社区能找到下载后是一个标准解决方案里面按命名空间分好了若干工程。第一步是编译整个解决方案务必将输出目标平台设置为 x64。# 假设你已经在源码根目录下用 dotnet CLI 还原并构建 dotnet restore TradeLink_X.sln dotnet build TradeLink_X.sln -c Release /p:Platformx64这里的Platformx64很关键因为多数 TL 依赖的原生组件比如某些行情解码库或数据库驱动只有 64 位版本如果你用 x86 编译跑起来第一分钟就可能因为“试图加载格式不正确的程序集”而崩溃——这是第一个坑后面避坑章还会展开。编译成功后你要找到TradeLinkApp或TradeLinkServer的启动工程。通常框架会附带一个模拟数据源它可以从本地 CSV 或数据库读取历史数据并以限定速度“回放” tick让你在没有真实券商账号的情况下验证整个链路。我一般会这样做最小启动验证先启动 TradeLink Server打开后能看到控制台输出监听端口默认会在配置里写明再启动一个空白策略工程。空白策略什么信号都不发但会订阅全部 tick并把自己注册到服务器。如果服务器控制台出现“client connected”以及 tick 数量递增就说明链路通了。// 最小策略骨架注册、订阅、释放 using TradeLink.API; using TradeLink.Common; public class BlankStrategy : TradeLink.API.TradeLink { private readonly Response _response new Response(); public Response Response _response; public bool IsValid true; public string Name BlankStrategy; public void Reset() { } public void Start() { // 向服务器订阅所有品种的行情符号可用空串表示全部 Response.SendSubscribe(); Console.WriteLine(订阅全部行情等待数据…); } public void Stop() { } public void GotTick(Tick tick) { // 数据到位就打印验证链路是否通 if (tick.IsTrade) Console.WriteLine($收到成交tick: {tick.symbol} {tick.trade}); } public void GotOrder(Order order) { } public void GotFill(Fill fill) { } public void GotPosition(Position position) { } public void GotMessage(char msgType, long source, long dest, long msgid, string message) { } }这段代码最需要注意的地方是Response对象。它是策略与服务器通信的出口所有订阅动作都要通过它来发。GotTick里我判断了tick.IsTrade因为一份 tick 消息里可能同时包含买价、卖价、最新成交价等多个字段你要区分现在是盘口变化还是真实成交。初始跑通阶段看到买一卖一不断刷新也算正常别误以为只有成交消息才算通。每一步都能复制后直接跑通这个项目就算立住了。下一步是进入核心机制理解。3. 深入 TradeLink 的三大核心机制Tick流、订单路由与Broker适配3.1 Tick 驱动与事件回调为什么你的策略不能自己拉行情TradeLink 的消息驱动模型要求你彻底放弃“拉模式”的思维。很多从其它平台迁移过来的开发者在Start()里写一个 while 循环主动GetQuote()结果线程直接被卡死因为框架的消息泵不会等你。正确做法是订阅——你告诉服务器“我要这些品种”之后所有数据会以事件形式涌进你的GotTick。订阅粒度有两种按合约和按产品组。按合约就是精确到某个月份的主力连续比如螺纹钢主力按产品组则是一个品种的所有月份。写的时候要注意TL 的订阅字符串语法和某些国内柜台不一样用逗号分隔多个合约空串表示“全部”。同时订阅是累积制的如果你先订阅了“rb”后来又订阅“rb2510”系统会给你叠加推送而不是替换这一点特别容易引发“为什么我收了两份 tick”的困惑。// 细粒度订阅只订阅两个具体合约 Response.SendSubscribe(rb2510, rb2511); // 稍后取消订阅某个合约参数与订阅时完全一致 Response.SendUnsubscribe(rb2510);我见过有开发者在Reset()里做订阅在Start()里又做一次导致重复订阅成交回报变成双份平仓就能给你做出翻倍仓位。血泪经验是订阅动作只放到Start()里并且启动前先调一次Reset()清理状态。还有一个关键点GotTick回调是在框架的接收线程里执行的。如果你在回调里做耗时操作比如写数据库、跑深度学习推理会阻塞后续所有消息处理。正确姿势是把数据丢进队列业务线程去消费或者至少把耗时计算移到并行任务里。TradeLink 的架构是单接收线程和某些用多线程分发引擎的平台不同别做超出它性能预期的操作。3.2 委托生命周期与状态机从 New 到 Filled 的完整路径下单不是发出去就结束了。TL 把订单抽象成一个状态机每种状态对应不同的消息类型。下图是几个核心状态的流转不画图直接列在表格里状态含义触发条件New刚生成尚未发送策略调用SendOrderSubmitted已提交给券商/柜台服务器确认收到PartFilled部分成交有部分数量成交回报Filled全部成交剩余数量全部成交Cancel取消请求策略调用SendCancelRejected被柜台拒绝参数非法或风控拦截写策略时你要在GotOrder(Order order)和GotFill(Fill fill)两个回调里做状态同步。Order对象里有OrderStatus字段每次都会带着最新状态推给你Fill则只承载成交明细。如果你只在发单后等一个GotFill就以为完事会漏掉部分成交的场景。比如你下 10 手结果只成交了 6 手就撤单了此时你会依次收到PartFilled和Cancel状态如果代码里没有处理这两者持仓同步就错乱了。public void GotOrder(Order order) { switch (order.OrderStatus) { case OrderStatus.Rejected: Console.WriteLine($订单被拒: {order.symbol}, 原因可能在消息里); break; case OrderStatus.PartFilled: // 注意这里是剩余未成交的委托状态不是累计成交 Console.WriteLine($部分成交剩余: {order.Unsolicited}); break; case OrderStatus.Filled: // 全部成交 Console.WriteLine($订单完成: {order.id}, 价格 {order.price}); break; } }Order.Unsolicited这个字段非常容易理解错它代表的是“剩余未成交数量”不是已成交量。有同行在这个字段上吃过亏把剩余量当成交量传入风控模块结果仓位计算翻了天。参数意义上它等价于Order.CumFill的反面是 TL 里少有的几个有歧义的命名之一。3.3 Broker 适配层如何对接一个不在官方列表里的券商TradeLink 官方适配的券商主要是国外几家零售经纪商与模拟通道但真实项目里往往需要你自己对接一个私有柜台或国内通道。TL 在设计上预留了接口理论上你能用同一个TradeLink.API头文件实现自定义连接。最常见做法是写一个自定义的Broker 类让它实现Broker接口。核心要做的事情有两件一是把外部柜台的行情解码翻译成 TL 的Tick对象二是把 TL 的Order对象翻译成柜台的委托报文。public class MyCustomBroker : TradeLink.API.Broker { public void SendOrder(Order order) { // 将 TL 的订单对象转换为柜台报文格式 var req new MyExchangeRequest { Symbol order.symbol, Side order.side TradeLink.API.Side.Buy ? B : S, Price (double)order.price, Quantity (int)order.CumFill (int)order.Unsolicited }; // 假设 ExchangeClient 是你自己写的 SDK 封装 ExchangeClient.Submit(req); } public void SendCancel(Order order) { /* 调用柜台撤单接口 */ } }逻辑并不复杂坑都在细节上。比如 TL 的Order.side是一个枚举Side.Buy而柜台报文可能是 “B”/“S” 字符串再比如 TL 的价格类型是decimal柜台接口是double隐式转换会丢精度必须显式(double)且确认对方能接受小数位数。此外很多柜台有“只减仓”的撤单模式即撤掉剩余数量这时你必须把Order.Unsolicited当作撤单数量传给柜台而不是重新算。我自己的经验是写适配器时先把OnTick和OnOrder两个方向分别打通不要同时接行情又接交易否则出问题你分不清是数据源的锅还是委托链路的锅。先让 tick 打印在控制台再手动下一笔 1 手单全程跟踪控制台回报确认无误后再开放全功能。4. 写第一个可回测的策略订阅历史 tick、算信号、下单的完整通路4.1 数据准备把历史数据喂给 TL 的回放引擎TradeLink 的回测能力依赖历史数据回放你可以把它理解成一个“数据点播机”按固定节奏把存量 tick 重新吐给策略。数据源一般是 CSV 文件或数据库表列名需要满足 TL 的约定至少有时间和价格字段推荐包含 bid/ask/volume因为很多策略会在盘口上做文章。我第一次用的时候手头的 CSV 是导出的逐笔成交没有盘口数据不得已写了个小脚本把每分钟的买卖价模拟补上。后来发现 TL 其实可以只用成交数据跑策略但你一旦在回测里用tick.bid或tick.ask空字段就会变成 0信号逻辑直接崩。所以做数据准备时先确认策略里用了哪些字段回头把对应列都补全。# 数据文件路径一般在回放引擎的配置里指定 # 一个典型的数据行格式如下CSV # time,symbol,bid,ask,trade,volume # 2025-01-06 09:30:01.123,rb2510,3950.0,3951.0,3950.5,3TL 载荷数据的时间戳精度很关键。回放引擎常见的是TradeLink.Research里的SimBroker或配套的回放工具会按时间戳顺序推送如果你数据里有乱序或重复时间戳引擎会按原顺序硬推不会帮你排序。预处理脚本里宁可先按时间排序再输出也不要让脏数据混进回放。4.2 一个完整的均线策略实现含订阅、信号、下单我们以最简单的双均线突破为例跑通整个策略生命周期。策略逻辑当快线上穿慢线时市价买入 1 手下穿时市价卖出平仓。核心代码里你需要一个 tick 计数和两个均线缓存。public class MaCrossStrategy : TradeLink.API.TradeLink { private readonly Response _response new Response(); private readonly Queuedecimal _fastPrices new Queuedecimal(); private readonly Queuedecimal _slowPrices new Queuedecimal(); private const int FastPeriod 10; private const int SlowPeriod 30; private bool _hasPosition false; private decimal _lastFastMa 0m; private decimal _lastSlowMa 0m; public Response Response _response; public void Start() { _response.SendSubscribe(rb2510); } public void GotTick(Tick tick) { // 只用成交价作为信号源避开盘口缺失问题 if (!tick.IsTrade) return; decimal price tick.trade; _fastPrices.Enqueue(price); _slowPrices.Enqueue(price); // 队列长度控制慢线周期决定最大长度 while (_slowPrices.Count SlowPeriod) _slowPrices.Dequeue(); while (_fastPrices.Count FastPeriod) _fastPrices.Dequeue(); decimal fastMa _fastPrices.Average(); decimal slowMa _slowPrices.Average(); // 金叉且当前无持仓时开仓 if (_lastFastMa _lastSlowMa fastMa slowMa !_hasPosition) { Order newOrder new OrderImpl(tick.symbol, true, 1, 0); _response.SendOrder(newOrder); _hasPosition true; } // 死叉且持仓时平仓 else if (_lastFastMa _lastSlowMa fastMa slowMa _hasPosition) { Order closeOrder new OrderImpl(tick.symbol, false, 1, 0); _response.SendOrder(closeOrder); _hasPosition false; } _lastFastMa fastMa; _lastSlowMa slowMa; } public void GotOrder(Order order) { } public void GotFill(Fill fill) { } public void GotPosition(Position position) { } public void GotMessage(char msgType, long source, long dest, long msgid, string message) { } public void Reset() { _hasPosition false; } public void Stop() { } public bool IsValid true; public string Name MaCrossStrategy; }这个策略有几个值得说透的选型点信号只依赖tick.trade为了数据普适性放弃盘口字段。这在真实行情里会略微延迟信号触发因为 trade 的出现比 bid/ask 变化晚一拍但在回测阶段避免了字段缺失造成的坑。队列均值代替数组用Queuedecimal天然维护滑窗入队出队复杂度 O(1)不涉及数组拷贝写起来也直观。OrderImpl构造里的true/false它代表买卖方向。true是买入false是卖出。这里平仓用的不是“平今/平昨”而是直接反向开仓——TL 里你可以把卖出当作开空但如果你想平掉多单就要自己维护持仓方向比如用_hasPosition。何时更新_lastFastMa与_lastSlowMa我是在每次收到 tick 后都更新包括队列没满的时候。如果慢线队列还没填够初值可能全是 0会产生连续金叉死叉所以我假设Reset()时已经把两个初值设置成合理值。实际生产环境里你应该等慢线队列满 30 个后再启动信号判断避免启动阶段误下单。4.3 回测结果怎么看成交明细、滑点与手续费模型的坑跑完回测TL 会输出一份成交明细包含开仓时间、价格、手数和累计盈亏。但你直接看这份输出会过于乐观因为默认回放没有滑点和手续费。真实交易中市价单会在对手价附近成交且每笔都有佣金。TL 提供了手续费模型接口常见做法是在GotFill里截获成交价手动扣减手续费再把净值计算到策略外部。我习惯在回测时给市价单加2 个最小变动价位的滑点比如螺纹钢最小变动是 1 元/吨买入价就在信号价基础上加 2卖出价减 2。这个修正之后策略是否还能盈利才能作为是否上实盘的依据。另一个常被忽略的点是T1 与持仓过夜。TL 回放引擎默认允许你当天开当天平但在某些真实市场里这会产生平仓异常。如果你的策略日内平仓务必在回测配置里开启“禁止当日平仓”或“手续费按平昨收取”等规则。没有这个约束你回测中高频交易的利润可能会被现实中无法实现的规则变量蒸发掉好几成。这一章写到这里策略通路已经完成。下面进入这个框架真正劝退新人的环节——各种边缘错误和状态不确定带来的玄学问题。5. TradeLink 避坑指南C# 量化开发中常见的 5 个翻车现场5.1 编译通过但运行时报“试图加载格式不正确的程序集”现象解决方案编译无任何错误但启动 TradeLink Server 或策略宿主程序时抛BadImageFormatException或 “An attempt was made to load a program with an incorrect format”网上搜一堆答案都指向“位数不匹配”。原因几乎都是平台目标位数不对。TL 的部分依赖项数据库驱动、原生行情解码库是 64 位专用你用了AnyCPU或 x86 编译运行时 JIT 以 32 位进程加载碰到 64 位原生库就崩。解决打开解决方案配置管理器为所有涉及原生库的工程显式选择x64不要依赖AnyCPU的兼容策略。同时确认启动项目也是 x64。改完配置后删掉 bin/obj 缓存重新 build否则旧文件残留会让你继续踩同一颗雷。5.2 行情疯狂刷屏但策略 Click 无反应现象服务器控制台显示 tick 数量持续增长但策略程序里的GotTick断点永远打不到或者打了很久才触发一次。原因多数是订阅与回调线程错位。策略的GotTick由通信通道的回调线程触发如果你在策略启动时没有正确调用Response.SendSubscribe或者通道组件配置了但未启动消息泵事件就被丢弃。还有一个隐蔽场景你注册了两个策略实例到同一个通道单实例的断点打在第二个实例上第一个实例抢走了消息。解决在Start()里打日志确认SendSubscribe执行成功且返回的订阅确认消息GotMessage到达检查宿主程序是否只单例注册。如果多策略并发给每个策略分配独立的事件通道不要共享一个Response。5.3 同一订单回报重复触发 GotOrder现象只下了一手单但GotOrder里打印了三次状态更新第二次和第三次的OrderStatus都是Submitted。原因TL 对订单状态的推送是“每变必推”但部分券商柜台在委托链路里会重复回传同一状态的回报。TL 通道层默认不做去重直接把所有回报都推给策略。解决策略层自己维护一个去重字典键用Order.idOrderStatus组合只有首次出现才处理。不要依赖框架帮你过滤。同时确认你没有在多个地方比如GotOrder和GotFill重复维护同一批状态变量。5.4 回测用历史数据时信号总是慢一拍现象同一套参数在 Python 的某回测库里金叉信号出现在 14:59:59在 TL 回放里变成 15:00:01差了整整 2 秒。原因TL 的回放引擎在推送 tick 时默认每个 tick 之间会做时间戳校验并按“实时速度”推演而不是全速。如果你的机器性能不足它就会放慢推送策略处理堆积导致信号延迟“现实化”。另外如果 CSV 时间戳精度只到秒多个 tick 挤在同一个秒内顺序是按文件行序不是按真实毫秒序。解决回测时开启“尽可能快”模式通常在引擎配置里叫bypass latency or fast-forward并且确保数据时间戳精确到毫秒及以上。如果数据本来就只有秒级先做毫秒补位同一秒内按行序递增再喂给引擎。5.5 外接自定义 Broker 时Order 里的价格和数量变成 0现象自己写的适配器把Order转给柜台接口时打印出来的order.price和order.CumFill都为 0导致柜台报错或废单。原因TL 的订单对象是多用途的。在“请求”阶段CumFill和UnSolicited可能尚未初始化真正的委托数量在Order.total或Order.Unsolicited CumFill里而价格在某些市价单模式下确实允许为 0。你如果统一用price字段而不判断order.IsMarket就会被市价单堵死。解决适配器里先判订单类型市价单则忽略价格字段用0或柜台的“市价标识”替代数量统一从order.Unsolicited order.CumFill取不要把CumFill当委托量。同时在发送前做一次防御性校验价格小于等于 0 且非市价单直接拒绝发送并记为Rejected。这五个坑覆盖了从环境、回测到实盘的常见翻车点。你可以把它们当作一份 TL 开发的“血泪清单”遇到诡异问题时逐一比对。6. Trick用 TradeLink 自带的模拟撮合做“策略混沌测试”TradeLink 框架里藏着一个极其实用的工具模拟撮合引擎SimBroker / SimOrder。很多人只把它当回测工具用却忽视了一个高级用法——用模拟撮合做策略的混沌测试。你可以人为制造乱序回报、重复回报、撤单延迟观察策略在恶劣环境下的自恢复能力这在真实上线前价值极高。举个例子。在真实柜台中偶尔会遇到“撤单确认迟迟不回来”的情况。你可以用 TL 模拟撮合来复现这种边界发一个撤单指令但配置撮合引擎延迟确认或直接丢弃回报再看看策略会不会把订单状态卡死。做法是在策略代码里注入一个人为延迟public void GotOrder(Order order) { if (order.OrderStatus OrderStatus.Cancel) { // 模拟撤单回报卡顿 5 秒 Thread.Sleep(5000); } // 其余正常逻辑 }注意这里Thread.Sleep只在测试代码里做绝不能出现在生产策略里。GotOrder是消息泵线程上的回调你睡眠会阻塞所有后续事件。这个混沌测试的目标是观察你的策略在状态不一致时是否仍然能通过超时重发或主动查询来修正仓位。如果你发现策略直接死锁那说明你需要引入订单本地状态表维护每一次状态流转的期望值与超时机制。这套习惯救过我一次——当时某跨平台系统从模拟撮合切换到真实柜台时撤单确认时序从“固定 200ms”变成了“随机 10~2000ms”策略直接出现了重复撤单。因为模拟阶段我只测了顺序流没测乱序流差点让一个模拟项目翻车。后来我在本地新增了“回报乱序测试”脚本专门打乱回报顺序后再回放策略状态机才算真正健壮起来。TL 的另一个进阶技巧是把它的回放引擎和外部数据管道串联让实时行情先落入本地数据库再通过回放引擎“延迟重放”当前时刻的数据这样做的好处是实现“影子盘验证”——同一个策略同时跑实盘和延迟回放对比两者的信号差异用来检测数据跳跃或策略状态漂移。回到方法论层面TradeLink 的价值不在一揽子策略库而在它给了你一个足够干净的 C# 事件驱动骨架。你用好了状态机理解清了回调边界它就能成为你在 .NET 生态里自建量化系统的一块稳定基石。作为把这条路走过一遍的人我给后来的实践者一句忠告先在模拟撮合里把各种异常揍一遍再考虑接真实柜台愿你在这个过程中少踩本地编译与状态错配的坑希望帮到你。本文还有配套的精品资源点击获取