用自然语言写量化策略：Vibe-Trading多智能体回测工作台解析

1. 为什么是“Vibe”：自然语言写策略背后的产品逻辑

先聊一个我自己的困扰。做量化交易的人每天面对的是什么？不是行情，不是K线，而是代码。一个策略从想法到落地，中间隔着数据清洗、因子计算、回测框架、参数调优，一整套活。很多时候灵感来了，脑子里是一个完整的逻辑——比如“如果开盘后半小时成交量放大，且价格突破前20日最高点，就追进去，止损设1.5倍ATR”，但你得把这个想法翻译成Python代码，写半天，再调半天，等结果跑出来，可能市场节奏已经变了。

Vibe-Trading这个项目，本质上就是把“想法”到“回测”之间的那层翻译成本砍掉。它让你直接用自然语言描述策略逻辑，由工作台帮你把这句话转成可执行的回测代码，跑完把结果摆在你面前。你不需要手写pandas的rolling、shift、resample，不需要自己去接交易所API，甚至不需要关心止损逻辑该写成stop_loss还是trailing_stop。这就是我理解中“Vibe”这个词的含义——你给一个基调，它给你一段旋律。

这个方向适合谁？我觉得有三类人最适合：

• 刚入门量化、还没把代码练熟的研究者。策略逻辑你可能是懂的，但写代码就是卡壳，这个工作台能让你先跑通策略闭环，建立正反馈。
• 有经验的量化开发者。你以为你不需要？实际上你在做因子挖掘或者策略草稿验证时，用自然语言快速起一个原型，比你打开IDE敲半小时要快得多。尤其适合在饭桌上冒出灵感时，手机或平板上就能验证。
• 研究多智能体、LLM Agent方向的同学。Vibe-Trading把多智能体框架、LLM调用、策略回测串在了一个工作台里，是一个很好的研究载体，你想看LLM Agent怎么协同工作，它就是一个直观的沙盒。

一句话概括：这个工作台解决的是“策略从脑子到回测结果”这条链路的效率问题，顺带把多智能体研究放进了同一个环境里。

2. 工作台整体设计与架构拆解

2.1 核心模块到底有哪些

Vibe-Trading不是一个大杂烩，它按职责分成了几个清晰模块，每个模块只干一件事。我根据实际使用体验，把它拆成四层：

我个人认为，最值得琢磨的不是某一个模块多强大，而是它们之间的接口怎么设计。Vibe-Trading在这点上做得很利落——交互层和策略层之间隔着一个“策略中间表示层”，也就是说，LLM生成的不是一堆散乱的代码，而是一份结构化的策略描述文件。这个文件有点类似策略的“通用语言”，既有人类可读的字段，比如入场条件、出场条件、仓位管理、止损类型，也可以直接被回测引擎解析执行。

为什么要多这么一层中间表示？直接让LLM生成代码然后exec不好吗？我试过，直接exec是最省事但也最危险的做法。LLM生成的代码可能有语法错误，可能用了未导入的库，更麻烦的是它可能写出效率极低的循环逻辑，导致回测跑得非常慢。中间的策略描述文件相当于一个“半结构化关卡”，LLM先输出策略字段，再由模板引擎渲染成标准代码。哪个环节出错，你能精准定位到是“理解错了”还是“渲染错了”。这是个很务实的取舍。

2.2 数据层和回测引擎的设计选择

先说数据层。回测这事的根基就是数据，数据不对，策略再漂亮也是白搭。Vibe-Trading在数据层做了两件事：一是抽象了统一的数据接口，不管数据来自csv文件、数据库还是行情API，都能转成统一的时间序列格式；二是用本地缓存做了一层加速，回测过的数据按日线、小时线、分钟线分别存储，第二次跑就不用重新拉取。

这里有个细节很值得学习：它对前复权处理做了标准化。很多人回测时忽略复权问题，直接用原始价格，这会导致回测结果严重失真。分红除息在A股非常频繁，如果你的回测里没有处理复权，那长期策略的回测出来可能完全是假的——盈利可能是分红造成的，亏损可能是除息砸出来的。Vibe-Trading的数据适配器强制要求按前复权价格入库，如果数据源不支持复权，它会直接报错提醒，而不是默默给你一个错误的结果。

