用Delphi快速搭建AI交易Agent：从秒级Demo到可控实盘

Delphi 这个名字很容易让有经验的开发者想起老牌开发工具。但在最近这个“Show HN”发布里Delphi 是一个面向 AI 交易 agent 的快速搭建工具目标是在几分钟内拼装出一个能接收行情、调用大模型、输出交易决策的 Agent 框架。我沿着这个目标把整个链路拆了一遍先用最小样例跑通数据读取和模型调用再逐步加上校验、回测和模拟盘最后把常见坑顺了一遍。整体判断是demo 能做到“seconds”但真正接近可用状态至少要补上确定性输出、风控参数、日志审计和充分回测四块内容。这篇文章适合想用 AI Agent 做量化交易研究但不想从零搭框架的开发者也适合已经在用传统量化策略、想对比一下 agent 方案的人。如果你以为它是自动赚钱工具请先停下来它解决的是工程化问题不是预测行情问题。1. 先看清楚 Delphi 解决的是哪个环节的问题AI 交易 agent 并不是一个新概念。最常见的落地方式是把大模型当作“决策建议器”给它当前的 K 线、新闻摘要、持仓信息和风险偏好让它输出一个动作比如买入、卖出、继续持有。这个过程中真正麻烦的不是调用模型而是把行情数据、模型推理、订单执行、日志留存串成一条稳定的链路。Delphi 这类工具要解决的核心问题正是这个串联过程。从实际开发角度看它帮你省掉的是重复造轮子的时间。如果没有这个框架你要自己处理数据源字段、模型 API 重试逻辑、输出格式解析、报错处理、下单接口对接这一套下来至少得写几百行胶水代码。有了 agent 骨架之后你需要关注的重点就变成了策略本身和风控边界。1.1 它和传统量化框架的差异传统量化策略的逻辑是相对确定性的均线金叉就买入RSI 超买就卖出止损触发就平仓。整个过程由事件驱动规则明确方便回测也很难出现“意料之外”的决策。它的瓶颈在于非结构化信息很难直接参与判断比如突发新闻、公告文本、社交媒体情绪。AI 交易 agent 的思路完全不同。它让大模型在每一步决策前读取工具返回的数据再根据提示词中的规则生成动作。好处是能处理文本、新闻、多模态信息代价是模型输出天然带有概率性同一个输入两次结果可能不同。Delphi 这类框架能快速把 agent 跑起来但它不会自动帮你消除模型的不确定性。所以我的建议是不要把它理解成一个能替代所有量化策略的框架更适合的定位是“传统规则之外的决策增强层”。比如让 agent 负责判断当前市场情绪适合进攻还是防守再由固定规则执行具体下单。1.2 你需要的知识基础开始动手之前先对照一下自己的知识储备Python 基础。不要求精通但至少要看得懂报错、改得动配置。API 调用经验。模型 API、行情 API、券商 API 本质上都是 HTTP 请求。行情数据结构。至少知道 K 线、tick、订单簿之间的区别。风控常识。仓位、止损、滑点、手续费会直接影响实际收益。日志与排错能力。agent 一旦跑起来你会面对大量模型输出和交易日志。如果这些概念里有一半以上不熟悉建议先跑模拟盘不要直接接真实资金。工具再快也快不过一个风险认知缺失的决策。2. 本地搭建前的环境与前置条件“Build in seconds”的前提是环境已经准备好。如果你连 Python 虚拟环境都没有建过那第一步要花的时间会比想象中多。我把前置条件按重要程度列一遍避免你卡在奇怪的地方。这里要特别注意项目名 Delphi 和老的 Borland Delphi/Pascal 开发工具没有任何关系。网上搜索 Delphi 时会出现大量老语言资料看英文项目文档时别被带偏。2.1 基础运行环境操作系统方面Windows、macOS、Linux 都有可能支持关键看项目依赖的数据源库和交易接口库有没有对应平台的预编译包。如果你用的是 Windows遇到一些编译型依赖报错比较常见优先用虚拟环境安装不要直接往系统 Python 里塞包。Python 版本建议选择项目 README 里要求的版本。大多数 AI agent 项目会要求 Python 3.9 以上但不代表越新越好有些依赖在新版本 Python 上还没有预编译包。我习惯先建一个干净的虚拟环境再安装依赖避免和本机其他项目冲突。硬件层面要区分两种场景。如果调用云端大模型 API普通 CPU 机器就能跑因为重活都在模型服务端完成。如果你想本地部署小模型做决策那就要关注显存。一般情况下7B 级别的量化模型至少需要 8GB 显存才能流畅运行13B 以上建议直接上云端 API不然推理速度会让你怀疑人生。2.2 数据、模型和券商接口的准备工作AI 交易 agent 的正常工作依赖三样外部服务行情数据源、大模型 API、交易执行接口。行情数据源可以有多种选择公开的加密货币行情接口、美股公开数据源、商业数据服务、券商自带的行情接口都可以。这里不推荐具体厂商因为不同地区、不同交易标的能用的服务差别很大。你先要确认自己交易的标的有稳定的历史数据和实时数据来源。大模型 API 是 agent 的大脑。当前绝大多数 agent 框架都兼容 OpenAI 风格的接口协议你只需要准备一个可用的 API Key。如果无法使用境外模型服务也可以找国内兼容 OpenAI 协议的模型服务或者本地部署开源模型只是速度和质量需要自己实测。交易执行接口是风险最高的一环。我强烈建议第一阶段只接模拟盘或者 paper trading 接口。真实下单和模拟下单的返回结构类似但真实资金一旦出错很难挽回。先把接口链路打通再逐步提高资金量。2.3 一个最小配置清单一个最小配置通常包含这些模块数据源、模型、风险参数、执行接口。下面给一个示例配置字段名以你实际使用的项目文档为准但思路是通用的。# 示例配置实际字段以项目 README 为准 data_source: type: ohlcv # K线数据 symbol: BTCUSDT interval: 1h model: provider: openai_compatible model_name: your-model-name temperature: 0.2 max_tokens: 1024 risk: max_position: 0.01 # 单次最大占用资金比例 stop_loss_pct: 0.03 # 止损百分比 max_open_positions: 1 execution: broker: paper # 先接模拟盘 api_key_env: BROKER_API_KEY这里面最容易忽略的是temperature。做交易决策时建议调低比如 0.1 到 0.3降低输出的随机性。虽然不能完全消除模型的不确定性但能让结果更稳定方便你判断策略本身是否有效。另一个容易踩坑的是api_key_env密钥不要写死在配置文件里用环境变量引用避免把密钥提交到代码仓库。注意不要一上来就接真实行情加真实下单。第一次跑通只需要让“数据能读取、模型能返回结果、结果能解析”三个最小环节成立。3. 从“秒级跑通”到“可控实盘”的实操路径标题说“Build your own AI trading agent in seconds”这里说的是搭建骨架的速度不包含调优和验证。如果只追求 demo确实可以很快加载配置调用一次模型输出一个决策。但要让这个 agent 长期稳定运行需要分成三轮逐步推进。3.1 第一轮用最小样例验证链路第一轮目标非常简单让 agent 读取一段行情输出一个结构化的交易决策不实际下单。不要在这时候加入复杂策略不要多标的并行也不要开多个模型对比。from delphi import Agent agent Agent.from_config(config.yaml) decision agent.decide(symbolBTCUSDT, lookback_hours24) print(action:, decision.action) print(size:, decision.size) print(reason:, decision.reason) print(confidence:, decision.confidence)注意上面只是示意代码实际 API 名称以项目文档为准。但你应该能从这一步观察到关键信息agent 是否能成功获取行情、是否成功调用模型、是否返回了标准结构。这一步有没有跑通的判断标准不是“有没有报错”而是三个问题行情数据是否为空、模型返回是否包含合法动作、reason 字段是否可读。如果这三个都满足链路就是通的。如果这一步卡住先别优化策略直接跳到第五节排查。3.2 第二轮把交易决策映射成确定性函数模型直接输出纯文本并不可靠。正确的做法是让模型返回 JSON 并做严格校验。每个字段都要限定取值范围比如 action 只能是 buy、sell、holdsize 必须在 0 到 1 之间confidence 必须在 0 到 1 之间。任何超出范围的结果都应该被拒绝并记录。这一轮要写的不是复杂代码而是一个校验函数。不要假设模型一定会按提示词输出必须把解析失败当作常见情况处理。如果模型连续多次输出非法结果agent 应该停止交易而不是尝试“猜一个合理值”。这一步是 agent 是否可用的底线。原因很简单交易系统里一个错误的订单格式可能导致资金损失而模型输出不可靠是常态。把决策动作固定在白名单里是成本最低的风控手段。3.3 第三轮接入回测与模拟盘链路通了、输出可校验了接下来才是真正验证策略的阶段。回测的目的是用历史数据观察 agent 的决策质量但这里有个经典陷阱数据泄露。如果你的 agent 能访问到未来数据回测结果会异常漂亮实盘却一塌糊涂。要特别注意两点一是时间戳严格对齐决策时只能使用当时已经结束的 K 线二是别把整个数据集一次性传给模型要让 agent 按时间顺序逐步读取。回测通过后再切换到模拟盘。模拟盘使用真实行情但下单不会产生真实资金变动。这个阶段至少要跑一到两周观察的不是单笔盈亏而是连续运行的稳定性有没有重复下单、有没有连接中断、有没有模型超时未处理。建议先跑单条任务再开批量任务。能跑通单条不代表能稳定跑批量。批量之后的日志、失败重试、输出命名都需要单独设计。4. AI 交易 Agent 的可信度与风控参数设计这个部分是整个项目里最值得花时间的环节。AI agent 的魅力在于它能处理复杂信息但风险也来自这里模型可能产生幻觉、可能忽略关键上下文、可能在一个不该交易的时点强行输出买卖动作。你不能把一个真实资金的执行权完全交给概率性输出。4.1 不能把策略完全交给大模型大模型适合做“建议者”不适合做“最终执行者”。比如你可以让它分析当前市场状态是趋势行情还是震荡行情再根据分析结果决定启用哪套规则。具体的下单参数、止损位置、仓位大小应该由固定代码或规则模块来确定。这样做的好处是模型分析错了损失有限规则执行错了有日志能追溯。反过来如果每一步决策都交给模型出了问题你根本无法确定是提示词不佳、数据不完整还是模型幻觉导致的。要特别小心模型对市场信息的“过度解读”。让它读新闻摘要时它可能生成看似合理但完全无法执行的理由。所以提示词里应该明确约束必须基于返回的数据字段做判断不允许猜测缺失信息。4.2 单笔风险、最大仓位、熔断参数风控参数是所有交易系统的核心AI agent 也不例外。建议至少配置以下几项参数作用建议初始值max_position控制单笔资金占用比例尽量小比如总资金的 1%max_open_positions限制同时持仓数量1 到 3stop_loss_pct价格反向达到阈值自动止损2% 到 5%max_drawdown总回撤达到阈值后停止新开仓5% 到 10%cooldown_seconds两次决策之间的最小间隔至少 300 秒这些初始值不是投资建议而是一个保守起点。你真正投入资金前应该根据自己的风险承受能力调整。core的通用原则是宁可错过机会也不要让单次决策毁掉整个账户。高频交易、高杠杆、满仓操作都不适合作为第一次实盘测试的起点。4.3 日志、审计与操作留痕传统策略的运行日志可能只需要记录价格和信号。AI 交易 agent 则需要更完整的审计信息。每次决策至少要保存决策时间、标的、输入数据摘要、模型返回原文、校验结果、最终执行动作、订单回执。日志的意义不只是排错。当你发现某一天亏损异常时需要回溯是哪一次模型判断失误是数据缺失导致还是提示词覆盖不足。没有日志的 agent 就像一台没有黑匣子的飞机发生问题后很难定位。建议把所有日志写到一个独立目录按日期分文件。日志内容要包含模型返回的原始内容不要只记录格式化后的 action。否则后续想优化提示词时缺少原始输出很难判断问题出在模型还是解析层。5. 典型报错与排查顺序运行 AI 交易 agent 的报错和普通 Web 服务不太一样。很多时候错误信息看起来发生在调用模型那一层实际问题却出在数据源或配置上。下面按出现频率排序写一套通用的排查顺序。5.1 启动失败、密钥无效、数据为空先看配置。配置路径不对是最常见的问题。项目读不到配置文件时可能直接使用默认值也可能报一个不明显的错误。你应该先确认当前工作目录和配置文件路径一致再看日志里有没有提示“配置加载失败”的警告。再看环境变量。密钥没设置成功API 调用就会返回认证错误。这里不要反复试错先写一个简单脚本打印环境变量是否存在然后把密钥加载逻辑独立出来。再查网络连通性。很多模型 API 和数据源 API 对网络环境有要求网络不稳定时会表现为超时或返回空数据。数据为空时优先检查标的代码、时间区间、K 线间隔是否受支持。有些数据源对历史深度有限制请求太早的数据自然返回为空。不要急着怀疑模型先用普通 HTTP 请求直接访问数据源确认返回内容正常。5.2 回测结果和预期差距大回测结果差不要慌这是常态。先判断是策略问题还是框架问题。最有效的排查顺序是把手续费和滑点计入模型观察交易频率是否过高检查是否存在未来函数最后再评估模型判断本身。有一个非常隐蔽的问题模型在回测中看到“未来数据”后生成的决策看似准确实盘却做不到。比如你让 agent 决定 10:00 是否买入但传入的数据里包含 10:00 之后才发布的新闻摘要这就属于泄露。检查方法很简单打印每次决策所用的数据截止时间确认它一定早于决策时间。还有一个常见问题是交易频率过高。大模型倾向于“找事情做”在趋势不明时频繁买卖手续费会吃掉大量利润。如果回测交易次数明显高于你的预设先调大 cooldown_seconds再考虑在提示词里增加“不确定时保持观望”的约束。5.3 实盘挂单异常从模拟盘切换到真实接口后报错也会变多。优先检查券商 API 权限和接口限制。有些接口要求先通过实名认证有些接口对最小下单数量有要求这些错误信息会直接返回但容易被忽略。重复下单是另一个高风险问题。如果你的 agent 在模型超时后执行重试而上一笔订单已经发出就可能重复持仓。解决方法是让每个决策带上唯一请求 ID下单接口对同一个 ID 做去重处理。如果你使用的框架不支持这个功能至少要在代码里检查当前持仓再决定是否下单。最后看订单格式。有些券商接口要求价格精确到小数后几位有些要求数量为整手。格式不对时订单可能被拒也可能被错误地修改。下单成功后的回执必须保存下来和交易记录对照。排查顺序总结先确认现象是报错、卡住还是结果异常再看配置路径、密钥、网络然后检查数据源返回最后看参数和模型输出。从日志里找线索不要凭感觉改代码。6. 哪些场景适合用这类 AI 交易 Agent最后说一点冷水。Delphi 这类工具包括整个 AI trading agent 的方向更适合解决“信息分析和决策辅助”问题而不是“预测涨跌”问题。它能帮你快速搭建一个处理非结构化信息的交易决策系统但它的表现上限取决于数据质量、模型能力、提示词设计和风控执行。适合用它的人群有三类一是想验证“大模型能否辅助交易”的研究者二是已经有稳定策略、想增加一个情绪分析或新闻分析模块的开发者三是愿意长时间跑模拟盘、具备基本风控意识的个人交易者。不适合急于求成、没有量化基础、资金量不大但想高频操作的用户。我这轮实测下来的最大经验是把时间花在工程验证上比花在调提示词上更值得。提示词可以慢慢优化但数据泄露、重复下单、日志缺失这些工程问题会直接导致结果失真。先跑通最小链路再逐步加复杂功能这是最稳妥的路径。如果你也想复现这个项目我建议把“秒级跑通”当成起点而不是终点。先跑一遍 demo然后立刻加上确定性输出、风控参数和完整日志再进入回测和模拟盘。这一套走完你对 AI 交易 agent 的认知会比看任何文档都清楚。