先说个反常识的判断：量化Agent最难的不是策略
上周在论坛翻到一个帖子，有人在做「自我进化的量化交易Agent」，面向A股、美股和加密货币，思路是用户用自然语言创建策略，系统持续读行情，在闭合K线上生成候选信号，再让大模型结合近期财经资讯复核，最后交给风控和模拟账户执行。
楼下第一个回复很扎心：「这得多大仓位、盈利、胜率才能覆盖成本」。第二个更狠：「子弹比策略先没」。
说真的，这些质疑都对，但都没说到我最在意的点。作者自己补了一句关键的话——「不需要一直调用大模型，是让大模型实现策略，本质还是程序在跑，大模型负责对策略模型定期反思」。
注意这句话背后的含义：既然是程序持续在跑、大模型定期反思，那这个系统真正的地基根本不是策略，是数据。行情往哪存、信号记在哪、模拟账户的每一笔虚拟成交怎么留痕、大模型要「反思」的时候去哪调历史——这些不解决，策略写得再花也是空中楼阁。
我自己折腾过类似的东西，一开始也是满脑子想策略，结果第三天就卡在「昨天那个信号到底为什么触发的，我查不到了」。这才是独立开发者最容易踩的坑。
为什么数据层一乱，Agent就废
量化Agent这类系统有个特点：它是长期运行的，还会自己「进化」。这就意味着两件事。
第一，你必须能回放。今天亏了一笔，你得能查出来是哪个信号、什么价位、当时大模型看了哪条资讯做的复核。
查不到，你连改都不知道从哪改。
第二，数据结构会随时间变脏。策略在变、参数在调、模型在换，如果所有东西都塞在几个日志文件或者一堆JSON里，跑一个月你自己都看不懂了。
我见过一种典型的错误做法：把行情、信号、账户状态、资讯全堆在内存或者散装文件里，图省事。刚开始跑得挺顺，等到要复盘、要对账、要给大模型喂历史上下文的时候，整个人傻眼。
这跟那个做Minecraft备份插件的老哥遇到的问题异曲同工——存档数据一旦超过预期，之前偷懒的架构会直接把你憋死。
所以我的观点很明确：动手写策略之前，先把数据分成三类想清楚，分别用对的地方存。
三类数据，三种存法
量化Agent的数据其实能拆成很清楚的三块，我一块块说。
**第一块，结构化的「账本」类数据。 ** 信号记录、持仓状态、模拟账户的每一笔虚拟成交、每次风控的判断结果——这些天生就是表格。
有时间、有品种、有价格、有方向、有状态。这类数据最怕的就是查不了、对不上。
这种场景我会直接用SQLite当账本。它轻,一个文件就是一个数据库,不用另起服务,特别适合独立开发者单机跑的Agent。
信号表、持仓表、成交流水表分开建,该有索引有索引,复盘的时候一条SQL就把某天的所有信号捞出来。调试阶段想直接看某张表现在长什么样、有没有脏数据,用SQLite编辑器打开点两下就行,不用为了看个表结构专门写查询脚本。
**第二块,非结构化的资讯类数据。 ** 帖子里提到大模型要「结合近期财经资讯复核」信号。
财经新闻、研报片段、公告——这些是纯文本,而且大模型需要的是「语义相关」,不是精确匹配。你不可能用SQL的LIKE去搜「跟这只票基本面相关的最近消息」。
这块我会用向量库来做语义召回。把抓来的资讯切片、向量化存进去,信号触发的时候按语义捞出最相关的几条喂给大模型复核。
用LanceDB知识库来干这件事比较顺手,它就是为这种「存文本、按语义查」的场景设计的,不用你自己去拼一套检索逻辑。
这里要提醒一句,资讯这东西风险不小。论坛里有个《AI Trust》系列专门讲过,「RAG让Agent变聪明,也让它记住错误」——如果你灌进去的资讯本身是错的或者过时的,大模型会拿着错误信息一本正经地做复核。
所以资讯入库前的清洗和时间戳,该做还得做,别偷懒。
**第三块,行情数据。 ** 这块看你的频率。
如果是分钟级、日线级的闭合K线,量不算爆炸,同样可以进SQLite按品种建表。真到高频那种量级,那是另一个话题了,超出独立开发者单机方案的范围,这里不硬扯。
一个随时能查的持仓看板,比你想象的重要
数据存好了,还差一步:你得能随时看。
我踩过的一个坑是,数据都进库了,但每次想知道「现在几个策略在跑、模拟账户浮亏多少、今天触发了几个信号」,都得手动敲SQL。跑起来一忙,根本没耐心天天敲,结果就是心里没数,出了问题才后知后觉。
后来我的做法是,拿HTML搭一个特别朴素的持仓看板,就几张表加几个数字:当前持仓、今日信号、账户净值曲线、最近一次大模型反思的结论。数据从SQLite里读,页面托管起来,手机上随时能刷一眼。
这个看板不需要多好看,信息密度到位就行。它的价值不在于炫技,在于让你对这个「自己会进化」的系统始终有掌控感。
别小看这一点——一个你随时能查的系统,和一个只能等它出事的黑盒,是两种完全不同的东西。
顺带说个跟数据无关但很重要的判断
论坛里还有个帖子挺有意思,有人拿阿里新出的「决策模型」测「删除users表全部数据安不安全」,结果模型给出安全和不安全各50%的概率,告诉它「数据库没备份」之后,它反而判定更安全了。
这事跟量化Agent有什么关系?关系大了。
它提醒你一件事:别把关键的安全判断完全交给大模型。风控这种「该不该下这一单、仓位超没超限」的判断,最好是确定性的规则,写死在代码里,大模型只做辅助的信号复核。
那个量化帖的作者其实想明白了这点——「最终交给确定性风控和系统模拟账户执行」,大模型不碰执行。这个边界划得很对。
今天就能做的一个小动作
如果你也在琢磨量化Agent,或者任何一个长期运行、会自我调整的系统,别急着写策略。先干一件事:
拿张纸,把你系统里所有要存的数据列出来,一条条问自己「这是结构化的还是文本的?我要精确查还是语义查?
结构化的进SQLite,文本语义的进向量库,分清楚。
就这一步,能帮你躲开我当初三天查不到信号来源的那种狼狈。策略可以慢慢调,但数据地基,一开始就得铺对。