盘前接收隔夜数据、整理新闻公告、计算信号盘中盯盘、下单、控制回撤盘后对着成交记录一条条复盘、调参、重新训练模型。这套流程我自己跑了三年多最深的感觉是真正消耗心力的不是策略本身而是流程里那些重复、琐碎、需要高度按部就班的环节。QuantBot多AI-Agent协作量化工作台的思路就是想把这些环节拆开交给不同的Agent去干最后拼成一个完整盘前-盘中-盘后自动化闭环。这篇文章我会把整体设计、各个Agent的职责、事件怎么流转、风控怎么兜底以及实际跑起来会遇到哪些坑一次性讲清楚。适合正在做个人量化研究、或者小团队想给投研流程做自动化的同学参考。1. QuantBot整体设计思路为什么把AI Agent拆成一支“团队”1.1 单Agent解决不了量化全流程量化交易天然是一条长链路数据采集、消息面分析、策略信号生成、风险控制、订单执行、盘后复盘、模型迭代每一个环节对输入输出的要求都不一样。早期我也试过用一个Agent包办所有事情给一个大模型塞满工具调用和上下文结果发现两个问题。第一个是上下文污染。数据清洗和归因复盘需要的信息差异太大混在一起之后信号Agent容易把无关信息当成决策依据。第二个是稳定性差。一次工具调用超时或者返回格式稍微变化整个流程就中断了从头再跑一遍的成本很高。把Agent拆开本质上就是做职责隔离各管一段任何一段出问题都能单独重试不会牵连整条链路。另外多Agent协作还有一个好处可以针对每个环节选择合适的模型。简单的情报摘要用小参数模型就够策略生成和归因分析用推理能力强的大模型成本和效果都能兼顾。拆开之后每一段都可以独立演进不需要为了一个功能升级把整个系统重构一遍。1.2 协作模式主管Agent 专家Agent 事件总线QuantBot采用的是一种很实用的协作模式我称之为“主管-专家”结构。主管Agent不直接做具体分析它只负责任务调度和结果汇总真正干活的是各个专家Agent比如数据采集Agent、情报Agent、风控Agent、执行Agent。专家Agent之间不直接互相调用所有通信都通过事件总线完成。这种方式的好处在于解耦。专家Agent不需要知道消息是谁发的只需要按照约定的事件结构消费数据、产出结果。比如情报Agent把分析结果写到事件总线策略信号Agent订阅了这条消息拿到结果后去更新自己的候选池。后续如果想换掉情报Agent只要保持事件结构不变其他模块完全不受影响。阶段流转也靠事件驱动。盘前结束后主管Agent会发布一个“盘前完成”的事件盘中监控Agent收到后开始启动。如果某天数据源异常盘前没有正常完成那么盘中阶段就不会被触发。状态可观测问题更容易定位。1.3 QuantBot的模块划分与运行阶段下面是QuantBot的模块划分。这个表格里的职责和工具是我实际项目里比较顺手的组合你可以按自己的数据源和技术栈调整。Agent核心职责运行阶段主要工具/数据数据采集Agent拉取行情、财务、新闻等数据并清洗落库盘前/盘中/盘后Python脚本、数据API、ClickHouse/PostgreSQL情报Agent分析新闻公告情绪识别潜在影响盘前LLM接口、关键词过滤、情感打分策略信号Agent根据因子和情报生成候选标的、方向、置信度盘前qlib、因子库、信号模板风控Agent校验仓位、止损、单票上限是否有否决权盘中风控规则引擎、账户查询执行Agent拆单、下单、跟踪成交回报盘中券商交易API、订单状态机复盘Agent生成日报归因盈亏总结得失盘后交易记录、行情归档、LLM模型迭代Agent回填数据、重算特征、触发训练盘后qlib、MLflow、特征仓库每个阶段有明确的输入输出。盘前阶段的产物是一份“当日交易计划书”包含候选标的、建议方向、最大仓位、需要重点关注的公告盘中阶段的产物是订单记录和风控事件盘后阶段的产物是复盘日报和可执行的模型优化任务。整条链路打通之后人工只需要在每天早上确认一次计划书其他时间盯异常报警就行。2. 盘前准备信息整合与信号生成2.1 盘前数据收集不能只看行情盘前阶段的第一个动作是把“隔夜世界”拉回本地。我一般把数据分成四大类行情类标的当日开盘集合竞价、昨收、夜盘相关品种表现、外盘指数。基本面类当日发布的财报、业绩预告、重大合同。消息类新闻快讯、监管公告、热门论坛/社交媒体的讨论热度。衍生数据类已经计算好的因子值、昨日的仓位和资金曲线。这里有个很容易踩的坑就是只关注行情而忽略消息。很多策略真正的死因是“突发利空出现但策略没有感知”。所以在QuantBot里数据采集Agent会设置多个数据源并行抓取然后把结果统一成标准化结构。比如消息类数据会统一为标题、正文摘要、来源、发布时间、相关标的列表五个字段。这样后续情报Agent处理起来非常方便。数据清洗也要在盘前完成。复权因子、停牌状态、涨跌停标识这些如果不处理好后面的信号计算全是错的。我遇到过最离谱的一次某个标的前一天停牌数据源返回了空值策略信号把空值当成了大跌信号差点在集合竞价阶段生成空单。后来我加了一条硬性规则任何涉及停牌或异常波动的数据必须由数据采集Agent显式标注不允许静默落库。2.2 情报Agent让大模型只做总结不做判断情报Agent是我觉得QuantBot里最体现“AI Agent”风格的部分但它的设计原则非常克制让大模型做内容总结和情感打分真正的交易判断交给策略信号Agent和风控Agent。具体流程是这样的。数据采集Agent抓完消息后情报Agent会先做一层规则过滤比如只保留与自选股池相关的消息再剔除来源可信度低的账号。过滤后的消息被拼成提示词交给LLM输出一个JSON结构{ news_id: 20250112_0012, title: 某公司发布年度业绩预增公告, sentiment: positive, score: 0.82, affected_symbols: [600001], summary: 公司预计2024年度净利润同比增长40%-50%主要受益于产品价格回升。, risk_tags: [业绩预增, 单季波动] }这个设计的核心是可控。情感打分只是一个辅助信号不会单独触发交易真正重要的事件会被打上标签比如“业绩预增”“股权质押”“监管问询”这些标签会直接影响策略信号Agent的标的过滤。如果LLM把某条消息误判为正面系统也会因为有结构化标签和摘要方便人工快速核对。2.3 策略信号Agent把数据变成可执行的交易计划盘前最后一个核心环节是生成交易计划。策略信号Agent会把三类输入整合在一起因子库输出的数值信号、情报Agent的结构化事件、前一个交易日的持仓状态。整合的逻辑不是简单加权而是分优先级。基本面事件和突发新闻的优先级最高如果一条消息被标记为“重大利空”那么无论因子信号多强策略信号Agent都会把相关标的从候选池剔除或者标上“仅观察不交易”。因子信号负责提供常规的买卖候选比如均线突破、动量排序、均值回归每个人可以把自己的策略逻辑塞进去。计划书的输出格式要稳定这是多Agent协作的底线。我习惯用一段管道符分隔的文本或者JSON生成之后落到工作目录同时发送到事件总线。举个例子{ plan_date: 2025-01-12, candidates: [ { symbol: 600001, direction: long, confidence: 0.76, suggested_position: 0.15, entry_note: 突破20日均线量能放大 } ], max_positions: 5, single_stock_limit: 0.2 }策略信号Agent不负责判断这笔交易能不能执行它只是给出建议。执行与否、仓位多大、要不要限制这些由盘中阶段的风控Agent和人工决策共同决定。这种“建议归建议、风控归风控”的边界能让整个系统在实盘中少捅很多娄子。3. 盘中执行实时监控与自动化下单3.1 事件驱动为什么不用定时轮询盘中最忌讳的就是“走一步看一步”。如果把行情刷新、订单状态查询、风控校验全部堆在同一个循环里任何一环耗时抖动都会导致监控延迟。QuantBot的盘中模块采用事件驱动而不是定时轮询。事件来源主要有三个。行情推送服务每隔几秒推送一次行情快照策略信号Agent在盘前生成的交易计划会在开盘后转成“待执行清单”人工在监控面板上手动触发的干预指令也会变成一个事件。所有事件进入统一的事件队列由调度器按优先级处理。优先级设计是风控事件 人工干预 订单状态变化 策略信号 行情快照。风控事件必须第一时间响应比如持仓超过上限不处理可能带来更大的风险。行情快照优先级最低因为即使丢一两帧也没关系大不了下次更新再修正。这样设计之后盘中系统很少出现“信号来了但队列堵死”的尴尬。3.2 风控Agent建议可以讨论熔断不能商量执行Agent负责把交易计划里的信号变成真实订单但每一笔订单下单前都必须过风控Agent这一关。我把风控规则分成两类。第一类是软风控Agent可以根据规则计算并给出警告。比如预计仓位超过目标上限但还没有达到危险值风控Agent会提示执行Agent减小下单量。第二类是硬风控一旦触发就不可绕过。典型规则包括单票仓位上限任何一只票的持仓市值不得超过总资产的一定比例比如20%。当日最大亏损线当日净值回撤超过某个阈值比如2%立即停止新建仓位。禁止对停牌/涨跌停标的开仓这种标的流动性极差委托容易变成僵尸单。硬风控不依赖大模型。我的做法是单独写一套规则引擎用纯代码实现执行Agent和风控Agent都不能修改。哪怕大模型判断错了硬风控依然能拦住绝大多数极端情况。有人觉得这样“不够智能”但实盘里最需要的恰恰是“确定性”而不是“智能”。3.3 订单执行的稳定性和幂等性问题自动化下单有个很隐蔽但很致命的问题重复下单。技术原因通常是网络超时。订单已经发给券商但客户端迟迟没收到回报程序以为下单失败又发了一次结果就出现了双倍仓位。解决思路是给每个订单一个全局唯一的业务ID并且在本地维护一个订单状态机。状态流转是CREATED → SUBMITTED → FILLED / PARTIAL_FILLED / CANCELED。每次要发起新委托之前先查一下这个业务ID是否已经存在如果存在就只做查询不再重复提交。另外一定要处理成交回报延迟。A股市场的成交回报有时候不是立刻回来的行情接口推送的成交量和委托队列变化也可能滞后。我的经验是下单之后先记录“目标数量”和“当前成交数量”过几秒钟再主动拉一次订单状态用查询参数和本地缓存比对再决定是继续加单还是撤单。这样能有效避免“以为没成交其实已经成交”的误判。4. 盘后复盘自动化总结与策略迭代4.1 复盘Agent自动生成日报盘后复盘的价值不用多说但很多个人交易者懒得写因为太花时间。QuantBot的复盘Agent把这些工作自动化了它读取当天的交易流水、委托记录、行情快照和早上的交易计划书自动生成一份结构化的复盘日报。我习惯让复盘Agent输出的日报包含这几个部分当日净值变化、分笔成交正负贡献、信号命中率、风控事件回顾、计划偏差说明。比如某天计划买入三只票实际只成交了一只复盘Agent会去追查另外两只是什么原因没有成交——是价格没到目标区间还是风控拦截了。这个追查过程由Agent调用工具完成然后生成结论。大模型的文本总结在这里很合适但还是要防止幻觉。我的做法是让复盘Agent只允许引用结构化数据比如成交记录里的实际价格、实际数量禁止它自己“估算”或“推测”。对于确实查不到的部分明确标注“数据缺失”而不是编一个原因出来。4.2 模型迭代Agent把盘后变成模型训练时间盘后还有一个重要任务更新模型。QuantBot的模型迭代Agent会在收盘后自动做工作流程是拉取当日完整行情和交易数据做数据一致性校验。把新数据并入历史特征库重新计算因子值。判断是否触发训练条件比如累计样本量超过阈值或者近N天模型预测偏差过大。如果触发则自动启动训练任务记录训练指标生成模型版本。特征工程这一步我特别建议借用qlib这类开源框架来管理。qlib对数据规范化、因子存储、回测流程的处理很成熟比从零手写省太多事。我自己在处理股票日线数据时会把qlib的Dataset和模型训练流程一起用模型更新完自动注册到MLflow方便回溯版本。这个环节最容易出的问题就是“未来函数”。盘后虽然只能拿到历史数据但如果在特征计算时不注意时序窗口比如把当天的收盘价拿去算当天的开盘信号就等于偷偷用了未来信息。模型迭代Agent跑出的训练指标再漂亮实盘也会翻车。我现在要求所有特征计算都基于“T日收盘后可得信息”并且在代码里显式加上时间窗口校验一旦发现特征里混入未来值立即终止训练任务。4.3 反馈闭环让Agent越用越“懂你”多Agent系统如果只有执行没有记忆那和普通脚本没有本质区别。QuantBot里的反馈闭环体现在两个地方。一个是对交易计划的反馈。复盘Agent生成的偏差结论会追加到交易计划文件的“历史备注”里策略信号Agent下一次生成计划时会把这些备注作为上下文输入。比如某只票连续三次被计划买入但实际都因为流动性太差没法成交Agent就会在下一次生成计划时自动调低它的优先级。另一个是对知识库的更新。我会定期把有价值的复盘结论、异常案例分析整理成纯文本写入知识库这些内容会作为Prompt的一部分注入到情报Agent和复盘Agent的提示词中。这样Agent就有了“长期记忆”同一个坑不会反复踩。当然知识库的维护需要人工审核一遍不能全自动否则错误知识会越积越多。5. 实践中的常见问题与排查技巧5.1 信号价格与实盘价格对不上这个问题的表现是盘前信号给出的参考价和盘中行情差距很大。最常见的原因是数据源时区不一致或者前复权价和实时价混用了。我排查时第一件事是看事件日志里的数据快照时间确认数据源返回的是哪个时间点的数据。排掉数据源问题后再查复权因子是否更新。记住一个原则信号计算、行情展示、交易下单必须统一使用同一套复权口径。5.2 大模型输出格式不稳定Agent输出JSON时偶尔会多出Markdown标记、注释或者多余的逗号导致下游解析失败。不要指望大模型每次都遵守约定我惯用的办法是在解析层加容错。先把结果里的代码块标记去掉再用容错JSON库解析如果还是失败就重试一次重试依然失败就把这条结果丢弃并在日志里标记。这个容错机制对整体稳定性帮助极大。盘前情报Agent如果输出有误系统不会整个崩溃只会丢失一条情报最多导致一个相关标的当天不在候选池里影响远小于流程卡死。5.3 盘中任务堆积、响应变慢如果事件队列里积压了大量行情快照而风控事件排在后面说明调度器的优先级没有生效。我遇到过一种情况行情推送线程太快队列长度无限增长低优先级的任务占满了内存。解决办法是给队列加长度上限超过上限后丢弃旧行情只保留最新快照。同时把行情处理做成“合并最新值”而不是一条一条处理。另外一个隐藏瓶颈是外部API调用。如果情报Agent在盘中突然需要调用一个响应很慢的大模型接口整个链路都会被拖住。所以盘中阶段的Agent严禁调用大模型接口所有需要大模型判断的事情都放到盘后。盘中的风控和执行必须是确定性代码。5.4 风控被绕过Agent系统的能力越强越要担心权限边界。如果执行Agent同时具备“读取持仓”“发送订单”和“修改风控参数”的权限一旦它的指令被人为构造或者模型输出异常后果会很严重。我的做法是把权限切成最小单元执行Agent只能发起委托和撤单不能修改任何风控阈值风控Agent的规则文件单独存放只有部署脚本有写入权限。相当于风控是独立铁幕不向任何Agent开放修改入口。日常检查时也可以通过审计日志看到每个Agent调用过哪些工具一旦发现异常权限行为立刻告警。5.5 策略在回测里很好实盘却很拉胯这个问题很多同学都遇到过其中一部分原因就是前面提到的未来函数另一部分原因是盘前情报没有真正被利用。QuantBot的多Agent结构虽然不能解决所有过拟合问题但它的复盘归因能力可以帮你快速定位问题。如果策略实盘跑得很差却被复盘Agent归因成“市场环境变化”那就要小心了——这不是Agent的错是策略本身可能只在特定行情里有效。我自己的判断标准是一个策略至少要在不同的市场状态上涨、震荡、下跌下各模拟跑一段时间确认它的优势来源是“信息处理”还是“运气”。如果归因显示盈利主要来自某两三天的极端行情那就说明策略风险偏高应该降低仓位甚至下掉。6. 从“能跑”到“好用”部署与扩展建议6.1 本地部署的大致架构对于个人量化研究者来说服务器资源不需要很大一台16G内存的Linux机器足够跑完所有盘前盘后任务。我个人习惯用Docker Compose管理各Agent服务每个Agent是一个独立服务通过消息队列通信。数据库用PostgreSQL存交易流水ClickHouse存行情快照Redis作为事件总线的临时存储。日志是排查问题的第一手段。每个Agent启动时都必须把输入参数、调用的工具、返回结果、耗时写入结构化日志。这样某一步出错时你能快速定位是数据源问题、模型问题还是网络问题。没有日志的多Agent系统基本没法维护。6.2 适用边界与需要注意的风险QuantBot这套工作流适合的场景是“有稳定策略逻辑、但希望自动化执行和复盘”的个人或小团队不适合把它当成一个全自动印钞机。自动化只能解决效率问题不能解决策略本身有没有效的问题。我强烈建议任何自动化系统在上实盘之前至少先跑两三个月的模拟盘重点不是看收益率而是看Agent的行为是否一致、日志是否正确、风控是否真的会触发。等系统连续几十个交易日不出大问题再考虑用很小的资金接入真实交易。过程虽然慢但很值得。另外要明确一点文中所有思路和代码都是技术架构层面的分享不构成任何投资建议。量化交易本身有风险自动化会放大风险请务必对策略做充分验证并严格控制资金投入。6.3 后续还能往什么方向扩展QuantBot的框架设计有很好的扩展性。如果后续要覆盖更多市场比如期货、多周期级别只需要新增对应的数据采集Agent和风控规则。如果想要处理更复杂的订单执行策略比如VWAP/TWAP拆单只需在执行Agent里增加算法单模块。模型端也有一个优化方向把训练好的模型做INT8量化部署到边缘端。例如用ONNX的形式导出模型让盘中模块直接用轻量推理引擎跑信号预测延迟可以再降一个量级。不过模型量化之后精度会有一定损失需要在离线回测中反复验证不要想都不想直接上实盘。最后再分享一个经验我一开始也是用一个的Agent包打天下后来遇到一次盘中连续重复下单的故障才下决心改成多Agent分工。改动之后稳定性上了一个台阶不是Agent有多智能而是每个环节的边界清晰了出问题能快速定位。如果你也想搭一个类似的量化工作台建议不要一上来就追求复杂的架构先把盘前、盘中的最小链路跑通再加盘后迭代一步步补成完整闭环。