Agent-Native Market Research Layer
OpenTrade 实战调研：它真正擅长的不是“算指标”，而是把指标组织成 Agent 可消费的研究证据
OpenTrade 的项目 Repo: vortezwohl/OpenTrade。
如果把量化研究拆成“找标的、拉行情、算指标、解释状态、形成判断、持续跟踪”六个环节，那么 OpenTrade 的价值不在于独占某一个环节，而在于把这些环节里最容易碎片化的那部分工作统一起来。它把不同资产、不同后端、不同指标层级和不同输出形态包装成更稳定的 CLI 语义，再通过 observation 视图把结果整理成适合 Claude Code、Codex 等 coding agent 消费的结构化证据。
一、先从安装开始：CLI 和 skills 怎么上手
对第一次接触 OpenTrade 的读者来说，最重要的不是先讨论指标，而是先把最小可用环境搭起来。OpenTrade 本身是 Python CLI，最直接的安装方式是通过 pip。
python -m pip install -U opentrade opentrade --help # 如果 shell 里没有 opentrade 命令，也可以尝试 python -m opentrade --help
第一行负责安装或升级 CLI，第二行用来确认命令已经可用。只要能正常看到 search、resolve、quote、stock、fund、bond、futures、market、watch 这些子命令，说明 CLI 已经装好。
skill 的安装要分开理解。OpenTrade CLI 负责拿数据、组织 observation 和暴露命令树；skills 负责教 Agent 在什么场景下调用什么命令、怎样解释指标、怎样区分默认值、怎样做股票、基金、债券或期货研究。这两层通常需要一起用，效果才完整。
| 对象 | 安装方式 | 作用 |
|---|---|---|
| OpenTrade CLI | python -m pip install -U opentrade | 提供实际可执行的市场数据命令。 |
| OpenTrade skills | 从官方仓库获取 skill 目录，并导入到所用 Agent 的自定义 skills 目录或安装器中 | 告诉 Agent 如何正确调用 CLI、解释 observation、使用指标层级。 |
opentrade、stock-research、fund-research、bond-research、futures-research 这些 skill 目录，然后通过所用 Agent 的“自定义 skills”机制导入。若你的 Agent 支持从 GitHub 安装 skill，就直接用安装器导入；若不支持，就把 skill 目录手动放进该 Agent 的用户 skills 目录。# 1. 安装 CLI python -m pip install -U opentrade # 2. 验证命令是否存在 opentrade --help # 3. 从 OpenTrade 官方仓库获取 skills # 选择 opentrade / stock-research / fund-research / bond-research / futures-research # 4. 用你的 Agent 的自定义 skills 功能导入这些 skill 目录
二、OpenTrade 是什么，不是什么
从实践应用上看，OpenTrade 更像一个“面向人类和 Agent 的行情操作界面”。它把常见研究动作压缩成一组统一命令：search、resolve、quote、stock、fund、bond、futures、market、watch。这套命令树覆盖了从标的发现、代码解析、最新行情、历史数据到持续轮询的大部分前台研究动作。
但它不等价于完整量化基础设施。它不负责组合优化，不负责事件驱动回测，不负责订单执行引擎，不负责券商账户同步，也不负责严肃意义上的风险中台。如果把传统量化平台比作一座工厂，OpenTrade 不是整座工厂，而是工厂前端那台把原料整理干净、贴上标签、送进传送带的高质量分拣机。
它最擅长的部分
- 统一不同资产的查询入口，降低命令层的心智负担。
- 把最新行情、指标、近期轨迹和事件线索组织成更适合解释的结果。
- 给 Agent 一个稳定、结构化、可重复调用的数据观察接口。
- 在高频率“先看一眼、先过一遍、先排一下”场景里非常高效。
它不应该被硬扛的部分
- 用它直接替代完整研究框架、信号工厂和回测框架。
- 把任何单次 observation 结果直接当成“交易结论”。
- 把技术指标数量误当成策略质量的替代品。
- 把 CLI 输出误认为已经完成了严肃的投资决策验证。
三、技术指标在 OpenTrade 里的真实角色
很多人第一次看到 OpenTrade 支持多层技术指标，会自然地把它理解成“一个指标计算器”或者“一个命令行版看盘软件”。这个理解只对了一半。OpenTrade 当然会算指标，但它真正有价值的地方，不是多算了几个 MACD、RSI、ATR，而是把这些指标放进一个带上下文的观察结构里，让它们在研究链条中有明确角色。
从量化研究方法上说，技术指标最适合承担三类任务：第一，作为趋势、波动、量价和位置关系的压缩表达；第二，作为候选快筛时的过滤条件；第三，作为既有研究结论的执行层补充证据。它们不适合单独承担“为什么买这个资产”“为什么在这个阶段配置这类资产”“为什么这个交易逻辑长期有效”这类更高层的问题。
indicator-level 和 observation 结构，暗示用户和 Agent 应该把指标当成研究证据，而不是万能结论。四、必须先分清两套默认值：程序真实默认值 vs skill 推荐值
OpenTrade 相关讨论里最容易混淆的一点，是“CLI 程序本身的真实默认值”和“为了让 Agent 工作得更稳定，skill 推荐给 Agent 的默认调用策略”并不相同。如果不区分这两层，命令解释会乱，输出预期也会乱。
| 维度 | 程序真实默认值 | 面向 Agent 的推荐默认值 | 实践含义 |
|---|---|---|---|
| 输出格式 | table | json | 人眼临时看表适合 table，Agent 消费和后续处理适合 json。 |
| 指标等级 | advanced | full | 程序默认追求平衡，Agent 推荐更完整，便于一次拿到更充分的上下文。 |
| 视图 | observation | 通常仍优先 observation | 除非明确需要原始数据，否则 observation 更适合解释。 |
| 追踪窗口 | 32 | 128 | 窗口更长，Agent 更容易观察近期轨迹、事件线和状态变化。 |
| backend | shared 命令省略时走 auto | 默认不显式写 --backend | 推荐做法是保留 CLI 自身的自动路由和失败切换空间。 |
json / full / 128 说成“程序默认值”。它们不是程序默认值，而是更适合 Agent 执行研究任务的推荐调用方式。五、为什么 observation 视图是 OpenTrade 的关键设计
对 Agent 来说，最难消化的往往不是“没有数据”，而是“数据太散”。原始行情、技术指标、轨迹点、近期事件、元信息如果散落在多段输出里，Agent 每次都要自己重新拼装，既费 token，也容易产生误读。OpenTrade 的 observation 视图恰好解决了这个问题。
在常见的 observation 结果里，Agent 往往能看到这样一组结构：meta、latest_quote、current_metrics、trace_points、recent_events。这不是简单换了个 JSON 包装，而是把“现在是什么状态”“最近是怎么走到这里的”“哪些指标值得被解释”放到了同一个观察平面上。
六、basic / advanced / full 三层指标体系应该怎么用
OpenTrade 对技术指标不是“一股脑全部打开”，而是分成 basic、advanced、full 三层。这种分层非常实用，因为不同研究阶段需要的信息密度并不相同。
| 层级 | 最适合的场景 | 取舍逻辑 |
|---|---|---|
basic | 批量快筛、高频 watch、网络受限场景 | 轻量、足够快，适合先把明显不合格的候选排掉。 |
advanced | 常规研究、程序默认平衡方案 | 兼顾信息量与成本，是最稳妥的中间层。 |
full | Agent 深度研判、需要完整解释上下文时 | 信息最全，但更重、更慢，也更依赖历史回补质量。 |
七、配套 research skills 是怎么处理技术指标的
OpenTrade 本身提供的是数据与观察层，真正把它接进不同资产研究框架的是配套 skills。值得注意的是，这些 skills 对技术指标的态度都相当克制：它们承认指标有用，但明确把指标放在“执行层过滤、位置判断、风险提示”的位置上，而不是让指标取代基本面、宏观、产业链或条款分析。
股票研究 skill
指标主要用来判断趋势强弱、量价是否配合、当前是否追高、回调是否健康。它适合辅助买卖节奏，不适合替代商业模式、行业格局、估值和催化剂分析。
基金研究 skill
指标更多是风格节奏和持有体验层的参考，尤其适合观察净值惯性、回撤斜率、短中期趋势是否被破坏。它并不能替代基金经理能力、风格暴露和组合结构判断。
债券研究 skill
指标只能做位置和风险辅助。真正重要的仍是利率方向、信用质量、条款结构、久期暴露和流动性条件。技术面在债券研究里通常只能排第二层，不能喧宾夺主。
期货研究 skill
指标的作用会相对更强，因为期货更强调节奏、波动和趋势延续。但即便如此，OpenTrade 配套 skill 仍然把它放在宏观、库存、期限结构、基差和主力合约研究之后，而非之前。
八、最适合落地的 Agent workflow
如果把 OpenTrade 接到 Claude Code、Codex 这类 Agent 前面，最自然的做法不是让 Agent 无脑刷命令，而是给它一条明确的工作流：先筛，再研判，再监控。这样每一步的输出都更容易解释，也更便于验证和复核。
场景一：候选快筛
目标是快速回答“有哪些标的值得进一步看”。此时不要一上来就追求最复杂的指标集合，先用较轻量的 observation 把趋势、动量、波动和位置看清楚。
opentrade quote price latest --symbols AAPL TSLA NVDA --format json --indicator-level basic --trace-window 64
场景二：深度研判
当候选对象已经缩小到少数几个时，适合切到 full，让 Agent 一次拿到更完整的 current_metrics、trace_points 和 recent_events。此时指标的作用，是验证原始研究假设能否被市场行为支持，而不是替代原始假设本身。
opentrade quote price latest --symbols AAPL --format json --indicator-level full --trace-window 128
场景三：持续跟踪
当研究结论已经形成，OpenTrade 很适合承担“观察哨”角色。它不负责替你下单，但很适合告诉 Agent：趋势有没有被破坏，波动有没有突然异常，是否需要重新拉起一次完整研究。
opentrade watch --interval 5 --count 6 quote price latest --symbols AAPL --format json --indicator-level basic
九、给 Claude Code / Codex 的实用接法
OpenTrade 最适合的接法，不是把它当成一个会自己思考的系统，而是把它当成 Agent 的外部感官。Agent 负责定义问题、组织流程、解释证据、输出结论；OpenTrade 负责把行情和技术面整理成适合消费的观察结果。
步骤 1：让 Agent 先定问题
例如“筛选近期趋势完整且回撤不过度的美股候选”，而不是“随便看下有没有机会”。问题定义清楚，命令组织才不会漂。
步骤 2：让 OpenTrade 负责拉观察结果
优先用 json + observation 让输出可被程序继续处理；需要快速大批量筛选时可适当降级指标等级。
步骤 3：让 Agent 解释，而不是复读指标
好的输出应该回答“这些指标共同说明了什么”“哪些证据互相冲突”“最可能的风险是什么”，而不是机械念一遍字段名。
步骤 4：把结果回写到研究流程
例如生成候选清单、研究备忘、复核建议、监控条件或下一轮问题列表，而不是在一次命令后就停止思考。
十、几个最容易被误用的地方
full。这会让快筛变重、watch 变慢，也会放大噪音和解释成本。auto 路由和不同 backend 的约束还没搞清时，直接把输出当成无差别同口径数据。尤其是涉及分时窗口限制时，更要理解上游后端的边界。十一、最后的判断
如果只从“能不能算很多技术指标”去理解 OpenTrade，会低估它；如果把它神化成“量化全栈平台”，又会高估它。它真正适合的位置，是成为人类研究者和 Agent 之间的一层市场观察接口。这层接口做对了，研究工作流会明显更顺：找标的更快，解释更一致，监控更容易自动化，Agent 的输出也更像一份研究结论，而不是一串指标朗读稿。