回测引擎方面，它采用的是事件驱动架构，而不是很多初学者爱用的向量化回测。事件驱动回测是逐根K线模拟真实交易流程的——每一根K线来了，先处理信号，再撮合，再更新仓位和资金，这中间会有滑点、手续费、涨跌停限制。向量化回测是直接把整个价格序列塞进数组公式里算，快是快，但没法模拟“我这一根K线收盘价才确定要下单，下一根K线开盘才能成交”这种时序约束。

用事件驱动引擎，一次性回测几千根K线，速度虽然不如向量化，但胜在真实。策略在实盘中遇到的执行偏差，在这个引擎里能被提前暴露出来。Vibe-Trading把延迟成交、滑点模型、手续费模型都做成了可配置项，你可以在回测的时候指定“我按下一根开盘价成交，滑点按0.02%算”，这样出来的结果才有参考价值。

2.3 为什么选择多智能体而不是单一大模型

这个项目叫“Vibe-Trading”，但它的研究价值很大程度上来自“多智能体”这个设计。你可能想问：现在LLM这么强，一个Agent吃点上下文不就能生成策略了吗？为什么还要搞多智能体？

单Agent的瓶颈在于身份和视角的单一性。你让一个LLM同时扮演策略设计者、回测分析者、风险控制者、市场解读人，它确实能完成，但它的判断会被单一提示词束缚——它会倾向于坚持自己第一次生成的策略逻辑，就算回测结果不好，它也会想办法找外部原因搪塞过去，而不是自我否定。

多智能体的核心思路是：把不同职责拆给不同的Agent，让它们各守一摊，互相质疑、互相验证。Vibe-Trading里至少跑了这么几个Agent：

• 策略生成Agent：负责把自然语言描述转换成结构化策略。
• 回测执行Agent：负责任务调度、执行回测、收集结果。
• 风险审计Agent：专门盯着最大回撤、夏普比率、风险暴露这些指标，策略收益再高，只要回撤超了它的底线，它就会打回重做。
• 市场研究员Agent：负责解读当前宏观环境或市场风格，给策略生成Agent提供“背景情报”。

这几个Agent之间不是简单的“你做完传给我”，而是有一个意见反馈回路。策略生成Agent产出一个策略，回测执行Agent跑完，风险审计Agent给出否定意见，这个意见被打回给策略生成Agent，要求它修改参数或者调整逻辑，然后再跑一轮。如此反复，直到所有Agent都点头，这个策略才算过关。

这个机制解决了一个我长期以来的痛点——回测过拟合的审查。以前我自己做策略，回测跑出年化60%，第一反应是“我是不是发现了圣杯”，第二反应才是“这里会不会过拟合”。但人很难对自己的策略保持客观，尤其是辛苦调出来的。多智能体里有了专门唱反调的风险审计Agent，它没有“保住这个策略”的心理包袱，反而能更冷静地把最大回撤、换手率、单笔亏损分布这些指标翻出来看。

3. 多智能体的配置与协同机制

3.1 多智能体的角色定义与上下文隔离

多智能体系统最常见的问题是“角色混淆”。在Dify这类平台上做多Agent编排时也经常遇到——Agent A和Agent B共用一套上下文，结果Agent B没有坚守自己“风险审查”的定位，反而被Agent A带跑偏，开始一起想办法优化策略。

Vibe-Trading的解法是上下文隔离。每个Agent有自己独立的提示词模板和上下文窗口，它们之间只能通过结构化的消息互相通信，不能互看对话历史。策略生成Agent不知道风险审计Agent具体怎么判断，它只收到一个结论：“该策略最大回撤超过设定阈值，需要调整仓位管理逻辑”。这个结论加上具体数值，被打包成一条消息传回策略生成Agent。

这么做的好处很明显：每个Agent的提示词可以被优化到极致，互不污染。你可以给市场研究员Agent大量宏观数据和行业研报，让它输出趋势判断；但你不希望这些数据全塞给策略生成Agent，因为它只需要基于一个简洁的策略模板做决策。上下文隔离还有效防止了token开销爆炸——多Agent系统最怕的就是所有上下文都共享，对话越长，token消耗越高，最后跑一次要几百万token。

配置多智能体时，角色定义这个环节我建议不要偷懒。我第一次配置时，偷懒只写了“你是风险控制Agent”，结果它输出什么？全是套话，一点都不具体。后来我参照Vibe-Trading里的模板改了写法，每个Agent的system prompt都要交代四件事：身份与目标、可以使用的工具、输入输出格式、绝对禁止的行为。以风险审计Agent为例：

