AI × 加密交易

交易 Agent 的说明书会过期：版本冲突检测与运行时元数据

知识库说上限 3，运行时配置已经是 2——交易 Agent 读的说明书过期了。这篇讲清静态 RAG 的漂移、版本冲突检测、确定性护栏，以及三种验证方式的边界。

一键发币： x402兼容 | Aptos | X Layer | SUI | SOL | BNB | ETH | BASE | ARB | OP | Polygon | Avalanche

一句话结论：交易 Agent 出错，很多时候不是模型不会判断，而是它读的说明书已经过期——RAG 知识库里的硬性上限、API 阈值和风控参数写死在几周前的文档里，实盘系统却每天在更新。有一个值得研究的样本：Agent 在下单前发现"知识库说最多 3 个子仓，运行时版本 v0.32.436 说最多 2 个"，于是比较版本号、改用实时配置、并把这次覆盖写进推理日志。真正可复用的不是"让 LLM 自己纠错"这个浪漫故事，而是它背后的三件工程事：双上下文注入、版本感知提示、确定性护栏。

本文整理 dev.to @kestrelquant《When LLMs Outsmart Their Manuals: Version Conflict Detection in Trading Agents》（2026-10-15）与 @geo_se《Can you test a crypto strategy with "fake money" first?》（dev.to，2026-10-15）两篇新文，做中文整理与二次分析。需要先说明两处立场：第一篇文章的作者是量化平台 Kestrel Quant，所述日志为脱敏自述、无法独立核验，本文把它当作"版本漂移"这一问题的一个具体样本，而不是"Agent 可以放心自主纠错"的证明；第二篇带有平台推广性质，其"验证方法论"部分与工具推荐部分已在文中分开标注。本文不构成投资建议。

一、凌晨的一份日志：Agent 发现自己读的说明书过期了

原文给出了 2026-10-14 凌晨的脱敏日志：系统正在评估一个 PONSUSDT LONG 的"子仓 swing 信号复核"，评分 44.9。Agent 的 _reasoning 字段留下了它当时的内部独白（原文为中文）：

子仓上限是 2 个（v0.32.276 说 max_positions_per_system=2：trend 通道最多 2 仓 + swing/bounce 通道最多 2 仓）。但知识库前面又说子仓最多 3 个。这里系统配置显示版本 0.32.436，比知识库的新。知识库说"子仓: swing+bounce 合计 | 加密评分…"

[Conflict Resolved]: System config v0.32.436 > Knowledge Base. Prioritizing live limit of 2.

翻译一下发生了什么：静态知识库（RAG 里的交易规则文档）写着"子仓上限 3 个"，而注入到运行时的元数据显示系统实际跑的是 v0.32.436，硬编码上限已经收紧为 2 个。版本号一比较，Agent 判断"运行时更新"，于是主动推翻知识库、采用实时限制，并把覆盖过程显式记在推理字段里，最终做出 PROCEED 裁决并成功路由订单。

这个样本的价值在两处：它同时展示了版本漂移的危险和一种可检测的解法。危险在于，如果 Agent 盲信知识库，就会按一个已经不存在的上限去下单——轻则被 API 拒绝，重则突破风险限制。解法在于，"哪份文档更新"这件事不必靠运气：版本号是可比较的。

二、问题的结构：静态 RAG vs 动态实盘

"说明书过期"在交易系统里不是边角情况，而是结构性矛盾：

规则在代码 / 配置里快速演化：子仓上限、单笔额度、杠杆系数、交易所的最小下单量与费率，都可能随版本更新而改变；
RAG 知识库是人写的、周级的：它只能反映"写下那天"的世界；
LLM 默认把检索到的文本当作事实：它不知道文档的"保质期"，更没有"文档与配置谁更权威"的先验。

原文把后果说得很直接：当 LLM 严格遵循一份过期的操作手册去实盘执行，典型结果就是订单被拒、风险限额被突破、或者触发灾难性的 API 错误。而这类失败最危险的地方在于——它看起来像"策略失效"，实际是"信息过期"，复盘方向完全错了。

