说实话我一开始搭 QuantBot 这个多 AI-Agent 协作量化工作台并不是因为“AI-Agent 很火所以我要追一下”。而是我自己的复盘习惯实在撑不住了收盘后想回看当天到底为什么做这个判断结果翻聊天记录、翻 K 线截图、翻订单流水每次都要折腾一两个小时。后来我就在想能不能让几个 AI-Agent 各自负责一段事帮我把盘前、盘中、盘后整个流程串成一个自动化闭环数据、结论、原因都能自动留下来。这就是 QuantBot 的起点。这篇文章我把整套系统的设计思路、Agent 分工、闭环跑法、踩过的坑一次讲清楚给同样想把自己量化工作流改造一遍的朋友做个参考。如果你正准备做量化但对代码和 AI-Agent 的组合怎么落地还没把握这篇文章也适合你。因为我不光会讲 QuantBot“是什么”更会讲清楚为什么每个环节要这么拆、每个 Agent 为什么这么分工以及哪几步是真正让我觉得“没白做”的。1. 为什么要用多个 AI-Agent 协作而不是写死一套自动交易脚本先讲一个最容易被误解的点。很多人一听“量化工作台”“AI-Agent”下意识觉得这是要做一套全自动炒股机器每天自动选股、自动下单、自动赚钱。如果你也抱着这个期待那我劝你先冷静。QuantBot 做的事不是替代你的投资判断而是把所有需要“人力去读、去盯、去整理、去复盘”的环节接过去把每一个判断背后的上下文压缩成几分钟就能看完的摘要。它更像一个能一起开会的研究员团队而不是一个替你按下买入键的执行器。那为什么不让一个大模型把从盘前到盘后所有事情全干完说实话我在早期原型里试过单 Agent 方案给一个模型塞了行情接口、新闻接口、持仓接口、复盘模板让它一个人当全能选手。结果非常现实日内运行时它会因为一条盘中新闻触发长篇分析导致核心盯盘任务被拖慢到了盘后复盘时它的上下文里还混着早上那些盘中噪音归因归得乱七八糟。问题不在于模型能力不够而在于你让一个“人”同时干研究员、交易员、风控员、复盘员它一定会角色混乱。类比一下你就懂了你去一家公司办事一个前台把所有部门的活全包了效果一定很差。真正高效的架构一定是分工明确的前台只负责接待和分流财务只对账法务只看合同。多 AI-Agent 协作本质上就是这个逻辑。每个 Agent 只拥有一段非常明确的职责边界、有限的工具权限、高度聚焦的提示词这样它的输出才稳定、可解释出了问题也知道去查哪一环。所以 QuantBot 的第一个设计原则就是把量化工作流按“认知分工”切成独立 Agent而不是把所有工具堆给一个 Agent。这个原则决定了后面所有消息结构、编排逻辑和权限设计。每多一个 Agent虽然会增加系统复杂度但换来的好处是每个环节的上下文都干净、可控出问题能快速定位模型之间的意图也不会互相污染。1.1 单 Agent 做量化的三个致命问题把单 Agent 跑量化的问题说细一点其实是三个。第一是上下文窗口的争夺。行情数据、新闻资讯、历史持仓每一类都是大量信息单个 Agent 要把这些都塞进上下文里才能干活但窗口是有限的它往往只能“记住最近的”而关键的历史判断早就被挤出去了。第二是错误无法隔离。盘前新闻解析出错和盘中行情误判是完全两类问题如果让同一个 Agent 处理你很难判断哪里开始错的因为整个链条都黏在一条 prompt 里没法单独验证某个环节。第三是实时性与深度的冲突。实时盯盘要求秒级响应而盘后再分析要求长时间推理完全不同的响应模式塞进同一个 Agent结果就是实时任务被推理任务阻塞深度任务又被实时任务打断。QuantBot 里我把这些冲突用 Agent 边界切开了盘中监控 Agent 只做行情窗口里的快速判断和消息触发盘后复盘 Agent 可以慢慢读数据、算归因、生成报告。两者互不占用对方的资源和上下文各自用各自的时间尺度运行。你可能觉得这是技术细节实际上这是整个系统稳定性的根基。1.2 QuantBot 和其他量化系统最关键的区别人机边界真正用过一段时间 QuantBot 之后我更加确信一个观点AI-Agent 量化系统解决的是“上下文管理”问题而不是“投资决策”问题。投什么、买多少、什么时候止损这些最终应该由人来做决定。Agent 能替你做的是保证你在做这些决定的时候手里拿到的材料和数据是完整的、有依据的、可追溯的。QuantBot 里专门留了几个人工确认点盘前生成的操作事项清单需要你过目盘中信号只有达到较高置信度才会推送提醒而且不会自动执行盘后复盘中涉及关键持仓调整的建议同样只作为建议存在。这几条看着损失了“全自动”的效率但长期看救了我很多次。因为模型会犯错、数据会延迟、市场会出现预案之外的走势出现这些情况时如果没有人守在决策环上一个错误会被系统自动放大。这套工作台的定位是让一个认真做交易的普通人拥有一个十人研究团队的信息处理能力但最终方向盘必须握在自己手里。2. QuantBot 的 Agent 分工与能力设计QuantBot 不是一个“巨型模型”而是一组各管一摊的“数字员工”。我一共设置了四个核心 Agent外加一个主控调度器。每个 Agent 有专门的提示词、职权范围、工具集和输出模板绝不越界。下面我把它们的角色和设计逻辑展开讲。2.1 盘前研究员把海量噪声压缩成可决策的事项清单这个 Agent 每天开盘前启动负责处理三件事昨夜外盘和重要资产的走势概况、与持仓或关注池相关的新闻公告、当天日历上可能引发波动的宏观事件。它的输出不是一篇又长又泛的行情综述而是一份结构化的“盘前事项清单”每一条都包含事件、关联标的、影响方向、置信度四个字段。这里的一个核心设计是要求置信度。我一开始没做这个约束结果这个 Agent 喜欢写“XX 板块或受情绪提振”模糊不清我没法判断哪条重要哪条次要。后来我把输出模板里加了一个“置信度打分”字段0 到 1 之间并要求它只给有明确信息支撑的条目打分。同样一条新闻如果只是自媒体讨论置信度就很低如果是公司公告或官方数据置信度就高。这样我早上扫一眼清单只挑高置信度的事深入看效率提升非常大。盘前研究员的另一个关键点是它必须知道“我持仓什么、关注什么”。所以我给它配置了一个只读的持仓和关注池数据接口同时保留了一个向量记忆库让它能查阅过去一周自己生成的报告。这样它能回答“这只票昨天那条利空到底消化完没有”这类需要时间上下文的问题而不只是给一个今天的信息快照。2.2 盘中监控员秒级响应但不做深度分析盘中监控员是 QuantBot 里唯一对实时性要求最高的 Agent。它只负责一件事盯着行情和中标事件一旦出现预设规则的触发就生成一条“警报事件”丢到消息队列里。它不会去写长文分析不会去查历史数据更不会给出买卖建议。它的输出就是极其简短的结构化事件比如“持仓 XX 在 10:32 出现放量下跌成交量是过去5日同时段均值的 2.3 倍”。为什么不让盘中 Agent 做分析因为大模型推理速度根本跟不上行情变化的速度。我曾经试过让它在触发警报后用模型生成解释结果平均耗时在 4 到 9 秒之间等它把解释写出来行情可能已经走完一个阶段了。所以 QuantBot 的策略是用确定性规则做筛选用模型做筛选后的二次判断和摘要。只有当警报进入高优先级通道才会调用模型生成简短解读并推送给人的确认端。盘中监控员对延迟有最高要求所以我单独给它接了一个低延迟通道其他 Agent 用的是普通队列。这个 Agent 还有一个特殊设计每次收盘后它会自动“失忆”清空当天积累的临时缓存避免把当天所有高频噪音带给次日会话。这种状态隔离在长周期运营里非常重要。2.3 风控复核 Agent唯一有“否决权”的角色风控复核 Agent 是我后来加上的。一开始我以为只要有了盘中监控就不需要额外的风险控制 Agent。结果有一段时间策略信号连续触发盘中监控员不断推送提醒我有点疲劳差点漏掉其中一条偏离我原始止损计划的信号。那次之后我就想QuantBot 里必须有一个角色专门盯着“人的纪律”而不是“市场机会”。风控复核 Agent 的输入是所有即将提交给人确认的买卖提醒和操作建议。它不管这笔交易是否赚钱只管一件事这个操作是否在既定的风控规则框架内。比如单笔仓位是否超限、总仓位是否接近风险阈值、如果是加仓操作是否符合原计划的加仓条件。当它检查到某条提醒超出预设参数时它会生成一个“否决标记”并附上具体原因。人虽然仍然可以选择忽略这个否决但必须多一步确认而且这个否决记录会留档出现在盘后复盘报告中。这个设计表面上是给流程添堵实际上它保护的是人在情绪波动时的判断力。人总有冲动的时候市场狂热或恐慌的瞬间一个强制要求“多确认一次”的缓冲点价值巨大。2.4 盘后复盘分析师从操作记录里提取经验不写流水账盘后复盘分析师大概是所有 Agent 里最适合发挥大模型能力的角色因为它没有实时性压力可以慢慢读数据、做归因、写报告。它的输入是当天所有 Agent 生成的事件日志、所有成交和操作记录、以及当天的行情数据快照。输出是一份复盘摘要分成三个模块纪律执行情况、策略表现归因、明日注意事项。我特别想强调的是纪律执行情况的刻画。过去我自己复盘总爱找外部理由——“今天市场不好”“这条消息来得太突然”。但 QuantBot 会把当天所有提醒、否决、漏看的情况列出来对照我的最终操作直接指出我有没有执行原计划。这个模块刚上线前两周相当扎心因为它会毫不留情地显示我在某些时刻偏离了计划。但恰恰是这种不留情面让我在后面的实盘运行中更有意识地遵守自己的交易纪律。为了归因可信盘后分析师必须拿到“对齐后的数据”。也就是收盘后会有大约二十分钟的静默期等券商结算和行情快照都稳定了再把数据喂给它。否则它拿到的盘中快照和最终数据有差异归因就会失真。这是数据工程层面的细节但直接影响复盘质量。3. 完整闭环是怎么串起来的主控编排、消息队列与状态记忆单有 Agent 角色还不够QuantBot 要形成一个完整的“盘前-盘中-盘后闭环”核心在于编排层。我把它拆成了三块主控调度器、消息总线、状态存储。这个架构看起来像普通的微服务但它比微服务更强调“每个 Agent 都是被动触发的工人”彼此之间不直接通话只通过消息总线异步协作。这样设计最大的好处是解耦。比如盘前研究员昨晚意外失败了盘中监控员完全不受影响照常运行盘后复盘分析师到点之后发现盘前数据缺失它会在报告里明确标注“该日盘前生成失败”而不会因为依赖环节断裂而崩溃。对量化这种长周期系统来说每个环节都不能因为其他环节的临时故障歇菜。异步消息是这一切的基础。3.1 主控调度器一个像闹钟又像状态机的东西QuantBot 的主控调度器逻辑不复杂核心是一个状态机加定时触发器。每个交易日里系统会根据时间把运行状态依次切换为盘前准备、盘中监控、收盘清算、盘后分析、结果归档。每个状态切换时调度器往消息队列里发送一条“状态切换事件”相应的 Agent 收到事件后开始自己的工作。下面这段伪代码可以更直观地表达这个流程while market_day_running: current_state get_current_state() if current_state PRE_MARKET and time_reaches(07:00): publish_event(pre_market_start) # 盘前研究员开始工作生成事项清单 elif current_state INTRADAY and time_reaches(09:15): publish_event(intraday_start) # 盘中监控员订阅行情事件开始盯盘 elif current_state INTRADAY and time_reaches(15:00): publish_event(intraday_end) # 盘中监控员进入休眠缓存清空 elif current_state POST_MARKET and data_reconciliation_done(): publish_event(post_market_start) # 盘后复盘分析师开始读取对齐数据生成复盘报告 elif current_state ARCHIVING: archive_all_reports() save_state_snapshot() reset_memory_for_new_day()你可能会问为什么不用现成的调度框架 Cron 就完了因为量化交易日里的状态切换不只是时间触发还依赖条件。比如收盘清算这个状态如果当天数据接口延迟你必须等数据对齐后再触发盘后分析死板的定时任务没法处理这种依赖。用状态机的好处是每一个状态都清楚自己的前置条件和后置动作也方便中途人工介入。3.2 Agent 之间不直接对话通过结构化消息协作在 QuantBot 早期测试中我犯过一个很典型的错误让一个 Agent 直接把输出结果作为另一个 Agent 的提示词上下文也就是 Agent 直接“对话”。看起来灵活实际上一旦链路变长错误信息会在 Agent 之间逐层放大。Agent A 输出里有一点小偏差Agent B 没发现并继续推理到 Agent C 那里偏差已经被放大成“事实”。所以后来我废掉了 Agent 之间的自由对话模式要求所有 Agent 之间的信息传递都必须使用结构化的消息对象。每条消息至少要包含事件类型、产生时间、数据来源、置信度、正文载荷这几个字段。例如盘中监控员发出一条警报事件格式大致是{ event_type: alarm_price_drop, producer: intraday_monitor, timestamp: 2025-05-16T10:32:0708:00, symbol: 000001, confidence: 0.82, payload: { price_drop_pct: 3.5, volume_ratio_vs_ma5: 2.3 } }这个格式的好处是盘后复盘分析师读取事件时不需要再去解析一段模糊的自然语言文本而是直接读取结构化的字段进行数值计算和归因统计。Agent 的输出越结构化整个系统的可控性就越强。做多 Agent 系统时一定要记住一条Agent 之间的接口最好比人和 Agent 之间的接口更严格。3.3 状态和记忆的存储长期有档案短期可失忆状态记忆是 QuantBot 能形成“闭环”的另一个关键。我采用的是冷热分离的存储方案实时运行期间需要快速访问的数据放 Redis例如日内触发的警报队列、当前仓位快照、当日临时状态需要追溯的完整历史信息放 SQLite 或文件存储例如每天的盘前清单、盘后报告、操作确认日志。每天开盘前系统会用一个轻量级的“记忆重置”过程把前一日的临时缓存清掉只保留长期档案和历史复盘沉淀出的“经验摘要”。这个经验摘要是盘后复盘 Agent 在每天结束前自动生成的一段结构化文本比如说“过去三天持仓 X 连续放量下跌但基本面未变考虑是否属于情绪错杀”——它会被存入长期记忆库成为第二日盘前研究员的参考上下文。这样一来系统就有了跨日的记忆能力而不是每天从零开始。我当时在设计这个记忆机制时参考了很多架构上的做法。太像长期团队积累会带来知识混乱太小会丢失有价值的历史背景。 QuantBot 的选择是只有沉淀后的结构化摘要能进入长期记忆原始聊天记录和日志都只做归档不做记忆检索。这样既避免了大模型长期上下文无限膨胀的问题也保证了历史信息是可追溯、可校验的。3.4 延迟、超时和失败降级稳健性不是可选项任何一个接入了外部 API 的自动化系统都必须面对服务的不可用风险。行情接口偶尔抽风模型 API 偶尔超时券商交易接口偶尔维护这些都是必然的。QuantBot 的每个外部调用都要配置独立的超时时间和重试策略并且明确规定某个 Agent 调用失败时系统是直接跳过还是发警告让人工接手。举个例子盘中监控如果发现行情 Provider 超过 3 秒没返回最新数据它不会被阻塞在那里瞎等而是立刻生成一条“行情延迟”事件把最近一个已知快照的时间戳标注出来。这样我看到的信号如果用了延迟数据至少不会误以为是实时状态。QuantBot 里许多运行时的诡异问题最后排查下来都是数据延迟造成的时间戳错位所以“宁可慢一点不可不知情”是实时环节的第一原则。4. 一个真实交易日的时间轴QuantBot 的闭环完整走了一遍很多朋友看了架构图会问我这系统听着挺完整那现实中一天是怎么跑下来的我这里复盘一个比较典型的交易日完整展示盘前、盘中、盘后三个时间段里 QuantBot 到底都做了什么。这个时间段是根据个人工作习惯定的你可以根据自己交易的市场节奏微调。4.1 盘前 07:00-09:00自动生成 12 条关注事件早上 7 点QuantBot 的主控调度器发出“盘前开始”事件盘前研究员被唤醒。它先读取持仓与关注池清单然后并行拉取隔夜的外盘指数、大宗商品、公告新闻、宏观日历。大概 7:35一份带置信度评分的盘前事件清单出现在我的手机推送里。这份清单通常有 10 到 20 条事项但它不是简单罗列新闻而是只保留与关注池相关的信息并按影响方向分类。我记得有一次盘前研究员在清单里列了一条某只持仓股昨日晚间发布成绩预告预计净利润同比增长 40% 到 60%置信度 0.9关联方向“偏多”。如果我没看到这条早上开盘我大概率会在低位犹豫而实际上我看到刺激清晰的清单后心里对“今天即便低开也不轻易割”做好了预案。这就是盘前研究的价值——不是预测走势而是让可能影响一天判断的关键信息不遗漏。同时风控复核 Agent 在盘前也会自动跑一遍比对当前仓位和最新持仓规则检查有没有规则的执行在昨晚发生了变化。比如如果是调仓日它会自动提示“今日计划调仓注意总仓位限制”这个提示会在盘前输出里与研究员的事件并列展示。4.2 盘中 09:30-15:00行情触发事件研究型问题进入异步队列开盘后盘中监控员接管主导权。它会以较高的频率轮询行情接口并运行一组盘中规则。这些规则包括持仓股短时间内上下波动超过预设阈值、成交量较近期均值异常放大、自选股触及关注价格等。一旦命中它会在 1 秒内生成警报事件并推送给我。比如持股在盘中突然快速下探跌破我预设的一个观察位盘中监控员会推送一句很简短的话“XX 当前跌破观察位 3.2%成交量为近期 1.8 倍。建议查看是否有新的消息面触发如需操作请确认。”它不会自动止损也不会说“赶紧割肉”它只是把客观状态送到我面前把决策权和执行权留给我。如果触发的同时盘前研究员的结论里有相关背景系统会同步拉出那条历史摘要作为附录帮我更快判断这波下跌是否有新信息支撑。盘中大部分事件都是这种“快速提醒”模式原因是大模型不宜被卷入秒级决策循环。但 QuantBot 并没有完全禁用模型在盘中的角色。少数需要归纳判断的复杂事件它会走一条异步队列。比如某板块短时间内多只个股联动异动这种模式不能靠单只股票规则来捕捉需要一个更全局性的视角。此时盘中监控员会触发研究型任务把事件整体摘要交给盘后复盘分析师晚一点处理而不会实时在盘中硬算。这套“实时规则 延迟深度分析”的组合在工程上解决了响应速度和推理深度的矛盾。4.3 收盘后 15:05-16:30数据对齐后的复盘报告与经验沉淀收盘后QuantBot 进入清算和复盘阶段。它不会在收盘那一刻立刻让复盘 Agent 开始分析而是先等待数据对齐模块完成工作。这个模块会去核对当天行情数据的最终快照、账户成交流水、Agent 产生的事件日志三份数据按股票代码和时间戳做交叉对齐。如果发现某条成交记录在行情快照里对应不上系统会把这条单子单独标记出来防止复盘时误判。大约在 15:40 左右数据对齐确认无误盘后复盘分析师启动。它会读取当天所有事件日志与操作记录按照“纪律执行、策略归因、次日准备”三个维度生成复盘报告。这份报告不会很长一般控制在三到五百字的核心摘要但它最大的价值在于“基于数据打分”不再靠我一天结束后的模糊记忆。比如当天我因为某条低置信度信号进行了临时加仓复盘报告就会明确写着“该次操作与盘前计划不符且信号置信度为 0.55存在纪律偏差风险。”这种客观结论是对交易者最有用的反馈。最后复盘 Agent 会从当天报告中提炼一段结构化经验摘要写入长期记忆库。这些摘要不会立即影响次日策略但会在次日盘中事件触发时作为上下文节点被系统拉取。至此一个完整的盘前-盘中-盘后闭环才算真正收口信息从盘前进入经过盘中验证在盘后被结构化归档并反过来影响次日盘前信息处理。4.4 值得留意的风险闭环会自动放大错误吗这是我最想提醒大家注意的问题。闭环系统最隐蔽的风险不是单一环节出错而是错误会被第二天“正当化”。比如某天盘前事件清单里有条低质量新闻但没人留意它的来源盘中真的驱动了一次操作到了盘后复盘报告会把它记录为“当日操作依据”。再过一天这条可疑的消息可能就被当作“历史经验摘要”进入长期记忆成了未来决策的上下文。整个过程每一步看起来都合理但源头其实已经不可靠。QuantBot 给出了一部分解决方案比如每条要写入长期记忆的事件必须包含数据来源与置信度。但更深层的防范得靠人的联动每隔一段时间我会主动去翻查记忆库里沉淀的摘要删掉明显过时或来源不可靠的历史条目。量化闭环的目标是帮你管理上下文但没人能替你做最终的经验淘汰。把这一点想清楚才不会从一个数据陷阱掉进另一个更隐蔽的记忆陷阱。5. 跑了近一百个交易日后我沉淀下来的一些工程取舍如果你也在规划类似的 AI-Agent 量化工作台我应该先分享一些初期的关键决策考量。首先是 API 成本预算问题。多 Agent 系统每天的模型调用次数远远超过单 Agent 方案不过控制成本的方式不是限制使用而是做任务路由。规则能处理的就绝不调用模型需要用模型的任务也尽量缩短上下文和输出长度。QuantBot 的盘前事件摘要和盘后复盘是最高频的模型调用场景而盘中大量规则判断走的是纯代码路径模型只负责少数事件的二次解读和推送改写成本总体可控。其次是模型选择。不同 Agent 完全可以选用不同的模型。盘前研究员侧重长文本的抽取和结构化整理我会偏向上下文窗口大的模型盘中监控员由于任务简单、对速度敏感几乎不需要大模型介入即使需要我用的也是延迟较低的轻量模型盘后复盘分析师需要较强的推理能力会选用较强模型。很多团队一开始就统一用某个“最强模型”其实多数任务是浪费的。5.1 LLM 幻觉在量化复盘里会被放大一定要做“引用校验”前面提到过多 Agent 系统最怕错误逐层放大。在实际运行中LLM 幻觉问题在盘后复盘中体现得最为明显。复盘 Agent 在分析某只股票的日内波动原因时如果新闻语料库里没有足够多的依据它会倾向用“疑似受市场情绪影响”这类套话更麻烦的是它有时会把不存在的“新闻”或“公告”写进归因里。我采取的办法是给盘后复盘 Agent 增加一个强制约束所有归因必须附带来源 ID也就是它引用的新闻、公告、行情事件都要对应到一个数据库记录。如果它写了一条没有来源 ID 的说法系统会在后处理阶段直接丢弃并标记为“未验证论断”。这一招把幻觉通过系统层过滤掉了而不是把希望寄托在模型的自觉上。我对这个设计印象非常深——它把模型的输出从“可信或不可信”变成一个可编程校验的对象很大程度上提升了整个系统的可靠性。5.2 多 Agent 协作的前提是先有稳定接口而不是先写提示词很多朋友一上来就兴奋地写提示词、开搞 Agent 对话常常忽略了底层的数据库、事件总线、接口是否已经就绪。我在刚起步时也想让 Agent 直接读取“行情”后来发现行情源不稳定、数据结构不一致模型再强也救不了。所以我的经验是先花时间把行情接口、持仓数据、操作流水、日志表彻底梳理一遍所有数据都有了干净的访问接口再考虑把这些接口接入 Agent。没有稳定管道再好的 Agent 也只是花架子。QuantBot 走到今天真正硬核的部分并不是那些复杂的提示词而是稳定的数据链路、明确的消息格式和一套能追溯状态的主题。Agent 反而是最容易替换的那一层。5.3 Agent 的权限必须最小化每个 Agent 只拿到完成本职工作所需的工具权限最小化是安全设计的重要一环很多人容易忽略。盘前研究员不需要知道你的券商交易密码盘中监控员不应该有权限直接改持仓盘后复盘分析师也没必要调用实盘下单接口。在 QuantBot 中每个 Agent 的工具集都是被硬隔离的甚至它们访问数据库都只能用只读账号。这个设计让我在接入新模型或调整提示词时不用心惊胆战就算某个 Agent 的提示词出现意外它也只有读取信息的能力无法对账产生破坏。对个人开发者而言这一条尤其是省心省力的保障。5.4 兜底方案永远是“人工可接管”而且接管动作要留痕我最终坚持的人工接管原则是在经历了几次模型 API 异常后才真正刻进系统里的。有一天模型调用连续失败QuantBot 的盘前研究一度没有输出。如果我在设计时把所有逻辑都绑定在模型返回上那天早上我就等于瞎了。后来系统增加了一个降级模式一旦检测到模型服务异常会退回到最基础的规则引擎模式仍然把行情摘要和日程提醒用短信推给我只是没有 AI 解读。这样即便 AI 服务全挂盘前该有的基础信息也不缺。更重要的是每次人工接管时系统会记录操作时间、原因和最终动作。月末回看这些人工接管记录本身就是很珍贵的复盘素材能看出哪些场景是自动化处理不了的哪些是我因为情绪而做出的非计划干预。这些记录和周报一起构成了完善 QuantBot 的参考坐标。6. 想复刻这套工作台的新手我建议你先不要做大的QuantBot 能做到这个完整度不是一次性搭建出来的。如果你现在刚开始接触 AI-Agent 和量化我强烈建议你先不要照抄这个全量架构。你从一条最简单的直线闭环入手反而更容易见效每天盘后把当天的行情数据和自己的操作记录存下来用一个大模型生成复盘摘要并归档。执行一周后再回头检查找出这份摘要里哪些地方不符合实际然后开始迭代设计。复盘的 Agent 一定要先做起来它最贴近我们的日常需求也能让你快速感受到量化闭环的价值。当你觉得单条盘后复盘线已经能稳定跑通再逐渐加入盘前研究 Agent然后是盘中监控规则。每一步都在上一轮跑出的数据接口和数据结构上扩展你会少走非常多弯路。我见过太多人想一步到位建一个多 Agent 机器人结果卡在连数据源都没理顺的地方项目不了了之。真正有效的方式是让系统先能回答你一个具体问题例如“今天为什么错过了一次加仓”再逐步让它能自己生成这些问题。6.1 推荐从单一 Agent 起步的小型最小闭环具体而言第一个最小闭环推荐做成这样每天收盘后把持仓、成交、全天行情快照塞给一个 Agent让它输出一份 300 字以内的复盘日报并存入一个独立文件夹。然后你用一周时间观察这份日报的质量手动修正模型输出里的错误。第二周你开始给它补充新闻数据接口观察归因是否变得准确。第三周再加“关注池”和简单的盘中提醒用量化规则触发事件用模型解读。这样一个版本一条线每一条线上线前都要有过往归档数据可供验证。它带来的直接好处是即使你完全没有 AI-Agent 开发经验也能在两周内跑出一个像样的“量化工作台雏形”然后自由改进。6.2 工具选型与成本控制的实际建议最后说说技术选型。QuantBot 的消息总线最开始甚至没有用专门的消息队列框架只是用 SQLite 里的任务表加轮询实现的数据量小时完全够用。后来事件量大了才更换成一个更完整的消息系统。数据库层面如果是个人项目SQLite 或本地 JSON 文件存储已经可以支撑前期的所有功能不要一上来就上重型的数据库集群。整体原则是能跑通的最小栈优先不要在第一步引入和行情无关的新框架。模型调用层面价格策略是另一个实用的经验点。盘前与复盘时段的任务对实时性要求不高可以用质量更强的模型因为此时慢一点没关系盘中提示更需要延迟低且便宜的小模型。不同任务的模型选型差异会让总成本比“无脑全用强模型”低很多。我个人到现在依然不打算让 QuantBot 自动下单。多一个 AI-Agent 写复盘也好、盯盘也好本质上还是给决策者装上一个更清晰的外脑。等哪一天系统能稳定输出“为什么做这个决策”以及“为什么不做那个决策”它就已经完成了我最初想它干的大部分事了。你如果也在搭类似的工具我建议先抓住那一件最让你头疼的事把它做透比什么都重要。 
长河君 · 2026/9/4 3:24:39 · 阅读 1.2k 多AI-Agent量化工作台QuantBot：从盘前到盘后的自动化闭环设计
说实话我一开始搭 QuantBot 这个多 AI-Agent 协作量化工作台并不是因为“AI-Agent 很火所以我要追一下”。而是我自己的复盘习惯实在撑不住了收盘后想回看当天到底为什么做这个判断结果翻聊天记录、翻 K 线截图、翻订单流水每次都要折腾一两个小时。后来我就在想能不能让几个 AI-Agent 各自负责一段事帮我把盘前、盘中、盘后整个流程串成一个自动化闭环数据、结论、原因都能自动留下来。这就是 QuantBot 的起点。这篇文章我把整套系统的设计思路、Agent 分工、闭环跑法、踩过的坑一次讲清楚给同样想把自己量化工作流改造一遍的朋友做个参考。如果你正准备做量化但对代码和 AI-Agent 的组合怎么落地还没把握这篇文章也适合你。因为我不光会讲 QuantBot“是什么”更会讲清楚为什么每个环节要这么拆、每个 Agent 为什么这么分工以及哪几步是真正让我觉得“没白做”的。1. 为什么要用多个 AI-Agent 协作而不是写死一套自动交易脚本先讲一个最容易被误解的点。很多人一听“量化工作台”“AI-Agent”下意识觉得这是要做一套全自动炒股机器每天自动选股、自动下单、自动赚钱。如果你也抱着这个期待那我劝你先冷静。QuantBot 做的事不是替代你的投资判断而是把所有需要“人力去读、去盯、去整理、去复盘”的环节接过去把每一个判断背后的上下文压缩成几分钟就能看完的摘要。它更像一个能一起开会的研究员团队而不是一个替你按下买入键的执行器。那为什么不让一个大模型把从盘前到盘后所有事情全干完说实话我在早期原型里试过单 Agent 方案给一个模型塞了行情接口、新闻接口、持仓接口、复盘模板让它一个人当全能选手。结果非常现实日内运行时它会因为一条盘中新闻触发长篇分析导致核心盯盘任务被拖慢到了盘后复盘时它的上下文里还混着早上那些盘中噪音归因归得乱七八糟。问题不在于模型能力不够而在于你让一个“人”同时干研究员、交易员、风控员、复盘员它一定会角色混乱。类比一下你就懂了你去一家公司办事一个前台把所有部门的活全包了效果一定很差。真正高效的架构一定是分工明确的前台只负责接待和分流财务只对账法务只看合同。多 AI-Agent 协作本质上就是这个逻辑。每个 Agent 只拥有一段非常明确的职责边界、有限的工具权限、高度聚焦的提示词这样它的输出才稳定、可解释出了问题也知道去查哪一环。所以 QuantBot 的第一个设计原则就是把量化工作流按“认知分工”切成独立 Agent而不是把所有工具堆给一个 Agent。这个原则决定了后面所有消息结构、编排逻辑和权限设计。每多一个 Agent虽然会增加系统复杂度但换来的好处是每个环节的上下文都干净、可控出问题能快速定位模型之间的意图也不会互相污染。1.1 单 Agent 做量化的三个致命问题把单 Agent 跑量化的问题说细一点其实是三个。第一是上下文窗口的争夺。行情数据、新闻资讯、历史持仓每一类都是大量信息单个 Agent 要把这些都塞进上下文里才能干活但窗口是有限的它往往只能“记住最近的”而关键的历史判断早就被挤出去了。第二是错误无法隔离。盘前新闻解析出错和盘中行情误判是完全两类问题如果让同一个 Agent 处理你很难判断哪里开始错的因为整个链条都黏在一条 prompt 里没法单独验证某个环节。第三是实时性与深度的冲突。实时盯盘要求秒级响应而盘后再分析要求长时间推理完全不同的响应模式塞进同一个 Agent结果就是实时任务被推理任务阻塞深度任务又被实时任务打断。QuantBot 里我把这些冲突用 Agent 边界切开了盘中监控 Agent 只做行情窗口里的快速判断和消息触发盘后复盘 Agent 可以慢慢读数据、算归因、生成报告。两者互不占用对方的资源和上下文各自用各自的时间尺度运行。你可能觉得这是技术细节实际上这是整个系统稳定性的根基。1.2 QuantBot 和其他量化系统最关键的区别人机边界真正用过一段时间 QuantBot 之后我更加确信一个观点AI-Agent 量化系统解决的是“上下文管理”问题而不是“投资决策”问题。投什么、买多少、什么时候止损这些最终应该由人来做决定。Agent 能替你做的是保证你在做这些决定的时候手里拿到的材料和数据是完整的、有依据的、可追溯的。QuantBot 里专门留了几个人工确认点盘前生成的操作事项清单需要你过目盘中信号只有达到较高置信度才会推送提醒而且不会自动执行盘后复盘中涉及关键持仓调整的建议同样只作为建议存在。这几条看着损失了“全自动”的效率但长期看救了我很多次。因为模型会犯错、数据会延迟、市场会出现预案之外的走势出现这些情况时如果没有人守在决策环上一个错误会被系统自动放大。这套工作台的定位是让一个认真做交易的普通人拥有一个十人研究团队的信息处理能力但最终方向盘必须握在自己手里。2. QuantBot 的 Agent 分工与能力设计QuantBot 不是一个“巨型模型”而是一组各管一摊的“数字员工”。我一共设置了四个核心 Agent外加一个主控调度器。每个 Agent 有专门的提示词、职权范围、工具集和输出模板绝不越界。下面我把它们的角色和设计逻辑展开讲。2.1 盘前研究员把海量噪声压缩成可决策的事项清单这个 Agent 每天开盘前启动负责处理三件事昨夜外盘和重要资产的走势概况、与持仓或关注池相关的新闻公告、当天日历上可能引发波动的宏观事件。它的输出不是一篇又长又泛的行情综述而是一份结构化的“盘前事项清单”每一条都包含事件、关联标的、影响方向、置信度四个字段。这里的一个核心设计是要求置信度。我一开始没做这个约束结果这个 Agent 喜欢写“XX 板块或受情绪提振”模糊不清我没法判断哪条重要哪条次要。后来我把输出模板里加了一个“置信度打分”字段0 到 1 之间并要求它只给有明确信息支撑的条目打分。同样一条新闻如果只是自媒体讨论置信度就很低如果是公司公告或官方数据置信度就高。这样我早上扫一眼清单只挑高置信度的事深入看效率提升非常大。盘前研究员的另一个关键点是它必须知道“我持仓什么、关注什么”。所以我给它配置了一个只读的持仓和关注池数据接口同时保留了一个向量记忆库让它能查阅过去一周自己生成的报告。这样它能回答“这只票昨天那条利空到底消化完没有”这类需要时间上下文的问题而不只是给一个今天的信息快照。2.2 盘中监控员秒级响应但不做深度分析盘中监控员是 QuantBot 里唯一对实时性要求最高的 Agent。它只负责一件事盯着行情和中标事件一旦出现预设规则的触发就生成一条“警报事件”丢到消息队列里。它不会去写长文分析不会去查历史数据更不会给出买卖建议。它的输出就是极其简短的结构化事件比如“持仓 XX 在 10:32 出现放量下跌成交量是过去5日同时段均值的 2.3 倍”。为什么不让盘中 Agent 做分析因为大模型推理速度根本跟不上行情变化的速度。我曾经试过让它在触发警报后用模型生成解释结果平均耗时在 4 到 9 秒之间等它把解释写出来行情可能已经走完一个阶段了。所以 QuantBot 的策略是用确定性规则做筛选用模型做筛选后的二次判断和摘要。只有当警报进入高优先级通道才会调用模型生成简短解读并推送给人的确认端。盘中监控员对延迟有最高要求所以我单独给它接了一个低延迟通道其他 Agent 用的是普通队列。这个 Agent 还有一个特殊设计每次收盘后它会自动“失忆”清空当天积累的临时缓存避免把当天所有高频噪音带给次日会话。这种状态隔离在长周期运营里非常重要。2.3 风控复核 Agent唯一有“否决权”的角色风控复核 Agent 是我后来加上的。一开始我以为只要有了盘中监控就不需要额外的风险控制 Agent。结果有一段时间策略信号连续触发盘中监控员不断推送提醒我有点疲劳差点漏掉其中一条偏离我原始止损计划的信号。那次之后我就想QuantBot 里必须有一个角色专门盯着“人的纪律”而不是“市场机会”。风控复核 Agent 的输入是所有即将提交给人确认的买卖提醒和操作建议。它不管这笔交易是否赚钱只管一件事这个操作是否在既定的风控规则框架内。比如单笔仓位是否超限、总仓位是否接近风险阈值、如果是加仓操作是否符合原计划的加仓条件。当它检查到某条提醒超出预设参数时它会生成一个“否决标记”并附上具体原因。人虽然仍然可以选择忽略这个否决但必须多一步确认而且这个否决记录会留档出现在盘后复盘报告中。这个设计表面上是给流程添堵实际上它保护的是人在情绪波动时的判断力。人总有冲动的时候市场狂热或恐慌的瞬间一个强制要求“多确认一次”的缓冲点价值巨大。2.4 盘后复盘分析师从操作记录里提取经验不写流水账盘后复盘分析师大概是所有 Agent 里最适合发挥大模型能力的角色因为它没有实时性压力可以慢慢读数据、做归因、写报告。它的输入是当天所有 Agent 生成的事件日志、所有成交和操作记录、以及当天的行情数据快照。输出是一份复盘摘要分成三个模块纪律执行情况、策略表现归因、明日注意事项。我特别想强调的是纪律执行情况的刻画。过去我自己复盘总爱找外部理由——“今天市场不好”“这条消息来得太突然”。但 QuantBot 会把当天所有提醒、否决、漏看的情况列出来对照我的最终操作直接指出我有没有执行原计划。这个模块刚上线前两周相当扎心因为它会毫不留情地显示我在某些时刻偏离了计划。但恰恰是这种不留情面让我在后面的实盘运行中更有意识地遵守自己的交易纪律。为了归因可信盘后分析师必须拿到“对齐后的数据”。也就是收盘后会有大约二十分钟的静默期等券商结算和行情快照都稳定了再把数据喂给它。否则它拿到的盘中快照和最终数据有差异归因就会失真。这是数据工程层面的细节但直接影响复盘质量。3. 完整闭环是怎么串起来的主控编排、消息队列与状态记忆单有 Agent 角色还不够QuantBot 要形成一个完整的“盘前-盘中-盘后闭环”核心在于编排层。我把它拆成了三块主控调度器、消息总线、状态存储。这个架构看起来像普通的微服务但它比微服务更强调“每个 Agent 都是被动触发的工人”彼此之间不直接通话只通过消息总线异步协作。这样设计最大的好处是解耦。比如盘前研究员昨晚意外失败了盘中监控员完全不受影响照常运行盘后复盘分析师到点之后发现盘前数据缺失它会在报告里明确标注“该日盘前生成失败”而不会因为依赖环节断裂而崩溃。对量化这种长周期系统来说每个环节都不能因为其他环节的临时故障歇菜。异步消息是这一切的基础。3.1 主控调度器一个像闹钟又像状态机的东西QuantBot 的主控调度器逻辑不复杂核心是一个状态机加定时触发器。每个交易日里系统会根据时间把运行状态依次切换为盘前准备、盘中监控、收盘清算、盘后分析、结果归档。每个状态切换时调度器往消息队列里发送一条“状态切换事件”相应的 Agent 收到事件后开始自己的工作。下面这段伪代码可以更直观地表达这个流程while market_day_running: current_state get_current_state() if current_state PRE_MARKET and time_reaches(07:00): publish_event(pre_market_start) # 盘前研究员开始工作生成事项清单 elif current_state INTRADAY and time_reaches(09:15): publish_event(intraday_start) # 盘中监控员订阅行情事件开始盯盘 elif current_state INTRADAY and time_reaches(15:00): publish_event(intraday_end) # 盘中监控员进入休眠缓存清空 elif current_state POST_MARKET and data_reconciliation_done(): publish_event(post_market_start) # 盘后复盘分析师开始读取对齐数据生成复盘报告 elif current_state ARCHIVING: archive_all_reports() save_state_snapshot() reset_memory_for_new_day()你可能会问为什么不用现成的调度框架 Cron 就完了因为量化交易日里的状态切换不只是时间触发还依赖条件。比如收盘清算这个状态如果当天数据接口延迟你必须等数据对齐后再触发盘后分析死板的定时任务没法处理这种依赖。用状态机的好处是每一个状态都清楚自己的前置条件和后置动作也方便中途人工介入。3.2 Agent 之间不直接对话通过结构化消息协作在 QuantBot 早期测试中我犯过一个很典型的错误让一个 Agent 直接把输出结果作为另一个 Agent 的提示词上下文也就是 Agent 直接“对话”。看起来灵活实际上一旦链路变长错误信息会在 Agent 之间逐层放大。Agent A 输出里有一点小偏差Agent B 没发现并继续推理到 Agent C 那里偏差已经被放大成“事实”。所以后来我废掉了 Agent 之间的自由对话模式要求所有 Agent 之间的信息传递都必须使用结构化的消息对象。每条消息至少要包含事件类型、产生时间、数据来源、置信度、正文载荷这几个字段。例如盘中监控员发出一条警报事件格式大致是{ event_type: alarm_price_drop, producer: intraday_monitor, timestamp: 2025-05-16T10:32:0708:00, symbol: 000001, confidence: 0.82, payload: { price_drop_pct: 3.5, volume_ratio_vs_ma5: 2.3 } }这个格式的好处是盘后复盘分析师读取事件时不需要再去解析一段模糊的自然语言文本而是直接读取结构化的字段进行数值计算和归因统计。Agent 的输出越结构化整个系统的可控性就越强。做多 Agent 系统时一定要记住一条Agent 之间的接口最好比人和 Agent 之间的接口更严格。3.3 状态和记忆的存储长期有档案短期可失忆状态记忆是 QuantBot 能形成“闭环”的另一个关键。我采用的是冷热分离的存储方案实时运行期间需要快速访问的数据放 Redis例如日内触发的警报队列、当前仓位快照、当日临时状态需要追溯的完整历史信息放 SQLite 或文件存储例如每天的盘前清单、盘后报告、操作确认日志。每天开盘前系统会用一个轻量级的“记忆重置”过程把前一日的临时缓存清掉只保留长期档案和历史复盘沉淀出的“经验摘要”。这个经验摘要是盘后复盘 Agent 在每天结束前自动生成的一段结构化文本比如说“过去三天持仓 X 连续放量下跌但基本面未变考虑是否属于情绪错杀”——它会被存入长期记忆库成为第二日盘前研究员的参考上下文。这样一来系统就有了跨日的记忆能力而不是每天从零开始。我当时在设计这个记忆机制时参考了很多架构上的做法。太像长期团队积累会带来知识混乱太小会丢失有价值的历史背景。 QuantBot 的选择是只有沉淀后的结构化摘要能进入长期记忆原始聊天记录和日志都只做归档不做记忆检索。这样既避免了大模型长期上下文无限膨胀的问题也保证了历史信息是可追溯、可校验的。3.4 延迟、超时和失败降级稳健性不是可选项任何一个接入了外部 API 的自动化系统都必须面对服务的不可用风险。行情接口偶尔抽风模型 API 偶尔超时券商交易接口偶尔维护这些都是必然的。QuantBot 的每个外部调用都要配置独立的超时时间和重试策略并且明确规定某个 Agent 调用失败时系统是直接跳过还是发警告让人工接手。举个例子盘中监控如果发现行情 Provider 超过 3 秒没返回最新数据它不会被阻塞在那里瞎等而是立刻生成一条“行情延迟”事件把最近一个已知快照的时间戳标注出来。这样我看到的信号如果用了延迟数据至少不会误以为是实时状态。QuantBot 里许多运行时的诡异问题最后排查下来都是数据延迟造成的时间戳错位所以“宁可慢一点不可不知情”是实时环节的第一原则。4. 一个真实交易日的时间轴QuantBot 的闭环完整走了一遍很多朋友看了架构图会问我这系统听着挺完整那现实中一天是怎么跑下来的我这里复盘一个比较典型的交易日完整展示盘前、盘中、盘后三个时间段里 QuantBot 到底都做了什么。这个时间段是根据个人工作习惯定的你可以根据自己交易的市场节奏微调。4.1 盘前 07:00-09:00自动生成 12 条关注事件早上 7 点QuantBot 的主控调度器发出“盘前开始”事件盘前研究员被唤醒。它先读取持仓与关注池清单然后并行拉取隔夜的外盘指数、大宗商品、公告新闻、宏观日历。大概 7:35一份带置信度评分的盘前事件清单出现在我的手机推送里。这份清单通常有 10 到 20 条事项但它不是简单罗列新闻而是只保留与关注池相关的信息并按影响方向分类。我记得有一次盘前研究员在清单里列了一条某只持仓股昨日晚间发布成绩预告预计净利润同比增长 40% 到 60%置信度 0.9关联方向“偏多”。如果我没看到这条早上开盘我大概率会在低位犹豫而实际上我看到刺激清晰的清单后心里对“今天即便低开也不轻易割”做好了预案。这就是盘前研究的价值——不是预测走势而是让可能影响一天判断的关键信息不遗漏。同时风控复核 Agent 在盘前也会自动跑一遍比对当前仓位和最新持仓规则检查有没有规则的执行在昨晚发生了变化。比如如果是调仓日它会自动提示“今日计划调仓注意总仓位限制”这个提示会在盘前输出里与研究员的事件并列展示。4.2 盘中 09:30-15:00行情触发事件研究型问题进入异步队列开盘后盘中监控员接管主导权。它会以较高的频率轮询行情接口并运行一组盘中规则。这些规则包括持仓股短时间内上下波动超过预设阈值、成交量较近期均值异常放大、自选股触及关注价格等。一旦命中它会在 1 秒内生成警报事件并推送给我。比如持股在盘中突然快速下探跌破我预设的一个观察位盘中监控员会推送一句很简短的话“XX 当前跌破观察位 3.2%成交量为近期 1.8 倍。建议查看是否有新的消息面触发如需操作请确认。”它不会自动止损也不会说“赶紧割肉”它只是把客观状态送到我面前把决策权和执行权留给我。如果触发的同时盘前研究员的结论里有相关背景系统会同步拉出那条历史摘要作为附录帮我更快判断这波下跌是否有新信息支撑。盘中大部分事件都是这种“快速提醒”模式原因是大模型不宜被卷入秒级决策循环。但 QuantBot 并没有完全禁用模型在盘中的角色。少数需要归纳判断的复杂事件它会走一条异步队列。比如某板块短时间内多只个股联动异动这种模式不能靠单只股票规则来捕捉需要一个更全局性的视角。此时盘中监控员会触发研究型任务把事件整体摘要交给盘后复盘分析师晚一点处理而不会实时在盘中硬算。这套“实时规则 延迟深度分析”的组合在工程上解决了响应速度和推理深度的矛盾。4.3 收盘后 15:05-16:30数据对齐后的复盘报告与经验沉淀收盘后QuantBot 进入清算和复盘阶段。它不会在收盘那一刻立刻让复盘 Agent 开始分析而是先等待数据对齐模块完成工作。这个模块会去核对当天行情数据的最终快照、账户成交流水、Agent 产生的事件日志三份数据按股票代码和时间戳做交叉对齐。如果发现某条成交记录在行情快照里对应不上系统会把这条单子单独标记出来防止复盘时误判。大约在 15:40 左右数据对齐确认无误盘后复盘分析师启动。它会读取当天所有事件日志与操作记录按照“纪律执行、策略归因、次日准备”三个维度生成复盘报告。这份报告不会很长一般控制在三到五百字的核心摘要但它最大的价值在于“基于数据打分”不再靠我一天结束后的模糊记忆。比如当天我因为某条低置信度信号进行了临时加仓复盘报告就会明确写着“该次操作与盘前计划不符且信号置信度为 0.55存在纪律偏差风险。”这种客观结论是对交易者最有用的反馈。最后复盘 Agent 会从当天报告中提炼一段结构化经验摘要写入长期记忆库。这些摘要不会立即影响次日策略但会在次日盘中事件触发时作为上下文节点被系统拉取。至此一个完整的盘前-盘中-盘后闭环才算真正收口信息从盘前进入经过盘中验证在盘后被结构化归档并反过来影响次日盘前信息处理。4.4 值得留意的风险闭环会自动放大错误吗这是我最想提醒大家注意的问题。闭环系统最隐蔽的风险不是单一环节出错而是错误会被第二天“正当化”。比如某天盘前事件清单里有条低质量新闻但没人留意它的来源盘中真的驱动了一次操作到了盘后复盘报告会把它记录为“当日操作依据”。再过一天这条可疑的消息可能就被当作“历史经验摘要”进入长期记忆成了未来决策的上下文。整个过程每一步看起来都合理但源头其实已经不可靠。QuantBot 给出了一部分解决方案比如每条要写入长期记忆的事件必须包含数据来源与置信度。但更深层的防范得靠人的联动每隔一段时间我会主动去翻查记忆库里沉淀的摘要删掉明显过时或来源不可靠的历史条目。量化闭环的目标是帮你管理上下文但没人能替你做最终的经验淘汰。把这一点想清楚才不会从一个数据陷阱掉进另一个更隐蔽的记忆陷阱。5. 跑了近一百个交易日后我沉淀下来的一些工程取舍如果你也在规划类似的 AI-Agent 量化工作台我应该先分享一些初期的关键决策考量。首先是 API 成本预算问题。多 Agent 系统每天的模型调用次数远远超过单 Agent 方案不过控制成本的方式不是限制使用而是做任务路由。规则能处理的就绝不调用模型需要用模型的任务也尽量缩短上下文和输出长度。QuantBot 的盘前事件摘要和盘后复盘是最高频的模型调用场景而盘中大量规则判断走的是纯代码路径模型只负责少数事件的二次解读和推送改写成本总体可控。其次是模型选择。不同 Agent 完全可以选用不同的模型。盘前研究员侧重长文本的抽取和结构化整理我会偏向上下文窗口大的模型盘中监控员由于任务简单、对速度敏感几乎不需要大模型介入即使需要我用的也是延迟较低的轻量模型盘后复盘分析师需要较强的推理能力会选用较强模型。很多团队一开始就统一用某个“最强模型”其实多数任务是浪费的。5.1 LLM 幻觉在量化复盘里会被放大一定要做“引用校验”前面提到过多 Agent 系统最怕错误逐层放大。在实际运行中LLM 幻觉问题在盘后复盘中体现得最为明显。复盘 Agent 在分析某只股票的日内波动原因时如果新闻语料库里没有足够多的依据它会倾向用“疑似受市场情绪影响”这类套话更麻烦的是它有时会把不存在的“新闻”或“公告”写进归因里。我采取的办法是给盘后复盘 Agent 增加一个强制约束所有归因必须附带来源 ID也就是它引用的新闻、公告、行情事件都要对应到一个数据库记录。如果它写了一条没有来源 ID 的说法系统会在后处理阶段直接丢弃并标记为“未验证论断”。这一招把幻觉通过系统层过滤掉了而不是把希望寄托在模型的自觉上。我对这个设计印象非常深——它把模型的输出从“可信或不可信”变成一个可编程校验的对象很大程度上提升了整个系统的可靠性。5.2 多 Agent 协作的前提是先有稳定接口而不是先写提示词很多朋友一上来就兴奋地写提示词、开搞 Agent 对话常常忽略了底层的数据库、事件总线、接口是否已经就绪。我在刚起步时也想让 Agent 直接读取“行情”后来发现行情源不稳定、数据结构不一致模型再强也救不了。所以我的经验是先花时间把行情接口、持仓数据、操作流水、日志表彻底梳理一遍所有数据都有了干净的访问接口再考虑把这些接口接入 Agent。没有稳定管道再好的 Agent 也只是花架子。QuantBot 走到今天真正硬核的部分并不是那些复杂的提示词而是稳定的数据链路、明确的消息格式和一套能追溯状态的主题。Agent 反而是最容易替换的那一层。5.3 Agent 的权限必须最小化每个 Agent 只拿到完成本职工作所需的工具权限最小化是安全设计的重要一环很多人容易忽略。盘前研究员不需要知道你的券商交易密码盘中监控员不应该有权限直接改持仓盘后复盘分析师也没必要调用实盘下单接口。在 QuantBot 中每个 Agent 的工具集都是被硬隔离的甚至它们访问数据库都只能用只读账号。这个设计让我在接入新模型或调整提示词时不用心惊胆战就算某个 Agent 的提示词出现意外它也只有读取信息的能力无法对账产生破坏。对个人开发者而言这一条尤其是省心省力的保障。5.4 兜底方案永远是“人工可接管”而且接管动作要留痕我最终坚持的人工接管原则是在经历了几次模型 API 异常后才真正刻进系统里的。有一天模型调用连续失败QuantBot 的盘前研究一度没有输出。如果我在设计时把所有逻辑都绑定在模型返回上那天早上我就等于瞎了。后来系统增加了一个降级模式一旦检测到模型服务异常会退回到最基础的规则引擎模式仍然把行情摘要和日程提醒用短信推给我只是没有 AI 解读。这样即便 AI 服务全挂盘前该有的基础信息也不缺。更重要的是每次人工接管时系统会记录操作时间、原因和最终动作。月末回看这些人工接管记录本身就是很珍贵的复盘素材能看出哪些场景是自动化处理不了的哪些是我因为情绪而做出的非计划干预。这些记录和周报一起构成了完善 QuantBot 的参考坐标。6. 想复刻这套工作台的新手我建议你先不要做大的QuantBot 能做到这个完整度不是一次性搭建出来的。如果你现在刚开始接触 AI-Agent 和量化我强烈建议你先不要照抄这个全量架构。你从一条最简单的直线闭环入手反而更容易见效每天盘后把当天的行情数据和自己的操作记录存下来用一个大模型生成复盘摘要并归档。执行一周后再回头检查找出这份摘要里哪些地方不符合实际然后开始迭代设计。复盘的 Agent 一定要先做起来它最贴近我们的日常需求也能让你快速感受到量化闭环的价值。当你觉得单条盘后复盘线已经能稳定跑通再逐渐加入盘前研究 Agent然后是盘中监控规则。每一步都在上一轮跑出的数据接口和数据结构上扩展你会少走非常多弯路。我见过太多人想一步到位建一个多 Agent 机器人结果卡在连数据源都没理顺的地方项目不了了之。真正有效的方式是让系统先能回答你一个具体问题例如“今天为什么错过了一次加仓”再逐步让它能自己生成这些问题。6.1 推荐从单一 Agent 起步的小型最小闭环具体而言第一个最小闭环推荐做成这样每天收盘后把持仓、成交、全天行情快照塞给一个 Agent让它输出一份 300 字以内的复盘日报并存入一个独立文件夹。然后你用一周时间观察这份日报的质量手动修正模型输出里的错误。第二周你开始给它补充新闻数据接口观察归因是否变得准确。第三周再加“关注池”和简单的盘中提醒用量化规则触发事件用模型解读。这样一个版本一条线每一条线上线前都要有过往归档数据可供验证。它带来的直接好处是即使你完全没有 AI-Agent 开发经验也能在两周内跑出一个像样的“量化工作台雏形”然后自由改进。6.2 工具选型与成本控制的实际建议最后说说技术选型。QuantBot 的消息总线最开始甚至没有用专门的消息队列框架只是用 SQLite 里的任务表加轮询实现的数据量小时完全够用。后来事件量大了才更换成一个更完整的消息系统。数据库层面如果是个人项目SQLite 或本地 JSON 文件存储已经可以支撑前期的所有功能不要一上来就上重型的数据库集群。整体原则是能跑通的最小栈优先不要在第一步引入和行情无关的新框架。模型调用层面价格策略是另一个实用的经验点。盘前与复盘时段的任务对实时性要求不高可以用质量更强的模型因为此时慢一点没关系盘中提示更需要延迟低且便宜的小模型。不同任务的模型选型差异会让总成本比“无脑全用强模型”低很多。我个人到现在依然不打算让 QuantBot 自动下单。多一个 AI-Agent 写复盘也好、盯盘也好本质上还是给决策者装上一个更清晰的外脑。等哪一天系统能稳定输出“为什么做这个决策”以及“为什么不做那个决策”它就已经完成了我最初想它干的大部分事了。你如果也在搭类似的工具我建议先抓住那一件最让你头疼的事把它做透比什么都重要。