身份与目标：你是量化策略风险审计员，负责审查策略回测结果中的风险指标， 目标是在看到任何策略时首先从风险角度寻找问题。 可以使用的工具：回测结果数据结构、风险指标计算函数。 输入输出格式：输入是回测报告JSON，输出是JSON格式的{结论: PASS/REJECT, 原因, 修改建议}。 绝对禁止的行为：禁止给出“看起来不错”这类模糊评价，必须给出精确数值和阈值。

这样配完之后，Agent的输出质量提升是肉眼可见的。

3.2 协同控制流程：从任务下发到结论收敛

多Agent协同控制，通俗讲就是怎么让一屋子各怀绝技的研究员能好好配合，最后产出一个统一结论。Vibe-Trading的协同控制流程我梳理成五个阶段：

1. 任务拆解：用户说“我想研究一个突破策略，品种用沪深300成分股，周期日线”。主控Agent把这个需求拆成子任务：数据获取任务、突破策略模板选择任务、风险偏好设置任务。
2. 任务分发：按角色分发。数据任务给数据管理员Agent，策略生成给策略生成Agent，风险参数设置给配置Agent。
3. 并行执行：多个Agent尽量并行处理。数据准备好之前，策略生成Agent可以先用占位数据结构开发策略逻辑，不互相等。
4. 结果汇总：策略生成Agent产出策略，回测执行Agent跑回测，风险审计Agent审查，每一步的结果都带有明确的元信息。
5. 迭代收敛：风险审计Agent驳回时，带着具体的修改建议回到策略生成Agent那边，重新生成，再回测，直到通过。

这里我得提一个工程上的坑：没有超时控制的多Agent系统会陷入死循环。风险审计Agent严格要求回撤低于10%，策略生成Agent怎么改都超过15%，两个Agent就会无限循环下去。Vibe-Trading在协同机制里加了一个“最大迭代次数”参数，默认是5次。5次还没通过，就把当前最优版本提交给用户，附一份失败报告，让用户来裁决。

另外，各Agent之间通信用的是消息队列模式，不是直接函数调用。这条设计很有远见——Agent可能分布在不同的进程甚至不同的机器上，用了消息队列，以后想扩展横向能力就方便了，想加一个“新闻情感分析Agent”进来，只需要订阅相关消息类型就行，不用改动已有Agent的代码。

3.3 如何引入外部工具，扩展Agent能力边界

Agent光有嘴皮子是不够的，关键是能不能调用工具。Vibe-Trading里的Agent工具分成三类：

• 数据工具：取K线、取财务数据、取板块行情。Agent可以自己按需调用，不需要用户提前把数据喂给它。
• 分析工具：计算夏普比率、最大回撤、收益分布、因子IC值等。这些工具和回测引擎解耦，Agent拿到原始序列后自己想算什么算什么。
• 通知工具：策略回测跑完、Agent之间迭代收敛时，可以通过webhook把结果推到飞书、钉钉或者微信。

我后来在自己的项目里复刻这个设计时，发现工具调用这里最容易翻车的是参数格式不匹配。Agent觉得它传了一个“20240101”格式的日期，但工具接口要的是“2024-01-01”，一报错Agent就开始胡编乱造。解决办法是用了一套JSON Schema约束，Agent在调用工具之前先要看到工具的入参Schema，LLM按照Schema生成参数，出错率大幅降低。

4. 实操：从自然语言到回测结果全流程

4.1 环境准备：快速部署工作台

我建议直接看官方文档的部署方式，这里补充一些文档里没细说的点。部署Vibe-Trading依赖的核心环境包括Python 3.10以上版本、Node.js 18以上（前端界面），以及一套LLM推理服务——你可以使用OpenAI兼容的API，也可以配置本地部署的模型。

配置本地模型时，关键在模型能力选择上。策略生成Agent最好用能力较强的模型，因为需要生成高质量代码；风险审计Agent和数据管理Agent可以用稍弱的模型，因为它们的任务更偏向逻辑判断而不是内容创造。这个配置策略能大幅降低推理成本，我一开始统一用同一个模型，跑五次迭代的token费用高到离谱，后来区分模型之后，成本降了接近一半。

启动工作台之后，一般会有两个入口：一个Web UI用于交互式对话，一个本地API端口用于程序化调用。第一次启动时它会自动检查数据目录是否存在，没有的话会帮你创建，还会下载一份示例行情数据供测试。这一步很贴心，意味着你部署完就能直接体验，不用先去准备数据。

4.2 用自然语言定义一条完整策略