对照整个 Agent 生态，这个问题并不只在交易里出现：仓库里的 AGENTS.md 说明书也存在同样的"地图过时"风险——1,866 个热门项目里约 2% 指向了已不存在的路径，而 Agent 不会跳过过时的一行，它会执行它。交易场景只是把"读错说明书"的代价放大到了真金白银。

三、架构：让 Agent 先比版本号，再执行

原文给出的方案分三层，可以逐层抄：

1）双上下文注入（Dual-Context Injection）

不要只把静态 RAG 文档塞进提示词。系统同时注入一个动态的 runtime_metadata JSON 块，内容包括：

当前系统版本号；
生效的 API 限制 / 参数；
实时环境 flag。

也就是说，Agent 的上下文里永远同时有"手册"和"当前仪表盘"，而不是只有手册。

2）交叉验证提示（Cross-Verification Prompting）

系统提示词里写死一条指令：

"如果静态知识库与动态运行时元数据存在冲突，就比较版本号；如果运行时版本更新，优先采用运行时元数据，并在 _reasoning 字段里显式记录这次覆盖。"

注意这条指令的两个细节：给出确定的比较规则（版本号新旧），而不是"请判断谁对"；要求记录覆盖，让"Agent 改读了哪份文档"本身成为可审计事件。

3）工具调用兜底（Tool-Calling Fallback）

如果 Agent 检测到版本冲突，但运行时元数据里没有那个具体的新限制，它被要求先调用 get_live_config 工具，从实盘数据库取回准确的参数，再执行交易。这解决的是"元数据不全"的中间态：不是猜，而是去取。

四、四条工程原则

作者从这次事故里总结了四条，每条都适用于任何"让 LLM 操作真实资金/资源"的系统：

把 RAG 当基线，不当真相：静态文档会腐朽，必须与动态状态注入配对；LLM 不应假设手册是最新。
把"版本感知"变成显式推理步骤：让比较时间戳或语义版本号成为思维链里必须经过的一步，而不是可选的谨慎。
记录"为什么"，不只记录"做了什么"：_reasoning 字段是这次能复盘的原因——如果只看成交记录，你只会看到一个成功订单，不会知道 Agent 曾经改写过规则。原文有一句话值得记住：透明推理对交易后审计至关重要。
优雅降级：如果冲突无法解决，默认采用最保守的风险参数，或者直接停止执行，而不是猜。

五、护栏：把"它自己判断"变成确定性检查

这是整篇原文里最应该被放大的一节。作者很清醒地指出：自主自我纠错不是银弹——

如果 LLM 误解了版本层级呢？
如果 runtime_metadata 本身被污染或损坏呢？

他们的做法是加一道独立于 LLM 的确定性检查：专门的"风险警告"模块监控推理日志，只要 Agent 基于版本冲突覆盖了核心风险参数（比如最大回撤、杠杆上限），在订单到达交易所之前，先由一段确定性的 Python 代码复核这个决定。

这条设计的含义，比"再加一个检查"更深：LLM 可以负责发现冲突、解释冲突、提出采用哪份配置；但"覆盖核心风险参数"这个动作，必须由确定性系统放行。对策略的其余部分，判断可以交给模型；对钱的边界，判断留在代码里。

六、验证的边界：回测、模拟盘、小额实盘

版本漂移解决的是"Agent 执行的规则是不是当前规则"；它不回答另一个问题：这套策略本身值不值得上线。第二篇材料把"上线前怎么验证"讲得比较完整，可直接当作清单。

三种验证方式，回答的问题并不一样：

方式	它在回答什么	主要陷阱
历史回测	用过去的数据快速看策略逻辑	过去≠未来；过拟合——历史上很美，进入新行情就崩
模拟盘（Paper Trading）	用实时行情 + 虚拟资金看"当前市况下表现"	没有真实滑点，也没有情绪压力；模拟好不等于实盘好
小额实盘	用"亏掉也不影响生活"的钱做最接近真相的验证	需要数周到数月跨越不同市场状态

