1. 这个项目到底在解决什么问题1.1 从 Show HN 说起Hacker News 上一直被开发者称为“作品展示墙”只要在标题里挂一个 Show HN 前缀意思就是“这是我亲手做出来的东西欢迎大家来捅刀子”。Wallstreetclaws.com 这个项目就是靠这个传统进入大家视野的它的卖点一句话就能说清让用户创建 AI Agents把这些 Agent 用在交易上。这个点子放到两三年前多半会被当成概念演示。当时大家聊 AI Agent聊的是客服机器人、日程助手、文档摘要很少有人正儿八经把它和真金白银的交易挂在一起。但这两年不一样了大模型的工具调用能力、上下文长度、指令跟随能力都上了一个台阶Agent 已经有能力在真实场景里做“观察—分析—决策—执行”的完整闭环。交易这件事恰好就是一个最典型、也最考验系统能力的闭环场景。我看到这个项目第一反应是它踩对了节奏。AI Agent 的讨论已经够多了差的不是概念而是一个能让人亲手用起来的落地场景。交易虽然门槛高、风险大但它反馈快、可量化、结果一目了然——策略赚不赚钱、风控到不到位拉一张收益曲线就全暴露了。这种“真实反馈”恰恰是 Agent 技术迭代最需要的东西。1.2 交易场景为什么适合 Agent而不是传统策略很多人会把“AI 交易代理”和“量化策略”混为一谈这里要掰开说清楚。传统量化策略是工程师先把规则写好MACD 金叉买入、RSI 超卖反弹、持仓超过 5% 就止损。规则是死的哪怕市场环境完全变了它还是会面无表情地执行。你可以把它理解成一个闹钟——设定好时间它就响不会看外面是晴天还是台风。而 AI Agent 更像一个管家。它不止会执行还会“看情况”。比如 Agent 读到一条重大新闻判断市场情绪转向它可以临时调整仓位看到行情异常波动它可以主动减少交易频率甚至可以根据当前持仓和风险预算动态决定下一笔交易的大小。这些都不是预先写死的规则而是模型根据实时信息推理出来的决策。从技术实现上说两者也完全不同。传统策略是“人写逻辑机器跑逻辑”AI 交易代理是“模型写意图代码控执行”。Agent 的核心是让大模型在每一步决策前先“思考一步”——看看当前有什么数据、能调用什么工具、该不该行动然后才生成一个结构化的交易意图。这个“思考”过程就是它和传统策略最本质的区别。但这里还是要泼一盆冷水AI 交易代理不是印钞机。它只是把传统量化里“人工盯盘、人工写规则、人工调整参数”这一大堆重复劳动交给了一个能自主决策的系统去做。收益依然来自策略逻辑和风险管理Agent 改变的只是决策的生成方式和响应速度。2. 一个 AI 交易代理的内部构造2.1 数据层Agent 的“眼睛”看到什么任何一个交易系统第一步都是数据AI 交易代理也一样。但 Agent 对数据的需求要比传统量化更宽因为它不仅要看数字还要看文本。行情数据是第一层。K 线、成交量、买卖盘口、实时价格这些是决策的基本输入。传统量化主要靠这一层做数学建模但 AI Agent 的真正优势在第二层——非结构化数据。财报新闻、公司公告、行业研报、社交媒体上的市场情绪这些文本信息对传统量化来说是出了名的难处理早期团队甚至要养一个团队专门做舆情标注。而大模型天生就是干这个的给它一段新闻它不但能读懂还能总结出“这利好还是利空”“影响程度有多大”。数据层的工程问题比想象中多。我自己的经验是数据质量不过关后面模型再强也是白搭。举个最常见的例子某券商接口返回的分钟级 K 线偶尔会缺一根如果你的 Agent 没有做数据补全它读取的“最新价”可能是五分钟前的旧数据由此做出的买卖决策自然是错的。更隐蔽的是时区问题跨市场交易时如果时间轴没有对齐Agent 会把两个不同时点的价格当成同一时刻来比较得出完全失真的结论。所以在实际搭建时数据层一定要做三层防护采集拉数据、清洗补缺失、去异常、缓存降低 API 调用频率。这三件事不复杂但每一件都值得单独写测试用例。2.2 决策层Agent 的“大脑”如何思考决策层是整个系统的核心也是最容易被人误解的地方。很多人以为 Agent 就是一个大模型给它一个提示词“帮我炒股”它就开始干活。真实情况远没有那么浪漫。现在主流做法是 ReAct 模式也就是“Reason Act”的循环。每一轮决策模型都先观察当前状态然后思考下一步该做什么再调用一个工具拿到工具返回的结果后继续思考。这个循环可以跑很多轮直到模型认为信息足够了才输出最终的交易意图。举个例子。你问 Agent “现在适合买入某只股票吗”它不会直接回答。它会先调用 get_price 拿当前价格再调用 get_news 读最近几条相关新闻可能还会调用 get_indicators 算一下 RSI 和 MACD最后把所有这些信息汇总才给出一个判断。这个过程看起来像人在操作实际上是模型在“推理循环”里反复调用工具、观察结果。要让这个循环稳定工作关键在工具调用function calling的工程质量。模型需要知道每个工具是干什么的、参数是什么、返回值长什么样这些都要写得很清楚。如果你的工具描述含糊模型就会乱传参比如把股票代码传成公司名称或者把 limit 订单类型写成 market。还有一个细节温度参数。在聊天场景里我们希望模型输出越多样越好所以温度通常设 0.7 或 1.0。但交易决策是高风险场景我们恰恰希望模型稳定、可重复、不发挥创意所以温度要调到接近 0。这个区别很大我见过不少团队在聊天场景调好的参数直接平移到交易场景结果 Agent 开始“自由发挥”同一个信号下一次给出完全不同的仓位建议根本没法做风控。2.3 执行层Agent 的“手脚”必须被绑起来决策层再聪明最终都要落到“买多少、什么时候下单、止损设在哪里”这些具体动作上。执行层就是 Agent 的“手脚”但我建议你最好把它的手脚绑住一半。执行层要处理的事务很多把模型输出的信号转成标准订单、调用券商或交易所 API 下单、监控订单状态已提交、已成交、已拒绝、更新持仓和账户权益。这些环节每个都有坑比如券商 API 偶尔会返回一个“未知状态”订单实际上已经成交了但系统不知道如果你的状态机处理不好就会重复下单或者漏单。我的原则很简单LLM 负责生成决策意图资金操作必须由确定性的代码执行。什么意思呢模型可以告诉你“我觉得应该买 500 股”但真正去下单的必须是一段写死的、经过充分测试的逻辑绝不能让模型直接调用下单工具。因为模型有幻觉它可能把“500 股”写成“5000 股”或者把“买入”写成“卖出”。这种错误在对话里无非是一句荒谬的话但在交易里就是实打实的损失。风控逻辑更要前置。最高单笔仓位、最大持仓数量、止损线、每日最大亏损限额这些必须放在执行层的最前面任何订单进来都要先过一遍风控闸门不通过就直接拒绝连问都不用问模型。这是一道保命防线优先级高于一切交易逻辑。3. 从零搭建一个最小可用的交易 Agent3.1 最小架构够用但五脏俱全如果你也想动手搭一个自己的 AI 交易代理我建议不要一上来就做重系统先做一个最小可用的闭环跑通之后再加功能。最小架构大概四块数据模块负责拉行情、抓新闻、算指标决策模块接一个大模型 API配置工具列表和系统提示词执行模块封装券商/交易所的下单接口风控模块仓位上限、止损线、黑名单检查技术栈没什么特别高深的Python 就够了FastAPI 做服务框架pandas 处理行情数据LLM 走 OpenAI 兼容接口或者本地部署模型执行层用你所在券商提供的 Python SDK。我这边用一个极简示例展示决策循环不绑定具体券商方便你替换成自己的数据源和下单接口。3.2 让 Agent 学会“看盘”工具函数是第一步Agent 要操作股票得先有“手”。工具函数就是它的手。下面这个示例先给 Agent 几个最基础的工具查价格、算 RSI、读新闻头条。import json import requests from datetime import datetime # 模拟的行情数据源实际使用时替换成你的数据供应商 MOCK_PRICES { AAPL: 188.5, MSFT: 415.2, TSLA: 245.8, } def get_price(symbol: str) - float: return MOCK_PRICES.get(symbol, 0.0) def get_rsi(symbol: str, period: int 14) - float: # 真实场景这里需要从历史K线计算这里返回一个模拟值 return 58.3 def get_news(symbol: str) - list[str]: return [ 公司发布最新季度财报营收超预期, 行业政策出现新的调整市场关注度上升, ] TOOLS [ { type: function, function: { name: get_price, description: 获取股票当前价格, parameters: { type: object, properties: { symbol: {type: string, description: 股票代码} }, required: [symbol], }, }, }, { type: function, function: { name: get_rsi, description: 计算股票的RSI指标用于判断超买超卖, parameters: { type: object, properties: { symbol: {type: string, description: 股票代码}, period: {type: integer, description: 周期默认14}, }, required: [symbol], }, }, }, { type: function, function: { name: get_news, description: 获取股票最新新闻头条, parameters: { type: object, properties: { symbol: {type: string, description: 股票代码} }, required: [symbol], }, }, }, ]工具实现好后就要把它们接进大模型的 function calling 循环。核心流程是先把用户指令和工具列表发给模型 → 模型返回“我要调用 get_price参数是 AAPL” → 我们执行函数把结果回传给模型 → 模型基于结果做进一步推理直到它认为信息足够输出最终决策。def run_agent_loop(user_prompt: str): messages [{role: user, content: user_prompt}] # 1. 调用模型传入工具列表 response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, tool_choiceauto, temperature0.1, # 交易场景必须用低温度 ) while True: msg response.choices[0].message messages.append(msg) # 2. 如果模型没有调用工具说明它要输最终答案了退出循环 if not msg.tool_calls: return msg.content # 3. 执行模型要求的每个工具调用 for tool_call in msg.tool_calls: func_name tool_call.function.name args json.loads(tool_call.function.arguments) if func_name get_price: result get_price(args[symbol]) elif func_name get_rsi: result get_rsi(args[symbol], args.get(period, 14)) elif func_name get_news: result get_news(args[symbol]) else: result 未知工具 messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps({symbol: args[symbol], value: result}), }) # 4. 把工具返回结果交给模型继续推理 response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, temperature0.1, )这套循环是整个 Agent 的地基。你要让模型输出结构化决策可以在最后一步要求它返回一个 JSON 格式的信号比如{ action: buy, symbol: AAPL, quantity: 100, order_type: limit, limit_price: 188.0, reason: 财报超预期叠加RSI未超买短期看多 }有了这个结构化输出风控模块就能直接验证执行模块也能直接把订单映射成券商 API 的调用参数。一个细节提醒这一步的输入输出最好都留日志。每一轮工具调用的参数、模型返回的决策、耗时全都要落盘。没有日志的 Agent 系统等于没有黑匣子的飞机出了问题根本没法定位。3.3 回测先别急着上真钱系统能跑通不代表能赚钱。任何交易 Agent 在上真实资金之前都必须经过回测这一关。回测的目的不是看“收益多高”而是验证这个 Agent 的系统行为在市场历史数据上是不是靠谱。回测框架可以选择开源项目比如 backtrader 或者 vectorbt也可以自己写一个简版。简版回测的核心逻辑并不复杂把历史的 K 线一根一根喂给 Agent 的决策循环让 Agent 在每一根 K 线结束时判断要不要交易然后根据结果更新模拟持仓和账户权益。我建议在回测阶段至少关注四个指标年化收益率衡量一年下来资金的增长速度最大回撤账户从峰值跌到谷底的最大幅度直接反映风险承受压力夏普比率每承受一单位风险能换来多少超额收益大于 1 算合格胜率和盈亏比赢的次数多不多以及赢的时候赚得多不多计算方式并不神秘。最大回撤就是在逐日权益曲线上找“最高点到之后最低点”之间的最大跌幅夏普比率大致是“策略平均收益减去无风险利率再除以收益标准差”。回测里最大的坑是过拟合。很多人看到某个参数组合在回测里收益翻倍就以为找到了财富密码。实际上这往往只是把这个参数调得恰好适配历史走势换个时间段就彻底失效。我自己的做法是回测样本必须分训练集和验证集前 70% 的时间段用来调参数后 30% 的时间段作为“没见过的数据”做验证。如果策略在验证集上收益明显下滑那基本可以断定是过拟合直接毙掉。还有一个容易忽略的成本问题回测里不能只看成交价一定要把手续费、滑点、冲击成本都算进去。尤其高频一点的策略交易成本可能是吃掉利润的最大元凶。很多策略在“理想零成本”回测下年化 30%扣掉真实交易成本后直接变负。4. 实测中的坑与排查实录4.1 回测是绿的实盘是红的这是所有交易系统新手都会遇到的魔咒。回测曲线漂亮得像教科书一上实盘就各种亏原因通常不外乎三个。第一个是未来函数也就是在回测时不小心用了“当时还没发生”的数据。比如你在模拟 2023 年 1 月的交易但数据表里不小心混入了 2023 年 2 月的财报数据Agent 在决策时就会“未卜先知”。这个问题非常隐蔽排查起来要仔细检查数据对齐逻辑。第二个是幸存者偏差。如果回测用的股票池是“现在还在上市的公司”那么那些已经退市、暴跌的股票就永远不会出现在回测里结果自然虚高。正确做法是把历史某一时刻确实存在的所有股票都纳入股票池。第三个是交易成本估算不足这个上面已经提过。解决办法是把手续费和滑点参数设得比实际更保守一些宁可回测难看一点也别让实盘给你上课。4.2 API 限流与行情延迟交易系统的 API 里到处都是限流。行情数据接口按分钟限次数模型 API 也按分钟限次数你用 Agent 一跑可能一个上午就把一天的配额用完了。我的经验是三层处理。第一层是缓存同一个股票的行情数据30 秒内不重复拉取新闻数据缓存 10 分钟因为市场没那么快变。第二层是批量请求很多行情接口支持一次传多个股票代码尽量用批量接口而不是循环单查。第三层是退避重试遇到 429 限流错误不要马上重试按指数退避策略等待第一次等 1 秒第二次等 4 秒第三次等 9 秒依次翻倍最多重试 5 次。行情延迟的问题更危险。你用的是分钟级 K 线Agent 从决策到下单可能已经过了几十秒价格早就变了。所以执行模块下单时应优先使用限价单而不是市价单否则你会在市场剧烈波动时付出远超预期的成本。4.3 模型的“一本正经胡说八道”大模型幻觉在交易场景里不是笑话是会亏钱的。我遇到过 Agent 在推理过程中把 AAPL 的价格从 188 想当然地“脑补”成了 208理由是没有调用工具而是“凭记忆”给了一个价格。还有一次模型把 get_price 的参数写成了字符串 “Apple Inc.”导致函数直接返回 0。解决思路有两个方向。一是约束工具调用把每个工具的 description 写得更细参数格式写得更严格并在代码里对参数做类型校验类型不匹配就拒绝执行并要求模型重试。二是对模型的最终决策做二次校验例如决策 JSON 里 quantity 必须是正整数limit_price 必须在当前价格 ±5% 范围内超出范围的订单一律拦截。校验逻辑不复杂但能过滤掉大部分幻觉错误。如果要更进一步可以让 Agent 在输出最终决策前增加一个“自查步骤”把价格、指标、新闻这些关键依据再列一遍然后由另一个独立的模型实例做交叉验证。双模型互相检查能显著降低幻觉率但成本也翻倍适合资金规模比较大的场景。4.4 常见问题速查表症状可能原因排查方向回测收益高但实盘亏未来函数、幸存者偏差、交易成本低估检查数据对齐逻辑、股票池时点调高成本参数Agent 频繁调 API 被限流没有做缓存和批量请求加一级缓存改用批量接口退避重试模型返回明显错误的价格幻觉没有先查行情再决策强制工具调用顺序参数类型校验二次确认实盘下单价格和决策价格差异大决策到执行之间延迟过长改用限价单缩短决策循环做滑点补偿Agent 在震荡市反复开仓策略对噪声过于敏感增加确认信号调高交易门槛降低交易频率5. 一些个人体会AI 交易代理这个方向我陆陆续续做了一年多最大的体会是技术本身并没有想象中那么玄乎ReAct 循环、function calling、行情数据处理这些都是成熟技术拼装。真正让项目拉开差距的是风控意识、工程细节以及对交易业务本身的理解。刚开始做的时候我也被“AI 自动炒股”这个概念冲昏过头觉得只要把模型调教好收益就会滚滚而来。踩过几轮坑之后才明白模型只是决策的一部分整个系统的可靠性来自数据、风控、执行这些看起来枯燥的模块。Agent 再聪明也只是把你的策略思路变成自动化的执行力它赚不赚钱最终还是取决于你在策略逻辑上有没有真正的 alpha。如果你也想在这个方向做点东西我的建议非常具体先用模拟盘或极小资金跑三个月再逐步放大。这段时间不是看收益而是看系统在各种市场环境下会不会出幺蛾子。日志和监控一定要做扎实宁可一天少交易几次也别让系统在不透明的情况下裸跑。交易是一个把错误放大的行业AI Agent 会把你的工程缺陷也放大十倍所以请先把地基打稳。