我们实际来一遍。在Web UI输入框里输入这么一句话，注意这是完整的自然语言描述，不是代码：

帮我写一个策略：当收盘价突破过去20日最高价时买入， 当收盘价跌破过去10日最低价时卖出，每次交易用总资金的20%仓位， 止损设在买入价的5%以下，手续费按万2.5算。

这句话包含的信息量其实很大，主控Agent会做以下几件事：

• 提取策略要素：突破类策略（唐奇安通道变体）、入场信号（收盘价突破20日高点）、出场信号（收盘价跌破10日低点）、仓位管理（单次20%资金）、止损规则（5%固定止损）、成本设置（万2.5）。
• 转换成结构化描述：生成一个类似JSON的策略配置文件，里面把入场条件、出场条件、仓位、风控拆成了字段。
• 渲染成可执行代码：用模板代码填充这些字段，生成完整的回测脚本。

等它跑完，页面会展示一份策略卡片，包括策略逻辑摘要、关键参数、回测结果概览。你可以看到这条策略的累计收益率、年化收益、最大回撤、夏普比率、交易次数。

这类突破策略在趋势行情里表现通常不错，但在震荡行情里会被反复打脸。你可以在对话里继续追问：“帮我改成过滤震荡行情，加上ATR过滤条件”，它会自动调整策略，重新跑回测。这就是自然语言驱动的魅力所在——调策略不再是改代码，而是聊天。

4.3 回测参数的设置与解读

回测不是跑完就完了，参数设置直接影响结果的可信度。Vibe-Trading的回测配置我建议重点关注这五个参数：

1. 初始资金：默认100万，可以按自己的实际情况调。
2. 手续费率：包括佣金和印花税。A股目前印花税是单边千分之0.5（卖出时收），佣金万2.5左右，两者都要自己配进去，不然回测收益会虚高。
3. 滑点：默认设为0.02%，这是经验值。流动性好的大票可以设低一点，小票最好调高。
4. K线周期：支持分钟级、小时级、日线。周期越短，回测越慢，对数据质量要求也越高。
5. 回测区间：建议至少包含一段完整的牛熊周期，比如2018年到2024年。只看牛市的回测没有参考意义。

我之前踩过一个很深的坑：参数设置里滑点填了0，手续费也填了0，回测收益率高了整整10个百分点。实际上高频交易或者小市值策略受交易成本影响最大，策略换手率越高，交易成本的影响越夸张。所以在看回测报告时，一定要先看一眼“换手率”这个指标，换手率越高的策略，对滑点和手续费的敏感性越强。你在Vibe-Trading的配置页里把手续费和滑点调高，回去看收益率曲线，大概率会变难看，但这个变难看的过程才是接近实盘的过程。

4.4 回测报告解读与多轮对话调优

跑完回测，输出报告里会有一堆指标，很多新手会盯着“累计收益”看，这不对。我自己的习惯是看四个指标的组合：

• 年化收益：拉长到不同年份看，要是某一年暴涨、其他年份不涨，那这个策略靠的是运气。
• 最大回撤：回撤决定了你能不能拿住这个策略。回撤40%的策略，就算年化收益高，实盘中你大概率在某次回撤中割肉离场。
• 夏普比率：综合收益和波动的指标，大于1算及格，大于2算优秀。
• 盈亏比与胜率：胜率低没关系，只要盈亏比高就行。趋势跟踪策略的胜率往往只有40%左右，但盈亏比能做到3比1以上。

在多轮对话中，你可以直接对报告提出质疑：“最大回撤太大了，能不能控制在15%以内，收益可以牺牲一点”。策略生成Agent会根据这条反馈去调整相关参数——比如调低单次仓位比例、加一条移动止损规则、或者增加一个波动率过滤条件。它会重新跑回测，把新旧报告放在一起对比。这个对比很重要，你要看它不仅优化了回撤，还付出了什么代价——如果代价是年化收益从30%掉到5%，那你就要跟它协商一个折中方案。

5. 常见问题与避坑指南

5.1 回测结果严重失真，问题出在哪

我玩量化这些年，见过无数“回测猛如虎，实盘亏成狗”的案例。用Vibe-Trading跑回测时，如果发现结果好得离谱，先排查这五个因素：

尤其要注意第一项“未来函数”。在Vibe-Trading里，有一个内置检查器会扫描策略信号是否使用了未来数据，比如你在“收盘价突破20日最高”这个信号里，用了“最高价”这个当根K线结束才知道的数据，却假设当根K线的开盘价就能成交，这就是典型的未来函数。工作台会自动标黄提醒，但如果你用自定义策略代码绕过了中间表示层，这个检查就不会生效，只能靠自己盯紧。