行业现状是三者往往割裂在三个平台：工具 A 回测、平台 B 模拟、交易所 C 实盘——在平台之间搬运参数的隐形成本本身就是一种损耗，对新手尤其劝退。

无论用哪种方式，原文给出三个必须质疑的细节：

回测窗口覆盖极端行情了吗？只跑一段单边牛市的年化收益参考价值很低；可信的回测至少要包含一次明确的下行和一次横盘整理；
费用和滑点算进去了吗？高频策略在回测里好看，实盘中手续费会吃掉相当一部分利润；换手率高的策略，费用对净收益的影响可能达到几个百分点；
你真的理解策略逻辑吗？如果说不清它为什么买、为什么卖，再漂亮的回测也拿不住——情绪化交易往往就发生在你不理解策略的时候。

对于拿不到第三方数据的平台，原文给的务实做法是：先用最小资金、甚至不投真钱，把同一段历史数据在其他工具上跑一遍，对比回测结果有没有异常偏差；同时看它是否愿意公开可查证的牌照与监管信息（这属于平台合规判断，不是业绩背书）。

最后是上线阶段两个最常见的坑：把验证结果当承诺（市场结构会变、策略会失效，这是常态），以及验证期太短（不到一个月的小额实盘"几乎说明不了什么"——市场可能恰好处于策略擅长的那段行情里）。

七、给交易 Agent 的检查清单

[ ] 规则版本化：每个会影响下单的参数都有版本号；策略、配置、知识库三者可比；
[ ] 双上下文：静态手册 + 实时 runtime_metadata 同时进上下文，缺一不可；
[ ] 冲突规则写死：版本新的优先，覆盖动作必须写进推理日志；
[ ] 缺参数就取，不要猜：用 get_live_config 之类的工具调用拿实时值；
[ ] 推理日志不可省：审计的粒度是"决策"，不是"成交"；
[ ] 核心风控确定性化：杠杆、回撤、单笔上限的覆盖要经过独立于 LLM 的代码复核；
[ ] 无法解决就保守：降级到最保守参数或停止执行；
[ ] 验证三层分开做：回测看逻辑、模拟看市况、小额实盘看真相，别拿一层当全部；
[ ] 回测必须过"极端行情 + 费用滑点 + 你真的懂"三问；
[ ] 验证不是承诺：策略失效是常态，保留人工复核与停机开关。

系列另两篇：AGENTS.md 该写什么：1,866 个项目的说明书实测（说明书本身该怎么写）与 AI 3D 重建 Skill：Monument 一砖一瓦盖建筑（一套专业流程如何变成可安装的 Skill）。

原文链接

@kestrelquant, When LLMs Outsmart Their Manuals: Version Conflict Detection in Trading Agents（dev.to，2026-10-15）：https://dev.to/kestrelquant/when-llms-outsmart-their-manuals-version-conflict-detection-in-trading-agents-d8h
@geo_se, Can you test a crypto strategy with "fake money" first? The three validation methods differ significantly（dev.to，2026-10-15）：https://dev.to/geo_se_5f4ee3e8897cc2c32f/can-you-test-a-crypto-strategy-with-fake-money-first-the-three-validation-methods-differ-12jg

免责声明

本文仅用于学习与研究目的，不构成任何投资建议、财务建议或交易建议。文中事故日志来自服务商脱敏自述、无法独立核验，相关内容仅用于说明"版本漂移"这一类工程问题；平台与工具描述均来自公开来源。加密资产价格波动剧烈，自动化交易存在策略失效、执行错误、流动性与合约风险；任何策略、Agent 与平台都需要自行评估、保留人工复核与停机开关，并 DYOR（Do Your Own Research）。请勿使用无法承受损失的资金参与交易。

本文属于「AI × 加密交易」专题。查看专题全部文章 →

免责声明：本站资源仅用于学习目的，也不应被视为投资建议，读者在采取任何行动之前应自行研究并对自己的决定承担全部责任。