多AI-Agent协作：构建量化交易自动化闭环的工程实践

如果你做过一段时间的实盘量化大概率会有同样的感觉策略写出来只是万里长征第一步真正折磨人的是后面这套“永远干不完的活”——盘前要去不同的数据源把行情、公告、舆情抓下来清洗好盘中得时刻盯着信号、仓位和订单状态盘后还要拉成交记录做归因、跑回测、优化参数。每一个环节都不难但串起来特别耗人尤其是当你想同时管三五套策略或者多账户多市场一起跑的时候手工流程基本就是灾难。QuantBot就是冲着这个问题做的。它不是一个简单的策略回测框架也不是一个自动下单脚本而是一个把AI-Agent协作机制和完整交易流程结合起来的工作台。简单说我用多个专职Agent模拟了一个小型量化团队的分工有人管数据、有人做研究、有人盯执行、有人管风控、有人做复盘他们通过一个消息编排中枢紧密协作把盘前、盘中、盘后三个环节串成一个自动化闭环。这篇文章就把我搭这套系统的完整思路、工程细节、踩过的坑和关键决策逻辑一次性讲清楚给正在搞量化自动化的朋友一个可以直接参考的样板。1. 为什么是“多AI-Agent协作”而不是一个大模型全干刚开始我也想过更激进的方案——把所有事情都丢给一个大模型让它既看数据又写策略又盯盘。但很快发现这条路走不通。核心原因有两个。第一盘前、盘中、盘后对响应速度和容错的要求差异太大。盘前做得再慢都行反正有充足时间让Agent反复研究、多轮验证盘中则完全是另一回事从信号产生到订单落到交易所中间链路必须稳定可控如果这时候还让大模型去“思考”一段长文本再决定要不要下单响应延迟和不确定性都没法接受。第二职责边界必须清晰否则出了故障你根本不知道问题出在哪个环节。一个把所有事情都揉在一起的Agent跟一个数据Agent、一个风控Agent互相独立的架构相比后者的可观测性和可恢复性要强得多一旦某个环节出错只需要把对应Agent的状态回滚重跑就行。所以我设计的QuantBot采用了“多专职Agent 统一编排中枢”的架构。每个Agent只负责一件事Agent之间不直接对话全部通过消息队列传递任务和结果。这样既保留了AI的推理和分析能力又让交易链路里的每一步都变得可追踪、可重放、可回滚。整套系统里我划分出了六个核心AgentAgent名称职责范围主要输出物DataAgent行情、公告、舆情、宏观经济数据采集清洗标准化DataFrame、数据质量报告ResearchAgent策略信号计算、事件驱动研究、组合建议SignalResult、仓位建议RiskAgent仓位限制、止损止盈规则、黑名单/白名单校验RiskCheckResult、告警事件ExecAgent订单拆分、下单路径选择、成交回报处理OrderTicket、ExecutionReportBookKeeperAgent交易日历、持仓成本、现金头寸的实时记账PositionSnapshot、PnLReportReviewAgent盘后归因、回测对比、策略更新建议ReviewReport、策略优化建议理论上这些Agent全都可以用同一个底层大模型驱动只是通过不同的System Prompt和工具集来隔离能力边界。但我在实际落地时数据密集型和计算密集型的任务比如清洗行情、算指标会让Agent调用专门的Python计算引擎去跑而不是让大模型逐行去“算”这样能用确定性的代码处理的地方就不用概率性的模型推理。大模型在大局判断、文本归纳、异常解释这类模糊任务上才是不可替代的。这种分工方式带来的直接好处是每个Agent可以被单独升级、单独测试、单独回滚出了故障也不会“一损俱损”。比如盘中ExecAgent出现报单异常我可以快速隔离它让风控接管挂起所有新订单而不影响DataAgent继续更新行情。2. 工作台的整体架构与任务流编排QuantBot整体分三层接入层、编排层、执行层。接入层负责交易所接口、数据源SDK、第三方API的适配执行层是各个Agent实际干活的地方跑代码、调模型、返回结构化结果真正连接这两层的是编排层也是整个系统的大脑所在。编排层做的事情简单说就是一张状态机加一个任务队列。我定义了一套交易会话TradingSession状态机主要状态包括PRE_MARKET_DATA_READY、SIGNAL_GENERATED、RISK_PASSED、ORDER_SENT、POSITION_UPDATED、POST_MARKET_SETTLED。每个Agent完成任务后把结果对象投递到消息中心编排中枢根据当前状态机的跳转条件决定下一个该唤醒哪些Agent。实际消息框架我用的Redis Stream加Celery的组合。Redis Stream做任务队列的好处是支持消费者组、消息ACK和Pending重投这样能保证每个任务至少被消费一次Celery负责任务调度和重试策略。如果追求更工业化的方案用RabbitMQ或者Kafka也可以但对于一个个人量化工作台的体量Redis Stream在运维成本和可靠性之间平衡得最好。任务编排里最重要的一个原则是“所有Agent的输入都来自消息中心而不是直接来自上游Agent的内存变量”。这么做看起来多绕了一圈但换来了两个关键能力一是任务可重放——如果后来发现某个Agent当时的输出错了我可以把那个时间窗口的消息重新消费一遍二是链路可审计——每一步谁在什么时间消费了什么消息产出了什么结果全部留痕这对盘后归因和故障排查太重要了。盘中闭环的延迟方面我做了一个比较极端的优化信号产生到订单进入券商柜台中间不做任何大模型推理只用确定性规则完成风控和报单。Agent在盘中扮演的是“异常裁判”的角色只有在触发阈值警戒线、需要临时判断是否调整退出策略时才调用大模型做短文本推理。这个设计保证了闭环稳定也控制了API成本。3. 盘前工作流研报、数据、信号Agent们怎么准备开盘盘前时段是整个闭环里AI参与度最高的环节因为不像盘中那样有严格的毫秒级要求。我的盘前流程从凌晨5点开始DataAgent率先启动按照配置的数据源清单逐一采集当日所需数据。数据采集不是简单地把数据拉回来存起来就完了DataAgent要做的第一件事是“数据完整性校验”。每天早上我都会看一份自动生成的数据质量报告里面包含各品类数据的缺失率、延迟时间、异常值数量、同环比一致性检查结果。这个报告非常关键——如果A股票昨天的分钟线数据少了一段而你没有发现ResearchAgent基于它生成的信号就可能是错的等到盘中你才发现整个策略逻辑就崩了。做完数据质量确认之后ResearchAgent开始正式工作。它会读取你配置的策略清单逐个计算技术指标、读取基本面事件日历、结合舆情因子生成一份结构化的信号结果。策略清单我建议用声明式配置来写比如一个均线策略只需要声明“period_short5、period_long20、symbol_poolhs300_component”ResearchAgent看到这段声明后自动去拉数据、算指标、产生信号而不是每次都重新描述一遍逻辑。盘前还有一个很费人工的环节是“事件驱动研究”比如某家公司突然发布了重大公告需要在开盘前判断它有没有可能影响你持仓股票的价格。我在QuantBot里给ResearchAgent注册了一个工具——公告解读器底层接的是大模型加结构化知识库。公告进来之后先抽取主体、事件类型、涉及的产品线和时间节点再与当前持仓和策略池做交叉比对最后输出“可能影响评级”和“建议关注度”。这一块大模型是强项因为它能理解自然语言背后复杂的事件关系而用传统的规则引擎做你光是维护关键词规则就要吐了。所有信号在进入盘前终态之前还要经过BookKeeperAgent的现金和持仓约束校验。比如ResearchAgent觉得某只股票机会很大建议买入5%仓位但如果当前账户现金只有3%系统就得给出仓位缩减建议并把调整理由写清楚。我在这个环节加了一个“现金规划模块”本质上做了一个带约束的资产配置优化目标函数是在不突破现金上限和单标的持仓上限的前提下最大化组合的信号加权收益。盘前流程的收尾工作是生成一份“当日作战计划”包括今日关注事件时间线、各策略计划触发的条件和预期信号数量、以及黑名单和风控阈值提醒。每天早上开盘前花30秒浏览一下这份计划你就能清楚知道当天系统大概会做哪些动作哪些位置的判断是需要你额外盯的。4. 盘中执行闭环从策略指令到订单落地的关键工程盘中执行闭环是整套系统里对稳定性要求最高的一段。我的核心原则是八个字规则先行、AI兜底。也就是说正常行情下所有订单动作都走确定性代码路径AIAgent只做监控和告警不参与高频决策。执行链路的起点是ResearchAgent实时产生的新信号。信号对象SignalResult包含策略ID、方向、建议价格区间、目标仓位和有效时间窗口。它不会直接发给ExecAgent而是先进入RiskAgent的风控检查。我的风控规则分三层风控层级检查内容违反动作账户层总仓位比例、当日亏损限额、最大回撤警戒只允许减仓禁止新建仓标的层单标的持仓上限、黑名单、涨跌停状态拒绝该标的的所有买入指令策略层策略最大开仓次数、相邻两次信号最小时间间隔暂时冻结该策略的新信号这三层规则全部用声明式配置写死分钟级频次内只做参数查询和数值比较不需要任何模型调用。实测下来单次风控检查耗时在1到3毫秒对盘中的影响可以忽略。通过了风控的订单会进入ExecAgent。ExecAgent要做三件事拆单、选路、报单。拆单的逻辑其实挺讲究——如果一个信号对应的目标仓位较大直接一笔市价单砸进去会产生巨大的冲击成本。我做了一个简化版的时间加权平均价格TWAP算法把目标数量按时间均匀切片每片再叠加一个随机偏移让每一小笔订单看起来都不那么“机械”。选路则是把订单按照价格优先和速度优先做路由。如果当前价格快触及信号价格区间就走直接市价单如果离目标位还有些距离就改挂限价单等价格主动来成交。这里我一直在持续优化的一个点是对盘口深度的估计——挂限价单的时候不能只看买一卖一还要参考五档盘口的挂单量分布不然一片大单过去直接打在很薄的价位上滑点很难看。订单发出后的处理同样重要。券商柜台返回每一笔成交回报后ExecAgent要实时更新订单状态——部分成交、全部成交、拒绝、超时并把这些状态同步给BookKeeperAgent做持仓记账。如果出现订单长时间不成交或者部分成交量太低的情况ExecAgent会做一次“订单自检”检查是不是价格离现价太远、是不是涨跌停封死、是不是券商通道拥堵然后把自检结果发到告警中心。整个盘中闭环里真正用到AI的场景集中在两种异常情况。第一种是连续触发止损且止损原因高度相似RiskAgent会临时调用大模型对最近N笔止损交易的上下文做一个归纳判断是不是出现了某种系统性的行情模式比如某板块整体回撤、某个事件引发连续跌停从而给出临时调整策略的提示。第二种是策略在盘中出现意料之外的信号爆量比如某策略一次性产生了几百个买入信号ResearchAgent会调用大模型对信号分布做一次“合理性检查”避免因为数据异常导致的全市场无差别开仓。实盘中我还特别处理了一个很容易被忽略的问题成交回报和行情推送之间的头部竞态。简单说订单可能已经成交了但最新一笔行情的接收顺序反而比较慢导致持仓记账时用了旧价格。这个问题如果不处理盘后你会莫名其妙发现盈亏对不上账。我用了一个基于单调递增序号对齐的方案行情和回报都带上时间戳和序号记账时按序号先后排序后再处理基本消除了竞态。5. 盘后复盘与自进化让工作台越跑越聪明收盘不是结束至少对QuantBot来说收盘才是最有价值的工作时段。盘后ReviewAgent的职责不是简单生成一张“今天赚了多少钱”的报表而是做三件深度的事情交易归因、策略对比、知识沉淀。交易归因这块我按照“行情贡献、策略贡献、执行贡献”三层拆解当日的盈亏。行情贡献指的是如果什么都不做、光持有基准组合能赚多少策略贡献是超越基准的那部分超额收益执行贡献则是拆单算法和滑点控制带来的隐形成本节约。这套归因模型能直接回答你最关心的那个问题——我今天到底是靠本事赚的钱还是靠运气。ReviewAgent会把每一笔平仓交易对齐到产生它的策略和入场信号如果一个策略每天都能稳定贡献超额收益它会在系统里获得更高的资金分配权重如果连续多日跑输基准它会被自动降低仓位限制。策略对比环节的本质是“用真实成交来做样本外检验”。回测再漂亮都可能被过拟合骗过去但实盘交易的成交记录是真实的样本外数据。QuantBot会把当日各策略的实际成交信号整理成一份带标记的数据集每周跑一次滚动样本外评估拿已成交信号算出来的收益率曲线和同期回测信号的预测收益率曲线做差异分析。如果二者系统性偏离超过阈值就触发策略劣化预警系统自动降低该策略的信任等级。知识沉淀是我觉得最像“AI-Agent”的部分。ReviewAgent每天复盘完会生成一篇结构化的观察报告内容包括当日市场风格特征、各Agent做出的关键决策及理由、执行链路中的异常情况以及这些异常的原因分析。每个月月底系统会对所有观察报告做一次摘要聚类提炼出一些反复出现的高频问题比如“某券商的回报推送经常在午后出现延迟”“某个行业板块的因子在财报季容易失效”并把它们更新进知识库成为后续策略参数调整和Agent提示词优化的背景材料。这套机制跑了一段时间之后你会发现知识库的价值越来越大。新的策略上线之前ResearchAgent会先检索历史知识库看看有没有相关品种或因子在不同市场状态下的表现记录这比从零开始盲目回测靠谱得多。盘后流程里也有一件必须做且必须要做对的事情对账。BookKeeperAgent会把当日的所有成交回报、资金流水、持仓变动整理成一套复合账和券商的结算文件做逐笔核对。这个环节我强烈建议不要完全信任API返回的字段一定要把“账户期内累计买入数量和累计卖出数量之差”与“实际期末持仓数量”做交叉验证有偏差立即告警。多数盘后问题其实都出在这种小账上越早发现越好解决。6. 落地过程中踩过的坑与避坑建议QuantBot从第一个能跑通的版本到现在相对稳定的状态中间踩的坑数都数不过来。挑几个最典型的分享出来希望你不用再走一遍。第一坑数据源“偶尔的坏数据”比“缺数据”更难防。缺数据一眼就能看到坏数据经常伪装成正常值混过去比如某根K线的最高价低于最低价、成交量突然多一个零、前复权价格在某一天出现了跳变。刚开始我天真地认为上游数据源会做质量把控直到某次策略在盘中突然开了一堆不该开的仓追查了半天才发现是数据源把一只股票的价格小数位弄错了。后来我在DataAgent里加了几道硬校验最高价必须大于等于最低价、收益率极值检测、复权价格连续性检测并且把校验失败的数据块自动隔离同时告警绝不带着脏数据算信号。第二坑AI-Agent的“一本正经胡说八道”放在交易里是致命的。某次复盘时ReviewAgent对一笔亏损交易给出长篇大论的解释逻辑非常自洽但仔细一查它引用的某条事件背景根本不存在完全是在脑补。自那以后我立了一条铁律所有Agent输出的结论凡是涉及数据引用和事实描述的必须附上可追溯到原始数据源的信息无法溯源的内容一律标记为“推测”绝不允许混进正式报告和策略参数里。第三坑任务链路越复杂越要重视超时和重试机制。Agent之间通过消息队列通信最怕的是某个Agent因为外部API变慢导致任务积压进而拖垮后面所有流程。我后来给每个Agent调用外部接口都设置了独立的超时时间和降级策略比如公告解读接口超时了就自动降级为纯关键词匹配绝不让一个环节的卡顿影响整条生产链路的运转。第四坑回测的“未来函数”和数据泄漏防不胜防。盘后对比环节第一次跑出来异常漂亮的胜率时我差点开心坏了结果仔细一查是前复权数据处理时把未来除权信息带进了历史区间导致回测信号看起来完美无缺。现在QuantBot的系统里有专门的“防泄漏检查器”会在开跑任何回测之前检查数据切分、因子计算和信号生成过程是否涉及未来信息宁可逻辑保守一些也要保证回测结论干净。第五坑对异常状态的“告警疲劳”。刚开始我把所有不常见的情况都设为告警级别结果一天能收到几百条消息没过几天人就看麻了真正的严重问题反而被淹没。后来我按照“影响资金安全、影响订单执行、影响数据完整性、仅提示”四个级别重新设计了告警体系重要的事情强制推送次要的事情只记录日志告警投放集中在飞书机器人上整体体验天差地别。最后再提一个日常运营的小建议盘中不要频繁去“优化”Agent的提示词和策略参数。交易系统的表现需要在一个连续的时间周期下才能被稳定评估盘中任何改动都会污染样本让你无法判断这个改动到底带来了收益提升还是噪声干扰。我给自己的规则是所有Agent提示词的修改和策略参数的调整一律进配置中心、一律走审批流、一律在收盘后生效。盘中只留一个权限——紧急风控的暂停按钮。我个人实际的体会是QuantBot这类工作台的价值不在于它能在某个单点任务上做得比一个人更优秀而在于它把“执行—观察—反思—改进”这个循环用工程化的方式稳定地运转起来了。以前我需要花大量时间在数据整理和流程维护上现在这些时间全部释放给了策略研究和市场思考这才是自动化闭环最有魅力的地方。