5.2 多智能体配置中的典型坑

多Agent配置这块，遇到的坑最多，而且往往很隐蔽。我总结了三个典型场景：

场景一：Agent角色冲突。风险审计Agent和策略生成Agent如果共享了部分上下文，或者提示词里有模糊地带，两个Agent会开始“互相说服”，最后产出的是一个谁都不满意的折中策略。解决方法是严格做上下文隔离，每个Agent只看到自己需要的信息，通信消息里不允许携带除结论之外的情感化表达。

场景二：工具调用权限过大。我试过给市场研究员Agent开放了回测执行工具的权限，结果它在没有任何策略更新的情况下自己反复跑回测，浪费了大量算力。后来统一遵循最小权限原则——只有回测执行Agent能调用回测工具，其他Agent只能提交请求。

场景三：Agent吞掉错误。LLM Agent在报错后往往会“硬着头皮”编造一个答案，而不是把错误反映给主控。比如数据工具返回了空值，策略生成Agent可能忽略这个空值继续生成策略，产生一个建立在幻觉数据上的结果。解决办法是在工具返回值中增加“数据状态”字段，如果数据为空或异常，强制Agent终止当前任务，上报主控重新拉取数据。

5.3 性能优化与数据缓存管理

回测性能是另一个花钱买教训的领域。Vibe-Trading默认支持本地缓存，但这个缓存不是越大越好。如果你的数据缓存目录包含了几年内所有股票和指数的分钟线数据，那磁盘占用能到几十个GB。好在它提供了按标签清理的功能，我只保留常用指数和自选股的分钟线，日线数据全量存。

另外一个经验是回测级别的并行化。策略研究经常需要做参数网格搜索，比如测试不同入场周期（10日、20日、30日、60日）的组合效果。Vibe-Trading的多智能体调度器天然支持参数网格任务分发——每个Agent分配一组参数，并行跑回测，最后汇总成参数热力图。我实测下来，4参数组合（每个参数5个水平，就是625次回测）在单机上可能要跑两个小时，但切到并行模式后只需要二十多分钟。如果你的机器是多核CPU，这个优化非常值得启用。

5.4 使用LLM生成策略时的心得

用自然语言生成策略，最忌讳的是描述模糊。你对工作台说“找一个好的策略”，它只会给你一个通用模板；但如果你说“要求策略持仓周期在3到10天之间，平均每年交易30次左右，最大回撤控制在12%以内”，它给出的策略就明显更有针对性。自然语言驱动不是让你完全放弃思考，而是把思考的重点从“代码怎么写”转移到了“策略怎么描述”。

还有一个心得是：多轮对话比一轮对话效果好太多。第一轮先让它出一个基础版本，第二轮根据回测结果提修改意见，第三轮再针对短板优化。目前LLM的策略生成能力还做不到“一语中的”，但它非常擅长“理解修改意见并调整策略”。这也是为什么这个工作台被设计成对话式，而不是输入一条命令就完事的原因——它鼓励你把它当成一个可以反复沟通的研究员，而不是一个指令执行器。

另外提一下多智能体研究中常被忽略的可解释性问题。在Vibe-Trading里，所有Agent之间的通信记录、决策轨迹、工具调用日志都会被记录下来，你可以像看聊天记录一样回放整个策略研发过程。在研究性场景里，这个功能比最终策略本身还有价值，因为你可以分析出“为什么这个Agent在那个节点做了那个选择”，这对改进Agent设计至关重要。

最后分享一个实操小技巧

最近一次实际使用时，我发现把Vibe-Trading同时跑在两条链路上效果很好：一条走完整的多智能体流程，让策略生成、回测、风控、迭代全部自动完成；另一条我手动用数据分析工具独立验证结果。两条链路的结果做交叉验证，能极大增强我对策略的信任度。自动化不是用来取代人工判断的，而是帮你把机械劳动消耗掉，让你把精力集中在真正需要人类判断力的地方——比如“这个策略逻辑在未来的市场环境里还成不成立”这种问题。

如果你也在折腾自然语言驱动量化研究，或者正在配置多智能体系统，可以在Vibe-Trading的基础上，把你自己常用的一些分析工具或数据库接进来。这个工作台的好处是它的接口足够开放，你可以像搭乐高一样，把它演进成完全属于自己的一套研究环境。