HyperGrok：给 AI Agent 配一个会"先请示再下单"的 Hyperliquid 交易台

一、先讲一个场景

假设你是一个人在做 Hyperliquid 永续合约。你打开 ChatGPT 或 Claude Code，说"帮我看看 ETH 现在能不能进"，然后过五分钟，你发现 AI 已经给你下了单。这大概是你最不想遇到的事。 HyperGrok（galleonlabs/hypergrok-trading-desk）要解决的正是这个问题。它不是又一个"AI 自动炒股"的框架，而是给 AI Agent 装上一套交易台的规章制度：7 个分工明确的角色、17 个共享技能、1 个唯一有下单权限的"写者"，以及一张必须由你本人按票号批准才能生效的票据（ticket）流程。 项目的一句话自我介绍是："Seven agents, one writer, your approval."（七个代理，一个写者，你的批准。）

二、背景：为什么是 Hyperliquid，为什么是 2026 年

Hyperliquid 是以太坊 Layer2 上的去中心化永续合约 DEX，它的特色是订单簿完全跑在自建的高性能撮合链上，撮合延迟在亚毫秒级，且提供官方 Python SDK 与 REST/WS 接口。对于传统 CEX，API key 通常同时具备"下单"和"提现"权限，密钥泄露等于资金直接蒸发；Hyperliquid 提供了 API wallet（也叫 agent wallet） 机制——由主钱包授权一个只能交易、不能提现的子密钥，这是 HyperGrok 全套安全设计的基石。 项目由 Andrew Wilkinson 与 Galleon Labs 于 2026 年 8 月创建，10 月 25 日发布 v1.7.0。当前 201 stars、44 forks、71 次提交、MIT 许可，几乎全部代码是 Python（27.9 万字节）+ 少量 Shell。有意思的是，它同时在 skills.sh、cursor.directory、botdirectory.ai 等多个 Agent 技能市场上架——它卖的不是代码，而是流程。

三、类比：把它想成一家真实的交易所自营交易部

这个类比能解释整个仓库的目录结构：

• agents/ 目录下的七个角色文件，就是交易部的七份岗位说明书。Desk Lead（交易台主管）统筹，Market Analyst（行情分析师）拉实时盘口，Research Analyst（研究员）看基本面与新闻催化，Strategist（策略师）把想法写成规则并回测，Risk Manager（风控）按你账户实况算仓位并有权说"不"，Execution Trader（执行交易员）是唯一持有密钥的角色，Trade Reviewer（交易复盘员）独立在群聊之外，以私聊形式记账与复盘。
• skills/ 下的 17 个 SKILL.md，就是交易部的制度手册：操作规程、交易生命周期与票据、风控限额与仓位算术、执行协议、监控例行、盘后复盘、故障应急、策略实验室，再加上 8 个 Hyperliquid 专题（安装与 API 钱包、市场数据、账户状态、订单、持仓与保证金、WebSocket、进阶操作、API 速查）。
• hooks/exchange_write_gate.py 就是门口的安检——在 Claude Code 里，凡是看起来像签名下单的 Bash 命令，一律弹窗要求人工确认。 关键设计是角色分离。六个角色只读（POST /info 公共接口），只有一个角色能写（POST /exchange 签名接口）。作者在 docs/ARCHITECTURE.md 里写得很直白："角色隔离在这里是一种工作约定，不是凭据隔离"——因为所有 Bot 共享同一台机器和同一批技能。真正的闸门不在对话里，而在 Grok Bot 原生的 "Ask first" 审批规则中，因为"能读到批准的 Bot，也能写下批准"。

四、核心功能与技术细节

1. Opening Bell：零密钥的第一次亮相

想验证这玩意能不能用，不需要钱包、不需要账号、不需要 API key：

git clone --depth 1 --branch v1.7.0 https://github.com/galleonlabs/hypergrok-trading-desk.git
cd hypergrok-trading-desk
python3 scripts/opening_bell.py --coin ETH

它直接打 Hyperliquid 公共 /info 端点，输出带时间戳的价格、资金费率、持仓量、价差与盘口深度，并且明确标注"这不是交易信号"。纯标准库实现，零第三方依赖，零网络凭证。

2. 一笔交易的七段路径

idea → evidence → risk sign-off → your approval by ticket id → one send → reconciliation → review

风控按你账户实况和交易所真实限额算出仓位并签发票据，你按票号批准，执行者只发一次，带 expiresAfter 过期保护，丢了响应就用 client order id 对账。每一个开仓、加仓、减仓、平仓动作都被视为"交易"，走同一条路径，只是换一张新票。

3. 研究数据集：可复现的历史证据

scripts/research_dataset.py 会在只读平面抓取有界 UTC 区间的 K 线与资金费率，把原始请求/响应、归一化 CSV 和带哈希的 manifest 一起存进 data/<name>/ 数据包，且永不覆盖已有数据包。策略师拿到数据包后必须先跑 --verify 离线回放校验。缺一小时就是缺一小时，作者明确写着：数据完整性、统计证据、Risk PASS 和你的批准，是四件独立的事。

