结论
PolyHermes 目前更像一个 Polymarket 跟单执行系统，不是一个策略生成框架。它可以二次开发接入 LLM 策略层，但更合理的方式是把 LLM 放在研究、评分、建议和复盘层，把现有系统保留为执行和风控层。
如果让 LLM 直接进入下单链路，风险会明显升高：
- 策略幻觉会直接变成真实订单
- prompt 漂移会影响仓位和价格
- LLM 输出不可稳定复现，不适合作为唯一决策源
- 一旦绕过现有风控模板，回撤会更难控制
项目定位
从仓库文档看，PolyHermes 的核心职责是：
- 监控 leader 交易
- 按模板复制下单
- 管理多账户、多 leader 和订单状态
- 通过 WebSocket 和轮询同步订单与持仓
- 使用模板参数做风险控制
它的架构中心是：
- 数据采集
- 跟单规则
- 订单执行
- 风控约束
这说明它不是围绕“生成 alpha 策略”设计的。
适合接入 LLM 的位置
1. Leader 研究层
仓库里已经存在 Leader Research Agent 的概念，说明项目本身已经把“研究”和“真钱跟单”分开。LLM 很适合用于：
- 将 leader 历史行为总结成自然语言画像
- 解释某个 leader 为什么得分高或低
- 结合新闻、事件类别、频率和回撤做候选排序
- 为人工审核提供可读报告
2. 策略推荐层
LLM 更适合生成“策略建议”，例如：
- 哪类市场适合跟单
- 哪些 leader 应该降权或禁用
- 哪些模板参数更保守
- 在高波动时是否降低复制比例
这些建议应该先落到结构化配置里，再由确定性逻辑执行。
3. 复盘分析层
LLM 很适合做：
- 交易总结
- 异常订单解释
- 回撤归因
- leader 行为模式归纳
这类任务不直接触发交易，安全性更高。
不适合接入 LLM 的位置
1. 直接执行下单
如果让 LLM 直接决定：
- 买还是卖
- 下多少
- 以什么价格追单
- 是否立刻撤单
那就相当于把“交易大脑”完全交给一个非确定性组件。
2. 绕过模板风控
PolyHermes 现有模板已经提供了：
copyRatiofixedAmountmaxOrderSizeminOrderSizemaxDailyOrderspriceTolerancesupportSell
LLM 不应该替代这些硬约束，只能在它们之内做建议。
推荐改造方案
架构分层
建议拆成四层：
- 数据层
- 交易流、leader 历史、市场状态、持仓、新闻
- LLM 策略层
- 输入结构化特征
- 输出策略建议、leader 评分、模板参数建议
- 规则与风控层
- 固定阈值
- 仓位上限
- 日亏损限制
- 黑名单与 kill switch
- 执行层
- 由现有 PolyHermes 负责下单、撤单、持仓同步
推荐流程
- 采集 leader 和市场数据
- LLM 生成结构化建议
- 规则引擎做二次校验
- 仅当通过校验后才写入跟单配置
- 执行层按配置运行
- 复盘层记录结果并反哺提示词或评分模型
安全评估
| 维度 | 评估 |
|---|---|
| 接入复杂度 | 中 |
| 实盘风险 | 高 |
| 可控性 | 中到高，前提是 LLM 不直接下单 |
| 可回滚性 | 高，只要保留执行层和风控层分离 |
| 二次开发成本 | 中 |
主要风险
- 提示词风险：LLM 建议不稳定
- 数据污染：leader 历史和实时数据口径不一致
- 过拟合：策略过度依赖少量样本
- 执行风险：价格容忍度、滑点和手续费可能吞掉 edge
- 风控失效：如果把 LLM 放在风控之前，可能造成超限交易
安全底线
如果要实盘，至少要满足：
- LLM 只能输出结构化建议，不能直接发交易指令
- 所有建议必须经过硬风控
- 保留 kill switch
- 先 paper trading，再小额灰度
- 对每次 LLM 建议保留审计日志
结论
PolyHermes 可以二次开发接入 LLM 策略，但前提是：
- 不改变它作为执行系统的角色
- 不让 LLM 直接控制真金白银下单
- 把 LLM 放到研究、评分、复盘和参数建议层
如果你的目标是做一个“专职 Polymarket 智能交易 agent”，PolyHermes 更适合当作执行底座，而不是完整的决策引擎。
关联连接
- PolyHermes — Polymarket 跟单交易系统实体页
- 摘要-polyhermes — PolyHermes 项目摘要
- QuantDinger — 可对照的 AI 量化交易平台
- GenericAgent — 更适合承载自我进化策略层的通用 Agent 底座