4. 仓位算术：按最坏情况定尺

scripts/stop_cost.py 读取公共行情与 L2 盘口，把止损成本算给你看——按不利成交价 + 双边 taker 手续费来定仓位。文档里反复强调：实际亏损可能超过这个假设。

5. 多运行时适配

同一套技能和票据流程，能装进 Grok Bot、Claude Code、Cursor、Codex、Gemini CLI、Grok Build。但作者诚实地标注了差异：Claude Code 有真实的 PreToolUse hook，Cursor 有角色 profile 但没有 hook，Grok Build 的规则加载"未经验证"，Codex 和 Gemini CLI 是把七个角色当作"带标签的流程"来跑，而不是真正的子代理。这种标注透明度在 Agent 项目里并不常见。

6. 自检与工程纪律

scripts/check.sh 是一个纯离线结构检查脚本，校验 17 个技能、7 个角色文件和各运行时 manifest 的一致性；仓库里配套有 11 个 test_*.py 单元测试文件。发布流程用 scripts/release_bump.py 同步技能哈希、拒绝在目标 tag 已存在时写入。CI 工作流跑在 GitHub Actions 上。

五、上手门槛

这个项目的"部署"其实是"安装"，而且门槛低得反常——不需要服务器、不需要 Docker、不需要 GPU：

• 最简路径：git clone + python3 scripts/opening_bell.py --coin ETH，纯标准库，Python 3.9+ 即可，五分钟内能看到真实市场快照。
• 完整路径：npm install --save-exact --ignore-scripts hypergrok-trading-desk@1.7.0，包内无 JS 入口、无运行时依赖、无安装钩子，安装不会启动交易台、更不会连钱包。
• 要真下单：你得自备 Hyperliquid API wallet（只能交易不能提现），通过运行时的密钥库注入，并验证该运行时的原生审批覆盖确实生效。作者的态度是：覆盖没验证之前，交易台停留在只读研究模式。 一句话总结门槛：读数据几乎零门槛，开钱包是真正的门槛，而那一步该由你自己按。

六、争议与局限（不回避）

1. 它不是量化系统，更不是策略。 仓库里没有任何策略代码、没有任何回测引擎、没有任何 alpha 来源。它提供的是流程与护栏，收益依然取决于人和模型在其中的判断。把 HyperGrok 当"AI 赚钱机器"是最常见的误读。
2. 角色分离的强度有限。 作者自己承认七个 Bot 共享机器与技能，"工作约定 ≠ 凭据隔离"。真正的安全取决于 Grok Bot 侧的 "Ask first" 规则是否真的覆盖了 SDK、脚本与 HTTP 三条写入路径。
3. Hook 是兜底而非门禁。 exchange_write_gate.py 用正则匹配 SDK 写方法名和 /exchange 路径，不追踪 import，作者在文件头注释中就写明"藏在辅助模块里的写入它看不见"。把安全寄托在一个正则 hook 上是不够的。
4. 多运行时的等价性未验证。 表格里那行"规则加载未经验证"是实打实的降级说明；Grok Build、Codex、Gemini CLI 路径的原生安装证明缺失。
5. 单点贡献者风险。 全部代码由一位作者（Galleon Labs / Andrew Wilkinson）编写，contributors 计数为 1，几乎没有外部代码审查。文档质量很高，但 bus factor 等于 1。
6. 永续合约本身的风险。 逐仓爆仓会直接吃掉账户，作者在 README 和 FAQ 里反复声明这不是投资建议。项目明确表示不会发币（"no token and will not launch one"）。
7. 数据可得性依赖第三方。 历史数据来自 Hyperliquid 公共接口，回测无法重建盘口内成交价，作者用 unavailable 明确标记缺失而非编造，这种"缺就是缺"的态度是加分项，但意味着实验结论天然带残缺。

七、行业意义

HyperGrok 代表的不是"AI 会炒股了"，而是 Agent 金融操作的安全工程范式正在成形：把批准权从对话里拿出来放到 Agent 运行时之外；把密钥能力降到"能交易不能提现"；把单写者、幂等对账、过期保护变成默认；把"流程"和"结果"分开评分记录。 从 2026 年 8 月创建到 10 月的 1.7.0 版本，71 次提交、10 个 release tag、17 个技能在 skills.sh 上累计 53 次安装——这个迭代节奏说明它不是灵光一现的 demo，而是一套在真实约束下反复打磨的规程。与此同时，它也在试探一个更大的命题：当 Agent 越来越多地拿到执行权，行业需要的是不是又一个更强的模型，而是更硬的护栏。 对 AI 爱好者的价值：这是一份写给人类的高质量"多 Agent 协作规范"样板；对 AI 开发者的价值：它把"审批门禁必须放在 Agent 运行时之外"这条经验，做成了一套可以直接 fork 改造的模板。